Nishanth Menon <nm@xxxxxx> writes: > Nishanth Menon had written, on 08/13/2009 11:43 AM, the following: >> Kevin Hilman had written, on 08/13/2009 11:40 AM, the following: >>> "Pandita, Vikram" <vikram.pandita@xxxxxx> writes: >>> >>>>> -----Original Message----- >>>>> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of >>>>> Sent: Thursday, August 13, 2009 11:31 AM >>>>>>> Since most of the code seemed repetitive, macros >>>>>>> have been used for readability. >>>>>>> >>>>>>> Signed-off-by: Sanjeev Premi <premi@xxxxxx> >>>>>> I like the feature-based approach. >>>>>> >>>>>> A couple questions though. Is there a bit/register that reports the >>>>>> collapsed powerdomains of the devices with modified PRCM? >>>>>> >>>>>> Also, how will other code query the features? You're currently >>>>>> exporting the omap_has_*() functions, but there are no prototypes. >>>>>> >>>>>> I think I'd rather see a static inline functions in <mach/cpu.h> >>>>>> for checking features. Comments to that end inlined below... >>>>> Wonder if we can setup some sort of infrastructure for: >>>>> a) features >>>>> b) erratas >>>>> linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) >>>>> revisions since at times they are used across multiple OMAPs? >>>> We are hitting exactly this issue with I2C errata 1.153 >>>> Instead of basing the errata check on cpu_is...(), its more >>>> appropriate to base it on IP revision of I2C. >>> Shouldn't the IP revision of I2C be avaialble in an I2C revision >>> register an be used in the driver instead of cpu_is*? >> what I was proposing is a much more generic infrastructure which i2c >> among other modules can use. Getting IP revision is already >> available in the specific IP modules REVISION registers - we might >> want to standardize how drivers handle revision based feature/errata >> set to ensure that they would have an optimal way to handle the >> same.. just my 2 cents.. >> > Thinking of this a little more: > driver's smart handling aside, having a sysfs entry to dump the > features and erratas for each of the modules used is so much nice to > have.. sigh.. just wondering if anyone has ideas how feasible this > might be.. $SUBJECT patch will dump all the chip features during boot, and it shouldn't be much work too add this to /proc/cpuinfo either. The errata are another story and should be left to another patch IMHO since Sanjeev is just tring to get base 35xx support enabled for now. Kevin -- 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
