> -----Original Message----- > From: Premi, Sanjeev > Sent: Tuesday, October 06, 2009 2:14 PM > To: Shilimkar, Santosh; Menon, Nishanth; linux-omap@xxxxxxxxxxxxxxx > Cc: Kevin H > Subject: RE: Question on OPP table handling > > > > -----Original Message----- > > From: Shilimkar, Santosh > > Sent: Tuesday, October 06, 2009 1:36 PM > > To: Menon, Nishanth; linux-omap@xxxxxxxxxxxxxxx > > Cc: Premi, Sanjeev; Kevin H > > Subject: RE: Question on OPP table handling > > > > > -----Original Message----- > > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Nishanth Menon > > > Sent: Monday, October 05, 2009 10:49 PM > > > To: linux-omap@xxxxxxxxxxxxxxx > > > Cc: Premi, Sanjeev; Kevin H > > > Subject: Re: Question on OPP table handling > > > > > > Kevin Hilman had written, on 10/05/2009 11:56 AM, the following: > > > > "Premi, Sanjeev" <premi@xxxxxx> writes: > > > > > > > >>> -----Original Message----- > > > >>> From: Nishanth Menon [mailto:menon.nishanth@xxxxxxxxx] > > > >>> Sent: Saturday, October 03, 2009 8:35 PM > > > >>> To: Premi, Sanjeev > > > >>> Cc: linux-omap@xxxxxxxxxxxxxxx > > > >>> Subject: Question on OPP table handling > > > >>> > > > >>> Sanjeev Premi said the following on 10/01/2009 01:03 PM: > > > >>>> +struct omap_opp omap3_mpu_rate_table[] = { > > > >>>> + {0, 0, 0}, > > > >>>> + /*OPP1*/ > > > >>>> + {S125M, VDD1_OPP1, 0x1E}, > > > >>>> + /*OPP2*/ > > > >>>> + {S250M, VDD1_OPP2, 0x26}, > > > >>>> + /*OPP3*/ > > > >>>> + {S500M, VDD1_OPP3, 0x30}, > > > >>>> + /*OPP4*/ > > > >>>> + {S550M, VDD1_OPP4, 0x36}, > > > >>>> + /*OPP5*/ > > > >>>> + {S600M, VDD1_OPP5, 0x3C}, > > > >>>> +}; > > > >>>> > > > >>> For those involved, > > > >>> if we wanted to convert omap3_mpu_table[] into > > > >>> *omap3_mpu_table so that > > > >>> we dynamically initialize it based on cpu type - what > > would be the > > > >>> recommendations? > > > >> Nishanth, > > > >> > > > >> Good idea! > > > >> > > > >> As a table, previous patch enables it (not as intent, but due to > > > syntax): > > > >> > > > >> > +/* struct omap_opp_table - View OPP table as an object > > > >> > + * @min: Minimum OPP id > > > >> > + * @max: Maximim OPP id > > > >> > + * @opps: Pointer to array defining the OPPs. > > > >> > + * > > > >> > + * An OPP table has varied length. Knowing minimum > > and maximum > > > >> > + * OPP ids allow easy traversal. > > > >> > + */ > > > >> > +struct omap_opp_table { > > > >> > + u8 min; > > > >> > + u8 max; > > > >> > + struct omap_opp* opps; > > > >> > +}; > > > >> > > > >> But now, I think it would be good to have an API that can fill an > > > opp_table: > > > >> > > > >> int add_opp_definition(u8 id, u32 freq, u16 vsel); > > > >> > > > >> ...and, if an array is preferred, length can be set as: > > > >> int set_opp_table_length (u8 max); > > > > > > > > I'm all for dynamic OPP setting, but not as an array. A > > list should > > > > probably be used. > > > > > > Won't a list implementation cause more than necessary > > overhead? I agree > > > that something like set_opp_table_length probably might be > > redundant in > > > that case. > > > > > > > > > >> If I were to extend the discussion from other thread on > > toggling the > > > valid OPPs > > > >> based on "enable_off_mode", these could be handy. > > > >> > > > >> int set_opp_valid(bool flag); > > > >> bool is_opp_valid(void); > > > >> > > > > > > > > Yes, we need a concept of a valid OPP, not just for OFF > > mode, but for > > > > OSWR and possibly for a full constraint framework as well. > > > Ack. > > Even though above approach is possibly better a simple fix > > could be just adding a flag in the structure (OPP > > valid/invalid) and populating this flag run time using CPU type. > > > > [sp] This is exactly in the original patch. OK Regards, Santosh -- 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
