[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Keerthy]

The series adds the support for hardware leveling. This needs the
kernel to be patched with hardware leveling support and the
kernel support is already in linux-next:

https://patchwork.kernel.org/project/linux-omap/list/?series=100273

Match recommended values from EMIF Tools app note:
http://www.ti.com/lit/an/sprac70/sprac70.pdf

The patch series is tested for AM437x-gp-evm DS0 and RTC+DRR mode
on linux-next in kernel.

Brad Griffis (6):
  arm: mach-omap2: am33xx: ddr: programming of EXT_PHY_CTRL1 and
    EXT_PHY_CTRL1_SHADOW
  arm: mach-omap2: am33xx: ddr: Add 1ms delay to avoid L3 error
  arm: mach-omap2: am33xx: Enable HW Leveling in the rtc+ddr path
  arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw
    leveling
  arm: mach-omap2: am33xx: ddr: update value for ext_phy_ctrl_36
  board: ti: am43xx: Enable hardware leveling

 arch/arm/mach-omap2/am33xx/board.c | 31 +++++++++++++++++++++++++++---
 arch/arm/mach-omap2/am33xx/ddr.c   | 29 ++++++++++++++++++++++++----
 board/ti/am43xx/board.c            |  2 +-
 3 files changed, 54 insertions(+), 8 deletions(-)

-- 
2.17.1

[U-Boot] [PATCH 1/6] arm: mach-omap2: am33xx: ddr: programming of EXT_PHY_CTRL1 and EXT_PHY_CTRL1_SHADOW

[Keerthy]

From: Brad Griffis <bgriffis@ti.com>

Adjust DQS skew in case where invert_clkout=1 is used.
Match recommended values from EMIF Tools app note:

http://www.ti.com/lit/an/sprac70/sprac70.pdf

Signed-off-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/mach-omap2/am33xx/ddr.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/ddr.c b/arch/arm/mach-omap2/am33xx/ddr.c
index be6f4d72cc..816d4e8e05 100644
--- a/arch/arm/mach-omap2/am33xx/ddr.c
+++ b/arch/arm/mach-omap2/am33xx/ddr.c
@@ -256,8 +256,16 @@ static void ext_phy_settings_hwlvl(const struct emif_regs *regs, int nr)
 	 * Enable hardware leveling on the EMIF.  For details about these
 	 * magic values please see the EMIF registers section of the TRM.
 	 */
-	writel(0x08020080, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_1);
-	writel(0x08020080, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_1_shdw);
+	if (regs->emif_ddr_phy_ctlr_1 & 0x00040000) {
+		/* PHY_INVERT_CLKOUT = 1 */
+		writel(0x00040100, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_1);
+		writel(0x00040100, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_1_shdw);
+	} else {
+		/* PHY_INVERT_CLKOUT = 0 */
+		writel(0x08020080, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_1);
+		writel(0x08020080, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_1_shdw);
+	}
+
 	writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_22);
 	writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_22_shdw);
 	writel(0x00600020, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_23);
-- 
2.17.1

[U-Boot] [PATCH 2/6] arm: mach-omap2: am33xx: ddr: Add 1ms delay to avoid L3 error

[Keerthy]

From: Brad Griffis <bgriffis@ti.com>

Add 1ms delay to avoid L3 timeout error during suspend resume.

Signed-off-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/mach-omap2/am33xx/ddr.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/am33xx/ddr.c b/arch/arm/mach-omap2/am33xx/ddr.c
index 816d4e8e05..5d947a68c3 100644
--- a/arch/arm/mach-omap2/am33xx/ddr.c
+++ b/arch/arm/mach-omap2/am33xx/ddr.c
@@ -138,6 +138,9 @@ void config_sdram_emif4d5(const struct emif_regs *regs, int nr)
 		/* Enable read leveling */
 		writel(0x80000000, &emif_reg[nr]->emif_rd_wr_lvl_ctl);
 
+		/* Wait 1ms because of L3 timeout error */
+		udelay(1000);
+
 		/*
 		 * Enable full read and write leveling.  Wait for read and write
 		 * leveling bit to clear RDWRLVLFULL_START bit 31
-- 
2.17.1

[U-Boot] [PATCH 3/6] arm: mach-omap2: am33xx: Enable HW Leveling in the rtc+ddr path

[Keerthy]

From: Brad Griffis <bgriffis@ti.com>

Enable HW leveling in RTC+DDR path. The mandate is to enable
HW leveling bit and then wait for 1 ms before accessing any
register.

Signed-off-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/mach-omap2/am33xx/board.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/am33xx/board.c b/arch/arm/mach-omap2/am33xx/board.c
index 62158a9592..fe7b8e1e55 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -38,6 +38,14 @@
 #include <asm/omap_musb.h>
 #include <asm/davinci_rtc.h>
 
+#define AM43XX_EMIF_BASE				0x4C000000
+#define AM43XX_SDRAM_CONFIG_OFFSET			0x8
+#define AM43XX_SDRAM_TYPE_MASK				0xE0000000
+#define AM43XX_SDRAM_TYPE_SHIFT				29
+#define AM43XX_SDRAM_TYPE_DDR3				3
+#define AM43XX_READ_WRITE_LEVELING_CTRL_OFFSET		0xDC
+#define AM43XX_RDWRLVLFULL_START			0x80000000
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int dram_init(void)
@@ -435,7 +443,7 @@ static void rtc_only(void)
 	struct prm_device_inst *prm_device =
 				(struct prm_device_inst *)PRM_DEVICE_INST;
 
-	u32 scratch1;
+	u32 scratch1, sdrc;
 	void (*resume_func)(void);
 
 	scratch1 = readl(&rtc->scratch1);
@@ -476,6 +484,26 @@ static void rtc_only(void)
 	/* Disable EMIF_DEVOFF for normal operation and to exit self-refresh */
 	writel(0, &prm_device->emif_ctrl);
 
+	/* Check EMIF4D_SDRAM_CONFIG[31:29] SDRAM_TYPE */
+	/* Only perform leveling if SDRAM_TYPE = 3 (DDR3) */
+	sdrc = readl(AM43XX_EMIF_BASE + AM43XX_SDRAM_CONFIG_OFFSET);
+
+	sdrc &= AM43XX_SDRAM_TYPE_MASK;
+	sdrc >>= AM43XX_SDRAM_TYPE_SHIFT;
+
+	if (sdrc == AM43XX_SDRAM_TYPE_DDR3) {
+		writel(AM43XX_RDWRLVLFULL_START,
+		       AM43XX_EMIF_BASE +
+		       AM43XX_READ_WRITE_LEVELING_CTRL_OFFSET);
+		mdelay(1);
+
+am43xx_wait:
+		sdrc = readl(AM43XX_EMIF_BASE +
+			     AM43XX_READ_WRITE_LEVELING_CTRL_OFFSET);
+		if (sdrc == AM43XX_RDWRLVLFULL_START)
+			goto am43xx_wait;
+	}
+
 	resume_func = (void *)readl(&rtc->scratch0);
 	if (resume_func)
 		resume_func();
-- 
2.17.1

[U-Boot] [PATCH 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Keerthy]

From: Brad Griffis <bgriffis@ti.com>

In case of RTC+DDR resume, need to restore EMIF context
before initiating hardware leveling.

Signed-off-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/mach-omap2/am33xx/board.c |  3 ---
 arch/arm/mach-omap2/am33xx/ddr.c   | 10 ++++++++++
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/board.c b/arch/arm/mach-omap2/am33xx/board.c
index fe7b8e1e55..5507348981 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -481,9 +481,6 @@ static void rtc_only(void)
 	rtc_only_prcm_init();
 	sdram_init();
 
-	/* Disable EMIF_DEVOFF for normal operation and to exit self-refresh */
-	writel(0, &prm_device->emif_ctrl);
-
 	/* Check EMIF4D_SDRAM_CONFIG[31:29] SDRAM_TYPE */
 	/* Only perform leveling if SDRAM_TYPE = 3 (DDR3) */
 	sdrc = readl(AM43XX_EMIF_BASE + AM43XX_SDRAM_CONFIG_OFFSET);
diff --git a/arch/arm/mach-omap2/am33xx/ddr.c b/arch/arm/mach-omap2/am33xx/ddr.c
index 5d947a68c3..e6e6ef8e9a 100644
--- a/arch/arm/mach-omap2/am33xx/ddr.c
+++ b/arch/arm/mach-omap2/am33xx/ddr.c
@@ -80,6 +80,9 @@ static void configure_mr(int nr, u32 cs)
  */
 void config_sdram_emif4d5(const struct emif_regs *regs, int nr)
 {
+	struct prm_device_inst *prm_device =
+			(struct prm_device_inst *)PRM_DEVICE_INST;
+
 	writel(0xA0, &emif_reg[nr]->emif_pwr_mgmt_ctrl);
 	writel(0xA0, &emif_reg[nr]->emif_pwr_mgmt_ctrl_shdw);
 	writel(regs->zq_config, &emif_reg[nr]->emif_zq_config);
@@ -126,6 +129,13 @@ void config_sdram_emif4d5(const struct emif_regs *regs, int nr)
 	writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl);
 	writel(regs->ref_ctrl, &emif_reg[nr]->emif_sdram_ref_ctrl_shdw);
 
+	/*
+	 * Disable EMIF_DEVOFF
+	 * -> Cold Boot: This is just rewriting the default register value.
+	 * -> RTC Resume: Must disable DEVOFF before leveling.
+	 */
+	writel(0, &prm_device->emif_ctrl);
+
 	/* Perform hardware leveling for DDR3 */
 	if (emif_sdram_type(regs->sdram_config) == EMIF_SDRAM_TYPE_DDR3) {
 		writel(readl(&emif_reg[nr]->emif_ddr_ext_phy_ctrl_36) |
-- 
2.17.1

[U-Boot] [PATCH 5/6] arm: mach-omap2: am33xx: ddr: update value for ext_phy_ctrl_36

[Keerthy]

From: Brad Griffis <bgriffis@ti.com>

for suspend/resume robustness

update value for ext_phy_ctrl_36 for suspend/resume robustness
with hardware leveling enabled.

Match recommended values from EMIF Tools app note:

http://www.ti.com/lit/an/sprac70/sprac70.pdf

Signed-off-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 arch/arm/mach-omap2/am33xx/ddr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/am33xx/ddr.c b/arch/arm/mach-omap2/am33xx/ddr.c
index e6e6ef8e9a..13fac2d3cd 100644
--- a/arch/arm/mach-omap2/am33xx/ddr.c
+++ b/arch/arm/mach-omap2/am33xx/ddr.c
@@ -307,8 +307,8 @@ static void ext_phy_settings_hwlvl(const struct emif_regs *regs, int nr)
 	writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_34_shdw);
 	writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_35);
 	writel(0x00000000, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_35_shdw);
-	writel(0x000000FF, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36);
-	writel(0x000000FF, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36_shdw);
+	writel(0x00000077, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36);
+	writel(0x00000077, &emif_reg[nr]->emif_ddr_ext_phy_ctrl_36_shdw);
 
 	/*
 	 * Sequence to ensure that the PHY is again in a known state after
-- 
2.17.1

[U-Boot] [PATCH 6/6] board: ti: am43xx: Enable hardware leveling

[Keerthy]

From: Brad Griffis <bgriffis@ti.com>

Remove the RDLVL_MASK, RDLVLGATE_MASK, WRLVL_MASK & enable
PHY_INVERT_CLKOUT to enable Hardware leveling for am437x
as recommended by EMIF Tools app note:

http://www.ti.com/sprac70

Signed-off-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
 board/ti/am43xx/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index 536c5b88ed..d29a22cf05 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -244,7 +244,7 @@ const struct emif_regs ddr3_emif_regs_400Mhz_production = {
 	.read_idle_ctrl			= 0x00050000,
 	.zq_config			= 0x50074BE4,
 	.temp_alert_config		= 0x0,
-	.emif_ddr_phy_ctlr_1		= 0x0E004008,
+	.emif_ddr_phy_ctlr_1		= 0x00048008,
 	.emif_ddr_ext_phy_ctrl_1	= 0x08020080,
 	.emif_ddr_ext_phy_ctrl_2	= 0x00000066,
 	.emif_ddr_ext_phy_ctrl_3	= 0x00000091,
-- 
2.17.1

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Tom Rini]

On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:

> The series adds the support for hardware leveling. This needs the
> kernel to be patched with hardware leveling support and the
> kernel support is already in linux-next:
> 
> https://patchwork.kernel.org/project/linux-omap/list/?series=100273
> 
> Match recommended values from EMIF Tools app note:
> http://www.ti.com/lit/an/sprac70/sprac70.pdf

What happens if you boot an old kernel with this series applied?  I'm a
bit worried about applying something that breaks existing kernels,
thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190413/23d2085f/attachment.sig>

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[keerthy]

On 4/13/2019 6:32 PM, Tom Rini wrote:
> On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
> 
>> The series adds the support for hardware leveling. This needs the
>> kernel to be patched with hardware leveling support and the
>> kernel support is already in linux-next:
>>
>> https://patchwork.kernel.org/project/linux-omap/list/?series=100273
>>
>> Match recommended values from EMIF Tools app note:
>> http://www.ti.com/lit/an/sprac70/sprac70.pdf
> 
> What happens if you boot an old kernel with this series applied?  I'm a
> bit worried about applying something that breaks existing kernels,
> thanks!

Hi Tom,

Deep Sleep 0 feature will fail as the corresponding hardware leveling 
patches will not be present.

Regards,
Keerthy

> 

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Tom Rini]

On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
> 
> 
> On 4/13/2019 6:32 PM, Tom Rini wrote:
> >On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
> >
> >>The series adds the support for hardware leveling. This needs the
> >>kernel to be patched with hardware leveling support and the
> >>kernel support is already in linux-next:
> >>
> >>https://patchwork.kernel.org/project/linux-omap/list/?series=100273
> >>
> >>Match recommended values from EMIF Tools app note:
> >>http://www.ti.com/lit/an/sprac70/sprac70.pdf
> >
> >What happens if you boot an old kernel with this series applied?  I'm a
> >bit worried about applying something that breaks existing kernels,
> >thanks!
> 
> Hi Tom,
> 
> Deep Sleep 0 feature will fail as the corresponding hardware leveling
> patches will not be present.

So to be clear, some new functionality will not work, but there is no
functional regression?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190414/c2c69e34/attachment.sig>

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[keerthy]

On 4/15/2019 6:35 AM, Tom Rini wrote:
> On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
>>
>>
>> On 4/13/2019 6:32 PM, Tom Rini wrote:
>>> On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
>>>
>>>> The series adds the support for hardware leveling. This needs the
>>>> kernel to be patched with hardware leveling support and the
>>>> kernel support is already in linux-next:
>>>>
>>>> https://patchwork.kernel.org/project/linux-omap/list/?series=100273
>>>>
>>>> Match recommended values from EMIF Tools app note:
>>>> http://www.ti.com/lit/an/sprac70/sprac70.pdf
>>>
>>> What happens if you boot an old kernel with this series applied?  I'm a
>>> bit worried about applying something that breaks existing kernels,
>>> thanks!
>>
>> Hi Tom,
>>
>> Deep Sleep 0 feature will fail as the corresponding hardware leveling
>> patches will not be present.
> 
> So to be clear, some new functionality will not work, but there is no
> functional regression?

Okay i got your concern. Deep sleep 0 is currently working with software 
leveling that will stop working with this patch series(hardware 
leveling) applied on older kernels. EMIF tools application note 
recommends hardware leveling over what existed previously.

Hence i posted this series. Older kernels with this patch series Deep 
sleep 0 feature will regress.

> 

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Keerthy]

On 15/04/19 7:43 AM, keerthy wrote:
> 
> 
> On 4/15/2019 6:35 AM, Tom Rini wrote:
>> On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
>>>
>>>
>>> On 4/13/2019 6:32 PM, Tom Rini wrote:
>>>> On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
>>>>
>>>>> The series adds the support for hardware leveling. This needs the
>>>>> kernel to be patched with hardware leveling support and the
>>>>> kernel support is already in linux-next:
>>>>>
>>>>> https://patchwork.kernel.org/project/linux-omap/list/?series=100273
>>>>>
>>>>> Match recommended values from EMIF Tools app note:
>>>>> http://www.ti.com/lit/an/sprac70/sprac70.pdf
>>>>
>>>> What happens if you boot an old kernel with this series applied?  I'm a
>>>> bit worried about applying something that breaks existing kernels,
>>>> thanks!
>>>
>>> Hi Tom,
>>>
>>> Deep Sleep 0 feature will fail as the corresponding hardware leveling
>>> patches will not be present.
>>
>> So to be clear, some new functionality will not work, but there is no
>> functional regression?
> 
> Okay i got your concern. Deep sleep 0 is currently working with software 
> leveling that will stop working with this patch series(hardware 
> leveling) applied on older kernels. EMIF tools application note 
> recommends hardware leveling over what existed previously.
> 
> Hence i posted this series. Older kernels with this patch series Deep 
> sleep 0 feature will regress.

Tom,

We need hardware leveling as per EMIF document. So older kernels at best 
can backport the patches here:

https://patchwork.kernel.org/patch/10882123/
https://patchwork.kernel.org/patch/10882127/

I do not see any other way to enable hardware leveling.

Tero/Dave,

Any concerns?

Regards,
Keerthy
> 
>>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Tero Kristo]

On 15/04/2019 11:56, Keerthy wrote:
> 
> 
> On 15/04/19 7:43 AM, keerthy wrote:
>>
>>
>> On 4/15/2019 6:35 AM, Tom Rini wrote:
>>> On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
>>>>
>>>>
>>>> On 4/13/2019 6:32 PM, Tom Rini wrote:
>>>>> On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
>>>>>
>>>>>> The series adds the support for hardware leveling. This needs the
>>>>>> kernel to be patched with hardware leveling support and the
>>>>>> kernel support is already in linux-next:
>>>>>>
>>>>>> https://patchwork.kernel.org/project/linux-omap/list/?series=100273
>>>>>>
>>>>>> Match recommended values from EMIF Tools app note:
>>>>>> http://www.ti.com/lit/an/sprac70/sprac70.pdf
>>>>>
>>>>> What happens if you boot an old kernel with this series applied?  
>>>>> I'm a
>>>>> bit worried about applying something that breaks existing kernels,
>>>>> thanks!
>>>>
>>>> Hi Tom,
>>>>
>>>> Deep Sleep 0 feature will fail as the corresponding hardware leveling
>>>> patches will not be present.
>>>
>>> So to be clear, some new functionality will not work, but there is no
>>> functional regression?
>>
>> Okay i got your concern. Deep sleep 0 is currently working with 
>> software leveling that will stop working with this patch 
>> series(hardware leveling) applied on older kernels. EMIF tools 
>> application note recommends hardware leveling over what existed 
>> previously.
>>
>> Hence i posted this series. Older kernels with this patch series Deep 
>> sleep 0 feature will regress.
> 
> Tom,
> 
> We need hardware leveling as per EMIF document. So older kernels at best 
> can backport the patches here:
> 
> https://patchwork.kernel.org/patch/10882123/
> https://patchwork.kernel.org/patch/10882127/
> 
> I do not see any other way to enable hardware leveling.
> 
> Tero/Dave,
> 
> Any concerns?

Well, if we are to enable the feature, I can't see how we can avoid 
conflict with older kernels. However, most of the time I would say 
people upgrade their kernel before upgrading u-boot so this should be 
fine. If we are really worried, we could maybe add the support to kernel 
first, wait some time and merge the support to u-boot after that.

-Tero

> 
> Regards,
> Keerthy
>>
>>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Tom Rini]

On Mon, Apr 15, 2019 at 12:22:22PM +0300, Tero Kristo wrote:
> On 15/04/2019 11:56, Keerthy wrote:
> >
> >
> >On 15/04/19 7:43 AM, keerthy wrote:
> >>
> >>
> >>On 4/15/2019 6:35 AM, Tom Rini wrote:
> >>>On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
> >>>>
> >>>>
> >>>>On 4/13/2019 6:32 PM, Tom Rini wrote:
> >>>>>On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
> >>>>>
> >>>>>>The series adds the support for hardware leveling. This needs the
> >>>>>>kernel to be patched with hardware leveling support and the
> >>>>>>kernel support is already in linux-next:
> >>>>>>
> >>>>>>https://patchwork.kernel.org/project/linux-omap/list/?series=100273
> >>>>>>
> >>>>>>Match recommended values from EMIF Tools app note:
> >>>>>>http://www.ti.com/lit/an/sprac70/sprac70.pdf
> >>>>>
> >>>>>What happens if you boot an old kernel with this series applied?
> >>>>>I'm a
> >>>>>bit worried about applying something that breaks existing kernels,
> >>>>>thanks!
> >>>>
> >>>>Hi Tom,
> >>>>
> >>>>Deep Sleep 0 feature will fail as the corresponding hardware leveling
> >>>>patches will not be present.
> >>>
> >>>So to be clear, some new functionality will not work, but there is no
> >>>functional regression?
> >>
> >>Okay i got your concern. Deep sleep 0 is currently working with software
> >>leveling that will stop working with this patch series(hardware
> >>leveling) applied on older kernels. EMIF tools application note
> >>recommends hardware leveling over what existed previously.
> >>
> >>Hence i posted this series. Older kernels with this patch series Deep
> >>sleep 0 feature will regress.
> >
> >Tom,
> >
> >We need hardware leveling as per EMIF document. So older kernels at best
> >can backport the patches here:
> >
> >https://patchwork.kernel.org/patch/10882123/
> >https://patchwork.kernel.org/patch/10882127/
> >
> >I do not see any other way to enable hardware leveling.
> >
> >Tero/Dave,
> >
> >Any concerns?
> 
> Well, if we are to enable the feature, I can't see how we can avoid conflict
> with older kernels. However, most of the time I would say people upgrade
> their kernel before upgrading u-boot so this should be fine. If we are
> really worried, we could maybe add the support to kernel first, wait some
> time and merge the support to u-boot after that.

I assume that as the patches are working their way through -next now,
we're also talking about older vendor tree kernels being where this did
work?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190415/ca23d129/attachment.sig>

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Keerthy]

On 15/04/19 4:58 PM, Tom Rini wrote:
> On Mon, Apr 15, 2019 at 12:22:22PM +0300, Tero Kristo wrote:
>> On 15/04/2019 11:56, Keerthy wrote:
>>>
>>>
>>> On 15/04/19 7:43 AM, keerthy wrote:
>>>>
>>>>
>>>> On 4/15/2019 6:35 AM, Tom Rini wrote:
>>>>> On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
>>>>>>
>>>>>>
>>>>>> On 4/13/2019 6:32 PM, Tom Rini wrote:
>>>>>>> On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
>>>>>>>
>>>>>>>> The series adds the support for hardware leveling. This needs the
>>>>>>>> kernel to be patched with hardware leveling support and the
>>>>>>>> kernel support is already in linux-next:
>>>>>>>>
>>>>>>>> https://patchwork.kernel.org/project/linux-omap/list/?series=100273
>>>>>>>>
>>>>>>>> Match recommended values from EMIF Tools app note:
>>>>>>>> http://www.ti.com/lit/an/sprac70/sprac70.pdf
>>>>>>>
>>>>>>> What happens if you boot an old kernel with this series applied?
>>>>>>> I'm a
>>>>>>> bit worried about applying something that breaks existing kernels,
>>>>>>> thanks!
>>>>>>
>>>>>> Hi Tom,
>>>>>>
>>>>>> Deep Sleep 0 feature will fail as the corresponding hardware leveling
>>>>>> patches will not be present.
>>>>>
>>>>> So to be clear, some new functionality will not work, but there is no
>>>>> functional regression?
>>>>
>>>> Okay i got your concern. Deep sleep 0 is currently working with software
>>>> leveling that will stop working with this patch series(hardware
>>>> leveling) applied on older kernels. EMIF tools application note
>>>> recommends hardware leveling over what existed previously.
>>>>
>>>> Hence i posted this series. Older kernels with this patch series Deep
>>>> sleep 0 feature will regress.
>>>
>>> Tom,
>>>
>>> We need hardware leveling as per EMIF document. So older kernels at best
>>> can backport the patches here:
>>>
>>> https://patchwork.kernel.org/patch/10882123/
>>> https://patchwork.kernel.org/patch/10882127/
>>>
>>> I do not see any other way to enable hardware leveling.
>>>
>>> Tero/Dave,
>>>
>>> Any concerns?
>>
>> Well, if we are to enable the feature, I can't see how we can avoid conflict
>> with older kernels. However, most of the time I would say people upgrade
>> their kernel before upgrading u-boot so this should be fine. If we are
>> really worried, we could maybe add the support to kernel first, wait some
>> time and merge the support to u-boot after that.
> 
> I assume that as the patches are working their way through -next now,
> we're also talking about older vendor tree kernels being where this did
> work?
> 

older kernels will have to port the above patches else Deep Sleep 0 will 
fail with newer u-boot with hardware leveling enabled. I assume they 
would be using older u-boot as well?

[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling

[Tom Rini]

On Mon, Apr 15, 2019 at 05:40:27PM +0530, Keerthy wrote:
> 
> 
> On 15/04/19 4:58 PM, Tom Rini wrote:
> >On Mon, Apr 15, 2019 at 12:22:22PM +0300, Tero Kristo wrote:
> >>On 15/04/2019 11:56, Keerthy wrote:
> >>>
> >>>
> >>>On 15/04/19 7:43 AM, keerthy wrote:
> >>>>
> >>>>
> >>>>On 4/15/2019 6:35 AM, Tom Rini wrote:
> >>>>>On Mon, Apr 15, 2019 at 06:19:31AM +0530, keerthy wrote:
> >>>>>>
> >>>>>>
> >>>>>>On 4/13/2019 6:32 PM, Tom Rini wrote:
> >>>>>>>On Fri, Apr 12, 2019 at 12:08:14PM +0530, Keerthy wrote:
> >>>>>>>
> >>>>>>>>The series adds the support for hardware leveling. This needs the
> >>>>>>>>kernel to be patched with hardware leveling support and the
> >>>>>>>>kernel support is already in linux-next:
> >>>>>>>>
> >>>>>>>>https://patchwork.kernel.org/project/linux-omap/list/?series=100273
> >>>>>>>>
> >>>>>>>>Match recommended values from EMIF Tools app note:
> >>>>>>>>http://www.ti.com/lit/an/sprac70/sprac70.pdf
> >>>>>>>
> >>>>>>>What happens if you boot an old kernel with this series applied?
> >>>>>>>I'm a
> >>>>>>>bit worried about applying something that breaks existing kernels,
> >>>>>>>thanks!
> >>>>>>
> >>>>>>Hi Tom,
> >>>>>>
> >>>>>>Deep Sleep 0 feature will fail as the corresponding hardware leveling
> >>>>>>patches will not be present.
> >>>>>
> >>>>>So to be clear, some new functionality will not work, but there is no
> >>>>>functional regression?
> >>>>
> >>>>Okay i got your concern. Deep sleep 0 is currently working with software
> >>>>leveling that will stop working with this patch series(hardware
> >>>>leveling) applied on older kernels. EMIF tools application note
> >>>>recommends hardware leveling over what existed previously.
> >>>>
> >>>>Hence i posted this series. Older kernels with this patch series Deep
> >>>>sleep 0 feature will regress.
> >>>
> >>>Tom,
> >>>
> >>>We need hardware leveling as per EMIF document. So older kernels at best
> >>>can backport the patches here:
> >>>
> >>>https://patchwork.kernel.org/patch/10882123/
> >>>https://patchwork.kernel.org/patch/10882127/
> >>>
> >>>I do not see any other way to enable hardware leveling.
> >>>
> >>>Tero/Dave,
> >>>
> >>>Any concerns?
> >>
> >>Well, if we are to enable the feature, I can't see how we can avoid conflict
> >>with older kernels. However, most of the time I would say people upgrade
> >>their kernel before upgrading u-boot so this should be fine. If we are
> >>really worried, we could maybe add the support to kernel first, wait some
> >>time and merge the support to u-boot after that.
> >
> >I assume that as the patches are working their way through -next now,
> >we're also talking about older vendor tree kernels being where this did
> >work?
> >
> 
> older kernels will have to port the above patches else Deep Sleep 0 will
> fail with newer u-boot with hardware leveling enabled. I assume they would
> be using older u-boot as well?

Yes, it sounds like there's reasonable support matrices here, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190415/befec6d6/attachment.sig>

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Tom Rini]

On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:

> From: Brad Griffis <bgriffis@ti.com>
> 
> In case of RTC+DDR resume, need to restore EMIF context
> before initiating hardware leveling.
> 
> Signed-off-by: Brad Griffis <bgriffis@ti.com>
> Signed-off-by: Keerthy <j-keerthy@ti.com>

This part off the series blows up the AM335x and older SoCs that also
re-use this code, please build test for all the "am33xx" boards and fix
the problems that arise, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190426/2e79d0c4/attachment.sig>

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Lokesh Vutla]

On 26/04/19 4:46 PM, Tom Rini wrote:
> On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> 
>> From: Brad Griffis <bgriffis@ti.com>
>>
>> In case of RTC+DDR resume, need to restore EMIF context
>> before initiating hardware leveling.
>>
>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
> 
> This part off the series blows up the AM335x and older SoCs that also
> re-use this code, please build test for all the "am33xx" boards and fix
> the problems that arise, thanks!

We should b able to enable TINY_FIT support and save some space. Patches are
already available in internal tree. Keerthy can you post them along with this
series?

Thanks and regards,
Lokesh

> 

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Tom Rini]

On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
> 
> 
> On 26/04/19 4:46 PM, Tom Rini wrote:
> > On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> > 
> >> From: Brad Griffis <bgriffis@ti.com>
> >>
> >> In case of RTC+DDR resume, need to restore EMIF context
> >> before initiating hardware leveling.
> >>
> >> Signed-off-by: Brad Griffis <bgriffis@ti.com>
> >> Signed-off-by: Keerthy <j-keerthy@ti.com>
> > 
> > This part off the series blows up the AM335x and older SoCs that also
> > re-use this code, please build test for all the "am33xx" boards and fix
> > the problems that arise, thanks!
> 
> We should b able to enable TINY_FIT support and save some space. Patches are
> already available in internal tree. Keerthy can you post them along with this
> series?

That's a good point but I wasn't clear enough sorry.  They all fail to
compile due to undefined new macros.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190426/49d12437/attachment.sig>

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Keerthy]

On 26/04/19 4:46 PM, Tom Rini wrote:
> On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> 
>> From: Brad Griffis <bgriffis@ti.com>
>>
>> In case of RTC+DDR resume, need to restore EMIF context
>> before initiating hardware leveling.
>>
>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
> 
> This part off the series blows up the AM335x and older SoCs that also
> re-use this code, please build test for all the "am33xx" boards and fix
> the problems that arise, thanks!

Sorry Tom. I should have caught that myself. I will build test the other 
relevant configs.

Thanks,
Keerthy
> 

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Keerthy]

On 26/04/19 5:23 PM, Lokesh Vutla wrote:
> 
> 
> On 26/04/19 4:46 PM, Tom Rini wrote:
>> On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
>>
>>> From: Brad Griffis <bgriffis@ti.com>
>>>
>>> In case of RTC+DDR resume, need to restore EMIF context
>>> before initiating hardware leveling.
>>>
>>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>
>> This part off the series blows up the AM335x and older SoCs that also
>> re-use this code, please build test for all the "am33xx" boards and fix
>> the problems that arise, thanks!
> 
> We should b able to enable TINY_FIT support and save some space. Patches are
> already available in internal tree. Keerthy can you post them along with this
> series?

Lokesh,

What Tom means here is that there is build break on am335x due to usage 
of a am43 specific struct variable in am3/4 common code path. I have 
added #define checks and all the builds for am335x are fine. I will boot 
test on beaglebone black and am335x_evm on monday and post the v2 of 
this patch. Tiny config series can come separately and not as part of this.

Regards,
Keerthy
> 
> Thanks and regards,
> Lokesh
> 
>>

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Keerthy]

On 26/04/19 6:25 PM, Tom Rini wrote:
> On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
>>
>>
>> On 26/04/19 4:46 PM, Tom Rini wrote:
>>> On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
>>>
>>>> From: Brad Griffis <bgriffis@ti.com>
>>>>
>>>> In case of RTC+DDR resume, need to restore EMIF context
>>>> before initiating hardware leveling.
>>>>
>>>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>>
>>> This part off the series blows up the AM335x and older SoCs that also
>>> re-use this code, please build test for all the "am33xx" boards and fix
>>> the problems that arise, thanks!
>>
>> We should b able to enable TINY_FIT support and save some space. Patches are
>> already available in internal tree. Keerthy can you post them along with this
>> series?
> 
> That's a good point but I wasn't clear enough sorry.  They all fail to
> compile due to undefined new macros.

Tom,

I have fixed with having am43 #ifdef for this particular patch.
I built omap3/omap4 and am335x defconfis and they are building fine.
I will boot test at least on am335x_evm and am335x_beagleboneblack 
before posting v2. Is it okay if i post v2 of this patch alone?

REgards,
Keerthy

> 

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Tom Rini]

On Fri, Apr 26, 2019 at 10:14:40PM +0530, Keerthy wrote:
> 
> 
> On 26/04/19 6:25 PM, Tom Rini wrote:
> >On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
> >>
> >>
> >>On 26/04/19 4:46 PM, Tom Rini wrote:
> >>>On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
> >>>
> >>>>From: Brad Griffis <bgriffis@ti.com>
> >>>>
> >>>>In case of RTC+DDR resume, need to restore EMIF context
> >>>>before initiating hardware leveling.
> >>>>
> >>>>Signed-off-by: Brad Griffis <bgriffis@ti.com>
> >>>>Signed-off-by: Keerthy <j-keerthy@ti.com>
> >>>
> >>>This part off the series blows up the AM335x and older SoCs that also
> >>>re-use this code, please build test for all the "am33xx" boards and fix
> >>>the problems that arise, thanks!
> >>
> >>We should b able to enable TINY_FIT support and save some space. Patches are
> >>already available in internal tree. Keerthy can you post them along with this
> >>series?
> >
> >That's a good point but I wasn't clear enough sorry.  They all fail to
> >compile due to undefined new macros.
> 
> Tom,
> 
> I have fixed with having am43 #ifdef for this particular patch.
> I built omap3/omap4 and am335x defconfis and they are building fine.
> I will boot test at least on am335x_evm and am335x_beagleboneblack before
> posting v2. Is it okay if i post v2 of this patch alone?

Can you repost the whole series please?  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190426/8c1f0bb0/attachment.sig>

[U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling

[Keerthy]

On 26/04/19 10:16 PM, Tom Rini wrote:
> On Fri, Apr 26, 2019 at 10:14:40PM +0530, Keerthy wrote:
>>
>>
>> On 26/04/19 6:25 PM, Tom Rini wrote:
>>> On Fri, Apr 26, 2019 at 05:23:28PM +0530, Lokesh Vutla wrote:
>>>>
>>>>
>>>> On 26/04/19 4:46 PM, Tom Rini wrote:
>>>>> On Fri, Apr 12, 2019 at 12:08:18PM +0530, Keerthy wrote:
>>>>>
>>>>>> From: Brad Griffis <bgriffis@ti.com>
>>>>>>
>>>>>> In case of RTC+DDR resume, need to restore EMIF context
>>>>>> before initiating hardware leveling.
>>>>>>
>>>>>> Signed-off-by: Brad Griffis <bgriffis@ti.com>
>>>>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>>>>
>>>>> This part off the series blows up the AM335x and older SoCs that also
>>>>> re-use this code, please build test for all the "am33xx" boards and fix
>>>>> the problems that arise, thanks!
>>>>
>>>> We should b able to enable TINY_FIT support and save some space. Patches are
>>>> already available in internal tree. Keerthy can you post them along with this
>>>> series?
>>>
>>> That's a good point but I wasn't clear enough sorry.  They all fail to
>>> compile due to undefined new macros.
>>
>> Tom,
>>
>> I have fixed with having am43 #ifdef for this particular patch.
>> I built omap3/omap4 and am335x defconfis and they are building fine.
>> I will boot test at least on am335x_evm and am335x_beagleboneblack before
>> posting v2. Is it okay if i post v2 of this patch alone?
> 
> Can you repost the whole series please?  Thanks!

Sure. I will repost the entire series.

Regards,
Keerthy
>