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"
WARNING: multiple messages have this Message-ID (diff)
From: arend@broadcom.com (Arend van Spriel)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 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 [this message]
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
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=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 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.