Re: Merging SSB and HND/AI support

On Mon, 2011-01-17 at 12:21 +0100, Jonas Gorski wrote: 

On 17 January 2011 11:56, Michael Büsch [off-list ref] wrote:

quoted

On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:

quoted

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.

quoted

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On 17 January 2011 12:57, Michael Büsch [off-list ref] 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.

quoted

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.