Return-path: Received: from mail-qy0-f174.google.com ([209.85.216.174]:58499 "EHLO mail-qy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756845Ab1DFVMp convert rfc822-to-8bit (ORCPT ); Wed, 6 Apr 2011 17:12:45 -0400 MIME-Version: 1.0 In-Reply-To: <1302124112.20093.11.camel@maggie> References: <1302033463-1846-1-git-send-email-zajec5@gmail.com> <1302123428.20093.6.camel@maggie> <1302124112.20093.11.camel@maggie> Date: Wed, 6 Apr 2011 23:12:44 +0200 Message-ID: Subject: Re: [RFC][PATCH] bcmai: introduce AI driver From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= To: =?UTF-8?Q?Michael_B=C3=BCsch?= Cc: Arend van Spriel , "linux-wireless@vger.kernel.org" , "John W. Linville" , Larry Finger , George Kashperko , "b43-dev@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , Russell King , Arnd Bergmann , linuxdriverproject , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: 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. -- Rafał