[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

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
-- 
1.9.1

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[york sun]

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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -----Original Message-----
> From: york sun
> Sent: Tuesday, September 06, 2016 9:10 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[york sun]

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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -----Original Message-----
> From: york sun
> Sent: Wednesday, September 07, 2016 9:17 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[york sun]

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 at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -----Original Message-----
> From: york sun
> Sent: Thursday, September 08, 2016 7:33 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at 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 at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[york sun]

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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -----Original Message-----
> From: york sun
> Sent: Thursday, September 08, 2016 9:22 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Scott Wood]

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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -----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 at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Scott Wood]

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 at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

> -----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 at 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 at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Prabhakar Kushwaha]

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 at 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 at 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 at 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

[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Scott Wood]

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 at 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 at 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 at 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