[U-Boot] [PATCH 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency

[Tom Rini]

On Mon, Jul 29, 2013 at 05:57:22PM +0200, Enric Balletbo Serra wrote:
> Hi Tom,
> 
> 2013/7/23 Dan Murphy <dmurphy at ti.com>:
> > On 07/19/2013 02:00 PM, Tom Rini wrote:
> >> Add a am33xx_spl_board_init (and enable the PMICs) that we may see,
> >> depending on the board we are running on.  In all cases, we see if we
> >> can rely on the efuse_sma register to tell us the maximum speed.  In the
> >> case of Beaglebone White, we need to make sure we are on AC power, and
> >> are on later than rev A1, and then we can ramp up to the PG1.0 maximum
> >> of 720Mhz.  In the case of Beaglebone Black, we are either on PG2.0 that
> >> supports 1GHz or PG2.1.  As PG2.0 may or may not have efuse_sma set, we
> >> cannot rely on this probe.  In the case of the GP EVM, EVM SK and IDK we
> >> need to rely on the efuse_sma if we are on PG2.1, and the defaults for
> >> PG1.0/2.0.
[snip]
> >> +             /*
> >> +              * The GP EVM, IDK and EVM SK use a TPS65910 PMIC.  For all
> >> +              * MPU frequencies we support we use a CORE voltage of
> >> +              * 1.1375V.  For MPU voltage we need to switch based on
> >> +              * the frequency we are running at.
> >> +              */
> >> +             if (i2c_probe(TPS65910_CTRL_I2C_ADDR))
> >> +                     return;
> >> +
> >> +             /* VDD1/2 voltage selection register access by control i/f */
> >> +             if (i2c_read(TPS65910_CTRL_I2C_ADDR, TPS65910_DEVCTRL_REG, 1,
> >> +                          buf, 1))
> >
> > Would it not be better to have an API in the pmic driver file that
> > you can call to access the pmic instead of calling the pmic
> > explicitly?

So, somewhat.

[snip]
> >> +             /* Depending on MPU clock we need different MPU VDD */
> >> +
> >> +             /* Default to PG1.0/PG2.0 values. */
> >> +             mpu_vdd = TPS65910_OP_REG_SEL_1_1_3;
> >> +
> >> +             if (sil_rev >= 2) {
> >> +                     switch (mpu_pll) {
> >> +                     case MPUPLL_M_1000:
> >> +                             mpu_vdd = TPS65910_OP_REG_SEL_1_3_2_5;
> >> +                             break;
> >> +                     case MPUPLL_M_800:
> >> +                             mpu_vdd = TPS65910_OP_REG_SEL_1_2_6;
> >> +                             break;
> >> +                     case MPUPLL_M_720:
> >> +                             mpu_vdd = TPS65910_OP_REG_SEL_1_2_0;
> >> +                             break;
> >> +                     case MPUPLL_M_600:
> >> +                     case MPUPLL_M_300:
> >> +                             mpu_vdd = TPS65910_OP_REG_SEL_1_1_3;
> >> +                             break;
> >> +                     }
> >> +             }
[snip]
> As example, I just pushed[1] in my personal git an implementation of
> am33xx_spl_board_init for IGEP COM AQUILA AM335x based on your
> patches. As you can see this function is very similar to the function
> implemented in your patch. I wonder if it's possible implement a more
> generic form in order to avoid repeating code in board files. Maybe
> something like this :
> 
> For am335x_evm :
> 
>  am33xx_spl_board_init {
>     /* Get MPU max frequency */
>     mpu_pll = am335x_get_efuse_mpu_max_freq()
>     if (board_is_bone() || board_is_bone_lt())
>         tps65217_set_mpu_voltagel(mpu_pll) /* not sure if this can be generic */
>     else
>         tp65910_set_mpu_voltagel(mpu_pll)

The problem is that the TPS65910 family supports a wide range of non-TI
platforms (s5p, rockchip rk29xx, i.mx) so we can't hide the PG A.B ->
voltage required bit in the tps65910 call.  I'll see how something looks
in arch/arm/cpu/armv7/am33xx/sys_info.c along with the
efuse_mpu_max_freq function.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130807/5e8b93d1/attachment.pgp>