Hello,
I am currently looking into adding support for the newer Broadcom
BCM47xx/53xx SoCs. They require having HND/AI support, which probably
means merging the current SSB code and the HND/AI code from the
brcm80211 driver. Is anyone already working on this?
As far as I can see, there are two possibilities:
a) Merge the HND/AI code into the current SSB code, or
b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
The former is probably the less intrusive one, but requires a bit of
ssb-named-but-actually-not-ssb code unless one renames several
functions and structs.
The latter has the advantage of having a certain bus abstraction
already built-in, but would require adapting the b43 code to it. It
also looks like it doesn't support (very) old SoCs.
Regards,
Jonas
P.S: The Maintainers file says SSB's list is netdev, but I would have
expected it to be linux-wireless. Is this still correct?
On Mon, Jan 17, 2011 at 14:43, Jonas Gorski <[email protected]> wrote:
> On 17 January 2011 12:57, Michael Büsch <[email protected]> wrote:
>> Well... I don't really like the idea of running one driver and
>> subsystem implementation on completely distinct types of silicon.
>> We will end up with the same mess that broadcom ended up with in
>> their "SB" code (broadcom's SSB backplane implementation).
>> For example, in their code the driver calls pci_enable_device() and
>> related PCI functions, even if there is no PCI device at all. The calls
>> are magically re-routed to the actual SB backplane.
>> You'd have to do the same mess with SSB. Calling ssb_device_enable()
>> will mean "enable the SSB device", if the backplane is SSB, and will
>> mean "enable the HND/AI" device, if the backplane is HND/AI.
> P.S: Any suggestions for the name? Would be "ai" okay? Technically
> it's "AMBA Interconnect", but "amba" is already taken.
If it's AMBA, can it be integrated with the existing code in drivers/amba/?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, 2011-01-17 at 12:20 +0100, Florian Fainelli wrote:
> On Monday 17 January 2011 11:56:23 Michael Büsch wrote:
> > On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> > > Hello,
> > >
> > > I am currently looking into adding support for the newer Broadcom
> > > BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> > > means merging the current SSB code and the HND/AI code from the
> > > brcm80211 driver. Is anyone already working on this?
> > >
> > > As far as I can see, there are two possibilities:
> > >
> > > a) Merge the HND/AI code into the current SSB code, or
> > >
> > > b) add the missing code for SoCs to brcm80211 and replace the SSB code
> > > with it.
> >
> > Why can't we keep those two platforms separated?
>
> That is also what I am wondering about. Considering that previous BCM47xx
> platforms use a MIPS4k core and newer one use MIPS74k or later, you would not
> be able to build a single kernel for both which takes advantages of compile-
> time optimizations targetting MIPS74k. If this ist not a big concern, then
> let's target a single kernel.
Ok, but it should be easily possible to compile both SSB and HND/AI
bus support into one kernel anyway. Nothing prevents drivers from having
an SSB and an HND/AI probe callback.
--
Greetings Michael.
On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> Hello,
>
> I am currently looking into adding support for the newer Broadcom
> BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> means merging the current SSB code and the HND/AI code from the
> brcm80211 driver. Is anyone already working on this?
>
> As far as I can see, there are two possibilities:
>
> a) Merge the HND/AI code into the current SSB code, or
>
> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
Why can't we keep those two platforms separated?
Is there really a lot of shared code between SSB and HND/AI?
It's true that there's currently a lot of device functionality built
into ssb. Like pci bridge, mips core, extif, etc...
If you take all that code out, you're probably not left with anything.
So why do we need to replace or merge SSB in the first place? Can't
it co-exist with HND/AI?
--
Greetings Michael.
On Mon, 2011-01-17 at 12:13 +0100, Johannes Berg wrote:
> On Mon, 2011-01-17 at 11:56 +0100, Michael Büsch wrote:
>
> > > As far as I can see, there are two possibilities:
> > >
> > > a) Merge the HND/AI code into the current SSB code, or
> > >
> > > b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
> >
> > Why can't we keep those two platforms separated?
> > Is there really a lot of shared code between SSB and HND/AI?
>
> I don't think there's a lot of shared code, but I believe that you need
> b43 to be able to target cores on both? And b43 currently uses the SSB
> APIs only.
Yeah right. That's what I was thinking about, too. Just leave SSB alone
and add bus glues to b43 for HND/AI. There's almost no SSB specific code
in b43. So it should be easily possible to add another probe entry from
the (to be written or derived from brcm80211) HND/AI subsystem.
--
Greetings Michael.
On 17 January 2011 14:54, Geert Uytterhoeven <[email protected]> wrote:
> If it's AMBA, can it be integrated with the existing code in drivers/amba/?
Hm, I once had a sentence about it there, I must have accidentally deleted it.
I tried finding similarities between Broadcom's code and ARM's AMBA
specification to better understand the code, but except some tiny ones
I couldn't find anything usable. Unfortunately I couldn't find
anything about Broadcom's AMBA implementation, except that it's "AMBA"
licensed from ARM.
Jonas
On 17 January 2011 11:56, Michael Büsch <[email protected]> wrote:
> On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
>> a) Merge the HND/AI code into the current SSB code, or
>>
>> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
>
> Why can't we keep those two platforms separated?
> Is there really a lot of shared code between SSB and HND/AI?
Yes, as far as I understand the AI bus behaves mostly like a SSB bus
except for places like enabling/disabling cores. E.g. the AI bus also
has a common core, which has a bit for telling whether its a SSB or AI
bus, and has the mostly the same registers as the SSB common cores (so
most driver_chipcommon_* stuff also applies for the AI bus).
> It's true that there's currently a lot of device functionality built
> into ssb. Like pci bridge, mips core, extif, etc...
> If you take all that code out, you're probably not left with anything.
That's because most shared code isn't in brcm80211, but only found in
the SDKs for the SoCs.
> So why do we need to replace or merge SSB in the first place? Can't
> it co-exist with HND/AI?
It probably can, but then the SSB code must be at least made AI aware
so it doesn't try to attach itself if it finds one. Also I don't know
if it is a good idea to let arch-specific code depend on code in
staging.
Jonas
On Mon, 2011-01-17 at 11:56 +0100, Michael Büsch wrote:
> > As far as I can see, there are two possibilities:
> >
> > a) Merge the HND/AI code into the current SSB code, or
> >
> > b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
>
> Why can't we keep those two platforms separated?
> Is there really a lot of shared code between SSB and HND/AI?
I don't think there's a lot of shared code, but I believe that you need
b43 to be able to target cores on both? And b43 currently uses the SSB
APIs only.
johannes
On Mon, 2011-01-17 at 12:21 +0100, Jonas Gorski wrote:
> On 17 January 2011 11:56, Michael Büsch <[email protected]> wrote:
> > On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> >> a) Merge the HND/AI code into the current SSB code, or
> >>
> >> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
> >
> > Why can't we keep those two platforms separated?
> > Is there really a lot of shared code between SSB and HND/AI?
>
> Yes, as far as I understand the AI bus behaves mostly like a SSB bus
> except for places like enabling/disabling cores. E.g. the AI bus also
> has a common core, which has a bit for telling whether its a SSB or AI
> bus, and has the mostly the same registers as the SSB common cores (so
> most driver_chipcommon_* stuff also applies for the AI bus).
Well... I don't really like the idea of running one driver and
subsystem implementation on completely distinct types of silicon.
We will end up with the same mess that broadcom ended up with in
their "SB" code (broadcom's SSB backplane implementation).
For example, in their code the driver calls pci_enable_device() and
related PCI functions, even if there is no PCI device at all. The calls
are magically re-routed to the actual SB backplane.
You'd have to do the same mess with SSB. Calling ssb_device_enable()
will mean "enable the SSB device", if the backplane is SSB, and will
mean "enable the HND/AI" device, if the backplane is HND/AI.
So I'm still in favor of doing a separate HND/AI bus implementation,
even if
that means duplicating a few lines of code. I think that compared to the
workarounds and conditionals needed for getting SSB to run on HND/AI
hardware, it will be a net win.
> > So why do we need to replace or merge SSB in the first place? Can't
> > it co-exist with HND/AI?
>
> It probably can, but then the SSB code must be at least made AI aware
> so it doesn't try to attach itself if it finds one.
SSB doesn't search for SSB busses in the system, because there's no
way to do so. The architecture (or the PCI/PCMCIA/SDIO device) registers
the bus,
if it detected an SSB device. So for the embedded case, it's hardcoded
in the arch code. For the PCI case it simply depends on the PCI IDs.
I don't see a problem here. Your arch code will already have to know
what machine it is running on. So it will have to decide whether to
register a SSB or HND/AI bus.
It's like a platform_device. However, it doesn't use the platform_device
mechanism. There's no technical reason. It would be trivial to port the
SSB bus registration to use platform_device, however.
> Also I don't know
> if it is a good idea to let arch-specific code depend on code in
> staging.
Sure. The code needs to be cleaned up and moved to the mainline kernel
_anyway_. You don't get around this.
--
Greetings Michael.
On Monday 17 January 2011 11:56:23 Michael Büsch wrote:
> On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> > Hello,
> >
> > I am currently looking into adding support for the newer Broadcom
> > BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> > means merging the current SSB code and the HND/AI code from the
> > brcm80211 driver. Is anyone already working on this?
> >
> > As far as I can see, there are two possibilities:
> >
> > a) Merge the HND/AI code into the current SSB code, or
> >
> > b) add the missing code for SoCs to brcm80211 and replace the SSB code
> > with it.
>
> Why can't we keep those two platforms separated?
That is also what I am wondering about. Considering that previous BCM47xx
platforms use a MIPS4k core and newer one use MIPS74k or later, you would not
be able to build a single kernel for both which takes advantages of compile-
time optimizations targetting MIPS74k. If this ist not a big concern, then
let's target a single kernel.
> Is there really a lot of shared code between SSB and HND/AI?
>
> It's true that there's currently a lot of device functionality built
> into ssb. Like pci bridge, mips core, extif, etc...
> If you take all that code out, you're probably not left with anything.
>
> So why do we need to replace or merge SSB in the first place? Can't
> it co-exist with HND/AI?
On 17 January 2011 12:57, Michael Büsch <[email protected]> wrote:
> Well... I don't really like the idea of running one driver and
> subsystem implementation on completely distinct types of silicon.
> We will end up with the same mess that broadcom ended up with in
> their "SB" code (broadcom's SSB backplane implementation).
> For example, in their code the driver calls pci_enable_device() and
> related PCI functions, even if there is no PCI device at all. The calls
> are magically re-routed to the actual SB backplane.
> You'd have to do the same mess with SSB. Calling ssb_device_enable()
> will mean "enable the SSB device", if the backplane is SSB, and will
> mean "enable the HND/AI" device, if the backplane is HND/AI.
It didn't strike me as that bad, but I also didn't look at any PCI code.
> So I'm still in favor of doing a separate HND/AI bus implementation,
> even if
> that means duplicating a few lines of code.
Well, it means at least duplicating most of the chipcommon driver and
the mips core driver. But if you are fine with that, I see no problem
with having a separate driver for the AI bus.
> SSB doesn't search for SSB busses in the system, because there's no
> way to do so. The architecture (or the PCI/PCMCIA/SDIO device) registers
> the bus,
> if it detected an SSB device. So for the embedded case, it's hardcoded
> in the arch code. For the PCI case it simply depends on the PCI IDs.
> I don't see a problem here. Your arch code will already have to know
> what machine it is running on. So it will have to decide whether to
> register a SSB or HND/AI bus.
Okay. This is mostly for the embedded case, where it is possible to
create a single kernel that boots on both. The "detection" could also
be done through the cpu type (74k => register AI bus, else SSB bus)
instead of the chipid register of the common core.
>> Also I don't know
>> if it is a good idea to let arch-specific code depend on code in
>> staging.
>
> Sure. The code needs to be cleaned up and moved to the mainline kernel
> _anyway_. You don't get around this.
Yes, you are right.
So I guess the proposed course of action would be:
1. Make the HND/AI-Bus code from brcm80211 its own independent driver,
2. Re-add the non-wifi related code (chipcommon, mips, etc),
3. Clean up the code until it meets Linux' code style/quality,
4. Move it out of staging,
and finally
5. Add the required arch specific code to bcm47xx for the newer SoCs.
Jonas
P.S: Any suggestions for the name? Would be "ai" okay? Technically
it's "AMBA Interconnect", but "amba" is already taken.