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.
Kevin
--
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
