[PATCH 0/2] ARM: OMAP2+: AM43x: Support DDR HW leveling suspend/resume

[PATCH 0/2] ARM: OMAP2+: AM43x: Support DDR HW leveling suspend/resume

[Dave Gerlach]

Hi,
These patches add support for resuming am437x SoCs from suspend to mem when
using hardware leveling (as configured by u-boot). This series has no effect
on boards not currently using hardware leveling (am437x-gp-evm, am437x-sk-evm)
but is required for any board that is using it (am437x-idk-evm) for resume to
work at all, so this increases support for boards without affecting those that
currently work.

This series adds a ti_emif_run_hw_leveling call that is loaded to SRAM so that
it can be run from low-level PM code during the resume path that attempts to
trigger the HW leveling sequence just as was done in u-boot after all previously
register values have been restored, which leads to a fully restored DDR
configuration.

These patches have been tested on am437x-gp-evm and am437x-sk-evm and showed
no noticeable change in behavior (including resume time) and also tested on
am437x-idk-evm which showed a working suspend to mem followed by resume, which
did not previously work.

Regards,
Dave

Dave Gerlach (2):
  memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware
    leveling
  ARM: OMAP2+: sleep43xx: Run EMIF HW leveling on resume path

 arch/arm/mach-omap2/sleep43xx.S  |  3 +++
 drivers/memory/emif.h            |  4 ++++
 drivers/memory/ti-emif-pm.c      |  3 +++
 drivers/memory/ti-emif-sram-pm.S | 41 ++++++++++++++++++++++++++++++++
 include/linux/ti-emif-sram.h     |  3 +++
 5 files changed, 54 insertions(+)

-- 
2.20.1

[PATCH 0/2] ARM: OMAP2+: AM43x: Support DDR HW leveling suspend/resume

[Dave Gerlach]

Hi,
These patches add support for resuming am437x SoCs from suspend to mem when
using hardware leveling (as configured by u-boot). This series has no effect
on boards not currently using hardware leveling (am437x-gp-evm, am437x-sk-evm)
but is required for any board that is using it (am437x-idk-evm) for resume to
work at all, so this increases support for boards without affecting those that
currently work.

This series adds a ti_emif_run_hw_leveling call that is loaded to SRAM so that
it can be run from low-level PM code during the resume path that attempts to
trigger the HW leveling sequence just as was done in u-boot after all previously
register values have been restored, which leads to a fully restored DDR
configuration.

These patches have been tested on am437x-gp-evm and am437x-sk-evm and showed
no noticeable change in behavior (including resume time) and also tested on
am437x-idk-evm which showed a working suspend to mem followed by resume, which
did not previously work.

Regards,
Dave

Dave Gerlach (2):
  memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware
    leveling
  ARM: OMAP2+: sleep43xx: Run EMIF HW leveling on resume path

 arch/arm/mach-omap2/sleep43xx.S  |  3 +++
 drivers/memory/emif.h            |  4 ++++
 drivers/memory/ti-emif-pm.c      |  3 +++
 drivers/memory/ti-emif-sram-pm.S | 41 ++++++++++++++++++++++++++++++++
 include/linux/ti-emif-sram.h     |  3 +++
 5 files changed, 54 insertions(+)

-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Dave Gerlach]

In certain situations, such as when returning from low power modes, the
EMIF must re-run hardware leveling to properly restore DDR3 access.

This is accomplished by introducing a new ti-emif-sram-pm call,
ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
the full write and read leveling processes.

Suggested-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 drivers/memory/emif.h            |  4 ++++
 drivers/memory/ti-emif-pm.c      |  3 +++
 drivers/memory/ti-emif-sram-pm.S | 41 ++++++++++++++++++++++++++++++++
 include/linux/ti-emif-sram.h     |  3 +++
 4 files changed, 51 insertions(+)

diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h
index 9e9f8037955d..6b71fadb3cfa 100644
--- a/drivers/memory/emif.h
+++ b/drivers/memory/emif.h
@@ -537,6 +537,9 @@
 #define MCONNID_SHIFT					0
 #define MCONNID_MASK					(0xff << 0)
 
+/* READ_WRITE_LEVELING_CONTROL */
+#define RDWRLVLFULL_START				0x80000000
+
 /* DDR_PHY_CTRL_1 - EMIF4D */
 #define DLL_SLAVE_DLY_CTRL_SHIFT_4D			4
 #define DLL_SLAVE_DLY_CTRL_MASK_4D			(0xFF << 4)
@@ -598,6 +601,7 @@ extern struct emif_regs_amx3 ti_emif_regs_amx3;
 
 void ti_emif_save_context(void);
 void ti_emif_restore_context(void);
+void ti_emif_run_hw_leveling(void);
 void ti_emif_enter_sr(void);
 void ti_emif_exit_sr(void);
 void ti_emif_abort_sr(void);
diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
index 2250d03ea17f..ab07aa163138 100644
--- a/drivers/memory/ti-emif-pm.c
+++ b/drivers/memory/ti-emif-pm.c
@@ -138,6 +138,9 @@ static int ti_emif_alloc_sram(struct device *dev,
 	emif_data->pm_functions.exit_sr =
 		sram_resume_address(emif_data,
 				    (unsigned long)ti_emif_exit_sr);
+	emif_data->pm_functions.run_hw_leveling =
+		sram_resume_address(emif_data,
+				    (unsigned long)ti_emif_run_hw_leveling);
 
 	emif_data->pm_data.regs_virt =
 		(struct emif_regs_amx3 *)emif_data->ti_emif_sram_data_virt;
diff --git a/drivers/memory/ti-emif-sram-pm.S b/drivers/memory/ti-emif-sram-pm.S
index a5369181e5c2..d75ae18efa7d 100644
--- a/drivers/memory/ti-emif-sram-pm.S
+++ b/drivers/memory/ti-emif-sram-pm.S
@@ -27,6 +27,7 @@
 #define EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK		0x0700
 
 #define EMIF_SDCFG_TYPE_DDR2				0x2 << SDRAM_TYPE_SHIFT
+#define EMIF_SDCFG_TYPE_DDR3				0x3 << SDRAM_TYPE_SHIFT
 #define EMIF_STATUS_READY				0x4
 
 #define AM43XX_EMIF_PHY_CTRL_REG_COUNT                  0x120
@@ -244,6 +245,46 @@ emif_skip_restore_extra_regs:
 	mov	pc, lr
 ENDPROC(ti_emif_restore_context)
 
+/*
+ * void ti_emif_run_hw_leveling(void)
+ *
+ * Used during resume to run hardware leveling again and restore the
+ * configuration of the EMIF PHY, only for DDR3.
+ */
+ENTRY(ti_emif_run_hw_leveling)
+	adr	r4, ti_emif_pm_sram_data
+	ldr	r0, [r4, #EMIF_PM_BASE_ADDR_PHYS_OFFSET]
+
+	ldr	r3, [r0, #EMIF_READ_WRITE_LEVELING_CONTROL]
+	orr	r3, r3, #RDWRLVLFULL_START
+	ldr	r2, [r0, #EMIF_SDRAM_CONFIG]
+	and	r2, r2, #SDRAM_TYPE_MASK
+	cmp	r2, #EMIF_SDCFG_TYPE_DDR3
+	bne	skip_hwlvl
+
+	str	r3, [r0, #EMIF_READ_WRITE_LEVELING_CONTROL]
+
+	/*
+	 * If EMIF registers are touched during initial stage of HW
+	 * leveling sequence there will be an L3 NOC timeout error issued
+	 * as the EMIF will not respond, which is not fatal, but it is
+	 * avoidable. This small wait loop is enough time for this condition
+	 * to clear, even at worst case of CPU running at max speed of 1Ghz.
+	 */
+	mov	r2, #0x2000
+1:
+	subs	r2, r2, #0x1
+	bne	1b
+
+	/* Bit clears when operation is complete */
+2:	ldr     r1, [r0, #EMIF_READ_WRITE_LEVELING_CONTROL]
+	tst     r1, #RDWRLVLFULL_START
+	bne     2b
+
+skip_hwlvl:
+	mov	pc, lr
+ENDPROC(ti_emif_run_hw_leveling)
+
 /*
  * void ti_emif_enter_sr(void)
  *
diff --git a/include/linux/ti-emif-sram.h b/include/linux/ti-emif-sram.h
index 53604b087f2c..2fc854155c27 100644
--- a/include/linux/ti-emif-sram.h
+++ b/include/linux/ti-emif-sram.h
@@ -55,6 +55,7 @@ struct ti_emif_pm_data {
 struct ti_emif_pm_functions {
 	u32 save_context;
 	u32 restore_context;
+	u32 run_hw_leveling;
 	u32 enter_sr;
 	u32 exit_sr;
 	u32 abort_sr;
@@ -126,6 +127,8 @@ static inline void ti_emif_asm_offsets(void)
 	       offsetof(struct ti_emif_pm_functions, save_context));
 	DEFINE(EMIF_PM_RESTORE_CONTEXT_OFFSET,
 	       offsetof(struct ti_emif_pm_functions, restore_context));
+	DEFINE(EMIF_PM_RUN_HW_LEVELING,
+	       offsetof(struct ti_emif_pm_functions, run_hw_leveling));
 	DEFINE(EMIF_PM_ENTER_SR_OFFSET,
 	       offsetof(struct ti_emif_pm_functions, enter_sr));
 	DEFINE(EMIF_PM_EXIT_SR_OFFSET,
-- 
2.20.1

[PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Dave Gerlach]

In certain situations, such as when returning from low power modes, the
EMIF must re-run hardware leveling to properly restore DDR3 access.

This is accomplished by introducing a new ti-emif-sram-pm call,
ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
the full write and read leveling processes.

Suggested-by: Brad Griffis <bgriffis@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 drivers/memory/emif.h            |  4 ++++
 drivers/memory/ti-emif-pm.c      |  3 +++
 drivers/memory/ti-emif-sram-pm.S | 41 ++++++++++++++++++++++++++++++++
 include/linux/ti-emif-sram.h     |  3 +++
 4 files changed, 51 insertions(+)

diff --git a/drivers/memory/emif.h b/drivers/memory/emif.h
index 9e9f8037955d..6b71fadb3cfa 100644
--- a/drivers/memory/emif.h
+++ b/drivers/memory/emif.h
@@ -537,6 +537,9 @@
 #define MCONNID_SHIFT					0
 #define MCONNID_MASK					(0xff << 0)
 
+/* READ_WRITE_LEVELING_CONTROL */
+#define RDWRLVLFULL_START				0x80000000
+
 /* DDR_PHY_CTRL_1 - EMIF4D */
 #define DLL_SLAVE_DLY_CTRL_SHIFT_4D			4
 #define DLL_SLAVE_DLY_CTRL_MASK_4D			(0xFF << 4)
@@ -598,6 +601,7 @@ extern struct emif_regs_amx3 ti_emif_regs_amx3;
 
 void ti_emif_save_context(void);
 void ti_emif_restore_context(void);
+void ti_emif_run_hw_leveling(void);
 void ti_emif_enter_sr(void);
 void ti_emif_exit_sr(void);
 void ti_emif_abort_sr(void);
diff --git a/drivers/memory/ti-emif-pm.c b/drivers/memory/ti-emif-pm.c
index 2250d03ea17f..ab07aa163138 100644
--- a/drivers/memory/ti-emif-pm.c
+++ b/drivers/memory/ti-emif-pm.c
@@ -138,6 +138,9 @@ static int ti_emif_alloc_sram(struct device *dev,
 	emif_data->pm_functions.exit_sr =
 		sram_resume_address(emif_data,
 				    (unsigned long)ti_emif_exit_sr);
+	emif_data->pm_functions.run_hw_leveling =
+		sram_resume_address(emif_data,
+				    (unsigned long)ti_emif_run_hw_leveling);
 
 	emif_data->pm_data.regs_virt =
 		(struct emif_regs_amx3 *)emif_data->ti_emif_sram_data_virt;
diff --git a/drivers/memory/ti-emif-sram-pm.S b/drivers/memory/ti-emif-sram-pm.S
index a5369181e5c2..d75ae18efa7d 100644
--- a/drivers/memory/ti-emif-sram-pm.S
+++ b/drivers/memory/ti-emif-sram-pm.S
@@ -27,6 +27,7 @@
 #define EMIF_POWER_MGMT_SELF_REFRESH_MODE_MASK		0x0700
 
 #define EMIF_SDCFG_TYPE_DDR2				0x2 << SDRAM_TYPE_SHIFT
+#define EMIF_SDCFG_TYPE_DDR3				0x3 << SDRAM_TYPE_SHIFT
 #define EMIF_STATUS_READY				0x4
 
 #define AM43XX_EMIF_PHY_CTRL_REG_COUNT                  0x120
@@ -244,6 +245,46 @@ emif_skip_restore_extra_regs:
 	mov	pc, lr
 ENDPROC(ti_emif_restore_context)
 
+/*
+ * void ti_emif_run_hw_leveling(void)
+ *
+ * Used during resume to run hardware leveling again and restore the
+ * configuration of the EMIF PHY, only for DDR3.
+ */
+ENTRY(ti_emif_run_hw_leveling)
+	adr	r4, ti_emif_pm_sram_data
+	ldr	r0, [r4, #EMIF_PM_BASE_ADDR_PHYS_OFFSET]
+
+	ldr	r3, [r0, #EMIF_READ_WRITE_LEVELING_CONTROL]
+	orr	r3, r3, #RDWRLVLFULL_START
+	ldr	r2, [r0, #EMIF_SDRAM_CONFIG]
+	and	r2, r2, #SDRAM_TYPE_MASK
+	cmp	r2, #EMIF_SDCFG_TYPE_DDR3
+	bne	skip_hwlvl
+
+	str	r3, [r0, #EMIF_READ_WRITE_LEVELING_CONTROL]
+
+	/*
+	 * If EMIF registers are touched during initial stage of HW
+	 * leveling sequence there will be an L3 NOC timeout error issued
+	 * as the EMIF will not respond, which is not fatal, but it is
+	 * avoidable. This small wait loop is enough time for this condition
+	 * to clear, even at worst case of CPU running at max speed of 1Ghz.
+	 */
+	mov	r2, #0x2000
+1:
+	subs	r2, r2, #0x1
+	bne	1b
+
+	/* Bit clears when operation is complete */
+2:	ldr     r1, [r0, #EMIF_READ_WRITE_LEVELING_CONTROL]
+	tst     r1, #RDWRLVLFULL_START
+	bne     2b
+
+skip_hwlvl:
+	mov	pc, lr
+ENDPROC(ti_emif_run_hw_leveling)
+
 /*
  * void ti_emif_enter_sr(void)
  *
diff --git a/include/linux/ti-emif-sram.h b/include/linux/ti-emif-sram.h
index 53604b087f2c..2fc854155c27 100644
--- a/include/linux/ti-emif-sram.h
+++ b/include/linux/ti-emif-sram.h
@@ -55,6 +55,7 @@ struct ti_emif_pm_data {
 struct ti_emif_pm_functions {
 	u32 save_context;
 	u32 restore_context;
+	u32 run_hw_leveling;
 	u32 enter_sr;
 	u32 exit_sr;
 	u32 abort_sr;
@@ -126,6 +127,8 @@ static inline void ti_emif_asm_offsets(void)
 	       offsetof(struct ti_emif_pm_functions, save_context));
 	DEFINE(EMIF_PM_RESTORE_CONTEXT_OFFSET,
 	       offsetof(struct ti_emif_pm_functions, restore_context));
+	DEFINE(EMIF_PM_RUN_HW_LEVELING,
+	       offsetof(struct ti_emif_pm_functions, run_hw_leveling));
 	DEFINE(EMIF_PM_ENTER_SR_OFFSET,
 	       offsetof(struct ti_emif_pm_functions, enter_sr));
 	DEFINE(EMIF_PM_EXIT_SR_OFFSET,
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] ARM: OMAP2+: sleep43xx: Run EMIF HW leveling on resume path

[Dave Gerlach]

When returning from DeepSleep mode on AM437x platforms the EMIF must run
DDR hardware leveling, same as done during u-boot, to properly restore the
EMIF PHY to it's operational state on platforms using DDR3.

Call the ti-emif-sram-pm run_hw_leveling routine to perform this. This
happens after all other EMIF values are restored so the exact same
configuration used at boot is used at the end of EMIF resume as well.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 arch/arm/mach-omap2/sleep43xx.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
index 5b9343b58fc7..0c1031442571 100644
--- a/arch/arm/mach-omap2/sleep43xx.S
+++ b/arch/arm/mach-omap2/sleep43xx.S
@@ -368,6 +368,9 @@ wait_emif_enable1:
 	mov     r1, #AM43XX_EMIF_POWEROFF_DISABLE
 	str     r1, [r2, #0x0]
 
+	ldr     r1, [r9, #EMIF_PM_RUN_HW_LEVELING]
+	blx     r1
+
 #ifdef CONFIG_CACHE_L2X0
 	ldr	r2, l2_cache_base
 	ldr	r0, [r2, #L2X0_CTRL]
-- 
2.20.1

[PATCH 2/2] ARM: OMAP2+: sleep43xx: Run EMIF HW leveling on resume path

[Dave Gerlach]

When returning from DeepSleep mode on AM437x platforms the EMIF must run
DDR hardware leveling, same as done during u-boot, to properly restore the
EMIF PHY to it's operational state on platforms using DDR3.

Call the ti-emif-sram-pm run_hw_leveling routine to perform this. This
happens after all other EMIF values are restored so the exact same
configuration used at boot is used at the end of EMIF resume as well.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 arch/arm/mach-omap2/sleep43xx.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/sleep43xx.S b/arch/arm/mach-omap2/sleep43xx.S
index 5b9343b58fc7..0c1031442571 100644
--- a/arch/arm/mach-omap2/sleep43xx.S
+++ b/arch/arm/mach-omap2/sleep43xx.S
@@ -368,6 +368,9 @@ wait_emif_enable1:
 	mov     r1, #AM43XX_EMIF_POWEROFF_DISABLE
 	str     r1, [r2, #0x0]
 
+	ldr     r1, [r9, #EMIF_PM_RUN_HW_LEVELING]
+	blx     r1
+
 #ifdef CONFIG_CACHE_L2X0
 	ldr	r2, l2_cache_base
 	ldr	r0, [r2, #L2X0_CTRL]
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> In certain situations, such as when returning from low power modes, the
> EMIF must re-run hardware leveling to properly restore DDR3 access.
> 
> This is accomplished by introducing a new ti-emif-sram-pm call,
> ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> the full write and read leveling processes.

OK nice that you also consider devices with LPDDR2 then in case we
start seeing those.

Regards,

Tony

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> In certain situations, such as when returning from low power modes, the
> EMIF must re-run hardware leveling to properly restore DDR3 access.
> 
> This is accomplished by introducing a new ti-emif-sram-pm call,
> ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> the full write and read leveling processes.

OK nice that you also consider devices with LPDDR2 then in case we
start seeing those.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Dave Gerlach]

Tony,
On 4/2/19 12:24 PM, Tony Lindgren wrote:
> * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
>> In certain situations, such as when returning from low power modes, the
>> EMIF must re-run hardware leveling to properly restore DDR3 access.
>>
>> This is accomplished by introducing a new ti-emif-sram-pm call,
>> ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
>> the full write and read leveling processes.
> 
> OK nice that you also consider devices with LPDDR2 then in case we
> start seeing those.

Yes, LPDDR2 will work fine with these. Any thoughts on if this series 
should come through you or Santosh?

Regards,
Dave

> 
> Regards,
> 
> Tony
> 

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Dave Gerlach]

Tony,
On 4/2/19 12:24 PM, Tony Lindgren wrote:
> * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
>> In certain situations, such as when returning from low power modes, the
>> EMIF must re-run hardware leveling to properly restore DDR3 access.
>>
>> This is accomplished by introducing a new ti-emif-sram-pm call,
>> ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
>> the full write and read leveling processes.
> 
> OK nice that you also consider devices with LPDDR2 then in case we
> start seeing those.

Yes, LPDDR2 will work fine with these. Any thoughts on if this series 
should come through you or Santosh?

Regards,
Dave

> 
> Regards,
> 
> Tony
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
> Tony,
> On 4/2/19 12:24 PM, Tony Lindgren wrote:
> > * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> > > In certain situations, such as when returning from low power modes, the
> > > EMIF must re-run hardware leveling to properly restore DDR3 access.
> > > 
> > > This is accomplished by introducing a new ti-emif-sram-pm call,
> > > ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> > > the full write and read leveling processes.
> > 
> > OK nice that you also consider devices with LPDDR2 then in case we
> > start seeing those.
> 
> Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
> come through you or Santosh?

Probably best that I queue these since there's also
arch/arm/mach-omap2 code related changes.

Regards,

Tony

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
> Tony,
> On 4/2/19 12:24 PM, Tony Lindgren wrote:
> > * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> > > In certain situations, such as when returning from low power modes, the
> > > EMIF must re-run hardware leveling to properly restore DDR3 access.
> > > 
> > > This is accomplished by introducing a new ti-emif-sram-pm call,
> > > ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> > > the full write and read leveling processes.
> > 
> > OK nice that you also consider devices with LPDDR2 then in case we
> > start seeing those.
> 
> Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
> come through you or Santosh?

Probably best that I queue these since there's also
arch/arm/mach-omap2 code related changes.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [190408 19:34]:
> * Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
> > Tony,
> > On 4/2/19 12:24 PM, Tony Lindgren wrote:
> > > * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> > > > In certain situations, such as when returning from low power modes, the
> > > > EMIF must re-run hardware leveling to properly restore DDR3 access.
> > > > 
> > > > This is accomplished by introducing a new ti-emif-sram-pm call,
> > > > ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> > > > the full write and read leveling processes.
> > > 
> > > OK nice that you also consider devices with LPDDR2 then in case we
> > > start seeing those.
> > 
> > Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
> > come through you or Santosh?
> 
> Probably best that I queue these since there's also
> arch/arm/mach-omap2 code related changes.

Santosh, is this OK with you? Care to ack the patch?

Regards,

Tony

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [190408 19:34]:
> * Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
> > Tony,
> > On 4/2/19 12:24 PM, Tony Lindgren wrote:
> > > * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> > > > In certain situations, such as when returning from low power modes, the
> > > > EMIF must re-run hardware leveling to properly restore DDR3 access.
> > > > 
> > > > This is accomplished by introducing a new ti-emif-sram-pm call,
> > > > ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> > > > the full write and read leveling processes.
> > > 
> > > OK nice that you also consider devices with LPDDR2 then in case we
> > > start seeing those.
> > 
> > Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
> > come through you or Santosh?
> 
> Probably best that I queue these since there's also
> arch/arm/mach-omap2 code related changes.

Santosh, is this OK with you? Care to ack the patch?

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[santosh.shilimkar]

On 4/9/19 8:19 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [190408 19:34]:
>> * Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
>>> Tony,
>>> On 4/2/19 12:24 PM, Tony Lindgren wrote:
>>>> * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
>>>>> In certain situations, such as when returning from low power modes, the
>>>>> EMIF must re-run hardware leveling to properly restore DDR3 access.
>>>>>
>>>>> This is accomplished by introducing a new ti-emif-sram-pm call,
>>>>> ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
>>>>> the full write and read leveling processes.
>>>>
>>>> OK nice that you also consider devices with LPDDR2 then in case we
>>>> start seeing those.
>>>
>>> Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
>>> come through you or Santosh?
>>
>> Probably best that I queue these since there's also
>> arch/arm/mach-omap2 code related changes.
> 
> Santosh, is this OK with you? Care to ack the patch?
> 
Sure Tony !!

Acked-by: Santosh Shilimkar <ssantosh@kernel.org>

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[santosh.shilimkar]

On 4/9/19 8:19 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [190408 19:34]:
>> * Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
>>> Tony,
>>> On 4/2/19 12:24 PM, Tony Lindgren wrote:
>>>> * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
>>>>> In certain situations, such as when returning from low power modes, the
>>>>> EMIF must re-run hardware leveling to properly restore DDR3 access.
>>>>>
>>>>> This is accomplished by introducing a new ti-emif-sram-pm call,
>>>>> ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
>>>>> the full write and read leveling processes.
>>>>
>>>> OK nice that you also consider devices with LPDDR2 then in case we
>>>> start seeing those.
>>>
>>> Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
>>> come through you or Santosh?
>>
>> Probably best that I queue these since there's also
>> arch/arm/mach-omap2 code related changes.
> 
> Santosh, is this OK with you? Care to ack the patch?
> 
Sure Tony !!

Acked-by: Santosh Shilimkar <ssantosh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* santosh.shilimkar@oracle.com <santosh.shilimkar@oracle.com> [190409 15:26]:
> On 4/9/19 8:19 AM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [190408 19:34]:
> > > * Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
> > > > Tony,
> > > > On 4/2/19 12:24 PM, Tony Lindgren wrote:
> > > > > * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> > > > > > In certain situations, such as when returning from low power modes, the
> > > > > > EMIF must re-run hardware leveling to properly restore DDR3 access.
> > > > > > 
> > > > > > This is accomplished by introducing a new ti-emif-sram-pm call,
> > > > > > ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> > > > > > the full write and read leveling processes.
> > > > > 
> > > > > OK nice that you also consider devices with LPDDR2 then in case we
> > > > > start seeing those.
> > > > 
> > > > Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
> > > > come through you or Santosh?
> > > 
> > > Probably best that I queue these since there's also
> > > arch/arm/mach-omap2 code related changes.
> > 
> > Santosh, is this OK with you? Care to ack the patch?
> > 
> Sure Tony !!
> 
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>

Thanks, applying these two patches into omap-for-v5.2/am4-ddr3
branch.

Reagrds,

Tony

Re: [PATCH 1/2] memory: ti-emif-sram: Add ti_emif_run_hw_leveling for DDR3 hardware leveling

[Tony Lindgren]

* santosh.shilimkar@oracle.com <santosh.shilimkar@oracle.com> [190409 15:26]:
> On 4/9/19 8:19 AM, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [190408 19:34]:
> > > * Dave Gerlach <d-gerlach@ti.com> [190408 18:31]:
> > > > Tony,
> > > > On 4/2/19 12:24 PM, Tony Lindgren wrote:
> > > > > * Dave Gerlach <d-gerlach@ti.com> [190402 16:57]:
> > > > > > In certain situations, such as when returning from low power modes, the
> > > > > > EMIF must re-run hardware leveling to properly restore DDR3 access.
> > > > > > 
> > > > > > This is accomplished by introducing a new ti-emif-sram-pm call,
> > > > > > ti_emif_run_hw_leveling, to check if DDR3 is in use and if so, trigger
> > > > > > the full write and read leveling processes.
> > > > > 
> > > > > OK nice that you also consider devices with LPDDR2 then in case we
> > > > > start seeing those.
> > > > 
> > > > Yes, LPDDR2 will work fine with these. Any thoughts on if this series should
> > > > come through you or Santosh?
> > > 
> > > Probably best that I queue these since there's also
> > > arch/arm/mach-omap2 code related changes.
> > 
> > Santosh, is this OK with you? Care to ack the patch?
> > 
> Sure Tony !!
> 
> Acked-by: Santosh Shilimkar <ssantosh@kernel.org>

Thanks, applying these two patches into omap-for-v5.2/am4-ddr3
branch.

Reagrds,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel