* [PATCH v11 0/6] arm64: sunxi: Initial Allwinner H616 SoC support
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi,
another attempt in getting the H616 finally officially supported. The
RTC patches went in, and together with the new RTC clock driver this
part is *mostly* covered now. The first two patches plug the last two
holes in the clock tree: the new RTC register gate clock, and the PLL
derived 32KHz clock, both required by the new RTC clock binding. Now
also working on the H6 ;-)
For simplicity I dropped the USB patches again - for now.
This is based on top of 5.18-rc3, but requires the "mark rtc-32k as
critical" clock patch[1], which has been pushed, but didn't reach
Linus' tree yet. Please note that there is no conflict, it's "just"
required for functionality.
For a complete changelog, see below.
Also available here: https://github.com/apritzel/linux/commits/h616-v11
Thanks!
Andre
==================
This series gathers patches to support the Allwinner H616 SoC. This is
a rather uninspired SoC (Quad-A53 with the usual peripherals), but
allows for some cheap development boards and TV boxes, and supports
up to 4GB of DRAM.
Some DT binding patches are sprinkled throughout the series, to add
the new compatible names right before they are used.
Eventually we get the .dtsi for the SoC in patch 3, and the .dts for
the OrangePi Zero2 board[2] in the over-next patch, followed by the
.dts for the X96 Mate TV box[3] afterwards.
U-Boot and Trusted Firmware support is now merged in released versions,
it allows booting via FEL or SD card, also you can TFTP kernels in on
the OrangePi Zero 2 board.
Many thanks to Jernej for his tremendous help on this, also for the
awesome input and help from the #linux-sunxi Freenode channel.
The whole series (including the prerequisites) can also be found here:
https://github.com/apritzel/linux/commits/h616-v11
Happy reviewing!
Cheers,
Andre
[1] https://lore.kernel.org/linux-arm-kernel/20220411050100.40964-1-samuel@sholland.org/
[2] https://linux-sunxi.org/Orange_Pi_Zero_2
[3] https://linux-sunxi.org/X96_Mate
Changelog v10 .. v11:
- Drop already merged RTC patches
- Drop USB patches
- Also add RTC gate clock to the H6, but mark it as unused
- Add X96 Mate manufacturer to vendor list
Changelog v9 .. v10:
- based on ccu-sun6i-rtc clock driver
- add RTC bus clock and 32k system PLL clock
- drop clock related code from actual RTC driver (just use RTC bits)
- .dtsi: remove redundant status = "okay"; from .dtsi
- .dts: drop #address-cells = <0> from IRQ controller nodes
- .dtsi: fix indentation of IR node
- .dtsi: adjust RTC node to new binding
- re-add USB patches
Changelog v8 .. v9:
- RTC: Rely on the division to split of the H:M:S part from the day part
- Add Jernej's Review tags
Changelog v7 .. v8:
- Rebase on top of 5.14-rc1, which already includes the previous v7 02/19
- Drop USB and Ethernet patches (to keep series small)
- Use "clocks: false" in RTC DT binding (2/11)
- Include fix for RTC overflow check (3/11)
- Use div_64() to avoid linking error on some 32-bit platforms (4+5/11)
- Adjust to changed RTC overflow check (5/11)
- Drop USB nodes from .dtsi file
- Move mmc-ddr-1_8v property from .dtsi file into board .dts
- Fix DTC warnings (underscore in node name, soc@0, #a-c in IRQ controllers)
Changelog v6 .. v7:
- Fix AXP305 binding documentation blunder (01/19)
- Improve new linear day support (use existing conversion functions) (04/19)
- Add support for changed RTC alarm registers (05/19)
- Add support for RTCs without a LOSC clock (06/19)
- Rework USB PHY2 SIDDQ quirk to use PHY clocks directly (14/19)
- Add X96 Mate compatible string to binding doc (17/19)
- Add Rob's ACKs
Changelog v5 .. v6:
- Drop already merged clock, pinctrl and MMC support from this series
- Properly fix AXP support by skipping power key initialisation
- Add patch to support new RTC date storage encoding
- Re-add USB HCI PHY refactoring
- Add patch to allow USB reset line sharing
- Add patch to introduce quirk for PHY2 SIDDQ clearing
- Re-add USB nodes to the .dtsi
- Add USB gadget support
- Add DT for X96 Mate TV box
Changelog v4 .. v5:
- Fix CCU binding to pass dtbs_check
- Add RSB compatible string to binding doc
- Rename IR pin name to pass dtbs_check
- Add EMAC compatible string to binding doc
- Drop USB PHY support and binding doc patches
- Drop USB nodes from .dtsi and .dts
- Drop second EMAC node from .dtsi
Changelog v3 .. v4:
- Drop MMC and pinctrl matches (already in some -next trees)
- Add Maxime's Acks
- Add patch to update the AXP MFD DT bindings
- Add new patch (05/21) to fix axp20x-pek driver
- Change AXP IRQ fix to check for invalid IRQ line number
- Split joint DT bindings patch (v3 18/21) into subsystems
- move dwmac variable to keep christmas tree
- Use enums for USB PHY compatible strings in DT binding
- Enable watchdog (briefly verified to work)
- Add PHY2 to HCI1&3, this fixes USB
- limit r-ccu register frame length to not collide with NMI controller
- add interrupt-controller property to AXP DT node
Changelog v2 .. v3:
- Add Rob's Acks
- Drop redundant maxItems from pinctrl DT binding
- Rename h_i2s* to just i2s* in pinctrl names
- Use more declarative i2s0_d{in,out}{0,1} names
- Add RSB pins to pinctrl
- Include RSB clocks (sharing with newly added H6 versions)
- Fix CEC clock (add 2nd enable bit, also fix predivider flag)
- Rename PMU_UNK1 register in USB PHY
- Add USB and MUSB DT binding patches
- Add MMC/SD speed modes to .dtsi
Changelog v1 .. v2:
- pinctrl: adjust irq bank map to cover undocumented GPIO bank IRQs
- use differing h_i2s0 pin output names
- r-ccu: fix number of used clocks
- ccu: remove PLL-PERIPHy(4X)
- ccu: fix gpu1 divider range
- ccu: fix usb-phy3 parent
- ccu: add missing TV clocks
- ccu: rework to CLK_OF_DECLARE style
- ccu: enable output bit for PLL clocks
- ccu: renumber clocks
- .dtsi: drop sun50i-a64-system-control fallback
- .dtsi: drop unknown SRAM regions
- .dtsi: add more (undocumented) GPIO interrupts
- .dtsi: fix I2C3 pin names
- .dtsi: use a100-emmc fallback for MMC2
- .dtsi: add second EMAC controller
- .dtsi: use H3 MUSB controller fallback
- .dtsi: fix frame size for USB PHY PMU registers
- .dtsi: add USB0 PHY references
- .dtsi: fix IR controller clock source
- .dts: fix LED naming and swap pins
- .dts: use 5V supply parent for USB supply
- .dts: drop dummy IRQ for AXP
- .dts: enable 3V3 header pin power rail
- .dts: add SPI flash node
- .dts: make USB-C port peripheral only
- add IRQ-less AXP support
- add two patches to support more than one EMAC clock
- add patch to rework and extend USB PHY support
- add DT binding documentation patches
Andre Przywara (6):
clk: sunxi-ng: h6-r: Add RTC gate clock
clk: sunxi-ng: h616: Add PLL derived 32KHz clock
arm64: dts: allwinner: Add Allwinner H616 .dtsi file
dt-bindings: arm: sunxi: Add two H616 board compatible strings
arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
arm64: dts: allwinner: h616: Add X96 Mate TV box support
.../devicetree/bindings/arm/sunxi.yaml | 10 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/allwinner/Makefile | 2 +
.../allwinner/sun50i-h616-orangepi-zero2.dts | 203 +++++++
.../dts/allwinner/sun50i-h616-x96-mate.dts | 177 ++++++
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 8 +
drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 2 +-
include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
include/dt-bindings/clock/sun50i-h616-ccu.h | 1 +
12 files changed, 985 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
--
2.35.3
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v11 0/6] arm64: sunxi: Initial Allwinner H616 SoC support
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi,
another attempt in getting the H616 finally officially supported. The
RTC patches went in, and together with the new RTC clock driver this
part is *mostly* covered now. The first two patches plug the last two
holes in the clock tree: the new RTC register gate clock, and the PLL
derived 32KHz clock, both required by the new RTC clock binding. Now
also working on the H6 ;-)
For simplicity I dropped the USB patches again - for now.
This is based on top of 5.18-rc3, but requires the "mark rtc-32k as
critical" clock patch[1], which has been pushed, but didn't reach
Linus' tree yet. Please note that there is no conflict, it's "just"
required for functionality.
For a complete changelog, see below.
Also available here: https://github.com/apritzel/linux/commits/h616-v11
Thanks!
Andre
==================
This series gathers patches to support the Allwinner H616 SoC. This is
a rather uninspired SoC (Quad-A53 with the usual peripherals), but
allows for some cheap development boards and TV boxes, and supports
up to 4GB of DRAM.
Some DT binding patches are sprinkled throughout the series, to add
the new compatible names right before they are used.
Eventually we get the .dtsi for the SoC in patch 3, and the .dts for
the OrangePi Zero2 board[2] in the over-next patch, followed by the
.dts for the X96 Mate TV box[3] afterwards.
U-Boot and Trusted Firmware support is now merged in released versions,
it allows booting via FEL or SD card, also you can TFTP kernels in on
the OrangePi Zero 2 board.
Many thanks to Jernej for his tremendous help on this, also for the
awesome input and help from the #linux-sunxi Freenode channel.
The whole series (including the prerequisites) can also be found here:
https://github.com/apritzel/linux/commits/h616-v11
Happy reviewing!
Cheers,
Andre
[1] https://lore.kernel.org/linux-arm-kernel/20220411050100.40964-1-samuel@sholland.org/
[2] https://linux-sunxi.org/Orange_Pi_Zero_2
[3] https://linux-sunxi.org/X96_Mate
Changelog v10 .. v11:
- Drop already merged RTC patches
- Drop USB patches
- Also add RTC gate clock to the H6, but mark it as unused
- Add X96 Mate manufacturer to vendor list
Changelog v9 .. v10:
- based on ccu-sun6i-rtc clock driver
- add RTC bus clock and 32k system PLL clock
- drop clock related code from actual RTC driver (just use RTC bits)
- .dtsi: remove redundant status = "okay"; from .dtsi
- .dts: drop #address-cells = <0> from IRQ controller nodes
- .dtsi: fix indentation of IR node
- .dtsi: adjust RTC node to new binding
- re-add USB patches
Changelog v8 .. v9:
- RTC: Rely on the division to split of the H:M:S part from the day part
- Add Jernej's Review tags
Changelog v7 .. v8:
- Rebase on top of 5.14-rc1, which already includes the previous v7 02/19
- Drop USB and Ethernet patches (to keep series small)
- Use "clocks: false" in RTC DT binding (2/11)
- Include fix for RTC overflow check (3/11)
- Use div_64() to avoid linking error on some 32-bit platforms (4+5/11)
- Adjust to changed RTC overflow check (5/11)
- Drop USB nodes from .dtsi file
- Move mmc-ddr-1_8v property from .dtsi file into board .dts
- Fix DTC warnings (underscore in node name, soc@0, #a-c in IRQ controllers)
Changelog v6 .. v7:
- Fix AXP305 binding documentation blunder (01/19)
- Improve new linear day support (use existing conversion functions) (04/19)
- Add support for changed RTC alarm registers (05/19)
- Add support for RTCs without a LOSC clock (06/19)
- Rework USB PHY2 SIDDQ quirk to use PHY clocks directly (14/19)
- Add X96 Mate compatible string to binding doc (17/19)
- Add Rob's ACKs
Changelog v5 .. v6:
- Drop already merged clock, pinctrl and MMC support from this series
- Properly fix AXP support by skipping power key initialisation
- Add patch to support new RTC date storage encoding
- Re-add USB HCI PHY refactoring
- Add patch to allow USB reset line sharing
- Add patch to introduce quirk for PHY2 SIDDQ clearing
- Re-add USB nodes to the .dtsi
- Add USB gadget support
- Add DT for X96 Mate TV box
Changelog v4 .. v5:
- Fix CCU binding to pass dtbs_check
- Add RSB compatible string to binding doc
- Rename IR pin name to pass dtbs_check
- Add EMAC compatible string to binding doc
- Drop USB PHY support and binding doc patches
- Drop USB nodes from .dtsi and .dts
- Drop second EMAC node from .dtsi
Changelog v3 .. v4:
- Drop MMC and pinctrl matches (already in some -next trees)
- Add Maxime's Acks
- Add patch to update the AXP MFD DT bindings
- Add new patch (05/21) to fix axp20x-pek driver
- Change AXP IRQ fix to check for invalid IRQ line number
- Split joint DT bindings patch (v3 18/21) into subsystems
- move dwmac variable to keep christmas tree
- Use enums for USB PHY compatible strings in DT binding
- Enable watchdog (briefly verified to work)
- Add PHY2 to HCI1&3, this fixes USB
- limit r-ccu register frame length to not collide with NMI controller
- add interrupt-controller property to AXP DT node
Changelog v2 .. v3:
- Add Rob's Acks
- Drop redundant maxItems from pinctrl DT binding
- Rename h_i2s* to just i2s* in pinctrl names
- Use more declarative i2s0_d{in,out}{0,1} names
- Add RSB pins to pinctrl
- Include RSB clocks (sharing with newly added H6 versions)
- Fix CEC clock (add 2nd enable bit, also fix predivider flag)
- Rename PMU_UNK1 register in USB PHY
- Add USB and MUSB DT binding patches
- Add MMC/SD speed modes to .dtsi
Changelog v1 .. v2:
- pinctrl: adjust irq bank map to cover undocumented GPIO bank IRQs
- use differing h_i2s0 pin output names
- r-ccu: fix number of used clocks
- ccu: remove PLL-PERIPHy(4X)
- ccu: fix gpu1 divider range
- ccu: fix usb-phy3 parent
- ccu: add missing TV clocks
- ccu: rework to CLK_OF_DECLARE style
- ccu: enable output bit for PLL clocks
- ccu: renumber clocks
- .dtsi: drop sun50i-a64-system-control fallback
- .dtsi: drop unknown SRAM regions
- .dtsi: add more (undocumented) GPIO interrupts
- .dtsi: fix I2C3 pin names
- .dtsi: use a100-emmc fallback for MMC2
- .dtsi: add second EMAC controller
- .dtsi: use H3 MUSB controller fallback
- .dtsi: fix frame size for USB PHY PMU registers
- .dtsi: add USB0 PHY references
- .dtsi: fix IR controller clock source
- .dts: fix LED naming and swap pins
- .dts: use 5V supply parent for USB supply
- .dts: drop dummy IRQ for AXP
- .dts: enable 3V3 header pin power rail
- .dts: add SPI flash node
- .dts: make USB-C port peripheral only
- add IRQ-less AXP support
- add two patches to support more than one EMAC clock
- add patch to rework and extend USB PHY support
- add DT binding documentation patches
Andre Przywara (6):
clk: sunxi-ng: h6-r: Add RTC gate clock
clk: sunxi-ng: h616: Add PLL derived 32KHz clock
arm64: dts: allwinner: Add Allwinner H616 .dtsi file
dt-bindings: arm: sunxi: Add two H616 board compatible strings
arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
arm64: dts: allwinner: h616: Add X96 Mate TV box support
.../devicetree/bindings/arm/sunxi.yaml | 10 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/allwinner/Makefile | 2 +
.../allwinner/sun50i-h616-orangepi-zero2.dts | 203 +++++++
.../dts/allwinner/sun50i-h616-x96-mate.dts | 177 ++++++
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 8 +
drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 2 +-
include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
include/dt-bindings/clock/sun50i-h616-ccu.h | 1 +
12 files changed, 985 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock
2022-04-28 23:09 ` Andre Przywara
@ 2022-04-28 23:09 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
The H6 and H616 feature an (undocumented) bus clock gate for accessing
the RTC registers. This seems to be enabled at reset (or by the BootROM),
so we got away without it so far, but exists regardless.
Since the new RTC clock binding for the H616 requires this "bus" clock
to be specified in the DT, add this to R_CCU clock driver and expose it
on the DT side with a new number.
We do this for both the H6 and H616, but mark it as IGNORE_UNUSED, as we
cannot reference it in any H6 DTs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +++++
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
index 712e103382d8..88509339031e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
@@ -98,6 +98,8 @@ static SUNXI_CCU_GATE(r_apb1_ir_clk, "r-apb1-ir", "r-apb1",
0x1cc, BIT(0), 0);
static SUNXI_CCU_GATE(r_apb1_w1_clk, "r-apb1-w1", "r-apb1",
0x1ec, BIT(0), 0);
+static SUNXI_CCU_GATE(r_apb1_rtc_clk, "r-apb1-rtc", "r-apb1",
+ 0x20c, BIT(0), CLK_IGNORE_UNUSED);
/* Information of IR(RX) mod clock is gathered from BSP source code */
static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M" };
@@ -147,6 +149,7 @@ static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
&r_apb2_i2c_clk.common,
&r_apb2_rsb_clk.common,
&r_apb1_ir_clk.common,
+ &r_apb1_rtc_clk.common,
&ir_clk.common,
};
@@ -163,6 +166,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
[CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
[CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
[CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
+ [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
[CLK_R_APB1_W1] = &r_apb1_w1_clk.common.hw,
[CLK_IR] = &ir_clk.common.hw,
[CLK_W1] = &w1_clk.common.hw,
@@ -179,6 +183,7 @@ static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
[CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
[CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
[CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
+ [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
[CLK_IR] = &ir_clk.common.hw,
},
.num = CLK_NUMBER,
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
index 7e290b840803..10e9b66afc6a 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
@@ -14,6 +14,6 @@
#define CLK_R_APB2 3
-#define CLK_NUMBER (CLK_R_APB2_RSB + 1)
+#define CLK_NUMBER (CLK_R_APB1_RTC + 1)
#endif /* _CCU_SUN50I_H6_R_H */
diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
index 890368d252c4..a96087abc86f 100644
--- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
+++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
@@ -22,5 +22,6 @@
#define CLK_W1 12
#define CLK_R_APB2_RSB 13
+#define CLK_R_APB1_RTC 14
#endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
--
2.35.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
The H6 and H616 feature an (undocumented) bus clock gate for accessing
the RTC registers. This seems to be enabled at reset (or by the BootROM),
so we got away without it so far, but exists regardless.
Since the new RTC clock binding for the H616 requires this "bus" clock
to be specified in the DT, add this to R_CCU clock driver and expose it
on the DT side with a new number.
We do this for both the H6 and H616, but mark it as IGNORE_UNUSED, as we
cannot reference it in any H6 DTs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +++++
drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
index 712e103382d8..88509339031e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
@@ -98,6 +98,8 @@ static SUNXI_CCU_GATE(r_apb1_ir_clk, "r-apb1-ir", "r-apb1",
0x1cc, BIT(0), 0);
static SUNXI_CCU_GATE(r_apb1_w1_clk, "r-apb1-w1", "r-apb1",
0x1ec, BIT(0), 0);
+static SUNXI_CCU_GATE(r_apb1_rtc_clk, "r-apb1-rtc", "r-apb1",
+ 0x20c, BIT(0), CLK_IGNORE_UNUSED);
/* Information of IR(RX) mod clock is gathered from BSP source code */
static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M" };
@@ -147,6 +149,7 @@ static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
&r_apb2_i2c_clk.common,
&r_apb2_rsb_clk.common,
&r_apb1_ir_clk.common,
+ &r_apb1_rtc_clk.common,
&ir_clk.common,
};
@@ -163,6 +166,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
[CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
[CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
[CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
+ [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
[CLK_R_APB1_W1] = &r_apb1_w1_clk.common.hw,
[CLK_IR] = &ir_clk.common.hw,
[CLK_W1] = &w1_clk.common.hw,
@@ -179,6 +183,7 @@ static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
[CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
[CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
[CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
+ [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
[CLK_IR] = &ir_clk.common.hw,
},
.num = CLK_NUMBER,
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
index 7e290b840803..10e9b66afc6a 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
@@ -14,6 +14,6 @@
#define CLK_R_APB2 3
-#define CLK_NUMBER (CLK_R_APB2_RSB + 1)
+#define CLK_NUMBER (CLK_R_APB1_RTC + 1)
#endif /* _CCU_SUN50I_H6_R_H */
diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
index 890368d252c4..a96087abc86f 100644
--- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
+++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
@@ -22,5 +22,6 @@
#define CLK_W1 12
#define CLK_R_APB2_RSB 13
+#define CLK_R_APB1_RTC 14
#endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 2/6] clk: sunxi-ng: h616: Add PLL derived 32KHz clock
2022-04-28 23:09 ` Andre Przywara
@ 2022-04-28 23:09 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
The RTC section of the H616 manual mentions in a half-sentence the
existence of a clock "32K divided by PLL_PERI(2X)". This is used as
one of the possible inputs for the mux that selects the clock for the
32 KHz fanout pad. On the H616 this is routed to pin PG10, and some
boards use that clock output to compensate for a missing 32KHz crystal.
On the OrangePi Zero2 this is for instance connected to the LPO pin of
the WiFi/BT chip.
The new RTC clock binding requires this clock to be named as one input
clock, so we need to expose this to the DT. In contrast to the D1 SoC
there does not seem to be a gate for this clock, so just use a fixed
divider clock, using a newly assigned clock number.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
---
drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 8 ++++++++
drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 2 +-
include/dt-bindings/clock/sun50i-h616-ccu.h | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
index 49a2474cf314..21e918582aa5 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
@@ -704,6 +704,13 @@ static CLK_FIXED_FACTOR_HWS(pll_periph0_2x_clk, "pll-periph0-2x",
pll_periph0_parents,
1, 2, 0);
+static const struct clk_hw *pll_periph0_2x_hws[] = {
+ &pll_periph0_2x_clk.hw
+};
+
+static CLK_FIXED_FACTOR_HWS(pll_system_32k_clk, "pll-system-32k",
+ pll_periph0_2x_hws, 36621, 1, 0);
+
static const struct clk_hw *pll_periph1_parents[] = {
&pll_periph1_clk.common.hw
};
@@ -852,6 +859,7 @@ static struct clk_hw_onecell_data sun50i_h616_hw_clks = {
[CLK_PLL_DDR1] = &pll_ddr1_clk.common.hw,
[CLK_PLL_PERIPH0] = &pll_periph0_clk.common.hw,
[CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.hw,
+ [CLK_PLL_SYSTEM_32K] = &pll_system_32k_clk.hw,
[CLK_PLL_PERIPH1] = &pll_periph1_clk.common.hw,
[CLK_PLL_PERIPH1_2X] = &pll_periph1_2x_clk.hw,
[CLK_PLL_GPU] = &pll_gpu_clk.common.hw,
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h b/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
index dd671b413f22..fdd2f4d5103f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
@@ -51,6 +51,6 @@
#define CLK_BUS_DRAM 56
-#define CLK_NUMBER (CLK_BUS_HDCP + 1)
+#define CLK_NUMBER (CLK_PLL_SYSTEM_32K + 1)
#endif /* _CCU_SUN50I_H616_H_ */
diff --git a/include/dt-bindings/clock/sun50i-h616-ccu.h b/include/dt-bindings/clock/sun50i-h616-ccu.h
index 4fc08b0df2f3..1191aca53ac6 100644
--- a/include/dt-bindings/clock/sun50i-h616-ccu.h
+++ b/include/dt-bindings/clock/sun50i-h616-ccu.h
@@ -111,5 +111,6 @@
#define CLK_BUS_TVE0 125
#define CLK_HDCP 126
#define CLK_BUS_HDCP 127
+#define CLK_PLL_SYSTEM_32K 128
#endif /* _DT_BINDINGS_CLK_SUN50I_H616_H_ */
--
2.35.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 2/6] clk: sunxi-ng: h616: Add PLL derived 32KHz clock
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
The RTC section of the H616 manual mentions in a half-sentence the
existence of a clock "32K divided by PLL_PERI(2X)". This is used as
one of the possible inputs for the mux that selects the clock for the
32 KHz fanout pad. On the H616 this is routed to pin PG10, and some
boards use that clock output to compensate for a missing 32KHz crystal.
On the OrangePi Zero2 this is for instance connected to the LPO pin of
the WiFi/BT chip.
The new RTC clock binding requires this clock to be named as one input
clock, so we need to expose this to the DT. In contrast to the D1 SoC
there does not seem to be a gate for this clock, so just use a fixed
divider clock, using a newly assigned clock number.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
---
drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 8 ++++++++
drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 2 +-
include/dt-bindings/clock/sun50i-h616-ccu.h | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
index 49a2474cf314..21e918582aa5 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
@@ -704,6 +704,13 @@ static CLK_FIXED_FACTOR_HWS(pll_periph0_2x_clk, "pll-periph0-2x",
pll_periph0_parents,
1, 2, 0);
+static const struct clk_hw *pll_periph0_2x_hws[] = {
+ &pll_periph0_2x_clk.hw
+};
+
+static CLK_FIXED_FACTOR_HWS(pll_system_32k_clk, "pll-system-32k",
+ pll_periph0_2x_hws, 36621, 1, 0);
+
static const struct clk_hw *pll_periph1_parents[] = {
&pll_periph1_clk.common.hw
};
@@ -852,6 +859,7 @@ static struct clk_hw_onecell_data sun50i_h616_hw_clks = {
[CLK_PLL_DDR1] = &pll_ddr1_clk.common.hw,
[CLK_PLL_PERIPH0] = &pll_periph0_clk.common.hw,
[CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.hw,
+ [CLK_PLL_SYSTEM_32K] = &pll_system_32k_clk.hw,
[CLK_PLL_PERIPH1] = &pll_periph1_clk.common.hw,
[CLK_PLL_PERIPH1_2X] = &pll_periph1_2x_clk.hw,
[CLK_PLL_GPU] = &pll_gpu_clk.common.hw,
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h b/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
index dd671b413f22..fdd2f4d5103f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
@@ -51,6 +51,6 @@
#define CLK_BUS_DRAM 56
-#define CLK_NUMBER (CLK_BUS_HDCP + 1)
+#define CLK_NUMBER (CLK_PLL_SYSTEM_32K + 1)
#endif /* _CCU_SUN50I_H616_H_ */
diff --git a/include/dt-bindings/clock/sun50i-h616-ccu.h b/include/dt-bindings/clock/sun50i-h616-ccu.h
index 4fc08b0df2f3..1191aca53ac6 100644
--- a/include/dt-bindings/clock/sun50i-h616-ccu.h
+++ b/include/dt-bindings/clock/sun50i-h616-ccu.h
@@ -111,5 +111,6 @@
#define CLK_BUS_TVE0 125
#define CLK_HDCP 126
#define CLK_BUS_HDCP 127
+#define CLK_PLL_SYSTEM_32K 128
#endif /* _DT_BINDINGS_CLK_SUN50I_H616_H_ */
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-04-28 23:09 ` Andre Przywara
@ 2022-04-28 23:09 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.
The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
1 file changed, 574 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index 000000000000..cc06cdd15ba5
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,574 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun50i-h616-ccu.h>
+#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
+#include <dt-bindings/reset/sun50i-h616-ccu.h>
+#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <1>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <2>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <3>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 512KiB reserved for ARM Trusted Firmware (BL31) */
+ secmon_reserved: secmon@40000000 {
+ reg = <0x0 0x40000000 0x0 0x80000>;
+ no-map;
+ };
+ };
+
+ osc24M: osc24M-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "osc24M";
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ arm,no-tick-in-suspend;
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ soc@0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x40000000>;
+
+ syscon: syscon@3000000 {
+ compatible = "allwinner,sun50i-h616-system-control";
+ reg = <0x03000000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram_c: sram@28000 {
+ compatible = "mmio-sram";
+ reg = <0x00028000 0x30000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x00028000 0x30000>;
+ };
+ };
+
+ ccu: clock@3001000 {
+ compatible = "allwinner,sun50i-h616-ccu";
+ reg = <0x03001000 0x1000>;
+ clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
+ clock-names = "hosc", "losc", "iosc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ watchdog: watchdog@30090a0 {
+ compatible = "allwinner,sun50i-h616-wdt",
+ "allwinner,sun6i-a31-wdt";
+ reg = <0x030090a0 0x20>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ pio: pinctrl@300b000 {
+ compatible = "allwinner,sun50i-h616-pinctrl";
+ reg = <0x0300b000 0x400>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc 0>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ ext_rgmii_pins: rgmii-pins {
+ pins = "PI0", "PI1", "PI2", "PI3", "PI4",
+ "PI5", "PI7", "PI8", "PI9", "PI10",
+ "PI11", "PI12", "PI13", "PI14", "PI15",
+ "PI16";
+ function = "emac0";
+ drive-strength = <40>;
+ };
+
+ i2c0_pins: i2c0-pins {
+ pins = "PI6", "PI7";
+ function = "i2c0";
+ };
+
+ i2c3_ph_pins: i2c3-ph-pins {
+ pins = "PH4", "PH5";
+ function = "i2c3";
+ };
+
+ ir_rx_pin: ir-rx-pin {
+ pins = "PH10";
+ function = "ir_rx";
+ };
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_pins: mmc2-pins {
+ pins = "PC0", "PC1", "PC5", "PC6",
+ "PC8", "PC9", "PC10", "PC11",
+ "PC13", "PC14", "PC15", "PC16";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ spi0_pins: spi0-pins {
+ pins = "PC0", "PC2", "PC3", "PC4";
+ function = "spi0";
+ };
+
+ spi1_pins: spi1-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "spi1";
+ };
+
+ spi1_cs_pin: spi1-cs-pin {
+ pins = "PH5";
+ function = "spi1";
+ };
+
+ uart0_ph_pins: uart0-ph-pins {
+ pins = "PH0", "PH1";
+ function = "uart0";
+ };
+
+ uart1_pins: uart1-pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1-rts-cts-pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
+ };
+
+ gic: interrupt-controller@3021000 {
+ compatible = "arm,gic-400";
+ reg = <0x03021000 0x1000>,
+ <0x03022000 0x2000>,
+ <0x03024000 0x2000>,
+ <0x03026000 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ mmc0: mmc@4020000 {
+ compatible = "allwinner,sun50i-h616-mmc",
+ "allwinner,sun50i-a100-mmc";
+ reg = <0x04020000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ status = "disabled";
+ max-frequency = <150000000>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ cap-sdio-irq;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@4021000 {
+ compatible = "allwinner,sun50i-h616-mmc",
+ "allwinner,sun50i-a100-mmc";
+ reg = <0x04021000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ status = "disabled";
+ max-frequency = <150000000>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ cap-sdio-irq;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@4022000 {
+ compatible = "allwinner,sun50i-h616-emmc",
+ "allwinner,sun50i-a100-emmc";
+ reg = <0x04022000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ status = "disabled";
+ max-frequency = <150000000>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ cap-sdio-irq;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ uart0: serial@5000000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000000 0x400>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
+ status = "disabled";
+ };
+
+ uart1: serial@5000400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000400 0x400>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART1>;
+ resets = <&ccu RST_BUS_UART1>;
+ status = "disabled";
+ };
+
+ uart2: serial@5000800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000800 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART2>;
+ resets = <&ccu RST_BUS_UART2>;
+ status = "disabled";
+ };
+
+ uart3: serial@5000c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000c00 0x400>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART3>;
+ resets = <&ccu RST_BUS_UART3>;
+ status = "disabled";
+ };
+
+ uart4: serial@5001000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05001000 0x400>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART4>;
+ resets = <&ccu RST_BUS_UART4>;
+ status = "disabled";
+ };
+
+ uart5: serial@5001400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05001400 0x400>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART5>;
+ resets = <&ccu RST_BUS_UART5>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@5002000 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002000 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@5002400 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002400 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@5002800 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002800 0x400>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c3: i2c@5002c00 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002c00 0x400>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C3>;
+ resets = <&ccu RST_BUS_I2C3>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4: i2c@5003000 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05003000 0x400>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C4>;
+ resets = <&ccu RST_BUS_I2C4>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi0: spi@5010000 {
+ compatible = "allwinner,sun50i-h616-spi",
+ "allwinner,sun8i-h3-spi";
+ reg = <0x05010000 0x1000>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_SPI0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi1: spi@5011000 {
+ compatible = "allwinner,sun50i-h616-spi",
+ "allwinner,sun8i-h3-spi";
+ reg = <0x05011000 0x1000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_SPI1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ emac0: ethernet@5020000 {
+ compatible = "allwinner,sun50i-h616-emac",
+ "allwinner,sun50i-a64-emac";
+ syscon = <&syscon>;
+ reg = <0x05020000 0x10000>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC0>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC0>;
+ clock-names = "stmmaceth";
+ status = "disabled";
+
+ mdio0: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ rtc: rtc@7000000 {
+ compatible = "allwinner,sun50i-h616-rtc";
+ reg = <0x07000000 0x400>;
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
+ <&ccu CLK_PLL_SYSTEM_32K>;
+ clock-names = "bus", "hosc",
+ "pll-32k";
+ clock-output-names = "osc32k", "osc32k-out", "iosc";
+ #clock-cells = <1>;
+ };
+
+ r_ccu: clock@7010000 {
+ compatible = "allwinner,sun50i-h616-r-ccu";
+ reg = <0x07010000 0x210>;
+ clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
+ <&ccu CLK_PLL_PERIPH0>;
+ clock-names = "hosc", "losc", "iosc", "pll-periph";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ r_pio: pinctrl@7022000 {
+ compatible = "allwinner,sun50i-h616-r-pinctrl";
+ reg = <0x07022000 0x400>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB1>, <&osc24M>, <&rtc 0>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ r_i2c_pins: r-i2c-pins {
+ pins = "PL0", "PL1";
+ function = "s_i2c";
+ };
+
+ r_rsb_pins: r-rsb-pins {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ };
+ };
+
+ ir: ir@7040000 {
+ compatible = "allwinner,sun50i-h616-ir",
+ "allwinner,sun6i-a31-ir";
+ reg = <0x07040000 0x400>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB1_IR>,
+ <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_R_APB1_IR>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_rx_pin>;
+ status = "disabled";
+ };
+
+ r_i2c: i2c@7081400 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x07081400 0x400>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB2_I2C>;
+ resets = <&r_ccu RST_R_APB2_I2C>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ r_rsb: rsb@7083000 {
+ compatible = "allwinner,sun50i-h616-rsb",
+ "allwinner,sun8i-a23-rsb";
+ reg = <0x07083000 0x400>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB2_RSB>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu RST_R_APB2_RSB>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
--
2.35.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
This (relatively) new SoC is similar to the H6, but drops the (broken)
PCIe support and the USB 3.0 controller. It also gets the management
controller removed, which in turn removes *some*, but not all of the
devices formerly dedicated to the ARISC (CPUS).
And while there is still the extra sunxi interrupt controller, the
package lacks the corresponding NMI pin, so no interrupts for the PMIC.
The reserved memory node is actually handled by Trusted Firmware now,
but U-Boot fails to propagate this to a separately loaded DTB, so we
keep it in here for now, until U-Boot learns to do this properly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
.../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
1 file changed, 574 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
new file mode 100644
index 000000000000..cc06cdd15ba5
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,574 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2020 Arm Ltd.
+// based on the H6 dtsi, which is:
+// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun50i-h616-ccu.h>
+#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
+#include <dt-bindings/reset/sun50i-h616-ccu.h>
+#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <1>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <2>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <3>;
+ enable-method = "psci";
+ clocks = <&ccu CLK_CPUX>;
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 512KiB reserved for ARM Trusted Firmware (BL31) */
+ secmon_reserved: secmon@40000000 {
+ reg = <0x0 0x40000000 0x0 0x80000>;
+ no-map;
+ };
+ };
+
+ osc24M: osc24M-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "osc24M";
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ arm,no-tick-in-suspend;
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ soc@0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x40000000>;
+
+ syscon: syscon@3000000 {
+ compatible = "allwinner,sun50i-h616-system-control";
+ reg = <0x03000000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ sram_c: sram@28000 {
+ compatible = "mmio-sram";
+ reg = <0x00028000 0x30000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x00028000 0x30000>;
+ };
+ };
+
+ ccu: clock@3001000 {
+ compatible = "allwinner,sun50i-h616-ccu";
+ reg = <0x03001000 0x1000>;
+ clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
+ clock-names = "hosc", "losc", "iosc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ watchdog: watchdog@30090a0 {
+ compatible = "allwinner,sun50i-h616-wdt",
+ "allwinner,sun6i-a31-wdt";
+ reg = <0x030090a0 0x20>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&osc24M>;
+ };
+
+ pio: pinctrl@300b000 {
+ compatible = "allwinner,sun50i-h616-pinctrl";
+ reg = <0x0300b000 0x400>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc 0>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ ext_rgmii_pins: rgmii-pins {
+ pins = "PI0", "PI1", "PI2", "PI3", "PI4",
+ "PI5", "PI7", "PI8", "PI9", "PI10",
+ "PI11", "PI12", "PI13", "PI14", "PI15",
+ "PI16";
+ function = "emac0";
+ drive-strength = <40>;
+ };
+
+ i2c0_pins: i2c0-pins {
+ pins = "PI6", "PI7";
+ function = "i2c0";
+ };
+
+ i2c3_ph_pins: i2c3-ph-pins {
+ pins = "PH4", "PH5";
+ function = "i2c3";
+ };
+
+ ir_rx_pin: ir-rx-pin {
+ pins = "PH10";
+ function = "ir_rx";
+ };
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ mmc2_pins: mmc2-pins {
+ pins = "PC0", "PC1", "PC5", "PC6",
+ "PC8", "PC9", "PC10", "PC11",
+ "PC13", "PC14", "PC15", "PC16";
+ function = "mmc2";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ spi0_pins: spi0-pins {
+ pins = "PC0", "PC2", "PC3", "PC4";
+ function = "spi0";
+ };
+
+ spi1_pins: spi1-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "spi1";
+ };
+
+ spi1_cs_pin: spi1-cs-pin {
+ pins = "PH5";
+ function = "spi1";
+ };
+
+ uart0_ph_pins: uart0-ph-pins {
+ pins = "PH0", "PH1";
+ function = "uart0";
+ };
+
+ uart1_pins: uart1-pins {
+ pins = "PG6", "PG7";
+ function = "uart1";
+ };
+
+ uart1_rts_cts_pins: uart1-rts-cts-pins {
+ pins = "PG8", "PG9";
+ function = "uart1";
+ };
+ };
+
+ gic: interrupt-controller@3021000 {
+ compatible = "arm,gic-400";
+ reg = <0x03021000 0x1000>,
+ <0x03022000 0x2000>,
+ <0x03024000 0x2000>,
+ <0x03026000 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ mmc0: mmc@4020000 {
+ compatible = "allwinner,sun50i-h616-mmc",
+ "allwinner,sun50i-a100-mmc";
+ reg = <0x04020000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC0>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ status = "disabled";
+ max-frequency = <150000000>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ cap-sdio-irq;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc1: mmc@4021000 {
+ compatible = "allwinner,sun50i-h616-mmc",
+ "allwinner,sun50i-a100-mmc";
+ reg = <0x04021000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC1>, <&ccu CLK_MMC1>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC1>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
+ status = "disabled";
+ max-frequency = <150000000>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ cap-sdio-irq;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ mmc2: mmc@4022000 {
+ compatible = "allwinner,sun50i-h616-emmc",
+ "allwinner,sun50i-a100-emmc";
+ reg = <0x04022000 0x1000>;
+ clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
+ clock-names = "ahb", "mmc";
+ resets = <&ccu RST_BUS_MMC2>;
+ reset-names = "ahb";
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ status = "disabled";
+ max-frequency = <150000000>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ mmc-ddr-3_3v;
+ cap-sdio-irq;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ uart0: serial@5000000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000000 0x400>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART0>;
+ resets = <&ccu RST_BUS_UART0>;
+ status = "disabled";
+ };
+
+ uart1: serial@5000400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000400 0x400>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART1>;
+ resets = <&ccu RST_BUS_UART1>;
+ status = "disabled";
+ };
+
+ uart2: serial@5000800 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000800 0x400>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART2>;
+ resets = <&ccu RST_BUS_UART2>;
+ status = "disabled";
+ };
+
+ uart3: serial@5000c00 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05000c00 0x400>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART3>;
+ resets = <&ccu RST_BUS_UART3>;
+ status = "disabled";
+ };
+
+ uart4: serial@5001000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05001000 0x400>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART4>;
+ resets = <&ccu RST_BUS_UART4>;
+ status = "disabled";
+ };
+
+ uart5: serial@5001400 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x05001400 0x400>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&ccu CLK_BUS_UART5>;
+ resets = <&ccu RST_BUS_UART5>;
+ status = "disabled";
+ };
+
+ i2c0: i2c@5002000 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002000 0x400>;
+ interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C0>;
+ resets = <&ccu RST_BUS_I2C0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: i2c@5002400 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002400 0x400>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C1>;
+ resets = <&ccu RST_BUS_I2C1>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c2: i2c@5002800 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002800 0x400>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C2>;
+ resets = <&ccu RST_BUS_I2C2>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c3: i2c@5002c00 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05002c00 0x400>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C3>;
+ resets = <&ccu RST_BUS_I2C3>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c4: i2c@5003000 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x05003000 0x400>;
+ interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_I2C4>;
+ resets = <&ccu RST_BUS_I2C4>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi0: spi@5010000 {
+ compatible = "allwinner,sun50i-h616-spi",
+ "allwinner,sun8i-h3-spi";
+ reg = <0x05010000 0x1000>;
+ interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_SPI0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ spi1: spi@5011000 {
+ compatible = "allwinner,sun50i-h616-spi",
+ "allwinner,sun8i-h3-spi";
+ reg = <0x05011000 0x1000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_SPI1>, <&ccu CLK_SPI1>;
+ clock-names = "ahb", "mod";
+ resets = <&ccu RST_BUS_SPI1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ emac0: ethernet@5020000 {
+ compatible = "allwinner,sun50i-h616-emac",
+ "allwinner,sun50i-a64-emac";
+ syscon = <&syscon>;
+ reg = <0x05020000 0x10000>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC0>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC0>;
+ clock-names = "stmmaceth";
+ status = "disabled";
+
+ mdio0: mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ rtc: rtc@7000000 {
+ compatible = "allwinner,sun50i-h616-rtc";
+ reg = <0x07000000 0x400>;
+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
+ <&ccu CLK_PLL_SYSTEM_32K>;
+ clock-names = "bus", "hosc",
+ "pll-32k";
+ clock-output-names = "osc32k", "osc32k-out", "iosc";
+ #clock-cells = <1>;
+ };
+
+ r_ccu: clock@7010000 {
+ compatible = "allwinner,sun50i-h616-r-ccu";
+ reg = <0x07010000 0x210>;
+ clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
+ <&ccu CLK_PLL_PERIPH0>;
+ clock-names = "hosc", "losc", "iosc", "pll-periph";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ r_pio: pinctrl@7022000 {
+ compatible = "allwinner,sun50i-h616-r-pinctrl";
+ reg = <0x07022000 0x400>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB1>, <&osc24M>, <&rtc 0>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ r_i2c_pins: r-i2c-pins {
+ pins = "PL0", "PL1";
+ function = "s_i2c";
+ };
+
+ r_rsb_pins: r-rsb-pins {
+ pins = "PL0", "PL1";
+ function = "s_rsb";
+ };
+ };
+
+ ir: ir@7040000 {
+ compatible = "allwinner,sun50i-h616-ir",
+ "allwinner,sun6i-a31-ir";
+ reg = <0x07040000 0x400>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB1_IR>,
+ <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_R_APB1_IR>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_rx_pin>;
+ status = "disabled";
+ };
+
+ r_i2c: i2c@7081400 {
+ compatible = "allwinner,sun50i-h616-i2c",
+ "allwinner,sun6i-a31-i2c";
+ reg = <0x07081400 0x400>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB2_I2C>;
+ resets = <&r_ccu RST_R_APB2_I2C>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ r_rsb: rsb@7083000 {
+ compatible = "allwinner,sun50i-h616-rsb",
+ "allwinner,sun8i-a23-rsb";
+ reg = <0x07083000 0x400>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&r_ccu CLK_R_APB2_RSB>;
+ clock-frequency = <3000000>;
+ resets = <&r_ccu RST_R_APB2_RSB>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_rsb_pins>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 4/6] dt-bindings: arm: sunxi: Add two H616 board compatible strings
2022-04-28 23:09 ` Andre Przywara
@ 2022-04-28 23:09 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
This adds the two board compatible strings of two boards with the
Allwinner H616 SoC. One is a development board from OrangePi, the other
some TV box from some formerly unused vendor. Add that vendor to the
vendor list on the way.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++++++++++
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 086c68771d2b..539af752dd27 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -858,6 +858,11 @@ properties:
- const: yones-toptech,bs1078-v2
- const: allwinner,sun6i-a31s
+ - description: X96 Mate TV box
+ items:
+ - const: hechuang,x96-mate
+ - const: allwinner,sun50i-h616
+
- description: Xunlong OrangePi
items:
- const: xunlong,orangepi
@@ -958,4 +963,9 @@ properties:
- const: xunlong,orangepi-zero-plus2-h3
- const: allwinner,sun8i-h3
+ - description: Xunlong OrangePi Zero 2
+ items:
+ - const: xunlong,orangepi-zero2
+ - const: allwinner,sun50i-h616
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 01430973ecec..eb50ff3487a7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -503,6 +503,8 @@ patternProperties:
description: Haoyu Microelectronic Co. Ltd.
"^hardkernel,.*":
description: Hardkernel Co., Ltd
+ "^hechuang,.*":
+ description: Shenzhen Hechuang Intelligent Co.
"^hideep,.*":
description: HiDeep Inc.
"^himax,.*":
--
2.35.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 4/6] dt-bindings: arm: sunxi: Add two H616 board compatible strings
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
This adds the two board compatible strings of two boards with the
Allwinner H616 SoC. One is a development board from OrangePi, the other
some TV box from some formerly unused vendor. Add that vendor to the
vendor list on the way.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++++++++++
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 086c68771d2b..539af752dd27 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -858,6 +858,11 @@ properties:
- const: yones-toptech,bs1078-v2
- const: allwinner,sun6i-a31s
+ - description: X96 Mate TV box
+ items:
+ - const: hechuang,x96-mate
+ - const: allwinner,sun50i-h616
+
- description: Xunlong OrangePi
items:
- const: xunlong,orangepi
@@ -958,4 +963,9 @@ properties:
- const: xunlong,orangepi-zero-plus2-h3
- const: allwinner,sun8i-h3
+ - description: Xunlong OrangePi Zero 2
+ items:
+ - const: xunlong,orangepi-zero2
+ - const: allwinner,sun50i-h616
+
additionalProperties: true
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 01430973ecec..eb50ff3487a7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -503,6 +503,8 @@ patternProperties:
description: Haoyu Microelectronic Co. Ltd.
"^hardkernel,.*":
description: Hardkernel Co., Ltd
+ "^hechuang,.*":
+ description: Shenzhen Hechuang Intelligent Co.
"^hideep,.*":
description: HiDeep Inc.
"^himax,.*":
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
2022-04-28 23:09 ` Andre Przywara
@ 2022-04-28 23:09 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
- Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
- 512MiB/1GiB DDR3 DRAM
- AXP305 PMIC
- Raspberry-Pi-1 compatible GPIO header
- extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
- 1 USB 2.0 host port
- 1 USB 2.0 type C port (power supply + OTG)
- MicroSD slot
- on-board 2MiB bootable SPI NOR flash
- 1Gbps Ethernet port (via RTL8211F PHY)
- micro-HDMI port
- unsupported Allwinner WiFi/BT chip
For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../allwinner/sun50i-h616-orangepi-zero2.dts | 203 ++++++++++++++++++
2 files changed, 204 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 8fa5c060a4fe..df2214e6d946 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index 000000000000..ca07cae698ce
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "OrangePi Zero2";
+ compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+ aliases {
+ ethernet0 = &emac0;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+ default-state = "on";
+ };
+
+ led-1 {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+ };
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the USB-C socket */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&emac0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ext_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ phy-supply = <®_dcdce>;
+ allwinner,rx-delay-ps = <3100>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+&mdio0 {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_dcdce>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ bus-width = <4>;
+ status = "okay";
+};
+
+&r_rsb {
+ status = "okay";
+
+ axp305: pmic@745 {
+ compatible = "x-powers,axp305", "x-powers,axp805",
+ "x-powers,axp806";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x745>;
+
+ x-powers,self-working-mode;
+ vina-supply = <®_vcc5v>;
+ vinb-supply = <®_vcc5v>;
+ vinc-supply = <®_vcc5v>;
+ vind-supply = <®_vcc5v>;
+ vine-supply = <®_vcc5v>;
+ aldoin-supply = <®_vcc5v>;
+ bldoin-supply = <®_vcc5v>;
+ cldoin-supply = <®_vcc5v>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-sys";
+ };
+
+ reg_aldo2: aldo2 { /* 3.3V on headers */
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext";
+ };
+
+ reg_aldo3: aldo3 { /* 3.3V on headers */
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext2";
+ };
+
+ reg_bldo1: bldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8";
+ };
+
+ bldo2 {
+ /* unused */
+ };
+
+ bldo3 {
+ /* unused */
+ };
+
+ bldo4 {
+ /* unused */
+ };
+
+ cldo1 {
+ /* reserved */
+ };
+
+ cldo2 {
+ /* unused */
+ };
+
+ cldo3 {
+ /* unused */
+ };
+
+ reg_dcdca: dcdca {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ reg_dcdcc: dcdcc {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-gpu-sys";
+ };
+
+ reg_dcdcd: dcdcd {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vdd-dram";
+ };
+
+ reg_dcdce: dcdce {
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-eth-mmc";
+ };
+
+ sw {
+ /* unused */
+ };
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
--
2.35.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
The OrangePi Zero 2 is a development board with the new H616 SoC. It
comes with the following features:
- Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
- 512MiB/1GiB DDR3 DRAM
- AXP305 PMIC
- Raspberry-Pi-1 compatible GPIO header
- extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
- 1 USB 2.0 host port
- 1 USB 2.0 type C port (power supply + OTG)
- MicroSD slot
- on-board 2MiB bootable SPI NOR flash
- 1Gbps Ethernet port (via RTL8211F PHY)
- micro-HDMI port
- unsupported Allwinner WiFi/BT chip
For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../allwinner/sun50i-h616-orangepi-zero2.dts | 203 ++++++++++++++++++
2 files changed, 204 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 8fa5c060a4fe..df2214e6d946 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
new file mode 100644
index 000000000000..ca07cae698ce
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2020 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "OrangePi Zero2";
+ compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
+
+ aliases {
+ ethernet0 = &emac0;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */
+ default-state = "on";
+ };
+
+ led-1 {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */
+ };
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the USB-C socket */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&emac0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ext_rgmii_pins>;
+ phy-mode = "rgmii";
+ phy-handle = <&ext_rgmii_phy>;
+ phy-supply = <®_dcdce>;
+ allwinner,rx-delay-ps = <3100>;
+ allwinner,tx-delay-ps = <700>;
+ status = "okay";
+};
+
+&mdio0 {
+ ext_rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_dcdce>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ bus-width = <4>;
+ status = "okay";
+};
+
+&r_rsb {
+ status = "okay";
+
+ axp305: pmic@745 {
+ compatible = "x-powers,axp305", "x-powers,axp805",
+ "x-powers,axp806";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x745>;
+
+ x-powers,self-working-mode;
+ vina-supply = <®_vcc5v>;
+ vinb-supply = <®_vcc5v>;
+ vinc-supply = <®_vcc5v>;
+ vind-supply = <®_vcc5v>;
+ vine-supply = <®_vcc5v>;
+ aldoin-supply = <®_vcc5v>;
+ bldoin-supply = <®_vcc5v>;
+ cldoin-supply = <®_vcc5v>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-sys";
+ };
+
+ reg_aldo2: aldo2 { /* 3.3V on headers */
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext";
+ };
+
+ reg_aldo3: aldo3 { /* 3.3V on headers */
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext2";
+ };
+
+ reg_bldo1: bldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8";
+ };
+
+ bldo2 {
+ /* unused */
+ };
+
+ bldo3 {
+ /* unused */
+ };
+
+ bldo4 {
+ /* unused */
+ };
+
+ cldo1 {
+ /* reserved */
+ };
+
+ cldo2 {
+ /* unused */
+ };
+
+ cldo3 {
+ /* unused */
+ };
+
+ reg_dcdca: dcdca {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ reg_dcdcc: dcdcc {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-gpu-sys";
+ };
+
+ reg_dcdcd: dcdcd {
+ regulator-always-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vdd-dram";
+ };
+
+ reg_dcdce: dcdce {
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-eth-mmc";
+ };
+
+ sw {
+ /* unused */
+ };
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 6/6] arm64: dts: allwinner: h616: Add X96 Mate TV box support
2022-04-28 23:09 ` Andre Przywara
@ 2022-04-28 23:09 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
The X96 Mate is an Allwinner H616 based TV box, featuring:
- Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
- 2GiB/4GiB RAM (fully usable!)
- 16/32/64GiB eMMC
- 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
- Unsupported Allwinner WiFi chip
- 2 x USB 2.0 host ports
- HDMI port
- IR receiver
- 5V/2A DC power supply via barrel plug
For more information see: https://linux-sunxi.org/X96_Mate
Add a basic devicetree for it, with SD card and eMMC working, as
well as serial and the essential peripherals, like the AXP PMIC.
This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h616-x96-mate.dts | 177 ++++++++++++++++++
2 files changed, 178 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index df2214e6d946..6a96494a2e0a 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -39,3 +39,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index 000000000000..aedb3a3dff38
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "X96 Mate";
+ compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC input */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&ir {
+ status = "okay";
+};
+
+&mmc0 {
+ vmmc-supply = <®_dcdce>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ bus-width = <4>;
+ status = "okay";
+};
+
+&mmc2 {
+ vmmc-supply = <®_dcdce>;
+ vqmmc-supply = <®_bldo1>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ status = "okay";
+};
+
+&r_rsb {
+ status = "okay";
+
+ axp305: pmic@745 {
+ compatible = "x-powers,axp305", "x-powers,axp805",
+ "x-powers,axp806";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x745>;
+
+ x-powers,self-working-mode;
+ vina-supply = <®_vcc5v>;
+ vinb-supply = <®_vcc5v>;
+ vinc-supply = <®_vcc5v>;
+ vind-supply = <®_vcc5v>;
+ vine-supply = <®_vcc5v>;
+ aldoin-supply = <®_vcc5v>;
+ bldoin-supply = <®_vcc5v>;
+ cldoin-supply = <®_vcc5v>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-sys";
+ };
+
+ /* Enabled by the Android BSP */
+ reg_aldo2: aldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext";
+ status = "disabled";
+ };
+
+ /* Enabled by the Android BSP */
+ reg_aldo3: aldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext2";
+ status = "disabled";
+ };
+
+ reg_bldo1: bldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8";
+ };
+
+ /* Enabled by the Android BSP */
+ reg_bldo2: bldo2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8-2";
+ status = "disabled";
+ };
+
+ bldo3 {
+ /* unused */
+ };
+
+ bldo4 {
+ /* unused */
+ };
+
+ cldo1 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-name = "vcc2v5";
+ };
+
+ cldo2 {
+ /* unused */
+ };
+
+ cldo3 {
+ /* unused */
+ };
+
+ reg_dcdca: dcdca {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ reg_dcdcc: dcdcc {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-gpu-sys";
+ };
+
+ reg_dcdcd: dcdcd {
+ regulator-always-on;
+ regulator-min-microvolt = <1360000>;
+ regulator-max-microvolt = <1360000>;
+ regulator-name = "vdd-dram";
+ };
+
+ reg_dcdce: dcdce {
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-eth-mmc";
+ };
+
+ sw {
+ /* unused */
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
--
2.35.3
^ permalink raw reply related [flat|nested] 54+ messages in thread
* [PATCH v11 6/6] arm64: dts: allwinner: h616: Add X96 Mate TV box support
@ 2022-04-28 23:09 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-04-28 23:09 UTC (permalink / raw)
To: Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
The X96 Mate is an Allwinner H616 based TV box, featuring:
- Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
- 2GiB/4GiB RAM (fully usable!)
- 16/32/64GiB eMMC
- 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
- Unsupported Allwinner WiFi chip
- 2 x USB 2.0 host ports
- HDMI port
- IR receiver
- 5V/2A DC power supply via barrel plug
For more information see: https://linux-sunxi.org/X96_Mate
Add a basic devicetree for it, with SD card and eMMC working, as
well as serial and the essential peripherals, like the AXP PMIC.
This DT is somewhat minimal, and should work on many other similar TV
boxes with the Allwinner H616 chip.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../dts/allwinner/sun50i-h616-x96-mate.dts | 177 ++++++++++++++++++
2 files changed, 178 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index df2214e6d946..6a96494a2e0a 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -39,3 +39,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
new file mode 100644
index 000000000000..aedb3a3dff38
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (C) 2021 Arm Ltd.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h616.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "X96 Mate";
+ compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc5v: vcc5v {
+ /* board wide 5V supply directly from the DC input */
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+};
+
+&ir {
+ status = "okay";
+};
+
+&mmc0 {
+ vmmc-supply = <®_dcdce>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+ bus-width = <4>;
+ status = "okay";
+};
+
+&mmc2 {
+ vmmc-supply = <®_dcdce>;
+ vqmmc-supply = <®_bldo1>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ status = "okay";
+};
+
+&r_rsb {
+ status = "okay";
+
+ axp305: pmic@745 {
+ compatible = "x-powers,axp305", "x-powers,axp805",
+ "x-powers,axp806";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ reg = <0x745>;
+
+ x-powers,self-working-mode;
+ vina-supply = <®_vcc5v>;
+ vinb-supply = <®_vcc5v>;
+ vinc-supply = <®_vcc5v>;
+ vind-supply = <®_vcc5v>;
+ vine-supply = <®_vcc5v>;
+ aldoin-supply = <®_vcc5v>;
+ bldoin-supply = <®_vcc5v>;
+ cldoin-supply = <®_vcc5v>;
+
+ regulators {
+ reg_aldo1: aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-sys";
+ };
+
+ /* Enabled by the Android BSP */
+ reg_aldo2: aldo2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext";
+ status = "disabled";
+ };
+
+ /* Enabled by the Android BSP */
+ reg_aldo3: aldo3 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc3v3-ext2";
+ status = "disabled";
+ };
+
+ reg_bldo1: bldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8";
+ };
+
+ /* Enabled by the Android BSP */
+ reg_bldo2: bldo2 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8-2";
+ status = "disabled";
+ };
+
+ bldo3 {
+ /* unused */
+ };
+
+ bldo4 {
+ /* unused */
+ };
+
+ cldo1 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-name = "vcc2v5";
+ };
+
+ cldo2 {
+ /* unused */
+ };
+
+ cldo3 {
+ /* unused */
+ };
+
+ reg_dcdca: dcdca {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ reg_dcdcc: dcdcc {
+ regulator-always-on;
+ regulator-min-microvolt = <810000>;
+ regulator-max-microvolt = <1080000>;
+ regulator-name = "vdd-gpu-sys";
+ };
+
+ reg_dcdcd: dcdcd {
+ regulator-always-on;
+ regulator-min-microvolt = <1360000>;
+ regulator-max-microvolt = <1360000>;
+ regulator-name = "vdd-dram";
+ };
+
+ reg_dcdce: dcdce {
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-eth-mmc";
+ };
+
+ sw {
+ /* unused */
+ };
+ };
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph_pins>;
+ status = "okay";
+};
--
2.35.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 54+ messages in thread
* Re: [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock
2022-04-28 23:09 ` Andre Przywara
@ 2022-05-03 2:06 ` Samuel Holland
-1 siblings, 0 replies; 54+ messages in thread
From: Samuel Holland @ 2022-05-03 2:06 UTC (permalink / raw)
To: Andre Przywara, Jernej Skrabec, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
On 4/28/22 6:09 PM, Andre Przywara wrote:
> The H6 and H616 feature an (undocumented) bus clock gate for accessing
> the RTC registers. This seems to be enabled at reset (or by the BootROM),
> so we got away without it so far, but exists regardless.
> Since the new RTC clock binding for the H616 requires this "bus" clock
> to be specified in the DT, add this to R_CCU clock driver and expose it
> on the DT side with a new number.
> We do this for both the H6 and H616, but mark it as IGNORE_UNUSED, as we
> cannot reference it in any H6 DTs.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
One tiny nit below, if you resend.
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +++++
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
> include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> index 712e103382d8..88509339031e 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> @@ -98,6 +98,8 @@ static SUNXI_CCU_GATE(r_apb1_ir_clk, "r-apb1-ir", "r-apb1",
> 0x1cc, BIT(0), 0);
> static SUNXI_CCU_GATE(r_apb1_w1_clk, "r-apb1-w1", "r-apb1",
> 0x1ec, BIT(0), 0);
> +static SUNXI_CCU_GATE(r_apb1_rtc_clk, "r-apb1-rtc", "r-apb1",
> + 0x20c, BIT(0), CLK_IGNORE_UNUSED);
>
> /* Information of IR(RX) mod clock is gathered from BSP source code */
> static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M" };
> @@ -147,6 +149,7 @@ static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
> &r_apb2_i2c_clk.common,
> &r_apb2_rsb_clk.common,
> &r_apb1_ir_clk.common,
> + &r_apb1_rtc_clk.common,
> &ir_clk.common,
> };
>
> @@ -163,6 +166,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
> [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
> + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> [CLK_R_APB1_W1] = &r_apb1_w1_clk.common.hw,
The new clock should go after CLK_R_APB1_W1 to match the ordering above.
> [CLK_IR] = &ir_clk.common.hw,
> [CLK_W1] = &w1_clk.common.hw,
> @@ -179,6 +183,7 @@ static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
> [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
> + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> [CLK_IR] = &ir_clk.common.hw,
> },
> .num = CLK_NUMBER,
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> index 7e290b840803..10e9b66afc6a 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> @@ -14,6 +14,6 @@
>
> #define CLK_R_APB2 3
>
> -#define CLK_NUMBER (CLK_R_APB2_RSB + 1)
> +#define CLK_NUMBER (CLK_R_APB1_RTC + 1)
>
> #endif /* _CCU_SUN50I_H6_R_H */
> diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> index 890368d252c4..a96087abc86f 100644
> --- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> +++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> @@ -22,5 +22,6 @@
> #define CLK_W1 12
>
> #define CLK_R_APB2_RSB 13
> +#define CLK_R_APB1_RTC 14
>
> #endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock
@ 2022-05-03 2:06 ` Samuel Holland
0 siblings, 0 replies; 54+ messages in thread
From: Samuel Holland @ 2022-05-03 2:06 UTC (permalink / raw)
To: Andre Przywara, Jernej Skrabec, Chen-Yu Tsai
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
On 4/28/22 6:09 PM, Andre Przywara wrote:
> The H6 and H616 feature an (undocumented) bus clock gate for accessing
> the RTC registers. This seems to be enabled at reset (or by the BootROM),
> so we got away without it so far, but exists regardless.
> Since the new RTC clock binding for the H616 requires this "bus" clock
> to be specified in the DT, add this to R_CCU clock driver and expose it
> on the DT side with a new number.
> We do this for both the H6 and H616, but mark it as IGNORE_UNUSED, as we
> cannot reference it in any H6 DTs.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
One tiny nit below, if you resend.
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +++++
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
> include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> index 712e103382d8..88509339031e 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> @@ -98,6 +98,8 @@ static SUNXI_CCU_GATE(r_apb1_ir_clk, "r-apb1-ir", "r-apb1",
> 0x1cc, BIT(0), 0);
> static SUNXI_CCU_GATE(r_apb1_w1_clk, "r-apb1-w1", "r-apb1",
> 0x1ec, BIT(0), 0);
> +static SUNXI_CCU_GATE(r_apb1_rtc_clk, "r-apb1-rtc", "r-apb1",
> + 0x20c, BIT(0), CLK_IGNORE_UNUSED);
>
> /* Information of IR(RX) mod clock is gathered from BSP source code */
> static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M" };
> @@ -147,6 +149,7 @@ static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
> &r_apb2_i2c_clk.common,
> &r_apb2_rsb_clk.common,
> &r_apb1_ir_clk.common,
> + &r_apb1_rtc_clk.common,
> &ir_clk.common,
> };
>
> @@ -163,6 +166,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
> [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
> + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> [CLK_R_APB1_W1] = &r_apb1_w1_clk.common.hw,
The new clock should go after CLK_R_APB1_W1 to match the ordering above.
> [CLK_IR] = &ir_clk.common.hw,
> [CLK_W1] = &w1_clk.common.hw,
> @@ -179,6 +183,7 @@ static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
> [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
> + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> [CLK_IR] = &ir_clk.common.hw,
> },
> .num = CLK_NUMBER,
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> index 7e290b840803..10e9b66afc6a 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> @@ -14,6 +14,6 @@
>
> #define CLK_R_APB2 3
>
> -#define CLK_NUMBER (CLK_R_APB2_RSB + 1)
> +#define CLK_NUMBER (CLK_R_APB1_RTC + 1)
>
> #endif /* _CCU_SUN50I_H6_R_H */
> diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> index 890368d252c4..a96087abc86f 100644
> --- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> +++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> @@ -22,5 +22,6 @@
> #define CLK_W1 12
>
> #define CLK_R_APB2_RSB 13
> +#define CLK_R_APB1_RTC 14
>
> #endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-04-28 23:09 ` Andre Przywara
@ 2022-05-03 19:05 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:05 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi!
Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> This (relatively) new SoC is similar to the H6, but drops the (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> And while there is still the extra sunxi interrupt controller, the
> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
>
> The reserved memory node is actually handled by Trusted Firmware now,
> but U-Boot fails to propagate this to a separately loaded DTB, so we
> keep it in here for now, until U-Boot learns to do this properly.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> 1 file changed, 574 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
boot/dts/allwinner/sun50i-h616.dtsi
> new file mode 100644
> index 000000000000..cc06cdd15ba5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,574 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Arm Ltd.
> +// based on the H6 dtsi, which is:
> +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@40000000 {
> + reg = <0x0 0x40000000 0x0 0x80000>;
> + no-map;
> + };
> + };
I'm not a fan of above. If anything changes in future in BL31, U-Boot would
need to reconfigure it anyway. Can we just skip it?
> +
> + osc24M: osc24M-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
> + };
Vendor kernel sets IRQ to low level. What is the difference?
> +
> + soc@0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x40000000>;
> +
> + syscon: syscon@3000000 {
> + compatible = "allwinner,sun50i-h616-system-
control";
> + reg = <0x03000000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_c: sram@28000 {
> + compatible = "mmio-sram";
> + reg = <0x00028000 0x30000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x00028000 0x30000>;
> + };
> + };
> +
> + ccu: clock@3001000 {
> + compatible = "allwinner,sun50i-h616-ccu";
> + reg = <0x03001000 0x1000>;
> + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> + clock-names = "hosc", "losc", "iosc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + watchdog: watchdog@30090a0 {
> + compatible = "allwinner,sun50i-h616-wdt",
> + "allwinner,sun6i-a31-wdt";
> + reg = <0x030090a0 0x20>;
> + interrupts = <GIC_SPI 50
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&osc24M>;
> + };
> +
> + pio: pinctrl@300b000 {
> + compatible = "allwinner,sun50i-h616-pinctrl";
> + reg = <0x0300b000 0x400>;
> + interrupts = <GIC_SPI 51
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 52
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 53
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 43
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 54
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 55
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 56
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 57
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
0>;
> + clock-names = "apb", "hosc", "losc";
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + ext_rgmii_pins: rgmii-pins {
> + pins = "PI0", "PI1", "PI2", "PI3",
"PI4",
> + "PI5", "PI7", "PI8", "PI9",
"PI10",
> + "PI11", "PI12", "PI13",
"PI14", "PI15",
> + "PI16";
> + function = "emac0";
> + drive-strength = <40>;
> + };
> +
> + i2c0_pins: i2c0-pins {
> + pins = "PI6", "PI7";
> + function = "i2c0";
> + };
> +
> + i2c3_ph_pins: i2c3-ph-pins {
> + pins = "PH4", "PH5";
> + function = "i2c3";
> + };
> +
> + ir_rx_pin: ir-rx-pin {
> + pins = "PH10";
> + function = "ir_rx";
> + };
> +
> + mmc0_pins: mmc0-pins {
> + pins = "PF0", "PF1", "PF2", "PF3",
> + "PF4", "PF5";
> + function = "mmc0";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + mmc2_pins: mmc2-pins {
> + pins = "PC0", "PC1", "PC5", "PC6",
> + "PC8", "PC9", "PC10",
"PC11",
> + "PC13", "PC14", "PC15",
"PC16";
> + function = "mmc2";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + spi0_pins: spi0-pins {
> + pins = "PC0", "PC2", "PC3", "PC4";
> + function = "spi0";
> + };
> +
> + spi1_pins: spi1-pins {
> + pins = "PH6", "PH7", "PH8";
> + function = "spi1";
> + };
> +
> + spi1_cs_pin: spi1-cs-pin {
> + pins = "PH5";
> + function = "spi1";
> + };
> +
> + uart0_ph_pins: uart0-ph-pins {
> + pins = "PH0", "PH1";
> + function = "uart0";
> + };
> +
> + uart1_pins: uart1-pins {
> + pins = "PG6", "PG7";
> + function = "uart1";
> + };
> +
> + uart1_rts_cts_pins: uart1-rts-cts-pins {
> + pins = "PG8", "PG9";
> + function = "uart1";
> + };
Please add /omit-if-no-ref/ where applicable.
> + };
> +
> + gic: interrupt-controller@3021000 {
> + compatible = "arm,gic-400";
> + reg = <0x03021000 0x1000>,
> + <0x03022000 0x2000>,
> + <0x03024000 0x2000>,
> + <0x03026000 0x2000>;
> + interrupts = <GIC_PPI 9
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + };
> +
> + mmc0: mmc@4020000 {
> + compatible = "allwinner,sun50i-h616-mmc",
> + "allwinner,sun50i-a100-mmc";
> + reg = <0x04020000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC0>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 35
IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + status = "disabled";
> + max-frequency = <150000000>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + mmc-ddr-3_3v;
> + cap-sdio-irq;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc1: mmc@4021000 {
> + compatible = "allwinner,sun50i-h616-mmc",
> + "allwinner,sun50i-a100-mmc";
> + reg = <0x04021000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
CLK_MMC1>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC1>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 36
IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + status = "disabled";
> + max-frequency = <150000000>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + mmc-ddr-3_3v;
> + cap-sdio-irq;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc2: mmc@4022000 {
> + compatible = "allwinner,sun50i-h616-emmc",
> + "allwinner,sun50i-a100-emmc";
> + reg = <0x04022000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
CLK_MMC2>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC2>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 37
IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins>;
> + status = "disabled";
> + max-frequency = <150000000>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + mmc-ddr-3_3v;
> + cap-sdio-irq;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + uart0: serial@5000000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000000 0x400>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + uart1: serial@5000400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000400 0x400>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART1>;
> + resets = <&ccu RST_BUS_UART1>;
> + status = "disabled";
> + };
> +
> + uart2: serial@5000800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000800 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART2>;
> + resets = <&ccu RST_BUS_UART2>;
> + status = "disabled";
> + };
> +
> + uart3: serial@5000c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000c00 0x400>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART3>;
> + resets = <&ccu RST_BUS_UART3>;
> + status = "disabled";
> + };
> +
> + uart4: serial@5001000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05001000 0x400>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART4>;
> + resets = <&ccu RST_BUS_UART4>;
> + status = "disabled";
> + };
> +
> + uart5: serial@5001400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05001400 0x400>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART5>;
> + resets = <&ccu RST_BUS_UART5>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c@5002000 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002000 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c@5002400 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002400 0x400>;
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c@5002800 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002800 0x400>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c3: i2c@5002c00 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002c00 0x400>;
> + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C3>;
> + resets = <&ccu RST_BUS_I2C3>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4: i2c@5003000 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05003000 0x400>;
> + interrupts = <GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C4>;
> + resets = <&ccu RST_BUS_I2C4>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + spi0: spi@5010000 {
> + compatible = "allwinner,sun50i-h616-spi",
> + "allwinner,sun8i-h3-spi";
> + reg = <0x05010000 0x1000>;
> + interrupts = <GIC_SPI 12
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
CLK_SPI0>;
> + clock-names = "ahb", "mod";
> + resets = <&ccu RST_BUS_SPI0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + spi1: spi@5011000 {
> + compatible = "allwinner,sun50i-h616-spi",
> + "allwinner,sun8i-h3-spi";
> + reg = <0x05011000 0x1000>;
> + interrupts = <GIC_SPI 13
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
CLK_SPI1>;
> + clock-names = "ahb", "mod";
> + resets = <&ccu RST_BUS_SPI1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + emac0: ethernet@5020000 {
> + compatible = "allwinner,sun50i-h616-emac",
> + "allwinner,sun50i-a64-emac";
> + syscon = <&syscon>;
> + reg = <0x05020000 0x10000>;
> + interrupts = <GIC_SPI 14
IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq";
> + resets = <&ccu RST_BUS_EMAC0>;
> + reset-names = "stmmaceth";
> + clocks = <&ccu CLK_BUS_EMAC0>;
> + clock-names = "stmmaceth";
> + status = "disabled";
> +
> + mdio0: mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + rtc: rtc@7000000 {
> + compatible = "allwinner,sun50i-h616-rtc";
> + reg = <0x07000000 0x400>;
> + interrupts = <GIC_SPI 101
IRQ_TYPE_LEVEL_HIGH>;
Above interrupt doesn't seem to be correct according to documentation. It
should be 104.
> + clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
> + <&ccu CLK_PLL_SYSTEM_32K>;
> + clock-names = "bus", "hosc",
> + "pll-32k";
> + clock-output-names = "osc32k", "osc32k-out",
"iosc";
> + #clock-cells = <1>;
> + };
> +
> + r_ccu: clock@7010000 {
> + compatible = "allwinner,sun50i-h616-r-ccu";
> + reg = <0x07010000 0x210>;
> + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> + <&ccu CLK_PLL_PERIPH0>;
> + clock-names = "hosc", "losc", "iosc", "pll-
periph";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + r_pio: pinctrl@7022000 {
> + compatible = "allwinner,sun50i-h616-r-
pinctrl";
> + reg = <0x07022000 0x400>;
> + interrupts = <GIC_SPI 43
IRQ_TYPE_LEVEL_HIGH>;
Above interrupt is already used for port E in first pinctrl. Is this shared
somehow?
Best regards,
Jernej
> + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
<&rtc 0>;
> + clock-names = "apb", "hosc", "losc";
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + r_i2c_pins: r-i2c-pins {
> + pins = "PL0", "PL1";
> + function = "s_i2c";
> + };
> +
> + r_rsb_pins: r-rsb-pins {
> + pins = "PL0", "PL1";
> + function = "s_rsb";
> + };
> + };
> +
> + ir: ir@7040000 {
> + compatible = "allwinner,sun50i-h616-ir",
> + "allwinner,sun6i-a31-ir";
> + reg = <0x07040000 0x400>;
> + interrupts = <GIC_SPI 106
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_R_APB1_IR>,
> + <&r_ccu CLK_IR>;
> + clock-names = "apb", "ir";
> + resets = <&r_ccu RST_R_APB1_IR>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_rx_pin>;
> + status = "disabled";
> + };
> +
> + r_i2c: i2c@7081400 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x07081400 0x400>;
> + interrupts = <GIC_SPI 105
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_R_APB2_I2C>;
> + resets = <&r_ccu RST_R_APB2_I2C>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + r_rsb: rsb@7083000 {
> + compatible = "allwinner,sun50i-h616-rsb",
> + "allwinner,sun8i-a23-rsb";
> + reg = <0x07083000 0x400>;
> + interrupts = <GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_R_APB2_RSB>;
> + clock-frequency = <3000000>;
> + resets = <&r_ccu RST_R_APB2_RSB>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&r_rsb_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +};
> --
> 2.35.3
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-05-03 19:05 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:05 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi!
Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> This (relatively) new SoC is similar to the H6, but drops the (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> And while there is still the extra sunxi interrupt controller, the
> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
>
> The reserved memory node is actually handled by Trusted Firmware now,
> but U-Boot fails to propagate this to a separately loaded DTB, so we
> keep it in here for now, until U-Boot learns to do this properly.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> 1 file changed, 574 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
boot/dts/allwinner/sun50i-h616.dtsi
> new file mode 100644
> index 000000000000..cc06cdd15ba5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,574 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Arm Ltd.
> +// based on the H6 dtsi, which is:
> +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@40000000 {
> + reg = <0x0 0x40000000 0x0 0x80000>;
> + no-map;
> + };
> + };
I'm not a fan of above. If anything changes in future in BL31, U-Boot would
need to reconfigure it anyway. Can we just skip it?
> +
> + osc24M: osc24M-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH)>;
> + };
Vendor kernel sets IRQ to low level. What is the difference?
> +
> + soc@0 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x40000000>;
> +
> + syscon: syscon@3000000 {
> + compatible = "allwinner,sun50i-h616-system-
control";
> + reg = <0x03000000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + sram_c: sram@28000 {
> + compatible = "mmio-sram";
> + reg = <0x00028000 0x30000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x00028000 0x30000>;
> + };
> + };
> +
> + ccu: clock@3001000 {
> + compatible = "allwinner,sun50i-h616-ccu";
> + reg = <0x03001000 0x1000>;
> + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> + clock-names = "hosc", "losc", "iosc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + watchdog: watchdog@30090a0 {
> + compatible = "allwinner,sun50i-h616-wdt",
> + "allwinner,sun6i-a31-wdt";
> + reg = <0x030090a0 0x20>;
> + interrupts = <GIC_SPI 50
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&osc24M>;
> + };
> +
> + pio: pinctrl@300b000 {
> + compatible = "allwinner,sun50i-h616-pinctrl";
> + reg = <0x0300b000 0x400>;
> + interrupts = <GIC_SPI 51
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 52
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 53
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 43
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 54
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 55
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 56
IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 57
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
0>;
> + clock-names = "apb", "hosc", "losc";
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + ext_rgmii_pins: rgmii-pins {
> + pins = "PI0", "PI1", "PI2", "PI3",
"PI4",
> + "PI5", "PI7", "PI8", "PI9",
"PI10",
> + "PI11", "PI12", "PI13",
"PI14", "PI15",
> + "PI16";
> + function = "emac0";
> + drive-strength = <40>;
> + };
> +
> + i2c0_pins: i2c0-pins {
> + pins = "PI6", "PI7";
> + function = "i2c0";
> + };
> +
> + i2c3_ph_pins: i2c3-ph-pins {
> + pins = "PH4", "PH5";
> + function = "i2c3";
> + };
> +
> + ir_rx_pin: ir-rx-pin {
> + pins = "PH10";
> + function = "ir_rx";
> + };
> +
> + mmc0_pins: mmc0-pins {
> + pins = "PF0", "PF1", "PF2", "PF3",
> + "PF4", "PF5";
> + function = "mmc0";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + mmc2_pins: mmc2-pins {
> + pins = "PC0", "PC1", "PC5", "PC6",
> + "PC8", "PC9", "PC10",
"PC11",
> + "PC13", "PC14", "PC15",
"PC16";
> + function = "mmc2";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
> + spi0_pins: spi0-pins {
> + pins = "PC0", "PC2", "PC3", "PC4";
> + function = "spi0";
> + };
> +
> + spi1_pins: spi1-pins {
> + pins = "PH6", "PH7", "PH8";
> + function = "spi1";
> + };
> +
> + spi1_cs_pin: spi1-cs-pin {
> + pins = "PH5";
> + function = "spi1";
> + };
> +
> + uart0_ph_pins: uart0-ph-pins {
> + pins = "PH0", "PH1";
> + function = "uart0";
> + };
> +
> + uart1_pins: uart1-pins {
> + pins = "PG6", "PG7";
> + function = "uart1";
> + };
> +
> + uart1_rts_cts_pins: uart1-rts-cts-pins {
> + pins = "PG8", "PG9";
> + function = "uart1";
> + };
Please add /omit-if-no-ref/ where applicable.
> + };
> +
> + gic: interrupt-controller@3021000 {
> + compatible = "arm,gic-400";
> + reg = <0x03021000 0x1000>,
> + <0x03022000 0x2000>,
> + <0x03024000 0x2000>,
> + <0x03026000 0x2000>;
> + interrupts = <GIC_PPI 9
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + };
> +
> + mmc0: mmc@4020000 {
> + compatible = "allwinner,sun50i-h616-mmc",
> + "allwinner,sun50i-a100-mmc";
> + reg = <0x04020000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC0>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 35
IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + status = "disabled";
> + max-frequency = <150000000>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + mmc-ddr-3_3v;
> + cap-sdio-irq;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc1: mmc@4021000 {
> + compatible = "allwinner,sun50i-h616-mmc",
> + "allwinner,sun50i-a100-mmc";
> + reg = <0x04021000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
CLK_MMC1>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC1>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 36
IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + status = "disabled";
> + max-frequency = <150000000>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + mmc-ddr-3_3v;
> + cap-sdio-irq;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + mmc2: mmc@4022000 {
> + compatible = "allwinner,sun50i-h616-emmc",
> + "allwinner,sun50i-a100-emmc";
> + reg = <0x04022000 0x1000>;
> + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
CLK_MMC2>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC2>;
> + reset-names = "ahb";
> + interrupts = <GIC_SPI 37
IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins>;
> + status = "disabled";
> + max-frequency = <150000000>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + mmc-ddr-3_3v;
> + cap-sdio-irq;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + uart0: serial@5000000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000000 0x400>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + uart1: serial@5000400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000400 0x400>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART1>;
> + resets = <&ccu RST_BUS_UART1>;
> + status = "disabled";
> + };
> +
> + uart2: serial@5000800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000800 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART2>;
> + resets = <&ccu RST_BUS_UART2>;
> + status = "disabled";
> + };
> +
> + uart3: serial@5000c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05000c00 0x400>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART3>;
> + resets = <&ccu RST_BUS_UART3>;
> + status = "disabled";
> + };
> +
> + uart4: serial@5001000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05001000 0x400>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART4>;
> + resets = <&ccu RST_BUS_UART4>;
> + status = "disabled";
> + };
> +
> + uart5: serial@5001400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x05001400 0x400>;
> + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART5>;
> + resets = <&ccu RST_BUS_UART5>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c@5002000 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002000 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c@5002400 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002400 0x400>;
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c@5002800 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002800 0x400>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c3: i2c@5002c00 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05002c00 0x400>;
> + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C3>;
> + resets = <&ccu RST_BUS_I2C3>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c4: i2c@5003000 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x05003000 0x400>;
> + interrupts = <GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C4>;
> + resets = <&ccu RST_BUS_I2C4>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + spi0: spi@5010000 {
> + compatible = "allwinner,sun50i-h616-spi",
> + "allwinner,sun8i-h3-spi";
> + reg = <0x05010000 0x1000>;
> + interrupts = <GIC_SPI 12
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
CLK_SPI0>;
> + clock-names = "ahb", "mod";
> + resets = <&ccu RST_BUS_SPI0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi0_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + spi1: spi@5011000 {
> + compatible = "allwinner,sun50i-h616-spi",
> + "allwinner,sun8i-h3-spi";
> + reg = <0x05011000 0x1000>;
> + interrupts = <GIC_SPI 13
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
CLK_SPI1>;
> + clock-names = "ahb", "mod";
> + resets = <&ccu RST_BUS_SPI1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + emac0: ethernet@5020000 {
> + compatible = "allwinner,sun50i-h616-emac",
> + "allwinner,sun50i-a64-emac";
> + syscon = <&syscon>;
> + reg = <0x05020000 0x10000>;
> + interrupts = <GIC_SPI 14
IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "macirq";
> + resets = <&ccu RST_BUS_EMAC0>;
> + reset-names = "stmmaceth";
> + clocks = <&ccu CLK_BUS_EMAC0>;
> + clock-names = "stmmaceth";
> + status = "disabled";
> +
> + mdio0: mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> + rtc: rtc@7000000 {
> + compatible = "allwinner,sun50i-h616-rtc";
> + reg = <0x07000000 0x400>;
> + interrupts = <GIC_SPI 101
IRQ_TYPE_LEVEL_HIGH>;
Above interrupt doesn't seem to be correct according to documentation. It
should be 104.
> + clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
> + <&ccu CLK_PLL_SYSTEM_32K>;
> + clock-names = "bus", "hosc",
> + "pll-32k";
> + clock-output-names = "osc32k", "osc32k-out",
"iosc";
> + #clock-cells = <1>;
> + };
> +
> + r_ccu: clock@7010000 {
> + compatible = "allwinner,sun50i-h616-r-ccu";
> + reg = <0x07010000 0x210>;
> + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> + <&ccu CLK_PLL_PERIPH0>;
> + clock-names = "hosc", "losc", "iosc", "pll-
periph";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + r_pio: pinctrl@7022000 {
> + compatible = "allwinner,sun50i-h616-r-
pinctrl";
> + reg = <0x07022000 0x400>;
> + interrupts = <GIC_SPI 43
IRQ_TYPE_LEVEL_HIGH>;
Above interrupt is already used for port E in first pinctrl. Is this shared
somehow?
Best regards,
Jernej
> + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
<&rtc 0>;
> + clock-names = "apb", "hosc", "losc";
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + r_i2c_pins: r-i2c-pins {
> + pins = "PL0", "PL1";
> + function = "s_i2c";
> + };
> +
> + r_rsb_pins: r-rsb-pins {
> + pins = "PL0", "PL1";
> + function = "s_rsb";
> + };
> + };
> +
> + ir: ir@7040000 {
> + compatible = "allwinner,sun50i-h616-ir",
> + "allwinner,sun6i-a31-ir";
> + reg = <0x07040000 0x400>;
> + interrupts = <GIC_SPI 106
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_R_APB1_IR>,
> + <&r_ccu CLK_IR>;
> + clock-names = "apb", "ir";
> + resets = <&r_ccu RST_R_APB1_IR>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_rx_pin>;
> + status = "disabled";
> + };
> +
> + r_i2c: i2c@7081400 {
> + compatible = "allwinner,sun50i-h616-i2c",
> + "allwinner,sun6i-a31-i2c";
> + reg = <0x07081400 0x400>;
> + interrupts = <GIC_SPI 105
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_R_APB2_I2C>;
> + resets = <&r_ccu RST_R_APB2_I2C>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + r_rsb: rsb@7083000 {
> + compatible = "allwinner,sun50i-h616-rsb",
> + "allwinner,sun8i-a23-rsb";
> + reg = <0x07083000 0x400>;
> + interrupts = <GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&r_ccu CLK_R_APB2_RSB>;
> + clock-frequency = <3000000>;
> + resets = <&r_ccu RST_R_APB2_RSB>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&r_rsb_pins>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +};
> --
> 2.35.3
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-05-03 19:05 ` Jernej Škrabec
@ 2022-05-03 19:41 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:41 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Dne torek, 03. maj 2022 ob 21:05:11 CEST je Jernej Škrabec napisal(a):
> Hi!
>
> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> >
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > 1 file changed, 574 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
> boot/dts/allwinner/sun50i-h616.dtsi
> > new file mode 100644
> > index 000000000000..cc06cdd15ba5
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -0,0 +1,574 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Arm Ltd.
> > +// based on the H6 dtsi, which is:
> > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > +
> > +/ {
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <0>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <1>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <2>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <3>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > + secmon_reserved: secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x80000>;
> > + no-map;
> > + };
> > + };
>
> I'm not a fan of above. If anything changes in future in BL31, U-Boot would
> need to reconfigure it anyway. Can we just skip it?
>
> > +
> > + osc24M: osc24M-clk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <24000000>;
> > + clock-output-names = "osc24M";
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + arm,no-tick-in-suspend;
> > + interrupts = <GIC_PPI 13
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 14
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 11
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>;
> > + };
>
> Vendor kernel sets IRQ to low level. What is the difference?
>
> > +
> > + soc@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x0 0x0 0x40000000>;
> > +
> > + syscon: syscon@3000000 {
> > + compatible = "allwinner,sun50i-h616-system-
> control";
> > + reg = <0x03000000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + sram_c: sram@28000 {
> > + compatible = "mmio-sram";
> > + reg = <0x00028000 0x30000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x00028000 0x30000>;
> > + };
> > + };
> > +
> > + ccu: clock@3001000 {
> > + compatible = "allwinner,sun50i-h616-ccu";
> > + reg = <0x03001000 0x1000>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> > + clock-names = "hosc", "losc", "iosc";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + watchdog: watchdog@30090a0 {
> > + compatible = "allwinner,sun50i-h616-wdt",
> > + "allwinner,sun6i-a31-wdt";
> > + reg = <0x030090a0 0x20>;
> > + interrupts = <GIC_SPI 50
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > + pio: pinctrl@300b000 {
> > + compatible = "allwinner,sun50i-h616-
pinctrl";
> > + reg = <0x0300b000 0x400>;
> > + interrupts = <GIC_SPI 51
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 52
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 53
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 54
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 55
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 56
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 57
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
> 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + ext_rgmii_pins: rgmii-pins {
> > + pins = "PI0", "PI1", "PI2",
"PI3",
> "PI4",
> > + "PI5", "PI7", "PI8",
"PI9",
> "PI10",
> > + "PI11", "PI12", "PI13",
> "PI14", "PI15",
> > + "PI16";
> > + function = "emac0";
> > + drive-strength = <40>;
> > + };
> > +
> > + i2c0_pins: i2c0-pins {
> > + pins = "PI6", "PI7";
> > + function = "i2c0";
> > + };
> > +
> > + i2c3_ph_pins: i2c3-ph-pins {
> > + pins = "PH4", "PH5";
> > + function = "i2c3";
> > + };
> > +
> > + ir_rx_pin: ir-rx-pin {
> > + pins = "PH10";
> > + function = "ir_rx";
> > + };
> > +
> > + mmc0_pins: mmc0-pins {
> > + pins = "PF0", "PF1", "PF2",
"PF3",
> > + "PF4", "PF5";
> > + function = "mmc0";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2",
"PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc2_pins: mmc2-pins {
> > + pins = "PC0", "PC1", "PC5",
"PC6",
> > + "PC8", "PC9", "PC10",
> "PC11",
> > + "PC13", "PC14", "PC15",
> "PC16";
> > + function = "mmc2";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + spi0_pins: spi0-pins {
> > + pins = "PC0", "PC2", "PC3",
"PC4";
> > + function = "spi0";
> > + };
> > +
> > + spi1_pins: spi1-pins {
> > + pins = "PH6", "PH7", "PH8";
> > + function = "spi1";
> > + };
> > +
> > + spi1_cs_pin: spi1-cs-pin {
> > + pins = "PH5";
> > + function = "spi1";
> > + };
> > +
> > + uart0_ph_pins: uart0-ph-pins {
> > + pins = "PH0", "PH1";
> > + function = "uart0";
> > + };
> > +
> > + uart1_pins: uart1-pins {
> > + pins = "PG6", "PG7";
> > + function = "uart1";
> > + };
> > +
> > + uart1_rts_cts_pins: uart1-rts-cts-pins {
> > + pins = "PG8", "PG9";
> > + function = "uart1";
> > + };
>
> Please add /omit-if-no-ref/ where applicable.
>
> > + };
> > +
> > + gic: interrupt-controller@3021000 {
> > + compatible = "arm,gic-400";
> > + reg = <0x03021000 0x1000>,
> > + <0x03022000 0x2000>,
> > + <0x03024000 0x2000>,
> > + <0x03026000 0x2000>;
> > + interrupts = <GIC_PPI 9
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + };
> > +
> > + mmc0: mmc@4020000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04020000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> CLK_MMC0>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC0>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 35
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc1: mmc@4021000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04021000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
> CLK_MMC1>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC1>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 36
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc2: mmc@4022000 {
> > + compatible = "allwinner,sun50i-h616-emmc",
> > + "allwinner,sun50i-a100-
emmc";
> > + reg = <0x04022000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
> CLK_MMC2>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC2>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 37
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc2_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + uart0: serial@5000000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000000 0x400>;
> > + interrupts = <GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART0>;
> > + resets = <&ccu RST_BUS_UART0>;
> > + status = "disabled";
> > + };
> > +
> > + uart1: serial@5000400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000400 0x400>;
> > + interrupts = <GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART1>;
> > + resets = <&ccu RST_BUS_UART1>;
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@5000800 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000800 0x400>;
> > + interrupts = <GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART2>;
> > + resets = <&ccu RST_BUS_UART2>;
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@5000c00 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000c00 0x400>;
> > + interrupts = <GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART3>;
> > + resets = <&ccu RST_BUS_UART3>;
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@5001000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001000 0x400>;
> > + interrupts = <GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART4>;
> > + resets = <&ccu RST_BUS_UART4>;
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial@5001400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001400 0x400>;
> > + interrupts = <GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART5>;
> > + resets = <&ccu RST_BUS_UART5>;
> > + status = "disabled";
> > + };
> > +
> > + i2c0: i2c@5002000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002000 0x400>;
> > + interrupts = <GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C0>;
> > + resets = <&ccu RST_BUS_I2C0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c1: i2c@5002400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002400 0x400>;
> > + interrupts = <GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C1>;
> > + resets = <&ccu RST_BUS_I2C1>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c2: i2c@5002800 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002800 0x400>;
> > + interrupts = <GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C2>;
> > + resets = <&ccu RST_BUS_I2C2>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c3: i2c@5002c00 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002c00 0x400>;
> > + interrupts = <GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C3>;
> > + resets = <&ccu RST_BUS_I2C3>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c4: i2c@5003000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05003000 0x400>;
> > + interrupts = <GIC_SPI 10
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C4>;
> > + resets = <&ccu RST_BUS_I2C4>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi0: spi@5010000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05010000 0x1000>;
> > + interrupts = <GIC_SPI 12
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
> CLK_SPI0>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi1: spi@5011000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05011000 0x1000>;
> > + interrupts = <GIC_SPI 13
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
> CLK_SPI1>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi1_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
Please remove default pins for SPI controllers. There are few different
combinations possible, so better add them in board DT files.
Best regards,
Jernej
> > +
> > + emac0: ethernet@5020000 {
> > + compatible = "allwinner,sun50i-h616-emac",
> > + "allwinner,sun50i-a64-emac";
> > + syscon = <&syscon>;
> > + reg = <0x05020000 0x10000>;
> > + interrupts = <GIC_SPI 14
> IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "macirq";
> > + resets = <&ccu RST_BUS_EMAC0>;
> > + reset-names = "stmmaceth";
> > + clocks = <&ccu CLK_BUS_EMAC0>;
> > + clock-names = "stmmaceth";
> > + status = "disabled";
> > +
> > + mdio0: mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +
> > + rtc: rtc@7000000 {
> > + compatible = "allwinner,sun50i-h616-rtc";
> > + reg = <0x07000000 0x400>;
> > + interrupts = <GIC_SPI 101
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt doesn't seem to be correct according to documentation. It
> should be 104.
>
> > + clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
> > + <&ccu CLK_PLL_SYSTEM_32K>;
> > + clock-names = "bus", "hosc",
> > + "pll-32k";
> > + clock-output-names = "osc32k", "osc32k-out",
> "iosc";
> > + #clock-cells = <1>;
> > + };
> > +
> > + r_ccu: clock@7010000 {
> > + compatible = "allwinner,sun50i-h616-r-ccu";
> > + reg = <0x07010000 0x210>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> > + <&ccu CLK_PLL_PERIPH0>;
> > + clock-names = "hosc", "losc", "iosc", "pll-
> periph";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + r_pio: pinctrl@7022000 {
> > + compatible = "allwinner,sun50i-h616-r-
> pinctrl";
> > + reg = <0x07022000 0x400>;
> > + interrupts = <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt is already used for port E in first pinctrl. Is this shared
> somehow?
>
> Best regards,
> Jernej
>
> > + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
> <&rtc 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + r_i2c_pins: r-i2c-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_i2c";
> > + };
> > +
> > + r_rsb_pins: r-rsb-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_rsb";
> > + };
> > + };
> > +
> > + ir: ir@7040000 {
> > + compatible = "allwinner,sun50i-h616-ir",
> > + "allwinner,sun6i-a31-ir";
> > + reg = <0x07040000 0x400>;
> > + interrupts = <GIC_SPI 106
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB1_IR>,
> > + <&r_ccu CLK_IR>;
> > + clock-names = "apb", "ir";
> > + resets = <&r_ccu RST_R_APB1_IR>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ir_rx_pin>;
> > + status = "disabled";
> > + };
> > +
> > + r_i2c: i2c@7081400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x07081400 0x400>;
> > + interrupts = <GIC_SPI 105
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_I2C>;
> > + resets = <&r_ccu RST_R_APB2_I2C>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + r_rsb: rsb@7083000 {
> > + compatible = "allwinner,sun50i-h616-rsb",
> > + "allwinner,sun8i-a23-rsb";
> > + reg = <0x07083000 0x400>;
> > + interrupts = <GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_RSB>;
> > + clock-frequency = <3000000>;
> > + resets = <&r_ccu RST_R_APB2_RSB>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&r_rsb_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +};
> > --
> > 2.35.3
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-05-03 19:41 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:41 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Dne torek, 03. maj 2022 ob 21:05:11 CEST je Jernej Škrabec napisal(a):
> Hi!
>
> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> >
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > 1 file changed, 574 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
> boot/dts/allwinner/sun50i-h616.dtsi
> > new file mode 100644
> > index 000000000000..cc06cdd15ba5
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -0,0 +1,574 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Arm Ltd.
> > +// based on the H6 dtsi, which is:
> > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > +
> > +/ {
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <0>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <1>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <2>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <3>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > + secmon_reserved: secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x80000>;
> > + no-map;
> > + };
> > + };
>
> I'm not a fan of above. If anything changes in future in BL31, U-Boot would
> need to reconfigure it anyway. Can we just skip it?
>
> > +
> > + osc24M: osc24M-clk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <24000000>;
> > + clock-output-names = "osc24M";
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + arm,no-tick-in-suspend;
> > + interrupts = <GIC_PPI 13
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 14
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 11
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>;
> > + };
>
> Vendor kernel sets IRQ to low level. What is the difference?
>
> > +
> > + soc@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x0 0x0 0x40000000>;
> > +
> > + syscon: syscon@3000000 {
> > + compatible = "allwinner,sun50i-h616-system-
> control";
> > + reg = <0x03000000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + sram_c: sram@28000 {
> > + compatible = "mmio-sram";
> > + reg = <0x00028000 0x30000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x00028000 0x30000>;
> > + };
> > + };
> > +
> > + ccu: clock@3001000 {
> > + compatible = "allwinner,sun50i-h616-ccu";
> > + reg = <0x03001000 0x1000>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> > + clock-names = "hosc", "losc", "iosc";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + watchdog: watchdog@30090a0 {
> > + compatible = "allwinner,sun50i-h616-wdt",
> > + "allwinner,sun6i-a31-wdt";
> > + reg = <0x030090a0 0x20>;
> > + interrupts = <GIC_SPI 50
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > + pio: pinctrl@300b000 {
> > + compatible = "allwinner,sun50i-h616-
pinctrl";
> > + reg = <0x0300b000 0x400>;
> > + interrupts = <GIC_SPI 51
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 52
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 53
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 54
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 55
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 56
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 57
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
> 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + ext_rgmii_pins: rgmii-pins {
> > + pins = "PI0", "PI1", "PI2",
"PI3",
> "PI4",
> > + "PI5", "PI7", "PI8",
"PI9",
> "PI10",
> > + "PI11", "PI12", "PI13",
> "PI14", "PI15",
> > + "PI16";
> > + function = "emac0";
> > + drive-strength = <40>;
> > + };
> > +
> > + i2c0_pins: i2c0-pins {
> > + pins = "PI6", "PI7";
> > + function = "i2c0";
> > + };
> > +
> > + i2c3_ph_pins: i2c3-ph-pins {
> > + pins = "PH4", "PH5";
> > + function = "i2c3";
> > + };
> > +
> > + ir_rx_pin: ir-rx-pin {
> > + pins = "PH10";
> > + function = "ir_rx";
> > + };
> > +
> > + mmc0_pins: mmc0-pins {
> > + pins = "PF0", "PF1", "PF2",
"PF3",
> > + "PF4", "PF5";
> > + function = "mmc0";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2",
"PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc2_pins: mmc2-pins {
> > + pins = "PC0", "PC1", "PC5",
"PC6",
> > + "PC8", "PC9", "PC10",
> "PC11",
> > + "PC13", "PC14", "PC15",
> "PC16";
> > + function = "mmc2";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + spi0_pins: spi0-pins {
> > + pins = "PC0", "PC2", "PC3",
"PC4";
> > + function = "spi0";
> > + };
> > +
> > + spi1_pins: spi1-pins {
> > + pins = "PH6", "PH7", "PH8";
> > + function = "spi1";
> > + };
> > +
> > + spi1_cs_pin: spi1-cs-pin {
> > + pins = "PH5";
> > + function = "spi1";
> > + };
> > +
> > + uart0_ph_pins: uart0-ph-pins {
> > + pins = "PH0", "PH1";
> > + function = "uart0";
> > + };
> > +
> > + uart1_pins: uart1-pins {
> > + pins = "PG6", "PG7";
> > + function = "uart1";
> > + };
> > +
> > + uart1_rts_cts_pins: uart1-rts-cts-pins {
> > + pins = "PG8", "PG9";
> > + function = "uart1";
> > + };
>
> Please add /omit-if-no-ref/ where applicable.
>
> > + };
> > +
> > + gic: interrupt-controller@3021000 {
> > + compatible = "arm,gic-400";
> > + reg = <0x03021000 0x1000>,
> > + <0x03022000 0x2000>,
> > + <0x03024000 0x2000>,
> > + <0x03026000 0x2000>;
> > + interrupts = <GIC_PPI 9
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + };
> > +
> > + mmc0: mmc@4020000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04020000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> CLK_MMC0>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC0>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 35
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc1: mmc@4021000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04021000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
> CLK_MMC1>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC1>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 36
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc2: mmc@4022000 {
> > + compatible = "allwinner,sun50i-h616-emmc",
> > + "allwinner,sun50i-a100-
emmc";
> > + reg = <0x04022000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
> CLK_MMC2>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC2>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 37
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc2_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + uart0: serial@5000000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000000 0x400>;
> > + interrupts = <GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART0>;
> > + resets = <&ccu RST_BUS_UART0>;
> > + status = "disabled";
> > + };
> > +
> > + uart1: serial@5000400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000400 0x400>;
> > + interrupts = <GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART1>;
> > + resets = <&ccu RST_BUS_UART1>;
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@5000800 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000800 0x400>;
> > + interrupts = <GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART2>;
> > + resets = <&ccu RST_BUS_UART2>;
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@5000c00 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000c00 0x400>;
> > + interrupts = <GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART3>;
> > + resets = <&ccu RST_BUS_UART3>;
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@5001000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001000 0x400>;
> > + interrupts = <GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART4>;
> > + resets = <&ccu RST_BUS_UART4>;
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial@5001400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001400 0x400>;
> > + interrupts = <GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART5>;
> > + resets = <&ccu RST_BUS_UART5>;
> > + status = "disabled";
> > + };
> > +
> > + i2c0: i2c@5002000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002000 0x400>;
> > + interrupts = <GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C0>;
> > + resets = <&ccu RST_BUS_I2C0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c1: i2c@5002400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002400 0x400>;
> > + interrupts = <GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C1>;
> > + resets = <&ccu RST_BUS_I2C1>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c2: i2c@5002800 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002800 0x400>;
> > + interrupts = <GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C2>;
> > + resets = <&ccu RST_BUS_I2C2>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c3: i2c@5002c00 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002c00 0x400>;
> > + interrupts = <GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C3>;
> > + resets = <&ccu RST_BUS_I2C3>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c4: i2c@5003000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05003000 0x400>;
> > + interrupts = <GIC_SPI 10
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C4>;
> > + resets = <&ccu RST_BUS_I2C4>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi0: spi@5010000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05010000 0x1000>;
> > + interrupts = <GIC_SPI 12
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
> CLK_SPI0>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi1: spi@5011000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05011000 0x1000>;
> > + interrupts = <GIC_SPI 13
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
> CLK_SPI1>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi1_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
Please remove default pins for SPI controllers. There are few different
combinations possible, so better add them in board DT files.
Best regards,
Jernej
> > +
> > + emac0: ethernet@5020000 {
> > + compatible = "allwinner,sun50i-h616-emac",
> > + "allwinner,sun50i-a64-emac";
> > + syscon = <&syscon>;
> > + reg = <0x05020000 0x10000>;
> > + interrupts = <GIC_SPI 14
> IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "macirq";
> > + resets = <&ccu RST_BUS_EMAC0>;
> > + reset-names = "stmmaceth";
> > + clocks = <&ccu CLK_BUS_EMAC0>;
> > + clock-names = "stmmaceth";
> > + status = "disabled";
> > +
> > + mdio0: mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +
> > + rtc: rtc@7000000 {
> > + compatible = "allwinner,sun50i-h616-rtc";
> > + reg = <0x07000000 0x400>;
> > + interrupts = <GIC_SPI 101
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt doesn't seem to be correct according to documentation. It
> should be 104.
>
> > + clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
> > + <&ccu CLK_PLL_SYSTEM_32K>;
> > + clock-names = "bus", "hosc",
> > + "pll-32k";
> > + clock-output-names = "osc32k", "osc32k-out",
> "iosc";
> > + #clock-cells = <1>;
> > + };
> > +
> > + r_ccu: clock@7010000 {
> > + compatible = "allwinner,sun50i-h616-r-ccu";
> > + reg = <0x07010000 0x210>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> > + <&ccu CLK_PLL_PERIPH0>;
> > + clock-names = "hosc", "losc", "iosc", "pll-
> periph";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + r_pio: pinctrl@7022000 {
> > + compatible = "allwinner,sun50i-h616-r-
> pinctrl";
> > + reg = <0x07022000 0x400>;
> > + interrupts = <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt is already used for port E in first pinctrl. Is this shared
> somehow?
>
> Best regards,
> Jernej
>
> > + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
> <&rtc 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + r_i2c_pins: r-i2c-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_i2c";
> > + };
> > +
> > + r_rsb_pins: r-rsb-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_rsb";
> > + };
> > + };
> > +
> > + ir: ir@7040000 {
> > + compatible = "allwinner,sun50i-h616-ir",
> > + "allwinner,sun6i-a31-ir";
> > + reg = <0x07040000 0x400>;
> > + interrupts = <GIC_SPI 106
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB1_IR>,
> > + <&r_ccu CLK_IR>;
> > + clock-names = "apb", "ir";
> > + resets = <&r_ccu RST_R_APB1_IR>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ir_rx_pin>;
> > + status = "disabled";
> > + };
> > +
> > + r_i2c: i2c@7081400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x07081400 0x400>;
> > + interrupts = <GIC_SPI 105
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_I2C>;
> > + resets = <&r_ccu RST_R_APB2_I2C>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + r_rsb: rsb@7083000 {
> > + compatible = "allwinner,sun50i-h616-rsb",
> > + "allwinner,sun8i-a23-rsb";
> > + reg = <0x07083000 0x400>;
> > + interrupts = <GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_RSB>;
> > + clock-frequency = <3000000>;
> > + resets = <&r_ccu RST_R_APB2_RSB>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&r_rsb_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +};
> > --
> > 2.35.3
> >
> >
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
2022-04-28 23:09 ` Andre Przywara
@ 2022-05-03 19:41 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:41 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Dne petek, 29. april 2022 ob 01:09:32 CEST je Andre Przywara napisal(a):
> The OrangePi Zero 2 is a development board with the new H616 SoC. It
> comes with the following features:
> - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> - 512MiB/1GiB DDR3 DRAM
> - AXP305 PMIC
> - Raspberry-Pi-1 compatible GPIO header
> - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
> - 1 USB 2.0 host port
> - 1 USB 2.0 type C port (power supply + OTG)
> - MicroSD slot
> - on-board 2MiB bootable SPI NOR flash
> - 1Gbps Ethernet port (via RTL8211F PHY)
> - micro-HDMI port
> - unsupported Allwinner WiFi/BT chip
>
> For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2
Please no external links.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-h616-orangepi-zero2.dts | 203 ++++++++++++++++++
> 2 files changed, 204 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
zero2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> index 8fa5c060a4fe..df2214e6d946 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/
arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> new file mode 100644
> index 000000000000..ca07cae698ce
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2020 Arm Ltd.
2022?
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> + model = "OrangePi Zero2";
> + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> +
> + aliases {
> + ethernet0 = &emac0;
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12
*/
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13
*/
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the USB-C socket
*/
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +};
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ext_rgmii_pins>;
> + phy-mode = "rgmii";
> + phy-handle = <&ext_rgmii_phy>;
> + phy-supply = <®_dcdce>;
> + allwinner,rx-delay-ps = <3100>;
> + allwinner,tx-delay-ps = <700>;
> + status = "okay";
> +};
> +
> +&mdio0 {
> + ext_rgmii_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdce>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&r_rsb {
> + status = "okay";
> +
> + axp305: pmic@745 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x745>;
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-sys";
> + };
> +
> + reg_aldo2: aldo2 { /* 3.3V on headers
*/
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext";
> + };
> +
> + reg_aldo3: aldo3 { /* 3.3V on headers
*/
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext2";
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-name = "vcc1v8";
> + };
> +
> + bldo2 {
> + /* unused */
> + };
> +
> + bldo3 {
> + /* unused */
> + };
> +
> + bldo4 {
> + /* unused */
> + };
> +
> + cldo1 {
> + /* reserved */
> + };
> +
> + cldo2 {
> + /* unused */
> + };
> +
> + cldo3 {
> + /* unused */
> + };
> +
> + reg_dcdca: dcdca {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + reg_dcdcc: dcdcc {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-gpu-sys";
> + };
> +
> + reg_dcdcd: dcdcd {
> + regulator-always-on;
> + regulator-min-microvolt =
<1500000>;
> + regulator-max-microvolt =
<1500000>;
> + regulator-name = "vdd-dram";
> + };
> +
> + reg_dcdce: dcdce {
> + regulator-boot-on;
As discussed in the past, this will cause reboot issues because Linux will
turn down above regulator and thus SD card will stop working. This should be
always on.
And please add pio regulators, this is something we always add later...
Best regards,
Jernej
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-eth-mmc";
> + };
> +
> + sw {
> + /* unused */
> + };
> + };
> + };
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <40000000>;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> --
> 2.35.3
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
@ 2022-05-03 19:41 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:41 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Dne petek, 29. april 2022 ob 01:09:32 CEST je Andre Przywara napisal(a):
> The OrangePi Zero 2 is a development board with the new H616 SoC. It
> comes with the following features:
> - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> - 512MiB/1GiB DDR3 DRAM
> - AXP305 PMIC
> - Raspberry-Pi-1 compatible GPIO header
> - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
> - 1 USB 2.0 host port
> - 1 USB 2.0 type C port (power supply + OTG)
> - MicroSD slot
> - on-board 2MiB bootable SPI NOR flash
> - 1Gbps Ethernet port (via RTL8211F PHY)
> - micro-HDMI port
> - unsupported Allwinner WiFi/BT chip
>
> For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2
Please no external links.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-h616-orangepi-zero2.dts | 203 ++++++++++++++++++
> 2 files changed, 204 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
zero2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> index 8fa5c060a4fe..df2214e6d946 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/
arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> new file mode 100644
> index 000000000000..ca07cae698ce
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> @@ -0,0 +1,203 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2020 Arm Ltd.
2022?
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/leds/common.h>
> +
> +/ {
> + model = "OrangePi Zero2";
> + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> +
> + aliases {
> + ethernet0 = &emac0;
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led-0 {
> + function = LED_FUNCTION_POWER;
> + color = <LED_COLOR_ID_RED>;
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12
*/
> + default-state = "on";
> + };
> +
> + led-1 {
> + function = LED_FUNCTION_STATUS;
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13
*/
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the USB-C socket
*/
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +};
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ext_rgmii_pins>;
> + phy-mode = "rgmii";
> + phy-handle = <&ext_rgmii_phy>;
> + phy-supply = <®_dcdce>;
> + allwinner,rx-delay-ps = <3100>;
> + allwinner,tx-delay-ps = <700>;
> + status = "okay";
> +};
> +
> +&mdio0 {
> + ext_rgmii_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdce>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&r_rsb {
> + status = "okay";
> +
> + axp305: pmic@745 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x745>;
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-sys";
> + };
> +
> + reg_aldo2: aldo2 { /* 3.3V on headers
*/
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext";
> + };
> +
> + reg_aldo3: aldo3 { /* 3.3V on headers
*/
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext2";
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-name = "vcc1v8";
> + };
> +
> + bldo2 {
> + /* unused */
> + };
> +
> + bldo3 {
> + /* unused */
> + };
> +
> + bldo4 {
> + /* unused */
> + };
> +
> + cldo1 {
> + /* reserved */
> + };
> +
> + cldo2 {
> + /* unused */
> + };
> +
> + cldo3 {
> + /* unused */
> + };
> +
> + reg_dcdca: dcdca {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + reg_dcdcc: dcdcc {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-gpu-sys";
> + };
> +
> + reg_dcdcd: dcdcd {
> + regulator-always-on;
> + regulator-min-microvolt =
<1500000>;
> + regulator-max-microvolt =
<1500000>;
> + regulator-name = "vdd-dram";
> + };
> +
> + reg_dcdce: dcdce {
> + regulator-boot-on;
As discussed in the past, this will cause reboot issues because Linux will
turn down above regulator and thus SD card will stop working. This should be
always on.
And please add pio regulators, this is something we always add later...
Best regards,
Jernej
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-eth-mmc";
> + };
> +
> + sw {
> + /* unused */
> + };
> + };
> + };
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <40000000>;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> --
> 2.35.3
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 6/6] arm64: dts: allwinner: h616: Add X96 Mate TV box support
2022-04-28 23:09 ` Andre Przywara
@ 2022-05-03 19:44 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:44 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Similar comments as for OrangePi Zero2...
Dne petek, 29. april 2022 ob 01:09:33 CEST je Andre Przywara napisal(a):
> The X96 Mate is an Allwinner H616 based TV box, featuring:
> - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> - 2GiB/4GiB RAM (fully usable!)
> - 16/32/64GiB eMMC
> - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
> - Unsupported Allwinner WiFi chip
> - 2 x USB 2.0 host ports
> - HDMI port
> - IR receiver
> - 5V/2A DC power supply via barrel plug
>
> For more information see: https://linux-sunxi.org/X96_Mate
Please remove external links.
>
> Add a basic devicetree for it, with SD card and eMMC working, as
> well as serial and the essential peripherals, like the AXP PMIC.
>
> This DT is somewhat minimal, and should work on many other similar TV
> boxes with the Allwinner H616 chip.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h616-x96-mate.dts | 177 ++++++++++++++++++
> 2 files changed, 178 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> index df2214e6d946..6a96494a2e0a 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -39,3 +39,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/
arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> new file mode 100644
> index 000000000000..aedb3a3dff38
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> @@ -0,0 +1,177 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2021 Arm Ltd.
2022?
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + model = "X96 Mate";
> + compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC input */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +};
> +
> +&ir {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdce>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&mmc2 {
> + vmmc-supply = <®_dcdce>;
> + vqmmc-supply = <®_bldo1>;
> + bus-width = <8>;
> + non-removable;
> + cap-mmc-hw-reset;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + status = "okay";
> +};
> +
> +&r_rsb {
> + status = "okay";
> +
> + axp305: pmic@745 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x745>;
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-sys";
> + };
> +
> + /* Enabled by the Android BSP */
> + reg_aldo2: aldo2 {
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext";
> + status = "disabled";
> + };
> +
> + /* Enabled by the Android BSP */
> + reg_aldo3: aldo3 {
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext2";
> + status = "disabled";
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-name = "vcc1v8";
> + };
> +
> + /* Enabled by the Android BSP */
> + reg_bldo2: bldo2 {
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-name = "vcc1v8-2";
> + status = "disabled";
> + };
> +
> + bldo3 {
> + /* unused */
> + };
> +
> + bldo4 {
> + /* unused */
> + };
> +
> + cldo1 {
> + regulator-min-microvolt =
<2500000>;
> + regulator-max-microvolt =
<2500000>;
> + regulator-name = "vcc2v5";
> + };
> +
> + cldo2 {
> + /* unused */
> + };
> +
> + cldo3 {
> + /* unused */
> + };
> +
> + reg_dcdca: dcdca {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + reg_dcdcc: dcdcc {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-gpu-sys";
> + };
> +
> + reg_dcdcd: dcdcd {
> + regulator-always-on;
> + regulator-min-microvolt =
<1360000>;
> + regulator-max-microvolt =
<1360000>;
> + regulator-name = "vdd-dram";
> + };
> +
> + reg_dcdce: dcdce {
> + regulator-boot-on;
Did you check if reboot (when booted from SD card) works? It should have same
issue as OrangePi Zero2.
Please also check and add pio power supplies.
Best regards,
Jernej
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-eth-mmc";
> + };
> +
> + sw {
> + /* unused */
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> --
> 2.35.3
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 6/6] arm64: dts: allwinner: h616: Add X96 Mate TV box support
@ 2022-05-03 19:44 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-03 19:44 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Similar comments as for OrangePi Zero2...
Dne petek, 29. april 2022 ob 01:09:33 CEST je Andre Przywara napisal(a):
> The X96 Mate is an Allwinner H616 based TV box, featuring:
> - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> - 2GiB/4GiB RAM (fully usable!)
> - 16/32/64GiB eMMC
> - 100Mbps Ethernet (via embedded AC200 EPHY, not yet supported)
> - Unsupported Allwinner WiFi chip
> - 2 x USB 2.0 host ports
> - HDMI port
> - IR receiver
> - 5V/2A DC power supply via barrel plug
>
> For more information see: https://linux-sunxi.org/X96_Mate
Please remove external links.
>
> Add a basic devicetree for it, with SD card and eMMC working, as
> well as serial and the essential peripherals, like the AXP PMIC.
>
> This DT is somewhat minimal, and should work on many other similar TV
> boxes with the Allwinner H616 chip.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../dts/allwinner/sun50i-h616-x96-mate.dts | 177 ++++++++++++++++++
> 2 files changed, 178 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
allwinner/Makefile
> index df2214e6d946..6a96494a2e0a 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -39,3 +39,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-x96-mate.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts b/arch/
arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> new file mode 100644
> index 000000000000..aedb3a3dff38
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> @@ -0,0 +1,177 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2021 Arm Ltd.
2022?
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + model = "X96 Mate";
> + compatible = "hechuang,x96-mate", "allwinner,sun50i-h616";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the DC input */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +};
> +
> +&ir {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdce>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&mmc2 {
> + vmmc-supply = <®_dcdce>;
> + vqmmc-supply = <®_bldo1>;
> + bus-width = <8>;
> + non-removable;
> + cap-mmc-hw-reset;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + status = "okay";
> +};
> +
> +&r_rsb {
> + status = "okay";
> +
> + axp305: pmic@745 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x745>;
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-sys";
> + };
> +
> + /* Enabled by the Android BSP */
> + reg_aldo2: aldo2 {
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext";
> + status = "disabled";
> + };
> +
> + /* Enabled by the Android BSP */
> + reg_aldo3: aldo3 {
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc3v3-ext2";
> + status = "disabled";
> + };
> +
> + reg_bldo1: bldo1 {
> + regulator-always-on;
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-name = "vcc1v8";
> + };
> +
> + /* Enabled by the Android BSP */
> + reg_bldo2: bldo2 {
> + regulator-min-microvolt =
<1800000>;
> + regulator-max-microvolt =
<1800000>;
> + regulator-name = "vcc1v8-2";
> + status = "disabled";
> + };
> +
> + bldo3 {
> + /* unused */
> + };
> +
> + bldo4 {
> + /* unused */
> + };
> +
> + cldo1 {
> + regulator-min-microvolt =
<2500000>;
> + regulator-max-microvolt =
<2500000>;
> + regulator-name = "vcc2v5";
> + };
> +
> + cldo2 {
> + /* unused */
> + };
> +
> + cldo3 {
> + /* unused */
> + };
> +
> + reg_dcdca: dcdca {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + reg_dcdcc: dcdcc {
> + regulator-always-on;
> + regulator-min-microvolt =
<810000>;
> + regulator-max-microvolt =
<1080000>;
> + regulator-name = "vdd-gpu-sys";
> + };
> +
> + reg_dcdcd: dcdcd {
> + regulator-always-on;
> + regulator-min-microvolt =
<1360000>;
> + regulator-max-microvolt =
<1360000>;
> + regulator-name = "vdd-dram";
> + };
> +
> + reg_dcdce: dcdce {
> + regulator-boot-on;
Did you check if reboot (when booted from SD card) works? It should have same
issue as OrangePi Zero2.
Please also check and add pio power supplies.
Best regards,
Jernej
> + regulator-min-microvolt =
<3300000>;
> + regulator-max-microvolt =
<3300000>;
> + regulator-name = "vcc-eth-mmc";
> + };
> +
> + sw {
> + /* unused */
> + };
> + };
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_ph_pins>;
> + status = "okay";
> +};
> --
> 2.35.3
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock
2022-05-03 2:06 ` Samuel Holland
@ 2022-05-06 16:10 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-06 16:10 UTC (permalink / raw)
To: Andre Przywara, Chen-Yu Tsai, Samuel Holland
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
Dne torek, 03. maj 2022 ob 04:06:59 CEST je Samuel Holland napisal(a):
> On 4/28/22 6:09 PM, Andre Przywara wrote:
> > The H6 and H616 feature an (undocumented) bus clock gate for accessing
> > the RTC registers. This seems to be enabled at reset (or by the BootROM),
> > so we got away without it so far, but exists regardless.
> > Since the new RTC clock binding for the H616 requires this "bus" clock
> > to be specified in the DT, add this to R_CCU clock driver and expose it
> > on the DT side with a new number.
> > We do this for both the H6 and H616, but mark it as IGNORE_UNUSED, as we
> > cannot reference it in any H6 DTs.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> Reviewed-by: Samuel Holland <samuel@sholland.org>
>
> One tiny nit below, if you resend.
Fixed and applied to sunxi/clk-for-5.19, thanks!
Best regards,
Jernej
>
> > ---
> > drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +++++
> > drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
> > include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
> > 3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.c
> > index 712e103382d8..88509339031e 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> > @@ -98,6 +98,8 @@ static SUNXI_CCU_GATE(r_apb1_ir_clk, "r-apb1-ir",
"r-apb1",
> > 0x1cc, BIT(0), 0);
> > static SUNXI_CCU_GATE(r_apb1_w1_clk, "r-apb1-w1", "r-apb1",
> > 0x1ec, BIT(0), 0);
> > +static SUNXI_CCU_GATE(r_apb1_rtc_clk, "r-apb1-rtc", "r-apb1",
> > + 0x20c, BIT(0), CLK_IGNORE_UNUSED);
> >
> > /* Information of IR(RX) mod clock is gathered from BSP source code */
> > static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M"
};
> > @@ -147,6 +149,7 @@ static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
> > &r_apb2_i2c_clk.common,
> > &r_apb2_rsb_clk.common,
> > &r_apb1_ir_clk.common,
> > + &r_apb1_rtc_clk.common,
> > &ir_clk.common,
> > };
> >
> > @@ -163,6 +166,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks
= {
> > [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> > [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> > [CLK_R_APB1_IR] =
&r_apb1_ir_clk.common.hw,
> > + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> > [CLK_R_APB1_W1] =
&r_apb1_w1_clk.common.hw,
>
> The new clock should go after CLK_R_APB1_W1 to match the ordering above.
>
> > [CLK_IR] = &ir_clk.common.hw,
> > [CLK_W1] = &w1_clk.common.hw,
> > @@ -179,6 +183,7 @@ static struct clk_hw_onecell_data
sun50i_h616_r_hw_clks = {
> > [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> > [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> > [CLK_R_APB1_IR] =
&r_apb1_ir_clk.common.hw,
> > + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> > [CLK_IR] = &ir_clk.common.hw,
> > },
> > .num = CLK_NUMBER,
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.h
> > index 7e290b840803..10e9b66afc6a 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> > @@ -14,6 +14,6 @@
> >
> > #define CLK_R_APB2 3
> >
> > -#define CLK_NUMBER (CLK_R_APB2_RSB + 1)
> > +#define CLK_NUMBER (CLK_R_APB1_RTC + 1)
> >
> > #endif /* _CCU_SUN50I_H6_R_H */
> > diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-
bindings/clock/sun50i-h6-r-ccu.h
> > index 890368d252c4..a96087abc86f 100644
> > --- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> > +++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> > @@ -22,5 +22,6 @@
> > #define CLK_W1 12
> >
> > #define CLK_R_APB2_RSB 13
> > +#define CLK_R_APB1_RTC 14
> >
> > #endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
> >
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock
@ 2022-05-06 16:10 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-06 16:10 UTC (permalink / raw)
To: Andre Przywara, Chen-Yu Tsai, Samuel Holland
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
Dne torek, 03. maj 2022 ob 04:06:59 CEST je Samuel Holland napisal(a):
> On 4/28/22 6:09 PM, Andre Przywara wrote:
> > The H6 and H616 feature an (undocumented) bus clock gate for accessing
> > the RTC registers. This seems to be enabled at reset (or by the BootROM),
> > so we got away without it so far, but exists regardless.
> > Since the new RTC clock binding for the H616 requires this "bus" clock
> > to be specified in the DT, add this to R_CCU clock driver and expose it
> > on the DT side with a new number.
> > We do this for both the H6 and H616, but mark it as IGNORE_UNUSED, as we
> > cannot reference it in any H6 DTs.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> Reviewed-by: Samuel Holland <samuel@sholland.org>
>
> One tiny nit below, if you resend.
Fixed and applied to sunxi/clk-for-5.19, thanks!
Best regards,
Jernej
>
> > ---
> > drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 5 +++++
> > drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 2 +-
> > include/dt-bindings/clock/sun50i-h6-r-ccu.h | 1 +
> > 3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.c
> > index 712e103382d8..88509339031e 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
> > @@ -98,6 +98,8 @@ static SUNXI_CCU_GATE(r_apb1_ir_clk, "r-apb1-ir",
"r-apb1",
> > 0x1cc, BIT(0), 0);
> > static SUNXI_CCU_GATE(r_apb1_w1_clk, "r-apb1-w1", "r-apb1",
> > 0x1ec, BIT(0), 0);
> > +static SUNXI_CCU_GATE(r_apb1_rtc_clk, "r-apb1-rtc", "r-apb1",
> > + 0x20c, BIT(0), CLK_IGNORE_UNUSED);
> >
> > /* Information of IR(RX) mod clock is gathered from BSP source code */
> > static const char * const r_mod0_default_parents[] = { "osc32k", "osc24M"
};
> > @@ -147,6 +149,7 @@ static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
> > &r_apb2_i2c_clk.common,
> > &r_apb2_rsb_clk.common,
> > &r_apb1_ir_clk.common,
> > + &r_apb1_rtc_clk.common,
> > &ir_clk.common,
> > };
> >
> > @@ -163,6 +166,7 @@ static struct clk_hw_onecell_data sun50i_h6_r_hw_clks
= {
> > [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> > [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> > [CLK_R_APB1_IR] =
&r_apb1_ir_clk.common.hw,
> > + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> > [CLK_R_APB1_W1] =
&r_apb1_w1_clk.common.hw,
>
> The new clock should go after CLK_R_APB1_W1 to match the ordering above.
>
> > [CLK_IR] = &ir_clk.common.hw,
> > [CLK_W1] = &w1_clk.common.hw,
> > @@ -179,6 +183,7 @@ static struct clk_hw_onecell_data
sun50i_h616_r_hw_clks = {
> > [CLK_R_APB2_I2C] = &r_apb2_i2c_clk.common.hw,
> > [CLK_R_APB2_RSB] = &r_apb2_rsb_clk.common.hw,
> > [CLK_R_APB1_IR] =
&r_apb1_ir_clk.common.hw,
> > + [CLK_R_APB1_RTC] = &r_apb1_rtc_clk.common.hw,
> > [CLK_IR] = &ir_clk.common.hw,
> > },
> > .num = CLK_NUMBER,
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h b/drivers/clk/sunxi-ng/
ccu-sun50i-h6-r.h
> > index 7e290b840803..10e9b66afc6a 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
> > @@ -14,6 +14,6 @@
> >
> > #define CLK_R_APB2 3
> >
> > -#define CLK_NUMBER (CLK_R_APB2_RSB + 1)
> > +#define CLK_NUMBER (CLK_R_APB1_RTC + 1)
> >
> > #endif /* _CCU_SUN50I_H6_R_H */
> > diff --git a/include/dt-bindings/clock/sun50i-h6-r-ccu.h b/include/dt-
bindings/clock/sun50i-h6-r-ccu.h
> > index 890368d252c4..a96087abc86f 100644
> > --- a/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> > +++ b/include/dt-bindings/clock/sun50i-h6-r-ccu.h
> > @@ -22,5 +22,6 @@
> > #define CLK_W1 12
> >
> > #define CLK_R_APB2_RSB 13
> > +#define CLK_R_APB1_RTC 14
> >
> > #endif /* _DT_BINDINGS_CLK_SUN50I_H6_R_CCU_H_ */
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 2/6] clk: sunxi-ng: h616: Add PLL derived 32KHz clock
2022-04-28 23:09 ` Andre Przywara
@ 2022-05-06 16:11 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-06 16:11 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
Dne petek, 29. april 2022 ob 01:09:29 CEST je Andre Przywara napisal(a):
> The RTC section of the H616 manual mentions in a half-sentence the
> existence of a clock "32K divided by PLL_PERI(2X)". This is used as
> one of the possible inputs for the mux that selects the clock for the
> 32 KHz fanout pad. On the H616 this is routed to pin PG10, and some
> boards use that clock output to compensate for a missing 32KHz crystal.
> On the OrangePi Zero2 this is for instance connected to the LPO pin of
> the WiFi/BT chip.
> The new RTC clock binding requires this clock to be named as one input
> clock, so we need to expose this to the DT. In contrast to the D1 SoC
> there does not seem to be a gate for this clock, so just use a fixed
> divider clock, using a newly assigned clock number.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Samuel Holland <samuel@sholland.org>
Applied to sunxi/clk-for-5.19, thanks!
Best regards,
Jernej
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 8 ++++++++
> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 2 +-
> include/dt-bindings/clock/sun50i-h616-ccu.h | 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h616.c
> index 49a2474cf314..21e918582aa5 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> @@ -704,6 +704,13 @@ static CLK_FIXED_FACTOR_HWS(pll_periph0_2x_clk, "pll-
periph0-2x",
> pll_periph0_parents,
> 1, 2, 0);
>
> +static const struct clk_hw *pll_periph0_2x_hws[] = {
> + &pll_periph0_2x_clk.hw
> +};
> +
> +static CLK_FIXED_FACTOR_HWS(pll_system_32k_clk, "pll-system-32k",
> + pll_periph0_2x_hws, 36621, 1, 0);
> +
> static const struct clk_hw *pll_periph1_parents[] = {
> &pll_periph1_clk.common.hw
> };
> @@ -852,6 +859,7 @@ static struct clk_hw_onecell_data sun50i_h616_hw_clks =
{
> [CLK_PLL_DDR1] =
&pll_ddr1_clk.common.hw,
> [CLK_PLL_PERIPH0] = &pll_periph0_clk.common.hw,
> [CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.hw,
> + [CLK_PLL_SYSTEM_32K] = &pll_system_32k_clk.hw,
> [CLK_PLL_PERIPH1] = &pll_periph1_clk.common.hw,
> [CLK_PLL_PERIPH1_2X] = &pll_periph1_2x_clk.hw,
> [CLK_PLL_GPU] =
&pll_gpu_clk.common.hw,
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h b/drivers/clk/sunxi-ng/
ccu-sun50i-h616.h
> index dd671b413f22..fdd2f4d5103f 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> @@ -51,6 +51,6 @@
>
> #define CLK_BUS_DRAM 56
>
> -#define CLK_NUMBER (CLK_BUS_HDCP + 1)
> +#define CLK_NUMBER (CLK_PLL_SYSTEM_32K + 1)
>
> #endif /* _CCU_SUN50I_H616_H_ */
> diff --git a/include/dt-bindings/clock/sun50i-h616-ccu.h b/include/dt-
bindings/clock/sun50i-h616-ccu.h
> index 4fc08b0df2f3..1191aca53ac6 100644
> --- a/include/dt-bindings/clock/sun50i-h616-ccu.h
> +++ b/include/dt-bindings/clock/sun50i-h616-ccu.h
> @@ -111,5 +111,6 @@
> #define CLK_BUS_TVE0 125
> #define CLK_HDCP 126
> #define CLK_BUS_HDCP 127
> +#define CLK_PLL_SYSTEM_32K 128
>
> #endif /* _DT_BINDINGS_CLK_SUN50I_H616_H_ */
> --
> 2.35.3
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 2/6] clk: sunxi-ng: h616: Add PLL derived 32KHz clock
@ 2022-05-06 16:11 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-05-06 16:11 UTC (permalink / raw)
To: Samuel Holland, Chen-Yu Tsai, Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel,
Stephen Boyd, Michael Turquette, linux-clk
Dne petek, 29. april 2022 ob 01:09:29 CEST je Andre Przywara napisal(a):
> The RTC section of the H616 manual mentions in a half-sentence the
> existence of a clock "32K divided by PLL_PERI(2X)". This is used as
> one of the possible inputs for the mux that selects the clock for the
> 32 KHz fanout pad. On the H616 this is routed to pin PG10, and some
> boards use that clock output to compensate for a missing 32KHz crystal.
> On the OrangePi Zero2 this is for instance connected to the LPO pin of
> the WiFi/BT chip.
> The new RTC clock binding requires this clock to be named as one input
> clock, so we need to expose this to the DT. In contrast to the D1 SoC
> there does not seem to be a gate for this clock, so just use a fixed
> divider clock, using a newly assigned clock number.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Samuel Holland <samuel@sholland.org>
Applied to sunxi/clk-for-5.19, thanks!
Best regards,
Jernej
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 8 ++++++++
> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 2 +-
> include/dt-bindings/clock/sun50i-h616-ccu.h | 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c b/drivers/clk/sunxi-ng/
ccu-sun50i-h616.c
> index 49a2474cf314..21e918582aa5 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> @@ -704,6 +704,13 @@ static CLK_FIXED_FACTOR_HWS(pll_periph0_2x_clk, "pll-
periph0-2x",
> pll_periph0_parents,
> 1, 2, 0);
>
> +static const struct clk_hw *pll_periph0_2x_hws[] = {
> + &pll_periph0_2x_clk.hw
> +};
> +
> +static CLK_FIXED_FACTOR_HWS(pll_system_32k_clk, "pll-system-32k",
> + pll_periph0_2x_hws, 36621, 1, 0);
> +
> static const struct clk_hw *pll_periph1_parents[] = {
> &pll_periph1_clk.common.hw
> };
> @@ -852,6 +859,7 @@ static struct clk_hw_onecell_data sun50i_h616_hw_clks =
{
> [CLK_PLL_DDR1] =
&pll_ddr1_clk.common.hw,
> [CLK_PLL_PERIPH0] = &pll_periph0_clk.common.hw,
> [CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.hw,
> + [CLK_PLL_SYSTEM_32K] = &pll_system_32k_clk.hw,
> [CLK_PLL_PERIPH1] = &pll_periph1_clk.common.hw,
> [CLK_PLL_PERIPH1_2X] = &pll_periph1_2x_clk.hw,
> [CLK_PLL_GPU] =
&pll_gpu_clk.common.hw,
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h b/drivers/clk/sunxi-ng/
ccu-sun50i-h616.h
> index dd671b413f22..fdd2f4d5103f 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> @@ -51,6 +51,6 @@
>
> #define CLK_BUS_DRAM 56
>
> -#define CLK_NUMBER (CLK_BUS_HDCP + 1)
> +#define CLK_NUMBER (CLK_PLL_SYSTEM_32K + 1)
>
> #endif /* _CCU_SUN50I_H616_H_ */
> diff --git a/include/dt-bindings/clock/sun50i-h616-ccu.h b/include/dt-
bindings/clock/sun50i-h616-ccu.h
> index 4fc08b0df2f3..1191aca53ac6 100644
> --- a/include/dt-bindings/clock/sun50i-h616-ccu.h
> +++ b/include/dt-bindings/clock/sun50i-h616-ccu.h
> @@ -111,5 +111,6 @@
> #define CLK_BUS_TVE0 125
> #define CLK_HDCP 126
> #define CLK_BUS_HDCP 127
> +#define CLK_PLL_SYSTEM_32K 128
>
> #endif /* _DT_BINDINGS_CLK_SUN50I_H616_H_ */
> --
> 2.35.3
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-05-03 19:05 ` Jernej Škrabec
@ 2022-06-30 0:04 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-06-30 0:04 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Tue, 03 May 2022 21:05:11 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
many thanks for taking the time to wade through this file!
> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> >
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > 1 file changed, 574 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
> boot/dts/allwinner/sun50i-h616.dtsi
> > new file mode 100644
> > index 000000000000..cc06cdd15ba5
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -0,0 +1,574 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Arm Ltd.
> > +// based on the H6 dtsi, which is:
> > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > +
> > +/ {
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <0>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <1>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <2>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <3>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > + secmon_reserved: secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x80000>;
> > + no-map;
> > + };
> > + };
>
> I'm not a fan of above. If anything changes in future in BL31, U-Boot would
> need to reconfigure it anyway. Can we just skip it?
I am not a fan neither, but last time I checked this is needed to boot.
Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
And that's nicely preserved if you use that DT ($fdtcontroladdr) for
the kernel as well.
But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
U-Boot fails to propagate the /reserved-memory node into that copy.
There does not seem to be a global notion of reserved memory in U-Boot.
Some commands (like tftp) explicitly parse the control DT to find and
respect reserved memory regions. bootm does that also, but only to
avoid placing the ramdisk or DTB into reserved memory. The information
ends up in images->lmb, but is not used to generate or amend nodes in
the target DT.
So the bits and pieces are there, but it will require some code to be
added to the generic U-Boot code.
So what do you think? Leaving this out will prevent loading DTBs into
U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
now, it should not really hurt. U-Boot will hopefully start to do the
right thing soon, then we can either phase it out here (maybe when we
actually change something in TF-A), or let U-Boot fix it.
>
> > +
> > + osc24M: osc24M-clk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <24000000>;
> > + clock-output-names = "osc24M";
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + arm,no-tick-in-suspend;
> > + interrupts = <GIC_PPI 13
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 14
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 11
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>;
> > + };
>
> Vendor kernel sets IRQ to low level. What is the difference?
Nothing, really. The polarity of SPI level IRQ lines is hardwired at
integration time, both at the peripheral and the GIC distributor. The
GIC software interface has no register to control that - all you can
configure is edge or level. There *is* some underlying polarity, but to
my understanding this is just mentioned here for completeness, and
because the binding requires to name one.
>
> > +
> > + soc@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x0 0x0 0x40000000>;
> > +
> > + syscon: syscon@3000000 {
> > + compatible = "allwinner,sun50i-h616-system-
> control";
> > + reg = <0x03000000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + sram_c: sram@28000 {
> > + compatible = "mmio-sram";
> > + reg = <0x00028000 0x30000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x00028000 0x30000>;
> > + };
> > + };
> > +
> > + ccu: clock@3001000 {
> > + compatible = "allwinner,sun50i-h616-ccu";
> > + reg = <0x03001000 0x1000>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> > + clock-names = "hosc", "losc", "iosc";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + watchdog: watchdog@30090a0 {
> > + compatible = "allwinner,sun50i-h616-wdt",
> > + "allwinner,sun6i-a31-wdt";
> > + reg = <0x030090a0 0x20>;
> > + interrupts = <GIC_SPI 50
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > + pio: pinctrl@300b000 {
> > + compatible = "allwinner,sun50i-h616-pinctrl";
> > + reg = <0x0300b000 0x400>;
> > + interrupts = <GIC_SPI 51
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 52
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 53
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 54
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 55
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 56
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 57
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
> 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + ext_rgmii_pins: rgmii-pins {
> > + pins = "PI0", "PI1", "PI2", "PI3",
> "PI4",
> > + "PI5", "PI7", "PI8", "PI9",
> "PI10",
> > + "PI11", "PI12", "PI13",
> "PI14", "PI15",
> > + "PI16";
> > + function = "emac0";
> > + drive-strength = <40>;
> > + };
> > +
> > + i2c0_pins: i2c0-pins {
> > + pins = "PI6", "PI7";
> > + function = "i2c0";
> > + };
> > +
> > + i2c3_ph_pins: i2c3-ph-pins {
> > + pins = "PH4", "PH5";
> > + function = "i2c3";
> > + };
> > +
> > + ir_rx_pin: ir-rx-pin {
> > + pins = "PH10";
> > + function = "ir_rx";
> > + };
> > +
> > + mmc0_pins: mmc0-pins {
> > + pins = "PF0", "PF1", "PF2", "PF3",
> > + "PF4", "PF5";
> > + function = "mmc0";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2", "PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc2_pins: mmc2-pins {
> > + pins = "PC0", "PC1", "PC5", "PC6",
> > + "PC8", "PC9", "PC10",
> "PC11",
> > + "PC13", "PC14", "PC15",
> "PC16";
> > + function = "mmc2";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + spi0_pins: spi0-pins {
> > + pins = "PC0", "PC2", "PC3", "PC4";
> > + function = "spi0";
> > + };
> > +
> > + spi1_pins: spi1-pins {
> > + pins = "PH6", "PH7", "PH8";
> > + function = "spi1";
> > + };
> > +
> > + spi1_cs_pin: spi1-cs-pin {
> > + pins = "PH5";
> > + function = "spi1";
> > + };
> > +
> > + uart0_ph_pins: uart0-ph-pins {
> > + pins = "PH0", "PH1";
> > + function = "uart0";
> > + };
> > +
> > + uart1_pins: uart1-pins {
> > + pins = "PG6", "PG7";
> > + function = "uart1";
> > + };
> > +
> > + uart1_rts_cts_pins: uart1-rts-cts-pins {
> > + pins = "PG8", "PG9";
> > + function = "uart1";
> > + };
>
> Please add /omit-if-no-ref/ where applicable.
OK. I think most boards have Bluetooth at UART1, though.
>
> > + };
> > +
> > + gic: interrupt-controller@3021000 {
> > + compatible = "arm,gic-400";
> > + reg = <0x03021000 0x1000>,
> > + <0x03022000 0x2000>,
> > + <0x03024000 0x2000>,
> > + <0x03026000 0x2000>;
> > + interrupts = <GIC_PPI 9
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + };
> > +
> > + mmc0: mmc@4020000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04020000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> CLK_MMC0>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC0>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 35
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc1: mmc@4021000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04021000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
> CLK_MMC1>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC1>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 36
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc2: mmc@4022000 {
> > + compatible = "allwinner,sun50i-h616-emmc",
> > + "allwinner,sun50i-a100-emmc";
> > + reg = <0x04022000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
> CLK_MMC2>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC2>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 37
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc2_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + uart0: serial@5000000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000000 0x400>;
> > + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART0>;
> > + resets = <&ccu RST_BUS_UART0>;
> > + status = "disabled";
> > + };
> > +
> > + uart1: serial@5000400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000400 0x400>;
> > + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART1>;
> > + resets = <&ccu RST_BUS_UART1>;
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@5000800 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000800 0x400>;
> > + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART2>;
> > + resets = <&ccu RST_BUS_UART2>;
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@5000c00 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000c00 0x400>;
> > + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART3>;
> > + resets = <&ccu RST_BUS_UART3>;
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@5001000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001000 0x400>;
> > + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART4>;
> > + resets = <&ccu RST_BUS_UART4>;
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial@5001400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001400 0x400>;
> > + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART5>;
> > + resets = <&ccu RST_BUS_UART5>;
> > + status = "disabled";
> > + };
> > +
> > + i2c0: i2c@5002000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002000 0x400>;
> > + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C0>;
> > + resets = <&ccu RST_BUS_I2C0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c1: i2c@5002400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002400 0x400>;
> > + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C1>;
> > + resets = <&ccu RST_BUS_I2C1>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c2: i2c@5002800 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002800 0x400>;
> > + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C2>;
> > + resets = <&ccu RST_BUS_I2C2>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c3: i2c@5002c00 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002c00 0x400>;
> > + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C3>;
> > + resets = <&ccu RST_BUS_I2C3>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c4: i2c@5003000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05003000 0x400>;
> > + interrupts = <GIC_SPI 10
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C4>;
> > + resets = <&ccu RST_BUS_I2C4>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi0: spi@5010000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05010000 0x1000>;
> > + interrupts = <GIC_SPI 12
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
> CLK_SPI0>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi1: spi@5011000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05011000 0x1000>;
> > + interrupts = <GIC_SPI 13
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
> CLK_SPI1>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi1_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + emac0: ethernet@5020000 {
> > + compatible = "allwinner,sun50i-h616-emac",
> > + "allwinner,sun50i-a64-emac";
> > + syscon = <&syscon>;
> > + reg = <0x05020000 0x10000>;
> > + interrupts = <GIC_SPI 14
> IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "macirq";
> > + resets = <&ccu RST_BUS_EMAC0>;
> > + reset-names = "stmmaceth";
> > + clocks = <&ccu CLK_BUS_EMAC0>;
> > + clock-names = "stmmaceth";
> > + status = "disabled";
> > +
> > + mdio0: mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +
> > + rtc: rtc@7000000 {
> > + compatible = "allwinner,sun50i-h616-rtc";
> > + reg = <0x07000000 0x400>;
> > + interrupts = <GIC_SPI 101
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt doesn't seem to be correct according to documentation. It
> should be 104.
That is a very good catch, 101/133 is indeed the RTC IRQ number on the
H6.
>
> > + clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
> > + <&ccu CLK_PLL_SYSTEM_32K>;
> > + clock-names = "bus", "hosc",
> > + "pll-32k";
> > + clock-output-names = "osc32k", "osc32k-out",
> "iosc";
> > + #clock-cells = <1>;
> > + };
> > +
> > + r_ccu: clock@7010000 {
> > + compatible = "allwinner,sun50i-h616-r-ccu";
> > + reg = <0x07010000 0x210>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> > + <&ccu CLK_PLL_PERIPH0>;
> > + clock-names = "hosc", "losc", "iosc", "pll-
> periph";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + r_pio: pinctrl@7022000 {
> > + compatible = "allwinner,sun50i-h616-r-
> pinctrl";
> > + reg = <0x07022000 0x400>;
> > + interrupts = <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt is already used for port E in first pinctrl. Is this shared
> somehow?
Huh, another good find. The manual does not seem to mention a GPIO_L
interrupt, and the two PL pins do not report function 6.
when probing the registers in U-Boot there are no other pins (neither in
PortL nor PortM), also the interrupt registers (@+0x200) are not
implemented. So there does not seem to be an interrupt.
The pinctrl driver does not seem to care (by looking at the code,
and by booting it), as .irq_banks is 0, so no IRQ controller
functionality is ever instantiated.
The binding makes the interrupts property mandatory, though, so this
needs to be amended there.
I will try to post a new version till the end of the week.
Thanks!
Andre
>
> Best regards,
> Jernej
>
> > + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
> <&rtc 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + r_i2c_pins: r-i2c-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_i2c";
> > + };
> > +
> > + r_rsb_pins: r-rsb-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_rsb";
> > + };
> > + };
> > +
> > + ir: ir@7040000 {
> > + compatible = "allwinner,sun50i-h616-ir",
> > + "allwinner,sun6i-a31-ir";
> > + reg = <0x07040000 0x400>;
> > + interrupts = <GIC_SPI 106
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB1_IR>,
> > + <&r_ccu CLK_IR>;
> > + clock-names = "apb", "ir";
> > + resets = <&r_ccu RST_R_APB1_IR>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ir_rx_pin>;
> > + status = "disabled";
> > + };
> > +
> > + r_i2c: i2c@7081400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x07081400 0x400>;
> > + interrupts = <GIC_SPI 105
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_I2C>;
> > + resets = <&r_ccu RST_R_APB2_I2C>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + r_rsb: rsb@7083000 {
> > + compatible = "allwinner,sun50i-h616-rsb",
> > + "allwinner,sun8i-a23-rsb";
> > + reg = <0x07083000 0x400>;
> > + interrupts = <GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_RSB>;
> > + clock-frequency = <3000000>;
> > + resets = <&r_ccu RST_R_APB2_RSB>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&r_rsb_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +};
> > --
> > 2.35.3
> >
> >
>
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-06-30 0:04 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-06-30 0:04 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Tue, 03 May 2022 21:05:11 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
many thanks for taking the time to wade through this file!
> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > PCIe support and the USB 3.0 controller. It also gets the management
> > controller removed, which in turn removes *some*, but not all of the
> > devices formerly dedicated to the ARISC (CPUS).
> > And while there is still the extra sunxi interrupt controller, the
> > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> >
> > The reserved memory node is actually handled by Trusted Firmware now,
> > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > keep it in here for now, until U-Boot learns to do this properly.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > 1 file changed, 574 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/
> boot/dts/allwinner/sun50i-h616.dtsi
> > new file mode 100644
> > index 000000000000..cc06cdd15ba5
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > @@ -0,0 +1,574 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +// Copyright (C) 2020 Arm Ltd.
> > +// based on the H6 dtsi, which is:
> > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > +
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > +
> > +/ {
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <0>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu1: cpu@1 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <1>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu2: cpu@2 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <2>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > +
> > + cpu3: cpu@3 {
> > + compatible = "arm,cortex-a53";
> > + device_type = "cpu";
> > + reg = <3>;
> > + enable-method = "psci";
> > + clocks = <&ccu CLK_CPUX>;
> > + };
> > + };
> > +
> > + reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > + secmon_reserved: secmon@40000000 {
> > + reg = <0x0 0x40000000 0x0 0x80000>;
> > + no-map;
> > + };
> > + };
>
> I'm not a fan of above. If anything changes in future in BL31, U-Boot would
> need to reconfigure it anyway. Can we just skip it?
I am not a fan neither, but last time I checked this is needed to boot.
Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
And that's nicely preserved if you use that DT ($fdtcontroladdr) for
the kernel as well.
But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
U-Boot fails to propagate the /reserved-memory node into that copy.
There does not seem to be a global notion of reserved memory in U-Boot.
Some commands (like tftp) explicitly parse the control DT to find and
respect reserved memory regions. bootm does that also, but only to
avoid placing the ramdisk or DTB into reserved memory. The information
ends up in images->lmb, but is not used to generate or amend nodes in
the target DT.
So the bits and pieces are there, but it will require some code to be
added to the generic U-Boot code.
So what do you think? Leaving this out will prevent loading DTBs into
U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
now, it should not really hurt. U-Boot will hopefully start to do the
right thing soon, then we can either phase it out here (maybe when we
actually change something in TF-A), or let U-Boot fix it.
>
> > +
> > + osc24M: osc24M-clk {
> > + #clock-cells = <0>;
> > + compatible = "fixed-clock";
> > + clock-frequency = <24000000>;
> > + clock-output-names = "osc24M";
> > + };
> > +
> > + pmu {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > + };
> > +
> > + psci {
> > + compatible = "arm,psci-0.2";
> > + method = "smc";
> > + };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + arm,no-tick-in-suspend;
> > + interrupts = <GIC_PPI 13
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 14
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 11
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> > + <GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>;
> > + };
>
> Vendor kernel sets IRQ to low level. What is the difference?
Nothing, really. The polarity of SPI level IRQ lines is hardwired at
integration time, both at the peripheral and the GIC distributor. The
GIC software interface has no register to control that - all you can
configure is edge or level. There *is* some underlying polarity, but to
my understanding this is just mentioned here for completeness, and
because the binding requires to name one.
>
> > +
> > + soc@0 {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0x0 0x0 0x0 0x40000000>;
> > +
> > + syscon: syscon@3000000 {
> > + compatible = "allwinner,sun50i-h616-system-
> control";
> > + reg = <0x03000000 0x1000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + sram_c: sram@28000 {
> > + compatible = "mmio-sram";
> > + reg = <0x00028000 0x30000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x00028000 0x30000>;
> > + };
> > + };
> > +
> > + ccu: clock@3001000 {
> > + compatible = "allwinner,sun50i-h616-ccu";
> > + reg = <0x03001000 0x1000>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> > + clock-names = "hosc", "losc", "iosc";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + watchdog: watchdog@30090a0 {
> > + compatible = "allwinner,sun50i-h616-wdt",
> > + "allwinner,sun6i-a31-wdt";
> > + reg = <0x030090a0 0x20>;
> > + interrupts = <GIC_SPI 50
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&osc24M>;
> > + };
> > +
> > + pio: pinctrl@300b000 {
> > + compatible = "allwinner,sun50i-h616-pinctrl";
> > + reg = <0x0300b000 0x400>;
> > + interrupts = <GIC_SPI 51
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 52
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 53
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 54
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 55
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 56
> IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 57
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
> 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + ext_rgmii_pins: rgmii-pins {
> > + pins = "PI0", "PI1", "PI2", "PI3",
> "PI4",
> > + "PI5", "PI7", "PI8", "PI9",
> "PI10",
> > + "PI11", "PI12", "PI13",
> "PI14", "PI15",
> > + "PI16";
> > + function = "emac0";
> > + drive-strength = <40>;
> > + };
> > +
> > + i2c0_pins: i2c0-pins {
> > + pins = "PI6", "PI7";
> > + function = "i2c0";
> > + };
> > +
> > + i2c3_ph_pins: i2c3-ph-pins {
> > + pins = "PH4", "PH5";
> > + function = "i2c3";
> > + };
> > +
> > + ir_rx_pin: ir-rx-pin {
> > + pins = "PH10";
> > + function = "ir_rx";
> > + };
> > +
> > + mmc0_pins: mmc0-pins {
> > + pins = "PF0", "PF1", "PF2", "PF3",
> > + "PF4", "PF5";
> > + function = "mmc0";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc1_pins: mmc1-pins {
> > + pins = "PG0", "PG1", "PG2", "PG3",
> > + "PG4", "PG5";
> > + function = "mmc1";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + mmc2_pins: mmc2-pins {
> > + pins = "PC0", "PC1", "PC5", "PC6",
> > + "PC8", "PC9", "PC10",
> "PC11",
> > + "PC13", "PC14", "PC15",
> "PC16";
> > + function = "mmc2";
> > + drive-strength = <30>;
> > + bias-pull-up;
> > + };
> > +
> > + spi0_pins: spi0-pins {
> > + pins = "PC0", "PC2", "PC3", "PC4";
> > + function = "spi0";
> > + };
> > +
> > + spi1_pins: spi1-pins {
> > + pins = "PH6", "PH7", "PH8";
> > + function = "spi1";
> > + };
> > +
> > + spi1_cs_pin: spi1-cs-pin {
> > + pins = "PH5";
> > + function = "spi1";
> > + };
> > +
> > + uart0_ph_pins: uart0-ph-pins {
> > + pins = "PH0", "PH1";
> > + function = "uart0";
> > + };
> > +
> > + uart1_pins: uart1-pins {
> > + pins = "PG6", "PG7";
> > + function = "uart1";
> > + };
> > +
> > + uart1_rts_cts_pins: uart1-rts-cts-pins {
> > + pins = "PG8", "PG9";
> > + function = "uart1";
> > + };
>
> Please add /omit-if-no-ref/ where applicable.
OK. I think most boards have Bluetooth at UART1, though.
>
> > + };
> > +
> > + gic: interrupt-controller@3021000 {
> > + compatible = "arm,gic-400";
> > + reg = <0x03021000 0x1000>,
> > + <0x03022000 0x2000>,
> > + <0x03024000 0x2000>,
> > + <0x03026000 0x2000>;
> > + interrupts = <GIC_PPI 9
> (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > + };
> > +
> > + mmc0: mmc@4020000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04020000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> CLK_MMC0>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC0>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 35
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc0_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc1: mmc@4021000 {
> > + compatible = "allwinner,sun50i-h616-mmc",
> > + "allwinner,sun50i-a100-mmc";
> > + reg = <0x04021000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
> CLK_MMC1>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC1>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 36
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc1_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + mmc2: mmc@4022000 {
> > + compatible = "allwinner,sun50i-h616-emmc",
> > + "allwinner,sun50i-a100-emmc";
> > + reg = <0x04022000 0x1000>;
> > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
> CLK_MMC2>;
> > + clock-names = "ahb", "mmc";
> > + resets = <&ccu RST_BUS_MMC2>;
> > + reset-names = "ahb";
> > + interrupts = <GIC_SPI 37
> IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&mmc2_pins>;
> > + status = "disabled";
> > + max-frequency = <150000000>;
> > + cap-sd-highspeed;
> > + cap-mmc-highspeed;
> > + mmc-ddr-3_3v;
> > + cap-sdio-irq;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + uart0: serial@5000000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000000 0x400>;
> > + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART0>;
> > + resets = <&ccu RST_BUS_UART0>;
> > + status = "disabled";
> > + };
> > +
> > + uart1: serial@5000400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000400 0x400>;
> > + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART1>;
> > + resets = <&ccu RST_BUS_UART1>;
> > + status = "disabled";
> > + };
> > +
> > + uart2: serial@5000800 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000800 0x400>;
> > + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART2>;
> > + resets = <&ccu RST_BUS_UART2>;
> > + status = "disabled";
> > + };
> > +
> > + uart3: serial@5000c00 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05000c00 0x400>;
> > + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART3>;
> > + resets = <&ccu RST_BUS_UART3>;
> > + status = "disabled";
> > + };
> > +
> > + uart4: serial@5001000 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001000 0x400>;
> > + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART4>;
> > + resets = <&ccu RST_BUS_UART4>;
> > + status = "disabled";
> > + };
> > +
> > + uart5: serial@5001400 {
> > + compatible = "snps,dw-apb-uart";
> > + reg = <0x05001400 0x400>;
> > + interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
> > + reg-shift = <2>;
> > + reg-io-width = <4>;
> > + clocks = <&ccu CLK_BUS_UART5>;
> > + resets = <&ccu RST_BUS_UART5>;
> > + status = "disabled";
> > + };
> > +
> > + i2c0: i2c@5002000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002000 0x400>;
> > + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C0>;
> > + resets = <&ccu RST_BUS_I2C0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c1: i2c@5002400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002400 0x400>;
> > + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C1>;
> > + resets = <&ccu RST_BUS_I2C1>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c2: i2c@5002800 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002800 0x400>;
> > + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C2>;
> > + resets = <&ccu RST_BUS_I2C2>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c3: i2c@5002c00 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05002c00 0x400>;
> > + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C3>;
> > + resets = <&ccu RST_BUS_I2C3>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + i2c4: i2c@5003000 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x05003000 0x400>;
> > + interrupts = <GIC_SPI 10
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_I2C4>;
> > + resets = <&ccu RST_BUS_I2C4>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi0: spi@5010000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05010000 0x1000>;
> > + interrupts = <GIC_SPI 12
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
> CLK_SPI0>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI0>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi0_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + spi1: spi@5011000 {
> > + compatible = "allwinner,sun50i-h616-spi",
> > + "allwinner,sun8i-h3-spi";
> > + reg = <0x05011000 0x1000>;
> > + interrupts = <GIC_SPI 13
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
> CLK_SPI1>;
> > + clock-names = "ahb", "mod";
> > + resets = <&ccu RST_BUS_SPI1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&spi1_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + emac0: ethernet@5020000 {
> > + compatible = "allwinner,sun50i-h616-emac",
> > + "allwinner,sun50i-a64-emac";
> > + syscon = <&syscon>;
> > + reg = <0x05020000 0x10000>;
> > + interrupts = <GIC_SPI 14
> IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "macirq";
> > + resets = <&ccu RST_BUS_EMAC0>;
> > + reset-names = "stmmaceth";
> > + clocks = <&ccu CLK_BUS_EMAC0>;
> > + clock-names = "stmmaceth";
> > + status = "disabled";
> > +
> > + mdio0: mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +
> > + rtc: rtc@7000000 {
> > + compatible = "allwinner,sun50i-h616-rtc";
> > + reg = <0x07000000 0x400>;
> > + interrupts = <GIC_SPI 101
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt doesn't seem to be correct according to documentation. It
> should be 104.
That is a very good catch, 101/133 is indeed the RTC IRQ number on the
H6.
>
> > + clocks = <&r_ccu CLK_R_APB1_RTC>, <&osc24M>,
> > + <&ccu CLK_PLL_SYSTEM_32K>;
> > + clock-names = "bus", "hosc",
> > + "pll-32k";
> > + clock-output-names = "osc32k", "osc32k-out",
> "iosc";
> > + #clock-cells = <1>;
> > + };
> > +
> > + r_ccu: clock@7010000 {
> > + compatible = "allwinner,sun50i-h616-r-ccu";
> > + reg = <0x07010000 0x210>;
> > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> > + <&ccu CLK_PLL_PERIPH0>;
> > + clock-names = "hosc", "losc", "iosc", "pll-
> periph";
> > + #clock-cells = <1>;
> > + #reset-cells = <1>;
> > + };
> > +
> > + r_pio: pinctrl@7022000 {
> > + compatible = "allwinner,sun50i-h616-r-
> pinctrl";
> > + reg = <0x07022000 0x400>;
> > + interrupts = <GIC_SPI 43
> IRQ_TYPE_LEVEL_HIGH>;
>
> Above interrupt is already used for port E in first pinctrl. Is this shared
> somehow?
Huh, another good find. The manual does not seem to mention a GPIO_L
interrupt, and the two PL pins do not report function 6.
when probing the registers in U-Boot there are no other pins (neither in
PortL nor PortM), also the interrupt registers (@+0x200) are not
implemented. So there does not seem to be an interrupt.
The pinctrl driver does not seem to care (by looking at the code,
and by booting it), as .irq_banks is 0, so no IRQ controller
functionality is ever instantiated.
The binding makes the interrupts property mandatory, though, so this
needs to be amended there.
I will try to post a new version till the end of the week.
Thanks!
Andre
>
> Best regards,
> Jernej
>
> > + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
> <&rtc 0>;
> > + clock-names = "apb", "hosc", "losc";
> > + gpio-controller;
> > + #gpio-cells = <3>;
> > + interrupt-controller;
> > + #interrupt-cells = <3>;
> > +
> > + r_i2c_pins: r-i2c-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_i2c";
> > + };
> > +
> > + r_rsb_pins: r-rsb-pins {
> > + pins = "PL0", "PL1";
> > + function = "s_rsb";
> > + };
> > + };
> > +
> > + ir: ir@7040000 {
> > + compatible = "allwinner,sun50i-h616-ir",
> > + "allwinner,sun6i-a31-ir";
> > + reg = <0x07040000 0x400>;
> > + interrupts = <GIC_SPI 106
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB1_IR>,
> > + <&r_ccu CLK_IR>;
> > + clock-names = "apb", "ir";
> > + resets = <&r_ccu RST_R_APB1_IR>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ir_rx_pin>;
> > + status = "disabled";
> > + };
> > +
> > + r_i2c: i2c@7081400 {
> > + compatible = "allwinner,sun50i-h616-i2c",
> > + "allwinner,sun6i-a31-i2c";
> > + reg = <0x07081400 0x400>;
> > + interrupts = <GIC_SPI 105
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_I2C>;
> > + resets = <&r_ccu RST_R_APB2_I2C>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > +
> > + r_rsb: rsb@7083000 {
> > + compatible = "allwinner,sun50i-h616-rsb",
> > + "allwinner,sun8i-a23-rsb";
> > + reg = <0x07083000 0x400>;
> > + interrupts = <GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&r_ccu CLK_R_APB2_RSB>;
> > + clock-frequency = <3000000>;
> > + resets = <&r_ccu RST_R_APB2_RSB>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&r_rsb_pins>;
> > + status = "disabled";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + };
> > + };
> > +};
> > --
> > 2.35.3
> >
> >
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
2022-05-03 19:41 ` Jernej Škrabec
@ 2022-06-30 0:08 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-06-30 0:08 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Tue, 03 May 2022 21:41:21 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne petek, 29. april 2022 ob 01:09:32 CEST je Andre Przywara napisal(a):
> > The OrangePi Zero 2 is a development board with the new H616 SoC. It
> > comes with the following features:
> > - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> > - 512MiB/1GiB DDR3 DRAM
> > - AXP305 PMIC
> > - Raspberry-Pi-1 compatible GPIO header
> > - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
> > - 1 USB 2.0 host port
> > - 1 USB 2.0 type C port (power supply + OTG)
> > - MicroSD slot
> > - on-board 2MiB bootable SPI NOR flash
> > - 1Gbps Ethernet port (via RTL8211F PHY)
> > - micro-HDMI port
> > - unsupported Allwinner WiFi/BT chip
> >
> > For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2
>
> Please no external links.
Shame. I understand the reasons behind that, but this source is rather
stable (more so than some LKML archives ;-), and I copied the actual
important information. But well, I guess people have to put it in their
search engine and hope it doesn't drop them to the vendor's website ;-)
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../allwinner/sun50i-h616-orangepi-zero2.dts | 203 ++++++++++++++++++
> > 2 files changed, 204 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
> zero2.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
> allwinner/Makefile
> > index 8fa5c060a4fe..df2214e6d946 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/
> arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > new file mode 100644
> > index 000000000000..ca07cae698ce
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > @@ -0,0 +1,203 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2020 Arm Ltd.
>
> 2022?
Mmh, but why? I wrote this in 2020, and it was published the first time
that year[1]. If the copyright year means anything, by my understanding
it should cover the earliest publication date, to establish the license
conditions over every copy out there.
[1]
https://lore.kernel.org/linux-arm-kernel/20201202135409.13683-8-andre.przywara@arm.com/
>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/leds/common.h>
> > +
> > +/ {
> > + model = "OrangePi Zero2";
> > + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> > +
> > + aliases {
> > + ethernet0 = &emac0;
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led-0 {
> > + function = LED_FUNCTION_POWER;
> > + color = <LED_COLOR_ID_RED>;
> > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12
> */
> > + default-state = "on";
> > + };
> > +
> > + led-1 {
> > + function = LED_FUNCTION_STATUS;
> > + color = <LED_COLOR_ID_GREEN>;
> > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13
> */
> > + };
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the USB-C socket
> */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > +&emac0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ext_rgmii_pins>;
> > + phy-mode = "rgmii";
> > + phy-handle = <&ext_rgmii_phy>;
> > + phy-supply = <®_dcdce>;
> > + allwinner,rx-delay-ps = <3100>;
> > + allwinner,tx-delay-ps = <700>;
> > + status = "okay";
> > +};
> > +
> > +&mdio0 {
> > + ext_rgmii_phy: ethernet-phy@1 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + vmmc-supply = <®_dcdce>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&r_rsb {
> > + status = "okay";
> > +
> > + axp305: pmic@745 {
> > + compatible = "x-powers,axp305", "x-powers,axp805",
> > + "x-powers,axp806";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + reg = <0x745>;
> > +
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-supply = <®_vcc5v>;
> > + aldoin-supply = <®_vcc5v>;
> > + bldoin-supply = <®_vcc5v>;
> > + cldoin-supply = <®_vcc5v>;
> > +
> > + regulators {
> > + reg_aldo1: aldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc-sys";
> > + };
> > +
> > + reg_aldo2: aldo2 { /* 3.3V on headers
> */
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc3v3-ext";
> > + };
> > +
> > + reg_aldo3: aldo3 { /* 3.3V on headers
> */
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc3v3-ext2";
> > + };
> > +
> > + reg_bldo1: bldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <1800000>;
> > + regulator-max-microvolt =
> <1800000>;
> > + regulator-name = "vcc1v8";
> > + };
> > +
> > + bldo2 {
> > + /* unused */
> > + };
> > +
> > + bldo3 {
> > + /* unused */
> > + };
> > +
> > + bldo4 {
> > + /* unused */
> > + };
> > +
> > + cldo1 {
> > + /* reserved */
> > + };
> > +
> > + cldo2 {
> > + /* unused */
> > + };
> > +
> > + cldo3 {
> > + /* unused */
> > + };
> > +
> > + reg_dcdca: dcdca {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <810000>;
> > + regulator-max-microvolt =
> <1080000>;
> > + regulator-name = "vdd-cpu";
> > + };
> > +
> > + reg_dcdcc: dcdcc {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <810000>;
> > + regulator-max-microvolt =
> <1080000>;
> > + regulator-name = "vdd-gpu-sys";
> > + };
> > +
> > + reg_dcdcd: dcdcd {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <1500000>;
> > + regulator-max-microvolt =
> <1500000>;
> > + regulator-name = "vdd-dram";
> > + };
> > +
> > + reg_dcdce: dcdce {
> > + regulator-boot-on;
>
> As discussed in the past, this will cause reboot issues because Linux will
> turn down above regulator and thus SD card will stop working. This should be
> always on.
>
> And please add pio regulators, this is something we always add later...
Sure, thanks for the heads up, will do.
Cheers,
Andre
>
> Best regards,
> Jernej
>
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc-eth-mmc";
> > + };
> > +
> > + sw {
> > + /* unused */
> > + };
> > + };
> > + };
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +
> > + flash@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "jedec,spi-nor";
> > + reg = <0>;
> > + spi-max-frequency = <40000000>;
> > + };
> > +};
> > +
> > +&uart0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart0_ph_pins>;
> > + status = "okay";
> > +};
> > --
> > 2.35.3
> >
> >
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
@ 2022-06-30 0:08 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-06-30 0:08 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Tue, 03 May 2022 21:41:21 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne petek, 29. april 2022 ob 01:09:32 CEST je Andre Przywara napisal(a):
> > The OrangePi Zero 2 is a development board with the new H616 SoC. It
> > comes with the following features:
> > - Four ARM Cortex-A53 cores, Mali-G31 MP2 GPU
> > - 512MiB/1GiB DDR3 DRAM
> > - AXP305 PMIC
> > - Raspberry-Pi-1 compatible GPIO header
> > - extra 13 pin expansion header, exposing pins for 2x USB 2.0 ports
> > - 1 USB 2.0 host port
> > - 1 USB 2.0 type C port (power supply + OTG)
> > - MicroSD slot
> > - on-board 2MiB bootable SPI NOR flash
> > - 1Gbps Ethernet port (via RTL8211F PHY)
> > - micro-HDMI port
> > - unsupported Allwinner WiFi/BT chip
> >
> > For more details see: https://linux-sunxi.org/Orange_Pi_Zero_2
>
> Please no external links.
Shame. I understand the reasons behind that, but this source is rather
stable (more so than some LKML archives ;-), and I copied the actual
important information. But well, I guess people have to put it in their
search engine and hope it doesn't drop them to the vendor's website ;-)
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > .../allwinner/sun50i-h616-orangepi-zero2.dts | 203 ++++++++++++++++++
> > 2 files changed, 204 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
> zero2.dts
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/
> allwinner/Makefile
> > index 8fa5c060a4fe..df2214e6d946 100644
> > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > @@ -38,3 +38,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb
> > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts b/
> arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > new file mode 100644
> > index 000000000000..ca07cae698ce
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> > @@ -0,0 +1,203 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > +/*
> > + * Copyright (C) 2020 Arm Ltd.
>
> 2022?
Mmh, but why? I wrote this in 2020, and it was published the first time
that year[1]. If the copyright year means anything, by my understanding
it should cover the earliest publication date, to establish the license
conditions over every copy out there.
[1]
https://lore.kernel.org/linux-arm-kernel/20201202135409.13683-8-andre.przywara@arm.com/
>
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sun50i-h616.dtsi"
> > +
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/leds/common.h>
> > +
> > +/ {
> > + model = "OrangePi Zero2";
> > + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> > +
> > + aliases {
> > + ethernet0 = &emac0;
> > + serial0 = &uart0;
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + led-0 {
> > + function = LED_FUNCTION_POWER;
> > + color = <LED_COLOR_ID_RED>;
> > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12
> */
> > + default-state = "on";
> > + };
> > +
> > + led-1 {
> > + function = LED_FUNCTION_STATUS;
> > + color = <LED_COLOR_ID_GREEN>;
> > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13
> */
> > + };
> > + };
> > +
> > + reg_vcc5v: vcc5v {
> > + /* board wide 5V supply directly from the USB-C socket
> */
> > + compatible = "regulator-fixed";
> > + regulator-name = "vcc-5v";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-always-on;
> > + };
> > +};
> > +
> > +&emac0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ext_rgmii_pins>;
> > + phy-mode = "rgmii";
> > + phy-handle = <&ext_rgmii_phy>;
> > + phy-supply = <®_dcdce>;
> > + allwinner,rx-delay-ps = <3100>;
> > + allwinner,tx-delay-ps = <700>;
> > + status = "okay";
> > +};
> > +
> > +&mdio0 {
> > + ext_rgmii_phy: ethernet-phy@1 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <1>;
> > + };
> > +};
> > +
> > +&mmc0 {
> > + vmmc-supply = <®_dcdce>;
> > + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> > + bus-width = <4>;
> > + status = "okay";
> > +};
> > +
> > +&r_rsb {
> > + status = "okay";
> > +
> > + axp305: pmic@745 {
> > + compatible = "x-powers,axp305", "x-powers,axp805",
> > + "x-powers,axp806";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + reg = <0x745>;
> > +
> > + x-powers,self-working-mode;
> > + vina-supply = <®_vcc5v>;
> > + vinb-supply = <®_vcc5v>;
> > + vinc-supply = <®_vcc5v>;
> > + vind-supply = <®_vcc5v>;
> > + vine-supply = <®_vcc5v>;
> > + aldoin-supply = <®_vcc5v>;
> > + bldoin-supply = <®_vcc5v>;
> > + cldoin-supply = <®_vcc5v>;
> > +
> > + regulators {
> > + reg_aldo1: aldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc-sys";
> > + };
> > +
> > + reg_aldo2: aldo2 { /* 3.3V on headers
> */
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc3v3-ext";
> > + };
> > +
> > + reg_aldo3: aldo3 { /* 3.3V on headers
> */
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc3v3-ext2";
> > + };
> > +
> > + reg_bldo1: bldo1 {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <1800000>;
> > + regulator-max-microvolt =
> <1800000>;
> > + regulator-name = "vcc1v8";
> > + };
> > +
> > + bldo2 {
> > + /* unused */
> > + };
> > +
> > + bldo3 {
> > + /* unused */
> > + };
> > +
> > + bldo4 {
> > + /* unused */
> > + };
> > +
> > + cldo1 {
> > + /* reserved */
> > + };
> > +
> > + cldo2 {
> > + /* unused */
> > + };
> > +
> > + cldo3 {
> > + /* unused */
> > + };
> > +
> > + reg_dcdca: dcdca {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <810000>;
> > + regulator-max-microvolt =
> <1080000>;
> > + regulator-name = "vdd-cpu";
> > + };
> > +
> > + reg_dcdcc: dcdcc {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <810000>;
> > + regulator-max-microvolt =
> <1080000>;
> > + regulator-name = "vdd-gpu-sys";
> > + };
> > +
> > + reg_dcdcd: dcdcd {
> > + regulator-always-on;
> > + regulator-min-microvolt =
> <1500000>;
> > + regulator-max-microvolt =
> <1500000>;
> > + regulator-name = "vdd-dram";
> > + };
> > +
> > + reg_dcdce: dcdce {
> > + regulator-boot-on;
>
> As discussed in the past, this will cause reboot issues because Linux will
> turn down above regulator and thus SD card will stop working. This should be
> always on.
>
> And please add pio regulators, this is something we always add later...
Sure, thanks for the heads up, will do.
Cheers,
Andre
>
> Best regards,
> Jernej
>
> > + regulator-min-microvolt =
> <3300000>;
> > + regulator-max-microvolt =
> <3300000>;
> > + regulator-name = "vcc-eth-mmc";
> > + };
> > +
> > + sw {
> > + /* unused */
> > + };
> > + };
> > + };
> > +};
> > +
> > +&spi0 {
> > + status = "okay";
> > +
> > + flash@0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "jedec,spi-nor";
> > + reg = <0>;
> > + spi-max-frequency = <40000000>;
> > + };
> > +};
> > +
> > +&uart0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart0_ph_pins>;
> > + status = "okay";
> > +};
> > --
> > 2.35.3
> >
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-06-30 0:04 ` Andre Przywara
@ 2022-07-02 21:16 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-02 21:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> On Tue, 03 May 2022 21:05:11 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi Jernej,
>
> many thanks for taking the time to wade through this file!
>
> > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > > PCIe support and the USB 3.0 controller. It also gets the management
> > > controller removed, which in turn removes *some*, but not all of the
> > > devices formerly dedicated to the ARISC (CPUS).
> > > And while there is still the extra sunxi interrupt controller, the
> > > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > >
> > > The reserved memory node is actually handled by Trusted Firmware now,
> > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > keep it in here for now, until U-Boot learns to do this properly.
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > >
> > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > > 1 file changed, 574 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > b/arch/arm64/
> >
> > boot/dts/allwinner/sun50i-h616.dtsi
> >
> > > new file mode 100644
> > > index 000000000000..cc06cdd15ba5
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > @@ -0,0 +1,574 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +// Copyright (C) 2020 Arm Ltd.
> > > +// based on the H6 dtsi, which is:
> > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > +
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > +
> > > +/ {
> > > + interrupt-parent = <&gic>;
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > +
> > > + cpus {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + cpu0: cpu@0 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <0>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > +
> > > + cpu1: cpu@1 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <1>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > +
> > > + cpu2: cpu@2 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <2>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > +
> > > + cpu3: cpu@3 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <3>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > + };
> > > +
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > + secmon_reserved: secmon@40000000 {
> > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > + no-map;
> > > + };
> > > + };
> >
> > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > would
> > need to reconfigure it anyway. Can we just skip it?
>
> I am not a fan neither, but last time I checked this is needed to boot.
> Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> the kernel as well.
> But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> U-Boot fails to propagate the /reserved-memory node into that copy.
> There does not seem to be a global notion of reserved memory in U-Boot.
> Some commands (like tftp) explicitly parse the control DT to find and
> respect reserved memory regions. bootm does that also, but only to
> avoid placing the ramdisk or DTB into reserved memory. The information
> ends up in images->lmb, but is not used to generate or amend nodes in
> the target DT.
> So the bits and pieces are there, but it will require some code to be
> added to the generic U-Boot code.
>
> So what do you think? Leaving this out will prevent loading DTBs into
> U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> now, it should not really hurt. U-Boot will hopefully start to do the
> right thing soon, then we can either phase it out here (maybe when we
> actually change something in TF-A), or let U-Boot fix it.
TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
supports carrying over reserved memory nodes. Whatever we do now, it will have
compatibility issues. If we introduce reserved memory node now, we can't
easily drop it later. Bootloaders are not very often updated, but kernels and
DTB files are, at least in my experience. So when we decide to drop the node?
After 10 years? Alternatively, reserved memory node can be just dropped and
anyone loading DTB file from outside would need to make sure it's patched. But
that's unexpected from user perspective, although patching DT files is done by
some distros.
Best regards,
Jernej
>
> > > +
> > > + osc24M: osc24M-clk {
> > > + #clock-cells = <0>;
> > > + compatible = "fixed-clock";
> > > + clock-frequency = <24000000>;
> > > + clock-output-names = "osc24M";
> > > + };
> > > +
> > > + pmu {
> > > + compatible = "arm,cortex-a53-pmu";
> > > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > > + };
> > > +
> > > + psci {
> > > + compatible = "arm,psci-0.2";
> > > + method = "smc";
> > > + };
> > > +
> > > + timer {
> > > + compatible = "arm,armv8-timer";
> > > + arm,no-tick-in-suspend;
> > > + interrupts = <GIC_PPI 13
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>,
> >
> > > + <GIC_PPI 14
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>,
> >
> > > + <GIC_PPI 11
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>,
> >
> > > + <GIC_PPI 10
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>;
> >
> > > + };
> >
> > Vendor kernel sets IRQ to low level. What is the difference?
>
> Nothing, really. The polarity of SPI level IRQ lines is hardwired at
> integration time, both at the peripheral and the GIC distributor. The
> GIC software interface has no register to control that - all you can
> configure is edge or level. There *is* some underlying polarity, but to
> my understanding this is just mentioned here for completeness, and
> because the binding requires to name one.
>
> > > +
> > > + soc@0 {
> > > + compatible = "simple-bus";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0x0 0x0 0x0 0x40000000>;
> > > +
> > > + syscon: syscon@3000000 {
> > > + compatible = "allwinner,sun50i-h616-system-
> >
> > control";
> >
> > > + reg = <0x03000000 0x1000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > +
> > > + sram_c: sram@28000 {
> > > + compatible = "mmio-sram";
> > > + reg = <0x00028000 0x30000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0 0x00028000 0x30000>;
> > > + };
> > > + };
> > > +
> > > + ccu: clock@3001000 {
> > > + compatible = "allwinner,sun50i-h616-ccu";
> > > + reg = <0x03001000 0x1000>;
> > > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> > > + clock-names = "hosc", "losc", "iosc";
> > > + #clock-cells = <1>;
> > > + #reset-cells = <1>;
> > > + };
> > > +
> > > + watchdog: watchdog@30090a0 {
> > > + compatible = "allwinner,sun50i-h616-wdt",
> > > + "allwinner,sun6i-a31-wdt";
> > > + reg = <0x030090a0 0x20>;
> > > + interrupts = <GIC_SPI 50
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&osc24M>;
> > > + };
> > > +
> > > + pio: pinctrl@300b000 {
> > > + compatible = "allwinner,sun50i-h616-
pinctrl";
> > > + reg = <0x0300b000 0x400>;
> > > + interrupts = <GIC_SPI 51
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 52
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 53
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 43
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 54
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 55
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 56
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 57
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
> >
> > 0>;
> >
> > > + clock-names = "apb", "hosc", "losc";
> > > + gpio-controller;
> > > + #gpio-cells = <3>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > +
> > > + ext_rgmii_pins: rgmii-pins {
> > > + pins = "PI0", "PI1", "PI2",
"PI3",
> >
> > "PI4",
> >
> > > + "PI5", "PI7", "PI8",
"PI9",
> >
> > "PI10",
> >
> > > + "PI11", "PI12", "PI13",
> >
> > "PI14", "PI15",
> >
> > > + "PI16";
> > > + function = "emac0";
> > > + drive-strength = <40>;
> > > + };
> > > +
> > > + i2c0_pins: i2c0-pins {
> > > + pins = "PI6", "PI7";
> > > + function = "i2c0";
> > > + };
> > > +
> > > + i2c3_ph_pins: i2c3-ph-pins {
> > > + pins = "PH4", "PH5";
> > > + function = "i2c3";
> > > + };
> > > +
> > > + ir_rx_pin: ir-rx-pin {
> > > + pins = "PH10";
> > > + function = "ir_rx";
> > > + };
> > > +
> > > + mmc0_pins: mmc0-pins {
> > > + pins = "PF0", "PF1", "PF2",
"PF3",
> > > + "PF4", "PF5";
> > > + function = "mmc0";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + mmc1_pins: mmc1-pins {
> > > + pins = "PG0", "PG1", "PG2",
"PG3",
> > > + "PG4", "PG5";
> > > + function = "mmc1";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + mmc2_pins: mmc2-pins {
> > > + pins = "PC0", "PC1", "PC5",
"PC6",
> > > + "PC8", "PC9", "PC10",
> >
> > "PC11",
> >
> > > + "PC13", "PC14", "PC15",
> >
> > "PC16";
> >
> > > + function = "mmc2";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + spi0_pins: spi0-pins {
> > > + pins = "PC0", "PC2", "PC3",
"PC4";
> > > + function = "spi0";
> > > + };
> > > +
> > > + spi1_pins: spi1-pins {
> > > + pins = "PH6", "PH7", "PH8";
> > > + function = "spi1";
> > > + };
> > > +
> > > + spi1_cs_pin: spi1-cs-pin {
> > > + pins = "PH5";
> > > + function = "spi1";
> > > + };
> > > +
> > > + uart0_ph_pins: uart0-ph-pins {
> > > + pins = "PH0", "PH1";
> > > + function = "uart0";
> > > + };
> > > +
> > > + uart1_pins: uart1-pins {
> > > + pins = "PG6", "PG7";
> > > + function = "uart1";
> > > + };
> > > +
> > > + uart1_rts_cts_pins: uart1-rts-cts-pins {
> > > + pins = "PG8", "PG9";
> > > + function = "uart1";
> > > + };
> >
> > Please add /omit-if-no-ref/ where applicable.
>
> OK. I think most boards have Bluetooth at UART1, though.
>
> > > + };
> > > +
> > > + gic: interrupt-controller@3021000 {
> > > + compatible = "arm,gic-400";
> > > + reg = <0x03021000 0x1000>,
> > > + <0x03022000 0x2000>,
> > > + <0x03024000 0x2000>,
> > > + <0x03026000 0x2000>;
> > > + interrupts = <GIC_PPI 9
> >
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > + };
> > > +
> > > + mmc0: mmc@4020000 {
> > > + compatible = "allwinner,sun50i-h616-mmc",
> > > + "allwinner,sun50i-a100-
mmc";
> > > + reg = <0x04020000 0x1000>;
> > > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> >
> > CLK_MMC0>;
> >
> > > + clock-names = "ahb", "mmc";
> > > + resets = <&ccu RST_BUS_MMC0>;
> > > + reset-names = "ahb";
> > > + interrupts = <GIC_SPI 35
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc0_pins>;
> > > + status = "disabled";
> > > + max-frequency = <150000000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + cap-sdio-irq;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + mmc1: mmc@4021000 {
> > > + compatible = "allwinner,sun50i-h616-mmc",
> > > + "allwinner,sun50i-a100-
mmc";
> > > + reg = <0x04021000 0x1000>;
> > > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
> >
> > CLK_MMC1>;
> >
> > > + clock-names = "ahb", "mmc";
> > > + resets = <&ccu RST_BUS_MMC1>;
> > > + reset-names = "ahb";
> > > + interrupts = <GIC_SPI 36
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc1_pins>;
> > > + status = "disabled";
> > > + max-frequency = <150000000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + cap-sdio-irq;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + mmc2: mmc@4022000 {
> > > + compatible = "allwinner,sun50i-h616-emmc",
> > > + "allwinner,sun50i-a100-
emmc";
> > > + reg = <0x04022000 0x1000>;
> > > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
> >
> > CLK_MMC2>;
> >
> > > + clock-names = "ahb", "mmc";
> > > + resets = <&ccu RST_BUS_MMC2>;
> > > + reset-names = "ahb";
> > > + interrupts = <GIC_SPI 37
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc2_pins>;
> > > + status = "disabled";
> > > + max-frequency = <150000000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + cap-sdio-irq;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + uart0: serial@5000000 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000000 0x400>;
> > > + interrupts = <GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART0>;
> > > + resets = <&ccu RST_BUS_UART0>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart1: serial@5000400 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000400 0x400>;
> > > + interrupts = <GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART1>;
> > > + resets = <&ccu RST_BUS_UART1>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart2: serial@5000800 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000800 0x400>;
> > > + interrupts = <GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART2>;
> > > + resets = <&ccu RST_BUS_UART2>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart3: serial@5000c00 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000c00 0x400>;
> > > + interrupts = <GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART3>;
> > > + resets = <&ccu RST_BUS_UART3>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart4: serial@5001000 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05001000 0x400>;
> > > + interrupts = <GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART4>;
> > > + resets = <&ccu RST_BUS_UART4>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart5: serial@5001400 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05001400 0x400>;
> > > + interrupts = <GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART5>;
> > > + resets = <&ccu RST_BUS_UART5>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + i2c0: i2c@5002000 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002000 0x400>;
> > > + interrupts = <GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C0>;
> > > + resets = <&ccu RST_BUS_I2C0>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&i2c0_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c1: i2c@5002400 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002400 0x400>;
> > > + interrupts = <GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C1>;
> > > + resets = <&ccu RST_BUS_I2C1>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c2: i2c@5002800 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002800 0x400>;
> > > + interrupts = <GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C2>;
> > > + resets = <&ccu RST_BUS_I2C2>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c3: i2c@5002c00 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002c00 0x400>;
> > > + interrupts = <GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C3>;
> > > + resets = <&ccu RST_BUS_I2C3>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c4: i2c@5003000 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05003000 0x400>;
> > > + interrupts = <GIC_SPI 10
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_BUS_I2C4>;
> > > + resets = <&ccu RST_BUS_I2C4>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + spi0: spi@5010000 {
> > > + compatible = "allwinner,sun50i-h616-spi",
> > > + "allwinner,sun8i-h3-spi";
> > > + reg = <0x05010000 0x1000>;
> > > + interrupts = <GIC_SPI 12
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
> >
> > CLK_SPI0>;
> >
> > > + clock-names = "ahb", "mod";
> > > + resets = <&ccu RST_BUS_SPI0>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&spi0_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + spi1: spi@5011000 {
> > > + compatible = "allwinner,sun50i-h616-spi",
> > > + "allwinner,sun8i-h3-spi";
> > > + reg = <0x05011000 0x1000>;
> > > + interrupts = <GIC_SPI 13
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
> >
> > CLK_SPI1>;
> >
> > > + clock-names = "ahb", "mod";
> > > + resets = <&ccu RST_BUS_SPI1>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&spi1_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + emac0: ethernet@5020000 {
> > > + compatible = "allwinner,sun50i-h616-emac",
> > > + "allwinner,sun50i-a64-
emac";
> > > + syscon = <&syscon>;
> > > + reg = <0x05020000 0x10000>;
> > > + interrupts = <GIC_SPI 14
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + interrupt-names = "macirq";
> > > + resets = <&ccu RST_BUS_EMAC0>;
> > > + reset-names = "stmmaceth";
> > > + clocks = <&ccu CLK_BUS_EMAC0>;
> > > + clock-names = "stmmaceth";
> > > + status = "disabled";
> > > +
> > > + mdio0: mdio {
> > > + compatible = "snps,dwmac-mdio";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > + };
> > > +
> > > + rtc: rtc@7000000 {
> > > + compatible = "allwinner,sun50i-h616-rtc";
> > > + reg = <0x07000000 0x400>;
> > > + interrupts = <GIC_SPI 101
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > Above interrupt doesn't seem to be correct according to documentation. It
> > should be 104.
>
> That is a very good catch, 101/133 is indeed the RTC IRQ number on the
> H6.
>
> > > + clocks = <&r_ccu CLK_R_APB1_RTC>,
<&osc24M>,
> > > + <&ccu CLK_PLL_SYSTEM_32K>;
> > > + clock-names = "bus", "hosc",
> > > + "pll-32k";
> > > + clock-output-names = "osc32k", "osc32k-
out",
> >
> > "iosc";
> >
> > > + #clock-cells = <1>;
> > > + };
> > > +
> > > + r_ccu: clock@7010000 {
> > > + compatible = "allwinner,sun50i-h616-r-ccu";
> > > + reg = <0x07010000 0x210>;
> > > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> > > + <&ccu CLK_PLL_PERIPH0>;
> > > + clock-names = "hosc", "losc", "iosc", "pll-
> >
> > periph";
> >
> > > + #clock-cells = <1>;
> > > + #reset-cells = <1>;
> > > + };
> > > +
> > > + r_pio: pinctrl@7022000 {
> > > + compatible = "allwinner,sun50i-h616-r-
> >
> > pinctrl";
> >
> > > + reg = <0x07022000 0x400>;
> > > + interrupts = <GIC_SPI 43
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > Above interrupt is already used for port E in first pinctrl. Is this
> > shared
> > somehow?
>
> Huh, another good find. The manual does not seem to mention a GPIO_L
> interrupt, and the two PL pins do not report function 6.
> when probing the registers in U-Boot there are no other pins (neither in
> PortL nor PortM), also the interrupt registers (@+0x200) are not
> implemented. So there does not seem to be an interrupt.
>
> The pinctrl driver does not seem to care (by looking at the code,
> and by booting it), as .irq_banks is 0, so no IRQ controller
> functionality is ever instantiated.
> The binding makes the interrupts property mandatory, though, so this
> needs to be amended there.
>
>
> I will try to post a new version till the end of the week.
>
> Thanks!
> Andre
>
> > Best regards,
> > Jernej
> >
> > > + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
> >
> > <&rtc 0>;
> >
> > > + clock-names = "apb", "hosc", "losc";
> > > + gpio-controller;
> > > + #gpio-cells = <3>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > +
> > > + r_i2c_pins: r-i2c-pins {
> > > + pins = "PL0", "PL1";
> > > + function = "s_i2c";
> > > + };
> > > +
> > > + r_rsb_pins: r-rsb-pins {
> > > + pins = "PL0", "PL1";
> > > + function = "s_rsb";
> > > + };
> > > + };
> > > +
> > > + ir: ir@7040000 {
> > > + compatible = "allwinner,sun50i-h616-ir",
> > > + "allwinner,sun6i-a31-ir";
> > > + reg = <0x07040000 0x400>;
> > > + interrupts = <GIC_SPI 106
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&r_ccu CLK_R_APB1_IR>,
> > > + <&r_ccu CLK_IR>;
> > > + clock-names = "apb", "ir";
> > > + resets = <&r_ccu RST_R_APB1_IR>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ir_rx_pin>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + r_i2c: i2c@7081400 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x07081400 0x400>;
> > > + interrupts = <GIC_SPI 105
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&r_ccu CLK_R_APB2_I2C>;
> > > + resets = <&r_ccu RST_R_APB2_I2C>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + r_rsb: rsb@7083000 {
> > > + compatible = "allwinner,sun50i-h616-rsb",
> > > + "allwinner,sun8i-a23-rsb";
> > > + reg = <0x07083000 0x400>;
> > > + interrupts = <GIC_SPI 109
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&r_ccu CLK_R_APB2_RSB>;
> > > + clock-frequency = <3000000>;
> > > + resets = <&r_ccu RST_R_APB2_RSB>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&r_rsb_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > + };
> > > +};
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-02 21:16 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-02 21:16 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> On Tue, 03 May 2022 21:05:11 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi Jernej,
>
> many thanks for taking the time to wade through this file!
>
> > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > > PCIe support and the USB 3.0 controller. It also gets the management
> > > controller removed, which in turn removes *some*, but not all of the
> > > devices formerly dedicated to the ARISC (CPUS).
> > > And while there is still the extra sunxi interrupt controller, the
> > > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > >
> > > The reserved memory node is actually handled by Trusted Firmware now,
> > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > keep it in here for now, until U-Boot learns to do this properly.
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > >
> > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > > 1 file changed, 574 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > b/arch/arm64/
> >
> > boot/dts/allwinner/sun50i-h616.dtsi
> >
> > > new file mode 100644
> > > index 000000000000..cc06cdd15ba5
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > @@ -0,0 +1,574 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +// Copyright (C) 2020 Arm Ltd.
> > > +// based on the H6 dtsi, which is:
> > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > +
> > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > +
> > > +/ {
> > > + interrupt-parent = <&gic>;
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > +
> > > + cpus {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + cpu0: cpu@0 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <0>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > +
> > > + cpu1: cpu@1 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <1>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > +
> > > + cpu2: cpu@2 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <2>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > +
> > > + cpu3: cpu@3 {
> > > + compatible = "arm,cortex-a53";
> > > + device_type = "cpu";
> > > + reg = <3>;
> > > + enable-method = "psci";
> > > + clocks = <&ccu CLK_CPUX>;
> > > + };
> > > + };
> > > +
> > > + reserved-memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > +
> > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > + secmon_reserved: secmon@40000000 {
> > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > + no-map;
> > > + };
> > > + };
> >
> > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > would
> > need to reconfigure it anyway. Can we just skip it?
>
> I am not a fan neither, but last time I checked this is needed to boot.
> Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> the kernel as well.
> But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> U-Boot fails to propagate the /reserved-memory node into that copy.
> There does not seem to be a global notion of reserved memory in U-Boot.
> Some commands (like tftp) explicitly parse the control DT to find and
> respect reserved memory regions. bootm does that also, but only to
> avoid placing the ramdisk or DTB into reserved memory. The information
> ends up in images->lmb, but is not used to generate or amend nodes in
> the target DT.
> So the bits and pieces are there, but it will require some code to be
> added to the generic U-Boot code.
>
> So what do you think? Leaving this out will prevent loading DTBs into
> U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> now, it should not really hurt. U-Boot will hopefully start to do the
> right thing soon, then we can either phase it out here (maybe when we
> actually change something in TF-A), or let U-Boot fix it.
TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
supports carrying over reserved memory nodes. Whatever we do now, it will have
compatibility issues. If we introduce reserved memory node now, we can't
easily drop it later. Bootloaders are not very often updated, but kernels and
DTB files are, at least in my experience. So when we decide to drop the node?
After 10 years? Alternatively, reserved memory node can be just dropped and
anyone loading DTB file from outside would need to make sure it's patched. But
that's unexpected from user perspective, although patching DT files is done by
some distros.
Best regards,
Jernej
>
> > > +
> > > + osc24M: osc24M-clk {
> > > + #clock-cells = <0>;
> > > + compatible = "fixed-clock";
> > > + clock-frequency = <24000000>;
> > > + clock-output-names = "osc24M";
> > > + };
> > > +
> > > + pmu {
> > > + compatible = "arm,cortex-a53-pmu";
> > > + interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> > > + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> > > + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
> > > + };
> > > +
> > > + psci {
> > > + compatible = "arm,psci-0.2";
> > > + method = "smc";
> > > + };
> > > +
> > > + timer {
> > > + compatible = "arm,armv8-timer";
> > > + arm,no-tick-in-suspend;
> > > + interrupts = <GIC_PPI 13
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>,
> >
> > > + <GIC_PPI 14
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>,
> >
> > > + <GIC_PPI 11
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>,
> >
> > > + <GIC_PPI 10
> > > + (GIC_CPU_MASK_SIMPLE(4) |
> >
> > IRQ_TYPE_LEVEL_HIGH)>;
> >
> > > + };
> >
> > Vendor kernel sets IRQ to low level. What is the difference?
>
> Nothing, really. The polarity of SPI level IRQ lines is hardwired at
> integration time, both at the peripheral and the GIC distributor. The
> GIC software interface has no register to control that - all you can
> configure is edge or level. There *is* some underlying polarity, but to
> my understanding this is just mentioned here for completeness, and
> because the binding requires to name one.
>
> > > +
> > > + soc@0 {
> > > + compatible = "simple-bus";
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0x0 0x0 0x0 0x40000000>;
> > > +
> > > + syscon: syscon@3000000 {
> > > + compatible = "allwinner,sun50i-h616-system-
> >
> > control";
> >
> > > + reg = <0x03000000 0x1000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges;
> > > +
> > > + sram_c: sram@28000 {
> > > + compatible = "mmio-sram";
> > > + reg = <0x00028000 0x30000>;
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + ranges = <0 0x00028000 0x30000>;
> > > + };
> > > + };
> > > +
> > > + ccu: clock@3001000 {
> > > + compatible = "allwinner,sun50i-h616-ccu";
> > > + reg = <0x03001000 0x1000>;
> > > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
> > > + clock-names = "hosc", "losc", "iosc";
> > > + #clock-cells = <1>;
> > > + #reset-cells = <1>;
> > > + };
> > > +
> > > + watchdog: watchdog@30090a0 {
> > > + compatible = "allwinner,sun50i-h616-wdt",
> > > + "allwinner,sun6i-a31-wdt";
> > > + reg = <0x030090a0 0x20>;
> > > + interrupts = <GIC_SPI 50
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&osc24M>;
> > > + };
> > > +
> > > + pio: pinctrl@300b000 {
> > > + compatible = "allwinner,sun50i-h616-
pinctrl";
> > > + reg = <0x0300b000 0x400>;
> > > + interrupts = <GIC_SPI 51
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 52
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 53
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 43
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 54
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 55
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 56
> >
> > IRQ_TYPE_LEVEL_HIGH>,
> >
> > > + <GIC_SPI 57
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc
> >
> > 0>;
> >
> > > + clock-names = "apb", "hosc", "losc";
> > > + gpio-controller;
> > > + #gpio-cells = <3>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > +
> > > + ext_rgmii_pins: rgmii-pins {
> > > + pins = "PI0", "PI1", "PI2",
"PI3",
> >
> > "PI4",
> >
> > > + "PI5", "PI7", "PI8",
"PI9",
> >
> > "PI10",
> >
> > > + "PI11", "PI12", "PI13",
> >
> > "PI14", "PI15",
> >
> > > + "PI16";
> > > + function = "emac0";
> > > + drive-strength = <40>;
> > > + };
> > > +
> > > + i2c0_pins: i2c0-pins {
> > > + pins = "PI6", "PI7";
> > > + function = "i2c0";
> > > + };
> > > +
> > > + i2c3_ph_pins: i2c3-ph-pins {
> > > + pins = "PH4", "PH5";
> > > + function = "i2c3";
> > > + };
> > > +
> > > + ir_rx_pin: ir-rx-pin {
> > > + pins = "PH10";
> > > + function = "ir_rx";
> > > + };
> > > +
> > > + mmc0_pins: mmc0-pins {
> > > + pins = "PF0", "PF1", "PF2",
"PF3",
> > > + "PF4", "PF5";
> > > + function = "mmc0";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + mmc1_pins: mmc1-pins {
> > > + pins = "PG0", "PG1", "PG2",
"PG3",
> > > + "PG4", "PG5";
> > > + function = "mmc1";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + mmc2_pins: mmc2-pins {
> > > + pins = "PC0", "PC1", "PC5",
"PC6",
> > > + "PC8", "PC9", "PC10",
> >
> > "PC11",
> >
> > > + "PC13", "PC14", "PC15",
> >
> > "PC16";
> >
> > > + function = "mmc2";
> > > + drive-strength = <30>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + spi0_pins: spi0-pins {
> > > + pins = "PC0", "PC2", "PC3",
"PC4";
> > > + function = "spi0";
> > > + };
> > > +
> > > + spi1_pins: spi1-pins {
> > > + pins = "PH6", "PH7", "PH8";
> > > + function = "spi1";
> > > + };
> > > +
> > > + spi1_cs_pin: spi1-cs-pin {
> > > + pins = "PH5";
> > > + function = "spi1";
> > > + };
> > > +
> > > + uart0_ph_pins: uart0-ph-pins {
> > > + pins = "PH0", "PH1";
> > > + function = "uart0";
> > > + };
> > > +
> > > + uart1_pins: uart1-pins {
> > > + pins = "PG6", "PG7";
> > > + function = "uart1";
> > > + };
> > > +
> > > + uart1_rts_cts_pins: uart1-rts-cts-pins {
> > > + pins = "PG8", "PG9";
> > > + function = "uart1";
> > > + };
> >
> > Please add /omit-if-no-ref/ where applicable.
>
> OK. I think most boards have Bluetooth at UART1, though.
>
> > > + };
> > > +
> > > + gic: interrupt-controller@3021000 {
> > > + compatible = "arm,gic-400";
> > > + reg = <0x03021000 0x1000>,
> > > + <0x03022000 0x2000>,
> > > + <0x03024000 0x2000>,
> > > + <0x03026000 0x2000>;
> > > + interrupts = <GIC_PPI 9
> >
> > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> >
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > + };
> > > +
> > > + mmc0: mmc@4020000 {
> > > + compatible = "allwinner,sun50i-h616-mmc",
> > > + "allwinner,sun50i-a100-
mmc";
> > > + reg = <0x04020000 0x1000>;
> > > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
> >
> > CLK_MMC0>;
> >
> > > + clock-names = "ahb", "mmc";
> > > + resets = <&ccu RST_BUS_MMC0>;
> > > + reset-names = "ahb";
> > > + interrupts = <GIC_SPI 35
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc0_pins>;
> > > + status = "disabled";
> > > + max-frequency = <150000000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + cap-sdio-irq;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + mmc1: mmc@4021000 {
> > > + compatible = "allwinner,sun50i-h616-mmc",
> > > + "allwinner,sun50i-a100-
mmc";
> > > + reg = <0x04021000 0x1000>;
> > > + clocks = <&ccu CLK_BUS_MMC1>, <&ccu
> >
> > CLK_MMC1>;
> >
> > > + clock-names = "ahb", "mmc";
> > > + resets = <&ccu RST_BUS_MMC1>;
> > > + reset-names = "ahb";
> > > + interrupts = <GIC_SPI 36
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc1_pins>;
> > > + status = "disabled";
> > > + max-frequency = <150000000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + cap-sdio-irq;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + mmc2: mmc@4022000 {
> > > + compatible = "allwinner,sun50i-h616-emmc",
> > > + "allwinner,sun50i-a100-
emmc";
> > > + reg = <0x04022000 0x1000>;
> > > + clocks = <&ccu CLK_BUS_MMC2>, <&ccu
> >
> > CLK_MMC2>;
> >
> > > + clock-names = "ahb", "mmc";
> > > + resets = <&ccu RST_BUS_MMC2>;
> > > + reset-names = "ahb";
> > > + interrupts = <GIC_SPI 37
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc2_pins>;
> > > + status = "disabled";
> > > + max-frequency = <150000000>;
> > > + cap-sd-highspeed;
> > > + cap-mmc-highspeed;
> > > + mmc-ddr-3_3v;
> > > + cap-sdio-irq;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + uart0: serial@5000000 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000000 0x400>;
> > > + interrupts = <GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART0>;
> > > + resets = <&ccu RST_BUS_UART0>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart1: serial@5000400 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000400 0x400>;
> > > + interrupts = <GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART1>;
> > > + resets = <&ccu RST_BUS_UART1>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart2: serial@5000800 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000800 0x400>;
> > > + interrupts = <GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART2>;
> > > + resets = <&ccu RST_BUS_UART2>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart3: serial@5000c00 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05000c00 0x400>;
> > > + interrupts = <GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART3>;
> > > + resets = <&ccu RST_BUS_UART3>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart4: serial@5001000 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05001000 0x400>;
> > > + interrupts = <GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART4>;
> > > + resets = <&ccu RST_BUS_UART4>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + uart5: serial@5001400 {
> > > + compatible = "snps,dw-apb-uart";
> > > + reg = <0x05001400 0x400>;
> > > + interrupts = <GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>;
> > > + reg-shift = <2>;
> > > + reg-io-width = <4>;
> > > + clocks = <&ccu CLK_BUS_UART5>;
> > > + resets = <&ccu RST_BUS_UART5>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + i2c0: i2c@5002000 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002000 0x400>;
> > > + interrupts = <GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C0>;
> > > + resets = <&ccu RST_BUS_I2C0>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&i2c0_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c1: i2c@5002400 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002400 0x400>;
> > > + interrupts = <GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C1>;
> > > + resets = <&ccu RST_BUS_I2C1>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c2: i2c@5002800 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002800 0x400>;
> > > + interrupts = <GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C2>;
> > > + resets = <&ccu RST_BUS_I2C2>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c3: i2c@5002c00 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05002c00 0x400>;
> > > + interrupts = <GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&ccu CLK_BUS_I2C3>;
> > > + resets = <&ccu RST_BUS_I2C3>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + i2c4: i2c@5003000 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x05003000 0x400>;
> > > + interrupts = <GIC_SPI 10
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_BUS_I2C4>;
> > > + resets = <&ccu RST_BUS_I2C4>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + spi0: spi@5010000 {
> > > + compatible = "allwinner,sun50i-h616-spi",
> > > + "allwinner,sun8i-h3-spi";
> > > + reg = <0x05010000 0x1000>;
> > > + interrupts = <GIC_SPI 12
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_BUS_SPI0>, <&ccu
> >
> > CLK_SPI0>;
> >
> > > + clock-names = "ahb", "mod";
> > > + resets = <&ccu RST_BUS_SPI0>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&spi0_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + spi1: spi@5011000 {
> > > + compatible = "allwinner,sun50i-h616-spi",
> > > + "allwinner,sun8i-h3-spi";
> > > + reg = <0x05011000 0x1000>;
> > > + interrupts = <GIC_SPI 13
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&ccu CLK_BUS_SPI1>, <&ccu
> >
> > CLK_SPI1>;
> >
> > > + clock-names = "ahb", "mod";
> > > + resets = <&ccu RST_BUS_SPI1>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&spi1_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + emac0: ethernet@5020000 {
> > > + compatible = "allwinner,sun50i-h616-emac",
> > > + "allwinner,sun50i-a64-
emac";
> > > + syscon = <&syscon>;
> > > + reg = <0x05020000 0x10000>;
> > > + interrupts = <GIC_SPI 14
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + interrupt-names = "macirq";
> > > + resets = <&ccu RST_BUS_EMAC0>;
> > > + reset-names = "stmmaceth";
> > > + clocks = <&ccu CLK_BUS_EMAC0>;
> > > + clock-names = "stmmaceth";
> > > + status = "disabled";
> > > +
> > > + mdio0: mdio {
> > > + compatible = "snps,dwmac-mdio";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > + };
> > > +
> > > + rtc: rtc@7000000 {
> > > + compatible = "allwinner,sun50i-h616-rtc";
> > > + reg = <0x07000000 0x400>;
> > > + interrupts = <GIC_SPI 101
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > Above interrupt doesn't seem to be correct according to documentation. It
> > should be 104.
>
> That is a very good catch, 101/133 is indeed the RTC IRQ number on the
> H6.
>
> > > + clocks = <&r_ccu CLK_R_APB1_RTC>,
<&osc24M>,
> > > + <&ccu CLK_PLL_SYSTEM_32K>;
> > > + clock-names = "bus", "hosc",
> > > + "pll-32k";
> > > + clock-output-names = "osc32k", "osc32k-
out",
> >
> > "iosc";
> >
> > > + #clock-cells = <1>;
> > > + };
> > > +
> > > + r_ccu: clock@7010000 {
> > > + compatible = "allwinner,sun50i-h616-r-ccu";
> > > + reg = <0x07010000 0x210>;
> > > + clocks = <&osc24M>, <&rtc 0>, <&rtc 2>,
> > > + <&ccu CLK_PLL_PERIPH0>;
> > > + clock-names = "hosc", "losc", "iosc", "pll-
> >
> > periph";
> >
> > > + #clock-cells = <1>;
> > > + #reset-cells = <1>;
> > > + };
> > > +
> > > + r_pio: pinctrl@7022000 {
> > > + compatible = "allwinner,sun50i-h616-r-
> >
> > pinctrl";
> >
> > > + reg = <0x07022000 0x400>;
> > > + interrupts = <GIC_SPI 43
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > Above interrupt is already used for port E in first pinctrl. Is this
> > shared
> > somehow?
>
> Huh, another good find. The manual does not seem to mention a GPIO_L
> interrupt, and the two PL pins do not report function 6.
> when probing the registers in U-Boot there are no other pins (neither in
> PortL nor PortM), also the interrupt registers (@+0x200) are not
> implemented. So there does not seem to be an interrupt.
>
> The pinctrl driver does not seem to care (by looking at the code,
> and by booting it), as .irq_banks is 0, so no IRQ controller
> functionality is ever instantiated.
> The binding makes the interrupts property mandatory, though, so this
> needs to be amended there.
>
>
> I will try to post a new version till the end of the week.
>
> Thanks!
> Andre
>
> > Best regards,
> > Jernej
> >
> > > + clocks = <&r_ccu CLK_R_APB1>, <&osc24M>,
> >
> > <&rtc 0>;
> >
> > > + clock-names = "apb", "hosc", "losc";
> > > + gpio-controller;
> > > + #gpio-cells = <3>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <3>;
> > > +
> > > + r_i2c_pins: r-i2c-pins {
> > > + pins = "PL0", "PL1";
> > > + function = "s_i2c";
> > > + };
> > > +
> > > + r_rsb_pins: r-rsb-pins {
> > > + pins = "PL0", "PL1";
> > > + function = "s_rsb";
> > > + };
> > > + };
> > > +
> > > + ir: ir@7040000 {
> > > + compatible = "allwinner,sun50i-h616-ir",
> > > + "allwinner,sun6i-a31-ir";
> > > + reg = <0x07040000 0x400>;
> > > + interrupts = <GIC_SPI 106
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&r_ccu CLK_R_APB1_IR>,
> > > + <&r_ccu CLK_IR>;
> > > + clock-names = "apb", "ir";
> > > + resets = <&r_ccu RST_R_APB1_IR>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&ir_rx_pin>;
> > > + status = "disabled";
> > > + };
> > > +
> > > + r_i2c: i2c@7081400 {
> > > + compatible = "allwinner,sun50i-h616-i2c",
> > > + "allwinner,sun6i-a31-i2c";
> > > + reg = <0x07081400 0x400>;
> > > + interrupts = <GIC_SPI 105
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&r_ccu CLK_R_APB2_I2C>;
> > > + resets = <&r_ccu RST_R_APB2_I2C>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > +
> > > + r_rsb: rsb@7083000 {
> > > + compatible = "allwinner,sun50i-h616-rsb",
> > > + "allwinner,sun8i-a23-rsb";
> > > + reg = <0x07083000 0x400>;
> > > + interrupts = <GIC_SPI 109
> >
> > IRQ_TYPE_LEVEL_HIGH>;
> >
> > > + clocks = <&r_ccu CLK_R_APB2_RSB>;
> > > + clock-frequency = <3000000>;
> > > + resets = <&r_ccu RST_R_APB2_RSB>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&r_rsb_pins>;
> > > + status = "disabled";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > + };
> > > +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-02 21:16 ` Jernej Škrabec
@ 2022-07-04 13:30 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-04 13:30 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Sat, 02 Jul 2022 23:16:53 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> > On Tue, 03 May 2022 21:05:11 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > many thanks for taking the time to wade through this file!
> >
> > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > > > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > > > PCIe support and the USB 3.0 controller. It also gets the management
> > > > controller removed, which in turn removes *some*, but not all of the
> > > > devices formerly dedicated to the ARISC (CPUS).
> > > > And while there is still the extra sunxi interrupt controller, the
> > > > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > > >
> > > > The reserved memory node is actually handled by Trusted Firmware now,
> > > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > > keep it in here for now, until U-Boot learns to do this properly.
> > > >
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > ---
> > > >
> > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > > > 1 file changed, 574 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > b/arch/arm64/
> > >
> > > boot/dts/allwinner/sun50i-h616.dtsi
> > >
> > > > new file mode 100644
> > > > index 000000000000..cc06cdd15ba5
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > @@ -0,0 +1,574 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > +// Copyright (C) 2020 Arm Ltd.
> > > > +// based on the H6 dtsi, which is:
> > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > +
> > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > +
> > > > +/ {
> > > > + interrupt-parent = <&gic>;
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > +
> > > > + cpus {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + cpu0: cpu@0 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <0>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > +
> > > > + cpu1: cpu@1 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <1>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > +
> > > > + cpu2: cpu@2 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <2>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > +
> > > > + cpu3: cpu@3 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <3>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > + };
> > > > +
> > > > + reserved-memory {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + ranges;
> > > > +
> > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > + secmon_reserved: secmon@40000000 {
> > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > + no-map;
> > > > + };
> > > > + };
> > >
> > > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > > would
> > > need to reconfigure it anyway. Can we just skip it?
> >
> > I am not a fan neither, but last time I checked this is needed to boot.
> > Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > the kernel as well.
> > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > U-Boot fails to propagate the /reserved-memory node into that copy.
> > There does not seem to be a global notion of reserved memory in U-Boot.
> > Some commands (like tftp) explicitly parse the control DT to find and
> > respect reserved memory regions. bootm does that also, but only to
> > avoid placing the ramdisk or DTB into reserved memory. The information
> > ends up in images->lmb, but is not used to generate or amend nodes in
> > the target DT.
> > So the bits and pieces are there, but it will require some code to be
> > added to the generic U-Boot code.
> >
> > So what do you think? Leaving this out will prevent loading DTBs into
> > U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> > now, it should not really hurt. U-Boot will hopefully start to do the
> > right thing soon, then we can either phase it out here (maybe when we
> > actually change something in TF-A), or let U-Boot fix it.
>
> TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
> supports carrying over reserved memory nodes.
But this also carries compatibility issues. U-Boot support the H616 for
more than a year now, and the earliest possible U-Boot release having that
propagation code would be the one released in October. And then people
would still need to update first, so that's quite some months out.
And I was actually hoping to get at least the H616 DT patches off my
plate, and get them into the tree to have a stable and agreed upon base
(before this series turns into a teenager ;-)
Then we could for instance update the U-Boot H616 support.
> Whatever we do now, it will have
> compatibility issues. If we introduce reserved memory node now, we can't
> easily drop it later. Bootloaders are not very often updated, but kernels and
> DTB files are, at least in my experience. So when we decide to drop the node?
I think of the three possibilities:
- Drop the node now, and ask people to not load DTBs explicitly
- Drop the node when U-Boot learned to propagate the reservation
- Keep the node
the last one is the least painful: having this node in does not really
hurt, so we can be very relaxed with this removal decision:
- If U-Boot does not add the reserved node, we are covered.
- If U-Boot adds the node, it will do so in a way where it deals with
existing reservations. So either it doesn't actually change anything, or
it extends the reservation.
- Should the TF-A location actually move (and we have no plans or needs to
do that), people would only get this by updating the firmware, at which
point the U-Boot part would surely be in place already. We don't really
support updating just BL31 in an existing binary firmware image, so you
would get an updated U-Boot as well.
I think the worst case scenario is that users end up with an unneeded 512K
reservation. If they care, a firmware update should solve this problem.
As for the time to remove that node: we could do that at the time when
(or rather: if) we actually change the TF-A reservation. At the moment
there are no plans to do this, and the size reservation is more than
generous (the current debug build is actually 77 KB or so only). If there
is no change, and the node stays in the .dtsi, it doesn't really hurt, see
above.
> After 10 years? Alternatively, reserved memory node can be just dropped and
> anyone loading DTB file from outside would need to make sure it's patched. But
> that's unexpected from user perspective, although patching DT files is done by
> some distros.
Yeah, let's not go there. As you know, I already dislike the idea of
explicitly loading DTBs at all, but I understand this is what people, and
distributions, do, so I'd rather have them covered. Hence the node to
work with existing firmware.
Does that make sense?
Cheers,
Andre
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-04 13:30 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-04 13:30 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Sat, 02 Jul 2022 23:16:53 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> > On Tue, 03 May 2022 21:05:11 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > many thanks for taking the time to wade through this file!
> >
> > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> > > > This (relatively) new SoC is similar to the H6, but drops the (broken)
> > > > PCIe support and the USB 3.0 controller. It also gets the management
> > > > controller removed, which in turn removes *some*, but not all of the
> > > > devices formerly dedicated to the ARISC (CPUS).
> > > > And while there is still the extra sunxi interrupt controller, the
> > > > package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> > > >
> > > > The reserved memory node is actually handled by Trusted Firmware now,
> > > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > > keep it in here for now, until U-Boot learns to do this properly.
> > > >
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > ---
> > > >
> > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> > > > 1 file changed, 574 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > b/arch/arm64/
> > >
> > > boot/dts/allwinner/sun50i-h616.dtsi
> > >
> > > > new file mode 100644
> > > > index 000000000000..cc06cdd15ba5
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > @@ -0,0 +1,574 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > +// Copyright (C) 2020 Arm Ltd.
> > > > +// based on the H6 dtsi, which is:
> > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > +
> > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > +
> > > > +/ {
> > > > + interrupt-parent = <&gic>;
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > +
> > > > + cpus {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + cpu0: cpu@0 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <0>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > +
> > > > + cpu1: cpu@1 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <1>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > +
> > > > + cpu2: cpu@2 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <2>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > +
> > > > + cpu3: cpu@3 {
> > > > + compatible = "arm,cortex-a53";
> > > > + device_type = "cpu";
> > > > + reg = <3>;
> > > > + enable-method = "psci";
> > > > + clocks = <&ccu CLK_CPUX>;
> > > > + };
> > > > + };
> > > > +
> > > > + reserved-memory {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + ranges;
> > > > +
> > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > + secmon_reserved: secmon@40000000 {
> > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > + no-map;
> > > > + };
> > > > + };
> > >
> > > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > > would
> > > need to reconfigure it anyway. Can we just skip it?
> >
> > I am not a fan neither, but last time I checked this is needed to boot.
> > Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > the kernel as well.
> > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > U-Boot fails to propagate the /reserved-memory node into that copy.
> > There does not seem to be a global notion of reserved memory in U-Boot.
> > Some commands (like tftp) explicitly parse the control DT to find and
> > respect reserved memory regions. bootm does that also, but only to
> > avoid placing the ramdisk or DTB into reserved memory. The information
> > ends up in images->lmb, but is not used to generate or amend nodes in
> > the target DT.
> > So the bits and pieces are there, but it will require some code to be
> > added to the generic U-Boot code.
> >
> > So what do you think? Leaving this out will prevent loading DTBs into
> > U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> > now, it should not really hurt. U-Boot will hopefully start to do the
> > right thing soon, then we can either phase it out here (maybe when we
> > actually change something in TF-A), or let U-Boot fix it.
>
> TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
> supports carrying over reserved memory nodes.
But this also carries compatibility issues. U-Boot support the H616 for
more than a year now, and the earliest possible U-Boot release having that
propagation code would be the one released in October. And then people
would still need to update first, so that's quite some months out.
And I was actually hoping to get at least the H616 DT patches off my
plate, and get them into the tree to have a stable and agreed upon base
(before this series turns into a teenager ;-)
Then we could for instance update the U-Boot H616 support.
> Whatever we do now, it will have
> compatibility issues. If we introduce reserved memory node now, we can't
> easily drop it later. Bootloaders are not very often updated, but kernels and
> DTB files are, at least in my experience. So when we decide to drop the node?
I think of the three possibilities:
- Drop the node now, and ask people to not load DTBs explicitly
- Drop the node when U-Boot learned to propagate the reservation
- Keep the node
the last one is the least painful: having this node in does not really
hurt, so we can be very relaxed with this removal decision:
- If U-Boot does not add the reserved node, we are covered.
- If U-Boot adds the node, it will do so in a way where it deals with
existing reservations. So either it doesn't actually change anything, or
it extends the reservation.
- Should the TF-A location actually move (and we have no plans or needs to
do that), people would only get this by updating the firmware, at which
point the U-Boot part would surely be in place already. We don't really
support updating just BL31 in an existing binary firmware image, so you
would get an updated U-Boot as well.
I think the worst case scenario is that users end up with an unneeded 512K
reservation. If they care, a firmware update should solve this problem.
As for the time to remove that node: we could do that at the time when
(or rather: if) we actually change the TF-A reservation. At the moment
there are no plans to do this, and the size reservation is more than
generous (the current debug build is actually 77 KB or so only). If there
is no change, and the node stays in the .dtsi, it doesn't really hurt, see
above.
> After 10 years? Alternatively, reserved memory node can be just dropped and
> anyone loading DTB file from outside would need to make sure it's patched. But
> that's unexpected from user perspective, although patching DT files is done by
> some distros.
Yeah, let's not go there. As you know, I already dislike the idea of
explicitly loading DTBs at all, but I understand this is what people, and
distributions, do, so I'd rather have them covered. Hence the node to
work with existing firmware.
Does that make sense?
Cheers,
Andre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-04 13:30 ` Andre Przywara
@ 2022-07-04 18:42 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-04 18:42 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara napisal(a):
> On Sat, 02 Jul 2022 23:16:53 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi Jernej,
>
> > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> > > On Tue, 03 May 2022 21:05:11 +0200
> > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > >
> > > Hi Jernej,
> > >
> > > many thanks for taking the time to wade through this file!
> > >
> > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
napisal(a):
> > > > > This (relatively) new SoC is similar to the H6, but drops the
(broken)
> > > > > PCIe support and the USB 3.0 controller. It also gets the management
> > > > > controller removed, which in turn removes *some*, but not all of the
> > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > And while there is still the extra sunxi interrupt controller, the
> > > > > package lacks the corresponding NMI pin, so no interrupts for the
PMIC.
> > > > >
> > > > > The reserved memory node is actually handled by Trusted Firmware
now,
> > > > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > > > keep it in here for now, until U-Boot learns to do this properly.
> > > > >
> > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > ---
> > > > >
> > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 +++++++++++++++
+++
> > > > > 1 file changed, 574 insertions(+)
> > > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > b/arch/arm64/
> > > >
> > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > >
> > > > > new file mode 100644
> > > > > index 000000000000..cc06cdd15ba5
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > @@ -0,0 +1,574 @@
> > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > +// based on the H6 dtsi, which is:
> > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > +
> > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > +
> > > > > +/ {
> > > > > + interrupt-parent = <&gic>;
> > > > > + #address-cells = <2>;
> > > > > + #size-cells = <2>;
> > > > > +
> > > > > + cpus {
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + cpu0: cpu@0 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <0>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > +
> > > > > + cpu1: cpu@1 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <1>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > +
> > > > > + cpu2: cpu@2 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <2>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > +
> > > > > + cpu3: cpu@3 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <3>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > + };
> > > > > +
> > > > > + reserved-memory {
> > > > > + #address-cells = <2>;
> > > > > + #size-cells = <2>;
> > > > > + ranges;
> > > > > +
> > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > > + secmon_reserved: secmon@40000000 {
> > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > + no-map;
> > > > > + };
> > > > > + };
> > > >
> > > > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > > > would
> > > > need to reconfigure it anyway. Can we just skip it?
> > >
> > > I am not a fan neither, but last time I checked this is needed to boot.
> > > Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > the kernel as well.
> > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > There does not seem to be a global notion of reserved memory in U-Boot.
> > > Some commands (like tftp) explicitly parse the control DT to find and
> > > respect reserved memory regions. bootm does that also, but only to
> > > avoid placing the ramdisk or DTB into reserved memory. The information
> > > ends up in images->lmb, but is not used to generate or amend nodes in
> > > the target DT.
> > > So the bits and pieces are there, but it will require some code to be
> > > added to the generic U-Boot code.
> > >
> > > So what do you think? Leaving this out will prevent loading DTBs into
> > > U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> > > now, it should not really hurt. U-Boot will hopefully start to do the
> > > right thing soon, then we can either phase it out here (maybe when we
> > > actually change something in TF-A), or let U-Boot fix it.
> >
> > TBH, if "soon" is really soon, I would rather wait with H616 DT until U-
Boot
> > supports carrying over reserved memory nodes.
>
> But this also carries compatibility issues. U-Boot support the H616 for
> more than a year now, and the earliest possible U-Boot release having that
> propagation code would be the one released in October.
I was hoping you would say July (next U-Boot release) :).
> And then people
> would still need to update first, so that's quite some months out.
> And I was actually hoping to get at least the H616 DT patches off my
> plate, and get them into the tree to have a stable and agreed upon base
> (before this series turns into a teenager ;-)
Yeah, I would like that too.
> Then we could for instance update the U-Boot H616 support.
>
> > Whatever we do now, it will have
> > compatibility issues. If we introduce reserved memory node now, we can't
> > easily drop it later. Bootloaders are not very often updated, but kernels
and
> > DTB files are, at least in my experience. So when we decide to drop the
node?
>
> I think of the three possibilities:
> - Drop the node now, and ask people to not load DTBs explicitly
> - Drop the node when U-Boot learned to propagate the reservation
> - Keep the node
> the last one is the least painful: having this node in does not really
> hurt, so we can be very relaxed with this removal decision:
> - If U-Boot does not add the reserved node, we are covered.
> - If U-Boot adds the node, it will do so in a way where it deals with
> existing reservations. So either it doesn't actually change anything, or
> it extends the reservation.
> - Should the TF-A location actually move (and we have no plans or needs to
> do that), people would only get this by updating the firmware, at which
> point the U-Boot part would surely be in place already. We don't really
> support updating just BL31 in an existing binary firmware image, so you
> would get an updated U-Boot as well.
>
> I think the worst case scenario is that users end up with an unneeded 512K
> reservation. If they care, a firmware update should solve this problem.
>
> As for the time to remove that node: we could do that at the time when
> (or rather: if) we actually change the TF-A reservation. At the moment
> there are no plans to do this, and the size reservation is more than
> generous (the current debug build is actually 77 KB or so only). If there
> is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> above.
I see your point, but I would like to get some input from Samuel first.
Samuel, what do you think?
>
> > After 10 years? Alternatively, reserved memory node can be just dropped
and
> > anyone loading DTB file from outside would need to make sure it's patched.
But
> > that's unexpected from user perspective, although patching DT files is done
by
> > some distros.
>
> Yeah, let's not go there. As you know, I already dislike the idea of
> explicitly loading DTBs at all, but I understand this is what people, and
> distributions, do, so I'd rather have them covered. Hence the node to
> work with existing firmware.
Reusing DTB from U-Boot is only useful when you're happy with completeness of
DT and with the lack of bugs in it. Then you can save troubles with skipping
external DTB load step and life is easier. But as you know, features and thus
nodes are added in steps and sometimes some bugs are fixed, which means it's
extremely handy to have easily updatable DTB file. Yes, U-Boot can be
automated, but it's tedious for distro to maintain one bootloader package per
board. Ideally, distro shouldn't care at all about that, but many boards don't
have designated bootloader storage (SPI NOR flash in AW case), so they have to
be combined on same storage, partition even, as distro. On the other hand,
when building kernel, you automatically build all relevant DTB files, which you
can then just copy to common place. No device specific handling needed. Also,
U-Boot doesn't sync DT files every release, so latest U-Boot doesn't necessarly
mean latest DT.
Above is a bit off topic, but I hope you understand why distros opt to use
external DTB files (speaking from my own experiences).
Best regards,
Jernej
>
> Does that make sense?
>
> Cheers,
> Andre
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-04 18:42 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-04 18:42 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara napisal(a):
> On Sat, 02 Jul 2022 23:16:53 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi Jernej,
>
> > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> > > On Tue, 03 May 2022 21:05:11 +0200
> > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > >
> > > Hi Jernej,
> > >
> > > many thanks for taking the time to wade through this file!
> > >
> > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
napisal(a):
> > > > > This (relatively) new SoC is similar to the H6, but drops the
(broken)
> > > > > PCIe support and the USB 3.0 controller. It also gets the management
> > > > > controller removed, which in turn removes *some*, but not all of the
> > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > And while there is still the extra sunxi interrupt controller, the
> > > > > package lacks the corresponding NMI pin, so no interrupts for the
PMIC.
> > > > >
> > > > > The reserved memory node is actually handled by Trusted Firmware
now,
> > > > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > > > keep it in here for now, until U-Boot learns to do this properly.
> > > > >
> > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > ---
> > > > >
> > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 +++++++++++++++
+++
> > > > > 1 file changed, 574 insertions(+)
> > > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > b/arch/arm64/
> > > >
> > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > >
> > > > > new file mode 100644
> > > > > index 000000000000..cc06cdd15ba5
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > @@ -0,0 +1,574 @@
> > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > +// based on the H6 dtsi, which is:
> > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > +
> > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > +
> > > > > +/ {
> > > > > + interrupt-parent = <&gic>;
> > > > > + #address-cells = <2>;
> > > > > + #size-cells = <2>;
> > > > > +
> > > > > + cpus {
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + cpu0: cpu@0 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <0>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > +
> > > > > + cpu1: cpu@1 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <1>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > +
> > > > > + cpu2: cpu@2 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <2>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > +
> > > > > + cpu3: cpu@3 {
> > > > > + compatible = "arm,cortex-a53";
> > > > > + device_type = "cpu";
> > > > > + reg = <3>;
> > > > > + enable-method = "psci";
> > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > + };
> > > > > + };
> > > > > +
> > > > > + reserved-memory {
> > > > > + #address-cells = <2>;
> > > > > + #size-cells = <2>;
> > > > > + ranges;
> > > > > +
> > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > > + secmon_reserved: secmon@40000000 {
> > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > + no-map;
> > > > > + };
> > > > > + };
> > > >
> > > > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > > > would
> > > > need to reconfigure it anyway. Can we just skip it?
> > >
> > > I am not a fan neither, but last time I checked this is needed to boot.
> > > Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > the kernel as well.
> > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > There does not seem to be a global notion of reserved memory in U-Boot.
> > > Some commands (like tftp) explicitly parse the control DT to find and
> > > respect reserved memory regions. bootm does that also, but only to
> > > avoid placing the ramdisk or DTB into reserved memory. The information
> > > ends up in images->lmb, but is not used to generate or amend nodes in
> > > the target DT.
> > > So the bits and pieces are there, but it will require some code to be
> > > added to the generic U-Boot code.
> > >
> > > So what do you think? Leaving this out will prevent loading DTBs into
> > > U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> > > now, it should not really hurt. U-Boot will hopefully start to do the
> > > right thing soon, then we can either phase it out here (maybe when we
> > > actually change something in TF-A), or let U-Boot fix it.
> >
> > TBH, if "soon" is really soon, I would rather wait with H616 DT until U-
Boot
> > supports carrying over reserved memory nodes.
>
> But this also carries compatibility issues. U-Boot support the H616 for
> more than a year now, and the earliest possible U-Boot release having that
> propagation code would be the one released in October.
I was hoping you would say July (next U-Boot release) :).
> And then people
> would still need to update first, so that's quite some months out.
> And I was actually hoping to get at least the H616 DT patches off my
> plate, and get them into the tree to have a stable and agreed upon base
> (before this series turns into a teenager ;-)
Yeah, I would like that too.
> Then we could for instance update the U-Boot H616 support.
>
> > Whatever we do now, it will have
> > compatibility issues. If we introduce reserved memory node now, we can't
> > easily drop it later. Bootloaders are not very often updated, but kernels
and
> > DTB files are, at least in my experience. So when we decide to drop the
node?
>
> I think of the three possibilities:
> - Drop the node now, and ask people to not load DTBs explicitly
> - Drop the node when U-Boot learned to propagate the reservation
> - Keep the node
> the last one is the least painful: having this node in does not really
> hurt, so we can be very relaxed with this removal decision:
> - If U-Boot does not add the reserved node, we are covered.
> - If U-Boot adds the node, it will do so in a way where it deals with
> existing reservations. So either it doesn't actually change anything, or
> it extends the reservation.
> - Should the TF-A location actually move (and we have no plans or needs to
> do that), people would only get this by updating the firmware, at which
> point the U-Boot part would surely be in place already. We don't really
> support updating just BL31 in an existing binary firmware image, so you
> would get an updated U-Boot as well.
>
> I think the worst case scenario is that users end up with an unneeded 512K
> reservation. If they care, a firmware update should solve this problem.
>
> As for the time to remove that node: we could do that at the time when
> (or rather: if) we actually change the TF-A reservation. At the moment
> there are no plans to do this, and the size reservation is more than
> generous (the current debug build is actually 77 KB or so only). If there
> is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> above.
I see your point, but I would like to get some input from Samuel first.
Samuel, what do you think?
>
> > After 10 years? Alternatively, reserved memory node can be just dropped
and
> > anyone loading DTB file from outside would need to make sure it's patched.
But
> > that's unexpected from user perspective, although patching DT files is done
by
> > some distros.
>
> Yeah, let's not go there. As you know, I already dislike the idea of
> explicitly loading DTBs at all, but I understand this is what people, and
> distributions, do, so I'd rather have them covered. Hence the node to
> work with existing firmware.
Reusing DTB from U-Boot is only useful when you're happy with completeness of
DT and with the lack of bugs in it. Then you can save troubles with skipping
external DTB load step and life is easier. But as you know, features and thus
nodes are added in steps and sometimes some bugs are fixed, which means it's
extremely handy to have easily updatable DTB file. Yes, U-Boot can be
automated, but it's tedious for distro to maintain one bootloader package per
board. Ideally, distro shouldn't care at all about that, but many boards don't
have designated bootloader storage (SPI NOR flash in AW case), so they have to
be combined on same storage, partition even, as distro. On the other hand,
when building kernel, you automatically build all relevant DTB files, which you
can then just copy to common place. No device specific handling needed. Also,
U-Boot doesn't sync DT files every release, so latest U-Boot doesn't necessarly
mean latest DT.
Above is a bit off topic, but I hope you understand why distros opt to use
external DTB files (speaking from my own experiences).
Best regards,
Jernej
>
> Does that make sense?
>
> Cheers,
> Andre
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-04 13:30 ` Andre Przywara
@ 2022-07-04 18:44 ` Samuel Holland
-1 siblings, 0 replies; 54+ messages in thread
From: Samuel Holland @ 2022-07-04 18:44 UTC (permalink / raw)
To: Andre Przywara, Jernej Škrabec
Cc: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi Andre,
On 7/4/22 8:30 AM, Andre Przywara wrote:
> On Sat, 02 Jul 2022 23:16:53 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>> Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
>>> On Tue, 03 May 2022 21:05:11 +0200
>>> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>>>> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
>>>>> This (relatively) new SoC is similar to the H6, but drops the (broken)
>>>>> PCIe support and the USB 3.0 controller. It also gets the management
>>>>> controller removed, which in turn removes *some*, but not all of the
>>>>> devices formerly dedicated to the ARISC (CPUS).
>>>>> And while there is still the extra sunxi interrupt controller, the
>>>>> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
>>>>>
>>>>> The reserved memory node is actually handled by Trusted Firmware now,
>>>>> but U-Boot fails to propagate this to a separately loaded DTB, so we
>>>>> keep it in here for now, until U-Boot learns to do this properly.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>> ---
>>>>>
>>>>> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
>>>>> 1 file changed, 574 insertions(+)
>>>>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>>>> b/arch/arm64/
>>>>
>>>> boot/dts/allwinner/sun50i-h616.dtsi
>>>>
>>>>> new file mode 100644
>>>>> index 000000000000..cc06cdd15ba5
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>>>> @@ -0,0 +1,574 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>>>> +// Copyright (C) 2020 Arm Ltd.
>>>>> +// based on the H6 dtsi, which is:
>>>>> +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
>>>>> +
>>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +#include <dt-bindings/clock/sun50i-h616-ccu.h>
>>>>> +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
>>>>> +#include <dt-bindings/reset/sun50i-h616-ccu.h>
>>>>> +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
>>>>> +
>>>>> +/ {
>>>>> + interrupt-parent = <&gic>;
>>>>> + #address-cells = <2>;
>>>>> + #size-cells = <2>;
>>>>> +
>>>>> + cpus {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + cpu0: cpu@0 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <0>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> +
>>>>> + cpu1: cpu@1 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <1>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> +
>>>>> + cpu2: cpu@2 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <2>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> +
>>>>> + cpu3: cpu@3 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <3>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + reserved-memory {
>>>>> + #address-cells = <2>;
>>>>> + #size-cells = <2>;
>>>>> + ranges;
>>>>> +
>>>>> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
>>>>> + secmon_reserved: secmon@40000000 {
>>>>> + reg = <0x0 0x40000000 0x0 0x80000>;
>>>>> + no-map;
>>>>> + };
>>>>> + };
>>>>
>>>> I'm not a fan of above. If anything changes in future in BL31, U-Boot
>>>> would
>>>> need to reconfigure it anyway. Can we just skip it?
>>>
>>> I am not a fan neither, but last time I checked this is needed to boot.
>>> Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
>>> And that's nicely preserved if you use that DT ($fdtcontroladdr) for
>>> the kernel as well.
>>> But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
>>> U-Boot fails to propagate the /reserved-memory node into that copy.
>>> There does not seem to be a global notion of reserved memory in U-Boot.
>>> Some commands (like tftp) explicitly parse the control DT to find and
>>> respect reserved memory regions. bootm does that also, but only to
>>> avoid placing the ramdisk or DTB into reserved memory. The information
>>> ends up in images->lmb, but is not used to generate or amend nodes in
>>> the target DT.
>>> So the bits and pieces are there, but it will require some code to be
>>> added to the generic U-Boot code.
>>>
>>> So what do you think? Leaving this out will prevent loading DTBs into
>>> U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
>>> now, it should not really hurt. U-Boot will hopefully start to do the
>>> right thing soon, then we can either phase it out here (maybe when we
>>> actually change something in TF-A), or let U-Boot fix it.
>>
>> TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
>> supports carrying over reserved memory nodes.
>
> But this also carries compatibility issues. U-Boot support the H616 for
> more than a year now, and the earliest possible U-Boot release having that
> propagation code would be the one released in October. And then people
> would still need to update first, so that's quite some months out.
> And I was actually hoping to get at least the H616 DT patches off my
> plate, and get them into the tree to have a stable and agreed upon base
> (before this series turns into a teenager ;-)
> Then we could for instance update the U-Boot H616 support.
There is no compatibility issue here if people are using $fdtcontroladdr.
>> Whatever we do now, it will have
>> compatibility issues. If we introduce reserved memory node now, we can't
>> easily drop it later. Bootloaders are not very often updated, but kernels and
>> DTB files are, at least in my experience. So when we decide to drop the node?
>
> I think of the three possibilities:
> - Drop the node now, and ask people to not load DTBs explicitly
This is my preferred solution. My position has always been that the devicetree
is provided by platform firmware, not the OS. The only reason for even
submitting the devicetree to Linux is because that is the location of the
bindings and validation tooling.
I have been using this approach for D1, and so far there have been no unsolvable
problems. Yes, most image builders assume you want to load a DTB from disk, but
teaching them not to do that is fairly simple. And yes, it means we have to do
better about keeping the U-Boot DTSs in sync, but I think we can manage that.
> - Drop the node when U-Boot learned to propagate the reservation
> - Keep the node
> the last one is the least painful: having this node in does not really
> hurt, so we can be very relaxed with this removal decision:
Supporting explicitly-loaded DTBs is the most painful option going forward,
because that means U-Boot has to know about and propagate _every_ runtime change
made by any firmware component (not just changes made by it) to the control FDT.
For example, consider TF-A patching in information about idle states, or SID
contents in secure mode, or marking nodes as "reserved" because it delegates
those devices to a secure enclave. This problem is solved if we say "we support
$fdtcontroladdr, and we support overlays; but you are on your own if you load a
DTB from disk."
Distros will continue loading DTBs from disk as long as it sorta-kinda-mostly
works, and then years later users will complain that their phone uses 4 watts at
idle, because their explicitly-loaded DTB contained idle states that their
firmware did not support (this is a true story).
"Don't load DTBs" is a much easier story to tell if doing so is obviously broken
out of the box from day 1.
Regards,
Samuel
> - If U-Boot does not add the reserved node, we are covered.
> - If U-Boot adds the node, it will do so in a way where it deals with
> existing reservations. So either it doesn't actually change anything, or
> it extends the reservation.
> - Should the TF-A location actually move (and we have no plans or needs to
> do that), people would only get this by updating the firmware, at which
> point the U-Boot part would surely be in place already. We don't really
> support updating just BL31 in an existing binary firmware image, so you
> would get an updated U-Boot as well.
>
> I think the worst case scenario is that users end up with an unneeded 512K
> reservation. If they care, a firmware update should solve this problem.
>
> As for the time to remove that node: we could do that at the time when
> (or rather: if) we actually change the TF-A reservation. At the moment
> there are no plans to do this, and the size reservation is more than
> generous (the current debug build is actually 77 KB or so only). If there
> is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> above.
>
>> After 10 years? Alternatively, reserved memory node can be just dropped and
>> anyone loading DTB file from outside would need to make sure it's patched. But
>> that's unexpected from user perspective, although patching DT files is done by
>> some distros.
>
> Yeah, let's not go there. As you know, I already dislike the idea of
> explicitly loading DTBs at all, but I understand this is what people, and
> distributions, do, so I'd rather have them covered. Hence the node to
> work with existing firmware.
>
> Does that make sense?
>
> Cheers,
> Andre
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-04 18:44 ` Samuel Holland
0 siblings, 0 replies; 54+ messages in thread
From: Samuel Holland @ 2022-07-04 18:44 UTC (permalink / raw)
To: Andre Przywara, Jernej Škrabec
Cc: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi Andre,
On 7/4/22 8:30 AM, Andre Przywara wrote:
> On Sat, 02 Jul 2022 23:16:53 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>> Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
>>> On Tue, 03 May 2022 21:05:11 +0200
>>> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>>>> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
>>>>> This (relatively) new SoC is similar to the H6, but drops the (broken)
>>>>> PCIe support and the USB 3.0 controller. It also gets the management
>>>>> controller removed, which in turn removes *some*, but not all of the
>>>>> devices formerly dedicated to the ARISC (CPUS).
>>>>> And while there is still the extra sunxi interrupt controller, the
>>>>> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
>>>>>
>>>>> The reserved memory node is actually handled by Trusted Firmware now,
>>>>> but U-Boot fails to propagate this to a separately loaded DTB, so we
>>>>> keep it in here for now, until U-Boot learns to do this properly.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>> ---
>>>>>
>>>>> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
>>>>> 1 file changed, 574 insertions(+)
>>>>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>>>> b/arch/arm64/
>>>>
>>>> boot/dts/allwinner/sun50i-h616.dtsi
>>>>
>>>>> new file mode 100644
>>>>> index 000000000000..cc06cdd15ba5
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>>>> @@ -0,0 +1,574 @@
>>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>>>> +// Copyright (C) 2020 Arm Ltd.
>>>>> +// based on the H6 dtsi, which is:
>>>>> +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
>>>>> +
>>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +#include <dt-bindings/clock/sun50i-h616-ccu.h>
>>>>> +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
>>>>> +#include <dt-bindings/reset/sun50i-h616-ccu.h>
>>>>> +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
>>>>> +
>>>>> +/ {
>>>>> + interrupt-parent = <&gic>;
>>>>> + #address-cells = <2>;
>>>>> + #size-cells = <2>;
>>>>> +
>>>>> + cpus {
>>>>> + #address-cells = <1>;
>>>>> + #size-cells = <0>;
>>>>> +
>>>>> + cpu0: cpu@0 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <0>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> +
>>>>> + cpu1: cpu@1 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <1>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> +
>>>>> + cpu2: cpu@2 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <2>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> +
>>>>> + cpu3: cpu@3 {
>>>>> + compatible = "arm,cortex-a53";
>>>>> + device_type = "cpu";
>>>>> + reg = <3>;
>>>>> + enable-method = "psci";
>>>>> + clocks = <&ccu CLK_CPUX>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + reserved-memory {
>>>>> + #address-cells = <2>;
>>>>> + #size-cells = <2>;
>>>>> + ranges;
>>>>> +
>>>>> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
>>>>> + secmon_reserved: secmon@40000000 {
>>>>> + reg = <0x0 0x40000000 0x0 0x80000>;
>>>>> + no-map;
>>>>> + };
>>>>> + };
>>>>
>>>> I'm not a fan of above. If anything changes in future in BL31, U-Boot
>>>> would
>>>> need to reconfigure it anyway. Can we just skip it?
>>>
>>> I am not a fan neither, but last time I checked this is needed to boot.
>>> Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
>>> And that's nicely preserved if you use that DT ($fdtcontroladdr) for
>>> the kernel as well.
>>> But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
>>> U-Boot fails to propagate the /reserved-memory node into that copy.
>>> There does not seem to be a global notion of reserved memory in U-Boot.
>>> Some commands (like tftp) explicitly parse the control DT to find and
>>> respect reserved memory regions. bootm does that also, but only to
>>> avoid placing the ramdisk or DTB into reserved memory. The information
>>> ends up in images->lmb, but is not used to generate or amend nodes in
>>> the target DT.
>>> So the bits and pieces are there, but it will require some code to be
>>> added to the generic U-Boot code.
>>>
>>> So what do you think? Leaving this out will prevent loading DTBs into
>>> U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
>>> now, it should not really hurt. U-Boot will hopefully start to do the
>>> right thing soon, then we can either phase it out here (maybe when we
>>> actually change something in TF-A), or let U-Boot fix it.
>>
>> TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
>> supports carrying over reserved memory nodes.
>
> But this also carries compatibility issues. U-Boot support the H616 for
> more than a year now, and the earliest possible U-Boot release having that
> propagation code would be the one released in October. And then people
> would still need to update first, so that's quite some months out.
> And I was actually hoping to get at least the H616 DT patches off my
> plate, and get them into the tree to have a stable and agreed upon base
> (before this series turns into a teenager ;-)
> Then we could for instance update the U-Boot H616 support.
There is no compatibility issue here if people are using $fdtcontroladdr.
>> Whatever we do now, it will have
>> compatibility issues. If we introduce reserved memory node now, we can't
>> easily drop it later. Bootloaders are not very often updated, but kernels and
>> DTB files are, at least in my experience. So when we decide to drop the node?
>
> I think of the three possibilities:
> - Drop the node now, and ask people to not load DTBs explicitly
This is my preferred solution. My position has always been that the devicetree
is provided by platform firmware, not the OS. The only reason for even
submitting the devicetree to Linux is because that is the location of the
bindings and validation tooling.
I have been using this approach for D1, and so far there have been no unsolvable
problems. Yes, most image builders assume you want to load a DTB from disk, but
teaching them not to do that is fairly simple. And yes, it means we have to do
better about keeping the U-Boot DTSs in sync, but I think we can manage that.
> - Drop the node when U-Boot learned to propagate the reservation
> - Keep the node
> the last one is the least painful: having this node in does not really
> hurt, so we can be very relaxed with this removal decision:
Supporting explicitly-loaded DTBs is the most painful option going forward,
because that means U-Boot has to know about and propagate _every_ runtime change
made by any firmware component (not just changes made by it) to the control FDT.
For example, consider TF-A patching in information about idle states, or SID
contents in secure mode, or marking nodes as "reserved" because it delegates
those devices to a secure enclave. This problem is solved if we say "we support
$fdtcontroladdr, and we support overlays; but you are on your own if you load a
DTB from disk."
Distros will continue loading DTBs from disk as long as it sorta-kinda-mostly
works, and then years later users will complain that their phone uses 4 watts at
idle, because their explicitly-loaded DTB contained idle states that their
firmware did not support (this is a true story).
"Don't load DTBs" is a much easier story to tell if doing so is obviously broken
out of the box from day 1.
Regards,
Samuel
> - If U-Boot does not add the reserved node, we are covered.
> - If U-Boot adds the node, it will do so in a way where it deals with
> existing reservations. So either it doesn't actually change anything, or
> it extends the reservation.
> - Should the TF-A location actually move (and we have no plans or needs to
> do that), people would only get this by updating the firmware, at which
> point the U-Boot part would surely be in place already. We don't really
> support updating just BL31 in an existing binary firmware image, so you
> would get an updated U-Boot as well.
>
> I think the worst case scenario is that users end up with an unneeded 512K
> reservation. If they care, a firmware update should solve this problem.
>
> As for the time to remove that node: we could do that at the time when
> (or rather: if) we actually change the TF-A reservation. At the moment
> there are no plans to do this, and the size reservation is more than
> generous (the current debug build is actually 77 KB or so only). If there
> is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> above.
>
>> After 10 years? Alternatively, reserved memory node can be just dropped and
>> anyone loading DTB file from outside would need to make sure it's patched. But
>> that's unexpected from user perspective, although patching DT files is done by
>> some distros.
>
> Yeah, let's not go there. As you know, I already dislike the idea of
> explicitly loading DTBs at all, but I understand this is what people, and
> distributions, do, so I'd rather have them covered. Hence the node to
> work with existing firmware.
>
> Does that make sense?
>
> Cheers,
> Andre
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-04 18:44 ` Samuel Holland
@ 2022-07-04 20:52 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-04 20:52 UTC (permalink / raw)
To: Samuel Holland
Cc: Jernej Škrabec, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Icenowy Zheng, linux-arm-kernel,
linux-sunxi, devicetree, linux-kernel
On Mon, 4 Jul 2022 13:44:18 -0500
Samuel Holland <samuel@sholland.org> wrote:
Hi Samuel,
> On 7/4/22 8:30 AM, Andre Przywara wrote:
> > On Sat, 02 Jul 2022 23:16:53 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >> Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> >>> On Tue, 03 May 2022 21:05:11 +0200
> >>> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >>>> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> >>>>> This (relatively) new SoC is similar to the H6, but drops the (broken)
> >>>>> PCIe support and the USB 3.0 controller. It also gets the management
> >>>>> controller removed, which in turn removes *some*, but not all of the
> >>>>> devices formerly dedicated to the ARISC (CPUS).
> >>>>> And while there is still the extra sunxi interrupt controller, the
> >>>>> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> >>>>>
> >>>>> The reserved memory node is actually handled by Trusted Firmware now,
> >>>>> but U-Boot fails to propagate this to a separately loaded DTB, so we
> >>>>> keep it in here for now, until U-Boot learns to do this properly.
> >>>>>
> >>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>>>> ---
> >>>>>
> >>>>> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> >>>>> 1 file changed, 574 insertions(+)
> >>>>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >>>>> b/arch/arm64/
> >>>>
> >>>> boot/dts/allwinner/sun50i-h616.dtsi
> >>>>
> >>>>> new file mode 100644
> >>>>> index 000000000000..cc06cdd15ba5
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >>>>> @@ -0,0 +1,574 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>>>> +// Copyright (C) 2020 Arm Ltd.
> >>>>> +// based on the H6 dtsi, which is:
> >>>>> +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> >>>>> +
> >>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> >>>>> +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> >>>>> +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> >>>>> +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> >>>>> +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> >>>>> +
> >>>>> +/ {
> >>>>> + interrupt-parent = <&gic>;
> >>>>> + #address-cells = <2>;
> >>>>> + #size-cells = <2>;
> >>>>> +
> >>>>> + cpus {
> >>>>> + #address-cells = <1>;
> >>>>> + #size-cells = <0>;
> >>>>> +
> >>>>> + cpu0: cpu@0 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <0>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> +
> >>>>> + cpu1: cpu@1 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <1>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> +
> >>>>> + cpu2: cpu@2 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <2>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> +
> >>>>> + cpu3: cpu@3 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <3>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> + };
> >>>>> +
> >>>>> + reserved-memory {
> >>>>> + #address-cells = <2>;
> >>>>> + #size-cells = <2>;
> >>>>> + ranges;
> >>>>> +
> >>>>> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> >>>>> + secmon_reserved: secmon@40000000 {
> >>>>> + reg = <0x0 0x40000000 0x0 0x80000>;
> >>>>> + no-map;
> >>>>> + };
> >>>>> + };
> >>>>
> >>>> I'm not a fan of above. If anything changes in future in BL31, U-Boot
> >>>> would
> >>>> need to reconfigure it anyway. Can we just skip it?
> >>>
> >>> I am not a fan neither, but last time I checked this is needed to boot.
> >>> Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> >>> And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> >>> the kernel as well.
> >>> But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> >>> U-Boot fails to propagate the /reserved-memory node into that copy.
> >>> There does not seem to be a global notion of reserved memory in U-Boot.
> >>> Some commands (like tftp) explicitly parse the control DT to find and
> >>> respect reserved memory regions. bootm does that also, but only to
> >>> avoid placing the ramdisk or DTB into reserved memory. The information
> >>> ends up in images->lmb, but is not used to generate or amend nodes in
> >>> the target DT.
> >>> So the bits and pieces are there, but it will require some code to be
> >>> added to the generic U-Boot code.
> >>>
> >>> So what do you think? Leaving this out will prevent loading DTBs into
> >>> U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> >>> now, it should not really hurt. U-Boot will hopefully start to do the
> >>> right thing soon, then we can either phase it out here (maybe when we
> >>> actually change something in TF-A), or let U-Boot fix it.
> >>
> >> TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
> >> supports carrying over reserved memory nodes.
> >
> > But this also carries compatibility issues. U-Boot support the H616 for
> > more than a year now, and the earliest possible U-Boot release having that
> > propagation code would be the one released in October. And then people
> > would still need to update first, so that's quite some months out.
> > And I was actually hoping to get at least the H616 DT patches off my
> > plate, and get them into the tree to have a stable and agreed upon base
> > (before this series turns into a teenager ;-)
> > Then we could for instance update the U-Boot H616 support.
>
> There is no compatibility issue here if people are using $fdtcontroladdr.
>
> >> Whatever we do now, it will have
> >> compatibility issues. If we introduce reserved memory node now, we can't
> >> easily drop it later. Bootloaders are not very often updated, but kernels and
> >> DTB files are, at least in my experience. So when we decide to drop the node?
> >
> > I think of the three possibilities:
> > - Drop the node now, and ask people to not load DTBs explicitly
>
> This is my preferred solution. My position has always been that the devicetree
> is provided by platform firmware, not the OS. The only reason for even
> submitting the devicetree to Linux is because that is the location of the
> bindings and validation tooling.
Well, you are barking at the wrong tree here ;-)
I am 100% behind the $fdtcontroladdr and "firmware ships DT" idea.
However this relies on one thing: that there will never be an
incompatible change to the DT. So at any point in time there must be
exactly one best DT for that board, and that DT must be able to boot
every kernel: older ones, current ones, FreeBSD ones, you name it.
Because otherwise you cannot update your DT, or you lose the ability to
boot a stable distro, or the stable fallback kernel that your distro
installed, for instance.
And this is not theoretical: Debian 11 ships with v5.10, which does not
boot with a DT from >= v5.13 (r_intc binding change for most AW SoCs).
And yes, this means we have to live with decisions we once made, and
have to make compromises, so cannot get the DT "exactly right by the
book", since we need to maintain compatibility. I strongly believe
there are solutions that allow this, even if we spot mistakes later or
need to amend something to make a new feature work. At the cost of
being potentially somewhat "hacky".
Some years ago I have been explicitly told that mainline sunxi Linux
does not have the resources to pull this off, and we don't guarantee
forward compatibility, which in my view renders this $fdtcontroladdr
approach moot. And the r_intc binding change, also the upcoming A23
clock change tell me that this is still the position among the
maintainers?
Or has this position changed for new SoCs? So do we promise to never
break compatibility for D1 and H616, and other new SoCs? Or even for
older SoCs, from now on?
> I have been using this approach for D1, and so far there have been no unsolvable
> problems. Yes, most image builders assume you want to load a DTB from disk, but
> teaching them not to do that is fairly simple. And yes, it means we have to do
> better about keeping the U-Boot DTSs in sync, but I think we can manage that.
Yes, I am very happy to update them much more regularly, and even have
some prototype tool to update the DTB directly in the FIT image on SPI
flash/eMMC boot/SD card/etc. Or I guess we rather explore the EFI
capsule update path more.
However this is all rather pointless (and actually counterproductive) if
that new DT does not boot all kernels.
> > - Drop the node when U-Boot learned to propagate the reservation
> > - Keep the node
> > the last one is the least painful: having this node in does not really
> > hurt, so we can be very relaxed with this removal decision:
>
> Supporting explicitly-loaded DTBs is the most painful option going forward,
> because that means U-Boot has to know about and propagate _every_ runtime change
> made by any firmware component (not just changes made by it) to the control FDT.
Yes, you have some point there.
> For example, consider TF-A patching in information about idle states, or SID
> contents in secure mode, or marking nodes as "reserved" because it delegates
> those devices to a secure enclave. This problem is solved if we say "we support
> $fdtcontroladdr, and we support overlays; but you are on your own if you load a
> DTB from disk."
>
> Distros will continue loading DTBs from disk as long as it sorta-kinda-mostly
> works, and then years later users will complain that their phone uses 4 watts at
> idle, because their explicitly-loaded DTB contained idle states that their
> firmware did not support (this is a true story).
>
> "Don't load DTBs" is a much easier story to tell if doing so is obviously broken
> out of the box from day 1.
I mostly agree, from a developer's point of view. My suggestion was
just trying to embrace the (current) reality, and giving the user the
ability to load a new DTB. But yes, they should not do this.
And I actually believe distros don't really like this approach either,
it's just how mainline Linux worked for most platforms: you better run
with the latest DTB, and the one matching the kernel (whatever that
means). So I think they will be quite happy to use U-Boot's DTB, though
this needs to be the universal one.
So I think the whole discussion boils down to the question of how we
are going to deal with upcoming DT fixes? Do we allow them only in a
compatible way?
And this could be a simple thing, like adding a previously unknown
regulator to a device: older kernels might not support that regulator,
so the device now fails probing. This is a prominent problem for
initial (minimal) DTs, where we only get PMIC support later. Sure, we
could demand having PMIC support in from day one, but there might be
other things we miss (like a clock gated by the RTC).
Cheers,
Andre
>
> Regards,
> Samuel
>
> > - If U-Boot does not add the reserved node, we are covered.
> > - If U-Boot adds the node, it will do so in a way where it deals with
> > existing reservations. So either it doesn't actually change anything, or
> > it extends the reservation.
> > - Should the TF-A location actually move (and we have no plans or needs to
> > do that), people would only get this by updating the firmware, at which
> > point the U-Boot part would surely be in place already. We don't really
> > support updating just BL31 in an existing binary firmware image, so you
> > would get an updated U-Boot as well.
> >
> > I think the worst case scenario is that users end up with an unneeded 512K
> > reservation. If they care, a firmware update should solve this problem.
> >
> > As for the time to remove that node: we could do that at the time when
> > (or rather: if) we actually change the TF-A reservation. At the moment
> > there are no plans to do this, and the size reservation is more than
> > generous (the current debug build is actually 77 KB or so only). If there
> > is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> > above.
> >
> >> After 10 years? Alternatively, reserved memory node can be just dropped and
> >> anyone loading DTB file from outside would need to make sure it's patched. But
> >> that's unexpected from user perspective, although patching DT files is done by
> >> some distros.
> >
> > Yeah, let's not go there. As you know, I already dislike the idea of
> > explicitly loading DTBs at all, but I understand this is what people, and
> > distributions, do, so I'd rather have them covered. Hence the node to
> > work with existing firmware.
> >
> > Does that make sense?
> >
> > Cheers,
> > Andre
> >
>
>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-04 20:52 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-04 20:52 UTC (permalink / raw)
To: Samuel Holland
Cc: Jernej Škrabec, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Icenowy Zheng, linux-arm-kernel,
linux-sunxi, devicetree, linux-kernel
On Mon, 4 Jul 2022 13:44:18 -0500
Samuel Holland <samuel@sholland.org> wrote:
Hi Samuel,
> On 7/4/22 8:30 AM, Andre Przywara wrote:
> > On Sat, 02 Jul 2022 23:16:53 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >> Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> >>> On Tue, 03 May 2022 21:05:11 +0200
> >>> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >>>> Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara napisal(a):
> >>>>> This (relatively) new SoC is similar to the H6, but drops the (broken)
> >>>>> PCIe support and the USB 3.0 controller. It also gets the management
> >>>>> controller removed, which in turn removes *some*, but not all of the
> >>>>> devices formerly dedicated to the ARISC (CPUS).
> >>>>> And while there is still the extra sunxi interrupt controller, the
> >>>>> package lacks the corresponding NMI pin, so no interrupts for the PMIC.
> >>>>>
> >>>>> The reserved memory node is actually handled by Trusted Firmware now,
> >>>>> but U-Boot fails to propagate this to a separately loaded DTB, so we
> >>>>> keep it in here for now, until U-Boot learns to do this properly.
> >>>>>
> >>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>>>> ---
> >>>>>
> >>>>> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 ++++++++++++++++++
> >>>>> 1 file changed, 574 insertions(+)
> >>>>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >>>>> b/arch/arm64/
> >>>>
> >>>> boot/dts/allwinner/sun50i-h616.dtsi
> >>>>
> >>>>> new file mode 100644
> >>>>> index 000000000000..cc06cdd15ba5
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> >>>>> @@ -0,0 +1,574 @@
> >>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >>>>> +// Copyright (C) 2020 Arm Ltd.
> >>>>> +// based on the H6 dtsi, which is:
> >>>>> +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> >>>>> +
> >>>>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> >>>>> +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> >>>>> +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> >>>>> +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> >>>>> +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> >>>>> +
> >>>>> +/ {
> >>>>> + interrupt-parent = <&gic>;
> >>>>> + #address-cells = <2>;
> >>>>> + #size-cells = <2>;
> >>>>> +
> >>>>> + cpus {
> >>>>> + #address-cells = <1>;
> >>>>> + #size-cells = <0>;
> >>>>> +
> >>>>> + cpu0: cpu@0 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <0>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> +
> >>>>> + cpu1: cpu@1 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <1>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> +
> >>>>> + cpu2: cpu@2 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <2>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> +
> >>>>> + cpu3: cpu@3 {
> >>>>> + compatible = "arm,cortex-a53";
> >>>>> + device_type = "cpu";
> >>>>> + reg = <3>;
> >>>>> + enable-method = "psci";
> >>>>> + clocks = <&ccu CLK_CPUX>;
> >>>>> + };
> >>>>> + };
> >>>>> +
> >>>>> + reserved-memory {
> >>>>> + #address-cells = <2>;
> >>>>> + #size-cells = <2>;
> >>>>> + ranges;
> >>>>> +
> >>>>> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> >>>>> + secmon_reserved: secmon@40000000 {
> >>>>> + reg = <0x0 0x40000000 0x0 0x80000>;
> >>>>> + no-map;
> >>>>> + };
> >>>>> + };
> >>>>
> >>>> I'm not a fan of above. If anything changes in future in BL31, U-Boot
> >>>> would
> >>>> need to reconfigure it anyway. Can we just skip it?
> >>>
> >>> I am not a fan neither, but last time I checked this is needed to boot.
> >>> Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> >>> And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> >>> the kernel as well.
> >>> But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> >>> U-Boot fails to propagate the /reserved-memory node into that copy.
> >>> There does not seem to be a global notion of reserved memory in U-Boot.
> >>> Some commands (like tftp) explicitly parse the control DT to find and
> >>> respect reserved memory regions. bootm does that also, but only to
> >>> avoid placing the ramdisk or DTB into reserved memory. The information
> >>> ends up in images->lmb, but is not used to generate or amend nodes in
> >>> the target DT.
> >>> So the bits and pieces are there, but it will require some code to be
> >>> added to the generic U-Boot code.
> >>>
> >>> So what do you think? Leaving this out will prevent loading DTBs into
> >>> U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> >>> now, it should not really hurt. U-Boot will hopefully start to do the
> >>> right thing soon, then we can either phase it out here (maybe when we
> >>> actually change something in TF-A), or let U-Boot fix it.
> >>
> >> TBH, if "soon" is really soon, I would rather wait with H616 DT until U-Boot
> >> supports carrying over reserved memory nodes.
> >
> > But this also carries compatibility issues. U-Boot support the H616 for
> > more than a year now, and the earliest possible U-Boot release having that
> > propagation code would be the one released in October. And then people
> > would still need to update first, so that's quite some months out.
> > And I was actually hoping to get at least the H616 DT patches off my
> > plate, and get them into the tree to have a stable and agreed upon base
> > (before this series turns into a teenager ;-)
> > Then we could for instance update the U-Boot H616 support.
>
> There is no compatibility issue here if people are using $fdtcontroladdr.
>
> >> Whatever we do now, it will have
> >> compatibility issues. If we introduce reserved memory node now, we can't
> >> easily drop it later. Bootloaders are not very often updated, but kernels and
> >> DTB files are, at least in my experience. So when we decide to drop the node?
> >
> > I think of the three possibilities:
> > - Drop the node now, and ask people to not load DTBs explicitly
>
> This is my preferred solution. My position has always been that the devicetree
> is provided by platform firmware, not the OS. The only reason for even
> submitting the devicetree to Linux is because that is the location of the
> bindings and validation tooling.
Well, you are barking at the wrong tree here ;-)
I am 100% behind the $fdtcontroladdr and "firmware ships DT" idea.
However this relies on one thing: that there will never be an
incompatible change to the DT. So at any point in time there must be
exactly one best DT for that board, and that DT must be able to boot
every kernel: older ones, current ones, FreeBSD ones, you name it.
Because otherwise you cannot update your DT, or you lose the ability to
boot a stable distro, or the stable fallback kernel that your distro
installed, for instance.
And this is not theoretical: Debian 11 ships with v5.10, which does not
boot with a DT from >= v5.13 (r_intc binding change for most AW SoCs).
And yes, this means we have to live with decisions we once made, and
have to make compromises, so cannot get the DT "exactly right by the
book", since we need to maintain compatibility. I strongly believe
there are solutions that allow this, even if we spot mistakes later or
need to amend something to make a new feature work. At the cost of
being potentially somewhat "hacky".
Some years ago I have been explicitly told that mainline sunxi Linux
does not have the resources to pull this off, and we don't guarantee
forward compatibility, which in my view renders this $fdtcontroladdr
approach moot. And the r_intc binding change, also the upcoming A23
clock change tell me that this is still the position among the
maintainers?
Or has this position changed for new SoCs? So do we promise to never
break compatibility for D1 and H616, and other new SoCs? Or even for
older SoCs, from now on?
> I have been using this approach for D1, and so far there have been no unsolvable
> problems. Yes, most image builders assume you want to load a DTB from disk, but
> teaching them not to do that is fairly simple. And yes, it means we have to do
> better about keeping the U-Boot DTSs in sync, but I think we can manage that.
Yes, I am very happy to update them much more regularly, and even have
some prototype tool to update the DTB directly in the FIT image on SPI
flash/eMMC boot/SD card/etc. Or I guess we rather explore the EFI
capsule update path more.
However this is all rather pointless (and actually counterproductive) if
that new DT does not boot all kernels.
> > - Drop the node when U-Boot learned to propagate the reservation
> > - Keep the node
> > the last one is the least painful: having this node in does not really
> > hurt, so we can be very relaxed with this removal decision:
>
> Supporting explicitly-loaded DTBs is the most painful option going forward,
> because that means U-Boot has to know about and propagate _every_ runtime change
> made by any firmware component (not just changes made by it) to the control FDT.
Yes, you have some point there.
> For example, consider TF-A patching in information about idle states, or SID
> contents in secure mode, or marking nodes as "reserved" because it delegates
> those devices to a secure enclave. This problem is solved if we say "we support
> $fdtcontroladdr, and we support overlays; but you are on your own if you load a
> DTB from disk."
>
> Distros will continue loading DTBs from disk as long as it sorta-kinda-mostly
> works, and then years later users will complain that their phone uses 4 watts at
> idle, because their explicitly-loaded DTB contained idle states that their
> firmware did not support (this is a true story).
>
> "Don't load DTBs" is a much easier story to tell if doing so is obviously broken
> out of the box from day 1.
I mostly agree, from a developer's point of view. My suggestion was
just trying to embrace the (current) reality, and giving the user the
ability to load a new DTB. But yes, they should not do this.
And I actually believe distros don't really like this approach either,
it's just how mainline Linux worked for most platforms: you better run
with the latest DTB, and the one matching the kernel (whatever that
means). So I think they will be quite happy to use U-Boot's DTB, though
this needs to be the universal one.
So I think the whole discussion boils down to the question of how we
are going to deal with upcoming DT fixes? Do we allow them only in a
compatible way?
And this could be a simple thing, like adding a previously unknown
regulator to a device: older kernels might not support that regulator,
so the device now fails probing. This is a prominent problem for
initial (minimal) DTs, where we only get PMIC support later. Sure, we
could demand having PMIC support in from day one, but there might be
other things we miss (like a clock gated by the RTC).
Cheers,
Andre
>
> Regards,
> Samuel
>
> > - If U-Boot does not add the reserved node, we are covered.
> > - If U-Boot adds the node, it will do so in a way where it deals with
> > existing reservations. So either it doesn't actually change anything, or
> > it extends the reservation.
> > - Should the TF-A location actually move (and we have no plans or needs to
> > do that), people would only get this by updating the firmware, at which
> > point the U-Boot part would surely be in place already. We don't really
> > support updating just BL31 in an existing binary firmware image, so you
> > would get an updated U-Boot as well.
> >
> > I think the worst case scenario is that users end up with an unneeded 512K
> > reservation. If they care, a firmware update should solve this problem.
> >
> > As for the time to remove that node: we could do that at the time when
> > (or rather: if) we actually change the TF-A reservation. At the moment
> > there are no plans to do this, and the size reservation is more than
> > generous (the current debug build is actually 77 KB or so only). If there
> > is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> > above.
> >
> >> After 10 years? Alternatively, reserved memory node can be just dropped and
> >> anyone loading DTB file from outside would need to make sure it's patched. But
> >> that's unexpected from user perspective, although patching DT files is done by
> >> some distros.
> >
> > Yeah, let's not go there. As you know, I already dislike the idea of
> > explicitly loading DTBs at all, but I understand this is what people, and
> > distributions, do, so I'd rather have them covered. Hence the node to
> > work with existing firmware.
> >
> > Does that make sense?
> >
> > Cheers,
> > Andre
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-04 18:42 ` Jernej Škrabec
@ 2022-07-04 21:58 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-04 21:58 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Mon, 04 Jul 2022 20:42:47 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara napisal(a):
> > On Sat, 02 Jul 2022 23:16:53 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> > > > On Tue, 03 May 2022 21:05:11 +0200
> > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > >
> > > > Hi Jernej,
> > > >
> > > > many thanks for taking the time to wade through this file!
> > > >
> > > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
> napisal(a):
> > > > > > This (relatively) new SoC is similar to the H6, but drops the
> (broken)
> > > > > > PCIe support and the USB 3.0 controller. It also gets the management
> > > > > > controller removed, which in turn removes *some*, but not all of the
> > > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > > And while there is still the extra sunxi interrupt controller, the
> > > > > > package lacks the corresponding NMI pin, so no interrupts for the
> PMIC.
> > > > > >
> > > > > > The reserved memory node is actually handled by Trusted Firmware
> now,
> > > > > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > > > > keep it in here for now, until U-Boot learns to do this properly.
> > > > > >
> > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > > ---
> > > > > >
> > > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 +++++++++++++++
> +++
> > > > > > 1 file changed, 574 insertions(+)
> > > > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > b/arch/arm64/
> > > > >
> > > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > > >
> > > > > > new file mode 100644
> > > > > > index 000000000000..cc06cdd15ba5
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > @@ -0,0 +1,574 @@
> > > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > > +// based on the H6 dtsi, which is:
> > > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > > +
> > > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > > +
> > > > > > +/ {
> > > > > > + interrupt-parent = <&gic>;
> > > > > > + #address-cells = <2>;
> > > > > > + #size-cells = <2>;
> > > > > > +
> > > > > > + cpus {
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + cpu0: cpu@0 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <0>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu1: cpu@1 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <1>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu2: cpu@2 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <2>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu3: cpu@3 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <3>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > + };
> > > > > > +
> > > > > > + reserved-memory {
> > > > > > + #address-cells = <2>;
> > > > > > + #size-cells = <2>;
> > > > > > + ranges;
> > > > > > +
> > > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > > > + secmon_reserved: secmon@40000000 {
> > > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > > + no-map;
> > > > > > + };
> > > > > > + };
> > > > >
> > > > > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > > > > would
> > > > > need to reconfigure it anyway. Can we just skip it?
> > > >
> > > > I am not a fan neither, but last time I checked this is needed to boot.
> > > > Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> > > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > > the kernel as well.
> > > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > > There does not seem to be a global notion of reserved memory in U-Boot.
> > > > Some commands (like tftp) explicitly parse the control DT to find and
> > > > respect reserved memory regions. bootm does that also, but only to
> > > > avoid placing the ramdisk or DTB into reserved memory. The information
> > > > ends up in images->lmb, but is not used to generate or amend nodes in
> > > > the target DT.
> > > > So the bits and pieces are there, but it will require some code to be
> > > > added to the generic U-Boot code.
> > > >
> > > > So what do you think? Leaving this out will prevent loading DTBs into
> > > > U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> > > > now, it should not really hurt. U-Boot will hopefully start to do the
> > > > right thing soon, then we can either phase it out here (maybe when we
> > > > actually change something in TF-A), or let U-Boot fix it.
> > >
> > > TBH, if "soon" is really soon, I would rather wait with H616 DT until U-
> Boot
> > > supports carrying over reserved memory nodes.
> >
> > But this also carries compatibility issues. U-Boot support the H616 for
> > more than a year now, and the earliest possible U-Boot release having that
> > propagation code would be the one released in October.
>
> I was hoping you would say July (next U-Boot release) :).
Well, 2022.07 was supposed to be released today, and even if that is
delayed by a bit, that's obviously far too late ;-)
> > And then people
> > would still need to update first, so that's quite some months out.
> > And I was actually hoping to get at least the H616 DT patches off my
> > plate, and get them into the tree to have a stable and agreed upon base
> > (before this series turns into a teenager ;-)
>
> Yeah, I would like that too.
>
> > Then we could for instance update the U-Boot H616 support.
> >
> > > Whatever we do now, it will have
> > > compatibility issues. If we introduce reserved memory node now, we can't
> > > easily drop it later. Bootloaders are not very often updated, but kernels
> and
> > > DTB files are, at least in my experience. So when we decide to drop the
> node?
> >
> > I think of the three possibilities:
> > - Drop the node now, and ask people to not load DTBs explicitly
> > - Drop the node when U-Boot learned to propagate the reservation
> > - Keep the node
> > the last one is the least painful: having this node in does not really
> > hurt, so we can be very relaxed with this removal decision:
> > - If U-Boot does not add the reserved node, we are covered.
> > - If U-Boot adds the node, it will do so in a way where it deals with
> > existing reservations. So either it doesn't actually change anything, or
> > it extends the reservation.
> > - Should the TF-A location actually move (and we have no plans or needs to
> > do that), people would only get this by updating the firmware, at which
> > point the U-Boot part would surely be in place already. We don't really
> > support updating just BL31 in an existing binary firmware image, so you
> > would get an updated U-Boot as well.
> >
> > I think the worst case scenario is that users end up with an unneeded 512K
> > reservation. If they care, a firmware update should solve this problem.
> >
> > As for the time to remove that node: we could do that at the time when
> > (or rather: if) we actually change the TF-A reservation. At the moment
> > there are no plans to do this, and the size reservation is more than
> > generous (the current debug build is actually 77 KB or so only). If there
> > is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> > above.
>
> I see your point, but I would like to get some input from Samuel first.
>
> Samuel, what do you think?
>
> >
> > > After 10 years? Alternatively, reserved memory node can be just dropped
> and
> > > anyone loading DTB file from outside would need to make sure it's patched.
> But
> > > that's unexpected from user perspective, although patching DT files is done
> by
> > > some distros.
> >
> > Yeah, let's not go there. As you know, I already dislike the idea of
> > explicitly loading DTBs at all, but I understand this is what people, and
> > distributions, do, so I'd rather have them covered. Hence the node to
> > work with existing firmware.
>
> Reusing DTB from U-Boot is only useful when you're happy with completeness of
> DT and with the lack of bugs in it. Then you can save troubles with skipping
> external DTB load step and life is easier. But as you know, features and thus
> nodes are added in steps and sometimes some bugs are fixed, which means it's
> extremely handy to have easily updatable DTB file.
Yes, definitely, see my reply to Samuel. I just held back with the DT
update in U-Boot because of the conflict between "we only take pure
kernel tree DTs" and "there is a breaking change" (r_intc binding).
If we find a way forward with the DT stability problem, I am happy to
push for a much more frequent DT update, or even update just the DT in
an existing firmware installation. This can be automated, since the DTB
is just a member in the FIT image, which can be re-assembled with an
updated DTB by some tool or script. Or we use capsule updates, of just
the DTB, separately (if this is possible)?
> Yes, U-Boot can be
> automated, but it's tedious for distro to maintain one bootloader package per
> board. Ideally, distro shouldn't care at all about that,
Yes, I totally agree, distros should not ship firmware. Since leaving
this to the board vendors is not realistic, I wonder if we (as "the
sunxi community") should step up here, and provide binary builds (purely
for convenience reasons) of board firmware? That could be updated from
a running Linux, or put on an SD card, or fetched by distros to
generate an installer? Wasn't there even some central storage offered
lately by Linux, to hold (UEFI) firmware update files?
> but many boards don't
> have designated bootloader storage (SPI NOR flash in AW case), so they have to
> be combined on same storage, partition even, as distro.
Have you tried eMMC boot partitions? I found them equally convenient as
SPI flash, and while not too many boards actually have SPI flash,
quite some have eMMC (thinking about TV boxes). I recently even
used "dual boot" with a BSP installation.
And even the smallest eMMCs seem to have 4 MB per boot partition, so
plenty of space for U-Boot (plus TF-A plus crust).
> On the other hand,
> when building kernel, you automatically build all relevant DTB files, which you
> can then just copy to common place. No device specific handling needed. Also,
> U-Boot doesn't sync DT files every release, so latest U-Boot doesn't necessarly
> mean latest DT.
Yes, for the compatibility reasons mentioned. I am more than happy to
make this a regular exercise (say at each kernel's -rc3 or so).
> Above is a bit off topic, but I hope you understand why distros opt to use
> external DTB files (speaking from my own experiences).
Yes, I understand where they (including LE) are coming from, to provide
a pragmatic solution to the users' problems. And that's why I wanted to
still give the possibility to load a DTB, even though I think this
should not be the standard way.
Cheers,
Andre
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-04 21:58 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-04 21:58 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Mon, 04 Jul 2022 20:42:47 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
> Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara napisal(a):
> > On Sat, 02 Jul 2022 23:16:53 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara napisal(a):
> > > > On Tue, 03 May 2022 21:05:11 +0200
> > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > >
> > > > Hi Jernej,
> > > >
> > > > many thanks for taking the time to wade through this file!
> > > >
> > > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
> napisal(a):
> > > > > > This (relatively) new SoC is similar to the H6, but drops the
> (broken)
> > > > > > PCIe support and the USB 3.0 controller. It also gets the management
> > > > > > controller removed, which in turn removes *some*, but not all of the
> > > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > > And while there is still the extra sunxi interrupt controller, the
> > > > > > package lacks the corresponding NMI pin, so no interrupts for the
> PMIC.
> > > > > >
> > > > > > The reserved memory node is actually handled by Trusted Firmware
> now,
> > > > > > but U-Boot fails to propagate this to a separately loaded DTB, so we
> > > > > > keep it in here for now, until U-Boot learns to do this properly.
> > > > > >
> > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > > ---
> > > > > >
> > > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574 +++++++++++++++
> +++
> > > > > > 1 file changed, 574 insertions(+)
> > > > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > b/arch/arm64/
> > > > >
> > > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > > >
> > > > > > new file mode 100644
> > > > > > index 000000000000..cc06cdd15ba5
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > @@ -0,0 +1,574 @@
> > > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > > +// based on the H6 dtsi, which is:
> > > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > > +
> > > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > > +
> > > > > > +/ {
> > > > > > + interrupt-parent = <&gic>;
> > > > > > + #address-cells = <2>;
> > > > > > + #size-cells = <2>;
> > > > > > +
> > > > > > + cpus {
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + cpu0: cpu@0 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <0>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu1: cpu@1 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <1>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu2: cpu@2 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <2>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > +
> > > > > > + cpu3: cpu@3 {
> > > > > > + compatible = "arm,cortex-a53";
> > > > > > + device_type = "cpu";
> > > > > > + reg = <3>;
> > > > > > + enable-method = "psci";
> > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > + };
> > > > > > + };
> > > > > > +
> > > > > > + reserved-memory {
> > > > > > + #address-cells = <2>;
> > > > > > + #size-cells = <2>;
> > > > > > + ranges;
> > > > > > +
> > > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > > > + secmon_reserved: secmon@40000000 {
> > > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > > + no-map;
> > > > > > + };
> > > > > > + };
> > > > >
> > > > > I'm not a fan of above. If anything changes in future in BL31, U-Boot
> > > > > would
> > > > > need to reconfigure it anyway. Can we just skip it?
> > > >
> > > > I am not a fan neither, but last time I checked this is needed to boot.
> > > > Indeed TF-A inserts this node, with the right values, into U-Boot's DT.
> > > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > > the kernel as well.
> > > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > > There does not seem to be a global notion of reserved memory in U-Boot.
> > > > Some commands (like tftp) explicitly parse the control DT to find and
> > > > respect reserved memory regions. bootm does that also, but only to
> > > > avoid placing the ramdisk or DTB into reserved memory. The information
> > > > ends up in images->lmb, but is not used to generate or amend nodes in
> > > > the target DT.
> > > > So the bits and pieces are there, but it will require some code to be
> > > > added to the generic U-Boot code.
> > > >
> > > > So what do you think? Leaving this out will prevent loading DTBs into
> > > > U-Boot, at the moment, which sounds bad. I suggest we keep it in, for
> > > > now, it should not really hurt. U-Boot will hopefully start to do the
> > > > right thing soon, then we can either phase it out here (maybe when we
> > > > actually change something in TF-A), or let U-Boot fix it.
> > >
> > > TBH, if "soon" is really soon, I would rather wait with H616 DT until U-
> Boot
> > > supports carrying over reserved memory nodes.
> >
> > But this also carries compatibility issues. U-Boot support the H616 for
> > more than a year now, and the earliest possible U-Boot release having that
> > propagation code would be the one released in October.
>
> I was hoping you would say July (next U-Boot release) :).
Well, 2022.07 was supposed to be released today, and even if that is
delayed by a bit, that's obviously far too late ;-)
> > And then people
> > would still need to update first, so that's quite some months out.
> > And I was actually hoping to get at least the H616 DT patches off my
> > plate, and get them into the tree to have a stable and agreed upon base
> > (before this series turns into a teenager ;-)
>
> Yeah, I would like that too.
>
> > Then we could for instance update the U-Boot H616 support.
> >
> > > Whatever we do now, it will have
> > > compatibility issues. If we introduce reserved memory node now, we can't
> > > easily drop it later. Bootloaders are not very often updated, but kernels
> and
> > > DTB files are, at least in my experience. So when we decide to drop the
> node?
> >
> > I think of the three possibilities:
> > - Drop the node now, and ask people to not load DTBs explicitly
> > - Drop the node when U-Boot learned to propagate the reservation
> > - Keep the node
> > the last one is the least painful: having this node in does not really
> > hurt, so we can be very relaxed with this removal decision:
> > - If U-Boot does not add the reserved node, we are covered.
> > - If U-Boot adds the node, it will do so in a way where it deals with
> > existing reservations. So either it doesn't actually change anything, or
> > it extends the reservation.
> > - Should the TF-A location actually move (and we have no plans or needs to
> > do that), people would only get this by updating the firmware, at which
> > point the U-Boot part would surely be in place already. We don't really
> > support updating just BL31 in an existing binary firmware image, so you
> > would get an updated U-Boot as well.
> >
> > I think the worst case scenario is that users end up with an unneeded 512K
> > reservation. If they care, a firmware update should solve this problem.
> >
> > As for the time to remove that node: we could do that at the time when
> > (or rather: if) we actually change the TF-A reservation. At the moment
> > there are no plans to do this, and the size reservation is more than
> > generous (the current debug build is actually 77 KB or so only). If there
> > is no change, and the node stays in the .dtsi, it doesn't really hurt, see
> > above.
>
> I see your point, but I would like to get some input from Samuel first.
>
> Samuel, what do you think?
>
> >
> > > After 10 years? Alternatively, reserved memory node can be just dropped
> and
> > > anyone loading DTB file from outside would need to make sure it's patched.
> But
> > > that's unexpected from user perspective, although patching DT files is done
> by
> > > some distros.
> >
> > Yeah, let's not go there. As you know, I already dislike the idea of
> > explicitly loading DTBs at all, but I understand this is what people, and
> > distributions, do, so I'd rather have them covered. Hence the node to
> > work with existing firmware.
>
> Reusing DTB from U-Boot is only useful when you're happy with completeness of
> DT and with the lack of bugs in it. Then you can save troubles with skipping
> external DTB load step and life is easier. But as you know, features and thus
> nodes are added in steps and sometimes some bugs are fixed, which means it's
> extremely handy to have easily updatable DTB file.
Yes, definitely, see my reply to Samuel. I just held back with the DT
update in U-Boot because of the conflict between "we only take pure
kernel tree DTs" and "there is a breaking change" (r_intc binding).
If we find a way forward with the DT stability problem, I am happy to
push for a much more frequent DT update, or even update just the DT in
an existing firmware installation. This can be automated, since the DTB
is just a member in the FIT image, which can be re-assembled with an
updated DTB by some tool or script. Or we use capsule updates, of just
the DTB, separately (if this is possible)?
> Yes, U-Boot can be
> automated, but it's tedious for distro to maintain one bootloader package per
> board. Ideally, distro shouldn't care at all about that,
Yes, I totally agree, distros should not ship firmware. Since leaving
this to the board vendors is not realistic, I wonder if we (as "the
sunxi community") should step up here, and provide binary builds (purely
for convenience reasons) of board firmware? That could be updated from
a running Linux, or put on an SD card, or fetched by distros to
generate an installer? Wasn't there even some central storage offered
lately by Linux, to hold (UEFI) firmware update files?
> but many boards don't
> have designated bootloader storage (SPI NOR flash in AW case), so they have to
> be combined on same storage, partition even, as distro.
Have you tried eMMC boot partitions? I found them equally convenient as
SPI flash, and while not too many boards actually have SPI flash,
quite some have eMMC (thinking about TV boxes). I recently even
used "dual boot" with a BSP installation.
And even the smallest eMMCs seem to have 4 MB per boot partition, so
plenty of space for U-Boot (plus TF-A plus crust).
> On the other hand,
> when building kernel, you automatically build all relevant DTB files, which you
> can then just copy to common place. No device specific handling needed. Also,
> U-Boot doesn't sync DT files every release, so latest U-Boot doesn't necessarly
> mean latest DT.
Yes, for the compatibility reasons mentioned. I am more than happy to
make this a regular exercise (say at each kernel's -rc3 or so).
> Above is a bit off topic, but I hope you understand why distros opt to use
> external DTB files (speaking from my own experiences).
Yes, I understand where they (including LE) are coming from, to provide
a pragmatic solution to the users' problems. And that's why I wanted to
still give the possibility to load a DTB, even though I think this
should not be the standard way.
Cheers,
Andre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-04 21:58 ` Andre Przywara
@ 2022-07-05 17:32 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-05 17:32 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
Dne ponedeljek, 04. julij 2022 ob 23:58:02 CEST je Andre Przywara napisal(a):
> On Mon, 04 Jul 2022 20:42:47 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi Jernej,
>
> > Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara
napisal(a):
> > > On Sat, 02 Jul 2022 23:16:53 +0200
> > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > >
> > > Hi Jernej,
> > >
> > > > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara
napisal(a):
> > > > > On Tue, 03 May 2022 21:05:11 +0200
> > > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > > >
> > > > > Hi Jernej,
> > > > >
> > > > > many thanks for taking the time to wade through this file!
> > > > >
> > > > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
> >
> > napisal(a):
> > > > > > > This (relatively) new SoC is similar to the H6, but drops the
> >
> > (broken)
> >
> > > > > > > PCIe support and the USB 3.0 controller. It also gets the
> > > > > > > management
> > > > > > > controller removed, which in turn removes *some*, but not all of
> > > > > > > the
> > > > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > > > And while there is still the extra sunxi interrupt controller,
> > > > > > > the
> > > > > > > package lacks the corresponding NMI pin, so no interrupts for
> > > > > > > the
> >
> > PMIC.
> >
> > > > > > > The reserved memory node is actually handled by Trusted Firmware
> >
> > now,
> >
> > > > > > > but U-Boot fails to propagate this to a separately loaded DTB,
> > > > > > > so we
> > > > > > > keep it in here for now, until U-Boot learns to do this
> > > > > > > properly.
> > > > > > >
> > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > > > ---
> > > > > > >
> > > > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574
> > > > > > > +++++++++++++++
> >
> > +++
> >
> > > > > > > 1 file changed, 574 insertions(+)
> > > > > > > create mode 100644
> > > > > > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > b/arch/arm64/
> > > > > >
> > > > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > > > >
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..cc06cdd15ba5
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > @@ -0,0 +1,574 @@
> > > > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > > > +// based on the H6 dtsi, which is:
> > > > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > > > +
> > > > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > > > +
> > > > > > > +/ {
> > > > > > > + interrupt-parent = <&gic>;
> > > > > > > + #address-cells = <2>;
> > > > > > > + #size-cells = <2>;
> > > > > > > +
> > > > > > > + cpus {
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + cpu0: cpu@0 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <0>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + cpu1: cpu@1 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <1>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + cpu2: cpu@2 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <2>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + cpu3: cpu@3 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <3>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > + };
> > > > > > > +
> > > > > > > + reserved-memory {
> > > > > > > + #address-cells = <2>;
> > > > > > > + #size-cells = <2>;
> > > > > > > + ranges;
> > > > > > > +
> > > > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31)
*/
> > > > > > > + secmon_reserved: secmon@40000000 {
> > > > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > > > + no-map;
> > > > > > > + };
> > > > > > > + };
> > > > > >
> > > > > > I'm not a fan of above. If anything changes in future in BL31,
> > > > > > U-Boot
> > > > > > would
> > > > > > need to reconfigure it anyway. Can we just skip it?
> > > > >
> > > > > I am not a fan neither, but last time I checked this is needed to
> > > > > boot.
> > > > > Indeed TF-A inserts this node, with the right values, into U-Boot's
> > > > > DT.
> > > > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > > > the kernel as well.
> > > > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > > > There does not seem to be a global notion of reserved memory in
> > > > > U-Boot.
> > > > > Some commands (like tftp) explicitly parse the control DT to find
> > > > > and
> > > > > respect reserved memory regions. bootm does that also, but only to
> > > > > avoid placing the ramdisk or DTB into reserved memory. The
> > > > > information
> > > > > ends up in images->lmb, but is not used to generate or amend nodes
> > > > > in
> > > > > the target DT.
> > > > > So the bits and pieces are there, but it will require some code to
> > > > > be
> > > > > added to the generic U-Boot code.
> > > > >
> > > > > So what do you think? Leaving this out will prevent loading DTBs
> > > > > into
> > > > > U-Boot, at the moment, which sounds bad. I suggest we keep it in,
> > > > > for
> > > > > now, it should not really hurt. U-Boot will hopefully start to do
> > > > > the
> > > > > right thing soon, then we can either phase it out here (maybe when
> > > > > we
> > > > > actually change something in TF-A), or let U-Boot fix it.
> > > >
> > > > TBH, if "soon" is really soon, I would rather wait with H616 DT until
> > > > U-
> >
> > Boot
> >
> > > > supports carrying over reserved memory nodes.
> > >
> > > But this also carries compatibility issues. U-Boot support the H616 for
> > > more than a year now, and the earliest possible U-Boot release having
> > > that
> > > propagation code would be the one released in October.
> >
> > I was hoping you would say July (next U-Boot release) :).
>
> Well, 2022.07 was supposed to be released today, and even if that is
> delayed by a bit, that's obviously far too late ;-)
>
> > > And then people
> > > would still need to update first, so that's quite some months out.
> > > And I was actually hoping to get at least the H616 DT patches off my
> > > plate, and get them into the tree to have a stable and agreed upon base
> > > (before this series turns into a teenager ;-)
> >
> > Yeah, I would like that too.
> >
> > > Then we could for instance update the U-Boot H616 support.
> > >
> > > > Whatever we do now, it will have
> > > > compatibility issues. If we introduce reserved memory node now, we
> > > > can't
> > > > easily drop it later. Bootloaders are not very often updated, but
> > > > kernels
> >
> > and
> >
> > > > DTB files are, at least in my experience. So when we decide to drop
> > > > the
> >
> > node?
> >
> > > I think of the three possibilities:
> > > - Drop the node now, and ask people to not load DTBs explicitly
> > > - Drop the node when U-Boot learned to propagate the reservation
> > > - Keep the node
> > > the last one is the least painful: having this node in does not really
> > > hurt, so we can be very relaxed with this removal decision:
> > > - If U-Boot does not add the reserved node, we are covered.
> > > - If U-Boot adds the node, it will do so in a way where it deals with
> > > existing reservations. So either it doesn't actually change anything, or
> > > it extends the reservation.
> > > - Should the TF-A location actually move (and we have no plans or needs
> > > to
> > > do that), people would only get this by updating the firmware, at which
> > > point the U-Boot part would surely be in place already. We don't really
> > > support updating just BL31 in an existing binary firmware image, so you
> > > would get an updated U-Boot as well.
> > >
> > > I think the worst case scenario is that users end up with an unneeded
> > > 512K
> > > reservation. If they care, a firmware update should solve this problem.
> > >
> > > As for the time to remove that node: we could do that at the time when
> > > (or rather: if) we actually change the TF-A reservation. At the moment
> > > there are no plans to do this, and the size reservation is more than
> > > generous (the current debug build is actually 77 KB or so only). If
> > > there
> > > is no change, and the node stays in the .dtsi, it doesn't really hurt,
> > > see
> > > above.
> >
> > I see your point, but I would like to get some input from Samuel first.
> >
> > Samuel, what do you think?
> >
> > > > After 10 years? Alternatively, reserved memory node can be just
> > > > dropped
> >
> > and
> >
> > > > anyone loading DTB file from outside would need to make sure it's
> > > > patched.
> >
> > But
> >
> > > > that's unexpected from user perspective, although patching DT files is
> > > > done
> >
> > by
> >
> > > > some distros.
> > >
> > > Yeah, let's not go there. As you know, I already dislike the idea of
> > > explicitly loading DTBs at all, but I understand this is what people,
> > > and
> > > distributions, do, so I'd rather have them covered. Hence the node to
> > > work with existing firmware.
> >
> > Reusing DTB from U-Boot is only useful when you're happy with completeness
> > of DT and with the lack of bugs in it. Then you can save troubles with
> > skipping external DTB load step and life is easier. But as you know,
> > features and thus nodes are added in steps and sometimes some bugs are
> > fixed, which means it's extremely handy to have easily updatable DTB
> > file.
>
> Yes, definitely, see my reply to Samuel. I just held back with the DT
> update in U-Boot because of the conflict between "we only take pure
> kernel tree DTs" and "there is a breaking change" (r_intc binding).
>
> If we find a way forward with the DT stability problem, I am happy to
> push for a much more frequent DT update, or even update just the DT in
> an existing firmware installation. This can be automated, since the DTB
> is just a member in the FIT image, which can be re-assembled with an
> updated DTB by some tool or script. Or we use capsule updates, of just
> the DTB, separately (if this is possible)?
I would like to have forward compatibility too, but IMO it's not very
realistic. Sooner or later we'll find something, like r_intc, again that won't
be possible to integrate in forward compatible manner.
>
> > Yes, U-Boot can be
> > automated, but it's tedious for distro to maintain one bootloader package
> > per board. Ideally, distro shouldn't care at all about that,
>
> Yes, I totally agree, distros should not ship firmware. Since leaving
> this to the board vendors is not realistic, I wonder if we (as "the
> sunxi community") should step up here, and provide binary builds (purely
> for convenience reasons) of board firmware? That could be updated from
> a running Linux, or put on an SD card, or fetched by distros to
> generate an installer? Wasn't there even some central storage offered
> lately by Linux, to hold (UEFI) firmware update files?
As someone who's working on distro which supports many SoCs from variety of
vendors, I can tell you that we'll ship bootloader integrated into our image
for years to come. Anyway, I also like to build U-Boot using my own options.
For example, I disable HDMI driver for A64, H3 and H5, because it turns out
that at least on H5, it can clash with Linux driver. Other distros prefer to
show some splash screen, etc. One size fits all solution doesn't seems
realistic to me. Maybe only if *everything* would be configurable and there
would be a way for distro to preconfigure it.
TBH, building U-Boot, Crust and TF-A is easy and ability to customize them is
very handy.
>
> > but many boards don't
> > have designated bootloader storage (SPI NOR flash in AW case), so they
> > have to be combined on same storage, partition even, as distro.
>
> Have you tried eMMC boot partitions? I found them equally convenient as
> SPI flash, and while not too many boards actually have SPI flash,
> quite some have eMMC (thinking about TV boxes). I recently even
> used "dual boot" with a BSP installation.
> And even the smallest eMMCs seem to have 4 MB per boot partition, so
> plenty of space for U-Boot (plus TF-A plus crust).
No, I didn't. I don't see any benefit of using eMMC boot partition over
treating eMMC as usual SD card and installing bootloader to sector 16.
Anyway, that won't change situation at all. SD card image with integrated
bootloader is still king. There are several reasons for that:
- cheapest boards are most popular and usually have only SD card for storage
(think OrangePi PC). There is nothing that you can do about it, except
including bootloader on SD card image.
- if you want to switch from Android to our distro, you need bootable SD card
due to higher boot priority (speaking for AW SoCs)
- not everyone wants to overwrite eMMC. Some prefer keeping Android, so it can
be used later for whatever purpose.
- some users have several distros for same board, each on it's own SD card.
Needless to say, each distro adjusted bootloader to its needs.
I like to offer flexibility in boot options, especially because it's currently
easy, thanks to integrated customized bootloader and external loading of dtb
files :)
>
> > On the other hand,
> > when building kernel, you automatically build all relevant DTB files,
> > which you can then just copy to common place. No device specific handling
> > needed. Also, U-Boot doesn't sync DT files every release, so latest
> > U-Boot doesn't necessarly mean latest DT.
>
> Yes, for the compatibility reasons mentioned. I am more than happy to
> make this a regular exercise (say at each kernel's -rc3 or so).
What about breaking changes? They can be important for new, useful
functionality but older kernels won't know what to do.
> Sadly, I don't think we're even close to avoiding shipping bootloader in
distro images or even external DTB loading.
> > Above is a bit off topic, but I hope you understand why distros opt to use
> > external DTB files (speaking from my own experiences).
>
> Yes, I understand where they (including LE) are coming from, to provide
> a pragmatic solution to the users' problems. And that's why I wanted to
> still give the possibility to load a DTB, even though I think this
> should not be the standard way.
I think loading external DTB support is important and shouldn't be ditched
anytime soon. If I understand correctly, that's an issue only on SoCs with TF-
A, which means only 64-bit AW SoCs. Yes, 32-bit AW SoCs are still a thing and
still used and no, I don't want TF-A there :).
Best regards,
Jernej
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-05 17:32 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-05 17:32 UTC (permalink / raw)
To: Andre Przywara
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
Dne ponedeljek, 04. julij 2022 ob 23:58:02 CEST je Andre Przywara napisal(a):
> On Mon, 04 Jul 2022 20:42:47 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi Jernej,
>
> > Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara
napisal(a):
> > > On Sat, 02 Jul 2022 23:16:53 +0200
> > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > >
> > > Hi Jernej,
> > >
> > > > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara
napisal(a):
> > > > > On Tue, 03 May 2022 21:05:11 +0200
> > > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > > >
> > > > > Hi Jernej,
> > > > >
> > > > > many thanks for taking the time to wade through this file!
> > > > >
> > > > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
> >
> > napisal(a):
> > > > > > > This (relatively) new SoC is similar to the H6, but drops the
> >
> > (broken)
> >
> > > > > > > PCIe support and the USB 3.0 controller. It also gets the
> > > > > > > management
> > > > > > > controller removed, which in turn removes *some*, but not all of
> > > > > > > the
> > > > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > > > And while there is still the extra sunxi interrupt controller,
> > > > > > > the
> > > > > > > package lacks the corresponding NMI pin, so no interrupts for
> > > > > > > the
> >
> > PMIC.
> >
> > > > > > > The reserved memory node is actually handled by Trusted Firmware
> >
> > now,
> >
> > > > > > > but U-Boot fails to propagate this to a separately loaded DTB,
> > > > > > > so we
> > > > > > > keep it in here for now, until U-Boot learns to do this
> > > > > > > properly.
> > > > > > >
> > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > > > ---
> > > > > > >
> > > > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574
> > > > > > > +++++++++++++++
> >
> > +++
> >
> > > > > > > 1 file changed, 574 insertions(+)
> > > > > > > create mode 100644
> > > > > > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > b/arch/arm64/
> > > > > >
> > > > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > > > >
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..cc06cdd15ba5
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > @@ -0,0 +1,574 @@
> > > > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > > > +// based on the H6 dtsi, which is:
> > > > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > > > +
> > > > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > > > +
> > > > > > > +/ {
> > > > > > > + interrupt-parent = <&gic>;
> > > > > > > + #address-cells = <2>;
> > > > > > > + #size-cells = <2>;
> > > > > > > +
> > > > > > > + cpus {
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + cpu0: cpu@0 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <0>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + cpu1: cpu@1 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <1>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + cpu2: cpu@2 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <2>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + cpu3: cpu@3 {
> > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > + device_type = "cpu";
> > > > > > > + reg = <3>;
> > > > > > > + enable-method = "psci";
> > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > + };
> > > > > > > + };
> > > > > > > +
> > > > > > > + reserved-memory {
> > > > > > > + #address-cells = <2>;
> > > > > > > + #size-cells = <2>;
> > > > > > > + ranges;
> > > > > > > +
> > > > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31)
*/
> > > > > > > + secmon_reserved: secmon@40000000 {
> > > > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > > > + no-map;
> > > > > > > + };
> > > > > > > + };
> > > > > >
> > > > > > I'm not a fan of above. If anything changes in future in BL31,
> > > > > > U-Boot
> > > > > > would
> > > > > > need to reconfigure it anyway. Can we just skip it?
> > > > >
> > > > > I am not a fan neither, but last time I checked this is needed to
> > > > > boot.
> > > > > Indeed TF-A inserts this node, with the right values, into U-Boot's
> > > > > DT.
> > > > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > > > the kernel as well.
> > > > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > > > There does not seem to be a global notion of reserved memory in
> > > > > U-Boot.
> > > > > Some commands (like tftp) explicitly parse the control DT to find
> > > > > and
> > > > > respect reserved memory regions. bootm does that also, but only to
> > > > > avoid placing the ramdisk or DTB into reserved memory. The
> > > > > information
> > > > > ends up in images->lmb, but is not used to generate or amend nodes
> > > > > in
> > > > > the target DT.
> > > > > So the bits and pieces are there, but it will require some code to
> > > > > be
> > > > > added to the generic U-Boot code.
> > > > >
> > > > > So what do you think? Leaving this out will prevent loading DTBs
> > > > > into
> > > > > U-Boot, at the moment, which sounds bad. I suggest we keep it in,
> > > > > for
> > > > > now, it should not really hurt. U-Boot will hopefully start to do
> > > > > the
> > > > > right thing soon, then we can either phase it out here (maybe when
> > > > > we
> > > > > actually change something in TF-A), or let U-Boot fix it.
> > > >
> > > > TBH, if "soon" is really soon, I would rather wait with H616 DT until
> > > > U-
> >
> > Boot
> >
> > > > supports carrying over reserved memory nodes.
> > >
> > > But this also carries compatibility issues. U-Boot support the H616 for
> > > more than a year now, and the earliest possible U-Boot release having
> > > that
> > > propagation code would be the one released in October.
> >
> > I was hoping you would say July (next U-Boot release) :).
>
> Well, 2022.07 was supposed to be released today, and even if that is
> delayed by a bit, that's obviously far too late ;-)
>
> > > And then people
> > > would still need to update first, so that's quite some months out.
> > > And I was actually hoping to get at least the H616 DT patches off my
> > > plate, and get them into the tree to have a stable and agreed upon base
> > > (before this series turns into a teenager ;-)
> >
> > Yeah, I would like that too.
> >
> > > Then we could for instance update the U-Boot H616 support.
> > >
> > > > Whatever we do now, it will have
> > > > compatibility issues. If we introduce reserved memory node now, we
> > > > can't
> > > > easily drop it later. Bootloaders are not very often updated, but
> > > > kernels
> >
> > and
> >
> > > > DTB files are, at least in my experience. So when we decide to drop
> > > > the
> >
> > node?
> >
> > > I think of the three possibilities:
> > > - Drop the node now, and ask people to not load DTBs explicitly
> > > - Drop the node when U-Boot learned to propagate the reservation
> > > - Keep the node
> > > the last one is the least painful: having this node in does not really
> > > hurt, so we can be very relaxed with this removal decision:
> > > - If U-Boot does not add the reserved node, we are covered.
> > > - If U-Boot adds the node, it will do so in a way where it deals with
> > > existing reservations. So either it doesn't actually change anything, or
> > > it extends the reservation.
> > > - Should the TF-A location actually move (and we have no plans or needs
> > > to
> > > do that), people would only get this by updating the firmware, at which
> > > point the U-Boot part would surely be in place already. We don't really
> > > support updating just BL31 in an existing binary firmware image, so you
> > > would get an updated U-Boot as well.
> > >
> > > I think the worst case scenario is that users end up with an unneeded
> > > 512K
> > > reservation. If they care, a firmware update should solve this problem.
> > >
> > > As for the time to remove that node: we could do that at the time when
> > > (or rather: if) we actually change the TF-A reservation. At the moment
> > > there are no plans to do this, and the size reservation is more than
> > > generous (the current debug build is actually 77 KB or so only). If
> > > there
> > > is no change, and the node stays in the .dtsi, it doesn't really hurt,
> > > see
> > > above.
> >
> > I see your point, but I would like to get some input from Samuel first.
> >
> > Samuel, what do you think?
> >
> > > > After 10 years? Alternatively, reserved memory node can be just
> > > > dropped
> >
> > and
> >
> > > > anyone loading DTB file from outside would need to make sure it's
> > > > patched.
> >
> > But
> >
> > > > that's unexpected from user perspective, although patching DT files is
> > > > done
> >
> > by
> >
> > > > some distros.
> > >
> > > Yeah, let's not go there. As you know, I already dislike the idea of
> > > explicitly loading DTBs at all, but I understand this is what people,
> > > and
> > > distributions, do, so I'd rather have them covered. Hence the node to
> > > work with existing firmware.
> >
> > Reusing DTB from U-Boot is only useful when you're happy with completeness
> > of DT and with the lack of bugs in it. Then you can save troubles with
> > skipping external DTB load step and life is easier. But as you know,
> > features and thus nodes are added in steps and sometimes some bugs are
> > fixed, which means it's extremely handy to have easily updatable DTB
> > file.
>
> Yes, definitely, see my reply to Samuel. I just held back with the DT
> update in U-Boot because of the conflict between "we only take pure
> kernel tree DTs" and "there is a breaking change" (r_intc binding).
>
> If we find a way forward with the DT stability problem, I am happy to
> push for a much more frequent DT update, or even update just the DT in
> an existing firmware installation. This can be automated, since the DTB
> is just a member in the FIT image, which can be re-assembled with an
> updated DTB by some tool or script. Or we use capsule updates, of just
> the DTB, separately (if this is possible)?
I would like to have forward compatibility too, but IMO it's not very
realistic. Sooner or later we'll find something, like r_intc, again that won't
be possible to integrate in forward compatible manner.
>
> > Yes, U-Boot can be
> > automated, but it's tedious for distro to maintain one bootloader package
> > per board. Ideally, distro shouldn't care at all about that,
>
> Yes, I totally agree, distros should not ship firmware. Since leaving
> this to the board vendors is not realistic, I wonder if we (as "the
> sunxi community") should step up here, and provide binary builds (purely
> for convenience reasons) of board firmware? That could be updated from
> a running Linux, or put on an SD card, or fetched by distros to
> generate an installer? Wasn't there even some central storage offered
> lately by Linux, to hold (UEFI) firmware update files?
As someone who's working on distro which supports many SoCs from variety of
vendors, I can tell you that we'll ship bootloader integrated into our image
for years to come. Anyway, I also like to build U-Boot using my own options.
For example, I disable HDMI driver for A64, H3 and H5, because it turns out
that at least on H5, it can clash with Linux driver. Other distros prefer to
show some splash screen, etc. One size fits all solution doesn't seems
realistic to me. Maybe only if *everything* would be configurable and there
would be a way for distro to preconfigure it.
TBH, building U-Boot, Crust and TF-A is easy and ability to customize them is
very handy.
>
> > but many boards don't
> > have designated bootloader storage (SPI NOR flash in AW case), so they
> > have to be combined on same storage, partition even, as distro.
>
> Have you tried eMMC boot partitions? I found them equally convenient as
> SPI flash, and while not too many boards actually have SPI flash,
> quite some have eMMC (thinking about TV boxes). I recently even
> used "dual boot" with a BSP installation.
> And even the smallest eMMCs seem to have 4 MB per boot partition, so
> plenty of space for U-Boot (plus TF-A plus crust).
No, I didn't. I don't see any benefit of using eMMC boot partition over
treating eMMC as usual SD card and installing bootloader to sector 16.
Anyway, that won't change situation at all. SD card image with integrated
bootloader is still king. There are several reasons for that:
- cheapest boards are most popular and usually have only SD card for storage
(think OrangePi PC). There is nothing that you can do about it, except
including bootloader on SD card image.
- if you want to switch from Android to our distro, you need bootable SD card
due to higher boot priority (speaking for AW SoCs)
- not everyone wants to overwrite eMMC. Some prefer keeping Android, so it can
be used later for whatever purpose.
- some users have several distros for same board, each on it's own SD card.
Needless to say, each distro adjusted bootloader to its needs.
I like to offer flexibility in boot options, especially because it's currently
easy, thanks to integrated customized bootloader and external loading of dtb
files :)
>
> > On the other hand,
> > when building kernel, you automatically build all relevant DTB files,
> > which you can then just copy to common place. No device specific handling
> > needed. Also, U-Boot doesn't sync DT files every release, so latest
> > U-Boot doesn't necessarly mean latest DT.
>
> Yes, for the compatibility reasons mentioned. I am more than happy to
> make this a regular exercise (say at each kernel's -rc3 or so).
What about breaking changes? They can be important for new, useful
functionality but older kernels won't know what to do.
> Sadly, I don't think we're even close to avoiding shipping bootloader in
distro images or even external DTB loading.
> > Above is a bit off topic, but I hope you understand why distros opt to use
> > external DTB files (speaking from my own experiences).
>
> Yes, I understand where they (including LE) are coming from, to provide
> a pragmatic solution to the users' problems. And that's why I wanted to
> still give the possibility to load a DTB, even though I think this
> should not be the standard way.
I think loading external DTB support is important and shouldn't be ditched
anytime soon. If I understand correctly, that's an issue only on SoCs with TF-
A, which means only 64-bit AW SoCs. Yes, 32-bit AW SoCs are still a thing and
still used and no, I don't want TF-A there :).
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-05 17:32 ` Jernej Škrabec
@ 2022-07-06 13:16 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-06 13:16 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Tue, 05 Jul 2022 19:32:26 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
so after seemingly having finished writing this email, I realised that
this won't really help, as I think this diverts the discussion. And the
problem has been around for a while, and won't probably be solved easily
or quickly. I think we agree to disagree here, or we should admit that
there are different approaches ("bundled firmware" vs. "UEFI"), so in the
interest of not blocking the H616 series:
Shall I just keep the firmware node? This would work both ways, whereas
dropping the node would impede the "bundled firmware" approach?
Answers and replies, as mentioned going potentially a bit off-topic, below.
> Dne ponedeljek, 04. julij 2022 ob 23:58:02 CEST je Andre Przywara napisal(a):
> > On Mon, 04 Jul 2022 20:42:47 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > > Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara
> napisal(a):
> > > > On Sat, 02 Jul 2022 23:16:53 +0200
> > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > >
> > > > Hi Jernej,
> > > >
> > > > > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara
> napisal(a):
> > > > > > On Tue, 03 May 2022 21:05:11 +0200
> > > > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > > > >
> > > > > > Hi Jernej,
> > > > > >
> > > > > > many thanks for taking the time to wade through this file!
> > > > > >
> > > > > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
> > >
> > > napisal(a):
> > > > > > > > This (relatively) new SoC is similar to the H6, but drops the
> > >
> > > (broken)
> > >
> > > > > > > > PCIe support and the USB 3.0 controller. It also gets the
> > > > > > > > management
> > > > > > > > controller removed, which in turn removes *some*, but not all of
> > > > > > > > the
> > > > > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > > > > And while there is still the extra sunxi interrupt controller,
> > > > > > > > the
> > > > > > > > package lacks the corresponding NMI pin, so no interrupts for
> > > > > > > > the
> > >
> > > PMIC.
> > >
> > > > > > > > The reserved memory node is actually handled by Trusted Firmware
> > >
> > > now,
> > >
> > > > > > > > but U-Boot fails to propagate this to a separately loaded DTB,
> > > > > > > > so we
> > > > > > > > keep it in here for now, until U-Boot learns to do this
> > > > > > > > properly.
> > > > > > > >
> > > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574
> > > > > > > > +++++++++++++++
> > >
> > > +++
> > >
> > > > > > > > 1 file changed, 574 insertions(+)
> > > > > > > > create mode 100644
> > > > > > > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > > b/arch/arm64/
> > > > > > >
> > > > > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > >
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..cc06cdd15ba5
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > > @@ -0,0 +1,574 @@
> > > > > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > > > > +// based on the H6 dtsi, which is:
> > > > > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > > > > +
> > > > > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > + interrupt-parent = <&gic>;
> > > > > > > > + #address-cells = <2>;
> > > > > > > > + #size-cells = <2>;
> > > > > > > > +
> > > > > > > > + cpus {
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <0>;
> > > > > > > > +
> > > > > > > > + cpu0: cpu@0 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <0>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu1: cpu@1 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <1>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu2: cpu@2 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <2>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu3: cpu@3 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <3>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + reserved-memory {
> > > > > > > > + #address-cells = <2>;
> > > > > > > > + #size-cells = <2>;
> > > > > > > > + ranges;
> > > > > > > > +
> > > > > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31)
> */
> > > > > > > > + secmon_reserved: secmon@40000000 {
> > > > > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > > > > + no-map;
> > > > > > > > + };
> > > > > > > > + };
> > > > > > >
> > > > > > > I'm not a fan of above. If anything changes in future in BL31,
> > > > > > > U-Boot
> > > > > > > would
> > > > > > > need to reconfigure it anyway. Can we just skip it?
> > > > > >
> > > > > > I am not a fan neither, but last time I checked this is needed to
> > > > > > boot.
> > > > > > Indeed TF-A inserts this node, with the right values, into U-Boot's
> > > > > > DT.
> > > > > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > > > > the kernel as well.
> > > > > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > > > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > > > > There does not seem to be a global notion of reserved memory in
> > > > > > U-Boot.
> > > > > > Some commands (like tftp) explicitly parse the control DT to find
> > > > > > and
> > > > > > respect reserved memory regions. bootm does that also, but only to
> > > > > > avoid placing the ramdisk or DTB into reserved memory. The
> > > > > > information
> > > > > > ends up in images->lmb, but is not used to generate or amend nodes
> > > > > > in
> > > > > > the target DT.
> > > > > > So the bits and pieces are there, but it will require some code to
> > > > > > be
> > > > > > added to the generic U-Boot code.
> > > > > >
> > > > > > So what do you think? Leaving this out will prevent loading DTBs
> > > > > > into
> > > > > > U-Boot, at the moment, which sounds bad. I suggest we keep it in,
> > > > > > for
> > > > > > now, it should not really hurt. U-Boot will hopefully start to do
> > > > > > the
> > > > > > right thing soon, then we can either phase it out here (maybe when
> > > > > > we
> > > > > > actually change something in TF-A), or let U-Boot fix it.
> > > > >
> > > > > TBH, if "soon" is really soon, I would rather wait with H616 DT until
> > > > > U-
> > >
> > > Boot
> > >
> > > > > supports carrying over reserved memory nodes.
> > > >
> > > > But this also carries compatibility issues. U-Boot support the H616 for
> > > > more than a year now, and the earliest possible U-Boot release having
> > > > that
> > > > propagation code would be the one released in October.
> > >
> > > I was hoping you would say July (next U-Boot release) :).
> >
> > Well, 2022.07 was supposed to be released today, and even if that is
> > delayed by a bit, that's obviously far too late ;-)
> >
> > > > And then people
> > > > would still need to update first, so that's quite some months out.
> > > > And I was actually hoping to get at least the H616 DT patches off my
> > > > plate, and get them into the tree to have a stable and agreed upon base
> > > > (before this series turns into a teenager ;-)
> > >
> > > Yeah, I would like that too.
> > >
> > > > Then we could for instance update the U-Boot H616 support.
> > > >
> > > > > Whatever we do now, it will have
> > > > > compatibility issues. If we introduce reserved memory node now, we
> > > > > can't
> > > > > easily drop it later. Bootloaders are not very often updated, but
> > > > > kernels
> > >
> > > and
> > >
> > > > > DTB files are, at least in my experience. So when we decide to drop
> > > > > the
> > >
> > > node?
> > >
> > > > I think of the three possibilities:
> > > > - Drop the node now, and ask people to not load DTBs explicitly
> > > > - Drop the node when U-Boot learned to propagate the reservation
> > > > - Keep the node
> > > > the last one is the least painful: having this node in does not really
> > > > hurt, so we can be very relaxed with this removal decision:
> > > > - If U-Boot does not add the reserved node, we are covered.
> > > > - If U-Boot adds the node, it will do so in a way where it deals with
> > > > existing reservations. So either it doesn't actually change anything, or
> > > > it extends the reservation.
> > > > - Should the TF-A location actually move (and we have no plans or needs
> > > > to
> > > > do that), people would only get this by updating the firmware, at which
> > > > point the U-Boot part would surely be in place already. We don't really
> > > > support updating just BL31 in an existing binary firmware image, so you
> > > > would get an updated U-Boot as well.
> > > >
> > > > I think the worst case scenario is that users end up with an unneeded
> > > > 512K
> > > > reservation. If they care, a firmware update should solve this problem.
> > > >
> > > > As for the time to remove that node: we could do that at the time when
> > > > (or rather: if) we actually change the TF-A reservation. At the moment
> > > > there are no plans to do this, and the size reservation is more than
> > > > generous (the current debug build is actually 77 KB or so only). If
> > > > there
> > > > is no change, and the node stays in the .dtsi, it doesn't really hurt,
> > > > see
> > > > above.
> > >
> > > I see your point, but I would like to get some input from Samuel first.
> > >
> > > Samuel, what do you think?
> > >
> > > > > After 10 years? Alternatively, reserved memory node can be just
> > > > > dropped
> > >
> > > and
> > >
> > > > > anyone loading DTB file from outside would need to make sure it's
> > > > > patched.
> > >
> > > But
> > >
> > > > > that's unexpected from user perspective, although patching DT files is
> > > > > done
> > >
> > > by
> > >
> > > > > some distros.
> > > >
> > > > Yeah, let's not go there. As you know, I already dislike the idea of
> > > > explicitly loading DTBs at all, but I understand this is what people,
> > > > and
> > > > distributions, do, so I'd rather have them covered. Hence the node to
> > > > work with existing firmware.
> > >
> > > Reusing DTB from U-Boot is only useful when you're happy with completeness
> > > of DT and with the lack of bugs in it. Then you can save troubles with
> > > skipping external DTB load step and life is easier. But as you know,
> > > features and thus nodes are added in steps and sometimes some bugs are
> > > fixed, which means it's extremely handy to have easily updatable DTB
> > > file.
> >
> > Yes, definitely, see my reply to Samuel. I just held back with the DT
> > update in U-Boot because of the conflict between "we only take pure
> > kernel tree DTs" and "there is a breaking change" (r_intc binding).
> >
> > If we find a way forward with the DT stability problem, I am happy to
> > push for a much more frequent DT update, or even update just the DT in
> > an existing firmware installation. This can be automated, since the DTB
> > is just a member in the FIT image, which can be re-assembled with an
> > updated DTB by some tool or script. Or we use capsule updates, of just
> > the DTB, separately (if this is possible)?
>
> I would like to have forward compatibility too, but IMO it's not very
> realistic. Sooner or later we'll find something, like r_intc, again that won't
> be possible to integrate in forward compatible manner.
That's a shame, I think we should at least try. And with my x86 background
let me tell you: there are solutions to those compatibility problems ;-)
The more nasty ones might be borderline hackish, but it's a question of
priorities, I guess.
> > > Yes, U-Boot can be
> > > automated, but it's tedious for distro to maintain one bootloader package
> > > per board. Ideally, distro shouldn't care at all about that,
> >
> > Yes, I totally agree, distros should not ship firmware. Since leaving
> > this to the board vendors is not realistic, I wonder if we (as "the
> > sunxi community") should step up here, and provide binary builds (purely
> > for convenience reasons) of board firmware? That could be updated from
> > a running Linux, or put on an SD card, or fetched by distros to
> > generate an installer? Wasn't there even some central storage offered
> > lately by Linux, to hold (UEFI) firmware update files?
>
> As someone who's working on distro which supports many SoCs from variety of
> vendors,
But that is relative, isn't it? I count 23 supported Allwinner devices in
LibreELEC, out of the 160 defconfigs in U-Boot or >180 sunxi .dts files in
the kernel.
So as most distributions, even with your ARM device focus, you chose to
limit the number of supported devices, as that approach inherently
doesn't scale.
I see the reasons behind this, because of the special focus of LibreELEC,
and probably the idea of giving a smooth user experience, but you could
potentially cover much more devices by offering a generic UEFI image, as
most *generic* distributions do, and as LE does for x86. But this relies
on having a stable DT for the platform.
I think conceptually this problem has been solved a long time ago: there
is some interface between firmware and the kernel, which allows a generic
kernel to configure itself accordingly. I refuse the idea that Arm based
device should be any different in this respect. Historically, because many
Arm based machines have a strong embedded background, that was not the
case, but I think we should move on from those dark ages (in terms of
support and maintainability).
> I can tell you that we'll ship bootloader integrated into our image
> for years to come. Anyway, I also like to build U-Boot using my own options.
> For example, I disable HDMI driver for A64, H3 and H5, because it turns out
> that at least on H5, it can clash with Linux driver.
That is good to hear, please tell the sunxi U-Boot maintainer, so that we
can fix it ;-)
> Other distros prefer to
> show some splash screen, etc. One size fits all solution doesn't seems
> realistic to me. Maybe only if *everything* would be configurable and there
> would be a way for distro to preconfigure it.
>
> TBH, building U-Boot, Crust and TF-A is easy and ability to customize them is
> very handy.
> > > but many boards don't
> > > have designated bootloader storage (SPI NOR flash in AW case), so they
> > > have to be combined on same storage, partition even, as distro.
> >
> > Have you tried eMMC boot partitions? I found them equally convenient as
> > SPI flash, and while not too many boards actually have SPI flash,
> > quite some have eMMC (thinking about TV boxes). I recently even
> > used "dual boot" with a BSP installation.
> > And even the smallest eMMCs seem to have 4 MB per boot partition, so
> > plenty of space for U-Boot (plus TF-A plus crust).
>
> No, I didn't. I don't see any benefit of using eMMC boot partition over
> treating eMMC as usual SD card and installing bootloader to sector 16.
The firmware is out of the way of normal (accidental) accesses, as it
lives in a separate block device, which is read-only, initially.
And it doesn't clash with partition tables. This gives the kind of
separation that people are used to on other computers: the firmware
belongs to the device, the OS is provided by the user.
We documented how to install firmware there in U-Boot's sunxi.rst.
> Anyway, that won't change situation at all. SD card image with integrated
> bootloader is still king.
Sure, if you don't have any other storage, then SD card it is. But this
still does not require marrying firmware and OS: you could start with a
"just firmware SD card", then install the OS from a USB device, or from a
generic image file copied to some SD partition. And then suddenly the
pure firmware image becomes OS/distro agnostic.
And conceptually this approach doesn't *prevent* separating firmware and
kernel/distro, it just allows you to get away with it.
> There are several reasons for that:
> - cheapest boards are most popular and usually have only SD card for storage
> (think OrangePi PC). There is nothing that you can do about it, except
> including bootloader on SD card image.
> - if you want to switch from Android to our distro, you need bootable SD card
> due to higher boot priority (speaking for AW SoCs)
> - not everyone wants to overwrite eMMC. Some prefer keeping Android, so it can
> be used later for whatever purpose.
> - some users have several distros for same board, each on it's own SD card.
> Needless to say, each distro adjusted bootloader to its needs.
All fine, but I don't see how this affects this discussion here. Yes, you
can treat those machines like embedded devices, and bundle firmware and
OS, but this is surely not the only way of deployment we should support.
Being able to just offer one generic UEFI based image seems much more
scalable to me.
> I like to offer flexibility in boot options, especially because it's currently
> easy, thanks to integrated customized bootloader and external loading of dtb
> files :)
Though I don't understand why you require external DTB loading: if you
marry distro and firmware anyway, you could as well put your DTB of choice
into U-Boot (in the U-Boot source tree, or replace it in the generated FIT
image). That looks like a one-time effort in your build system?
> > > On the other hand,
> > > when building kernel, you automatically build all relevant DTB files,
> > > which you can then just copy to common place. No device specific handling
> > > needed. Also, U-Boot doesn't sync DT files every release, so latest
> > > U-Boot doesn't necessarly mean latest DT.
> >
> > Yes, for the compatibility reasons mentioned. I am more than happy to
> > make this a regular exercise (say at each kernel's -rc3 or so).
>
> What about breaking changes? They can be important for new, useful
> functionality but older kernels won't know what to do.
Yes, that is the core of this discussion. Doing this relies on not having
them in the first place. There is no problem when this affects new
features, or functionality that the old kernel didn't support anyway.
But we must avoid change affecting older kernels.
At least I would like to ask for us to try: in my experience with some
thinking and clever code we can pull this off. Other platforms seem to be
able to commit to this.
As a compromise, I was wondering if we should define some time of grace
period, initially, were we don't guarantee non-breaking changes only.
So the first, say three, kernels could include breaking changes, but
afterwards we stick to support at least this kernel, with every new DT to
come.
> > Sadly, I don't think we're even close to avoiding shipping bootloader in
> distro images or even external DTB loading.
> > > Above is a bit off topic, but I hope you understand why distros opt to use
> > > external DTB files (speaking from my own experiences).
> >
> > Yes, I understand where they (including LE) are coming from, to provide
> > a pragmatic solution to the users' problems. And that's why I wanted to
> > still give the possibility to load a DTB, even though I think this
> > should not be the standard way.
>
> I think loading external DTB support is important and shouldn't be ditched
> anytime soon. If I understand correctly, that's an issue only on SoCs with TF-
> A, which means only 64-bit AW SoCs. Yes, 32-bit AW SoCs are still a thing and
> still used and no, I don't want TF-A there :).
I think it's a conceptual issue, not TF-A related: A DT was always meant
to be amended by firmware (think of the memory node, or the MAC address).
U-Boot just decided to make those changes very late, just before launching
the kernel, so that this newly loaded DTB is already available. But if the
SPL decides to make changes, or picks a certain DT, you have this problem
as well.
Cheers,
Andre
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-06 13:16 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-06 13:16 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Samuel Holland, Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski,
Icenowy Zheng, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel
On Tue, 05 Jul 2022 19:32:26 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
Hi Jernej,
so after seemingly having finished writing this email, I realised that
this won't really help, as I think this diverts the discussion. And the
problem has been around for a while, and won't probably be solved easily
or quickly. I think we agree to disagree here, or we should admit that
there are different approaches ("bundled firmware" vs. "UEFI"), so in the
interest of not blocking the H616 series:
Shall I just keep the firmware node? This would work both ways, whereas
dropping the node would impede the "bundled firmware" approach?
Answers and replies, as mentioned going potentially a bit off-topic, below.
> Dne ponedeljek, 04. julij 2022 ob 23:58:02 CEST je Andre Przywara napisal(a):
> > On Mon, 04 Jul 2022 20:42:47 +0200
> > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Hi Jernej,
> >
> > > Dne ponedeljek, 04. julij 2022 ob 15:30:57 CEST je Andre Przywara
> napisal(a):
> > > > On Sat, 02 Jul 2022 23:16:53 +0200
> > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > >
> > > > Hi Jernej,
> > > >
> > > > > Dne četrtek, 30. junij 2022 ob 02:04:10 CEST je Andre Przywara
> napisal(a):
> > > > > > On Tue, 03 May 2022 21:05:11 +0200
> > > > > > Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > > > >
> > > > > > Hi Jernej,
> > > > > >
> > > > > > many thanks for taking the time to wade through this file!
> > > > > >
> > > > > > > Dne petek, 29. april 2022 ob 01:09:30 CEST je Andre Przywara
> > >
> > > napisal(a):
> > > > > > > > This (relatively) new SoC is similar to the H6, but drops the
> > >
> > > (broken)
> > >
> > > > > > > > PCIe support and the USB 3.0 controller. It also gets the
> > > > > > > > management
> > > > > > > > controller removed, which in turn removes *some*, but not all of
> > > > > > > > the
> > > > > > > > devices formerly dedicated to the ARISC (CPUS).
> > > > > > > > And while there is still the extra sunxi interrupt controller,
> > > > > > > > the
> > > > > > > > package lacks the corresponding NMI pin, so no interrupts for
> > > > > > > > the
> > >
> > > PMIC.
> > >
> > > > > > > > The reserved memory node is actually handled by Trusted Firmware
> > >
> > > now,
> > >
> > > > > > > > but U-Boot fails to propagate this to a separately loaded DTB,
> > > > > > > > so we
> > > > > > > > keep it in here for now, until U-Boot learns to do this
> > > > > > > > properly.
> > > > > > > >
> > > > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 574
> > > > > > > > +++++++++++++++
> > >
> > > +++
> > >
> > > > > > > > 1 file changed, 574 insertions(+)
> > > > > > > > create mode 100644
> > > > > > > > arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > > b/arch/arm64/
> > > > > > >
> > > > > > > boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > >
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..cc06cdd15ba5
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> > > > > > > > @@ -0,0 +1,574 @@
> > > > > > > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > > > > > > +// Copyright (C) 2020 Arm Ltd.
> > > > > > > > +// based on the H6 dtsi, which is:
> > > > > > > > +// Copyright (C) 2017 Icenowy Zheng <icenowy@aosc.io>
> > > > > > > > +
> > > > > > > > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > > > > +#include <dt-bindings/clock/sun50i-h616-ccu.h>
> > > > > > > > +#include <dt-bindings/clock/sun50i-h6-r-ccu.h>
> > > > > > > > +#include <dt-bindings/reset/sun50i-h616-ccu.h>
> > > > > > > > +#include <dt-bindings/reset/sun50i-h6-r-ccu.h>
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > + interrupt-parent = <&gic>;
> > > > > > > > + #address-cells = <2>;
> > > > > > > > + #size-cells = <2>;
> > > > > > > > +
> > > > > > > > + cpus {
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <0>;
> > > > > > > > +
> > > > > > > > + cpu0: cpu@0 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <0>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu1: cpu@1 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <1>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu2: cpu@2 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <2>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + cpu3: cpu@3 {
> > > > > > > > + compatible = "arm,cortex-a53";
> > > > > > > > + device_type = "cpu";
> > > > > > > > + reg = <3>;
> > > > > > > > + enable-method = "psci";
> > > > > > > > + clocks = <&ccu CLK_CPUX>;
> > > > > > > > + };
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + reserved-memory {
> > > > > > > > + #address-cells = <2>;
> > > > > > > > + #size-cells = <2>;
> > > > > > > > + ranges;
> > > > > > > > +
> > > > > > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31)
> */
> > > > > > > > + secmon_reserved: secmon@40000000 {
> > > > > > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > > > > > + no-map;
> > > > > > > > + };
> > > > > > > > + };
> > > > > > >
> > > > > > > I'm not a fan of above. If anything changes in future in BL31,
> > > > > > > U-Boot
> > > > > > > would
> > > > > > > need to reconfigure it anyway. Can we just skip it?
> > > > > >
> > > > > > I am not a fan neither, but last time I checked this is needed to
> > > > > > boot.
> > > > > > Indeed TF-A inserts this node, with the right values, into U-Boot's
> > > > > > DT.
> > > > > > And that's nicely preserved if you use that DT ($fdtcontroladdr) for
> > > > > > the kernel as well.
> > > > > > But if someone *loads* a DTB into U-Boot (to $fdt_addr_r), then
> > > > > > U-Boot fails to propagate the /reserved-memory node into that copy.
> > > > > > There does not seem to be a global notion of reserved memory in
> > > > > > U-Boot.
> > > > > > Some commands (like tftp) explicitly parse the control DT to find
> > > > > > and
> > > > > > respect reserved memory regions. bootm does that also, but only to
> > > > > > avoid placing the ramdisk or DTB into reserved memory. The
> > > > > > information
> > > > > > ends up in images->lmb, but is not used to generate or amend nodes
> > > > > > in
> > > > > > the target DT.
> > > > > > So the bits and pieces are there, but it will require some code to
> > > > > > be
> > > > > > added to the generic U-Boot code.
> > > > > >
> > > > > > So what do you think? Leaving this out will prevent loading DTBs
> > > > > > into
> > > > > > U-Boot, at the moment, which sounds bad. I suggest we keep it in,
> > > > > > for
> > > > > > now, it should not really hurt. U-Boot will hopefully start to do
> > > > > > the
> > > > > > right thing soon, then we can either phase it out here (maybe when
> > > > > > we
> > > > > > actually change something in TF-A), or let U-Boot fix it.
> > > > >
> > > > > TBH, if "soon" is really soon, I would rather wait with H616 DT until
> > > > > U-
> > >
> > > Boot
> > >
> > > > > supports carrying over reserved memory nodes.
> > > >
> > > > But this also carries compatibility issues. U-Boot support the H616 for
> > > > more than a year now, and the earliest possible U-Boot release having
> > > > that
> > > > propagation code would be the one released in October.
> > >
> > > I was hoping you would say July (next U-Boot release) :).
> >
> > Well, 2022.07 was supposed to be released today, and even if that is
> > delayed by a bit, that's obviously far too late ;-)
> >
> > > > And then people
> > > > would still need to update first, so that's quite some months out.
> > > > And I was actually hoping to get at least the H616 DT patches off my
> > > > plate, and get them into the tree to have a stable and agreed upon base
> > > > (before this series turns into a teenager ;-)
> > >
> > > Yeah, I would like that too.
> > >
> > > > Then we could for instance update the U-Boot H616 support.
> > > >
> > > > > Whatever we do now, it will have
> > > > > compatibility issues. If we introduce reserved memory node now, we
> > > > > can't
> > > > > easily drop it later. Bootloaders are not very often updated, but
> > > > > kernels
> > >
> > > and
> > >
> > > > > DTB files are, at least in my experience. So when we decide to drop
> > > > > the
> > >
> > > node?
> > >
> > > > I think of the three possibilities:
> > > > - Drop the node now, and ask people to not load DTBs explicitly
> > > > - Drop the node when U-Boot learned to propagate the reservation
> > > > - Keep the node
> > > > the last one is the least painful: having this node in does not really
> > > > hurt, so we can be very relaxed with this removal decision:
> > > > - If U-Boot does not add the reserved node, we are covered.
> > > > - If U-Boot adds the node, it will do so in a way where it deals with
> > > > existing reservations. So either it doesn't actually change anything, or
> > > > it extends the reservation.
> > > > - Should the TF-A location actually move (and we have no plans or needs
> > > > to
> > > > do that), people would only get this by updating the firmware, at which
> > > > point the U-Boot part would surely be in place already. We don't really
> > > > support updating just BL31 in an existing binary firmware image, so you
> > > > would get an updated U-Boot as well.
> > > >
> > > > I think the worst case scenario is that users end up with an unneeded
> > > > 512K
> > > > reservation. If they care, a firmware update should solve this problem.
> > > >
> > > > As for the time to remove that node: we could do that at the time when
> > > > (or rather: if) we actually change the TF-A reservation. At the moment
> > > > there are no plans to do this, and the size reservation is more than
> > > > generous (the current debug build is actually 77 KB or so only). If
> > > > there
> > > > is no change, and the node stays in the .dtsi, it doesn't really hurt,
> > > > see
> > > > above.
> > >
> > > I see your point, but I would like to get some input from Samuel first.
> > >
> > > Samuel, what do you think?
> > >
> > > > > After 10 years? Alternatively, reserved memory node can be just
> > > > > dropped
> > >
> > > and
> > >
> > > > > anyone loading DTB file from outside would need to make sure it's
> > > > > patched.
> > >
> > > But
> > >
> > > > > that's unexpected from user perspective, although patching DT files is
> > > > > done
> > >
> > > by
> > >
> > > > > some distros.
> > > >
> > > > Yeah, let's not go there. As you know, I already dislike the idea of
> > > > explicitly loading DTBs at all, but I understand this is what people,
> > > > and
> > > > distributions, do, so I'd rather have them covered. Hence the node to
> > > > work with existing firmware.
> > >
> > > Reusing DTB from U-Boot is only useful when you're happy with completeness
> > > of DT and with the lack of bugs in it. Then you can save troubles with
> > > skipping external DTB load step and life is easier. But as you know,
> > > features and thus nodes are added in steps and sometimes some bugs are
> > > fixed, which means it's extremely handy to have easily updatable DTB
> > > file.
> >
> > Yes, definitely, see my reply to Samuel. I just held back with the DT
> > update in U-Boot because of the conflict between "we only take pure
> > kernel tree DTs" and "there is a breaking change" (r_intc binding).
> >
> > If we find a way forward with the DT stability problem, I am happy to
> > push for a much more frequent DT update, or even update just the DT in
> > an existing firmware installation. This can be automated, since the DTB
> > is just a member in the FIT image, which can be re-assembled with an
> > updated DTB by some tool or script. Or we use capsule updates, of just
> > the DTB, separately (if this is possible)?
>
> I would like to have forward compatibility too, but IMO it's not very
> realistic. Sooner or later we'll find something, like r_intc, again that won't
> be possible to integrate in forward compatible manner.
That's a shame, I think we should at least try. And with my x86 background
let me tell you: there are solutions to those compatibility problems ;-)
The more nasty ones might be borderline hackish, but it's a question of
priorities, I guess.
> > > Yes, U-Boot can be
> > > automated, but it's tedious for distro to maintain one bootloader package
> > > per board. Ideally, distro shouldn't care at all about that,
> >
> > Yes, I totally agree, distros should not ship firmware. Since leaving
> > this to the board vendors is not realistic, I wonder if we (as "the
> > sunxi community") should step up here, and provide binary builds (purely
> > for convenience reasons) of board firmware? That could be updated from
> > a running Linux, or put on an SD card, or fetched by distros to
> > generate an installer? Wasn't there even some central storage offered
> > lately by Linux, to hold (UEFI) firmware update files?
>
> As someone who's working on distro which supports many SoCs from variety of
> vendors,
But that is relative, isn't it? I count 23 supported Allwinner devices in
LibreELEC, out of the 160 defconfigs in U-Boot or >180 sunxi .dts files in
the kernel.
So as most distributions, even with your ARM device focus, you chose to
limit the number of supported devices, as that approach inherently
doesn't scale.
I see the reasons behind this, because of the special focus of LibreELEC,
and probably the idea of giving a smooth user experience, but you could
potentially cover much more devices by offering a generic UEFI image, as
most *generic* distributions do, and as LE does for x86. But this relies
on having a stable DT for the platform.
I think conceptually this problem has been solved a long time ago: there
is some interface between firmware and the kernel, which allows a generic
kernel to configure itself accordingly. I refuse the idea that Arm based
device should be any different in this respect. Historically, because many
Arm based machines have a strong embedded background, that was not the
case, but I think we should move on from those dark ages (in terms of
support and maintainability).
> I can tell you that we'll ship bootloader integrated into our image
> for years to come. Anyway, I also like to build U-Boot using my own options.
> For example, I disable HDMI driver for A64, H3 and H5, because it turns out
> that at least on H5, it can clash with Linux driver.
That is good to hear, please tell the sunxi U-Boot maintainer, so that we
can fix it ;-)
> Other distros prefer to
> show some splash screen, etc. One size fits all solution doesn't seems
> realistic to me. Maybe only if *everything* would be configurable and there
> would be a way for distro to preconfigure it.
>
> TBH, building U-Boot, Crust and TF-A is easy and ability to customize them is
> very handy.
> > > but many boards don't
> > > have designated bootloader storage (SPI NOR flash in AW case), so they
> > > have to be combined on same storage, partition even, as distro.
> >
> > Have you tried eMMC boot partitions? I found them equally convenient as
> > SPI flash, and while not too many boards actually have SPI flash,
> > quite some have eMMC (thinking about TV boxes). I recently even
> > used "dual boot" with a BSP installation.
> > And even the smallest eMMCs seem to have 4 MB per boot partition, so
> > plenty of space for U-Boot (plus TF-A plus crust).
>
> No, I didn't. I don't see any benefit of using eMMC boot partition over
> treating eMMC as usual SD card and installing bootloader to sector 16.
The firmware is out of the way of normal (accidental) accesses, as it
lives in a separate block device, which is read-only, initially.
And it doesn't clash with partition tables. This gives the kind of
separation that people are used to on other computers: the firmware
belongs to the device, the OS is provided by the user.
We documented how to install firmware there in U-Boot's sunxi.rst.
> Anyway, that won't change situation at all. SD card image with integrated
> bootloader is still king.
Sure, if you don't have any other storage, then SD card it is. But this
still does not require marrying firmware and OS: you could start with a
"just firmware SD card", then install the OS from a USB device, or from a
generic image file copied to some SD partition. And then suddenly the
pure firmware image becomes OS/distro agnostic.
And conceptually this approach doesn't *prevent* separating firmware and
kernel/distro, it just allows you to get away with it.
> There are several reasons for that:
> - cheapest boards are most popular and usually have only SD card for storage
> (think OrangePi PC). There is nothing that you can do about it, except
> including bootloader on SD card image.
> - if you want to switch from Android to our distro, you need bootable SD card
> due to higher boot priority (speaking for AW SoCs)
> - not everyone wants to overwrite eMMC. Some prefer keeping Android, so it can
> be used later for whatever purpose.
> - some users have several distros for same board, each on it's own SD card.
> Needless to say, each distro adjusted bootloader to its needs.
All fine, but I don't see how this affects this discussion here. Yes, you
can treat those machines like embedded devices, and bundle firmware and
OS, but this is surely not the only way of deployment we should support.
Being able to just offer one generic UEFI based image seems much more
scalable to me.
> I like to offer flexibility in boot options, especially because it's currently
> easy, thanks to integrated customized bootloader and external loading of dtb
> files :)
Though I don't understand why you require external DTB loading: if you
marry distro and firmware anyway, you could as well put your DTB of choice
into U-Boot (in the U-Boot source tree, or replace it in the generated FIT
image). That looks like a one-time effort in your build system?
> > > On the other hand,
> > > when building kernel, you automatically build all relevant DTB files,
> > > which you can then just copy to common place. No device specific handling
> > > needed. Also, U-Boot doesn't sync DT files every release, so latest
> > > U-Boot doesn't necessarly mean latest DT.
> >
> > Yes, for the compatibility reasons mentioned. I am more than happy to
> > make this a regular exercise (say at each kernel's -rc3 or so).
>
> What about breaking changes? They can be important for new, useful
> functionality but older kernels won't know what to do.
Yes, that is the core of this discussion. Doing this relies on not having
them in the first place. There is no problem when this affects new
features, or functionality that the old kernel didn't support anyway.
But we must avoid change affecting older kernels.
At least I would like to ask for us to try: in my experience with some
thinking and clever code we can pull this off. Other platforms seem to be
able to commit to this.
As a compromise, I was wondering if we should define some time of grace
period, initially, were we don't guarantee non-breaking changes only.
So the first, say three, kernels could include breaking changes, but
afterwards we stick to support at least this kernel, with every new DT to
come.
> > Sadly, I don't think we're even close to avoiding shipping bootloader in
> distro images or even external DTB loading.
> > > Above is a bit off topic, but I hope you understand why distros opt to use
> > > external DTB files (speaking from my own experiences).
> >
> > Yes, I understand where they (including LE) are coming from, to provide
> > a pragmatic solution to the users' problems. And that's why I wanted to
> > still give the possibility to load a DTB, even though I think this
> > should not be the standard way.
>
> I think loading external DTB support is important and shouldn't be ditched
> anytime soon. If I understand correctly, that's an issue only on SoCs with TF-
> A, which means only 64-bit AW SoCs. Yes, 32-bit AW SoCs are still a thing and
> still used and no, I don't want TF-A there :).
I think it's a conceptual issue, not TF-A related: A DT was always meant
to be amended by firmware (think of the memory node, or the MAC address).
U-Boot just decided to make those changes very late, just before launching
the kernel, so that this newly loaded DTB is already available. But if the
SPL decides to make changes, or picks a certain DT, you have this problem
as well.
Cheers,
Andre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-06 13:16 ` Andre Przywara
@ 2022-07-07 6:30 ` Samuel Holland
-1 siblings, 0 replies; 54+ messages in thread
From: Samuel Holland @ 2022-07-07 6:30 UTC (permalink / raw)
To: Andre Przywara, Jernej Škrabec
Cc: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi Andre, Jernej,
On 7/6/22 8:16 AM, Andre Przywara wrote:
> so after seemingly having finished writing this email, I realised that
> this won't really help, as I think this diverts the discussion. And the
> problem has been around for a while, and won't probably be solved easily
> or quickly. I think we agree to disagree here, or we should admit that
> there are different approaches ("bundled firmware" vs. "UEFI"), so in the
> interest of not blocking the H616 series:
>
> Shall I just keep the firmware node? This would work both ways, whereas
> dropping the node would impede the "bundled firmware" approach?
Let me try to sum up the relevant portion of my thoughts (and save the rest for
elsewhere):
The only reason to add the reserved-memory node is to support externally-loaded
DTBs. By adding the node, we are committing to support externally-loaded DTBs on
this SoC.
Upgrading the kernel is not allowed to break boot. If we support
externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.
If we remove the reserved-memory node, the combination of old U-Boot + new
externally-loaded DTB will stop booting (the kernel version is irrelevant).
Therefore, if we add the node, we can never remove it, full stop.
I will (begrudgingly) accept that, as long as the node matches what TF-A
actually generates today. That means, please:
- Drop the label and update the node name
- Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)
Regards,
Samuel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-07 6:30 ` Samuel Holland
0 siblings, 0 replies; 54+ messages in thread
From: Samuel Holland @ 2022-07-07 6:30 UTC (permalink / raw)
To: Andre Przywara, Jernej Škrabec
Cc: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Hi Andre, Jernej,
On 7/6/22 8:16 AM, Andre Przywara wrote:
> so after seemingly having finished writing this email, I realised that
> this won't really help, as I think this diverts the discussion. And the
> problem has been around for a while, and won't probably be solved easily
> or quickly. I think we agree to disagree here, or we should admit that
> there are different approaches ("bundled firmware" vs. "UEFI"), so in the
> interest of not blocking the H616 series:
>
> Shall I just keep the firmware node? This would work both ways, whereas
> dropping the node would impede the "bundled firmware" approach?
Let me try to sum up the relevant portion of my thoughts (and save the rest for
elsewhere):
The only reason to add the reserved-memory node is to support externally-loaded
DTBs. By adding the node, we are committing to support externally-loaded DTBs on
this SoC.
Upgrading the kernel is not allowed to break boot. If we support
externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.
If we remove the reserved-memory node, the combination of old U-Boot + new
externally-loaded DTB will stop booting (the kernel version is irrelevant).
Therefore, if we add the node, we can never remove it, full stop.
I will (begrudgingly) accept that, as long as the node matches what TF-A
actually generates today. That means, please:
- Drop the label and update the node name
- Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)
Regards,
Samuel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-07 6:30 ` Samuel Holland
@ 2022-07-07 16:39 ` Jernej Škrabec
-1 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-07 16:39 UTC (permalink / raw)
To: Andre Przywara, Samuel Holland
Cc: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Dne četrtek, 07. julij 2022 ob 08:30:32 CEST je Samuel Holland napisal(a):
> Hi Andre, Jernej,
>
> On 7/6/22 8:16 AM, Andre Przywara wrote:
> > so after seemingly having finished writing this email, I realised that
> > this won't really help, as I think this diverts the discussion. And the
> > problem has been around for a while, and won't probably be solved easily
> > or quickly. I think we agree to disagree here, or we should admit that
> > there are different approaches ("bundled firmware" vs. "UEFI"), so in the
> > interest of not blocking the H616 series:
> >
> > Shall I just keep the firmware node? This would work both ways, whereas
> > dropping the node would impede the "bundled firmware" approach?
>
> Let me try to sum up the relevant portion of my thoughts (and save the rest
> for elsewhere):
>
> The only reason to add the reserved-memory node is to support
> externally-loaded DTBs. By adding the node, we are committing to support
> externally-loaded DTBs on this SoC.
>
> Upgrading the kernel is not allowed to break boot. If we support
> externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.
>
> If we remove the reserved-memory node, the combination of old U-Boot + new
> externally-loaded DTB will stop booting (the kernel version is irrelevant).
> Therefore, if we add the node, we can never remove it, full stop.
>
> I will (begrudgingly) accept that, as long as the node matches what TF-A
> actually generates today. That means, please:
> - Drop the label and update the node name
> - Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)
In the interest of moving things forward, I agree to that.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-07 16:39 ` Jernej Škrabec
0 siblings, 0 replies; 54+ messages in thread
From: Jernej Škrabec @ 2022-07-07 16:39 UTC (permalink / raw)
To: Andre Przywara, Samuel Holland
Cc: Chen-Yu Tsai, Rob Herring, Krzysztof Kozlowski, Icenowy Zheng,
linux-arm-kernel, linux-sunxi, devicetree, linux-kernel
Dne četrtek, 07. julij 2022 ob 08:30:32 CEST je Samuel Holland napisal(a):
> Hi Andre, Jernej,
>
> On 7/6/22 8:16 AM, Andre Przywara wrote:
> > so after seemingly having finished writing this email, I realised that
> > this won't really help, as I think this diverts the discussion. And the
> > problem has been around for a while, and won't probably be solved easily
> > or quickly. I think we agree to disagree here, or we should admit that
> > there are different approaches ("bundled firmware" vs. "UEFI"), so in the
> > interest of not blocking the H616 series:
> >
> > Shall I just keep the firmware node? This would work both ways, whereas
> > dropping the node would impede the "bundled firmware" approach?
>
> Let me try to sum up the relevant portion of my thoughts (and save the rest
> for elsewhere):
>
> The only reason to add the reserved-memory node is to support
> externally-loaded DTBs. By adding the node, we are committing to support
> externally-loaded DTBs on this SoC.
>
> Upgrading the kernel is not allowed to break boot. If we support
> externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.
>
> If we remove the reserved-memory node, the combination of old U-Boot + new
> externally-loaded DTB will stop booting (the kernel version is irrelevant).
> Therefore, if we add the node, we can never remove it, full stop.
>
> I will (begrudgingly) accept that, as long as the node matches what TF-A
> actually generates today. That means, please:
> - Drop the label and update the node name
> - Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)
In the interest of moving things forward, I agree to that.
Best regards,
Jernej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
2022-07-07 6:30 ` Samuel Holland
@ 2022-07-08 9:47 ` Andre Przywara
-1 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-08 9:47 UTC (permalink / raw)
To: Samuel Holland
Cc: Jernej Škrabec, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Icenowy Zheng, linux-arm-kernel,
linux-sunxi, devicetree, linux-kernel
On Thu, 7 Jul 2022 01:30:32 -0500
Samuel Holland <samuel@sholland.org> wrote:
Hi Samuel,
> Hi Andre, Jernej,
>
> On 7/6/22 8:16 AM, Andre Przywara wrote:
> > so after seemingly having finished writing this email, I realised that
> > this won't really help, as I think this diverts the discussion. And the
> > problem has been around for a while, and won't probably be solved easily
> > or quickly. I think we agree to disagree here, or we should admit that
> > there are different approaches ("bundled firmware" vs. "UEFI"), so in the
> > interest of not blocking the H616 series:
> >
> > Shall I just keep the firmware node? This would work both ways, whereas
> > dropping the node would impede the "bundled firmware" approach?
>
> Let me try to sum up the relevant portion of my thoughts (and save the rest for
> elsewhere):
>
> The only reason to add the reserved-memory node is to support externally-loaded
> DTBs. By adding the node, we are committing to support externally-loaded DTBs on
> this SoC.
>
> Upgrading the kernel is not allowed to break boot. If we support
> externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.
>
> If we remove the reserved-memory node, the combination of old U-Boot + new
> externally-loaded DTB will stop booting (the kernel version is irrelevant).
> Therefore, if we add the node, we can never remove it, full stop.
Well, this all depends on the initial commitment to support
externally-loaded DTBs. I don't think we need to make this promise, I'd
rather see this as a concession to people doing so *right now*, and for
the sheer practicality of using this DT until we merge it into U-Boot.
> I will (begrudgingly) accept that, as long as the node matches what TF-A
> actually generates today. That means, please:
> - Drop the label and update the node name
I will drop the label. For the node name: the binding does not enforce it,
but asks that "node names should reflect the purpose", so I went with
"secmon", as used by other platforms. I will send a patch to TF-A to fix
it there instead.
If you disagree, feel free to fix this up before committing.
> - Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)
Verified in TF-A and changed.
I also added a short comment explaining the situation. Feel free to amend
this if needed.
Many thanks for the discussion and for resolving this. I much appreciate
your flexibility and pragmatism in this matter!
Cheers,
Andre
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
@ 2022-07-08 9:47 ` Andre Przywara
0 siblings, 0 replies; 54+ messages in thread
From: Andre Przywara @ 2022-07-08 9:47 UTC (permalink / raw)
To: Samuel Holland
Cc: Jernej Škrabec, Chen-Yu Tsai, Rob Herring,
Krzysztof Kozlowski, Icenowy Zheng, linux-arm-kernel,
linux-sunxi, devicetree, linux-kernel
On Thu, 7 Jul 2022 01:30:32 -0500
Samuel Holland <samuel@sholland.org> wrote:
Hi Samuel,
> Hi Andre, Jernej,
>
> On 7/6/22 8:16 AM, Andre Przywara wrote:
> > so after seemingly having finished writing this email, I realised that
> > this won't really help, as I think this diverts the discussion. And the
> > problem has been around for a while, and won't probably be solved easily
> > or quickly. I think we agree to disagree here, or we should admit that
> > there are different approaches ("bundled firmware" vs. "UEFI"), so in the
> > interest of not blocking the H616 series:
> >
> > Shall I just keep the firmware node? This would work both ways, whereas
> > dropping the node would impede the "bundled firmware" approach?
>
> Let me try to sum up the relevant portion of my thoughts (and save the rest for
> elsewhere):
>
> The only reason to add the reserved-memory node is to support externally-loaded
> DTBs. By adding the node, we are committing to support externally-loaded DTBs on
> this SoC.
>
> Upgrading the kernel is not allowed to break boot. If we support
> externally-loaded DTBs, that rule extends to DTBs shipped with the kernel.
>
> If we remove the reserved-memory node, the combination of old U-Boot + new
> externally-loaded DTB will stop booting (the kernel version is irrelevant).
> Therefore, if we add the node, we can never remove it, full stop.
Well, this all depends on the initial commitment to support
externally-loaded DTBs. I don't think we need to make this promise, I'd
rather see this as a concession to people doing so *right now*, and for
the sheer practicality of using this DT until we merge it into U-Boot.
> I will (begrudgingly) accept that, as long as the node matches what TF-A
> actually generates today. That means, please:
> - Drop the label and update the node name
I will drop the label. For the node name: the binding does not enforce it,
but asks that "node names should reflect the purpose", so I went with
"secmon", as used by other platforms. I will send a patch to TF-A to fix
it there instead.
If you disagree, feel free to fix this up before committing.
> - Reduce the size to 256 KiB, matching (BL31_LIMIT - BL31_BASE)
Verified in TF-A and changed.
I also added a short comment explaining the situation. Feel free to amend
this if needed.
Many thanks for the discussion and for resolving this. I much appreciate
your flexibility and pragmatism in this matter!
Cheers,
Andre
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2022-07-08 9:48 UTC | newest]
Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-28 23:09 [PATCH v11 0/6] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-04-28 23:09 ` [PATCH v11 1/6] clk: sunxi-ng: h6-r: Add RTC gate clock Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-05-03 2:06 ` Samuel Holland
2022-05-03 2:06 ` Samuel Holland
2022-05-06 16:10 ` Jernej Škrabec
2022-05-06 16:10 ` Jernej Škrabec
2022-04-28 23:09 ` [PATCH v11 2/6] clk: sunxi-ng: h616: Add PLL derived 32KHz clock Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-05-06 16:11 ` Jernej Škrabec
2022-05-06 16:11 ` Jernej Škrabec
2022-04-28 23:09 ` [PATCH v11 3/6] arm64: dts: allwinner: Add Allwinner H616 .dtsi file Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-05-03 19:05 ` Jernej Škrabec
2022-05-03 19:05 ` Jernej Škrabec
2022-05-03 19:41 ` Jernej Škrabec
2022-05-03 19:41 ` Jernej Škrabec
2022-06-30 0:04 ` Andre Przywara
2022-06-30 0:04 ` Andre Przywara
2022-07-02 21:16 ` Jernej Škrabec
2022-07-02 21:16 ` Jernej Škrabec
2022-07-04 13:30 ` Andre Przywara
2022-07-04 13:30 ` Andre Przywara
2022-07-04 18:42 ` Jernej Škrabec
2022-07-04 18:42 ` Jernej Škrabec
2022-07-04 21:58 ` Andre Przywara
2022-07-04 21:58 ` Andre Przywara
2022-07-05 17:32 ` Jernej Škrabec
2022-07-05 17:32 ` Jernej Škrabec
2022-07-06 13:16 ` Andre Przywara
2022-07-06 13:16 ` Andre Przywara
2022-07-07 6:30 ` Samuel Holland
2022-07-07 6:30 ` Samuel Holland
2022-07-07 16:39 ` Jernej Škrabec
2022-07-07 16:39 ` Jernej Škrabec
2022-07-08 9:47 ` Andre Przywara
2022-07-08 9:47 ` Andre Przywara
2022-07-04 18:44 ` Samuel Holland
2022-07-04 18:44 ` Samuel Holland
2022-07-04 20:52 ` Andre Przywara
2022-07-04 20:52 ` Andre Przywara
2022-04-28 23:09 ` [PATCH v11 4/6] dt-bindings: arm: sunxi: Add two H616 board compatible strings Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-04-28 23:09 ` [PATCH v11 5/6] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-05-03 19:41 ` Jernej Škrabec
2022-05-03 19:41 ` Jernej Škrabec
2022-06-30 0:08 ` Andre Przywara
2022-06-30 0:08 ` Andre Przywara
2022-04-28 23:09 ` [PATCH v11 6/6] arm64: dts: allwinner: h616: Add X96 Mate TV box support Andre Przywara
2022-04-28 23:09 ` Andre Przywara
2022-05-03 19:44 ` Jernej Škrabec
2022-05-03 19:44 ` Jernej Škrabec
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.