Re: [PATCH] Runtime detection of Si features

[Kevin Hilman <khilman@deeprootsystems.com>]

Nishanth Menon <nm@ti.com> 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@ti.com> writes:
>>>
>>>>> -----Original Message-----
>>>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] 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@ti.com>
>>>>>> 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