On Fri, Feb 13, 2015 at 12:16 AM, Robin Gong b38343@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@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@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/...) 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@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/a1af6ac6f00b4da7c8a5656e8ff09...
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