RE: [RFC] [PATCH 3/7] usb: ehci-omap: omap: Add OMAP4 support

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

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux