[PATCH 0/2] arm64: dts: sun50i: H6: Enable SPI flash

131 views
Skip to first unread message

Andre Przywara

unread,
Jan 8, 2020, 5:10:29 AM1/8/20
to Maxime Ripard, Chen-Yu Tsai, Mark Brown, linu...@vger.kernel.org, linux-ar...@lists.infradead.org, linux...@googlegroups.com, Icenowy Zheng, devic...@vger.kernel.org, Rob Herring, Mark Rutland
Even though the SPI controller in the Allwinner H6 SoC is more advanced
than in the previous generations (it supports 3-wire and 4-wire mode),
the register set stayed backwards-compatible. So we can use the existing
driver to use the "normal" SPI mode, for instance to access the SPI
flash soldered on the Pine H64 board.

These two patches allow this by adding the SPI controller nodes to the
DT. The compatible strings include an H6 specific name, so that any
future 4-wire enhancements for instance would be automatically usable
once the driver learns this new trick. For now we use the H3 fallback
name to bind the current driver.

This time I tested this actual branch ;-) (on top of sunxi/dt-for-5.6),
on a Pine H64, both the internal SPI flash as well with SPI flash
connected to the other SPI controller available on the GPIO headers.

One thing I noticed: Only SPI0 seems to connect the two extra pins
required for 4-wire mode. Does this require some extra DT property or
the like? Can we derive this from the number of pins in the pinctrl-0
property? Or will we later introduce a new compatible string to prepend
to the current list?

Cheers,
Andre.

Andre Przywara (2):
arm64: dts: sun50i: H6: Add SPI controllers nodes and pinmuxes
arm64: dts: allwinner: h6: Pine H64: Add SPI flash node

.../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 13 +++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 54 +++++++++++++++++++
2 files changed, 67 insertions(+)

--
2.17.1

Andre Przywara

unread,
Jan 8, 2020, 5:10:30 AM1/8/20
to Maxime Ripard, Chen-Yu Tsai, Mark Brown, linu...@vger.kernel.org, linux-ar...@lists.infradead.org, linux...@googlegroups.com, Icenowy Zheng, devic...@vger.kernel.org, Rob Herring, Mark Rutland
The Allwinner H6 SoC contains two SPI controllers similar to the H3/A64,
but with the added capability of 3-wire and 4-wire operation modes.
For now the driver does not support those, but the SPI registers are
fully backwards-compatible, just adding bits and registers which were
formerly reserved. So we can use the existing driver for the "normal" SPI
modes, for instance to access the SPI NOR flash soldered on the PineH64
board.
We use an H6 specific compatible string in addition to the existing H3
string, so when the driver later gains Quad SPI support, it should work
automatically without any DT changes.

Tested by accessing the SPI flash on a Pine H64 board (SPI0), also
connecting another SPI flash to the SPI1 header pins.

Signed-off-by: Andre Przywara <andre.p...@arm.com>
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 54 ++++++++++++++++++++
1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 3329283e38ab..40835850893e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -338,6 +338,30 @@
bias-pull-up;
};

+ /omit-if-no-ref/
+ spi0_pins: spi0-pins {
+ pins = "PC0", "PC2", "PC3";
+ function = "spi0";
+ };
+
+ /omit-if-no-ref/
+ spi0_cs_pin: spi0-cs-pin {
+ pins = "PC5";
+ function = "spi0";
+ };
+
+ /omit-if-no-ref/
+ spi1_pins: spi1-pins {
+ pins = "PH4", "PH5", "PH6";
+ function = "spi1";
+ };
+
+ /omit-if-no-ref/
+ spi1_cs_pin: spi1-cs-pin {
+ pins = "PH3";
+ function = "spi1";
+ };
+
spdif_tx_pin: spdif-tx-pin {
pins = "PH7";
function = "spdif";
@@ -504,6 +528,36 @@
#size-cells = <0>;
};

+ spi0: spi@5010000 {
+ compatible = "allwinner,sun50i-h6-spi",
+ "allwinner,sun8i-h3-spi";
+ reg = <0x05010000 0x1000>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 22>, <&dma 22>;
+ dma-names = "rx", "tx";
+ resets = <&ccu RST_BUS_SPI0>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi1: spi@5011000 {
+ compatible = "allwinner,sun50i-h6-spi",
+ "allwinner,sun8i-h3-spi";
+ reg = <0x05011000 0x1000>;
+ interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;
+ clock-names = "ahb", "mod";
+ dmas = <&dma 23>, <&dma 23>;
+ dma-names = "rx", "tx";
+ resets = <&ccu RST_BUS_SPI1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
emac: ethernet@5020000 {
compatible = "allwinner,sun50i-h6-emac",
"allwinner,sun50i-a64-emac";
--
2.17.1

Andre Przywara

unread,
Jan 8, 2020, 5:10:32 AM1/8/20
to Maxime Ripard, Chen-Yu Tsai, Mark Brown, linu...@vger.kernel.org, linux-ar...@lists.infradead.org, linux...@googlegroups.com, Icenowy Zheng, devic...@vger.kernel.org, Rob Herring, Mark Rutland
The Pine H64 board comes with SPI flash soldered on the board, connected
to the SPI0 pins (so it can also boot from there).

Add the required DT node to make the flash accessible from Linux.

Signed-off-by: Andre Przywara <andre.p...@arm.com>
---
.../arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index d1c2aa5b3a20..a72f605a3a64 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -14,6 +14,7 @@
aliases {
ethernet0 = &emac;
serial0 = &uart0;
+ spi0 = &spi0;
};

chosen {
@@ -278,6 +279,18 @@
vcc-pm-supply = <&reg_aldo1>;
};

+&spi0 {
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs_pin>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ flash@0 {
+ compatible = "winbond,w25q128", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000000>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_ph_pins>;
--
2.17.1

Clément Péron

unread,
Jan 8, 2020, 5:45:28 AM1/8/20
to Andre Przywara, Maxime Ripard, Chen-Yu Tsai, Mark Brown, linu...@vger.kernel.org, linux-arm-kernel, linux-sunxi, Icenowy Zheng, devicetree, Rob Herring, Mark Rutland
Hi Andre,
You need to document this compatible in the dt-bindings to avoid any warnings.

Regards,
Clement
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20200108101006.150706-2-andre.przywara%40arm.com.

Andre Przywara

unread,
Jan 8, 2020, 6:47:26 AM1/8/20
to Emmanuel Vadot, Maxime Ripard, Chen-Yu Tsai, Mark Rutland, devic...@vger.kernel.org, Rob Herring, linu...@vger.kernel.org, linux...@googlegroups.com, Mark Brown, Icenowy Zheng, linux-ar...@lists.infradead.org
On Wed, 8 Jan 2020 12:34:48 +0100
Emmanuel Vadot <ma...@bidouilliste.com> wrote:

Hi Emmanuel,
> That would prevent users to use an overlay and use those pins, is that
> something that we want ? I'm not sure that the space saved by those are
> useful.

Me neither ;-), but Maxime asked for it before, and it doesn't really hurt.

For overlays: if a .dtb is compiled with support for overlays (-@ to generate symbols), this tag is ignored, and the nodes stay in the .dtb, regardless of being referenced or not. Just confirmed by trying this.

Cheers,
Andre.

>
> Cheers,

André Przywara

unread,
Jan 12, 2020, 10:12:32 AM1/12/20
to Maxime Ripard, Chen-Yu Tsai, Mark Brown, linu...@vger.kernel.org, linux-ar...@lists.infradead.org, linux...@googlegroups.com, Icenowy Zheng, devic...@vger.kernel.org, Rob Herring, Mark Rutland
On 11/01/2020 17:26, Maxime Ripard wrote:

Hi Maxime,
> It seems suspicious to use it in the Pine H64, since PC5 is also used
> by the eMMC (and this prevents either the SPI or the emmc controller
> to probe, depending on which probed first).

Argh, good catch! I saw that AW changed the pin sharing between SPI and
MMC2 slightly, but didn't actually check that they made it worse :-(
Because this time it's the MMC CMD pin affected, and not the somewhat
optional DS pin as in the A64.
So I see we can't really have both at the same time. So what about this:

We keep the SPI flash chip described as in patch 2/2 (as it's soldered
on every board), but mark it as disabled and explain this in a comment.
This way we can't access it under Linux, but keep a potential eMMC chip
accessible.

In U-Boot's DT copy we could deviate and mark it as "okay", as U-Boot
doesn't use both eMMC and SPI at the same time. I need to check whether
this works or we would need to move the pinmux setup out of the probe
routine into something later.

And we could go one step further: If U-Boot detects an eMMC connected
(it's on a socket and so optional), it changes the SPI flash status to
"disabled", to allow EFI apps and kernels using this DT to access the
eMMC - which is far more useful than the SPI flash.
Otherwise (no eMMC connected) it can stay at "okay", as there would be
no conflict.

Does this make sense?

Cheers,
Andre.
Reply all
Reply to author
Forward
0 new messages