> -----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. 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
