* Nishanth Menon <nm@xxxxxx> [100707 16:44]:
> >>overall, we will face this in the future. there are OMAP generic
> >>features and OMAP family specific features. currently OMAP3 has
> >>34xx, 35xx series and 3630 and 37xx series. in future we may see
> >>similar things for OMAP4+ as well.. we need a differentiator when it
> >>comes to omap3 specific features Vs omap generic feature.
> >
> >Sounds it will get more complex.. We should probably set it up
> >with something like this then:
> >
> >#define FEAT_MPU_L2_OUTER BIT(1)
> >#define FEAT_MPU_L2 BIT(0)
> >...
> >
> >#define FEAT_IVA2 BIT(1)
> >#define FEAT_IVA BIT(0)
> >...
> >
> >#define FEAT_L3_192 BIT(0)
> >...
> >
> >struct omap_feature {
> > u32 mpu; /* MPU features */
> > u32 iva; /* IVA features */
> > u32 l3_max_clk;
> > ...
> >};
> I think I understand your intent here is to introduce per IP based
> feature - that is really not necessary yet (we dont really have a
> usecase needing this level of complexity yet). it will be a natural
> evolution when we need to have such a feature handling.
But we already have a problem where we need to check for various
revisions and features and use cpu_is_omapxxxx. It would be nice to
just call omap_has_feature without having to worry about which omap
it is.
> currently a need for errata handling per ip is required, and we have
> a mechanism (quirks) to handle it on a IP basis. here the intent was
> to identify OMAP specific features in some common way.
OK. I'll post an experimental series shortly, let's see if that
works for you.
Regards,
Tony
--
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
