Felipe Balbi wrote: > Hi, > > On Fri, Aug 20, 2010 at 07:47:07AM +0200, ext Gadiyar, Anand wrote: > >The differences between OMAP3 and OMAP4 are: > >- The OMAP4 has a different set of clocks which do not exist on OMAP3. > >- The register bits for configuring port modes is different > > is it a different ip core or just a modification of the previous ? > > >For the clock handling: > >One approach: On OMAP3, have a set of dummy clocks corresponding to the > >per-port clocks on OMAP4. Then the driver wouldn't need to know which > >SoC it is running on. > > > >Another approach: > >Have a different glue layer driver for OMAP4. > > > >For the register bit differences, we do need to know which SoC we are > >running on to be able to use the correct register bits. For this, > > isn't the ehci ip revision different ? Why don't you use that instead of > cpu_is_omap* > Yes the revision - but that's not as good a test as using UHH_REVISION. The difference between the IPs is a function of the UHH_REVISION, and to me reading EHCI revision/capabilities is more hack-ish than just using UHH_REVSION. > >One approach: > >At the very minimum, we need a set of clocks to be enabled to be able to > >read the UHH_REVISION register, and we could use that to figure out which > >bits we need to use. > > exactly > > >The other approach I can think of is to have platform data tell us (I'm > >guessing this is a bad idea). > > yeah, that would be bad... > > >What do you think? > > another approach: > > make ohci and ehci play well together Yes - this is long overdue and work in progress. > have an omap3-specific and one > omap4-specific MFD-like driver that will instantiate ehci and ohci > platform_drivers and handle clock + locking to shared address space. > > then you define a set of accessor functions for registers with different > offset that act differently depending on revision of the ip core. > > Does that work ? The shared address spaces need to be configured once at init - their values are board dependent and wouldn't need to be changed at runtime. This should work. We'll work on it. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
