[PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

Hello.

On 03/20/2014 02:50 PM, Arnd Bergmann wrote:

quoted

quoted

quoted

quoted

The question is whether there is anyone who would do this properly.

quoted

quoted

quoted

     Nobody cares, it seems. As you can imagine, I stopped to care enough after
being switched to other projects.

quoted

quoted

I only care about it because I have the intention to get all 'randconfig'
kernels to build eventually. For stuff that is definitely 'legacy'
and won't get cleaned up properly, I'm fine with a hack.

quoted

quoted

quoted

quoted

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

quoted

quoted

quoted

     The idea at the time was to just ioremap() this register but I was not
very eager.

quoted

quoted

Yes, that would work, too. However, that would cause problems later
if we ever try to make the davinci platform "multiplatform", unless we also
pass the physical address in a platform resource and make this a larger

quoted

Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver
access to syscfg registers too and I just asked him to pass the physical
addresses using platform resource. I think thats the best bet we have in
the absence of a modern interface.

Ok.

    Depends on what SYSCFG register it uses. It wouldn't be good if that 
register range includes CFGCHIP2.

quoted

quoted

The syscon (system controller) framework helps share a set of registers
across multiple drivers. If all accesses to the CFGCHIP2 register are
in a single PHY driver, we wouldn't need it.

quoted

CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not
sure if there can be a single PHY driver for both.

The phy infrastructure explicitly supports multiple consumers for one
phy, if I'm reading the code correctly.

    Yes, it does. The issue is that the PHY code is different in MUSB and OHCI 
drivers. I don't think the PHY driver knows what device binds to it.

	Arnd

WBR, Sergei