Re: FEATURES - is it good enough

["Menon, Nishanth" <nm@ti.com>]

Alexander Shishkin said the following on 12/01/2009 05:42 PM:
> On Fri, Nov 20, 2009 at 02:09:01 -0600, Nishanth Menon wrote:
>   
>> Aguirre, Sergio had written, on 11/20/2009 01:43 PM, the following:
>>     
>>>> -----Original Message-----
>>>> From: Menon, Nishanth Sent: Friday, November 20, 2009 1:24 PM
>>>> To: Kevin Hilman
>>>> Cc: Shilimkar, Santosh; Aguirre, Sergio; Pandita, Vikram;
>>>> linux-omap@vger.kernel.org
>>>> Subject: Re: FEATURES - is it good enough
>>>>
>>>> Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:
>>>>         
>>>>> "Shilimkar, Santosh" <santosh.shilimkar@ti.com> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>           
>>>>>>>> Probably not something ot be attached in this patch, but...
>>>>>>>>
>>>>>>>> I'm a bit curious about something:
>>>>>>>>
>>>>>>>> Why touching omap3_features in OMAP4?
>>>>>>>>
>>>>>>>> Isn't there a omap4_features?
>>>>>>>>
>>>>>>>> Or even better, an omap_features?
>>>>>>>>                 
>>>>>> This "is_feature" suppose to take care of Errata's also, is it?
>>>>>>             
>>>>> "It's not a bug it's a feature." :)
>>>>>           
>>>> Bug. Santosh pointed out internally to h/w discussion which
>>>> clearly shows this as a h/w limitation. (thanks santosh)
>>>>
>>>>         
>>>>>> This is errata more than a feature..... We better differentiate in
>>>>>> this regard
>>>>>>             
>>>>> I agree, I have a hard time calling this empty fifo read fault a
>>>>> "feature."  We need a similar thing for errata.
>>>>>           
>>>> Agreed. This is a classic example why we need a common errata
>>>> handling mechanism scalable across silicon variants on an IP
>>>> basis. two problems in front of us:
>>>> a) what do we want to do with 8250 workaround needed for
>>>> omap3630 and omap4? can we go ahead with features marking it
>>>> clearly as a "misuse of features for the time being"
>>>>         
>>> IMHO, That "for the time being" will stay forever if we don't do something now.
>>>
>>> Most of the big problems are raised because someone says "ok, lets have this for
>>> the time being". But that time never comes.
>>>
>>> See that crazy CaMeL-Casing hanging around in /drivers/dsp/bridge/ for a while as
>>> an example. When that will ever be fixed? I bet someone said some time:
>>> "ok, lets fix it later" :-)
>>>
>>> On the other hand. What's the big motivation to have this as a "feature"?
>>>
>>> Who else than the serial driver cares about the "feature" awareness?
>>>       
>> please see [1] and [2]. this wont be the first time I published
>> something previously that got ignored and got re-discussed. note:
>>     
>
> The [1] proposal sounds interesting to me, but it's not a very trivial matter.
>
>   
>> BTW, to be fair, DSPBridge already has plans to get fixed anyways..
>>
>> Options I can think which were discussed:
>> a) introduce omap3_features omap3_errata: negative: wont read like
>> if I use omap3_has_errata() for OMAP4 code.
>> b) introduce omap_features and omap_errata: negative: how do you
>> link this to IP based usage across silicon (e.g. I2C).
>>     
>
> How about omap_has_errata(module, errata)?
> Or even something more generic?
>   
hmm.. just throwing more ideas up in the air:

Call method:
omap_ip_has_errata(u32 ip, u32 rev, u8 check_type,  u8 erratum)
where,
    ip = I2C, GPMC, MMC, etc..
    rev = revision number
    check_type = GT, LT, NE, EQ
    erratum = erratum type

omap_cpu_has_errata(u32 cpu_id, u32 rev, u8 check_type, u16 erratum)
where,
    cpu_id = 15xx, 16xx etc ( can this be a function pointer to
cpu_is..() functions? if so, how do we register this)
    rev = chip revision number
    check_type = GT, LT, NE, EQ
    erratum = erratum type
  
Registration/Initialization: ??

maybe this could be extended to features also..
Regards,
Nishanth Menon