[lkml]   [2011]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] bcmai: introduce AI driver
    W dniu 6 kwietnia 2011 23:08 użytkownik Michael Büsch <> 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 <> napisał:
    >> > On Wed, 2011-04-06 at 22:42 +0200, Rafał Miłecki wrote:
    >> >> 2011/4/6 Rafał Miłecki <>:
    >> >> > 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-04-06 23:15    [W:0.029 / U:1.480 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site