> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Premi, Sanjeev > Sent: Thursday, March 17, 2011 2:01 PM > To: Sripathy, Vishwanath; linux-omap@xxxxxxxxxxxxxxx > Cc: Cousson, Benoit; paul@xxxxxxxxx > 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; linux-omap@xxxxxxxxxxxxxxx > > Subject: RE: [RFCv2 2/2] AM35x: voltage: Basic initialization > > > > > -----Original Message----- > > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Sanjeev Premi > > > Sent: Wednesday, March 16, 2011 1:02 PM > > > To: linux-omap@xxxxxxxxxxxxxxx > > > 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 <premi@xxxxxx> > > > --- > > [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 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
