From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8E3D8C433EF for ; Thu, 24 Feb 2022 11:00:44 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3317783C97; Thu, 24 Feb 2022 12:00:38 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id D0C4E83C97; Thu, 24 Feb 2022 12:00:36 +0100 (CET) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id C455F83BD3 for ; Thu, 24 Feb 2022 12:00:30 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0B3AE106F; Thu, 24 Feb 2022 03:00:30 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 76A593F70D; Thu, 24 Feb 2022 03:00:28 -0800 (PST) Date: Thu, 24 Feb 2022 11:00:24 +0000 From: Andre Przywara To: Jagan Teki Cc: Simon Glass , Tom Rini , Chen-Yu Tsai , Hauke Mehrtens , Jernej Skrabec , Samuel Holland , Icenowy Zheng , Joe Hershberger , Wolfgang Denk , Daniel Wagenknecht , u-boot@lists.denx.de Subject: Re: [PATCH 7/7] sunxi: H6: Enable SPI0 in DT when no eMMC is used Message-ID: <20220224110024.1de2e092@donnerap.cambridge.arm.com> In-Reply-To: References: <20220111124607.863952-1-andre.przywara@arm.com> <20220111124607.863952-8-andre.przywara@arm.com> <20220120140624.5f828b3e@donnerap.cambridge.arm.com> Organization: ARM X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On Thu, 24 Feb 2022 13:00:56 +0530 Jagan Teki wrote: Hi Jagan, > On Thu, Jan 20, 2022 at 8:06 PM Jagan Teki wrote: > > > > On Thu, Jan 20, 2022 at 7:36 PM Andre Przywara wrote: > > > > > > On Thu, 20 Jan 2022 19:08:57 +0530 > > > Jagan Teki wrote: > > > > > > Hi, > > > > > > > On Tue, Jan 11, 2022 at 6:16 PM Andre Przywara wrote: > > > > > > > > > > On the Allwinner H6 SoC both the SPI0 and the eMMC device share one pin, > > > > > so cannot be used simultaneously. On Linux this is a showstopper, since > > > > > only one of them would be able to claim the pin, and the probe order is > > > > > somewhat random. The DT consequently disables SPI0 in favour of the more > > > > > useful eMMC. > > > > > > > > > > But a comment in the DT actually suggests that this could be reversed by > > > > > U-Boot, if no eMMC is actually connected. Let's now implement this: > > > > > When we fix up the device tree before booting a kernel, we iterate over > > > > > all MMC devices, and check if there is an eMMC device among them. If none > > > > > can be found, we enable SPI0 instead, to allow Linux access to the SPI > > > > > flash. > > > > > > > > > Since this fixup is not really universally applicable to all boards, > > > > > let's hide it behind a Kconfig option, and enable it only on the one > > > > > supported board where this makes sense: the Pine H64. > > > > > > > > > > Please note that the SPI functionality is still disabled in U-Boot > > > > > proper, the pinmux clash affects us too: it would always disable the eMMC > > > > > and so spoil this algorithm here. > > > > > > > > > > Signed-off-by: Andre Przywara > > > > > --- > > > > > arch/arm/mach-sunxi/Kconfig | 10 ++++++++ > > > > > board/sunxi/board.c | 50 +++++++++++++++++++++++++++++++++++++ > > > > > configs/pine_h64_defconfig | 1 + > > > > > 3 files changed, 61 insertions(+) > > > > > > > > > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > > > > > index 56ff1e197c..ce66453029 100644 > > > > > --- a/arch/arm/mach-sunxi/Kconfig > > > > > +++ b/arch/arm/mach-sunxi/Kconfig > > > > > @@ -1047,6 +1047,16 @@ config BLUETOOTH_DT_DEVICE_FIXUP > > > > > The used address is "bdaddr" if set, and "ethaddr" with the LSB > > > > > flipped elsewise. > > > > > > > > > > +config SUNXI_H6_ENABLE_SPIFLASH > > > > > + bool "Enable H6 SPI flash vs. eMMC enablement" > > > > > + depends on MACH_SUN50I_H6 > > > > > + default n > > > > > + help > > > > > + Enable this option if you want U-Boot check for an eMMC device > > > > > + on Allwinner H6 boards, and enable the SPI flash if none is found. > > > > > + SPI0 and MMC2 share one pin, so cannot coexist in Linux. The > > > > > + DT prefers eMMC, but if none is used, we can safely enable SPI. > > > > > > > > Why we need a separate macro, cannot we check it H6 globally as it SoC design? > > > > > > This "hack" is board dependent. We don't know if there is a SPI flash or > > > eMMC in the first place, and this whole concept is weird enough that it > > > warrants a separate config option. > > > Probably due to this hardware issue the PineH64 is actually the only board > > > in mainline that has both SPI flash and eMMC, and I don't want to enable > > > SPI flash on every eMMC less board. Also it simplifies the code if we can > > > assume that both DT nodes exist, when that config is enabled. > > > > > > Cheers, > > > Andre > > > > > > P.S. Actually I wanted to forgot to mark this one as RFC, as I am not sure > > > that it's justified. The comment in the mainline DT suggests this > > > solution, and I was curious what it would take to make it work, as > > > apparently some people are interested in it. > > > > If it board-specific, better switch to RFC or load the overlay by > > checking on board specific boot script. > > Anything about this? Yeah, I meant to tag this patch as RFC (as I mentioned in the cover letter), but the actually forgot to do it. So overlays would be one solution - for kernels, at least, though not for U-Boot. Is there some framework / functionality in place to automatically apply them (outside of some user specific scripting)? I will have a think about that, and will drop this patch for now. Cheers, Andre