[U-Boot] [PATCH 07/12] imx:mx6 Support LDO bypass

Tim Harvey tharvey at gateworks.com
Wed Feb 11 16:47:57 CET 2015


On Wed, Feb 11, 2015 at 2:49 AM, Robin Gong <b38343 at freescale.com> wrote:
<snip>
>>
>> This is very board dependent. Here you are referring to a board that
>> has a reset input to the PMIC's from the IMX6's watchdog output. In
>> this case, this reset routing/pinmux would be needed regardless of
>> using ldo-bypass mode or not and that should just be a pinmux of the
>> pin your using for WDOG_B.
>>
> There are two types of reboot in our chip by watchdog : SRS/warm reset
> (Software Reset Signal) and WDOG_B(reset signal output to external pmic
> to trigger next power cycle). In fact, warm reset can work most cases except
> ldo-bypass mode and this is why we connect WDOG_B reset and ldo-bypass here:
> kernel may trigger warm reset at the lowest cpu freq setpoint, for example
> VDDARM 0.975v at 396Mhz ldo-bypass mode. i.mx6q will reboot with ldo-enable mode
> @792Mhz and the VDDARM_IN 0.975v can't support system boot.Thus, we need use
> WDOG_B pin to reset external pmic if using ldo-byapss mode.

Hi Robin,

I understand that configuring WDOG_B external reset must be used when
LDO bypass is used. This should be done in the kernel but you can also
set this pinmux up in uboot in the board-specific init.

If your kernel is providing the PMIC driver and cpufreq driver that
alter the cpu core frequencies it must also be configuring pinmux so
that WDOG_B gets routed to the pin that connects to the PMIC so any
reset based on that wdog (SRS or timeout) issues a hard reset to the
PMIC. Failure to do so is a kernel bug. I believe this is done
properly in the Freescale kernel for the reference boards.

If you are trying to take care of an issue caused by a watchdog reset
(SRS or timeout) not properly resetting a PMIC (ie perhaps a PCB
errata where signal doesn't go to the PMIC) then you should probably
simply set the PMIC rails where they need to be for the 800MHz
operation in the bootloader and not muck with the CPU frequency.
Honestly, if your PMIC rails are too low for 800MHz on powerup your
bootloader may not be stable anyway right? Note that the operating
setpoints have the same SOC voltage for both 792MHz and 396MHz, its
only the ARM voltage that is lower for 396 vs 792 and chances are your
not going to have an issue just in the bootloader at that point.

<snip>
>>
>> What you are doing here is relying on a device-tree binding from the
>> Freescale 'vendor' kernel, which will NEVER make it upstream and this
>> is one of the issues I was running into getting ldo-bypass capability
>> upstream in the kernel.
>>
>> The issue here is that LDO bypass is dependent on the following things:
>>   1. your voltage rail requirements - which are dependent on the CPU
>> frequency (there is a nice table in the IMX6 datasheets of voltage on
>> each rail at each frequency operating point validated by Freescale).
>> The exception of always using the LDO for 1.2GHz is specified here as
>> well.
>>   2. you have a PMIC in your design on VDD_ARM_IN and VDD_SOC_IN rails
>> - this should be specified in the device-tree as well
>>   3. you have valid PMIC drivers configured
>>
>> In the kernel, its not desired to have a single device-tree node
>> called 'fsl,ldo-bypass' for an enable. Instead you need to make sure
>> that you PMIC regulators that are 'not' the internal IMX6 anatop
>> regulators. This property is not a mainline linux device-tree binding.
>>
> Yes, understood. But we have no better solution, because we need touch both
> internal anatop regulator and external pmic regulator in ldo-bypass mode, that
> bring kernel cpufreq driver code too messy....

I just don't see the point in having the CPU frequency changed in the
bootloader - leave this up to the OS kernel. I don't think any of this
patch should go into mainline uboot.

I think my kernel patch I referenced provides you with a simple kernel
solution that de-couples ldo-bypass completely from the bootloader.

<snip>
>>
>> While it is correct that you must not use LDO bypass when operating at
>> 1.2GHz, that does not mean that a CPU capable of 1.2GHz can't use LDO
>> bypass at the lower operating points.
>>
> I see, but to simply things, we regard as 1.2GHz chip(fused) may running at
> 1.2GHz and force it work in ldo-enable mode although it has chance to running
> at 1Ghz. In other words, ldo-bypass mode only set once not dynamically.

Are you saying there is an IMX6 variant that powers up per eFUSE
settings at 1.2GHz? The IMX6QDLRM efuse settings I'm looking at just
have two power-up frequency options: 392MHz and 792MHz.

In my opinion, your PMIC should be setting VDD_ARM and VDD_SOC at the
necessary voltages for what the CPU is currently running at, in the
bootloader. Its up to your OS to properly control this to its needs
later. Again, if for some reason (hardware errata) you have a
situation where the PMIC maybe didn't get reset and the board powers
up into the bootloader at a frequency higher than the rails are set
to, then simply set its rails to where they need to be for the freq
your running at in the bootloader.

>> > +
>> > +static int arm_orig_podf;
>> > +void set_arm_freq_400M(bool is_400M)
>> > +{
>> > +       struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
>> > +
>> > +       if (is_400M)
>> > +               writel(0x1, &mxc_ccm->cacrr);
>> > +       else
>> > +               writel(arm_orig_podf, &mxc_ccm->cacrr);
>> > +}
>>
>> I have no idea what is going on here. Are we now running at different
>> CPU frequencies in U-boot? The IMX6 comes up in either 800MHz or
>> 400MHz per BOOT_CFG3 e-fuse and from the U-Boot I'm working with
>> (still on 2010.04 but pretty sure its the same in 2014.10) the CPU
>> frequency is never changed in the bootloader.
>>
> Let's try to explain why we downgrade cpufreq to 400Mhz before ldo-bypass mode
> switch(i.mx6q):
>   cpufreq    VDDSOC    VDDARM
>   400Mhz     0.975v     1.175v
>   800Mhz     1.175v     1.175v
> If system boot from 800Mhz, considering VDDARM setting with 1.175v after
> ldo-bypass mode switch, and the voltage drop which bring by internal regulator
> 125mv, we have to set VDDARM 1.175v+125mv = 1.3v before ldo-bypass mode switch,
> but the 1.3v beyond our max voltage for VDDARM. So we have to downgrade the cpufreq
> to 400Mhz.

Too much complexity in my opinion for the power reduction benefits
while in the bootloader. Leave ldo-bypass out of the bootloader and
you won't have to bother with this. The IMX6 can handle a max of 1.3V
on VDD_ARM_IN and VDD_SOC_IN (and 1.5V on the output side of the LDO).
So you can simply set your PMIC in the bootloader to something between
that and 1.175v and be done with it right?

>> This brings me to the question of why does LDO bypass have anything at
>> all do to with the bootloader?
>>
> We only need do once ldo-bypass switch, so we hope it can be implemented in
> u-boot

It doesn't belong in uboot. It was wrong for Freescale to create a
dependence between the bootloader and the kernel when it is so easy to
avoid.

I don't think any of this particular patch should go into mainline uboot.

Regards,

Tim


More information about the U-Boot mailing list