On Wed, Dec 02, 2009 at 08:06:16 +0200, Menon, Nishanth wrote: > 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@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? > > > 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 Is there a use case when a caller would be interested in an erratum of a cpu other than the one it is currently running on? Otherwise it could be omap_this_cpu_has_errata(). And the same for IPs. > check_type = GT, LT, NE, EQ Is this meant to compare cpu ids or revision numbers? I'm not sure I follow the idea here. > erratum = erratum type > > Registration/Initialization: ?? Perhaps, statically compiled in tables of per-cpu/rev erratas/features. This has to be better than runtime detection and at least as good as making assumptions based on cpu_is_omapXXXX(). > maybe this could be extended to features also.. Aren't features and erratas semantically the same thing? Maybe, the same interface could be used. 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
