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"
b) a common silicon errata handling mechanism: Does anyone have
proposals for this? I can see it help in numerous places in our code
today and will help readability of the code instead of getting the risk
of "feature not a bug" misread.. ;)..
--
Regards,
Nishanth Menon
--
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
