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@xxxxxxxxxxxxxxx
Subject: Re: FEATURES - is it good enough
Kevin Hilman had written, on 11/20/2009 12:35 PM, the following:
"Shilimkar, Santosh" <santosh.shilimkar@xxxxxx> 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:
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).
I dont think these are scalable solutions though..
--
Regards,
Nishanth Menon
[1] http://marc.info/?l=linux-omap&m=125018632606920&w=2
[2] http://marc.info/?l=linux-omap&m=125319739327677&w=2
--
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
