[U-Boot] [PATCH] 440spe MQ initialization
Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver).
Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results.
Signed-off-by: Yuri Tikhonov yur@emcraft.com --- cpu/ppc4xx/44x_spd_ddr2.c | 10 ++++++---- include/asm-ppc/ppc4xx-sdram.h | 5 +++++ 2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/cpu/ppc4xx/44x_spd_ddr2.c b/cpu/ppc4xx/44x_spd_ddr2.c index f1d7684..995d5fe 100644 --- a/cpu/ppc4xx/44x_spd_ddr2.c +++ b/cpu/ppc4xx/44x_spd_ddr2.c @@ -2261,10 +2261,12 @@ static void program_memory_queue(unsigned long *dimm_populated, /* * Set optimal value for Memory Queue HB/LL Configuration registers */ - mtdcr(SDRAM_CONF1HB, mfdcr(SDRAM_CONF1HB) | SDRAM_CONF1HB_AAFR | - SDRAM_CONF1HB_RPEN | SDRAM_CONF1HB_RFTE); - mtdcr(SDRAM_CONF1LL, mfdcr(SDRAM_CONF1LL) | SDRAM_CONF1LL_AAFR | - SDRAM_CONF1LL_RPEN | SDRAM_CONF1LL_RFTE); + mtdcr(SDRAM_CONF1HB, (mfdcr(SDRAM_CONF1HB) & ~SDRAM_CONF1HB_MASK) | + SDRAM_CONF1HB_AAFR | SDRAM_CONF1HB_RPEN | SDRAM_CONF1HB_RFTE | + SDRAM_CONF1HB_RPLM | SDRAM_CONF1HB_WRCL); + mtdcr(SDRAM_CONF1LL, (mfdcr(SDRAM_CONF1LL) & ~SDRAM_CONF1LL_MASK) | + SDRAM_CONF1LL_AAFR | SDRAM_CONF1LL_RPEN | SDRAM_CONF1LL_RFTE | + SDRAM_CONF1LL_RPLM); mtdcr(SDRAM_CONFPATHB, mfdcr(SDRAM_CONFPATHB) | SDRAM_CONFPATHB_TPEN); #endif } diff --git a/include/asm-ppc/ppc4xx-sdram.h b/include/asm-ppc/ppc4xx-sdram.h index 8efa557..98faced 100644 --- a/include/asm-ppc/ppc4xx-sdram.h +++ b/include/asm-ppc/ppc4xx-sdram.h @@ -272,8 +272,11 @@ #define SDRAM_CONF1HB_PRPD 0x00080000 /* PLB Read pipeline Disable - Bit 12 */ #define SDRAM_CONF1HB_PWPD 0x00040000 /* PLB Write pipeline Disable - Bit 13 */ #define SDRAM_CONF1HB_PRW 0x00020000 /* PLB Read Wait - Bit 14 */ +#define SDRAM_CONF1HB_RPLM 0x00001000 /* Read Passing Limit 1 - Bits 16..19 */ #define SDRAM_CONF1HB_RPEN 0x00000800 /* Read Passing Enable - Bit 20 */ #define SDRAM_CONF1HB_RFTE 0x00000400 /* Read Flow Through Enable - Bit 21 */ +#define SDRAM_CONF1HB_WRCL 0x00000080 /* MCIF Cycle Limit 1 - Bits 22..24 */ +#define SDRAM_CONF1HB_MASK 0x0000F380 /* RPLM & WRCL mask */
#define SDRAM_ERRSTATHB (SDRAMQ_DCR_BASE+0x7) /* error status HB */ #define SDRAM_ERRADDUHB (SDRAMQ_DCR_BASE+0x8) /* error address upper 32 HB */ @@ -284,8 +287,10 @@ #define SDRAM_CONF1LL_PRPD 0x00080000 /* PLB Read pipeline Disable - Bit 12 */ #define SDRAM_CONF1LL_PWPD 0x00040000 /* PLB Write pipeline Disable - Bit 13 */ #define SDRAM_CONF1LL_PRW 0x00020000 /* PLB Read Wait - Bit 14 */ +#define SDRAM_CONF1LL_RPLM 0x00001000 /* Read Passing Limit 1 - Bits 16..19 */ #define SDRAM_CONF1LL_RPEN 0x00000800 /* Read Passing Enable - Bit 20 */ #define SDRAM_CONF1LL_RFTE 0x00000400 /* Read Flow Through Enable - Bit 21 */ +#define SDRAM_CONF1LL_MASK 0x0000F000 /* RPLM mask */
#define SDRAM_ERRSTATLL (SDRAMQ_DCR_BASE+0xC) /* error status LL */ #define SDRAM_ERRADDULL (SDRAMQ_DCR_BASE+0xD) /* error address upper 32 LL */
Hi Yuri,
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver).
Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results.
AMCC just recently updated the 440SP(e) MQ initialization with this patch:
commit 079589bcfb24ba11068460276a3cc9549ab5346f Author: Prodyut Hazarika phazarika@amcc.com Date: Wed Aug 20 09:38:51 2008 -0700
ppc4xx: Optimize PLB4 Arbiter and Memory Queue settings for PPC440SP/SPe, PPC405EX and PPC460EX/GT/SX
- Read pipeline depth set to 4 for PPC440SP/SPE, PPC405EX, PPC460EX/GT/SX processors - Moved PLB4 Arbiter register definitions to ppc4xx.h since it is shared across processors (405 and 440/460) - Optimize Memory Queue settings for PPC440SP/SPE and PPC460EX/GT/SX processors - Add register bit definitions for Memory Queue Configuration registers
Signed-off-by: Prodyut Hazarika phazarika@amcc.com Signed-off-by: Stefan Roese sr@denx.de
I have a bad feeling changing this "optimized" settings without AMCC's specific ACK.
Prodyut, are you ok with Yuri's change?
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hello,
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
--- Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Best regards,
Wolfgang Denk ---
On Tuesday, September 23, 2008 you wrote:
Hi Yuri,
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver).
Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results.
AMCC just recently updated the 440SP(e) MQ initialization with this patch:
commit 079589bcfb24ba11068460276a3cc9549ab5346f Author: Prodyut Hazarika phazarika@amcc.com Date: Wed Aug 20 09:38:51 2008 -0700
ppc4xx: Optimize PLB4 Arbiter and Memory Queue settings for PPC440SP/SPe, PPC405EX and PPC460EX/GT/SX
- Read pipeline depth set to 4 for PPC440SP/SPE, PPC405EX, PPC460EX/GT/SX processors - Moved PLB4 Arbiter register definitions to ppc4xx.h since it is shared across processors (405 and 440/460) - Optimize Memory Queue settings for PPC440SP/SPE and PPC460EX/GT/SX processors - Add register bit definitions for Memory Queue Configuration registers
Signed-off-by: Prodyut Hazarika <phazarika@amcc.com> Signed-off-by: Stefan Roese <sr@denx.de>
I have a bad feeling changing this "optimized" settings without AMCC's specific ACK.
Prodyut, are you ok with Yuri's change?
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Regards, Yuri
-- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Yuriy/Stefan-
This is AMCC confirmation about configuration.
Regards,
Olga Buchonina AMCC PowerPC Applications Engineering
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Tuesday, September 23, 2008 4:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk
on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de ===================================================================== --------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Hi Stefan/Yuri, I looked at the changes. I had already submitted the changes in an earlier patch. This code to set the PLB4 arbiter depth was moved to cpu_init_f function in cpu/ppc4xx/cpu_init.c since it is common across many processor families.
Please don't do the same thing again in the program_memory_queue function.
Thanks, Prodyut
________________________________
From: Stefan Roese [mailto:sr@denx.de] Sent: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hello Prodyut,
On Tuesday, September 23, 2008 you wrote:
Hi Stefan/Yuri, I looked at the changes. I had already submitted the changes in an earlier patch. This code to set the PLB4 arbiter depth was moved to cpu_init_f function in cpu/ppc4xx/cpu_init.c since it is common across many processor families.
Please don't do the same thing again in the program_memory_queue function.
Well, actually my patch doesn't have a deal with the PLB configuring, but with MQ only. So, it's OK here.
But then another question arises: in Linux, in ppc440spe_configure_raid_devices(), beside the other things we do the following:
/* Configure PLB as follows: * PLB: 0xDF000000. This means * - Priority level 00 fair priority, * - Priority level 01 fair priority, * - Priority level 11 fair priority, * - High Bus Utilization enabled, * - 4 Deep read pipe, * - 2 Deep write pipe. */ mask = (1 << PLB_ACR_PPM0) | (1 << PLB_ACR_PPM1) | (1 << PLB_ACR_PPM3) | (1 << PLB_ACR_HBU) | ((3 & PLB_ACR_RDP_MSK) << PLB_ACR_RDP) | (1 << PLB_ACR_WRP); mtdcr(DCRN_PLB0_ACR, mask); mtdcr(DCRN_PLB1_ACR, mask);
Is it OK, or should we remove these strings from the Linux driver, assuming U-Boot has already done this ?
Thanks in advance, Yuri
From: Stefan Roese [mailto:sr@denx.de] Sent: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
-- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com
Hi Yuri,
Is it OK, or should we remove these strings from the Linux driver, assuming U-Boot has already done this ?
Please go ahead and remove these from the linux driver. And I think this driver has not been submitted to the powerpc tree, since I still don't see it in Josh's or Linus's tree.
Thanks, Prodyut
From: Stefan Roese [mailto:sr@denx.de] Sent: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
-- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com
Hi Prodyut,
On Tuesday, September 23, 2008 you wrote:
Hi Yuri,
Is it OK, or should we remove these strings from the Linux driver, assuming U-Boot has already done this ?
Please go ahead and remove these from the linux driver.
Thanks for confirmation, will do.
And I think this driver has not been submitted to the powerpc tree, since I still don't see it in Josh's or Linus's tree.
Yep, for now it's present in the linux-2.6-denx tree only. We are about to post this to MLs along with our RAID-6 related changes soon.
From: Stefan Roese [mailto:sr@denx.de] Sent: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
-- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com
Regards, Yuri
-- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
Is it OK, or should we remove these strings from the Linux driver, assuming U-Boot has already done this ?
Please go ahead and remove these from the linux driver.
Thanks for confirmation, will do.
I have to admit that I am a little confused now. Are there now any patches that should be applied to U-Boot regarding the MQ and/or the PLB arbiter configuration? It seems to me that Yuri's configuration from the RAID driver (which will be dropped in the RAID driver soon) is not fully covered in the current U-Boot version.
So please let me know if Yuri's original MQ patch should be applied and if there is another PLB arbiter patch that should be applied too.
Thanks.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
I have to admit that I am a little confused now. Are there now any patches that should be applied to U-Boot regarding the MQ and/or the PLB arbiter configuration?
There is no patch that needs to be applied for PLB arbiter configuration. My earlier patch covered that.
It seems to me that Yuri's configuration from the RAID driver (which will be dropped in the RAID driver soon) is not fully covered in the current U-Boot version.
Yuri's configuration from RAID driver should be droppred coz changing MQ/PLB4 registers from Linux is not recommended
So please let me know if Yuri's original MQ patch should be applied and if there is another PLB arbiter patch that should be applied too.
Yuri's patch does the following - set RLPM (read passing limit) bits in MQ register to 1, - set WRCL (MCIF cycle limit) in MQ registers to 1. In my testing, as far as I can remember, these values were set to 1 by default. I had tested with Canyonlands, Kilauea, Katmai and Glacier boards. So unless Yuri found that these values were not default values in some processor, Yuri's patch should be applied.
Thanks, Prodyut
Hi Yuri/Stefan, I remember duriing my testing that the default Read passing limit (RPML) and MCIF limit (WRCL) was 1. So there was no need to set these registers again to the same values.
Thanks, Prodyut
: Tue 9/23/2008 2:43 AM To: Yuri Tikhonov Cc: u-boot@lists.denx.de; Prodyut Hazarika; Olga Buchonina Subject: Re: [U-Boot] [PATCH] 440spe MQ initialization
On Tuesday 23 September 2008, Yuri Tikhonov wrote:
BTW, when I said "recommended by AMCC" in the patch description I referred to the following information forwarded to me by Wolfgang Denk on Tue Mar 18 2008:
Dear Yuri,
here is some additional (and hopefully helpful) information from AMCC
regarding the observed hangs on the katmai board:
If possible, can you please check if you still see the lock up when you program MQ as follows: set value in HB and if you are using LL also as follows: MQ0_CF1H = 0x80001C80 MQ0_CF1L = 0x80001C80 Additionally, make sure that your PLB settings are: PLB0_ACR = 0xDF000000 ( 4 deep read and 2 deep write) PLB1_ACR = 0xDF000000 ( 4 deep read and 2 deep write) Please let me know if this fixes the issue. I also would like to know how you are programming your DMA and how is the traffic is pipelined. Regards, Olga Buchonina AMCC PowerPC Applications Engineering
Understood. I just would like to see an ACK from AMCC on this since they just updated this MQ init code.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan,
In message 200809231237.12323.yur@emcraft.com Yuri Tikhonov wrote:
Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver).
Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results.
Signed-off-by: Yuri Tikhonov yur@emcraft.com
cpu/ppc4xx/44x_spd_ddr2.c | 10 ++++++---- include/asm-ppc/ppc4xx-sdram.h | 5 +++++ 2 files changed, 11 insertions(+), 4 deletions(-)
I must admit that I lost track in the discussion following this posting what the real state of affairs is now. Do we need to change anything in U-Boot, or not, and why not?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Friday 17 October 2008, Wolfgang Denk wrote:
Set the MQ Read Passing & MCIF Cycle limits to the recommended by AMCC values. This fixes the occasional 440SPe hard locking issues when the 440SPe's dedicated DMA engines are used (e.g. by the h/w accelerated RAID driver).
Previously the appropriate initialization had been made in Linux, by the ppc440spe ADMA driver, which is wrong because modifying the MQ configuration registers after normal operation has begun is not supported and could have unpredictable results.
Signed-off-by: Yuri Tikhonov yur@emcraft.com
cpu/ppc4xx/44x_spd_ddr2.c | 10 ++++++---- include/asm-ppc/ppc4xx-sdram.h | 5 +++++ 2 files changed, 11 insertions(+), 4 deletions(-)
I must admit that I lost track in the discussion following this posting what the real state of affairs is now. Do we need to change anything in U-Boot, or not, and why not?
I also lost track of whats really needed, I'm afraid. That's why I asked about this a few weeks ago. Here an extract from the last mail:
On Thursday 25 September 2008, Prodyut Hazarika wrote:
So please let me know if Yuri's original MQ patch should be applied and if there is another PLB arbiter patch that should be applied too.
Yuri's patch does the following
- set RLPM (read passing limit) bits in MQ register to 1,
- set WRCL (MCIF cycle limit) in MQ registers to 1.
In my testing, as far as I can remember, these values were set to 1 by default. I had tested with Canyonlands, Kilauea, Katmai and Glacier boards. So unless Yuri found that these values were not default values in some processor, Yuri's patch should be applied.
So it seems that the current code relies on some already preset (default) values in those registers. I don't really like this. I'll try to provide a patch that configures those registers completely in a short while.
It would be great if Yuri could test this on a target to see if we are still missing something.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Dear Stefan Roese,
In message 200810171142.40636.sr@denx.de you wrote:
So it seems that the current code relies on some already preset (default) values in those registers. I don't really like this. I'll try to provide a patch that configures those registers completely in a short while.
"In a short while" means very few hours? If Yuri is sopposed to test this, we have little time left. The release is scheduled for tomorrow.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Friday 17 October 2008, Wolfgang Denk wrote:
So it seems that the current code relies on some already preset (default) values in those registers. I don't really like this. I'll try to provide a patch that configures those registers completely in a short while.
"In a short while" means very few hours?
Yes. I already tested with Yuri's patch and it doesn't change the resulting register values. So the current code already sets the correct values, it just doesn't set all bits explicitly. I'll provide another patch in a few minutes to set these bits explicitly, since this makes it clearer which bits are really configured.
If Yuri is sopposed to test this, we have little time left. The release is scheduled for tomorrow.
Understood. He can test with the current U-Boot version without setting the MQ registers in the DMA/RAID Linux driver.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (5)
-
Olga Buchonina -
Prodyut Hazarika -
Stefan Roese -
Wolfgang Denk -
Yuri Tikhonov