[U-Boot] [PATCH 0/6] board: ti: am43xx: Enable hardware leveling
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(-)
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);
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
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();
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) |
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!
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
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.
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
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!
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
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
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
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
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:
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,
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!
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
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?
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.
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@lists.denx.de https://lists.denx.de/listinfo/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@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
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?
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?
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!
participants (5)
-
Keerthy -
keerthy
-
Lokesh Vutla -
Tero Kristo -
Tom Rini