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

[Tim Harvey]

On Fri, Feb 13, 2015 at 12:16 AM, Robin Gong <b38343 at freescale.com> wrote:
> 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.

Hi Robin,

'To limit the impact from kernel, set this bit in u-boot' indicates
that you are trying to create a u-boot and kernel dependence on each
other which is a bad idea. The kernel should take care of everything
it needs without making assumptions on what the bootloader did.

You are correct in that the current imx2_wdt.c does not 'set' the
write-once WCR bit to enable the external reset but it does seem funny
to me that Freescale decided to patch system.c's mxc_restart
(http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/arch/arm/mach-imx/system.c?h=imx_3.10.53_1.1.0_ga&id=ee07b144e1adff13d262e7f353f5804e3c2d3e06)
to try to deal with the machine_restart case but did not patch
imx2_wdt.c to deal with the watchdog timeout case.

Wouldn't these boards also hang when reset from a watchdog timeout
when using ldo-enabled and CPU at 397Mhz. It seems to me that you should
also be patching imx2_wdt.c to set WCR for that case.

>> 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>
>>
> Can you please share me the patch link? Thanks.

The link was further up in the thread in response to Peng:

Instead of touching U-Boot, in my 'Freescale' kernel I look for the
fsl,ldo-bypass node in the kernel init and enable it just like their
bootloader would have:

https://github.com/Gateworks/linux-imx6/commit/a1af6ac6f00b4da7c8a5656e8ff093d4ab5cadee

It is still not good to rely on the fsl,ldo-bypass property to be set
(which will never make it into mainline) because this does not
garuntee that ldo-bypass is setup and functioning correctly at all (ie
user could have PMIC driver disabled, or not configured in device-tree
properly as source for arm/soc rails) but I haven't figured out the
best solution upstream yet and haven't had time to get back to it. Its
still a much lesser evil than requiring that ldo-bypass be configured
in the bootloader. This patch removes the dependence upon the
bootloader (I will never use Freescales hacked up U-Boot - I think its
still based on a 2009 branch).

I have given up on getting patches into Freescale's kernel - perhaps
being an employee you will have better luck :) I'm still hoping that
someday mainline linux will have all the IPU/VPU/GPU support for IMX6
that is missing (but getting very close!) which is what is forcing me
to use Freescale's kernel for some of our BSP's.

Tim