Search Linux Wireless

Re: [RFC][PATCH] ssb: separate common scanning functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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".

Answer me this question, please:
Why do you think my proposed patch conflicts with layout proposed by you?

You said you want to have "Backplane-type handler". So according to
this we will need two drivers/handlers: 1 for scanning SSB and 1 for
scanning AI. That's what I try to implement. I just want to share some
functions between the one for SSB and the one for AI.

I don't see the point where my patch is in conflict with your idea.

-- 
RafaÅ
--
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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux