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@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: 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? Regards, -- Alex -- 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
