From: Andre Przywara <andre.przywara@arm.com>
To: Jagan Teki <jagan@amarulasolutions.com>
Cc: Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>,
Chen-Yu Tsai <wens@csie.org>, Hauke Mehrtens <hauke@hauke-m.de>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Icenowy Zheng <icenowy@aosc.xyz>,
Joe Hershberger <joe.hershberger@ni.com>,
Wolfgang Denk <wd@denx.de>,
Daniel Wagenknecht <dwagenk@mailbox.org>,
u-boot@lists.denx.de
Subject: Re: [PATCH 7/7] sunxi: H6: Enable SPI0 in DT when no eMMC is used
Date: Thu, 20 Jan 2022 14:06:24 +0000 [thread overview]
Message-ID: <20220120140624.5f828b3e@donnerap.cambridge.arm.com> (raw)
In-Reply-To: <CAMty3ZD9LFyaHDNmJ5cjer3rg0g2_pzwxer5nLXOa+5ODM9fEA@mail.gmail.com>
On Thu, 20 Jan 2022 19:08:57 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:
Hi,
> On Tue, Jan 11, 2022 at 6:16 PM Andre Przywara <andre.przywara@arm.com> 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 <andre.przywara@arm.com>
> > ---
> > 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.
next prev parent reply other threads:[~2022-01-20 14:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 12:46 [PATCH 0/7] sunxi: Fix U-Boot proper SPI operation Andre Przywara
2022-01-11 12:46 ` [PATCH 1/7] sunxi: SPI: fix pinmuxing for Allwinner H6 SoCs Andre Przywara
2022-01-11 12:46 ` [PATCH 2/7] sunxi: Kconfig: Fix up SPI configuration Andre Przywara
2022-01-24 17:02 ` Andre Przywara
2022-02-24 7:26 ` Jagan Teki
2022-02-24 7:26 ` Jagan Teki
2022-01-11 12:46 ` [PATCH 3/7] env: sunxi: Define location in SPI flash Andre Przywara
2022-01-11 12:46 ` [PATCH 4/7] sunxi: use boot source for determining environment location Andre Przywara
2022-04-15 17:28 ` Chris Morgan
2022-04-20 23:33 ` Andre Przywara
2022-05-05 15:43 ` Chris Morgan
2022-01-11 12:46 ` [PATCH 5/7] env: sunxi: enable ENV_IS_IN_SPI_FLASH Andre Przywara
2022-01-11 12:46 ` [PATCH 6/7] sunxi: boards: Enable SPI flash support in U-Boot proper Andre Przywara
2022-01-11 12:46 ` [PATCH 7/7] sunxi: H6: Enable SPI0 in DT when no eMMC is used Andre Przywara
2022-01-20 13:38 ` Jagan Teki
2022-01-20 14:06 ` Andre Przywara [this message]
2022-01-20 14:36 ` Jagan Teki
2022-02-24 7:30 ` Jagan Teki
2022-02-24 11:00 ` Andre Przywara
2022-03-10 12:05 ` [PATCH 0/7] sunxi: Fix U-Boot proper SPI operation Jagan Teki
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=20220120140624.5f828b3e@donnerap.cambridge.arm.com \
--to=andre.przywara@arm.com \
--cc=dwagenk@mailbox.org \
--cc=hauke@hauke-m.de \
--cc=icenowy@aosc.xyz \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=joe.hershberger@ni.com \
--cc=samuel@sholland.org \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=wd@denx.de \
--cc=wens@csie.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox