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;
>>>> [email protected]
>>>> Subject: Re: FEATURES - is it good enough
>>>>
>>>> Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:
>>>>
>>>>> "Shilimkar, Santosh" <[email protected]> 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
--
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
