<snip>---<snip> > > > > > Here is a sample usage from one of the patch I am reworking > > for submission here: > > > > @@ -488,7 +494,9 @@ void omap_sram_idle(void) > > * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. > > * Hence store/restore the SDRC_POWER register here. > > */ > > - if (omap_rev() >= OMAP3430_REV_ES3_0 && > > + if ((cpu_is_omap3630() > > + || cpu_is_omap3505() || cpu_is_omap3517() > > + || cpu_rev_ge(34xx, OMAP34XX_ES_3_0)) && > cpu_rev_ge(34xx, OMAP34XX_ES_3_0) -> this is the cause of my > comment on > dirty code - redundant OMAP34XX_ in the macro when I do say > it is 34xx > in the first parameter! > > > omap_type() != OMAP2_DEVICE_TYPE_GP && > > core_next_state == PWRDM_POWER_OFF) > > sdrc_pwr = sdrc_read_reg(SDRC_POWER); > > > > Don't try to look more into the actual content of this example, > > but try to use existing macros to re-implement this condition. > > > > omap_rev() is always > OMAP3430_REV_ES3_0 for all OMAP35x devices; > > even for OMAP3530 at ES2.1 level (0x35302034 > 0x34304034) > > > > And the original condition doesn't hold good. > > > > Try to visualize silicon revision viz. "2.1" for OMAP3505 requiring > > the same example condition to be updated. > > I see similar potential use in enabling quirks and features > (the above > code btw could be better handled with a single variable > errata which is > populated with a flag at pm_init time.. > Will have detailed response later... But, 3530, 3505 and 3517 are not erratas. These are different silicons. AND this patch has no relation to power management. More and more silicons are going to be added to linux-omap tree as they are based. They all will follow their own revision lifecycle. I have no issues to go back and add the 2420 etc. but I don't have much information on their revision history. If you provide me info, I can update the patch OR you can submit a follow-up patch with related changes. The macros don't change due to addition of additional silicon revisions. ~sanjeev > > > > ~sanjeev > >> -- > >> Regards, > >> Nishanth Menon > > > -- > Regards, > Nishanth Menon > -- 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
