Hello,
We have slightly improved our knowledge of new Broadcom's bus. It
appears Broadcom took standard AMBA bus and put on it two cores for
every device:
1) First core from each pair is real AMBA device, it has CID and PID.
Broadcom called it wrapper, it is used to control second core
(enabling second, disabling second, resetting second, setting flags of
second).
2) Second core from each pair is Broadcom specific device. It can
*not* be treated as standard AMBA core - attempting to read it's CID
on PID leads to machine hang. Instead it is identified by MANUF, ID,
REV and CLASS. Example can be 80211 core.
One of the idea is to integrate with current AMBA driver:
1) First driver read info about all cores in Broadcom specific way. It
registers all *wrapper* (AMBA type) cores as amba_device(s).
2) Second driver registers for cores with PID 0x103BB369 (Broadcom
specific I believe). It receives wrappers (from AMBA bus) and exposes
wrapper-related Broadcom specific core in the system.
Problem: how to expose Broadcom specific cores in the system? Remember
we can not use amba_device, because Broadcom specific cores are
programmed and identified differently.
Could we register some virtual bcm_amba bus in the system and register
Broadcom specific cores with it? Or is there something better for this
case? In summary everything I need is to make driver (for example b43)
able to register for Broadcom specific core with Broadcom specific
identifiers. For example:
static const struct axi_device_id b43_axi_tbl[] = {
AXI_CORE(AXI_MANUF_BCM, AXI_CORE_80211, 0x17, AXI_ANY_CLASS),
AXI_CORETABLE_END
};
MODULE_DEVICE_TABLE(axi, b43_axi_tbl);
We have problems deciding architecture, the whole proposed layout is
not approved as final yet. Right now I try to check possibilities.
--
Rafał
>
> We have slightly improved our knowledge of new Broadcom's bus. It
> appears Broadcom took standard AMBA bus and put on it two cores for
> every device:
> 1) First core from each pair is real AMBA device, it has CID and PID.
> Broadcom called it wrapper, it is used to control second core
> (enabling second, disabling second, resetting second, setting flags of
> second).
> 2) Second core from each pair is Broadcom specific device. It can
> *not* be treated as standard AMBA core - attempting to read it's CID
> on PID leads to machine hang. Instead it is identified by MANUF, ID,
> REV and CLASS. Example can be 80211 core.
>
> One of the idea is to integrate with current AMBA driver:
> 1) First driver read info about all cores in Broadcom specific way. It
> registers all *wrapper* (AMBA type) cores as amba_device(s).
> 2) Second driver registers for cores with PID 0x103BB369 (Broadcom
> specific I believe). It receives wrappers (from AMBA bus) and exposes
> wrapper-related Broadcom specific core in the system.
>
> Problem: how to expose Broadcom specific cores in the system? Remember
> we can not use amba_device, because Broadcom specific cores are
> programmed and identified differently.
>
> Could we register some virtual bcm_amba bus in the system and register
> Broadcom specific cores with it? Or is there something better for this
> case? In summary everything I need is to make driver (for example b43)
> able to register for Broadcom specific core with Broadcom specific
> identifiers. For example:
> static const struct axi_device_id b43_axi_tbl[] = {
> AXI_CORE(AXI_MANUF_BCM, AXI_CORE_80211, 0x17, AXI_ANY_CLASS),
> AXI_CORETABLE_END
> };
> MODULE_DEVICE_TABLE(axi, b43_axi_tbl);
>
> We have problems deciding architecture, the whole proposed layout is
> not approved as final yet. Right now I try to check possibilities.
>
If you beleive you do need to register broadcom ip core devices on amba
bus then I would suggest you to introduce class driver for broadcom
cores rather than breaking into bus_type layout. But to be honest I
think it is bad idea and your original approach where you managed agents
internally and registered _broadcom_ devices on dedicated _broadcom_ bus
have much more sense. Going your original way you still can also
register agents on amba thus registering two buses per host but honestly
registering them just for the sake of registering makes no sense at all.
Have nice day,
George
W dniu 14 kwietnia 2011 13:43 użytkownik George Kashperko
<[email protected]> napisał:
>> We have slightly improved our knowledge of new Broadcom's bus. It
>> appears Broadcom took standard AMBA bus and put on it two cores for
>> every device:
>> 1) First core from each pair is real AMBA device, it has CID and PID.
>> Broadcom called it wrapper, it is used to control second core
>> (enabling second, disabling second, resetting second, setting flags of
>> second).
>> 2) Second core from each pair is Broadcom specific device. It can
>> *not* be treated as standard AMBA core - attempting to read it's CID
>> on PID leads to machine hang. Instead it is identified by MANUF, ID,
>> REV and CLASS. Example can be 80211 core.
>>
>> One of the idea is to integrate with current AMBA driver:
>> 1) First driver read info about all cores in Broadcom specific way. It
>> registers all *wrapper* (AMBA type) cores as amba_device(s).
>> 2) Second driver registers for cores with PID 0x103BB369 (Broadcom
>> specific I believe). It receives wrappers (from AMBA bus) and exposes
>> wrapper-related Broadcom specific core in the system.
>>
>> Problem: how to expose Broadcom specific cores in the system? Remember
>> we can not use amba_device, because Broadcom specific cores are
>> programmed and identified differently.
>>
>> Could we register some virtual bcm_amba bus in the system and register
>> Broadcom specific cores with it? Or is there something better for this
>> case? In summary everything I need is to make driver (for example b43)
>> able to register for Broadcom specific core with Broadcom specific
>> identifiers. For example:
>> static const struct axi_device_id b43_axi_tbl[] = {
>> AXI_CORE(AXI_MANUF_BCM, AXI_CORE_80211, 0x17, AXI_ANY_CLASS),
>> AXI_CORETABLE_END
>> };
>> MODULE_DEVICE_TABLE(axi, b43_axi_tbl);
>>
>> We have problems deciding architecture, the whole proposed layout is
>> not approved as final yet. Right now I try to check possibilities.
>>
> If you beleive you do need to register broadcom ip core devices on amba
> bus then I would suggest you to introduce class driver for broadcom
> cores rather than breaking into bus_type layout. But to be honest I
> think it is bad idea and your original approach where you managed agents
> internally and registered _broadcom_ devices on dedicated _broadcom_ bus
> have much more sense. Going your original way you still can also
> register agents on amba thus registering two buses per host but honestly
> registering them just for the sake of registering makes no sense at all.
I think you may be right, but we got so messed with so many ideas we
need to clean this out. Our old ideas:
1) Extending ssb
2) Separated library (brcmaxi)
3) Broadcom specific bus (bcmai)
4) AMBA AXI bus (axi)
5) Integrating with drivers/amba
I simply decide to consider every idea seriously and decide which will
fit our needs the best way.
Hauke: you were proposing integrating with drivers/amba. I really
expect you to comment on this, please tell us how do you see this now,
when we have better overview. I took your proposal seriously, you can
see the results above.
I think I agree with George that in proposed architecture we are using
drivers/amba just for the idea of using it. We don't get anything from
it, we don't provide anything to it that could be used anywhere else.
I think we should simply take the last version of my patch, rename it
to bcmamba, fix last issues and commit. It looks we use almos nothing
AMBA specific in your driver.
But as I said, I treat every proposal seriously. So please share your
minds Hauke & others.
--
Rafał
On 04/14/2011 02:04 PM, Rafał Miłecki wrote:
> W dniu 14 kwietnia 2011 13:43 użytkownik George Kashperko
> <[email protected]> napisał:
>>> We have slightly improved our knowledge of new Broadcom's bus. It
>>> appears Broadcom took standard AMBA bus and put on it two cores for
>>> every device:
>>> 1) First core from each pair is real AMBA device, it has CID and PID.
>>> Broadcom called it wrapper, it is used to control second core
>>> (enabling second, disabling second, resetting second, setting flags of
>>> second).
>>> 2) Second core from each pair is Broadcom specific device. It can
>>> *not* be treated as standard AMBA core - attempting to read it's CID
>>> on PID leads to machine hang. Instead it is identified by MANUF, ID,
>>> REV and CLASS. Example can be 80211 core.
>>>
>>> One of the idea is to integrate with current AMBA driver:
>>> 1) First driver read info about all cores in Broadcom specific way. It
>>> registers all *wrapper* (AMBA type) cores as amba_device(s).
>>> 2) Second driver registers for cores with PID 0x103BB369 (Broadcom
>>> specific I believe). It receives wrappers (from AMBA bus) and exposes
>>> wrapper-related Broadcom specific core in the system.
>>>
>>> Problem: how to expose Broadcom specific cores in the system? Remember
>>> we can not use amba_device, because Broadcom specific cores are
>>> programmed and identified differently.
>>>
>>> Could we register some virtual bcm_amba bus in the system and register
>>> Broadcom specific cores with it? Or is there something better for this
>>> case? In summary everything I need is to make driver (for example b43)
>>> able to register for Broadcom specific core with Broadcom specific
>>> identifiers. For example:
>>> static const struct axi_device_id b43_axi_tbl[] = {
>>> AXI_CORE(AXI_MANUF_BCM, AXI_CORE_80211, 0x17, AXI_ANY_CLASS),
>>> AXI_CORETABLE_END
>>> };
>>> MODULE_DEVICE_TABLE(axi, b43_axi_tbl);
>>>
>>> We have problems deciding architecture, the whole proposed layout is
>>> not approved as final yet. Right now I try to check possibilities.
>>>
>> If you beleive you do need to register broadcom ip core devices on amba
>> bus then I would suggest you to introduce class driver for broadcom
>> cores rather than breaking into bus_type layout. But to be honest I
>> think it is bad idea and your original approach where you managed agents
>> internally and registered _broadcom_ devices on dedicated _broadcom_ bus
>> have much more sense. Going your original way you still can also
>> register agents on amba thus registering two buses per host but honestly
>> registering them just for the sake of registering makes no sense at all.
>
> I think you may be right, but we got so messed with so many ideas we
> need to clean this out. Our old ideas:
> 1) Extending ssb
> 2) Separated library (brcmaxi)
> 3) Broadcom specific bus (bcmai)
> 4) AMBA AXI bus (axi)
> 5) Integrating with drivers/amba
>
> I simply decide to consider every idea seriously and decide which will
> fit our needs the best way.
>
> Hauke: you were proposing integrating with drivers/amba. I really
> expect you to comment on this, please tell us how do you see this now,
> when we have better overview. I took your proposal seriously, you can
> see the results above.
I had no closer look at drivers/amba and this bus driver, I just saw
that there was a discussion about drivers/amba and this implementation
with no result. When the Bradcom cores are not directly connected to
AMBA, but are using some sort of wrapper and there are no benefits in
using drivers/amba, just leave it.
As the implementation of the Braodcom AIX Bus contains some Broadcom
extensions and there seams to be no normal AMBA device being connected
to some Broadcom devices with this special interface number 3) "Broadcom
specific bus (bcmai)" seams to the the best approach in my opinion.
> I think I agree with George that in proposed architecture we are using
> drivers/amba just for the idea of using it. We don't get anything from
> it, we don't provide anything to it that could be used anywhere else.
> I think we should simply take the last version of my patch, rename it
> to bcmamba, fix last issues and commit. It looks we use almos nothing
> AMBA specific in your driver.
This sounds good.
>
> But as I said, I treat every proposal seriously. So please share your
> minds Hauke & others.
>
Hauke
> W dniu 14 kwietnia 2011 13:43 użytkownik George Kashperko
> <[email protected]> napisał:
> >> We have slightly improved our knowledge of new Broadcom's bus. It
> >> appears Broadcom took standard AMBA bus and put on it two cores for
> >> every device:
> >> 1) First core from each pair is real AMBA device, it has CID and PID.
> >> Broadcom called it wrapper, it is used to control second core
> >> (enabling second, disabling second, resetting second, setting flags of
> >> second).
> >> 2) Second core from each pair is Broadcom specific device. It can
> >> *not* be treated as standard AMBA core - attempting to read it's CID
> >> on PID leads to machine hang. Instead it is identified by MANUF, ID,
> >> REV and CLASS. Example can be 80211 core.
> >>
> >> One of the idea is to integrate with current AMBA driver:
> >> 1) First driver read info about all cores in Broadcom specific way. It
> >> registers all *wrapper* (AMBA type) cores as amba_device(s).
> >> 2) Second driver registers for cores with PID 0x103BB369 (Broadcom
> >> specific I believe). It receives wrappers (from AMBA bus) and exposes
> >> wrapper-related Broadcom specific core in the system.
> >>
> >> Problem: how to expose Broadcom specific cores in the system? Remember
> >> we can not use amba_device, because Broadcom specific cores are
> >> programmed and identified differently.
> >>
> >> Could we register some virtual bcm_amba bus in the system and register
> >> Broadcom specific cores with it? Or is there something better for this
> >> case? In summary everything I need is to make driver (for example b43)
> >> able to register for Broadcom specific core with Broadcom specific
> >> identifiers. For example:
> >> static const struct axi_device_id b43_axi_tbl[] = {
> >> AXI_CORE(AXI_MANUF_BCM, AXI_CORE_80211, 0x17, AXI_ANY_CLASS),
> >> AXI_CORETABLE_END
> >> };
> >> MODULE_DEVICE_TABLE(axi, b43_axi_tbl);
> >>
> >> We have problems deciding architecture, the whole proposed layout is
> >> not approved as final yet. Right now I try to check possibilities.
> >>
> > If you beleive you do need to register broadcom ip core devices on amba
> > bus then I would suggest you to introduce class driver for broadcom
> > cores rather than breaking into bus_type layout. But to be honest I
> > think it is bad idea and your original approach where you managed agents
> > internally and registered _broadcom_ devices on dedicated _broadcom_ bus
> > have much more sense. Going your original way you still can also
> > register agents on amba thus registering two buses per host but honestly
> > registering them just for the sake of registering makes no sense at all.
>
> I think you may be right, but we got so messed with so many ideas we
> need to clean this out. Our old ideas:
> 1) Extending ssb
> 2) Separated library (brcmaxi)
> 3) Broadcom specific bus (bcmai)
> 4) AMBA AXI bus (axi)
> 5) Integrating with drivers/amba
First of all, think its obvious we have to implement dedicated broadcom
bus for specific broadcom devices management. Yes, the fact is,
old-style broadcom devices used Sonics SiliconBackplane interconnects,
new-line ones are based on amba axi, but both of them are industrial
buses 99,9% of which specs are electrical and about 0,1% refer to some
programmers' model. You could plan for amba or some other industrial bus
interface use by implementing enable/disable/reset/state/control as ops,
but at this point I suggest to manage agents internally by your
broadcom-specific bus driver code.
As for layout I've reviwed my original intent on bus model several days
ago after finally rewieved my latest ssb-related .pdf's findings,
Broadcom GPL sources for android, number of 2.4- and 2.6-based
ASUS/Buffalo/Dlink/Linksys/Netgear/Siemens/USRobotics/HewlettPackard/Belkin embeddables' firmwares.
Finally I see it as host->bridge->interconnect->ip_core->device where:
* host and bridge are implemented and managed by host device driver (e.
g. pci device driver managing all device pci functions or e. g. mips/arm
embeddable host);
* interconnect layer is managed by dedicated type handlers abstracted by
functional tables (providing scanning and agent management services);
* cores and their devices are managed by the bus core code regardless of
the host device type and underlying interconnect implementation.
In this way we will separate cows from horses and won't need inventing
some other bus driver when decide to support same broadcom buses over e.
g. usb.
* host driver manages bus lifetime, host-specific workarounds, provide
interconnect ports' accesses via 1+ bridges;
* interconnect handler (it could become driver at some point if/when
amba will evolve to not only platform-like embeddable bus) provides bus
enumeration and agent management;
* bus driver itself manages cooperation of upstream host/bridges with
underlying interconnect handler feeding the system with actual
buscommon/buscore/configuration/port devices.
As for devices here, classifying them to specific types
(buscommon/buscore/configuration/port/platform) will finally
differentiate pci bridge cores from host ones, will let to have
sprom/otp/flash configuration containers managed by dedicated drivers,
cleans support for non-chipcommon buscommons, buscommon-less or
chipcommon-as-buscore interconnects and more.
I see rather beneficial managing both buscommon and buscore separately
from host driver. You already "detouched" chipcommon from the bus core
code, the same way buscore can (and should I beleive) be separate
driver. The only thing here you seems to miss in your code is that
chipcommon devices (and buscore as well if only you decide to have it as
separate driver as well) are "special" and you must manage their
lifetimes to
1. ensure it's driver is loaded and initialized prior any other device
on the bus;
2. should not be unloaded until any other bus device have driver bound
to the bus;
>
> I simply decide to consider every idea seriously and decide which will
> fit our needs the best way.
>
> Hauke: you were proposing integrating with drivers/amba. I really
> expect you to comment on this, please tell us how do you see this now,
> when we have better overview. I took your proposal seriously, you can
> see the results above.
>
> I think I agree with George that in proposed architecture we are using
> drivers/amba just for the idea of using it. We don't get anything from
> it, we don't provide anything to it that could be used anywhere else.
> I think we should simply take the last version of my patch, rename it
> to bcmamba, fix last issues and commit. It looks we use almos nothing
> AMBA specific in your driver.
>
> But as I said, I treat every proposal seriously. So please share your
> minds Hauke & others.
>
Have nice day,
George
W dniu 14 kwietnia 2011 14:34 użytkownik Hauke Mehrtens
<[email protected]> napisał:
> On 04/14/2011 02:04 PM, Rafał Miłecki wrote:
>> Hauke: you were proposing integrating with drivers/amba. I really
>> expect you to comment on this, please tell us how do you see this now,
>> when we have better overview. I took your proposal seriously, you can
>> see the results above.
>
> I had no closer look at drivers/amba and this bus driver, I just saw
> that there was a discussion about drivers/amba and this implementation
> with no result. When the Bradcom cores are not directly connected to
> AMBA, but are using some sort of wrapper and there are no benefits in
> using drivers/amba, just leave it.
>
> As the implementation of the Braodcom AIX Bus contains some Broadcom
> extensions and there seams to be no normal AMBA device being connected
> to some Broadcom devices with this special interface number 3) "Broadcom
> specific bus (bcmai)" seams to the the best approach in my opinion.
Thanks for commenting.
Russell: you were asking:
> What does this do which the 'amba' bus support doesn't?
I believe I explained it well in this thread. Do you still think about
using amba/driver? Do you think we should use it?
Arnd: I found you saying:
> I believe the one thing we really want from this driver is the bus
> scan code, which is not present in the amba bus implementation,
I explained how it works, I believe scanning (EPROM in this case) it
Broadcom specific, not really AMBA standard. How do you see it?
--
Rafał
> W dniu 14 kwietnia 2011 14:34 użytkownik Hauke Mehrtens
> <[email protected]> napisał:
> > On 04/14/2011 02:04 PM, Rafał Miłecki wrote:
> >> Hauke: you were proposing integrating with drivers/amba. I really
> >> expect you to comment on this, please tell us how do you see this now,
> >> when we have better overview. I took your proposal seriously, you can
> >> see the results above.
> >
> > I had no closer look at drivers/amba and this bus driver, I just saw
> > that there was a discussion about drivers/amba and this implementation
> > with no result. When the Bradcom cores are not directly connected to
> > AMBA, but are using some sort of wrapper and there are no benefits in
> > using drivers/amba, just leave it.
> >
> > As the implementation of the Braodcom AIX Bus contains some Broadcom
> > extensions and there seams to be no normal AMBA device being connected
> > to some Broadcom devices with this special interface number 3) "Broadcom
> > specific bus (bcmai)" seams to the the best approach in my opinion.
>
> Thanks for commenting.
>
> Russell: you were asking:
> > What does this do which the 'amba' bus support doesn't?
> I believe I explained it well in this thread. Do you still think about
> using amba/driver? Do you think we should use it?
>
> Arnd: I found you saying:
> > I believe the one thing we really want from this driver is the bus
> > scan code, which is not present in the amba bus implementation,
> I explained how it works, I believe scanning (EPROM in this case) it
> Broadcom specific, not really AMBA standard. How do you see it?
>
It might not Broadcom specific as EPROM core seems to be CoreLink one
core and maybe is arm-developed. But it isn't documented publicly and we
don't know yet if it is obligatory for all amba (or at least axi)
interconnects or not.
Have nice day,
George
W dniu 14 kwietnia 2011 15:15 użytkownik George Kashperko
<[email protected]> napisał:
>
>> W dniu 14 kwietnia 2011 14:34 użytkownik Hauke Mehrtens
>> <[email protected]> napisał:
>> > On 04/14/2011 02:04 PM, Rafał Miłecki wrote:
>> >> Hauke: you were proposing integrating with drivers/amba. I really
>> >> expect you to comment on this, please tell us how do you see this now,
>> >> when we have better overview. I took your proposal seriously, you can
>> >> see the results above.
>> >
>> > I had no closer look at drivers/amba and this bus driver, I just saw
>> > that there was a discussion about drivers/amba and this implementation
>> > with no result. When the Bradcom cores are not directly connected to
>> > AMBA, but are using some sort of wrapper and there are no benefits in
>> > using drivers/amba, just leave it.
>> >
>> > As the implementation of the Braodcom AIX Bus contains some Broadcom
>> > extensions and there seams to be no normal AMBA device being connected
>> > to some Broadcom devices with this special interface number 3) "Broadcom
>> > specific bus (bcmai)" seams to the the best approach in my opinion.
>>
>> Thanks for commenting.
>>
>> Russell: you were asking:
>> > What does this do which the 'amba' bus support doesn't?
>> I believe I explained it well in this thread. Do you still think about
>> using amba/driver? Do you think we should use it?
>>
>> Arnd: I found you saying:
>> > I believe the one thing we really want from this driver is the bus
>> > scan code, which is not present in the amba bus implementation,
>> I explained how it works, I believe scanning (EPROM in this case) it
>> Broadcom specific, not really AMBA standard. How do you see it?
>>
> It might not Broadcom specific as EPROM core seems to be CoreLink one
> core and maybe is arm-developed. But it isn't documented publicly and we
> don't know yet if it is obligatory for all amba (or at least axi)
> interconnects or not.
Maybe EPROM is not Broadcom specific, but I suspect the content we
deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
manuf/id/rev/class we deal with. So I guess everything *we* (out
driver) read from EPROM is Bcm specific.
--
Rafał
> >> Arnd: I found you saying:
> >> > I believe the one thing we really want from this driver is the bus
> >> > scan code, which is not present in the amba bus implementation,
> >> I explained how it works, I believe scanning (EPROM in this case) it
> >> Broadcom specific, not really AMBA standard. How do you see it?
> >>
> > It might not Broadcom specific as EPROM core seems to be CoreLink one
> > core and maybe is arm-developed. But it isn't documented publicly and we
> > don't know yet if it is obligatory for all amba (or at least axi)
> > interconnects or not.
>
> Maybe EPROM is not Broadcom specific, but I suspect the content we
> deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
> manuf/id/rev/class we deal with. So I guess everything *we* (out
> driver) read from EPROM is Bcm specific.
>
Played around amba registers on bcm4716. For all amba cores present
(under all I mean broadcom ip core agents, oob router core, erom core,
and other I-dont-know-what-for cores present at 0x18100000). All those
feature AMBA_CID (0xb105f00d) as PrimeCell ID, and slightly different
PrimeCell PeripheralIDs:
* vendor 0xBB, part_number 0x368 for broadcom cores' agents;
* vendor 0xBB, part_number 0x367 for OOB router core (don't ask me wth
is this please);
* vendor 0xBB, part_number 0x366 for EROM core;
ARM vendor id is 0x41. Might 0xBB is Broadcom vendor id but I've found
no evidence for that with google.
Have nice day,
George
W dniu 15 kwietnia 2011 20:36 użytkownik George Kashperko
<[email protected]> napisał:
>> >> Arnd: I found you saying:
>> >> > I believe the one thing we really want from this driver is the bus
>> >> > scan code, which is not present in the amba bus implementation,
>> >> I explained how it works, I believe scanning (EPROM in this case) it
>> >> Broadcom specific, not really AMBA standard. How do you see it?
>> >>
>> > It might not Broadcom specific as EPROM core seems to be CoreLink one
>> > core and maybe is arm-developed. But it isn't documented publicly and we
>> > don't know yet if it is obligatory for all amba (or at least axi)
>> > interconnects or not.
>>
>> Maybe EPROM is not Broadcom specific, but I suspect the content we
>> deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
>> manuf/id/rev/class we deal with. So I guess everything *we* (out
>> driver) read from EPROM is Bcm specific.
>>
>
> Played around amba registers on bcm4716. For all amba cores present
> (under all I mean broadcom ip core agents, oob router core, erom core,
> and other I-dont-know-what-for cores present at 0x18100000). All those
> feature AMBA_CID (0xb105f00d) as PrimeCell ID, and slightly different
> PrimeCell PeripheralIDs:
> * vendor 0xBB, part_number 0x368 for broadcom cores' agents;
> * vendor 0xBB, part_number 0x367 for OOB router core (don't ask me wth
> is this please);
> * vendor 0xBB, part_number 0x366 for EROM core;
>
> ARM vendor id is 0x41. Might 0xBB is Broadcom vendor id but I've found
> no evidence for that with google.
Yeah, as I suspected, everything except Broadcom specific cores
matches AMBA standards quite nicely. Still, I don't see anything in it
we could use for driver.
Let's wait for Russell and Arnd to comment.
--
Rafał
> W dniu 15 kwietnia 2011 20:36 użytkownik George Kashperko
> <[email protected]> napisał:
> >> >> Arnd: I found you saying:
> >> >> > I believe the one thing we really want from this driver is the bus
> >> >> > scan code, which is not present in the amba bus implementation,
> >> >> I explained how it works, I believe scanning (EPROM in this case) it
> >> >> Broadcom specific, not really AMBA standard. How do you see it?
> >> >>
> >> > It might not Broadcom specific as EPROM core seems to be CoreLink one
> >> > core and maybe is arm-developed. But it isn't documented publicly and we
> >> > don't know yet if it is obligatory for all amba (or at least axi)
> >> > interconnects or not.
> >>
> >> Maybe EPROM is not Broadcom specific, but I suspect the content we
> >> deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
> >> manuf/id/rev/class we deal with. So I guess everything *we* (out
> >> driver) read from EPROM is Bcm specific.
> >>
> >
> > Played around amba registers on bcm4716. For all amba cores present
> > (under all I mean broadcom ip core agents, oob router core, erom core,
> > and other I-dont-know-what-for cores present at 0x18100000). All those
> > feature AMBA_CID (0xb105f00d) as PrimeCell ID, and slightly different
> > PrimeCell PeripheralIDs:
> > * vendor 0xBB, part_number 0x368 for broadcom cores' agents;
> > * vendor 0xBB, part_number 0x367 for OOB router core (don't ask me wth
> > is this please);
> > * vendor 0xBB, part_number 0x366 for EROM core;
> >
> > ARM vendor id is 0x41. Might 0xBB is Broadcom vendor id but I've found
> > no evidence for that with google.
>
> Yeah, as I suspected, everything except Broadcom specific cores
> matches AMBA standards quite nicely. Still, I don't see anything in it
> we could use for driver.
>
> Let's wait for Russell and Arnd to comment.
Summarising the differences and similarities in broadcom core management
for ssb and amba I think on another possibility on making bus-related
things.
SSB-attached cores were OCP-compliant ones. This resulted in OCP device
identification with 16-bit vendor id, 12-bit core id with all IDs
starting with 0x800. 4-bit revision code. Also seems this implied
status/control registers.
AMBA-attached broadcom cores seems to follow this reusing their
OCP-compliant cores on axi.
So, we could start with introducing virtual "ocp" bus (which could be of
some use for other vendors utilising ocp model) with additional
library/module for broadcom-specific extensions (accounting for
buscommon/buscore/etc.).
On other hand just broadcom-specific bus looks like good alternative too
but here I just fail to decide on relevant naming.
Have nice day,
George
W dniu 15 kwietnia 2011 21:42 użytkownik George Kashperko
<[email protected]> napisał:
> So, we could start with introducing virtual "ocp" bus (which could be of
> some use for other vendors utilising ocp model) with additional
> library/module for broadcom-specific extensions (accounting for
> buscommon/buscore/etc.).
I think we over-complicate that.
> On other hand just broadcom-specific bus looks like good alternative too
> but here I just fail to decide on relevant naming.
Just bcmamba / bcmaxi?
--
Rafał
> W dniu 15 kwietnia 2011 20:36 użytkownik George Kashperko
> <[email protected]> napisał:
> >> >> Arnd: I found you saying:
> >> >> > I believe the one thing we really want from this driver is the bus
> >> >> > scan code, which is not present in the amba bus implementation,
> >> >> I explained how it works, I believe scanning (EPROM in this case) it
> >> >> Broadcom specific, not really AMBA standard. How do you see it?
> >> >>
> >> > It might not Broadcom specific as EPROM core seems to be CoreLink one
> >> > core and maybe is arm-developed. But it isn't documented publicly and we
> >> > don't know yet if it is obligatory for all amba (or at least axi)
> >> > interconnects or not.
> >>
> >> Maybe EPROM is not Broadcom specific, but I suspect the content we
> >> deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
> >> manuf/id/rev/class we deal with. So I guess everything *we* (out
> >> driver) read from EPROM is Bcm specific.
> >>
> >
> > Played around amba registers on bcm4716. For all amba cores present
> > (under all I mean broadcom ip core agents, oob router core, erom core,
> > and other I-dont-know-what-for cores present at 0x18100000). All those
> > feature AMBA_CID (0xb105f00d) as PrimeCell ID, and slightly different
> > PrimeCell PeripheralIDs:
> > * vendor 0xBB, part_number 0x368 for broadcom cores' agents;
> > * vendor 0xBB, part_number 0x367 for OOB router core (don't ask me wth
> > is this please);
> > * vendor 0xBB, part_number 0x366 for EROM core;
> >
> > ARM vendor id is 0x41. Might 0xBB is Broadcom vendor id but I've found
> > no evidence for that with google.
>
> Yeah, as I suspected, everything except Broadcom specific cores
> matches AMBA standards quite nicely. Still, I don't see anything in it
> we could use for driver.
>
> Let's wait for Russell and Arnd to comment.
>
Btw, googling for PL366, PL367, PL368 gives nothing relevant except one
reference to "NIC-301 Interconnect Device Management (PL368)" which is
restricted to arm partners. Think it have something to do with that
magic "DMP - Device Management Plugin" Broadcom guys mentioned earlier.
Might those 0xBB/0x368 cores are produced with that "plugin".
Have nice day,
George
Rafał Miłecki wrote:
> > On other hand just broadcom-specific bus looks like good alternative
> > too but here I just fail to decide on relevant naming.
>
> Just bcmamba / bcmaxi?
Do bcm make any other (different) busses that would warrant a more
specific name, hinting somehow at the wireless cards specifically?
Or is it just cool to have a short name? Me I always like short names.
//Peter
2011/4/15 Peter Stuge <[email protected]>:
> Rafał Miłecki wrote:
>> > On other hand just broadcom-specific bus looks like good alternative
>> > too but here I just fail to decide on relevant naming.
>>
>> Just bcmamba / bcmaxi?
>
> Do bcm make any other (different) busses that would warrant a more
> specific name, hinting somehow at the wireless cards specifically?
>
> Or is it just cool to have a short name? Me I always like short names.
I don't think Broadcom is going to publish new cards based on AMBA
with totally different cores discovery, agent (wrapper) programming,
etc. However of course we never know that and I think Broadcom does
not as well.
Of the other point there is no sense in calling it
bcm_amba_axi_for_wifi as I believe we can meet other devices than just
wifi on this architecture. So let's just call it bcmamba and there is
not other much better solution. If in the future we will hit some
problems we can always try some renaming, aliasing... we will see.
--
Rafał
On 16 April 2011 16:00, Rafał Miłecki <[email protected]> wrote:
> Of the other point there is no sense in calling it
> bcm_amba_axi_for_wifi as I believe we can meet other devices than just
> wifi on this architecture.
Current bcm47xx/53xx SoCs from Broadcom also use this architecture for
the system bus (like the older ones used SSB), and they usually have
ethernet macs, memory controllers, mips cores on it (and, as far as I
can see, also always a 802.11 core).
Jonas
On Friday 15 April 2011, Rafał Miłecki wrote:
> W dniu 15 kwietnia 2011 20:36 użytkownik George Kashperko
> <[email protected]> napisał:
> >> >> Arnd: I found you saying:
> >> >> > I believe the one thing we really want from this driver is the bus
> >> >> > scan code, which is not present in the amba bus implementation,
> >> >> I explained how it works, I believe scanning (EPROM in this case) it
> >> >> Broadcom specific, not really AMBA standard. How do you see it?
> >>
> >> Maybe EPROM is not Broadcom specific, but I suspect the content we
> >> deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
> >> manuf/id/rev/class we deal with. So I guess everything we (out
> >> driver) read from EPROM is Bcm specific.
> >>
> >
> > Played around amba registers on bcm4716. For all amba cores present
> > (under all I mean broadcom ip core agents, oob router core, erom core,
> > and other I-dont-know-what-for cores present at 0x18100000). All those
> > feature AMBA_CID (0xb105f00d) as PrimeCell ID, and slightly different
> > PrimeCell PeripheralIDs:
> > * vendor 0xBB, part_number 0x368 for broadcom cores' agents;
> > * vendor 0xBB, part_number 0x367 for OOB router core (don't ask me wth
> > is this please);
> > * vendor 0xBB, part_number 0x366 for EROM core;
> >
> > ARM vendor id is 0x41. Might 0xBB is Broadcom vendor id but I've found
> > no evidence for that with google.
>
> Yeah, as I suspected, everything except Broadcom specific cores
> matches AMBA standards quite nicely. Still, I don't see anything in it
> we could use for driver.
>
> Let's wait for Russell and Arnd to comment.
In general, the bus_type directly relates to how a device gets probed.
If broadcom uses the same basic register layout as regular AMBA devices,
it should use the amba bus type.
Compare this to the PCI bus type, which essentially deals with devices
that have a PCI configuration space that contains generic (irq, memory,
vendor/device ID, ...) registers along with device specific registers.
I think it would be fine to extend the AMBA bus slightly if there are
just minor differences.
A new bus_type really only makes sense if you expect a lot of devices
to use this and you want to have the probing in the bus. If you only
want to have a way to enumerate devices that get created by the
parent driver, you can also use platform devices.
Arnd
W dniu 17 kwietnia 2011 19:38 użytkownik Arnd Bergmann <[email protected]> napisał:
> On Friday 15 April 2011, Rafał Miłecki wrote:
>> W dniu 15 kwietnia 2011 20:36 użytkownik George Kashperko
>> <[email protected]> napisał:
>> >> >> Arnd: I found you saying:
>> >> >> > I believe the one thing we really want from this driver is the bus
>> >> >> > scan code, which is not present in the amba bus implementation,
>> >> >> I explained how it works, I believe scanning (EPROM in this case) it
>> >> >> Broadcom specific, not really AMBA standard. How do you see it?
>> >>
>> >> Maybe EPROM is not Broadcom specific, but I suspect the content we
>> >> deal with in bcmai/axi is Broadcom specific. I didn't see any notes of
>> >> manuf/id/rev/class we deal with. So I guess everything we (out
>> >> driver) read from EPROM is Bcm specific.
>> >>
>> >
>> > Played around amba registers on bcm4716. For all amba cores present
>> > (under all I mean broadcom ip core agents, oob router core, erom core,
>> > and other I-dont-know-what-for cores present at 0x18100000). All those
>> > feature AMBA_CID (0xb105f00d) as PrimeCell ID, and slightly different
>> > PrimeCell PeripheralIDs:
>> > * vendor 0xBB, part_number 0x368 for broadcom cores' agents;
>> > * vendor 0xBB, part_number 0x367 for OOB router core (don't ask me wth
>> > is this please);
>> > * vendor 0xBB, part_number 0x366 for EROM core;
>> >
>> > ARM vendor id is 0x41. Might 0xBB is Broadcom vendor id but I've found
>> > no evidence for that with google.
>>
>> Yeah, as I suspected, everything except Broadcom specific cores
>> matches AMBA standards quite nicely. Still, I don't see anything in it
>> we could use for driver.
>>
>> Let's wait for Russell and Arnd to comment.
>
> In general, the bus_type directly relates to how a device gets probed.
> If broadcom uses the same basic register layout as regular AMBA devices,
> it should use the amba bus type.
>From Broadcom side we *could* use some registers that are AMBA
specific, they are present... but there is totally no point in doing
that. Everything we use is Broadcom specific.
> I think it would be fine to extend the AMBA bus slightly if there are
> just minor differences.
As I said, Broadcom specific driver use nothing from AMBA common
things. Plus we implement routines that are Broadcom specific and no
other platform will use them.
--
Rafał
On Monday 18 April 2011, Rafał Miłecki wrote:
> W dniu 17 kwietnia 2011 19:38 użytkownik Arnd Bergmann <[email protected]> napisał:
>
> > In general, the bus_type directly relates to how a device gets probed.
> > If broadcom uses the same basic register layout as regular AMBA devices,
> > it should use the amba bus type.
>
> From Broadcom side we *could* use some registers that are AMBA
> specific, they are present... but there is totally no point in doing
> that. Everything we use is Broadcom specific.
>
>
> > I think it would be fine to extend the AMBA bus slightly if there are
> > just minor differences.
>
> As I said, Broadcom specific driver use nothing from AMBA common
> things. Plus we implement routines that are Broadcom specific and no
> other platform will use them.
You mean the hardware has two sets of registers containing the same
information, one of them the standard registers, and one with broadcom
specific ones?
Why don't you just use the standard ones then?
Arnd
W dniu 18 kwietnia 2011 16:19 użytkownik Arnd Bergmann <[email protected]> napisał:
> On Monday 18 April 2011, Rafał Miłecki wrote:
>> W dniu 17 kwietnia 2011 19:38 użytkownik Arnd Bergmann <[email protected]> napisał:
>>
>> > In general, the bus_type directly relates to how a device gets probed.
>> > If broadcom uses the same basic register layout as regular AMBA devices,
>> > it should use the amba bus type.
>>
>> From Broadcom side we *could* use some registers that are AMBA
>> specific, they are present... but there is totally no point in doing
>> that. Everything we use is Broadcom specific.
>>
>>
>> > I think it would be fine to extend the AMBA bus slightly if there are
>> > just minor differences.
>>
>> As I said, Broadcom specific driver use nothing from AMBA common
>> things. Plus we implement routines that are Broadcom specific and no
>> other platform will use them.
>
> You mean the hardware has two sets of registers containing the same
> information, one of them the standard registers, and one with broadcom
> specific ones?
>
> Why don't you just use the standard ones then?
No. Did you read my first mail in this thread?
There is pair of cores for every device. First is AMBA-specific called
agent/wrapper and second one is Broadcom-specific.
AMBA specific core called agent/wrapper has AMBA specific registers:
CID and PID. However we do not ever read that in Broadcom driver,
because that are useless for us. On AMBA specific core we use only
some Broadcom specific registers to manage (enable/disable) *second*
(Broadcom-specific) core.
--
Rafał
> >
> > You mean the hardware has two sets of registers containing the same
> > information, one of them the standard registers, and one with broadcom
> > specific ones?
> >
> > Why don't you just use the standard ones then?
>
> No. Did you read my first mail in this thread?
>
> There is pair of cores for every device. First is AMBA-specific called
> agent/wrapper and second one is Broadcom-specific.
>
> AMBA specific core called agent/wrapper has AMBA specific registers:
> CID and PID. However we do not ever read that in Broadcom driver,
> because that are useless for us. On AMBA specific core we use only
> some Broadcom specific registers to manage (enable/disable) *second*
> (Broadcom-specific) core.
>
Actually there could be two wrappers per agent (wrappers and agents
ain't the same, wrapper could be part of agent or core, for broadcom
ssb/axi buses seems we have wrappers in agents only).
Earlier at ssb-times we had wrappers built into agent, separate agent
per core connection for each broadcom core. Connections are implied with
bus usage by core - core can act as bus initiator (starting transfers to
bus regions, those SBTMxxx registers used for control/state), bus target
(accepting transfers from external bus regions, those SBIMxxx registers)
or both.
Currently for broadcom on axi bus we have the same (might implied by
cores circuitry designed to be OCP-compliant) - cores being able to act
both as initiators and targets have two wrappers built into agent, all
other have either slave or master wrapper.
Unlike ssb, where we used wrappers differently, for axi we use them just
for reset and control/state queries and we never reset/query chipcommon
therefore can silently ignore its agent wrappers. For pcie in device
mode we might need to reset both wrappers for clean initialization (at
least I see both master and slave wrappers' reset during 4716 pci device
mode startup in number of GPL'ed sourcecodes) but here I dont know for
sure. For all other single-role cores we have either target or initiator
wrapper for agent control and as those seems to feature same dmp
register's layout therefore we see no difference in wether we reset
agent master or slave.
Unfortunately still have just one axi-based box to play with. Will be
much appreciated if you could share EROM dumps from your boards to get
better understanding of agents/wrappers coupling and relations.
As for amba bus usage I think we could get back to this idea later at
some point if/when broadcom implement some different agents and/or erom
core with other layout or if we spot broadcom-on-axi bus with some
useful native axi peripherals without DMP wrappers (they are actually
already there on the bus but we have no clue how to control them and
actualy have no need to do that anyways) which won't fit into our
coure->agent model but for now I think there is no benefit in doing
that.
Have nice day,
George
W dniu 18 kwietnia 2011 17:35 użytkownik George Kashperko
<[email protected]> napisał:
> Unfortunately still have just one axi-based box to play with. Will be
> much appreciated if you could share EROM dumps from your boards to get
> better understanding of agents/wrappers coupling and relations.
You're welcome.
It's just my standard card, not SoC.
--
Rafał
> W dniu 18 kwietnia 2011 17:35 użytkownik George Kashperko
> <[email protected]> napisał:
> > Unfortunately still have just one axi-based box to play with. Will be
> > much appreciated if you could share EROM dumps from your boards to get
> > better understanding of agents/wrappers coupling and relations.
>
> You're welcome.
>
> It's just my standard card, not SoC.
>
Thanks alot.
Have nice day,
George
On Monday 18 April 2011, Rafał Miłecki wrote:
> W dniu 18 kwietnia 2011 16:19 użytkownik Arnd Bergmann <[email protected]> napisał:
> > You mean the hardware has two sets of registers containing the same
> > information, one of them the standard registers, and one with broadcom
> > specific ones?
> >
> > Why don't you just use the standard ones then?
>
> No. Did you read my first mail in this thread?
I'm sorry, but I found the information in this thread and the related ones
highly confusing and sometimes contradictory. Thanks for clarifying it
once more.
> There is pair of cores for every device. First is AMBA-specific called
> agent/wrapper and second one is Broadcom-specific.
>
> AMBA specific core called agent/wrapper has AMBA specific registers:
> CID and PID. However we do not ever read that in Broadcom driver,
> because that are useless for us. On AMBA specific core we use only
> some Broadcom specific registers to manage (enable/disable) second
> (Broadcom-specific) core.
Ideally, we should model the devices along the IP blocks and how they
fit together. If I understand correctly what you are saying, your hardware
looks like
pci_dev
|
+---------+-----------+ ...
| | |
amba_dev amba_dev amba_dev
| | |
bcm_dev bcm_dev bcm_dev
In that case, you would need three bus types (pci_bus, amba_bus and
your own bcm_bus) and at least seven devices to represent all of it
using the device model. This is possible, but it seems you are also
saying that you don't need the complexity of this, e.g. because you
don't care about the amba device at all.
The easiest shortcut would be to not represent the AMBA devices
at all, and I guess that is fine. Introducing your own bus_type
for the broadcom devices sounds like a correct way to use the
linux driver model, especially if the devices on that bus are
totally independent from one another. I think you should do that
if you have e.g. a PCI card containing a single PCI function with
multiple IP blocks that do completely unrelated things (wifi,
bluetooth, ethernet, ...).
You could also just use platform_devices if you don't want to
introduce your own bus, and there is not much commonality between
the devices in terms of probing them.
However, I would not use the device model if the IP blocks in your
device are just responsible for different aspects of one logical
device, e.g. PHY, power management and DMA within a single network
adapter. If that is what you have, don't use a Linux device for
each of those blocks at all, but instead do a "library" module
for each block: export some interfaces from the module that can
be used by multiple drivers, and create the data structure from
the main driver, filled out with the data describing the IP
block (memory ranges, interrupts, etc).
Arnd
On Sun, 17 Apr 2011 19:38:12 +0200, Arnd Bergmann <[email protected]> wrote:
Hi Rafał,
As you probably expected I tried to integrate and use your bcmai/bcmaxi/?
driver with our brcm80211 driver (making progress). In the mean time I
tried to follow the discussions going on, but I am still catching up.
> Compare this to the PCI bus type, which essentially deals with devices
> that have a PCI configuration space that contains generic (irq, memory,
> vendor/device ID, ...) registers along with device specific registers.
How much alike is the (BCM)AXI bus type? My assumption was that each
registered PCI device is handled by a single driver module. In the
current(?) bcmai implementation each device driver is called with the
appropriate device structure reference, but it will also have the bus
structure reference and through that can also access other cores on the
(bcm)axi bus. This seems to me a potential issue when there are no
synchronization mechanisms in place (whether in a SoC configuration or
PCI-hosted). Does the PCI bus type allow driver for device A access
device B?
> A new bus_type really only makes sense if you expect a lot of devices
> to use this and you want to have the probing in the bus. If you only
> want to have a way to enumerate devices that get created by the
> parent driver, you can also use platform devices.
The main assumption of the (bcm)axi driver seems to be that each core can
be considered as a device. Correct me if I am wrong, but I consider a
device to be an entity providing a particular system function. So an
ethernet device provides ethernet connectivity function, a mixer device
provides sound mixing function, and so on. The cores within a chip are not
always self-contained like this. To clarify let's say a system function is
realized by programming core A, core B, and finally trigger core A to set
the function in motion. This implies the need of coordination between the
programming steps on those cores.
Is my view on what is a device wrong? Does a platform device differ in
this respect from a regular device?
Gr. AvS
--
"The world is indeed comic, but the joke is on mankind." — H.P. Lovecraft
On Tue, Apr 19, 2011 at 03:58:32PM +0200, Arend van Spriel wrote:
> On Sun, 17 Apr 2011 19:38:12 +0200, Arnd Bergmann <[email protected]> wrote:
>
> Hi Rafał,
>
> As you probably expected I tried to integrate and use your bcmai/bcmaxi/?
> driver with our brcm80211 driver (making progress). In the mean time
> I tried to follow the discussions going on, but I am still catching
> up.
>
> >Compare this to the PCI bus type, which essentially deals with devices
> >that have a PCI configuration space that contains generic (irq, memory,
> >vendor/device ID, ...) registers along with device specific registers.
>
> How much alike is the (BCM)AXI bus type? My assumption was that each
> registered PCI device is handled by a single driver module. In the
> current(?) bcmai implementation each device driver is called with the
> appropriate device structure reference, but it will also have the bus
> structure reference and through that can also access other cores on the
> (bcm)axi bus. This seems to me a potential issue when there are no
> synchronization mechanisms in place (whether in a SoC configuration or
> PCI-hosted). Does the PCI bus type allow driver for device A access
> device B?
>
> >A new bus_type really only makes sense if you expect a lot of devices
> >to use this and you want to have the probing in the bus. If you only
> >want to have a way to enumerate devices that get created by the
> >parent driver, you can also use platform devices.
>
> The main assumption of the (bcm)axi driver seems to be that each core can
> be considered as a device. Correct me if I am wrong, but I consider a
> device to be an entity providing a particular system function. So an
> ethernet device provides ethernet connectivity function, a mixer device
> provides sound mixing function, and so on. The cores within a chip are not
> always self-contained like this. To clarify let's say a system function is
> realized by programming core A, core B, and finally trigger core A to set
> the function in motion. This implies the need of coordination between the
> programming steps on those cores.
>
> Is my view on what is a device wrong? Does a platform device differ in
> this respect from a regular device?
Please don't use a platform device, unless there is no other way for
your device to work. For this device, you are connected to the PCI bus,
so a platform device does not make sense at all.
thanks,
greg k-h
W dniu 19 kwietnia 2011 15:58 użytkownik Arend van Spriel
<[email protected]> napisał:
> On Sun, 17 Apr 2011 19:38:12 +0200, Arnd Bergmann <[email protected]> wrote:
>
> Hi Rafał,
>
> As you probably expected I tried to integrate and use your bcmai/bcmaxi/?
> driver with our brcm80211 driver (making progress). In the mean time I tried
> to follow the discussions going on, but I am still catching up.
>
>> Compare this to the PCI bus type, which essentially deals with devices
>> that have a PCI configuration space that contains generic (irq, memory,
>> vendor/device ID, ...) registers along with device specific registers.
>
> How much alike is the (BCM)AXI bus type? My assumption was that each
> registered PCI device is handled by a single driver module. In the
> current(?) bcmai implementation each device driver is called with the
> appropriate device structure reference, but it will also have the bus
> structure reference and through that can also access other cores on the
> (bcm)axi bus. This seems to me a potential issue when there are no
> synchronization mechanisms in place (whether in a SoC configuration or
> PCI-hosted). Does the PCI bus type allow driver for device A access
> device B?
There are bus-specific infos that have to be available for drivers,
like board id, sprom, CC access. So bcmai(?) drivers have to have
access to bus struct.
One core driver should never touch other core, like 80211 touching ETH
or USB or anything. Exception is CC and maybe PCI(e).
I still have to make use of all windows to improve cores access.
>> A new bus_type really only makes sense if you expect a lot of devices
>> to use this and you want to have the probing in the bus. If you only
>> want to have a way to enumerate devices that get created by the
>> parent driver, you can also use platform devices.
>
> The main assumption of the (bcm)axi driver seems to be that each core can
> be considered as a device. Correct me if I am wrong, but I consider a
> device to be an entity providing a particular system function. So an
> ethernet device provides ethernet connectivity function, a mixer device
> provides sound mixing function, and so on. The cores within a chip are not
> always self-contained like this. To clarify let's say a system function is
> realized by programming core A, core B, and finally trigger core A to set
> the function in motion. This implies the need of coordination between the
> programming steps on those cores.
What cores may need to access each other? AFAIK so far we didn't meet
such a cores.
--
Rafał
On Tuesday 19 April 2011, Arend van Spriel wrote:
> > A new bus_type really only makes sense if you expect a lot of devices
> > to use this and you want to have the probing in the bus. If you only
> > want to have a way to enumerate devices that get created by the
> > parent driver, you can also use platform devices.
>
> The main assumption of the (bcm)axi driver seems to be that each core can
> be considered as a device. Correct me if I am wrong, but I consider a
> device to be an entity providing a particular system function. So an
> ethernet device provides ethernet connectivity function, a mixer device
> provides sound mixing function, and so on. The cores within a chip are not
> always self-contained like this. To clarify let's say a system function is
> realized by programming core A, core B, and finally trigger core A to set
> the function in motion. This implies the need of coordination between the
> programming steps on those cores.
>
> Is my view on what is a device wrong? Does a platform device differ in
> this respect from a regular device?
A platform device means something that cannot be probed, in every other
respect it is the same as other devices. From your explanation above,
it seems that you don't actually need to represent the cores on your
particular chips as struct device in Linux at all.
If you wanted to use platform_device, the right way would probably
be an MFD device that creates multiple child devices (which end
up as platform_device, though you don't need to worry about that)
from the PCI driver. Then you could use the child devices completely
independent from one another.
Since you say that the cores in this case are tightly coupled and
don't provide independent functionality to the system, there is
no need to represent them as devices.
Arnd
On Tue, 19 Apr 2011 16:02:57 +0200, Greg KH <[email protected]> wrote:
> Please don't use a platform device, unless there is no other way for
> your device to work. For this device, you are connected to the PCI bus,
> so a platform device does not make sense at all.
Hi Greg,
This is only true for a particular usage model. There are two models as
shown below:
1) PCI(e) card
...........
+----------+ : x y z : x, y, and z are cores.
| uC |__________:___|_|_| :
| | PCI-bus : axi-bus :
+----------+ :.........:
bcm chipset
2) SoC
...............
: uC x y z :
: |____|_|_| :
: axi-bus :
:.............:
bcm chipset
Your statement is true for 1) but in usage model 2) there is no PCI bus.
Also you refer to the chipset when you say 'device'. In the axi bus type
each individual core is registered as a device in the linux device tree.
Gr. AvS
--
"The world is indeed comic, but the joke is on mankind." — H.P. Lovecraft
On Wednesday 20 April 2011 08:39:59 Arend van Spriel wrote:
> On Tue, 19 Apr 2011 16:02:57 +0200, Greg KH <[email protected]> wrote:
>
> > Please don't use a platform device, unless there is no other way for
> > your device to work. For this device, you are connected to the PCI bus,
> > so a platform device does not make sense at all.
>
> Hi Greg,
>
> This is only true for a particular usage model. There are two models as
> shown below:
>
> 1) PCI(e) card
> ...........
> +----------+ : x y z : x, y, and z are cores.
> | uC |__________:___|_|_| :
> | | PCI-bus : axi-bus :
> +----------+ :.........:
> bcm chipset
>
> 2) SoC
> ...............
> : uC x y z :
> : |____|_|_| :
> : axi-bus :
> :.............:
> bcm chipset
>
> Your statement is true for 1) but in usage model 2) there is no PCI bus.
> Also you refer to the chipset when you say 'device'. In the axi bus type
> each individual core is registered as a device in the linux device tree.
I guess what Greg was referring to is having platform devices for x/y/z
here. In case 2, you might still need to have a platform_device for the
combination of the three IP cores if they make up one logical device.
As mentioned in my reply, it depends a lot on what these cores actually
are, e.g. whether you might want to have only one of them active in a
given system to drive a specific functionality, or if you always need
all three of them.
Arnd
On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann <[email protected]> wrote:
> On Tuesday 19 April 2011, Arend van Spriel wrote:
>
>> > A new bus_type really only makes sense if you expect a lot of devices
>> > to use this and you want to have the probing in the bus. If you only
>> > want to have a way to enumerate devices that get created by the
>> > parent driver, you can also use platform devices.
>>
>> The main assumption of the (bcm)axi driver seems to be that each core
>> can
>> be considered as a device. Correct me if I am wrong, but I consider a
>> device to be an entity providing a particular system function. So an
>> ethernet device provides ethernet connectivity function, a mixer device
>> provides sound mixing function, and so on. The cores within a chip are
>> not
>> always self-contained like this. To clarify let's say a system function
>> is
>> realized by programming core A, core B, and finally trigger core A to
>> set
>> the function in motion. This implies the need of coordination between
>> the
>> programming steps on those cores.
>>
>> Is my view on what is a device wrong? Does a platform device differ in
>> this respect from a regular device?
>
> A platform device means something that cannot be probed, in every other
> respect it is the same as other devices. From your explanation above,
> it seems that you don't actually need to represent the cores on your
> particular chips as struct device in Linux at all.
>
> If you wanted to use platform_device, the right way would probably
> be an MFD device that creates multiple child devices (which end
> up as platform_device, though you don't need to worry about that)
> from the PCI driver. Then you could use the child devices completely
> independent from one another.
>
> Since you say that the cores in this case are tightly coupled and
> don't provide independent functionality to the system, there is
> no need to represent them as devices.
Hi Arnd,
The case is a hypothetical one, but I consider it a likely one. The axi
bus driver currently registers each detected core as a device in the linux
device tree. My statement is that this implies loose or no coupling
between those cores, which is not true. One (or two) exceptions have
already been identified. I would expect your last line to read: ...to the
system, those cores should not be represented as devices.
Gr. AvS
--
"The world is indeed comic, but the joke is on mankind." — H.P. Lovecraft
On Wednesday 20 April 2011 09:16:26 Arend van Spriel wrote:
> >
> > A platform device means something that cannot be probed, in every other
> > respect it is the same as other devices. From your explanation above,
> > it seems that you don't actually need to represent the cores on your
> > particular chips as struct device in Linux at all.
> >
> > If you wanted to use platform_device, the right way would probably
> > be an MFD device that creates multiple child devices (which end
> > up as platform_device, though you don't need to worry about that)
> > from the PCI driver. Then you could use the child devices completely
> > independent from one another.
> >
> > Since you say that the cores in this case are tightly coupled and
> > don't provide independent functionality to the system, there is
> > no need to represent them as devices.
>
> The case is a hypothetical one, but I consider it a likely one. The axi
> bus driver currently registers each detected core as a device in the linux
> device tree. My statement is that this implies loose or no coupling
> between those cores, which is not true. One (or two) exceptions have
> already been identified. I would expect your last line to read: ...to the
> system, those cores should not be represented as devices.
The important question is what is most practical here. If most of the
cores of this type are standalone devices, it's probably best to represent
all of them as separate devices, and find ways to deal with the few logical
devices that are spread across multiple cores.
It it's the exception and you typically have a significant number of IP
blocks that need to be combined to make a single logical device, I would
recommend not representing each of them as a struct device.
We really need to figure out first what the requirements are given the
hardware you want to support with this.
Arnd
2011/4/20 Arend van Spriel <[email protected]>:
> On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann <[email protected]> wrote:
>
>> On Tuesday 19 April 2011, Arend van Spriel wrote:
>>
>>> > A new bus_type really only makes sense if you expect a lot of devices
>>> > to use this and you want to have the probing in the bus. If you only
>>> > want to have a way to enumerate devices that get created by the
>>> > parent driver, you can also use platform devices.
>>>
>>> The main assumption of the (bcm)axi driver seems to be that each core can
>>> be considered as a device. Correct me if I am wrong, but I consider a
>>> device to be an entity providing a particular system function. So an
>>> ethernet device provides ethernet connectivity function, a mixer device
>>> provides sound mixing function, and so on. The cores within a chip are
>>> not
>>> always self-contained like this. To clarify let's say a system function
>>> is
>>> realized by programming core A, core B, and finally trigger core A to set
>>> the function in motion. This implies the need of coordination between the
>>> programming steps on those cores.
>>>
>>> Is my view on what is a device wrong? Does a platform device differ in
>>> this respect from a regular device?
>>
>> A platform device means something that cannot be probed, in every other
>> respect it is the same as other devices. From your explanation above,
>> it seems that you don't actually need to represent the cores on your
>> particular chips as struct device in Linux at all.
>>
>> If you wanted to use platform_device, the right way would probably
>> be an MFD device that creates multiple child devices (which end
>> up as platform_device, though you don't need to worry about that)
>> from the PCI driver. Then you could use the child devices completely
>> independent from one another.
>>
>> Since you say that the cores in this case are tightly coupled and
>> don't provide independent functionality to the system, there is
>> no need to represent them as devices.
>
> Hi Arnd,
>
> The case is a hypothetical one, but I consider it a likely one. The axi bus
> driver currently registers each detected core as a device in the linux
> device tree. My statement is that this implies loose or no coupling between
> those cores, which is not true. One (or two) exceptions have already been
> identified. I would expect your last line to read: ...to the system, those
> cores should not be represented as devices.
I do not register that exceptional devices in my code.
--
Rafał
On Wed, 20 Apr 2011 09:26:08 +0200, Arnd Bergmann <[email protected]> wrote:
> On Wednesday 20 April 2011 09:16:26 Arend van Spriel wrote:
>> >
>> > A platform device means something that cannot be probed, in every
>> other
>> > respect it is the same as other devices. From your explanation above,
>> > it seems that you don't actually need to represent the cores on your
>> > particular chips as struct device in Linux at all.
>> >
>> > If you wanted to use platform_device, the right way would probably
>> > be an MFD device that creates multiple child devices (which end
>> > up as platform_device, though you don't need to worry about that)
>> > from the PCI driver. Then you could use the child devices completely
>> > independent from one another.
>> >
>> > Since you say that the cores in this case are tightly coupled and
>> > don't provide independent functionality to the system, there is
>> > no need to represent them as devices.
>>
>> The case is a hypothetical one, but I consider it a likely one. The axi
>> bus driver currently registers each detected core as a device in the
>> linux
>> device tree. My statement is that this implies loose or no coupling
>> between those cores, which is not true. One (or two) exceptions have
>> already been identified. I would expect your last line to read: ...to
>> the
>> system, those cores should not be represented as devices.
>
> The important question is what is most practical here. If most of the
> cores of this type are standalone devices, it's probably best to
> represent
> all of them as separate devices, and find ways to deal with the few
> logical
> devices that are spread across multiple cores.
> It it's the exception and you typically have a significant number of IP
> blocks that need to be combined to make a single logical device, I would
> recommend not representing each of them as a struct device.
>
> We really need to figure out first what the requirements are given the
> hardware you want to support with this.
Very true. I have forwarded this email conversation to a colleague of mine
to see whether my hypothesis is likely or rarely true at least for
Broadcom chipsets. As we concluded that Broadcom seems to be the only one
currently using this bus that input may be sufficient to determine the
requirements.
Gr. AvS
--
"The world is indeed comic, but the joke is on mankind." — H.P. Lovecraft
On 04/20/2011 09:29 AM, Rafał Miłecki wrote:
> I do not register that exceptional devices in my code.
Hi Rafał,
There has been some radio silence on the subject of the (bcm)axi driver.
I was getting a feeling that my concerns were almost all out of the way
in latest emails I got from Arnd and/or Jonas. Do you have an update of
what plans you have with this module.
Gr. AvS
W dniu 5 maja 2011 14:33 użytkownik Arend van Spriel
<[email protected]> napisał:
> On 04/20/2011 09:29 AM, Rafał Miłecki wrote:
>>
>> I do not register that exceptional devices in my code.
>
> Hi Rafał,
>
> There has been some radio silence on the subject of the (bcm)axi driver. I
> was getting a feeling that my concerns were almost all out of the way in
> latest emails I got from Arnd and/or Jonas. Do you have an update of what
> plans you have with this module.
Hey,
I got some unique possibility to work on machine affected by DMA
errors and I spent last 2 weeks only on solving this issue. I'm going
to go back to AMBA topic again soo.
--
Rafał
On 05/05/2011 02:48 PM, Rafał Miłecki wrote:
>
> Hey,
>
> I got some unique possibility to work on machine affected by DMA
> errors and I spent last 2 weeks only on solving this issue. I'm going
> to go back to AMBA topic again soo.
Great,
I was spending some time on other stuff as well. I will be picking up
integrating the module in our brcm80211 driver to get a feel how it fits.
Gr. AvS