| Message ID | 1388076695-28174-6-git-send-email-festevam@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | Stefano Babic |
| Headers | show |
On 26/12/2013 17:51, Fabio Estevam wrote: > From: Fabio Estevam <fabio.estevam@freescale.com> > > As U-boot does not use GPU/VPU peripherals, shutdown the VDDPU regulator > in order to save power. > > Signed-off-by: Anson Huang <b20788@freescale.com> > Signed-off-by: Jason Liu <r64343@freescale.com> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic
Hello, On Thu, Dec 26, 2013 at 2:51 PM, Fabio Estevam <festevam@gmail.com> wrote: > From: Fabio Estevam <fabio.estevam@freescale.com> > > As U-boot does not use GPU/VPU peripherals, shutdown the VDDPU regulator > in order to save power. > > Signed-off-by: Anson Huang <b20788@freescale.com> > Signed-off-by: Jason Liu <r64343@freescale.com> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer board; reverting this makes this to work again. It freezes when loading Vivante module. Can someone reproduce this freeze?
On Thu, Jan 9, 2014 at 3:50 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer board; > reverting this makes this to work again. It freezes when loading Vivante > module. VDDPU is needed for using the GPU, so the kernel should turn on the VDDPU regulator. Looks like you are getting a kernel bug. Regards, Fabio Estevam
On Thu, Jan 9, 2014 at 5:06 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Thu, Jan 9, 2014 at 3:50 PM, Otavio Salvador <otavio@ossystems.com.br> > wrote: > > > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer board; > > reverting this makes this to work again. It freezes when loading Vivante > > module. > > VDDPU is needed for using the GPU, so the kernel should turn on the > VDDPU regulator. > > Looks like you are getting a kernel bug. > It might be but shouldn't we delay this patch for now?
On Thu, Jan 9, 2014 at 5:11 PM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> It might be but shouldn't we delay this patch for now?
I don't think so.
Please post your dts file. Most likely you are using
pu-supply = <&pu_dummy>;
where you should be using the internal vddpu instead.
Also, please post your kernel log and make sure vddpu is being turned on.
Regards,
Fabio Estevam
On Thu, Jan 9, 2014 at 5:13 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Thu, Jan 9, 2014 at 5:11 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > >> It might be but shouldn't we delay this patch for now? > > I don't think so. > > Please post your dts file. Most likely you are using > > pu-supply = <&pu_dummy>; > > where you should be using the internal vddpu instead. > > Also, please post your kernel log and make sure vddpu is being turned on. Please try this on your dts file: pu-supply = <®_pu>; Regards, Fabio Estevam
On Thu, Jan 9, 2014 at 5:30 PM, Fabio Estevam <festevam@gmail.com> wrote: > On Thu, Jan 9, 2014 at 5:13 PM, Fabio Estevam <festevam@gmail.com> wrote: > > On Thu, Jan 9, 2014 at 5:11 PM, Otavio Salvador <otavio@ossystems.com.br> > wrote: > > > >> It might be but shouldn't we delay this patch for now? > > > > I don't think so. > > > > Please post your dts file. Most likely you are using > > > > pu-supply = <&pu_dummy>; > > > > where you should be using the internal vddpu instead. > > > > Also, please post your kernel log and make sure vddpu is being turned on. > > Please try this on your dts file: > pu-supply = <®_pu>; > Mine dts has: &gpu { pu-supply = <®_pu>; }; The bootlog is at: http://privatepaste.com/download/104a504b26
On Thu, Jan 9, 2014 at 5:39 PM, Otavio Salvador <otavio@ossystems.com.br> wrote: > Mine dts has: > > > &gpu { > pu-supply = <®_pu>; > }; > > The bootlog is at: > > http://privatepaste.com/download/104a504b26 According to your log: vdd1p1: 800 <--> 1375 mV at 1125 mV vdd3p0: 2800 <--> 3150 mV at 3000 mV vdd2p5: 2000 <--> 2750 mV at 2425 mV cpu: 725 <--> 1450 mV at 1100 mV vddpu: 725 <--> 1450 mV cpu regulator is at 1.1V, which is below the spec for 800MHz, so this is an issue. vddpu is still turned off. Hard to tell where the problem is without looking at your dts file. Anyway, we are getting off topic on the U-boot list now :-) Regards, Fabio Estevam
Hi Otavio, On 09/01/2014 20:11, Otavio Salvador wrote: > > > > On Thu, Jan 9, 2014 at 5:06 PM, Fabio Estevam <festevam@gmail.com > <mailto:festevam@gmail.com>> wrote: > > On Thu, Jan 9, 2014 at 3:50 PM, Otavio Salvador > <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote: > > > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer > board; > > reverting this makes this to work again. It freezes when loading > Vivante > > module. > > VDDPU is needed for using the GPU, so the kernel should turn on the > VDDPU regulator. > > Looks like you are getting a kernel bug. > > > It might be but shouldn't we delay this patch for now? Now or later it does not change. The correct behavior is done with the patch, and the kernel must turn power on. If it does not, the patch is needed for the kernel, not here. Stefano
Hello, On Thu, Jan 9, 2014 at 7:31 PM, Stefano Babic <sbabic@denx.de> wrote: > > On 09/01/2014 20:11, Otavio Salvador wrote: > >> On Thu, Jan 9, 2014 at 5:06 PM, Fabio Estevam <festevam@gmail.com >> <mailto:festevam@gmail.com>> wrote: >> >> On Thu, Jan 9, 2014 at 3:50 PM, Otavio Salvador >> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote: >> >> > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer >> board; >> > reverting this makes this to work again. It freezes when loading >> Vivante >> > module. >> >> VDDPU is needed for using the GPU, so the kernel should turn on the >> VDDPU regulator. >> >> Looks like you are getting a kernel bug. >> >> It might be but shouldn't we delay this patch for now? >> > > Now or later it does not change. The correct behavior is done with the > patch, and the kernel must turn power on. If it does not, the patch is > needed for the kernel, not here. I've been debugging to make 3.10 to work with this patch, but without success... I think this patch should be reverted and be added back to 2014.04 release so we have more time to debug this.
Hi Otavio, hi Fabio, On 15/01/2014 18:12, Otavio Salvador wrote: > > I've been debugging to make 3.10 to work with this patch, but without > success... > > I think this patch should be reverted and be added back to 2014.04 > release so we have more time to debug this. > Generally, I disagree to fix an issue in U-Boot when it is clear that this should be fixed in another component (in our case, the FSL-3.10 kernel). A patch should be revert if it is buggy - but this patch does the work and generally U-Boot should not activate what it does not need. I understand Otavio's reasons to avoid that users by taking the official releases for U-Boot and FSL-3.10 will get a not working system. But anyway, IMHO the fix should flow into FSL-3.10 and not here. Best regards, Stefano Babic
=Hello, Otavio Salvador wrote > > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer board; > reverting this makes this to work again. It freezes when loading Vivante > module. > > Can someone reproduce this freeze? The kernel 3.0.35 freezes also on the SabreSD platform with this commit. Best regards -- View this message in context: http://u-boot.10912.n7.nabble.com/PATCH-v2-1-6-mx6-soc-Staticize-set-vddsoc-tp170344p171610.html Sent from the U-Boot mailing list archive at Nabble.com.
Hi Pierre, On Thu, Jan 16, 2014 at 6:40 AM, Pierre Aubert <p.aubert@staubli.com> wrote: > =Hello, > > > Otavio Salvador wrote >> >> It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer board; >> reverting this makes this to work again. It freezes when loading Vivante >> module. >> >> Can someone reproduce this freeze? > > The kernel 3.0.35 freezes also on the SabreSD platform with this commit. What is the output of "md.l 0x20C8140 1' on your board? What is the mx6 variant (solo, dl, q) and silicon version? Regards, Fabio Estevam
Hi Fabio, Le 16/01/2014 12:19, Fabio Estevam a écrit : > Hi Pierre, > > On Thu, Jan 16, 2014 at 6:40 AM, Pierre Aubert <p.aubert@staubli.com> wrote: >> =Hello, >> >> >> Otavio Salvador wrote >>> It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer board; >>> reverting this makes this to work again. It freezes when loading Vivante >>> module. >>> >>> Can someone reproduce this freeze? >> The kernel 3.0.35 freezes also on the SabreSD platform with this commit. > What is the output of "md.l 0x20C8140 1' on your board? => md.l 0x20C8140 1 020c8140: 004c0010 > > What is the mx6 variant (solo, dl, q) and silicon version? I'm using a SabreSDP with a iMX6DL : U-Boot 2014.01-rc3-00077-g751be3b (Jan 16 2014 - 08:27:51) CPU: Freescale i.MX6DL rev1.1 at 792 MHz Reset cause: POR Board: MX6-SabreSD DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 No panel detected: default to Hannstar-XGA Display: Hannstar-XGA (1024x768) In: serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 > > Regards, > > Fabio Estevam Best regards
diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c index 0208cba..b944edd 100644 --- a/arch/arm/cpu/armv7/mx6/soc.c +++ b/arch/arm/cpu/armv7/mx6/soc.c @@ -19,6 +19,8 @@ #include <asm/arch/mxc_hdmi.h> #include <asm/arch/crm_regs.h> +#define VDDPU_MASK (0x1f << 9) + enum ldo_reg { LDO_ARM, LDO_SOC, @@ -177,11 +179,50 @@ 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 7202073..aede126 100644 --- a/arch/arm/include/asm/arch-mx6/crm_regs.h +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h @@ -890,4 +890,5 @@ 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 7ef7152..fb0c4c7 100644 --- a/arch/arm/include/asm/arch-mx6/imx-regs.h +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h @@ -659,5 +659,28 @@ 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__ */