Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> 
> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 14 kwietnia 2011 13:43 u?ytkownik George Kashperko
<george@znau.edu.ua> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Hauke Mehrtens]

On 04/14/2011 02:04 PM, Rafa? Mi?ecki wrote:
> W dniu 14 kwietnia 2011 13:43 u?ytkownik George Kashperko
> <george@znau.edu.ua> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 14 kwietnia 2011 14:34 u?ytkownik Hauke Mehrtens
<hauke@hauke-m.de> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> W dniu 14 kwietnia 2011 14:34 u?ytkownik Hauke Mehrtens
> <hauke@hauke-m.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 14 kwietnia 2011 15:15 u?ytkownik George Kashperko
<george@znau.edu.ua> napisa?:
>
>> W dniu 14 kwietnia 2011 14:34 u?ytkownik Hauke Mehrtens
>> <hauke@hauke-m.de> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> >> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 15 kwietnia 2011 20:36 u?ytkownik George Kashperko
<george@znau.edu.ua> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> W dniu 15 kwietnia 2011 20:36 u?ytkownik George Kashperko
> <george@znau.edu.ua> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 15 kwietnia 2011 21:42 u?ytkownik George Kashperko
<george@znau.edu.ua> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Peter Stuge]

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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

2011/4/15 Peter Stuge <peter@stuge.se>:
> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Jonas Gorski]

On 16 April 2011 16:00, Rafa? Mi?ecki <zajec5@gmail.com> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> W dniu 15 kwietnia 2011 20:36 u?ytkownik George Kashperko
> <george@znau.edu.ua> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arnd Bergmann]

On Friday 15 April 2011, Rafa? Mi?ecki wrote:
> W dniu 15 kwietnia 2011 20:36 u?ytkownik George Kashperko
> <george@znau.edu.ua> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 17 kwietnia 2011 19:38 u?ytkownik Arnd Bergmann <arnd@arndb.de> napisa?:
> On Friday 15 April 2011, Rafa? Mi?ecki wrote:
>> W dniu 15 kwietnia 2011 20:36 u?ytkownik George Kashperko
>> <george@znau.edu.ua> 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.

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arnd Bergmann]

On Monday 18 April 2011, Rafa? Mi?ecki wrote:
> W dniu 17 kwietnia 2011 19:38 u?ytkownik Arnd Bergmann <arnd@arndb.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 18 kwietnia 2011 16:19 u?ytkownik Arnd Bergmann <arnd@arndb.de> napisa?:
> On Monday 18 April 2011, Rafa? Mi?ecki wrote:
>> W dniu 17 kwietnia 2011 19:38 u?ytkownik Arnd Bergmann <arnd@arndb.de> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> >
> > 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 18 kwietnia 2011 17:35 u?ytkownik George Kashperko
<george@znau.edu.ua> 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?
-------------- next part --------------
0x4BF80001	TAG==CI		CID==0x800
0x22004211	TAG==CI		PORTS==1+1	WRAPPERS==1+0
0x00000003	TAG==MST_PORT
0x18000005	TAG==ADDR	ST==SLV_PORT	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0
0x181000C5	TAG==ADDR	ST==MST_WRAP	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0

0x4BF81201	TAG==CI		CID==0x812
0x17004211	TAG==CI		PORTS==1+1	WRAPPERS==1+0
0x00000103	TAG==MST_PORT
0x18001005	TAG==ADDR	ST==SLV_PORT	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0
0x181010C5	TAG==ADDR	ST==MST_WRAP	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0

0x4BF82001	TAG==CI		CID==0x820
0x0F084411	TAG==CI		PORTS==1+2	WRAPPERS==1+1
0x00000203	TAG==MST_PORT
0x18002005	TAG==ADDR	ST==SLV_PORT	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0
0x08000135	TAG==ADDR	ST==SLV_PORT	ADDRL==...	PORT==1		AD_AG32==0	AD_SZ_MASK==0x30==SZD
0x08000000					SIZEL==...			SD_SG32==0
0x0000013D	TAG==ADDR	ST==SLV_PORT	ADDRL==...	PORT==1		AD_AG32==8	AD_SZ_MASK==0x30==SZD
0x80000000					ADDRH==...
0x00000008					SIZEL==...			SD_SG32==8
0x80000000					SIZEH==...
0x181020C5	TAG==ADDR	ST==MST_WRAP	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0
0x18103185	TAG==ADDR	ST==SLV_WRAP	ADDRL==...	PORT==1		AD_AG32==0	AD_SZ_MASK==0

0x43B13501	TAG==CI		CID==0x135
0x00080201	TAG==CI		PORTS==0+1	WRAPPERS==0+1
0x18000065	TAG==ADDR	ST==BRIDGE	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0x60
0x18104085	TAG==ADDR	ST==SLV_WRAP	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0

0x43B13501	TAG==CI		CID==0x135
0x00080201	TAG==CI		PORTS==0+1	WRAPPERS==0+1
0x18100075	TAG==ADDR	ST==BRIDGE	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0x30==SZD
0x00009000					SIZEL=...
0x18105085	TAG==ADDR	ST==SLV_WRAP	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0

0x43B36701	TAG==CI		CID==0x367 (note: OOB_ROUTER, we do not care about lack of wrappers)
0x00000201	TAG==CI		PORTS==0+1	WRAPPERS==0+0
0x18106005	TAG==ADDR	ST==SLV_PORT	ADDRL==...	PORT==0		AD_AG32==0	AD_SZ_MASK==0

0x43B36601	TAG==CI		CID==0x366
0x00000201	TAG==CI		PORTS==0+1	WRAPPERS==0+0
0x18107005	(...) ? NO WRAPPERS

0x43B30101	TAG==CI		CID==0x301
0x00000201	TAG==CI		PORTS==0+1	WRAPPERS==0+0
0x18003005	(...) ? NO WRAPPERS

0x43BFFF01	TAG==CI		CID==0xFFF
0x00080201	TAG==CI		PORTS==0+1	WRAPPERS==0+1
0x00000035	(...) ? MANUF_ARM && DEF_AI_COMP
0x08000000	(...) ? MANUF_ARM && DEF_AI_COMP
0x10000035	(...) ? MANUF_ARM && DEF_AI_COMP
0x08000000	(...) ? MANUF_ARM && DEF_AI_COMP
0x18004035	(...) ? MANUF_ARM && DEF_AI_COMP
0x000FC000	(...) ? MANUF_ARM && DEF_AI_COMP
0x18109035	(...) ? MANUF_ARM && DEF_AI_COMP
0xE7EF7008	(...) ? MANUF_ARM && DEF_AI_COMP
0x7FFFFFFF	(...) ? MANUF_ARM && DEF_AI_COMP
0x18108085	(...) ? MANUF_ARM && DEF_AI_COMP

0x0000000F	TAG==END

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> W dniu 18 kwietnia 2011 17:35 u?ytkownik George Kashperko
> <george@znau.edu.ua> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arnd Bergmann]

On Monday 18 April 2011, Rafa? Mi?ecki wrote:
> W dniu 18 kwietnia 2011 16:19 u?ytkownik Arnd Bergmann <arnd@arndb.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arend van Spriel]

On Sun, 17 Apr 2011 19:38:12 +0200, Arnd Bergmann <arnd@arndb.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Greg KH]

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 <arnd@arndb.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arend van Spriel]

On Tue, 19 Apr 2011 16:02:57 +0200, Greg KH <greg@kroah.com> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arnd Bergmann]

On Wednesday 20 April 2011 08:39:59 Arend van Spriel wrote:
> On Tue, 19 Apr 2011 16:02:57 +0200, Greg KH <greg@kroah.com> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 19 kwietnia 2011 15:58 u?ytkownik Arend van Spriel
<arend@broadcom.com> napisa?:
> On Sun, 17 Apr 2011 19:38:12 +0200, Arnd Bergmann <arnd@arndb.de> 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?

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arnd Bergmann]

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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arend van Spriel]

On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann <arnd@arndb.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arnd Bergmann]

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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arend van Spriel]

On Wed, 20 Apr 2011 09:26:08 +0200, Arnd Bergmann <arnd@arndb.de> 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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

2011/4/20 Arend van Spriel <arend@broadcom.com>:
> On Tue, 19 Apr 2011 16:35:40 +0200, Arnd Bergmann <arnd@arndb.de> 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?

AXI driver status => previously: Re: Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arend van Spriel]

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

AXI driver status => previously: Re: Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Rafał Miłecki]

W dniu 5 maja 2011 14:33 u?ytkownik Arend van Spriel
<arend@broadcom.com> 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?

AXI driver status => previously: Re: Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[Arend van Spriel]

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

Could I (ab)use bus (struct bus_type) for virtual Broadcom bus?

[George Kashperko]

> W dniu 14 kwietnia 2011 13:43 u?ytkownik George Kashperko
> <george@znau.edu.ua> 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