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_H6default nhelpEnable this option if you want U-Boot check for an eMMC deviceon Allwinner H6 boards, and enable the SPI flash if none is found.SPI0 and MMC2 share one pin, so cannot coexist in Linux. TheDT 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.