* [U-Boot] [PATCH 1/6] arm: mach-omap2: am33xx: ddr: programming of EXT_PHY_CTRL1 and EXT_PHY_CTRL1_SHADOW
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
@ 2019-04-12 6:38 ` Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 2/6] arm: mach-omap2: am33xx: ddr: Add 1ms delay to avoid L3 error Keerthy
` (5 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-12 6:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [U-Boot] [PATCH 2/6] arm: mach-omap2: am33xx: ddr: Add 1ms delay to avoid L3 error
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 1/6] arm: mach-omap2: am33xx: ddr: programming of EXT_PHY_CTRL1 and EXT_PHY_CTRL1_SHADOW Keerthy
@ 2019-04-12 6:38 ` Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 3/6] arm: mach-omap2: am33xx: Enable HW Leveling in the rtc+ddr path Keerthy
` (4 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-12 6:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [U-Boot] [PATCH 3/6] arm: mach-omap2: am33xx: Enable HW Leveling in the rtc+ddr path
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 1/6] arm: mach-omap2: am33xx: ddr: programming of EXT_PHY_CTRL1 and EXT_PHY_CTRL1_SHADOW Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 2/6] arm: mach-omap2: am33xx: ddr: Add 1ms delay to avoid L3 error Keerthy
@ 2019-04-12 6:38 ` Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling Keerthy
` (3 subsequent siblings)
6 siblings, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-12 6:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [U-Boot] [PATCH 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
` (2 preceding siblings ...)
2019-04-12 6:38 ` [U-Boot] [PATCH 3/6] arm: mach-omap2: am33xx: Enable HW Leveling in the rtc+ddr path Keerthy
@ 2019-04-12 6:38 ` Keerthy
2019-04-26 11:16 ` [U-Boot] [U-Boot, " Tom Rini
2019-04-12 6:38 ` [U-Boot] [PATCH 5/6] arm: mach-omap2: am33xx: ddr: update value for ext_phy_ctrl_36 Keerthy
` (2 subsequent siblings)
6 siblings, 1 reply; 24+ messages in thread
From: Keerthy @ 2019-04-12 6:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-12 6:38 ` [U-Boot] [PATCH 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling Keerthy
@ 2019-04-26 11:16 ` Tom Rini
2019-04-26 11:53 ` Lokesh Vutla
2019-04-26 14:11 ` Keerthy
0 siblings, 2 replies; 24+ messages in thread
From: Tom Rini @ 2019-04-26 11:16 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 11:16 ` [U-Boot] [U-Boot, " Tom Rini
@ 2019-04-26 11:53 ` Lokesh Vutla
2019-04-26 12:55 ` Tom Rini
2019-04-26 16:39 ` Keerthy
2019-04-26 14:11 ` Keerthy
1 sibling, 2 replies; 24+ messages in thread
From: Lokesh Vutla @ 2019-04-26 11:53 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 11:53 ` Lokesh Vutla
@ 2019-04-26 12:55 ` Tom Rini
2019-04-26 16:44 ` Keerthy
2019-04-26 16:39 ` Keerthy
1 sibling, 1 reply; 24+ messages in thread
From: Tom Rini @ 2019-04-26 12:55 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 12:55 ` Tom Rini
@ 2019-04-26 16:44 ` Keerthy
2019-04-26 16:46 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: Keerthy @ 2019-04-26 16:44 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 16:44 ` Keerthy
@ 2019-04-26 16:46 ` Tom Rini
2019-04-26 16:50 ` Keerthy
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2019-04-26 16:46 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 16:46 ` Tom Rini
@ 2019-04-26 16:50 ` Keerthy
0 siblings, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-26 16:50 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 11:53 ` Lokesh Vutla
2019-04-26 12:55 ` Tom Rini
@ 2019-04-26 16:39 ` Keerthy
1 sibling, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-26 16:39 UTC (permalink / raw)
To: u-boot
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
>
>>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [U-Boot, 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling
2019-04-26 11:16 ` [U-Boot] [U-Boot, " Tom Rini
2019-04-26 11:53 ` Lokesh Vutla
@ 2019-04-26 14:11 ` Keerthy
1 sibling, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-26 14:11 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 5/6] arm: mach-omap2: am33xx: ddr: update value for ext_phy_ctrl_36
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
` (3 preceding siblings ...)
2019-04-12 6:38 ` [U-Boot] [PATCH 4/6] arm: mach-omap2: am33xx: Disable EMIF_DEVOFF immediately before hw leveling Keerthy
@ 2019-04-12 6:38 ` Keerthy
2019-04-12 6:38 ` [U-Boot] [PATCH 6/6] board: ti: am43xx: Enable hardware leveling Keerthy
2019-04-13 13:02 ` [U-Boot] [PATCH 0/6] " Tom Rini
6 siblings, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-12 6:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [U-Boot] [PATCH 6/6] board: ti: am43xx: Enable hardware leveling
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
` (4 preceding siblings ...)
2019-04-12 6:38 ` [U-Boot] [PATCH 5/6] arm: mach-omap2: am33xx: ddr: update value for ext_phy_ctrl_36 Keerthy
@ 2019-04-12 6:38 ` Keerthy
2019-04-13 13:02 ` [U-Boot] [PATCH 0/6] " Tom Rini
6 siblings, 0 replies; 24+ messages in thread
From: Keerthy @ 2019-04-12 6:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-12 6:38 [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling Keerthy
` (5 preceding siblings ...)
2019-04-12 6:38 ` [U-Boot] [PATCH 6/6] board: ti: am43xx: Enable hardware leveling Keerthy
@ 2019-04-13 13:02 ` Tom Rini
2019-04-15 0:49 ` keerthy
6 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2019-04-13 13:02 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-13 13:02 ` [U-Boot] [PATCH 0/6] " Tom Rini
@ 2019-04-15 0:49 ` keerthy
2019-04-15 1:05 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: keerthy @ 2019-04-15 0:49 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 0:49 ` keerthy
@ 2019-04-15 1:05 ` Tom Rini
2019-04-15 2:13 ` keerthy
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2019-04-15 1:05 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 1:05 ` Tom Rini
@ 2019-04-15 2:13 ` keerthy
2019-04-15 8:56 ` Keerthy
0 siblings, 1 reply; 24+ messages in thread
From: keerthy @ 2019-04-15 2:13 UTC (permalink / raw)
To: u-boot
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.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 2:13 ` keerthy
@ 2019-04-15 8:56 ` Keerthy
2019-04-15 9:22 ` Tero Kristo
0 siblings, 1 reply; 24+ messages in thread
From: Keerthy @ 2019-04-15 8:56 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 8:56 ` Keerthy
@ 2019-04-15 9:22 ` Tero Kristo
2019-04-15 11:28 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: Tero Kristo @ 2019-04-15 9:22 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 9:22 ` Tero Kristo
@ 2019-04-15 11:28 ` Tom Rini
2019-04-15 12:10 ` Keerthy
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2019-04-15 11:28 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 11:28 ` Tom Rini
@ 2019-04-15 12:10 ` Keerthy
2019-04-15 12:14 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: Keerthy @ 2019-04-15 12:10 UTC (permalink / raw)
To: u-boot
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?
^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
2019-04-15 12:10 ` Keerthy
@ 2019-04-15 12:14 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2019-04-15 12:14 UTC (permalink / raw)
To: u-boot
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>
^ permalink raw reply [flat|nested] 24+ messages in thread