From: "Arend van Spriel" <arend@broadcom.com>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"John W. Linville" <linville@tuxdriver.com>,
"Michael Büsch" <mb@bu3sch.de>,
"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, 6 Apr 2011 22:25:33 +0200 [thread overview]
Message-ID: <op.vti9ote53ri7v4@arend-laptop> (raw)
In-Reply-To: <BANLkTinubrmryu=Bco5_AVcj_arn7SWZxw@mail.gmail.com>
On Wed, 06 Apr 2011 20:02:20 +0200, Rafał Miłecki <zajec5@gmail.com> wrote:
> 2011/4/6 Arend van Spriel <arend@broadcom.com>:
>> 1. Term Broadcom AI
>>
>
> I'm still little confused with that, let me read old mails, google a
> little, etc. I though AMBA AXI is AI on ARM host, give me some time
> for this.
It is the interconnect or backplane which the cores in the chip are hooked
up to. See the ARM website for some more info:
http://www.arm.com/products/system-ip/interconnect/axi/index.php
>
>> 2. Bus registration
>>
>
> You should drop initialization (to do not perform it twice), but
> ChipCommon ops are still allowed. See: bcmai_cc_read32,
> bcmai_cc_write32, bcmai_cc_mask32, bcmai_cc_set32, bcmai_cc_maskset32.
>
> You can simply call:
> bcmai_cc_read32(mydev->bus.drv_cc, CC_REGISTER);
>
> There is nothing stopping you from registering one driver for few
> cores. We do this in b43 for old SSBs with 2 wireless cores. Of course
> this is not possible to use 2 drivers for 1 core at the same time.
So in theory 2 drivers for 2 separate cores can both call
bcmai_cc_read32(). 2 drivers for 1 core indeed seems a 'little awkward' ;-)
>
>> 3. Device identification
>>
>> The cores are identified by manufacturer, core id and revision in your
>> patch. I would not use the revision because 4 out of 5 times a revision
>> change does indicate a hardware change but no change in programming
>> interface. The enumeration data does contain a more selective field
>> indicating the core class (4 bits following the core identifier). I
>> suggest
>> to replace the revision field by this class field.
>
> Please tell me sth more about "core class (4 bits following the core
> identifier)". BCMAI_CC_ID_ID is 0x0000FFFF, did you really mean
> 0x000F0000 which is revision? I guess you meant 0x00F00000 which is
> package? Thank you for pointing this, it may be very important. For
> the same reasons I want to have revision, I do not want to miss
> something else that is important. I think we should add package as one
> another core attribute.
>
You found my comment in the code on this. So given your argument above
that this is an ABI set in stone I propose to add the component class
instead of having it replace the revision.
>
>> 4. PCI Host interface
>>
>
> No, it is not for b43 only. You are right of course, I'll rename this.
> It's pretty simple (dumb) driver which is just here just to auto-load
> bcmai module for given PCI IDs. You could just register driver for
> 802.11 core and work fine with b43_pci_ai_bridge aside, but it is not
> correct name for this anyway.
>
ack.
>
>> Now for the code comments, see inline remarks below.
>
>> Probably a different name would be better. bcm suggests this is broadcom
>> specific, but it is hardware functionality provided by ARM. Suggestions:
>> axi, axidmp,amba_axi.
>
> Let me read more abouth this.
>
>
>>> +static u32 bcmai_host_pci_aread32(struct bcmai_device *core, u16
>>> offset)
>>> +{
>>> + if (unlikely(core->bus->mapped_core != core))
>>> + bcmai_host_pci_switch_core(core);
>>> + return ioread32(core->bus->mmio + 0x1000 + offset);
>>> +}
>>
>> Maybe you can replace the 0x1000 with BCMAI_CORE_SIZE (if that was the
>> correct define).
>
> I agree. Probably something like (1 * BCMAI_CORE_SIZE) would be even
> more self-explaining for new developers.
>
great.
>
>
>>> + bcmai_scan_switch_core(bus, BCMAI_ADDR_BASE);
>>
>> Is BCMAI_ADDR_BASE used in other source file in this module? Otherwise,
>> it
>> could be defined in this source file only instead of in a header file.
>
> I though we prefer to keep defines in .h in Linux, let me check (Google)
> for it.
>
>>
>> Probably this list includes some cores that were in old chips, but will
>> never show up in bcmai chips.
>
> Can you point which cores we should keep/drop?
I have that question pending over here.
Gr. AvS
--
"The most merciful thing in the world, I think, is the inability of the
human
mind to correlate all its contents." - "The Call of Cthulhu"
next prev parent reply other threads:[~2011-04-06 20:25 UTC|newest]
Thread overview: 45+ 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:25 ` Rafał Miłecki
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:25 ` Michael Büsch
2011-04-05 20:37 ` Joe Perches
2011-04-05 20:50 ` Larry Finger
2011-04-06 14:18 ` Arend van Spriel
2011-04-06 18:02 ` Rafał Miłecki
2011-04-06 20:25 ` Arend van Spriel [this message]
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
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=op.vti9ote53ri7v4@arend-laptop \
--to=arend@broadcom.com \
--cc=Larry.Finger@lwfinger.net \
--cc=arnd@arndb.de \
--cc=b43-dev@lists.infradead.org \
--cc=devel@linuxdriverproject.org \
--cc=george@znau.edu.ua \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=rmk@arm.linux.org.uk \
--cc=zajec5@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).