[U-Boot] [PATCH 0/3] arm: tegra20/colibri_t20: early pmic rail configuration

[U-Boot] [PATCH 0/3] arm: tegra20/colibri_t20: early pmic rail configuration

[Marcel Ziswiler]

Implement early TPS6586X PMIC rail configuration setting SM0 being
VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.

While those are PMIC power-up defaults the SoC might have been reset
separately with certain rails being left at lower DVFS states which
is e.g. the case upon watchdog reset while otherwise nearly idling.

This fixes an issue of the Colibri T20 being stuck in U-Boot's SPL upon
watchdog reset (e.g. running downstream L4T Linux kernel as there
exists no mainline Tegra20 watchdog driver as of yet).

The last patch in this series is not really related but just gets rid
of a spurious MAX_I2C_RETRY define in the Colibri T20's board file.


Marcel Ziswiler (3):
  arm: tegra20: implement early pmic rail configuration
  colibri_t20: enable early pmic rail configuration
  colibri_t20: get rid of spurious MAX_I2C_RETRY define

 arch/arm/mach-tegra/tegra20/cpu.c       | 76 ++++++++++++++++++++++++++++++++-
 board/toradex/colibri_t20/colibri_t20.c |  1 -
 include/configs/colibri_t20.h           |  2 +
 3 files changed, 77 insertions(+), 2 deletions(-)

-- 
2.4.3

[U-Boot] [PATCH 1/3] arm: tegra20: implement early pmic rail configuration

[Marcel Ziswiler]

Implement early TPS6586X PMIC rail configuration setting SM0 being
VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.

While those are PMIC power-up defaults the SoC might have been reset
separately with certain rails being left at lower DVFS states which
is e.g. the case upon watchdog reset while otherwise nearly idling.

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---

 arch/arm/mach-tegra/tegra20/cpu.c | 76 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/tegra20/cpu.c b/arch/arm/mach-tegra/tegra20/cpu.c
index 67f49d7..aa05e1b 100644
--- a/arch/arm/mach-tegra/tegra20/cpu.c
+++ b/arch/arm/mach-tegra/tegra20/cpu.c
@@ -15,16 +15,64 @@
  */
 
 #include <common.h>
-#include <asm/io.h>
+#include <asm/arch/clock.h>
 #include <asm/arch/tegra.h>
 #include <asm/arch-tegra/pmc.h>
+#include <asm/arch-tegra/tegra_i2c.h>
+#include <asm/io.h>
 #include "../cpu.h"
 
+#define I2C_SEND_2_BYTES		0x0a02
+#define TPS6586X_I2C_ADDR		(0x34<<1)
+#define TPS6586X_VCC1_REG		0x20
+#define TPS6586X_SM1V1_REG		0x23
+#define TPS6586X_SM0V1_REG		0x26
+
+/* Tegra20-specific DVC init code */
+void tegra_i2c_ll_init(void)
+{
+	struct dvc_ctlr *reg = (struct dvc_ctlr *)TEGRA_DVC_BASE;
+
+	writel(DVC_CTRL_REG3_I2C_HW_SW_PROG_MASK, &reg->ctrl3);
+}
+
+void tegra_i2c_ll_write(uint offset, uint8_t data)
+{
+	struct dvc_ctlr *reg = (struct dvc_ctlr *)TEGRA_DVC_BASE;
+
+	writel(TPS6586X_I2C_ADDR, &reg->cmd_addr0);
+	writel(2, &reg->cnfg);
+
+	writel((data << 8) | (offset & 0xff), &reg->cmd_data1);
+	writel(I2C_SEND_2_BYTES, &reg->cnfg);
+}
+
 static void enable_cpu_power_rail(void)
 {
 	struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
 	u32 reg;
 
+	debug("%s entry\n", __func__);
+
+#ifdef CONFIG_TEGRA_EARLY_TPS6586X
+	tegra_i2c_ll_init();
+
+	/* Set SM0 being VDD_CORE_1.2V to 1.2 volts */
+	tegra_i2c_ll_write(TPS6586X_SM0V1_REG, 0x13);
+
+	udelay(1000);
+
+	/* Set SM1 being VDD_CPU_1.0V to 1.0 volts */
+	tegra_i2c_ll_write(TPS6586X_SM1V1_REG, 0x0b);
+
+	udelay(1000);
+
+	/* Make sure primary voltages are selected and ramped towards */
+	tegra_i2c_ll_write(TPS6586X_VCC1_REG, 0x05);
+
+	udelay(10 * 1000);
+#endif
+
 	reg = readl(&pmc->pmc_cntrl);
 	reg |= CPUPWRREQ_OE;
 	writel(reg, &pmc->pmc_cntrl);
@@ -38,8 +86,34 @@ static void enable_cpu_power_rail(void)
 	udelay(3750);
 }
 
+/* T20 requires some special clock initialization, incl. setting up DVC I2C */
+void t20_init_clocks(void)
+{
+	debug("%s entry\n", __func__);
+
+	/* Put i2c in reset and enable clocks */
+	reset_set_enable(PERIPH_ID_DVC_I2C, 1);
+	clock_set_enable(PERIPH_ID_DVC_I2C, 1);
+
+	/*
+	 * Our high-level clock routines are not available prior to
+	 * relocation. We use the low-level functions which require a
+	 * hard-coded divisor. Use CLK_M with divide by (n + 1 = 16)
+	 */
+	clock_ll_set_source_divisor(PERIPH_ID_DVC_I2C, 3, 15);
+
+	/* Give clocks time to stabilize, then take i2c out of reset */
+	udelay(1000);
+
+	reset_set_enable(PERIPH_ID_DVC_I2C, 0);
+}
+
 void start_cpu(u32 reset_vector)
 {
+	debug("%s entry, reset_vector = %x\n", __func__, reset_vector);
+
+	t20_init_clocks();
+
 	/* Enable VDD_CPU */
 	enable_cpu_power_rail();
 
-- 
2.4.3

[U-Boot] [PATCH 1/3] arm: tegra20: implement early pmic rail configuration

[Stephen Warren]

On 08/20/2015 01:52 AM, Marcel Ziswiler wrote:
> Implement early TPS6586X PMIC rail configuration setting SM0 being
> VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.
>
> While those are PMIC power-up defaults the SoC might have been reset
> separately with certain rails being left at lower DVFS states which
> is e.g. the case upon watchdog reset while otherwise nearly idling.

> diff --git a/arch/arm/mach-tegra/tegra20/cpu.c b/arch/arm/mach-tegra/tegra20/cpu.c

>   static void enable_cpu_power_rail(void)
>   {
>   	struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
>   	u32 reg;
>
> +	debug("%s entry\n", __func__);
> +
> +#ifdef CONFIG_TEGRA_EARLY_TPS6586X
> +	tegra_i2c_ll_init();
> +
> +	/* Set SM0 being VDD_CORE_1.2V to 1.2 volts */
> +	tegra_i2c_ll_write(TPS6586X_SM0V1_REG, 0x13);

Does the CORE rail get adjusted by DVFS? Hopefully if it does, it is 
never set so low that AVP operation at reset is impossible...

> +	udelay(1000);

all the delays in this patch seem very large. What drove the choice of 
the delay values?

[U-Boot] [PATCH 2/3] colibri_t20: enable early pmic rail configuration

[Marcel Ziswiler]

Enable early TPS6586X PMIC rail configuration setting SM0 being
VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.

While those are PMIC power-up defaults the SoC might have been reset
separately with certain rails being left at lower DVFS states which
is e.g. the case upon watchdog reset while otherwise nearly idling.

This fixes an issue being stuck in U-Boot's SPL upon watchdog reset
(e.g. running downstream L4T Linux kernel as there exists no mainline
Tegra20 watchdog driver as of yet).

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---

 include/configs/colibri_t20.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/colibri_t20.h b/include/configs/colibri_t20.h
index 7611fc5..124d767 100644
--- a/include/configs/colibri_t20.h
+++ b/include/configs/colibri_t20.h
@@ -13,6 +13,8 @@
 
 #define CONFIG_ARCH_MISC_INIT
 
+#define CONFIG_TEGRA_EARLY_TPS6586X
+
 /* High-level configuration options */
 #define CONFIG_TEGRA_BOARD_STRING	"Toradex Colibri T20"
 
-- 
2.4.3

[U-Boot] [PATCH 2/3] colibri_t20: enable early pmic rail configuration

[Stephen Warren]

On 08/20/2015 01:52 AM, Marcel Ziswiler wrote:
> Enable early TPS6586X PMIC rail configuration setting SM0 being
> VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.
>
> While those are PMIC power-up defaults the SoC might have been reset
> separately with certain rails being left at lower DVFS states which
> is e.g. the case upon watchdog reset while otherwise nearly idling.
>
> This fixes an issue being stuck in U-Boot's SPL upon watchdog reset
> (e.g. running downstream L4T Linux kernel as there exists no mainline
> Tegra20 watchdog driver as of yet).

Rather than enable this with yet another CONFIG_ option, perhaps we can 
put this code into a C file dedicated to the colibri_t20 board, and then 
have the common code call it (and implement a weak function that does 
nothing to satisfy the linker on other boards).

[U-Boot] [PATCH 3/3] colibri_t20: get rid of spurious MAX_I2C_RETRY define

[Marcel Ziswiler]

That MAX_I2C_RETRY define has been a copy/paste left over not actually
used anywhere in this file therefore get rid of it.

Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---

 board/toradex/colibri_t20/colibri_t20.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/board/toradex/colibri_t20/colibri_t20.c b/board/toradex/colibri_t20/colibri_t20.c
index 83e1ddc..ba80267 100644
--- a/board/toradex/colibri_t20/colibri_t20.c
+++ b/board/toradex/colibri_t20/colibri_t20.c
@@ -16,7 +16,6 @@
 #include <i2c.h>
 
 #define PMU_I2C_ADDRESS		0x34
-#define MAX_I2C_RETRY		3
 #define PMU_SUPPLYENE		0x14
 #define PMU_SUPPLYENE_SYSINEN	(1<<5)
 #define PMU_SUPPLYENE_EXITSLREQ	(1<<1)
-- 
2.4.3

[U-Boot] [PATCH 0/3] arm: tegra20/colibri_t20: early pmic rail configuration

[Stephen Warren]

On 08/20/2015 01:52 AM, Marcel Ziswiler wrote:
>
> Implement early TPS6586X PMIC rail configuration setting SM0 being
> VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.
>
> While those are PMIC power-up defaults the SoC might have been reset
> separately with certain rails being left at lower DVFS states which
> is e.g. the case upon watchdog reset while otherwise nearly idling.

Is there any guarantee that the voltage levels are high enough for the 
AVP to run correctly before the CORE rail is adjusted? It sounds to me 
like a HW design issue; the SoC reset output should reset the PMIC too.

[U-Boot] [PATCH 1/3] arm: tegra20: implement early pmic rail configuration

[Marcel Ziswiler]

On 20 Aug 2015 22:00, Stephen Warren <swarren@wwwdotorg.org> wrote:

> Does the CORE rail get adjusted by DVFS? Hopefully if it does, it is
> never set so low that AVP operation at reset is impossible...

Exactly.

> > +     udelay(1000);
>
> all the delays in this patch seem very large. What drove the choice of
> the delay values?

Three things: I2C transfers at that speed will take at least around some 3 to 4 hundred us to complete so we stay at the save side. Plus the T30 equivalent file uses the exact same delays so it can't be that wrong. My testing also showed that setting it anywhere much lower will cause reliability issues.

[U-Boot] [PATCH 1/3] arm: tegra20: implement early pmic rail configuration

[Stephen Warren]

On 08/20/2015 05:06 PM, Marcel Ziswiler wrote:
> On 20 Aug 2015 22:00, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
>  > Does the CORE rail get adjusted by DVFS? Hopefully if it does, it is
>  > never set so low that AVP operation at reset is impossible...
>
> Exactly.
>
>  > > +     udelay(1000);
>  >
>  > all the delays in this patch seem very large. What drove the choice of
>  > the delay values?
>
> Three things: I2C transfers at that speed will take at least around some
> 3 to 4 hundred us to complete so we stay at the save side.

The I2C transfers should have already synchronously completed, so there 
should be no need to wait for those. If that's not true, there's a 
serious bug that needs to be fixed.

 > Plus the T30
> equivalent file uses the exact same delays so it can't be that wrong. My
> testing also showed that setting it anywhere much lower will cause
> reliability issues.

OK, consistency with other code seems reasonable. I still think there's 
little point in such long delays though, but that could be fixed later.