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?

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

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

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

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

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

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

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

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

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

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