[RFC][PATCH] bcmai: introduce AI driver
george at znau.edu.ua
Wed Apr 6 20:00:29 EDT 2011
> W dniu 6 kwietnia 2011 23:18 użytkownik George Kashperko
> <george at znau.edu.ua> napisał:
> >> We have 2 windows. I didn't try this, but let's assume they have no
> >> limitations. We can use first window for one driver only, second
> >> driver for second driver only. That gives us 2 drivers simultaneously
> >> working drivers. No driver need to reset core really often (and not
> >> inside interrupt context) so we will switch driver's window to agent
> >> (from core) only at init/reset.
> >> The question is what amount of driver we will need to support at the same time.
> > I guess (correct me please, Broadcom guys if I'm wrong) there are two
> > functions two-head w11 pci host and therefore 4 sliding windows, 2 per
> > each function.
> I don't understand you. Can you use more friendly language? functions?
> 2head? w11?
For PCI function description take a look at PCI specs or PCI
configuration space description (e. g.
Sorry for missleading short-ups, w11 - bcm80211 core, under two-head I
mean ssb/axi with two functional cores on same interconnect (like w11
+w11, not a lot of these exists I guess). Also there were some b43+b44
on single PCI ssb host and those where implemented as ssb interconnect
on multifunctional PCI host therefore providing separate access windows
for each function.
Might I mussunderstood something (its late night here at my place) when
you where talking about using coreswitching involved for two drivers
therefore I remembered about those functions. Seems now you were talking
about chipcommon+b43 access sharing same window.
As for core switching requirments for earlier SSB interconnects on PCI
hosts where there were no direct chipcommon access, that one can be
accomplished without spin_lock/mutex for b43 or b44 cores with proper
AXI doesn't need spinlocks/mutexes as both chipcommon and pci bridge are
available directly and b43 will be the only one requiring window access.
Have nice day,
More information about the linux-arm-kernel