+ Benoit, Paul > -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Gadiyar, Anand > Sent: Friday, August 20, 2010 11:17 AM > To: felipe.balbi@xxxxxxxxx; Munegowda, Keshava > Cc: linux-usb@xxxxxxxxxxxxxxx; linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [RFC] [PATCH 3/7] usb: ehci-omap: omap: Add OMAP4 support > > Felipe Balbi wrote: > > On Thu, Aug 19, 2010 at 01:49:33AM +0200, ext Keshava Munegowda wrote: > > >@@ -298,7 +327,163 @@ static int omap_start_ehc(struct ehci_hc > > > } > > > > > > if (cpu_is_omap44xx()) { > > >- /* TODO */ > > > > driver should never make use of cpu_is_omap* calls neither machine_is_* > > for that matter. Driver shouldn't care about correct clock names either. > > You need to find a better to handle differences between omap3 and omap4. > > > > 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 > > 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. > One similar problem was with GFX between OMAP4 versions. The clock tree was completely different. Even DSS on OMAP3 and OMAP4 has different clock tree. Paul and Benoit suggested that this can be handled within the framework. I know USB is a special case because of different scenario's has different clock needs. You can list down the problems here. May be we can handle this in a more generic way using the frameworks rather than glue layer. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
