diff mbox

[U-Boot] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled

Message ID 1456135520-48373-1-git-send-email-Qianyu.Gong@nxp.com
State Superseded
Delegated to: York Sun
Headers show

Commit Message

Gong Qianyu Feb. 22, 2016, 10:05 a.m. UTC 
QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
IFC should be disabled.
But just disable IFC driver in LS1043A Linux is not enough because
mdio-mux will access IFC address space -- actually it accesses FPGA
which is connected to IFC CS3. So disable the whole IFC node in
Linux device tree.

Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>

Comments

Prabhakar Kushwaha Feb. 22, 2016, 11:51 a.m. UTC | #1 
> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Gong
> Qianyu
> Sent: Monday, February 22, 2016 3:35 PM
> To: u-boot@lists.denx.de; york sun <york.sun@nxp.com>; oss@buserror.net
> Cc: Qianyu Gong <qianyu.gong@nxp.com>; Mingkai Hu
> <mingkai.hu@nxp.com>
> Subject: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> with QSPI enabled
> 
> QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled, IFC
> should be disabled.
> But just disable IFC driver in LS1043A Linux is not enough because mdio-mux
> will access IFC address space -- actually it accesses FPGA which is connected
> to IFC CS3. So disable the whole IFC node in Linux device tree.
> 

FPGA and NAND access are valid use-case during QSPI boot

So why IFC controller is being disabled from device tree. 

> Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 4e4861d..5bb3048 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> CONFIG_FSL_LSCH3
>  	fdt_fixup_smmu(blob);
>  #endif
> +
> +#ifdef CONFIG_LS1043A

I will suggest to avoid SoC specific defines

--prabhakar
Crystal Wood Feb. 23, 2016, 12:11 a.m. UTC | #2 
On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> IFC should be disabled.
> But just disable IFC driver in LS1043A Linux is not enough because
> mdio-mux will access IFC address space -- actually it accesses FPGA
> which is connected to IFC CS3. So disable the whole IFC node in
> Linux device tree.
> 
> Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 4e4861d..5bb3048 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_FSL_LSCH3
>  	fdt_fixup_smmu(blob);
>  #endif
> +
> +#ifdef CONFIG_LS1043A
> +#ifdef CONFIG_FSL_QSPI
> +	do_fixup_by_compat(blob, "fsl,ifc",
> +			   "status", "disabled", 8 + 1, 1);
> +#endif
> +#endif
>  }

This muxing is done at runtime, right?  It isn't a case of the board
hardwiring one or the other?  In that case, it should be handled at runtime
here as well.  At a minimum, allow the user to use hwconfig to choose which
they want to be accessible.  Ideally there would be something in the device
tree to list the reason(s) for a device being disabled, so the OS knows it can
regard the device as being enabled if it knows about and enables them all.

-Scott
Gong Qianyu March 11, 2016, 10:18 a.m. UTC | #3 
Hi Scott,

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Tuesday, February 23, 2016 8:12 AM
> To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york sun
> <york.sun@nxp.com>
> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > IFC should be disabled.
> > But just disable IFC driver in LS1043A Linux is not enough because
> > mdio-mux will access IFC address space -- actually it accesses FPGA
> > which is connected to IFC CS3. So disable the whole IFC node in Linux
> > device tree.
> >
> > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 4e4861d..5bb3048 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_FSL_LSCH3
> >  	fdt_fixup_smmu(blob);
> >  #endif
> > +
> > +#ifdef CONFIG_LS1043A
> > +#ifdef CONFIG_FSL_QSPI
> > +	do_fixup_by_compat(blob, "fsl,ifc",
> > +			   "status", "disabled", 8 + 1, 1); #endif #endif
> >  }
> 
> This muxing is done at runtime, right?  It isn't a case of the board hardwiring one
> or the other?  In that case, it should be handled at runtime here as well.  At a
> minimum, allow the user to use hwconfig to choose which they want to be
> accessible.  Ideally there would be something in the device tree to list the reason(s)
> for a device being disabled, so the OS knows it can regard the device as being
> enabled if it knows about and enables them all.
> 
> -Scott

Sorry for the late reply. We have been asking the silicon team for the details of the pin 
muxing these days. 
The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as long as QSPI is 
enabled on LS1043AQDS board. 
As I know, this muxing won't be handled in kernel. Since IFC is disabled in U-Boot, 
IFC node would better be disabled in kernel as well.
Also in such cases, users have no other choice.


Regards,
Qianyu
Gong Qianyu March 11, 2016, 10:32 a.m. UTC | #4 
Hi Prabhakar,

> -----Original Message-----
> From: Prabhakar Kushwaha
> Sent: Monday, February 22, 2016 7:51 PM
> To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york sun
> <york.sun@nxp.com>; oss@buserror.net
> Cc: Qianyu Gong <qianyu.gong@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>
> Subject: RE: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> with QSPI enabled
> 
> 
> > -----Original Message-----
> > From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Gong
> > Qianyu
> > Sent: Monday, February 22, 2016 3:35 PM
> > To: u-boot@lists.denx.de; york sun <york.sun@nxp.com>;
> > oss@buserror.net
> > Cc: Qianyu Gong <qianyu.gong@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>
> > Subject: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> > LS1043A with QSPI enabled
> >
> > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > IFC should be disabled.
> > But just disable IFC driver in LS1043A Linux is not enough because
> > mdio-mux will access IFC address space -- actually it accesses FPGA
> > which is connected to IFC CS3. So disable the whole IFC node in Linux device tree.
> >
> 
> FPGA and NAND access are valid use-case during QSPI boot
> 
> So why IFC controller is being disabled from device tree.
> 

As Mingkai explained, neither FGPA nor NAND is valid when QSPI is enabled on LS1043AQDS.

> > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 4e4861d..5bb3048 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_FSL_LSCH3
> >  	fdt_fixup_smmu(blob);
> >  #endif
> > +
> > +#ifdef CONFIG_LS1043A
> 
> I will suggest to avoid SoC specific defines
> 
> --prabhakar

I think only LS1043A needs this fixup for the moment.
So if there's any change on new chips, it wouldn't affect them.


Regards,
Qianyu
Gong Qianyu March 28, 2016, 8:11 a.m. UTC | #5 
Hi all,

Any comments about this patch? Thanks!

Regards,
Qianyu

> -----Original Message-----
> From: Gong Qianyu [mailto:Qianyu.Gong@nxp.com]
> Sent: Monday, February 22, 2016 6:05 PM
> To: u-boot@lists.denx.de; york sun <york.sun@nxp.com>; oss@buserror.net
> Cc: Mingkai Hu <mingkai.hu@nxp.com>; Qianyu Gong <qianyu.gong@nxp.com>
> Subject: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> IFC should be disabled.
> But just disable IFC driver in LS1043A Linux is not enough because
> mdio-mux will access IFC address space -- actually it accesses FPGA
> which is connected to IFC CS3. So disable the whole IFC node in
> Linux device tree.
> 
> Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-
> layerscape/fdt.c
> index 4e4861d..5bb3048 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_FSL_LSCH3
>  	fdt_fixup_smmu(blob);
>  #endif
> +
> +#ifdef CONFIG_LS1043A
> +#ifdef CONFIG_FSL_QSPI
> +	do_fixup_by_compat(blob, "fsl,ifc",
> +			   "status", "disabled", 8 + 1, 1);
> +#endif
> +#endif
>  }
> --
> 2.1.0.27.g96db324
Prabhakar Kushwaha March 28, 2016, 8:51 a.m. UTC | #6 
> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Qianyu
> Gong
> Sent: Friday, March 11, 2016 3:49 PM
> To: Scott Wood <oss@buserror.net>; u-boot@lists.denx.de; york sun
> <york.sun@nxp.com>
> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> Subject: Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> LS1043A with QSPI enabled
> 
> Hi Scott,
> 
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Tuesday, February 23, 2016 8:12 AM
> > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york
> sun
> > <york.sun@nxp.com>
> > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > with QSPI enabled
> >
> > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > > IFC should be disabled.
> > > But just disable IFC driver in LS1043A Linux is not enough because
> > > mdio-mux will access IFC address space -- actually it accesses FPGA
> > > which is connected to IFC CS3. So disable the whole IFC node in
> > > Linux device tree.
> > >
> > > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> > >
> > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > index 4e4861d..5bb3048 100644
> > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > > CONFIG_FSL_LSCH3
> > >  	fdt_fixup_smmu(blob);
> > >  #endif
> > > +
> > > +#ifdef CONFIG_LS1043A
> > > +#ifdef CONFIG_FSL_QSPI
> > > +	do_fixup_by_compat(blob, "fsl,ifc",
> > > +			   "status", "disabled", 8 + 1, 1); #endif #endif
> > >  }
> >
> > This muxing is done at runtime, right?  It isn't a case of the board
> > hardwiring one or the other?  In that case, it should be handled at
> > runtime here as well.  At a minimum, allow the user to use hwconfig to
> > choose which they want to be accessible.  Ideally there would be
> > something in the device tree to list the reason(s) for a device being
> > disabled, so the OS knows it can regard the device as being enabled if it
> knows about and enables them all.
> >
> > -Scott
> 
> Sorry for the late reply. We have been asking the silicon team for the details
> of the pin muxing these days.
> The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as long as
> QSPI is enabled on LS1043AQDS board.
> As I know, this muxing won't be handled in kernel. Since IFC is disabled in U-
> Boot, IFC node would better be disabled in kernel as well.
> Also in such cases, users have no other choice.
> 

This may not be always true.  

 In LS1088A, IFC-FPGA is available during QSPI boot.

--prabhakar
Gong Qianyu March 28, 2016, 9:43 a.m. UTC | #7 
Hi Prabhakar,

> -----Original Message-----
> From: Prabhakar Kushwaha
> Sent: Monday, March 28, 2016 4:52 PM
> To: Qianyu Gong <qianyu.gong@nxp.com>; Scott Wood <oss@buserror.net>; u-
> boot@lists.denx.de; york sun <york.sun@nxp.com>
> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> Subject: RE: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> 
> > -----Original Message-----
> > From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Qianyu
> > Gong
> > Sent: Friday, March 11, 2016 3:49 PM
> > To: Scott Wood <oss@buserror.net>; u-boot@lists.denx.de; york sun
> > <york.sun@nxp.com>
> > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > Subject: Re: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for
> > LS1043A with QSPI enabled
> >
> > Hi Scott,
> >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york
> > sun
> > > <york.sun@nxp.com>
> > > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > with QSPI enabled
> > >
> > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > enabled, IFC should be disabled.
> > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > mdio-mux will access IFC address space -- actually it accesses
> > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > in Linux device tree.
> > > >
> > > > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index 4e4861d..5bb3048 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > #ifdef
> > > > CONFIG_FSL_LSCH3
> > > >  	fdt_fixup_smmu(blob);
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LS1043A
> > > > +#ifdef CONFIG_FSL_QSPI
> > > > +	do_fixup_by_compat(blob, "fsl,ifc",
> > > > +			   "status", "disabled", 8 + 1, 1); #endif #endif
> > > >  }
> > >
> > > This muxing is done at runtime, right?  It isn't a case of the board
> > > hardwiring one or the other?  In that case, it should be handled at
> > > runtime here as well.  At a minimum, allow the user to use hwconfig
> > > to choose which they want to be accessible.  Ideally there would be
> > > something in the device tree to list the reason(s) for a device
> > > being disabled, so the OS knows it can regard the device as being
> > > enabled if it
> > knows about and enables them all.
> > >
> > > -Scott
> >
> > Sorry for the late reply. We have been asking the silicon team for the
> > details of the pin muxing these days.
> > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > long as QSPI is enabled on LS1043AQDS board.
> > As I know, this muxing won't be handled in kernel. Since IFC is
> > disabled in U- Boot, IFC node would better be disabled in kernel as well.
> > Also in such cases, users have no other choice.
> >
> 
> This may not be always true.
> 
>  In LS1088A, IFC-FPGA is available during QSPI boot.
> 
> --prabhakar
> 

Yes, you're right. That's why I added "#ifdef CONFIG_LS1043A".
So I think it only affects ls1043a so far.

Regards,
Qianyu
Crystal Wood March 29, 2016, 8:44 p.m. UTC | #8 
On Fri, 2016-03-11 at 10:18 +0000, Qianyu Gong wrote:
> Hi Scott,
> 
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Tuesday, February 23, 2016 8:12 AM
> > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york sun
> > <york.sun@nxp.com>
> > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with
> > QSPI
> > enabled
> > 
> > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is enabled,
> > > IFC should be disabled.
> > > But just disable IFC driver in LS1043A Linux is not enough because
> > > mdio-mux will access IFC address space -- actually it accesses FPGA
> > > which is connected to IFC CS3. So disable the whole IFC node in Linux
> > > device tree.
> > > 
> > > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> > > 
> > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > index 4e4861d..5bb3048 100644
> > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > > CONFIG_FSL_LSCH3
> > >  	fdt_fixup_smmu(blob);
> > >  #endif
> > > +
> > > +#ifdef CONFIG_LS1043A
> > > +#ifdef CONFIG_FSL_QSPI
> > > +	do_fixup_by_compat(blob, "fsl,ifc",
> > > +			   "status", "disabled", 8 + 1, 1); #endif
> > > #endif
> > >  }
> > 
> > This muxing is done at runtime, right?  It isn't a case of the board
> > hardwiring one
> > or the other?  In that case, it should be handled at runtime here as well.
> >   At a
> > minimum, allow the user to use hwconfig to choose which they want to be
> > accessible.  Ideally there would be something in the device tree to list
> > the reason(s)
> > for a device being disabled, so the OS knows it can regard the device as
> > being
> > enabled if it knows about and enables them all.
> > 
> > -Scott
> 
> Sorry for the late reply. We have been asking the silicon team for the
> details of the pin 
> muxing these days. 
> The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as long
> as QSPI is 
> enabled on LS1043AQDS board. 
> As I know, this muxing won't be handled in kernel. Since IFC is disabled in
> U-Boot, 
> IFC node would better be disabled in kernel as well.
> Also in such cases, users have no other choice.

Why should the user not have a choice to choose IFC over QSPI?  Where is the
muxing configured?

-Scott
Gong Qianyu March 30, 2016, 6:20 a.m. UTC | #9 
Hi Scott,

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Wednesday, March 30, 2016 4:45 AM
> To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york sun
> <york.sun@nxp.com>
> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On Fri, 2016-03-11 at 10:18 +0000, Qianyu Gong wrote:
> > Hi Scott,
> >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york
> > > sun <york.sun@nxp.com>
> > > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > with QSPI enabled
> > >
> > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > enabled, IFC should be disabled.
> > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > mdio-mux will access IFC address space -- actually it accesses
> > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > in Linux device tree.
> > > >
> > > > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > index 4e4861d..5bb3048 100644
> > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > #ifdef
> > > > CONFIG_FSL_LSCH3
> > > >  	fdt_fixup_smmu(blob);
> > > >  #endif
> > > > +
> > > > +#ifdef CONFIG_LS1043A
> > > > +#ifdef CONFIG_FSL_QSPI
> > > > +	do_fixup_by_compat(blob, "fsl,ifc",
> > > > +			   "status", "disabled", 8 + 1, 1); #endif
> > > > #endif
> > > >  }
> > >
> > > This muxing is done at runtime, right?  It isn't a case of the board
> > > hardwiring one or the other?  In that case, it should be handled at
> > > runtime here as well.
> > >   At a
> > > minimum, allow the user to use hwconfig to choose which they want to
> > > be accessible.  Ideally there would be something in the device tree
> > > to list the reason(s) for a device being disabled, so the OS knows
> > > it can regard the device as being enabled if it knows about and
> > > enables them all.
> > >
> > > -Scott
> >
> > Sorry for the late reply. We have been asking the silicon team for the
> > details of the pin muxing these days.
> > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > long as QSPI is enabled on LS1043AQDS board.
> > As I know, this muxing won't be handled in kernel. Since IFC is
> > disabled in U-Boot, IFC node would better be disabled in kernel as
> > well.
> > Also in such cases, users have no other choice.
> 
> Why should the user not have a choice to choose IFC over QSPI?  Where is the
> muxing configured?
> 
> -Scott

Because this muxing can't be changed at runtime.
Two ways so far to configure it:
1. SW6[1-4] switches on ls1043aqds board.
2. Modify QIXIS board config registers and reset the board.


Regards,
Qianyu
Crystal Wood March 31, 2016, 2:38 a.m. UTC | #10 
On Wed, 2016-03-30 at 06:20 +0000, Qianyu Gong wrote:
> Hi Scott,
> 
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Wednesday, March 30, 2016 4:45 AM
> > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york sun
> > <york.sun@nxp.com>
> > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with
> > QSPI
> > enabled
> > 
> > On Fri, 2016-03-11 at 10:18 +0000, Qianyu Gong wrote:
> > > Hi Scott,
> > > 
> > > > -----Original Message-----
> > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > Sent: Tuesday, February 23, 2016 8:12 AM
> > > > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot@lists.denx.de; york
> > > > sun <york.sun@nxp.com>
> > > > Cc: Mingkai Hu <mingkai.hu@nxp.com>
> > > > Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> > > > with QSPI enabled
> > > > 
> > > > On Mon, 2016-02-22 at 18:05 +0800, Gong Qianyu wrote:
> > > > > QSPI and IFC are pin-multiplexed on LS1043A. So if QSPI is
> > > > > enabled, IFC should be disabled.
> > > > > But just disable IFC driver in LS1043A Linux is not enough because
> > > > > mdio-mux will access IFC address space -- actually it accesses
> > > > > FPGA which is connected to IFC CS3. So disable the whole IFC node
> > > > > in Linux device tree.
> > > > > 
> > > > > Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
> > > > > 
> > > > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > index 4e4861d..5bb3048 100644
> > > > > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > > > > @@ -204,4 +204,11 @@ void ft_cpu_setup(void *blob, bd_t *bd)
> > > > > #ifdef
> > > > > CONFIG_FSL_LSCH3
> > > > >  	fdt_fixup_smmu(blob);
> > > > >  #endif
> > > > > +
> > > > > +#ifdef CONFIG_LS1043A
> > > > > +#ifdef CONFIG_FSL_QSPI
> > > > > +	do_fixup_by_compat(blob, "fsl,ifc",
> > > > > +			   "status", "disabled", 8 + 1, 1); #endif
> > > > > #endif
> > > > >  }
> > > > 
> > > > This muxing is done at runtime, right?  It isn't a case of the board
> > > > hardwiring one or the other?  In that case, it should be handled at
> > > > runtime here as well.
> > > >   At a
> > > > minimum, allow the user to use hwconfig to choose which they want to
> > > > be accessible.  Ideally there would be something in the device tree
> > > > to list the reason(s) for a device being disabled, so the OS knows
> > > > it can regard the device as being enabled if it knows about and
> > > > enables them all.
> > > > 
> > > > -Scott
> > > 
> > > Sorry for the late reply. We have been asking the silicon team for the
> > > details of the pin muxing these days.
> > > The conclusion is that all IFC interfaces(cs0/cs1/cs2) are disabled as
> > > long as QSPI is enabled on LS1043AQDS board.
> > > As I know, this muxing won't be handled in kernel. Since IFC is
> > > disabled in U-Boot, IFC node would better be disabled in kernel as
> > > well.
> > > Also in such cases, users have no other choice.
> > 
> > Why should the user not have a choice to choose IFC over QSPI?  Where is
> > the
> > muxing configured?
> > 
> > -Scott
> 
> Because this muxing can't be changed at runtime.
> Two ways so far to configure it:
> 1. SW6[1-4] switches on ls1043aqds board.
> 2. Modify QIXIS board config registers and reset the board.

These sound like runtime to me -- not compile time.

-Scott
York Sun July 19, 2016, 9:57 p.m. UTC | #11 
On 03/30/2016 07:39 PM, Scott Wood wrote:
> On Wed, 2016-03-30 at 06:20 +0000, Qianyu Gong wrote:

<snip>

>>
>> Because this muxing can't be changed at runtime.
>> Two ways so far to configure it:
>> 1. SW6[1-4] switches on ls1043aqds board.
>> 2. Modify QIXIS board config registers and reset the board.
>
> These sound like runtime to me -- not compile time.
>

Qianyu,

If one can change mux by either changing switches, or setting QIXIS 
registers, you should be able to read those status and run the fixup, agree?

York
Gong Qianyu July 20, 2016, 6:39 a.m. UTC | #12 
Hi York,

> -----Original Message-----
> From: york sun
> Sent: Wednesday, July 20, 2016 5:58 AM
> To: Scott Wood <oss@buserror.net>; Qianyu Gong <qianyu.gong@nxp.com>; u-
> boot@lists.denx.de
> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On 03/30/2016 07:39 PM, Scott Wood wrote:
> > On Wed, 2016-03-30 at 06:20 +0000, Qianyu Gong wrote:
> 
> <snip>
> 
> >>
> >> Because this muxing can't be changed at runtime.
> >> Two ways so far to configure it:
> >> 1. SW6[1-4] switches on ls1043aqds board.
> >> 2. Modify QIXIS board config registers and reset the board.
> >
> > These sound like runtime to me -- not compile time.
> >
> 
> Qianyu,
> 
> If one can change mux by either changing switches, or setting QIXIS registers, you
> should be able to read those status and run the fixup, agree?
> 
> York

Yes, we could read QIXIS registers at runtime. But the current argument is that if we need to
build two rcw&U-Boot images to support IFC or QSPI, which is already done on LS1021AQDS
and LS1043AQDS. This is made at compile time and I just have no idea to solve the rcw issue.
So.. how do you think about it?


Regards,
Qianyu
York Sun July 20, 2016, 9:25 p.m. UTC | #13 
On 07/19/2016 11:39 PM, Qianyu Gong wrote:
> Hi York,
>
>> -----Original Message-----
>> From: york sun
>> Sent: Wednesday, July 20, 2016 5:58 AM
>> To: Scott Wood <oss@buserror.net>; Qianyu Gong <qianyu.gong@nxp.com>; u-
>> boot@lists.denx.de
>> Cc: Mingkai Hu <mingkai.hu@nxp.com>
>> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
>> enabled
>>
>> On 03/30/2016 07:39 PM, Scott Wood wrote:
>>> On Wed, 2016-03-30 at 06:20 +0000, Qianyu Gong wrote:
>>
>> <snip>
>>
>>>>
>>>> Because this muxing can't be changed at runtime.
>>>> Two ways so far to configure it:
>>>> 1. SW6[1-4] switches on ls1043aqds board.
>>>> 2. Modify QIXIS board config registers and reset the board.
>>>
>>> These sound like runtime to me -- not compile time.
>>>
>>
>> Qianyu,
>>
>> If one can change mux by either changing switches, or setting QIXIS registers, you
>> should be able to read those status and run the fixup, agree?
>>
>> York
>
> Yes, we could read QIXIS registers at runtime. But the current argument is that if we need to
> build two rcw&U-Boot images to support IFC or QSPI, which is already done on LS1021AQDS
> and LS1043AQDS. This is made at compile time and I just have no idea to solve the rcw issue.
> So.. how do you think about it?
>

Having different SPL builds is not ideal, but that's what we have. 
Without introducing another mechanism, we cannot concatenate SPL with 
different RCW files.

On the other side, if condition can be detected at run time, please do 
so, even when the condition only applies to one of SPL boot method. We 
should reduce compile option as much as we can so we have less options 
to test.

York
Gong Qianyu July 21, 2016, 3:51 a.m. UTC | #14 
Hi York,

> -----Original Message-----
> From: york sun
> Sent: Thursday, July 21, 2016 5:25 AM
> To: Qianyu Gong <qianyu.gong@nxp.com>; Scott Wood <oss@buserror.net>; u-
> boot@lists.denx.de
> Cc: Mingkai Hu <mingkai.hu@nxp.com>; Huan Wang <alison.wang@nxp.com>
> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI
> enabled
> 
> On 07/19/2016 11:39 PM, Qianyu Gong wrote:
> > Hi York,
> >
> >> -----Original Message-----
> >> From: york sun
> >> Sent: Wednesday, July 20, 2016 5:58 AM
> >> To: Scott Wood <oss@buserror.net>; Qianyu Gong <qianyu.gong@nxp.com>;
> >> u- boot@lists.denx.de
> >> Cc: Mingkai Hu <mingkai.hu@nxp.com>
> >> Subject: Re: [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A
> >> with QSPI enabled
> >>
> >> On 03/30/2016 07:39 PM, Scott Wood wrote:
> >>> On Wed, 2016-03-30 at 06:20 +0000, Qianyu Gong wrote:
> >>
> >> <snip>
> >>
> >>>>
> >>>> Because this muxing can't be changed at runtime.
> >>>> Two ways so far to configure it:
> >>>> 1. SW6[1-4] switches on ls1043aqds board.
> >>>> 2. Modify QIXIS board config registers and reset the board.
> >>>
> >>> These sound like runtime to me -- not compile time.
> >>>
> >>
> >> Qianyu,
> >>
> >> If one can change mux by either changing switches, or setting QIXIS
> >> registers, you should be able to read those status and run the fixup, agree?
> >>
> >> York
> >
> > Yes, we could read QIXIS registers at runtime. But the current
> > argument is that if we need to build two rcw&U-Boot images to support
> > IFC or QSPI, which is already done on LS1021AQDS and LS1043AQDS. This is
> made at compile time and I just have no idea to solve the rcw issue.
> > So.. how do you think about it?
> >
> 
> Having different SPL builds is not ideal, but that's what we have.
> Without introducing another mechanism, we cannot concatenate SPL with
> different RCW files.
> 
> On the other side, if condition can be detected at run time, please do so, even
> when the condition only applies to one of SPL boot method. We should reduce
> compile option as much as we can so we have less options to test.
> 
> York

OK, thanks. I'll have a try. 
Since the muxing is board-specific, I'd also like to move it to ft_board_setup().


Regards,
Qianyu
diff mbox

Patch

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4e4861d..5bb3048 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -204,4 +204,11 @@  void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FSL_LSCH3
 	fdt_fixup_smmu(blob);
 #endif
+
+#ifdef CONFIG_LS1043A
+#ifdef CONFIG_FSL_QSPI
+	do_fixup_by_compat(blob, "fsl,ifc",
+			   "status", "disabled", 8 + 1, 1);
+#endif
+#endif
 }