On Fri, 2011-12-09 at 16:21 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@xxxxxx> writes:
>
> > OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
> > overlap with VDD2 and attempting to modify VDD1 voltage will actually change
> > VDD2 voltage.
> >
> > Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
> > ---
> > arch/arm/mach-omap2/vc3xxx_data.c | 1 +
> > 2 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/vc3xxx_data.c b/arch/arm/mach-omap2/vc3xxx_data.c
> > index cfe348e..0136ad5 100644
> > --- a/arch/arm/mach-omap2/vc3xxx_data.c
> > +++ b/arch/arm/mach-omap2/vc3xxx_data.c
> > @@ -46,6 +46,7 @@ static struct omap_vc_common omap3_vc_common = {
> > };
> >
> > struct omap_vc_channel omap3_vc_mpu = {
> > + .flags = OMAP_VC_CHANNEL_DEFAULT,
> > .common = &omap3_vc_common,
> > .smps_sa_reg = OMAP3_PRM_VC_SMPS_SA_OFFSET,
> > .smps_volra_reg = OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET,
>
> Looking more at the flow diagram you mentioned in the OMAP3 TRM, I don't
> think this is right for OMAP3.
>
> Setting the USE_DEFAULTS flags means that VDD1 will only ever be able to
> use [slave address | voltage reg | command reg] zero. While this is
> quite likely in most scenarios, the HW doesn't limit this like it does
> on OMAP4.
>
> On OMAP3, it's very possible to configure VDD1 to use
> [slave address | voltage reg | command reg] one if you want (even though
> I'm not sure why you would.)
>
> In any case, my point is that setting the USE_DEFAULTS flag forces an
> OMAP4 restriction onto OMAP3 which the hardware doesn't have.
>
Well, the voltage control does not work at all if this is not done. I am
not sure what is the root cause for this, as I don't have currently
oscilloscope available so that I could take a look at the bus traffic.
The voltage rail behavior is incorrect unless this change is in, this is
easily seen by measuring the voltage levels and trying to change the
voltages by sw.
-Tero
--
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
