All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <oss@buserror.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled
Date: Tue, 29 Mar 2016 15:44:43 -0500	[thread overview]
Message-ID: <1459284283.32510.1.camel@buserror.net> (raw)
In-Reply-To: <AM2PR04MB09641B052234B3469ECCA9EAE7B50@AM2PR04MB0964.eurprd04.prod.outlook.com>

On Fri, 2016-03-11 at 10:18 +0000, Qianyu Gong wrote:
> Hi Scott,
> 
> > -----Original Message-----
> > From: Scott Wood [mailto:oss at buserror.net]
> > Sent: Tuesday, February 23, 2016 8:12 AM
> > To: Qianyu Gong <qianyu.gong@nxp.com>; u-boot at 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

  parent reply	other threads:[~2016-03-29 20:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-22 10:05 [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled Gong Qianyu
2016-02-22 11:51 ` Prabhakar Kushwaha
2016-03-11 10:32   ` Qianyu Gong
2016-02-23  0:11 ` Scott Wood
2016-03-11 10:18   ` Qianyu Gong
2016-03-28  8:51     ` Prabhakar Kushwaha
2016-03-28  9:43       ` Qianyu Gong
2016-03-29 20:44     ` Scott Wood [this message]
2016-03-30  6:20       ` Qianyu Gong
2016-03-31  2:38         ` Scott Wood
2016-07-19 21:57           ` york sun
2016-07-20  6:39             ` Qianyu Gong
2016-07-20 21:25               ` york sun
2016-07-21  3:51                 ` Qianyu Gong
2016-03-28  8:11 ` Qianyu Gong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1459284283.32510.1.camel@buserror.net \
    --to=oss@buserror.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.