[RFC][PATCH] bcmai: introduce AI driver

George Kashperko george at znau.edu.ua
Wed Apr 6 21:18:57 UTC 2011


> W dniu 6 kwietnia 2011 23:08 użytkownik Michael Büsch <mb at bu3sch.de> napisał:
> > On Wed, 2011-04-06 at 23:01 +0200, Rafał Miłecki wrote:
> >> W dniu 6 kwietnia 2011 22:57 użytkownik Michael Büsch <mb at bu3sch.de> napisał:
> >> > On Wed, 2011-04-06 at 22:42 +0200, Rafał Miłecki wrote:
> >> >> 2011/4/6 Rafał Miłecki <zajec5 at gmail.com>:
> >> >> > If we want to have two drivers working on two (different) cores
> >> >> > simultaneously, we will have to add trivial mutex to group core
> >> >> > switching with core operation (read/write).
> >> >>
> >> >> With a little of work we could avoid switching and mutexes on no-host
> >> >> boards. MMIO is not limited to one core at once in such a case.
> >> >
> >> > I don't think that this is a problem at all.
> >> > All that magic does happen inside of the bus I/O handlers.
> >> > Just like SSB does it.
> >> > From a driver point of view, the I/O functions just need to
> >> > be atomic.
> >> >
> >> > For SSB it's not always 100% atomic, but we're always safe
> >> > due to some assumptions being made. But this is an SSB implementation
> >> > detail that is different from AXI. So don't look too closely
> >> > at the SSB implementation of the I/O functions. You certainly want
> >> > to implement them slightly differently in AXI. SSB currently doesn't
> >> > make use of the additional sliding windows, because they are not
> >> > available in the majority of SSB devices.
> >> >
> >> > The AXI bus subsystem will manage the sliding windows and the driver
> >> > doesn't know about the details.
> >>
> >> Sure, I've meant mutex inside bcmai (or whatever name), not on the driver side!
> >>
> >> In BCMAI:
> >> bcmai_read() {
> >> mutex_get();
> >> switch_core();
> >> ioread();
> >> mutex_release();
> >> }
> >
> > Yeah that basically is the idea. But it's a little bit harder than that.
> > The problem is that the mutex cannot be taken in interrupt context.
> > A spinlock probably is a bit hairy, too, depending on how heavy
> > a core switch is on AXI.
> >
> > On SSB we workaround this with some (dirty but working) assumptions.
> >
> > On AXI you probably can do lockless I/O, if you use the two windows
> > (how many windows are there?) in a clever way to avoid core switching
> > completely after the system was initialized.
> 
> 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.

You really was in need for core switching for PCI SSB hosts, but seem
all that stuff for PCI switching in current bcm80211/utils code is
rudimentary stuff left from PCI times when you was required to use
sliding window for chipcommon and pci bridge core access.

Have nice day,
George






More information about the devel mailing list