* Nishanth Menon <[email protected]> [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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
