From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qianyu Gong Date: Fri, 11 Mar 2016 10:18:47 +0000 Subject: [U-Boot] [PATCH] armv8/fsl-layerscape: add IFC fixup for LS1043A with QSPI enabled In-Reply-To: <1456186306.2463.103.camel@buserror.net> References: <1456135520-48373-1-git-send-email-Qianyu.Gong@nxp.com> <1456186306.2463.103.camel@buserror.net> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Scott, > -----Original Message----- > From: Scott Wood [mailto:oss at buserror.net] > Sent: Tuesday, February 23, 2016 8:12 AM > To: Qianyu Gong ; u-boot at lists.denx.de; york sun > > Cc: Mingkai Hu > 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 > > > > 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