> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Premi, Sanjeev
> Sent: Thursday, March 17, 2011 2:01 PM
> To: Sripathy, Vishwanath; [email protected]
> Cc: Cousson, Benoit; [email protected]
> Subject: RE: [RFCv2 2/2] AM35x: voltage: Basic initialization
>
> > -----Original Message-----
> > From: Sripathy, Vishwanath
> > Sent: Wednesday, March 16, 2011 4:33 PM
> > To: Premi, Sanjeev; [email protected]
> > Subject: RE: [RFCv2 2/2] AM35x: voltage: Basic initialization
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:linux-omap-
> > > [email protected]] On Behalf Of Sanjeev Premi
> > > Sent: Wednesday, March 16, 2011 1:02 PM
> > > To: [email protected]
> > > Cc: Sanjeev Premi
> > > Subject: [RFCv2 2/2] AM35x: voltage: Basic initialization
> > >
> > > This patch adds the basic initialization of voltage layer
> > > for AM35x. Since AM35x doesn't support voltage scaling,
> > > Many functions emply fucntions have been defined to plug
> > > into existing voltage layer.
> > >
> > > Signed-off-by: Sanjeev Premi <[email protected]>
> > > ---
>
> [snip]...[snip]
>
> > > +/**
> > > + * AM35x - Empty initialization of voltage processor
> > > + */
> > > +static void __init am3517_vp_init(struct omap_vdd_info *vdd)
> > > +{
> > > +}
> > > +
> > > +/**
> > > * omap_voltage_early_init()- Volatage driver early init
> > > */
> > > static int __init omap_voltage_early_init(void)
> > > {
> > > int i;
> > >
> > > - if (cpu_is_omap34xx()) {
> > > + if (cpu_is_omap3505() || cpu_is_omap3517()) {
> > > + vdd_info = am3517_vdd_info;
> > > + nr_scalable_vdd =
> > > AM3517_NR_SCALABLE_VDD;
> > As you have mentioned that there is no voltage scaling
> supported, then
> > shoudn't nr_scalable_vdd = 0?
> > If nr_scalable_vdd is 0, then you probably would not need any
> > other TPS
> > specific changes in Voltage.c as VP and VC initialization itself is
> > skipped.
>
> [sp] Yes, there is no voltage scaling; but there are two
> problems in the
> flow.
> Notice I had this value 0 in previous RFC; and yes I expected the
> vp and vc to be excluded as you say; however, code isn't really
> meant to do so.
> Few loops using "nr_scalable_vdd" fail as value "0"
> doesn't meet the
> entry criteria. This problem is/was easily fixes by an additional
> if statement.
>
> The things, however, get stuck in HWMOD again when the parent of
[sp] Being more specific:
The parent here refers to "parent" vdd i.e. "vdd_name".
~sanjeev
> omap3xxx_l3_main_hwmod is set as "core". Changing this causes
> another cascade of changes leading to almost duplicating
> the complete
> hwmod structure for AM35x.
>
> Easy solution was to set use "core". Rest of the changes
> in the patch
> ensure that code flows properly - and there is no scaling.
>
> ~sanjeev
>
> >
> > Vishwa
> > > + vc_init = am3517_vc_init;
> > > + vp_init = am3517_vp_init;
> > > + vdd_data_configure = am3517_vdd_data_configure;
> > > + } else if (cpu_is_omap34xx()) {
> > > vdd_info = omap3_vdd_info;
> > > nr_scalable_vdd = OMAP3_NR_SCALABLE_VDD;
> > > vc_init = omap3_vc_init;
> > > --
> --
> 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
> --
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
