All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Büsch" <mb@bu3sch.de>
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC][PATCH] bcmai: introduce AI driver
Date: Wed, 06 Apr 2011 23:08:32 +0200	[thread overview]
Message-ID: <1302124112.20093.11.camel@maggie> (raw)
In-Reply-To: <BANLkTimGSoYzp0Z4vyCS_H5PDKhgjYuLBA@mail.gmail.com> (sfid-20110406_230206_684163_663F35B6)

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@bu3sch.de> napisa?:
> > On Wed, 2011-04-06 at 22:42 +0200, Rafa? Mi?ecki wrote:
> >> 2011/4/6 Rafa? Mi?ecki <zajec5@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.

-- 
Greetings Michael.

WARNING: multiple messages have this Message-ID (diff)
From: "Michael Büsch" <mb@bu3sch.de>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Arend van Spriel <arend@broadcom.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"John W. Linville" <linville@tuxdriver.com>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	George Kashperko <george@znau.edu.ua>,
	"b43-dev@lists.infradead.org" <b43-dev@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Russell King <rmk@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	linuxdriverproject <devel@linuxdriverproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] bcmai: introduce AI driver
Date: Wed, 06 Apr 2011 23:08:32 +0200	[thread overview]
Message-ID: <1302124112.20093.11.camel@maggie> (raw)
In-Reply-To: <BANLkTimGSoYzp0Z4vyCS_H5PDKhgjYuLBA@mail.gmail.com> (sfid-20110406_230206_684163_663F35B6)

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@bu3sch.de> napisał:
> > On Wed, 2011-04-06 at 22:42 +0200, Rafał Miłecki wrote:
> >> 2011/4/6 Rafał Miłecki <zajec5@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.

-- 
Greetings Michael.


WARNING: multiple messages have this Message-ID (diff)
From: mb@bu3sch.de (Michael Büsch)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC][PATCH] bcmai: introduce AI driver
Date: Wed, 06 Apr 2011 23:08:32 +0200	[thread overview]
Message-ID: <1302124112.20093.11.camel@maggie> (raw)
In-Reply-To: <BANLkTimGSoYzp0Z4vyCS_H5PDKhgjYuLBA@mail.gmail.com> (sfid-20110406_230206_684163_663F35B6)

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@bu3sch.de> napisa?:
> > On Wed, 2011-04-06 at 22:42 +0200, Rafa? Mi?ecki wrote:
> >> 2011/4/6 Rafa? Mi?ecki <zajec5@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.

-- 
Greetings Michael.

  reply	other threads:[~2011-04-06 21:08 UTC|newest]

Thread overview: 109+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-05 19:57 [RFC][PATCH] bcmai: introduce AI driver Rafał Miłecki
2011-04-05 19:57 ` Rafał Miłecki
2011-04-05 19:25 ` Rafał Miłecki
2011-04-05 19:25   ` Rafał Miłecki
2011-04-05 19:29 ` Michael Büsch
2011-04-05 19:29   ` Michael Büsch
2011-04-05 19:35 ` Joe Perches
2011-04-05 20:15   ` Rafał Miłecki
2011-04-05 20:15     ` Rafał Miłecki
2011-04-05 20:25     ` Michael Büsch
2011-04-05 20:25       ` Michael Büsch
2011-04-05 22:30       ` [PATCH] ssb: Use pr_fmt and pr_<level>, remove CONFIG_SSB_SILENT Joe Perches
2011-04-05 20:37     ` [RFC][PATCH] bcmai: introduce AI driver Joe Perches
2011-04-05 20:50     ` Larry Finger
2011-04-05 20:50       ` Larry Finger
2011-04-06 14:18 ` Arend van Spriel
2011-04-06 14:18   ` Arend van Spriel
2011-04-06 18:02   ` Rafał Miłecki
2011-04-06 18:02     ` Rafał Miłecki
2011-04-06 18:02     ` Rafał Miłecki
2011-04-06 20:25     ` Arend van Spriel
2011-04-06 20:25       ` Arend van Spriel
2011-04-06 20:40       ` Rafał Miłecki
2011-04-06 20:40         ` Rafał Miłecki
2011-04-06 20:40         ` Rafał Miłecki
2011-04-06 20:42         ` Rafał Miłecki
2011-04-06 20:42           ` Rafał Miłecki
2011-04-06 20:42           ` Rafał Miłecki
2011-04-06 20:57           ` Michael Büsch
2011-04-06 20:57             ` Michael Büsch
2011-04-06 20:57             ` Michael Büsch
2011-04-06 21:01             ` Rafał Miłecki
2011-04-06 21:01               ` Rafał Miłecki
2011-04-06 21:01               ` Rafał Miłecki
2011-04-06 21:08               ` Michael Büsch [this message]
2011-04-06 21:08                 ` Michael Büsch
2011-04-06 21:08                 ` Michael Büsch
2011-04-06 21:12                 ` Rafał Miłecki
2011-04-06 21:12                   ` Rafał Miłecki
2011-04-06 21:12                   ` Rafał Miłecki
2011-04-06 21:18                   ` George Kashperko
2011-04-06 21:18                     ` George Kashperko
2011-04-06 23:20                     ` Rafał Miłecki
2011-04-06 23:20                       ` Rafał Miłecki
2011-04-06 23:20                       ` Rafał Miłecki
2011-04-07  0:00                       ` George Kashperko
2011-04-07  0:00                         ` George Kashperko
2011-04-07  0:54                         ` Rafał Miłecki
2011-04-07  0:54                           ` Rafał Miłecki
2011-04-07  0:54                           ` Rafał Miłecki
2011-04-07  1:02                           ` George Kashperko
2011-04-07  1:02                             ` George Kashperko
2011-04-07  7:54                           ` Michael Büsch
2011-04-07  7:54                             ` Michael Büsch
2011-04-07  7:54                             ` Michael Büsch
2011-04-07  8:58                             ` Arend van Spriel
2011-04-07  8:58                               ` Arend van Spriel
2011-04-07 18:50                               ` George Kashperko
2011-04-07 18:50                                 ` George Kashperko
2011-04-07  9:55                             ` Rafał Miłecki
2011-04-07  9:55                               ` Rafał Miłecki
2011-04-07  9:55                               ` Rafał Miłecki
2011-04-07 18:36                               ` George Kashperko
2011-04-07 18:36                                 ` George Kashperko
2011-04-06 21:20                   ` Michael Büsch
2011-04-06 21:20                     ` Michael Büsch
2011-04-06 21:20                     ` Michael Büsch
2011-04-08 16:56   ` Rafał Miłecki
2011-04-08 16:56     ` Rafał Miłecki
2011-04-08 16:56     ` Rafał Miłecki
2011-04-08 17:09     ` Rafał Miłecki
2011-04-08 17:09       ` Rafał Miłecki
2011-04-08 17:09       ` Rafał Miłecki
2011-04-08 17:14       ` Rafał Miłecki
2011-04-08 17:14         ` Rafał Miłecki
2011-04-08 17:14         ` Rafał Miłecki
2011-04-08 17:24     ` Arend van Spriel
2011-04-08 17:24       ` Arend van Spriel
2011-04-08 17:27       ` Rafał Miłecki
2011-04-08 17:27         ` Rafał Miłecki
2011-04-08 17:27         ` Rafał Miłecki
2011-04-08 17:28         ` Arend van Spriel
2011-04-08 17:28           ` Arend van Spriel
2011-04-08 17:31           ` Rafał Miłecki
2011-04-08 17:31             ` Rafał Miłecki
2011-04-08 17:31             ` Rafał Miłecki
2011-04-09  7:10       ` George Kashperko
2011-04-09  7:10         ` George Kashperko
2011-04-09 11:01         ` Arend van Spriel
2011-04-09 11:01           ` Arend van Spriel
2011-04-10  8:01   ` Pavel Machek
2011-04-10  8:01     ` Pavel Machek
2011-04-10  8:05     ` Rafał Miłecki
2011-04-10  8:05       ` Rafał Miłecki
2011-04-10  8:05       ` Rafał Miłecki
2011-04-10  8:24       ` Pavel Machek
2011-04-10  8:24         ` Pavel Machek
2011-04-10  8:30         ` Rafał Miłecki
2011-04-10  8:30           ` Rafał Miłecki
2011-04-10  8:30           ` Rafał Miłecki
2011-04-10  9:33           ` Arend van Spriel
2011-04-10  9:33             ` Arend van Spriel
2011-04-10 11:32             ` Rafał Miłecki
2011-04-10 11:32               ` Rafał Miłecki
2011-04-10 11:32               ` Rafał Miłecki
2011-04-10 14:36               ` Arend van Spriel
2011-04-10 14:36                 ` Arend van Spriel
2011-04-10 16:11             ` George Kashperko
2011-04-10 16:11               ` George Kashperko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1302124112.20093.11.camel@maggie \
    --to=mb@bu3sch.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.