From: George Kashperko <george@znau.edu.ua>
To: Arend van Spriel <arend@broadcom.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Russell King <rmk@arm.linux.org.uk>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"b43-dev@lists.infradead.org" <b43-dev@lists.infradead.org>,
linuxdriverproject <devel@linuxdriverproject.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [RFC][PATCH] bcmai: introduce AI driver
Date: Thu, 07 Apr 2011 21:50:40 +0300 [thread overview]
Message-ID: <1302202240.30694.16.camel@dev.znau.edu.ua> (raw)
In-Reply-To: <op.vtj8jn133ri7v4@arend-laptop>
> On Thu, 07 Apr 2011 09:54:46 +0200, Michael Büsch <mb@bu3sch.de> wrote:
>
> >> Ahh, so while talking about 4 windows, I guess you counted fixes
> >> windows as well. That would be right, matching my knowledge.
> >>
> >> When asking question about amount of cores we may want to use
> >> simultaneously I didn't think about ChipCommon or PCIe. The real
> >> problem would be to support for example two 802.11 cores and one
> >> ethernet core at the same time. That gives us 3 cores while we have
> >> only 2 sliding windows.
> >
> > Would that really be a problem? Think of it. This combination
> > will only be available on embedded devices. But do we have windows
> > on embedded devices? I guess not. If AXI is similar to SSB, the MMIO
> > of all cores will always be mapped. So accesses can be done
> > without switch or lock.
>
> Agree. For embedded systems there is no need to switch cores. Each core
> register space and wrapper register space is mapped. In the brcm80211 we
> have the concept of fast versus slow host interface. The criteria for fast
> host interface is based on following expression:
>
> fast_host_bus = (host_bus_coretype == PCIE_CORE_ID) ||
> ((host_bus_coretype == PCI_CORE_ID) && (host_bus_corerev >= 13))
>
> If this is true, chipcommon and pci/pcie registers are accessed without
> sliding the window using the fixed offsets Rafał mentioned earlier. The
> BAR0 window size is 16KB.
Well, the major pci window managing concept in your code isn't really
fast switching but rather smart switching. chipcommon and pci bridge
core specific processing is well refined in appropriate routines each
looking like:
irqdisable switchcore(cc_or_pcie)
... code ...
switchcore(back) irqenable
Thus you always have pci window pointing to the function core and can
ioread/iowrite without spinlocking windowed accesses.
Yes, you use also "fast" switching for pci rev. >= 13 && pcie avoiding
irq(ena|disa) for such a configurations but, as I've mentioned earlier,
for axi this is rudimentary from pci rev. < 13 times as both pci bridge
and chipcommon are available simultaneously with fixed windows.
>
> > I do really think that engineers at broadcom are clever enough
> > to design a hardware that does not require expensive window sliding
> > all the time while operating.
> >
>
> If a bigger window is clever enough ;-)
>
> Gr. AvS
Have nice day,
George
next prev parent reply other threads:[~2011-04-07 18:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1302033463-1846-1-git-send-email-zajec5@gmail.com>
[not found] ` <1302032137.3969.10.camel@Joe-Laptop>
[not found] ` <BANLkTimTmqop-xzFsWr1=2RXv5z6iTre4Q@mail.gmail.com>
[not found] ` <1302035106.1923.7.camel@maggie>
2011-04-05 22:30 ` [PATCH] ssb: Use pr_fmt and pr_<level>, remove CONFIG_SSB_SILENT Joe Perches
2011-04-06 14:18 ` [RFC][PATCH] bcmai: introduce AI driver Arend van Spriel
2011-04-06 18:02 ` Rafał Miłecki
2011-04-06 20:25 ` Arend van Spriel
2011-04-06 20:40 ` Rafał Miłecki
2011-04-06 20:42 ` Rafał Miłecki
2011-04-06 20:57 ` Michael Büsch
2011-04-06 21:01 ` Rafał Miłecki
2011-04-06 21:08 ` Michael Büsch
2011-04-06 21:12 ` Rafał Miłecki
2011-04-06 21:18 ` George Kashperko
2011-04-06 23:20 ` Rafał Miłecki
2011-04-07 0:00 ` George Kashperko
2011-04-07 0:54 ` Rafał Miłecki
2011-04-07 1:02 ` George Kashperko
2011-04-07 7:54 ` Michael Büsch
2011-04-07 8:58 ` Arend van Spriel
2011-04-07 18:50 ` George Kashperko [this message]
2011-04-07 9:55 ` Rafał Miłecki
2011-04-07 18:36 ` George Kashperko
2011-04-06 21:20 ` Michael Büsch
2011-04-08 16:56 ` Rafał Miłecki
2011-04-08 17:09 ` Rafał Miłecki
2011-04-08 17:14 ` Rafał Miłecki
2011-04-08 17:24 ` Arend van Spriel
2011-04-08 17:27 ` Rafał Miłecki
2011-04-08 17:28 ` Arend van Spriel
2011-04-08 17:31 ` Rafał Miłecki
2011-04-09 7:10 ` George Kashperko
2011-04-09 11:01 ` Arend van Spriel
2011-04-10 8:01 ` Pavel Machek
2011-04-10 8:05 ` Rafał Miłecki
2011-04-10 8:24 ` Pavel Machek
2011-04-10 8:30 ` Rafał Miłecki
2011-04-10 9:33 ` Arend van Spriel
2011-04-10 11:32 ` Rafał Miłecki
2011-04-10 14:36 ` Arend van Spriel
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=1302202240.30694.16.camel@dev.znau.edu.ua \
--to=george@znau.edu.ua \
--cc=Larry.Finger@lwfinger.net \
--cc=arend@broadcom.com \
--cc=arnd@arndb.de \
--cc=b43-dev@lists.infradead.org \
--cc=devel@linuxdriverproject.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox