> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Kevin Hilman > Sent: Saturday, September 12, 2009 2:52 AM > To: Premi, Sanjeev > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [RFC] OMAP3 : PM : Handle variable length OPP tables > > "Premi, Sanjeev" <premi@xxxxxx> writes: > > >> -----Original Message----- > >> From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > >> Sent: Friday, September 11, 2009 12:00 AM > >> To: Premi, Sanjeev > >> Cc: linux-omap@xxxxxxxxxxxxxxx > >> Subject: Re: [RFC] OMAP3 : PM : Handle variable length OPP tables > >> > >> "Premi, Sanjeev" <premi@xxxxxx> writes: > >> > >> > Hi all, > >> > > >> > There is no generic function to translate an OPP to FREQ > >> and vice versa. > >> > Came across the problem while trying to submit a follow-up > >> to earlier > >> > patch for change in mpurate via bootargs. > >> > > >> > The function get_opp in resource34xx.c, but it is always > >> called with an > >> > explicit addition of MAX_VDDn_OPP e.g. > >> > > >> > opp = get_opp(mpu_opps + MAX_VDD1_OPP, clk->rate); > >> > opp = get_opp(l3_opps + MAX_VDD2_OPP, clk->rate); > >> > > >> > This is 'addition' is required as there is no > encapsulation of the > >> > MIN and MAX VDDs associated to the table. > >> > > >> > The patch below fixes this issue; buy creating a 'table' > object with > >> > necessary information. It can also help in getting rid of the > >> > empty {0, 0, 0} at index 0 of each OPP table. > >> > > >> > At the moment, it does not break any functionality in > >> resource34xx.c; > >> > migration to this encapsulation can be taken as next step. > >> > > >> > This code is bare 'git-diff' for early comments. Formal > >> patch to follow... > >> > > >> > Best regards, > >> > Sanjeev > >> > >> Is the goal of the min and max fields so you could have some OPPs > >> in the table that aren't valid for some SoCs? IOW, the 'max' value > >> might be higher on newer SoCs with higher OPPs. > > > > The goal is to have get_*() functions where caller > shouldn't be aware > > of the MAX_ for the table. Considering table as an object, it should > > be able to provide its own length. > > > > Reason to use min and max was to maintain current > functionality as is. > > Else, simple 'length' should be sufficient. > > > >> > >> What if you want a list of OPPs, but want to remove one from the > >> middle of the list? The min/max approach doesn't work here. > >> > >> What about a also extending the struct omap_opp to have > some sort of > >> valid field. > > > > This doesn't help in eliminating the addition of MAX value for each > > function call. > > No it doesn't. I'm just thinking about the next step of > having a more flexible list of OPPs. [sp] Oh yes, it will be a good addition. I misunderstood your earlier comment :( Best regards, Sanjeev > > Kevin > > snip---snip--snip -- 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
