> 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. > > 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 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. Well, keep in mind its my own view on the things how they are to be done right :) Have nice day, George -- 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
