> -----Original Message----- > From: Cousson, Benoit > Sent: Tuesday, October 06, 2009 2:12 PM > To: Kevin H; linux-omap@xxxxxxxxxxxxxxx > Cc: Premi, Sanjeev; Menon, Nishanth > Subject: RE: Question on OPP table handling > > Hi Kevin, > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Nishanth Menon > > Sent: Monday, October 05, 2009 7:19 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. > > I'm aligned with Nishanth. I think a static table with the > possibility to disable some entry is good enough to deal with > most of the OPPs we have on OMAP3 and we will have to handle on OMAP4. > > OPPs are defined during silicon characterization, and should > not be changed dynamically (in theory). [sp] The intent of 'dynamic' is not with respect to changing the OPPs but manitaining OPPs in an array or a list. This is to take care of possibility that an OPP is not applicable for specific devices. E.g. OPP5 was earlier considered 'overdrive'; and the code had a small 'hack' to prevent this OPP being used during cpufreq. Marking the OPP 'disabled/invalid' in the table would have been a better solution. In a 'list' implementation, the node corresponding to such OPPs can be removed from the 'active' list. Best regards, Sanjeev > > Do you have something in mind that might justify a dynamic management? > > Regards, > Benoit > > > >> 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. > > -- > > 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 > > -- 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
