[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com --- README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/README b/README index 30d7ee3..873a24c 100644 --- a/README +++ b/README @@ -533,6 +533,9 @@ The following options need to be configured: CONFIG_SYS_FSL_IFC_LE Defines the IFC controller register space as Little Endian
+ CONFIG_SYS_FSL_IFC_CLK_DIV + Defines divider of platform clock(clock input to IFC controller). + CONFIG_SYS_FSL_PBL_PBI It enables addition of RCW (Power on reset configuration) in built image. Please refer doc/README.pblimage for more details diff --git a/arch/arm/cpu/armv7/ls102xa/clock.c b/arch/arm/cpu/armv7/ls102xa/clock.c index 7a337e1..5d0411f 100644 --- a/arch/arm/cpu/armv7/ls102xa/clock.c +++ b/arch/arm/cpu/armv7/ls102xa/clock.c @@ -19,10 +19,6 @@ DECLARE_GLOBAL_DATA_PTR; void get_sys_info(struct sys_info *sys_info) { struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); -#ifdef CONFIG_FSL_IFC - struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL}; - u32 ccr; -#endif struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_LS1_CLK_ADDR); unsigned int cpu; const u8 core_cplx_pll[6] = { @@ -74,10 +70,8 @@ void get_sys_info(struct sys_info *sys_info) }
#if defined(CONFIG_FSL_IFC) - ccr = in_be32(&ifc_regs.gregs->ifc_ccr); - ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1; - - sys_info->freq_localbus = sys_info->freq_systembus / ccr; + sys_info->freq_localbus = sys_info->freq_systembus / + CONFIG_SYS_FSL_IFC_CLK_DIV; #endif }
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c index 8922197..dbc56af 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c @@ -22,10 +22,6 @@ DECLARE_GLOBAL_DATA_PTR; void get_sys_info(struct sys_info *sys_info) { struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); -#ifdef CONFIG_FSL_IFC - struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL}; - u32 ccr; -#endif #if (defined(CONFIG_FSL_ESDHC) &&\ defined(CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK)) ||\ defined(CONFIG_SYS_DPAA_FMAN) @@ -153,10 +149,8 @@ void get_sys_info(struct sys_info *sys_info) #endif
#if defined(CONFIG_FSL_IFC) - ccr = ifc_in32(&ifc_regs.gregs->ifc_ccr); - ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1; - - sys_info->freq_localbus = sys_info->freq_systembus / ccr; + sys_info->freq_localbus = sys_info->freq_systembus / + CONFIG_SYS_FSL_IFC_CLK_DIV; #endif }
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c index a9b12a4..3b8389e 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c @@ -26,10 +26,6 @@ DECLARE_GLOBAL_DATA_PTR; void get_sys_info(struct sys_info *sys_info) { struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); -#ifdef CONFIG_FSL_IFC - struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL}; - u32 ccr; -#endif struct ccsr_clk_cluster_group __iomem *clk_grp[2] = { (void *)(CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR), (void *)(CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR) @@ -129,10 +125,8 @@ void get_sys_info(struct sys_info *sys_info) }
#if defined(CONFIG_FSL_IFC) - ccr = ifc_in32(&ifc_regs.gregs->ifc_ccr); - ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1; - - sys_info->freq_localbus = sys_info->freq_systembus / ccr; + sys_info->freq_localbus = sys_info->freq_systembus / + CONFIG_SYS_FSL_IFC_CLK_DIV; #endif }
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h b/arch/arm/include/asm/arch-fsl-layerscape/config.h index 5279981..2856193 100644 --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h @@ -29,6 +29,7 @@ #ifdef CONFIG_LS2080A #define CONFIG_MAX_CPUS 16 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 2 #define CONFIG_NUM_DDR_CONTROLLERS 3 #define CONFIG_SYS_FSL_HAS_DP_DDR /* Runtime check to confirm */ #define CONFIG_SYS_FSL_CLUSTER_CLOCKS { 1, 1, 4, 4 } @@ -173,6 +174,7 @@ #define CONFIG_SYS_NUM_FM1_DTSEC 7 #define CONFIG_SYS_NUM_FM1_10GEC 1 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 4 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_SYS_FSL_DDR_BE #define CONFIG_SYS_DDR_BLOCK1_SIZE ((phys_size_t)2 << 30) #define CONFIG_MAX_MEM_MAPPED CONFIG_SYS_DDR_BLOCK1_SIZE @@ -214,6 +216,7 @@ #define CONFIG_SYS_NUM_FM1_DTSEC 8 #define CONFIG_SYS_NUM_FM1_10GEC 2 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 4 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 2 #define CONFIG_SYS_FSL_DDR_BE #define CONFIG_SYS_DDR_BLOCK1_SIZE ((phys_size_t)2 << 30) #define CONFIG_MAX_MEM_MAPPED CONFIG_SYS_DDR_BLOCK1_SIZE diff --git a/arch/arm/include/asm/arch-ls102xa/config.h b/arch/arm/include/asm/arch-ls102xa/config.h index 56d8f32..5f0d756 100644 --- a/arch/arm/include/asm/arch-ls102xa/config.h +++ b/arch/arm/include/asm/arch-ls102xa/config.h @@ -123,6 +123,7 @@ #ifdef CONFIG_LS102XA #define CONFIG_MAX_CPUS 2 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_NUM_DDR_CONTROLLERS 1 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0 #define CONFIG_SYS_FSL_SEC_COMPAT 5 diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c index e732969..ea92ff3 100644 --- a/arch/powerpc/cpu/mpc85xx/speed.c +++ b/arch/powerpc/cpu/mpc85xx/speed.c @@ -27,10 +27,6 @@ DECLARE_GLOBAL_DATA_PTR; void get_sys_info(sys_info_t *sys_info) { volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); -#ifdef CONFIG_FSL_IFC - struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL}; - u32 ccr; -#endif #ifdef CONFIG_FSL_CORENET volatile ccsr_clk_t *clk = (void *)(CONFIG_SYS_FSL_CORENET_CLK_ADDR); unsigned int cpu; @@ -641,10 +637,8 @@ void get_sys_info(sys_info_t *sys_info) #endif
#if defined(CONFIG_FSL_IFC) - ccr = ifc_in32(&ifc_regs.gregs->ifc_ccr); - ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1; - - sys_info->freq_localbus = sys_info->freq_systembus / ccr; + sys_info->freq_localbus = sys_info->freq_systembus / + CONFIG_SYS_FSL_IFC_CLK_DIV; #endif }
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 505d355..fcfbb01 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -151,6 +151,7 @@ #define CONFIG_NUM_DDR_CONTROLLERS 1 #define CONFIG_USB_MAX_CONTROLLER_COUNT 1 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 4 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.2" #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY @@ -590,6 +591,7 @@ #define CONFIG_SYS_FSL_DSP_M2_RAM_ADDR 0xb0000000 #define CONFIG_SYS_FSL_DSP_CCSRBAR_DEFAULT 0xff600000 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 3 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 #define CONFIG_NAND_FSL_IFC #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 @@ -612,6 +614,7 @@ #define CONFIG_SYS_FSL_DSP_M3_RAM_ADDR 0xc0000000 #define CONFIG_SYS_FSL_DSP_CCSRBAR_DEFAULT 0xff600000 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 3 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 #define CONFIG_NAND_FSL_IFC #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 @@ -666,6 +669,7 @@ #define CONFIG_SYS_PME_CLK 0 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_4_7 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 2 #define CONFIG_SYS_FMAN_V3 #define CONFIG_SYS_FM1_CLK 3 #define CONFIG_SYS_FM2_CLK 3 @@ -714,6 +718,7 @@ #define CONFIG_SYS_ETVPE_CLK 1 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_4_7 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 4 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 2 #define CONFIG_SYS_FMAN_V3 #define CONFIG_SYS_FM_MURAM_SIZE 0x60000 #define CONFIG_SYS_FSL_TBCLK_DIV 16 @@ -786,6 +791,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define CONFIG_SYS_PME_CLK CONFIG_PME_PLAT_CLK_DIV #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 2 #define CONFIG_SYS_FSL_ERRATUM_A008044 #define CONFIG_SYS_FMAN_V3 #define CONFIG_FM_PLAT_CLK_DIV 1 @@ -839,6 +845,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013) #define CONFIG_USB_MAX_CONTROLLER_COUNT 2 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 2 #define CONFIG_SYS_FM1_CLK 0 #define CONFIG_SYS_SDHC_CLK 0/* Select SDHC CLK begining from PLL1 per rcw field value */ @@ -896,6 +903,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013) #define CONFIG_SYS_SDHC_CLK_2_PLL /* Select SDHC CLK from 2 PLLs */ #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_4_7 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_SYS_FMAN_V3 #define CONFIG_SYS_FM_MURAM_SIZE 0x28000 #define CONFIG_SYS_FSL_TBCLK_DIV 16 @@ -926,6 +934,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013) #define CONFIG_NUM_DDR_CONTROLLERS 1 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_4_6 #define CONFIG_SYS_FSL_IFC_BANK_COUNT 8 +#define CONFIG_SYS_FSL_IFC_CLK_DIV 1 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 #define CONFIG_SYS_FSL_ERRATUM_A005125 #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC 3
On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com
README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
Prabkahar,
Two concerns here
1, it is not only IFC for powerpc. Older SoCs have local bus. That's why the variable is named freq_localbus..
2, what's the reason for this change? Is it wrong to use ccr to calculate the clock? Or is it because recent Layerscape SoCs have platform PLL different from platform clock? If the latter, can we limit the fix to platform clock and not changing powerpc?
York
-----Original Message----- From: york sun Sent: Tuesday, September 06, 2016 9:10 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com
README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
Prabkahar,
Two concerns here
1, it is not only IFC for powerpc. Older SoCs have local bus. That's why the variable is named freq_localbus..
As per my understanding, Issue is valid for eLBC SoC also. Just wanted to confirm from internal IP team before spinning patch to fix it.
2, what's the reason for this change? Is it wrong to use ccr to calculate the clock? Or is it because recent Layerscape SoCs have platform PLL different from platform clock? If the latter, can we limit the fix to platform clock and not changing powerpc?
CCR governs the IFC output clock. This clock is used for synchronous NOR, NAND flashes. It is nowhere govern IFC IP internal clock.
It is true since conception of IFC. Unfortunately code written is wrong since P1010. It is confusing everyone.
--prabhakar
On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Tuesday, September 06, 2016 9:10 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com
README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
Prabkahar,
Two concerns here
1, it is not only IFC for powerpc. Older SoCs have local bus. That's why the variable is named freq_localbus..
As per my understanding, Issue is valid for eLBC SoC also. Just wanted to confirm from internal IP team before spinning patch to fix it.
2, what's the reason for this change? Is it wrong to use ccr to calculate the clock? Or is it because recent Layerscape SoCs have platform PLL different from platform clock? If the latter, can we limit the fix to platform clock and not changing powerpc?
CCR governs the IFC output clock. This clock is used for synchronous NOR, NAND flashes. It is nowhere govern IFC IP internal clock.
It is true since conception of IFC. Unfortunately code written is wrong since P1010. It is confusing everyone.
Are you saying the freq_localbus should be the internal clock, not output clock? As far as I can remember, this variable has always be used for output clock since 85xx. I am open to the idea to change to internal clock only if it makes sense. Browsing the code, I see this variable is used for information only, except for setting arch.lbc_clk.
York
York
-----Original Message----- From: york sun Sent: Wednesday, September 07, 2016 9:17 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Tuesday, September 06, 2016 9:10 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com
README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
Prabkahar,
Two concerns here
1, it is not only IFC for powerpc. Older SoCs have local bus. That's why the variable is named freq_localbus..
As per my understanding, Issue is valid for eLBC SoC also. Just wanted to confirm from internal IP team before spinning patch to fix it.
2, what's the reason for this change? Is it wrong to use ccr to calculate the clock? Or is it because recent Layerscape SoCs have platform PLL different from platform clock? If the latter, can we limit the fix to platform clock and not changing powerpc?
CCR governs the IFC output clock. This clock is used for synchronous NOR, NAND flashes. It is nowhere govern
IFC IP internal clock.
It is true since conception of IFC. Unfortunately code written is wrong since
P1010.
It is confusing everyone.
Are you saying the freq_localbus should be the internal clock, not output clock? As far as I can remember, this variable has always be used for output clock since 85xx. I am open to the idea to change to internal clock only if it makes sense. Browsing the code, I see this variable is used for information only, except for setting arch.lbc_clk.
Everyone believe it to be IFC internal clock not the output clock. As I always used to get query from customers about wrong IFC speed.
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during synchronous NOR, syn NAND. Please note it is currently not being supported by IFC.
--prabhakar
On 09/07/2016 06:30 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Wednesday, September 07, 2016 9:17 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Tuesday, September 06, 2016 9:10 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com
README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
Prabkahar,
Two concerns here
1, it is not only IFC for powerpc. Older SoCs have local bus. That's why the variable is named freq_localbus..
As per my understanding, Issue is valid for eLBC SoC also. Just wanted to confirm from internal IP team before spinning patch to fix it.
2, what's the reason for this change? Is it wrong to use ccr to calculate the clock? Or is it because recent Layerscape SoCs have platform PLL different from platform clock? If the latter, can we limit the fix to platform clock and not changing powerpc?
CCR governs the IFC output clock. This clock is used for synchronous NOR, NAND flashes. It is nowhere govern
IFC IP internal clock.
It is true since conception of IFC. Unfortunately code written is wrong since
P1010.
It is confusing everyone.
Are you saying the freq_localbus should be the internal clock, not output clock? As far as I can remember, this variable has always be used for output clock since 85xx. I am open to the idea to change to internal clock only if it makes sense. Browsing the code, I see this variable is used for information only, except for setting arch.lbc_clk.
Everyone believe it to be IFC internal clock not the output clock.
Not everyone.
As I always used to get query from customers about wrong IFC speed.
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
York
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 7:33 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/07/2016 06:30 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Wednesday, September 07, 2016 9:17 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 07:42 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Tuesday, September 06, 2016 9:10 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/06/2016 04:15 AM, Prabhakar Kushwaha wrote:
IFC IP clock is always a constant divisor of platform clock pre-defined per SoC. Clock Control register (CCR) used in current implementation governs IFC IP output clock.
So update IFC IP clock to be defined as per predefined clock divisor of platform clock.
Signed-off-by: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com
README | 3 +++ arch/arm/cpu/armv7/ls102xa/clock.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 10 ++-------- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 10 ++-------- arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h | 1 + arch/powerpc/cpu/mpc85xx/speed.c | 10 ++-------- arch/powerpc/include/asm/config_mpc85xx.h | 9 +++++++++ 8 files changed, 24 insertions(+), 32 deletions(-)
Prabkahar,
Two concerns here
1, it is not only IFC for powerpc. Older SoCs have local bus. That's why the variable is named freq_localbus..
As per my understanding, Issue is valid for eLBC SoC also. Just wanted to confirm from internal IP team before spinning patch to fix it.
2, what's the reason for this change? Is it wrong to use ccr to calculate the clock? Or is it because recent Layerscape SoCs have platform PLL different from platform clock? If the latter, can we limit the fix to platform clock and not changing powerpc?
CCR governs the IFC output clock. This clock is used for synchronous NOR, NAND flashes. It is nowhere govern
IFC IP internal clock.
It is true since conception of IFC. Unfortunately code written is wrong since
P1010.
It is confusing everyone.
Are you saying the freq_localbus should be the internal clock, not output clock? As far as I can remember, this variable has always be used for output clock since 85xx. I am open to the idea to change to internal clock only if it makes sense. Browsing the code, I see this variable is used for information only, except for setting arch.lbc_clk.
Everyone believe it to be IFC internal clock not the output clock.
Not everyone.
As I always used to get query from customers about wrong IFC speed.
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during
synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
No device tree fixup is being done for IFC.
--prabhakar
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during
synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
York
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during
synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
--prabhakar
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during
synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT (Prabhakar, can you answer my question of whether there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out.
-Scott
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 6:05 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
So better to print IP clock to avoid any confusion. IFC output clock will be printed when it is actually being used during
synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT
(Prabhakar, can you answer my question of whether
there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out.
IFC frequency means IP clock or IP output clock?
If IP clock then other patch for eLBC still valid. If there is possibility of this frequency may require for future flash. I agree we should keep device tree fix-up code for eLBC.
For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. It is missing for now :(
Regarding RDNOUT, let me check and come back on the mail thread.
--prabhakar
On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 6:05 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
> So better to print IP clock to avoid any confusion. > IFC output clock will be printed when it is actually being used during synchronous NOR, syn NAND.
I am not against changing it to internal clock. But what are you going to print on the console? I think it is confusing to say IFC or local bus internal clock speed. Please also check how this clock is used and make sure arch.lbc_clk is still correct, after passing to Linux.
arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT
(Prabhakar, can you answer my question of whether
there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out.
IFC frequency means IP clock or IP output clock?
External bus clock. Which is currently being written to the device tree?
If IP clock then other patch for eLBC still valid.
What other patch?
For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. It is missing for now :(
No, we don't want to introduce new clock-frequency fixups. If we need this on IFC we should add a clocks property. But if we already have clock-frequency on eLBC then no reason not to use that if needed.
-Scott
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 7:30 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 6:05 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
>> So better to print IP clock to avoid any confusion. >> IFC output clock will be printed when it is actually being used during > synchronous NOR, syn NAND. > > I am not against changing it to internal clock. But what are you going > to print on the console? I think it is confusing to say IFC or local bus > internal clock speed. Please also check how this clock is used and make > sure arch.lbc_clk is still correct, after passing to Linux. > arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT
(Prabhakar, can you answer my question of whether
there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out.
IFC frequency means IP clock or IP output clock?
External bus clock. Which is currently being written to the device tree?
Currently, for eLBC IP output clock is being written in as freq_localbus hence "bus-frequency" Output IP clock is being calculated using CCB/LCR.
If IP clock then other patch for eLBC still valid.
What other patch?
http://patchwork.ozlabs.org/patch/666848/
--prabhakar
Hi Scott,
Sorry for late reply on this thread
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 7:30 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 6:05 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
>> So better to print IP clock to avoid any confusion. >> IFC output clock will be printed when it is actually being used during > synchronous NOR, syn NAND. > > I am not against changing it to internal clock. But what are you going > to print on the console? I think it is confusing to say IFC or local bus > internal clock speed. Please also check how this clock is used and make > sure arch.lbc_clk is still correct, after passing to Linux. > arch.lbc_clk is only being used for eLBC for device tree fixup. And I checked the Linux eLBC driver. Looks like it is not using used.
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT
(Prabhakar, can you answer my question of whether
there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out.
IFC frequency means IP clock or IP output clock?
External bus clock. Which is currently being written to the device tree?
If IP clock then other patch for eLBC still valid.
What other patch?
For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. It is missing for now :(
No, we don't want to introduce new clock-frequency fixups. If we need this on IFC we should add a clocks property. But if we already have clock-frequency on eLBC then no reason not to use that if needed.
I am not against keeping " bus-frequency" on eLBC. (U-boot fixup bus-frequency not clock-frequncy)
But the value which is getting assigned to " bus-frequency" is not right. Currently, it is setting SYSCLK/LCRR i.e. output clock where eLBC run at CCB or CCB/2. So, if we want to have " bus-frequency " on eLBC then it needs to be corrected.
--prabhakar
On 09/22/2016 03:55 AM, Prabhakar Kushwaha wrote:
Hi Scott,
Sorry for late reply on this thread
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 7:30 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: Scott Wood Sent: Friday, September 09, 2016 6:05 AM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; york sun york.sun@nxp.com; u-boot@lists.denx.de Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
-----Original Message----- From: york sun Sent: Thursday, September 08, 2016 9:22 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; u- boot@lists.denx.de; Scott Wood scott.wood@nxp.com Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
<snip>
>>> So better to print IP clock to avoid any confusion. >>> IFC output clock will be printed when it is actually being used during >> synchronous NOR, syn NAND. >> >> I am not against changing it to internal clock. But what are you going >> to print on the console? I think it is confusing to say IFC or local bus >> internal clock speed. Please also check how this clock is used and make >> sure arch.lbc_clk is still correct, after passing to Linux. >> > arch.lbc_clk is only being used for eLBC for device tree fixup. > And I checked the Linux eLBC driver. Looks like it is not using used. >
If this clock is not used, can we drop it completely?
From my point of view Yes.
Scott, Please advice
Well, there is that patch from Matt Weber that is trying to guess the IFC frequency in order to use NWAIT... Not sure if we'll end up actually using NWAIT
(Prabhakar, can you answer my question of whether
there is a better opcode to use with RNDOUT?) or ever sending a real RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but if U-Boot is currently writing the clock frequency into the device tree I don't see why we'd rip it out.
IFC frequency means IP clock or IP output clock?
External bus clock. Which is currently being written to the device tree?
If IP clock then other patch for eLBC still valid.
What other patch?
For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC. It is missing for now :(
No, we don't want to introduce new clock-frequency fixups. If we need this on IFC we should add a clocks property. But if we already have clock-frequency on eLBC then no reason not to use that if needed.
I am not against keeping " bus-frequency" on eLBC. (U-boot fixup bus-frequency not clock-frequncy)
But the value which is getting assigned to " bus-frequency" is not right. Currently, it is setting SYSCLK/LCRR i.e. output clock where eLBC run at CCB or CCB/2. So, if we want to have " bus-frequency " on eLBC then it needs to be corrected.
If the fixup is not correct then just remove it.
-Scott
participants (3)
-
Prabhakar Kushwaha -
Scott Wood -
york sun