| Message ID | 1389877049-17615-1-git-send-email-fabio.estevam@freescale.com |
|---|---|
| State | Superseded |
| Delegated to: | Stefano Babic |
| Headers | show |
Hi Fabio, hi Albert, On 16/01/2014 13:57, Fabio Estevam wrote: > Commit 022298278 (mx6: soc: Disable VDDPU regulator) is causing kernel hang > for people using FSL kernel 3.0.35 and 3.10, so revert it for now. > > Reported-by: Otavio Salvador <otavio@ossystems.com.br> > Reported-by: Pierre Aubert <p.aubert@staubli.com> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> > --- > Stefano, > > I will provide a proper fix after 2014.01 is out, but to allow people to use > mainline U-boot with FSL kernels, it would be better to revert it for now. > Anyway, is it the fix known ? Should it be done in U-Boot or FSL-3.10 kernel ? > Thanks Albert, commit 022298278 generate trouble to several users. There is no drawbacks for U-Boot to revert it. Can you directly pick it up or do you prefer I send a PR ? Thanks, Stefano
Hi Stefano, On Thu, Jan 16, 2014 at 11:06 AM, Stefano Babic <sbabic@denx.de> wrote: > Anyway, is it the fix known ? Should it be done in U-Boot or FSL-3.10 > kernel ? I have just started debugging, so I am not sure at this point. Internal FSL U-boot also disables VDDPU, but it does not cause the hang when GPU driver is loaded. Regards, Fabio Estevam
Hello Fabio and Stefano, On Thu, Jan 16, 2014 at 11:21 AM, Fabio Estevam <festevam@gmail.com> wrote: > > On Thu, Jan 16, 2014 at 11:06 AM, Stefano Babic <sbabic@denx.de> wrote: > > > Anyway, is it the fix known ? Should it be done in U-Boot or FSL-3.10 > > kernel ? > > I have just started debugging, so I am not sure at this point. > > Internal FSL U-boot also disables VDDPU, but it does not cause the > hang when GPU driver is loaded. > As I said the SabreSD case seems to be solvable adding support for the PMIC. I did it for our customer board and it works however it does not solve the case where the board does not have a PMIC. One of our customer is in that case and for now I don't know a solution for it. The PMIC way that has been done in FSL fork is quite ugly as it does not use the PMIC API but can be used as a base for it.
On Thu, Jan 16, 2014 at 1:33 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > As I said the SabreSD case seems to be solvable adding support for the PMIC. Have you really tried it? I tried adding PMIC support on sabresd and it did overcome the GPU hang. > I did it for our customer board and it works however it does not solve the It worked for you probably because you used the ldo bypass mode. Regards, Fabio Estevam
On Thu, Jan 16, 2014 at 1:42 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Thu, Jan 16, 2014 at 1:33 PM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > >> As I said the SabreSD case seems to be solvable adding support for the PMIC. > > Have you really tried it? I tried adding PMIC support on sabresd and > it did overcome the GPU hang. I meant 'it did not overcome the GPU hang".
On Thu, Jan 16, 2014 at 1:42 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Thu, Jan 16, 2014 at 1:33 PM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > > > As I said the SabreSD case seems to be solvable adding support for the > PMIC. > > Have you really tried it? I tried adding PMIC support on sabresd and > it did overcome the GPU hang. > > > I did it for our customer board and it works however it does not solve > the > > It worked for you probably because you used the ldo bypass mode. > Yes; I did the bypass mode.
On Thu, Jan 16, 2014 at 1:50 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: >> It worked for you probably because you used the ldo bypass mode. > > > Yes; I did the bypass mode. We currently don't do LDO bypass mode in mainline U-boot. We do it in FSL U-boot. With LDO bypass, lower VDDARM and VDDSOC voltages can be supplied as per the mx6 datasheet. I just measured with the scope and the VDDARM/SOC voltages supplied by the 3.10 FSL kernel are below the minimum for the LDO enabled case. So setting LDO bypass in U-boot 'fixes' the issue. We can implement LDO bypass after 2014.01 is out, but for this release let's just revert the VDDPU disable patch. Do you agree? Regards, Fabio Estevam
On Thu, Jan 16, 2014 at 2:01 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Thu, Jan 16, 2014 at 1:50 PM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > > >> It worked for you probably because you used the ldo bypass mode. > > > > > > Yes; I did the bypass mode. > > We currently don't do LDO bypass mode in mainline U-boot. We do it in > FSL U-boot. > > With LDO bypass, lower VDDARM and VDDSOC voltages can be supplied as > per the mx6 datasheet. > > I just measured with the scope and the VDDARM/SOC voltages supplied by > the 3.10 FSL kernel are below the minimum for the LDO enabled case. So > setting LDO bypass in U-boot 'fixes' the issue. > > We can implement LDO bypass after 2014.01 is out, but for this release > let's just revert the VDDPU disable patch. > > Do you agree? > Yes I do.
Hi Fabio, On 16/01/2014 17:01, Fabio Estevam wrote: > On Thu, Jan 16, 2014 at 1:50 PM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > >>> It worked for you probably because you used the ldo bypass mode. >> >> >> Yes; I did the bypass mode. > > We currently don't do LDO bypass mode in mainline U-boot. We do it in > FSL U-boot. > > With LDO bypass, lower VDDARM and VDDSOC voltages can be supplied as > per the mx6 datasheet. > > I just measured with the scope and the VDDARM/SOC voltages supplied by > the 3.10 FSL kernel are below the minimum for the LDO enabled case. So > setting LDO bypass in U-boot 'fixes' the issue. > > We can implement LDO bypass after 2014.01 is out, but for this release > let's just revert the VDDPU disable patch. > > Do you agree? > +1 Best regards, Stefano Babic
Le 16/01/2014 17:01, Fabio Estevam a écrit : > On Thu, Jan 16, 2014 at 1:50 PM, Otavio Salvador > <otavio@ossystems.com.br> wrote: > >>> It worked for you probably because you used the ldo bypass mode. >> >> Yes; I did the bypass mode. > We currently don't do LDO bypass mode in mainline U-boot. We do it in > FSL U-boot. > > With LDO bypass, lower VDDARM and VDDSOC voltages can be supplied as > per the mx6 datasheet. > > I just measured with the scope and the VDDARM/SOC voltages supplied by > the 3.10 FSL kernel are below the minimum for the LDO enabled case. So > setting LDO bypass in U-boot 'fixes' the issue. > > We can implement LDO bypass after 2014.01 is out, but for this release > let's just revert the VDDPU disable patch. > > Do you agree? +1 > > Regards, > > Fabio Estevam
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c index 009a644..0208cba 100644 --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -19,8 +19,6 @@ #include <asm/arch/mxc_hdmi.h> #include <asm/arch/crm_regs.h> -#define VDDPU_MASK (0x1f << 9) - enum ldo_reg { LDO_ARM, LDO_SOC, @@ -179,50 +177,11 @@ static void imx_set_wdog_powerdown(bool enable) writew(enable, &wdog2->wmcr); } -static void imx_set_vddpu_power_down(void) -{ - struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR; - struct gpc_regs *gpc = (struct gpc_regs *)GPC_BASE_ADDR; - - u32 reg; - - /* - * Disable the brown out detection since we are going to be - * disabling the LDO. - */ - reg = readl(&anatop->ana_misc2); - reg &= ~ANADIG_ANA_MISC2_REG1_BO_EN; - writel(reg, &anatop->ana_misc2); - - /* need to power down xPU in GPC before turning off PU LDO */ - reg = readl(&gpc->gpu_ctrl); - writel(reg | 0x1, &gpc->gpu_ctrl); - - reg = readl(&gpc->ctrl); - writel(reg | 0x1, &gpc->ctrl); - while (readl(&gpc->ctrl) & 0x1) - ; - - /* Mask the ANATOP brown out interrupt in the GPC. */ - reg = readl(&gpc->imr4); - reg |= 0x80000000; - writel(reg, &gpc->imr4); - - /* disable VDDPU */ - writel(VDDPU_MASK, &anatop->reg_core_clr); - - /* Clear the BO interrupt in the ANATOP. */ - reg = readl(&anatop->ana_misc1); - reg |= 0x80000000; - writel(reg, &anatop->ana_misc1); -} - int arch_cpu_init(void) { init_aips(); imx_set_wdog_powerdown(false); /* Disable PDE bit of WMCR register */ - imx_set_vddpu_power_down(); #ifdef CONFIG_APBH_DMA /* Start APBH DMA */ diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h b/arch/arm/include/asm/arch-mx6/crm_regs.h index aede126..7202073 100644 --- a/arch/arm/include/asm/arch-mx6/crm_regs.h +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h @@ -890,5 +890,4 @@ struct mxc_ccm_reg { #define BF_ANADIG_PFD_528_PFD0_FRAC(v) \ (((v) << 0) & BM_ANADIG_PFD_528_PFD0_FRAC) -#define ANADIG_ANA_MISC2_REG1_BO_EN (1 << 13) #endif /*__ARCH_ARM_MACH_MX6_CCM_REGS_H__ */ diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h b/arch/arm/include/asm/arch-mx6/imx-regs.h index 7f89865..f2ad6e9 100644 --- a/arch/arm/include/asm/arch-mx6/imx-regs.h +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h @@ -663,28 +663,5 @@ struct wdog_regs { u16 wmcr; /* Miscellaneous Control */ }; -struct gpc_regs { - u32 ctrl; /* 0x000 */ - u32 pgr; /* 0x004 */ - u32 imr1; /* 0x008 */ - u32 imr2; /* 0x00c */ - u32 imr3; /* 0x010 */ - u32 imr4; /* 0x014 */ - u32 isr1; /* 0x018 */ - u32 isr2; /* 0x01c */ - u32 isr3; /* 0x020 */ - u32 isr4; /* 0x024 */ - u32 reserved1[0x86]; - u32 gpu_ctrl; /* 0x260 */ - u32 gpu_pupscr; /* 0x264 */ - u32 gpu_pdnscr; /* 0x268 */ - u32 gpu_sr; /* 0x26c */ - u32 reserved2[0xc]; - u32 cpu_ctrl; /* 0x2a0 */ - u32 cpu_pupscr; /* 0x2a4 */ - u32 cpu_pdnscr; /* 0x2a8 */ - u32 cpu_sr; /* 0x2ac */ -}; - #endif /* __ASSEMBLER__*/ #endif /* __ASM_ARCH_MX6_IMX_REGS_H__ */
Commit 022298278 (mx6: soc: Disable VDDPU regulator) is causing kernel hang for people using FSL kernel 3.0.35 and 3.10, so revert it for now. Reported-by: Otavio Salvador <otavio@ossystems.com.br> Reported-by: Pierre Aubert <p.aubert@staubli.com> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> --- Stefano, I will provide a proper fix after 2014.01 is out, but to allow people to use mainline U-boot with FSL kernels, it would be better to revert it for now. Thanks arch/arm/cpu/armv7/mx6/soc.c | 41 -------------------------------- arch/arm/include/asm/arch-mx6/crm_regs.h | 1 - arch/arm/include/asm/arch-mx6/imx-regs.h | 23 ------------------ 3 files changed, 65 deletions(-)