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

[Robin Gong]

On Wed, Feb 11, 2015 at 07:47:57AM -0800, Tim Harvey wrote:
> 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.
>
pinmux is not enough. WDT bit of WDOGx_WCR need to be taken care of if you want
to enable WDOG_B pin reset function. But unfortunately the current wdog driver
of kernel not touch this write-once bit. To limit the impact from kernel, set
this bit in u-boot.
> 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.
> 
As you saw in another mail, bootloader is too late. It'll hang in ROM code.
> <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.
> 
Can you please share me the patch link? Thanks.
> <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.
> 
Sorry, I mean max frequency(SPEED_GRADING[1:0]), not power-up frequency. 
> 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?
> 
Not for power reduction, just for match with the voltage setting which data
sheet saying in any time or any narrow timing window. Have to set VDDRAM_IN
1.3v for 800Mhz(VDDARM 1.175v) before ldo-bypass mode switched. And set
VDDARM_IN to 1.175v after ldo-bypass mode switched. But in the narrow window
which VDDARM_IN from 1.3v to 1.175v with ldo-bypass mode enabled. The 1.3v
plus power ripple may beyond the max volage.
> >> 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.
> 
Tim, thanks for your reviewing, understood your concerning. Looks it's better
done in kernel.
> Regards,
> 
> Tim