> -----Original Message-----
> From: Nishanth Menon [mailto:[email protected]]
> Sent: Saturday, October 03, 2009 8:35 PM
> To: Premi, Sanjeev
> Cc: [email protected]
> 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);
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);
Best regards,
Sanjeev
> Regards,
> Nishanth Menon
>
>
> --
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
