On 03/18/2011 11:25 AM, RafaÅ MiÅecki wrote:
2011/3/18 George Kashperko<george@xxxxxxxxxxx>:
2011/3/18 RafaÅ MiÅecki<zajec5@xxxxxxxxx>:
What for example about pci.c? Which functions from that file won't be
duplicated in totally separated?
At first I though we will need to duplicate all pci routines like
ssb_pci_switch_coreidx and ssb_pci_xtal. But now I've checked
brcm80211 and it seems it reads SPROM even from AI bus-cards.
Btw ssb_pci_xtal is for PCI. PCIE hosts don't need this.
Not even all PCI devices. Just 4306 I believe:
/* kludge to enable the clock on the 4306 which lacks a slowclock */
if (bustype == PCI_BUS&& !si_ispcie(sii))
si_clkctl_xtal(&sii->pub, XTAL | PLL, ON);
Do you really want to duplicate all the SPROM code in *totally
separated* driver for AI?!
Every sb/ai backplane known to me at the moment are featuring the
following hardware design:
System backplane with individual devices on it (called cores)
communicating with the means of agents. The agents for sb are in the
main core registers space, and apart from the core registers for axi.
The backplane itself is "mastered" by buscore device. This is mips core
for embeddables, pci(e) core for pci(e) hosted backplanes, pcmcia core
for backplanes on pcmcia/sdio. Might OCP core is some sort of buscore as
well used to bridge two sb backplanes.
Buscore is responsible for interrupts management, backplane-to-host-bus
operations, agent-to-agent transfers.
Apart from the buscore, there is another "special" device on the
backplane - buscommon. Unlike buscore this one seems to be optional, and
not present on some old pcmcia-hosted backplanes. The buscommon is
responsible for managing bus clocks, can serve uarts, also is a source
of misc. configuration information for the backplane. These buscommons
are chipcommon and extif cores.
Here it would be great to have more technical background on the subject
but unfortunately apart from the staging brcm80211 and GPL packages for
respective embeddables the only open doc on the subject available to me
is www.broadcom.com/collateral/pg/440X-PG02-R.pdf
Well, OK, it's generally well known already. Maybe I just prefer to
call "buscore" a "hostcore" and "buscommon" a "chipcommon". I believe
that are the names we hot used to.
So software model I see here looks like following:
* Backplane-type handler responsible for
~ initial scanning;
~ agent-specific operations (core enable/disable, irq flags management,
etc.);
* The bus driver itself responsible for initial detection and assignment
of backplane handler and also managig driver registration/binding/etc
for
~ buscommon;
~ buscore;
~ regular cores;
* Host driver managing:
~ requests to the physical address space of backplane;
~ host interrupt management;
~ host-specific workarounds (ssb_pci_xtal is one of them);
This requires generic interfaces for:
* host (like those ssb_bus_ops which are actually not bus but host ops -
handling not core accesses but physical backplane addresses requests;
iterrupt management ops);
* backplane (scan, enable, disable, irq_flag etc.);
* buscore (backplane irq/errors/etc. management);
* buscommon (backplane clocks/etc. management, capabilities queries);
Buscommon and buscore unlike current ssb model could be separate
drivers. This will help to break apart all that mess of versions
checking and revision-specific processing. This will provide clean way
of obsoleting and removing the support for old hardware and introducing
newer one.
Regular bus core devices thus are to be registered with linux once
buscommon, buscore and host drivers are bound and set up making the bus
operational.
Buscore and buscommon as separate drivers will require some code to be
replicated over close versions but overall I've already tested this
approach with chipcommons with pmu r0, r1 and r5 on pcie and mips hosts
and final drivers' code is clean and manageable unlike all that mess in
hndpmu.c
Same stands for mips/pci host cores.
OK, I generally agree. We can try moving to such a layout. The only
thing I hate in your view is "obsoleting and removing the support for
old hardware".
I also do not like the thought of removing support of old hardware. Given the
lack of support from some vendors, Linux may be somewhat slow in providing
drivers for new devices; however, we can and should keep the support for legacy
devices. I built a sandbox computer just for testing a BCM4306/3 that uses b43
and a BCM4303 using b43legacy.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
