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.
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,
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.
The other approach I can think of is to have platform data tell us (I'm
guessing this is a bad idea).
What do you think?
- 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
