Hello Sergei On Tue, 7 Dec 2010, Sergei Shtylyov wrote:
> On 06-12-2010 20:54, Tony Lindgren wrote: > > > > > > As the control.h have been moved to new location and it's > > > > > > uses are not allowed to drivers directly so moving the phy > > > > > > control, interrupt clear and reset functionality to board > > > > > > files. > > > > > > I'm not fond of the whole approach. I'm not sure why accesses to > > > > > the > > > > > control registers are such a no-no, taking into account that one needs > > > > > to > > > > > access such regisyter to clear the interrupt... > > > Because drivers should arch independent and any tinkering of the > > platform level registers will lead into pains later on that > > I end up having to deal with. > > > To me it seem you just init to separate out the transceiver, > > right? > > We also have to install a hook to clear the MUSB level interrupt via the > control register -- that's a thing that makes me dubious about not allowing > drivers to access the control registers. That's only true for the AM35xx "IP subsystem" devices. It's not true for any other device on that chip. It is just due to the fact that the AM35xx hardware designers chose not to follow the standard OMAP3430 hardware design practice. (Actually this standard practice goes back even further, at least to the OMAP2420 days.) The OMAP2430/34xx/36xx adaptation layer for musb doesn't have to do these nasty SCM accesses. As far as I know, every other device on the AM35xx outside the "IP subsystem" places its interrupt status registers in the same IP subsystem as the device that raises the interrupt. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
