linux-sunxi.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support
@ 2021-05-19 10:41 Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) Andre Przywara
                   ` (16 more replies)
  0 siblings, 17 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel

Hi,

after some pause those are the "remaining" patches to get the new
Allwinner H616 SoC supported.
Compared to v5 from January there are quite some changes: For a start
the clock, pinctrl and MMC bits made it into v5.12 already, so this series
starts right after that. The missing interrupt facility of the AXP is now
hopefully solved properly (patch 02).
The RTC turned out to be incompatible, the date is stored in a different
way. Patch 04 addresses this now. And finally the USB support got some
major overhaul: For a start it now seems to work - but I claimed that
before, so don't hold your breath, but test, please! There are now two
new patches to the Allwinner USB PHY driver to make this happen (11 and 12),
plus we need some seemingly random extra list of clocks and reset added to
each EHCI and OHCI node. Not pretty, but this looks like a nasty hardware
problem, so probably justifies some quirk. Meh.

Changelog below. Based on 5.13-rc1.

U-Boot support is part of the v2021.04 release, and Trusted Firmware
support is also mainline and part of the just released v2.5 version.

As an added bonus I got myself the "X96 Mate" TV box [2] with this SoC, so
the final patch contains a DT for this box as well. Probably the first
supported Allwinner machine with 4GB of DRAM actually usable.

The whole series can also be found here:
https://github.com/apritzel/linux/commits/h616-v6

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.

Various DT binding patches are sprinkled throughout the series, to add
the new compatible names right before they are used.
Patch 2 teaches the AXP MFD driver to get along without having an
interrupt, as the missing NMI pin on the H616 leads to some boards not
having the AXP IRQ line connected.
Patch 4 and 5 add support for the new RTC: the date is now stored as a
linear number, not broken down into day-month-year. The benefit is that
this lifts the limit of the old date counter, which would have rolled
over around 2032. 
Patch 7 adds a tweak to the EMAC driver, to deal with the second EMAC
clock used for the second Ethernet controller.
This is somewhat optional for the current .dts, as this doesn't use
the second EMAC (yet).
Patches 10-13 add the USB support, there are several small changes needed
to the Allwinner PHY driver to make this work. Some hardware changes look
like accidents ;-)
Eventually we get the .dtsi for the SoC in patch 14, and the .dts for
the OrangePi Zero2 board[1] in the penultimate patch, followed by
the .dts for the X96 Mate TV box[2] in the final commit.

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.

Happy reviewing!

Cheers,
Andre

[1] https://linux-sunxi.org/Orange_Pi_Zero_2
[2] https://linux-sunxi.org/X96_Mate

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
- Enable 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 (20):
  dt-bindings: clk: sunxi-ccu: Add compatible string for Allwinner H616
  clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
  clk: sunxi-ng: Add support for the Allwinner H616 CCU
  dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  Input: axp20x-pek: Bail out if AXP has no interrupt line connected
  mfd: axp20x: Allow AXP chips without interrupt lines
  dt-bindings: sram: sunxi-sram: Add H616 compatible string
  soc: sunxi: sram: Add support for more than one EMAC clock
  dt-bindings: watchdog: sun4i: Add H616 compatible string
  dt-bindings: i2c: mv64xxx: Add H616 compatible string
  dt-bindings: media: IR: Add H616 IR compatible string
  dt-bindings: rtc: sun6i: Add H616 compatible string
  dt-bindings: spi: sunxi: Add H616 compatible string
  dt-bindings: bus: rsb: Add H616 compatible string
  dt-bindings: net: sun8i-emac: Add H616 compatible string
  net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register
  phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling
  arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding
  arm64: dts: allwinner: Add OrangePi Zero 2 .dts

Andre Przywara (17):
  dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  mfd: axp20x: Allow AXP 806 chips without interrupt lines
  dt-bindings: rtc: sun6i: Add H616 compatible string
  rtc: sun6i: Add support for linear day storage
  rtc: sun6i: Add Allwinner H616 support
  dt-bindings: net: sun8i-emac: Add H616 compatible string
  net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register
  dt-bindings: usb: Add H616 compatible string
  dt-bindings: usb: sunxi-musb: Add H616 compatible string
  phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling
  phy: sun4i-usb: Allow reset line to be shared
  phy: sun4i-usb: Introduce port2 SIDDQ quirk
  phy: sun4i-usb: Add support for the H616 USB PHY
  arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding
  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        |   5 +
 .../devicetree/bindings/mfd/axp20x.txt        |   3 +-
 .../net/allwinner,sun8i-a83t-emac.yaml        |   4 +-
 .../phy/allwinner,sun8i-h3-usb-phy.yaml       |   4 +-
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml |   5 +-
 .../usb/allwinner,sun4i-a10-musb.yaml         |   3 +
 arch/arm64/boot/dts/allwinner/Makefile        |   2 +
 .../allwinner/sun50i-h616-orangepi-zero2.dts  | 245 ++++++
 .../dts/allwinner/sun50i-h616-x96-mate.dts    | 201 +++++
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 747 ++++++++++++++++++
 drivers/mfd/axp20x.c                          |  24 +-
 .../net/ethernet/stmicro/stmmac/dwmac-sun8i.c |  12 +-
 drivers/phy/allwinner/phy-sun4i-usb.c         |  73 +-
 drivers/rtc/rtc-sun6i.c                       |  62 +-
 14 files changed, 1342 insertions(+), 48 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.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-21  1:39   ` Rob Herring
  2021-05-22 14:46   ` Samuel Holland
  2021-05-19 10:41 ` [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines Andre Przywara
                   ` (15 subsequent siblings)
  16 siblings, 2 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree, Lee Jones

The AXP305 PMIC used in AXP805 seems to be fully compatible to the
AXP805 PMIC, so add the proper chain of compatible strings.

Also at least on one board (Orangepi Zero2) there is no interrupt line
connected to the CPU, so make the "interrupts" property optional.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 4991a6415796..4fd748101e3c 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -26,10 +26,10 @@ Required properties:
     * "x-powers,axp803"
     * "x-powers,axp806"
     * "x-powers,axp805", "x-powers,axp806"
+    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
     * "x-powers,axp809"
     * "x-powers,axp813"
 - reg: The I2C slave address or RSB hardware address for the AXP chip
-- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
 - #interrupt-cells: Should be set to 1
 
@@ -43,6 +43,7 @@ more information:
 			AXP20x/LDO3: software-based implementation
 
 Optional properties:
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
 		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
 		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 15:01   ` Lee Jones
  2021-05-19 10:41 ` [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Andre Przywara
                   ` (14 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Lee Jones

Currently the AXP chip requires to have its IRQ line connected to some
interrupt controller, and will fail probing when this is not the case.

On a new Allwinner SoC (H616) there is no NMI pin anymore, and at
least one board does not connect the AXP's IRQ pin to anything else,
so the interrupt functionality of the AXP chip is simply not available.

Check whether the interrupt line number returned by the platform code is
valid, before trying to register the irqchip. If not, we skip this
registration, to avoid the driver to bail out completely.
Also we need to skip the power key functionality, as this relies on
a valid IRQ as well.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/mfd/axp20x.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3eae04e24ac8..4145a38b3890 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -884,8 +884,13 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
 		axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
 		break;
 	case AXP806_ID:
+		/*
+		 * Don't register the power key part if in slave mode or
+		 * if there is no interrupt line.
+		 */
 		if (of_property_read_bool(axp20x->dev->of_node,
-					  "x-powers,self-working-mode")) {
+					  "x-powers,self-working-mode") &&
+		    axp20x->irq > 0) {
 			axp20x->nr_cells = ARRAY_SIZE(axp806_self_working_cells);
 			axp20x->cells = axp806_self_working_cells;
 		} else {
@@ -959,12 +964,17 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
 				     AXP806_REG_ADDR_EXT_ADDR_SLAVE_MODE);
 	}
 
-	ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
-			  IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
-			   -1, axp20x->regmap_irq_chip, &axp20x->regmap_irqc);
-	if (ret) {
-		dev_err(axp20x->dev, "failed to add irq chip: %d\n", ret);
-		return ret;
+	/* Only if there is an interrupt line connected towards the CPU. */
+	if (axp20x->irq > 0) {
+		ret = regmap_add_irq_chip(axp20x->regmap, axp20x->irq,
+				IRQF_ONESHOT | IRQF_SHARED | axp20x->irq_flags,
+				-1, axp20x->regmap_irq_chip,
+				&axp20x->regmap_irqc);
+		if (ret) {
+			dev_err(axp20x->dev, "failed to add irq chip: %d\n",
+				ret);
+			return ret;
+		}
 	}
 
 	ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-21  1:39   ` Rob Herring
  2021-05-21  2:37   ` Samuel Holland
  2021-05-19 10:41 ` [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage Andre Przywara
                   ` (13 subsequent siblings)
  16 siblings, 2 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree, Alessandro Zummo, Alexandre Belloni, linux-rtc

Add the obvious compatible name to the existing RTC binding.
The actual RTC part of the device uses a different day/month/year
storage scheme, so it's not compatible with the previous devices.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index b1b0ee769b71..178c955f88bf 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
           - const: allwinner,sun50i-a64-rtc
           - const: allwinner,sun8i-h3-rtc
       - const: allwinner,sun50i-h6-rtc
+      - const: allwinner,sun50i-h616-rtc
 
   reg:
     maxItems: 1
@@ -97,7 +98,9 @@ allOf:
       properties:
         compatible:
           contains:
-            const: allwinner,sun50i-h6-rtc
+            enum:
+              - allwinner,sun50i-h6-rtc
+              - allwinner,sun50i-h616-rtc
 
     then:
       properties:
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (2 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-22  7:26   ` Jernej Škrabec
  2021-05-19 10:41 ` [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support Andre Przywara
                   ` (12 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Alessandro Zummo, Alexandre Belloni, linux-rtc

Newer versions of the Allwinner RTC, as for instance found in the H616
SoC, no longer store a broken-down day/month/year representation in the
RTC_DAY_REG, but just a linear day number.
The user manual does not give any indication about the expected epoch
time of this day count, but the BSP kernel uses the UNIX epoch, which
allows easy support due to existing conversion functions in the kernel.

Allow tagging a compatible string with a flag, and use that to mark
those new RTCs. Then convert between a UNIX day number (converted into
seconds) and the broken-down day representation using mktime64() and
time64_to_tm() in the set_time/get_time functions.

That enables support for the RTC in those new chips.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 58 +++++++++++++++++++++++++++++------------
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index adec1b14a8de..0228e9dfd969 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -133,12 +133,15 @@ struct sun6i_rtc_clk_data {
 	unsigned int has_auto_swt : 1;
 };
 
+#define RTC_LINEAR_DAY	BIT(0)
+
 struct sun6i_rtc_dev {
 	struct rtc_device *rtc;
 	const struct sun6i_rtc_clk_data *data;
 	void __iomem *base;
 	int irq;
 	unsigned long alarm;
+	unsigned long flags;
 
 	struct clk_hw hw;
 	struct clk_hw *int_osc;
@@ -471,17 +474,30 @@ static int sun6i_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
 	rtc_tm->tm_min  = SUN6I_TIME_GET_MIN_VALUE(time);
 	rtc_tm->tm_hour = SUN6I_TIME_GET_HOUR_VALUE(time);
 
-	rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
-	rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date);
-	rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
-
-	rtc_tm->tm_mon  -= 1;
-
-	/*
-	 * switch from (data_year->min)-relative offset to
-	 * a (1900)-relative one
-	 */
-	rtc_tm->tm_year += SUN6I_YEAR_OFF;
+	if (chip->flags & RTC_LINEAR_DAY) {
+		struct tm tm;
+
+		/*
+		 * Newer chips store a linear day number, the manual
+		 * does not mandate any epoch base. The BSP driver uses
+		 * the UNIX epoch, let's just copy that, as it's the
+		 * easiest anyway.
+		 */
+		time64_to_tm((date & 0xffff) * 3600ULL * 24, 0, &tm);
+		rtc_tm->tm_mday = tm.tm_mday;
+		rtc_tm->tm_mon  = tm.tm_mon;
+		rtc_tm->tm_year = tm.tm_year;
+	} else {
+		rtc_tm->tm_mday = SUN6I_DATE_GET_DAY_VALUE(date);
+		rtc_tm->tm_mon  = SUN6I_DATE_GET_MON_VALUE(date) - 1;
+		rtc_tm->tm_year = SUN6I_DATE_GET_YEAR_VALUE(date);
+
+		/*
+		 * switch from (data_year->min)-relative offset to
+		 * a (1900)-relative one
+		 */
+		rtc_tm->tm_year += SUN6I_YEAR_OFF;
+	}
 
 	return 0;
 }
@@ -571,15 +587,21 @@ static int sun6i_rtc_settime(struct device *dev, struct rtc_time *rtc_tm)
 	u32 date = 0;
 	u32 time = 0;
 
-	rtc_tm->tm_year -= SUN6I_YEAR_OFF;
 	rtc_tm->tm_mon += 1;
 
-	date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
-		SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
-		SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
+	if (chip->flags & RTC_LINEAR_DAY) {
+		date = mktime64(rtc_tm->tm_year + 1900, rtc_tm->tm_mon,
+				rtc_tm->tm_mday, 0, 0, 0) / (3600ULL * 24);
+	} else {
+		rtc_tm->tm_year -= SUN6I_YEAR_OFF;
+
+		date = SUN6I_DATE_SET_DAY_VALUE(rtc_tm->tm_mday) |
+			SUN6I_DATE_SET_MON_VALUE(rtc_tm->tm_mon)  |
+			SUN6I_DATE_SET_YEAR_VALUE(rtc_tm->tm_year);
 
-	if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
-		date |= SUN6I_LEAP_SET_VALUE(1);
+		if (is_leap_year(rtc_tm->tm_year + SUN6I_YEAR_MIN))
+			date |= SUN6I_LEAP_SET_VALUE(1);
+	}
 
 	time = SUN6I_TIME_SET_SEC_VALUE(rtc_tm->tm_sec)  |
 		SUN6I_TIME_SET_MIN_VALUE(rtc_tm->tm_min)  |
@@ -678,6 +700,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, chip);
 
+	chip->flags = (unsigned long)of_device_get_match_data(&pdev->dev);
+
 	chip->irq = platform_get_irq(pdev, 0);
 	if (chip->irq < 0)
 		return chip->irq;
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (3 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-22  7:29   ` Jernej Škrabec
  2021-05-19 10:41 ` [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string Andre Przywara
                   ` (11 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Alessandro Zummo, Alexandre Belloni, linux-rtc

The H616 RTC changes its day storage to the newly introduced linear day
scheme, so pair the new compatible string with this feature flag.
So far the clock parts seem to be the same as the H6, so combine the
compatible string with the existing H6 support bits.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/rtc/rtc-sun6i.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 0228e9dfd969..ec0cd0ee539a 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -382,6 +382,8 @@ static void __init sun50i_h6_rtc_clk_init(struct device_node *node)
 }
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
 		      sun50i_h6_rtc_clk_init);
+CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
+		      sun50i_h6_rtc_clk_init);
 
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
@@ -773,6 +775,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
 	{ .compatible = "allwinner,sun8i-v3-rtc" },
 	{ .compatible = "allwinner,sun50i-h5-rtc" },
 	{ .compatible = "allwinner,sun50i-h6-rtc" },
+	{ .compatible = "allwinner,sun50i-h616-rtc",
+		.data = (void *)RTC_LINEAR_DAY },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (4 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-21  1:40   ` Rob Herring
  2021-05-19 10:41 ` [PATCH v6 07/17] net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register Andre Przywara
                   ` (10 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree, David S . Miller, Jakub Kicinski, netdev

Add the obvious compatible name to the existing EMAC binding, and pair
it with the existing A64 fallback compatible string, as the devices are
compatible.

On the way use enums to group the compatible devices together.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml    | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 7f2578d48e3f..0ccdab103f59 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -19,7 +19,9 @@ properties:
       - const: allwinner,sun8i-v3s-emac
       - const: allwinner,sun50i-a64-emac
       - items:
-          - const: allwinner,sun50i-h6-emac
+          - enum:
+              - allwinner,sun50i-h6-emac
+              - allwinner,sun50i-h616-emac
           - const: allwinner,sun50i-a64-emac
 
   reg:
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 07/17] net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (5 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string Andre Przywara
                   ` (9 subsequent siblings)
  16 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	David S . Miller, Jakub Kicinski, netdev, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu

The Allwinner H616 SoC has two EMAC controllers, with the second one
being tied to the internal PHY, but also using a separate EMAC clock
register.

To tell the driver about which clock register to use, we add a parameter
to our syscon phandle. The driver will use this value as an index into
the regmap, so that we can address more than the first register, if
needed.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4422baeed3d8..5f3fefd9a74e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -1147,11 +1147,13 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 	struct stmmac_resources stmmac_res;
 	struct sunxi_priv_data *gmac;
 	struct device *dev = &pdev->dev;
+	struct reg_field syscon_field;
 	phy_interface_t interface;
 	int ret;
 	struct stmmac_priv *priv;
 	struct net_device *ndev;
 	struct regmap *regmap;
+	u32 syscon_idx = 0;
 
 	ret = stmmac_get_platform_resources(pdev, &stmmac_res);
 	if (ret)
@@ -1209,8 +1211,12 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	gmac->regmap_field = devm_regmap_field_alloc(dev, regmap,
-						     *gmac->variant->syscon_field);
+	syscon_field = *gmac->variant->syscon_field;
+	ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1,
+					 &syscon_idx);
+	if (!ret)
+		syscon_field.reg += syscon_idx * sizeof(u32);
+	gmac->regmap_field = devm_regmap_field_alloc(dev, regmap, syscon_field);
 	if (IS_ERR(gmac->regmap_field)) {
 		ret = PTR_ERR(gmac->regmap_field);
 		dev_err(dev, "Unable to map syscon register: %d\n", ret);
@@ -1330,6 +1336,8 @@ static const struct of_device_id sun8i_dwmac_match[] = {
 		.data = &emac_variant_a64 },
 	{ .compatible = "allwinner,sun50i-h6-emac",
 		.data = &emac_variant_h6 },
+	{ .compatible = "allwinner,sun50i-h616-emac",
+		.data = &emac_variant_h6 },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, sun8i_dwmac_match);
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (6 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 07/17] net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-21  1:40   ` Rob Herring
  2021-05-19 10:41 ` [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: " Andre Przywara
                   ` (8 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree, Kishon Vijay Abraham I, Vinod Koul, linux-phy,
	linux-usb

The H616 has four PHYs as the H3, along with their respective clock
gates and resets, so the property description is identical.

However the PHYs itself need some special bits, so we need a new
compatible string for it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
index f80431060803..e288450e0844 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml
@@ -15,7 +15,9 @@ properties:
     const: 1
 
   compatible:
-    const: allwinner,sun8i-h3-usb-phy
+    enum:
+      - allwinner,sun8i-h3-usb-phy
+      - allwinner,sun50i-h616-usb-phy
 
   reg:
     items:
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: Add H616 compatible string
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (7 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-21  1:40   ` Rob Herring
  2021-05-19 10:41 ` [PATCH v6 10/17] phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling Andre Przywara
                   ` (7 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree, Greg Kroah-Hartman, linux-usb

The H616 MUSB peripheral is compatible to the H3 one (8 endpoints).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
---
 .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml      | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
index 0f520f17735e..933fa356d2ce 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml
@@ -22,6 +22,9 @@ properties:
               - allwinner,sun8i-a83t-musb
               - allwinner,sun50i-h6-musb
           - const: allwinner,sun8i-a33-musb
+      - items:
+          - const: allwinner,sun50i-h616-musb
+          - const: allwinner,sun8i-h3-musb
 
   reg:
     maxItems: 1
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 10/17] phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (8 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: " Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 11/17] phy: sun4i-usb: Allow reset line to be shared Andre Przywara
                   ` (6 subsequent siblings)
  16 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Kishon Vijay Abraham I, Vinod Koul, linux-phy, linux-usb

As Icenowy pointed out, newer manuals (starting with H6) actually
document the register block at offset 0x800 as "HCI controller and PHY
interface", also describe the bits in our "PMU_UNK1" register.
Let's put proper names to those "unknown" variables and symbols.

While we are at it, generalise the existing code by allowing a bitmap
of bits to clear and set, to cover newer SoCs: The A100 and H616 use a
different bit for the SIDDQ control.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 30 ++++++++++++---------------
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index 788dd5cdbb7d..142f4cafdc78 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -43,7 +43,7 @@
 #define REG_PHYCTL_A33			0x10
 #define REG_PHY_OTGCTL			0x20
 
-#define REG_PMU_UNK1			0x10
+#define REG_HCI_PHY_CTL			0x10
 
 #define PHYCTL_DATA			BIT(7)
 
@@ -82,6 +82,7 @@
 /* A83T specific control bits for PHY0 */
 #define PHY_CTL_VBUSVLDEXT		BIT(5)
 #define PHY_CTL_SIDDQ			BIT(3)
+#define PHY_CTL_H3_SIDDQ		BIT(1)
 
 /* A83T specific control bits for PHY2 HSIC */
 #define SUNXI_EHCI_HS_FORCE		BIT(20)
@@ -115,9 +116,9 @@ struct sun4i_usb_phy_cfg {
 	int hsic_index;
 	enum sun4i_usb_phy_type type;
 	u32 disc_thresh;
+	u32 hci_phy_ctl_clear;
 	u8 phyctl_offset;
 	bool dedicated_clocks;
-	bool enable_pmu_unk1;
 	bool phy0_dual_route;
 	int missing_phys;
 };
@@ -288,6 +289,12 @@ static int sun4i_usb_phy_init(struct phy *_phy)
 		return ret;
 	}
 
+	if (phy->pmu && data->cfg->hci_phy_ctl_clear) {
+		val = readl(phy->pmu + REG_HCI_PHY_CTL);
+		val &= ~data->cfg->hci_phy_ctl_clear;
+		writel(val, phy->pmu + REG_HCI_PHY_CTL);
+	}
+
 	if (data->cfg->type == sun8i_a83t_phy ||
 	    data->cfg->type == sun50i_h6_phy) {
 		if (phy->index == 0) {
@@ -297,11 +304,6 @@ static int sun4i_usb_phy_init(struct phy *_phy)
 			writel(val, data->base + data->cfg->phyctl_offset);
 		}
 	} else {
-		if (phy->pmu && data->cfg->enable_pmu_unk1) {
-			val = readl(phy->pmu + REG_PMU_UNK1);
-			writel(val & ~2, phy->pmu + REG_PMU_UNK1);
-		}
-
 		/* Enable USB 45 Ohm resistor calibration */
 		if (phy->index == 0)
 			sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
@@ -863,7 +865,6 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = false,
-	.enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -872,7 +873,6 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
 	.disc_thresh = 2,
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = false,
-	.enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -881,7 +881,6 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -890,7 +889,6 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
 	.disc_thresh = 2,
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = false,
-	.enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -899,7 +897,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -908,7 +905,6 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
@@ -925,7 +921,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = true,
+	.hci_phy_ctl_clear = PHY_CTL_H3_SIDDQ,
 	.phy0_dual_route = true,
 };
 
@@ -935,7 +931,7 @@ static const struct sun4i_usb_phy_cfg sun8i_r40_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = true,
+	.hci_phy_ctl_clear = PHY_CTL_H3_SIDDQ,
 	.phy0_dual_route = true,
 };
 
@@ -945,7 +941,7 @@ static const struct sun4i_usb_phy_cfg sun8i_v3s_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = true,
+	.hci_phy_ctl_clear = PHY_CTL_H3_SIDDQ,
 	.phy0_dual_route = true,
 };
 
@@ -955,7 +951,7 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
 	.disc_thresh = 3,
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
-	.enable_pmu_unk1 = true,
+	.hci_phy_ctl_clear = PHY_CTL_H3_SIDDQ,
 	.phy0_dual_route = true,
 };
 
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 11/17] phy: sun4i-usb: Allow reset line to be shared
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (9 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 10/17] phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk Andre Przywara
                   ` (5 subsequent siblings)
  16 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Kishon Vijay Abraham I, Vinod Koul, linux-phy, linux-usb,
	Philipp Zabel

The USB HCIs (and PHYs?) in Allwinner's newer generation SoCs (H616)
rely on the reset line of USB PHY 2 to be de-asserted, even when only
one of the other PHYs is actually in use.

To make those ports work, we include this reset line in the HCIs' resets
property, which requires this line to be shareable.

Change the call to allocate the reset line to mark it as shared, to
enable the other ports on those SoCs.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index 142f4cafdc78..126ef74d013c 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -788,7 +788,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
 		}
 
 		snprintf(name, sizeof(name), "usb%d_reset", i);
-		phy->reset = devm_reset_control_get(dev, name);
+		phy->reset = devm_reset_control_get_shared(dev, name);
 		if (IS_ERR(phy->reset)) {
 			dev_err(dev, "failed to get reset %s\n", name);
 			return PTR_ERR(phy->reset);
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (10 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 11/17] phy: sun4i-usb: Allow reset line to be shared Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-24 11:59   ` Maxime Ripard
  2021-05-19 10:41 ` [PATCH v6 13/17] phy: sun4i-usb: Add support for the H616 USB PHY Andre Przywara
                   ` (4 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Kishon Vijay Abraham I, Vinod Koul, linux-phy, linux-usb

At least the Allwinner H616 SoC requires a weird quirk to make most
USB PHYs work: Only port2 works out of the box, but all other ports
need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
the PMU PHY control register needs to be cleared. For this register to
be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....

Instead of disguising this as some generic feature, do exactly that
in our PHY init:
If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
this one special clock, and clear the SIDDQ bit. We can pull in the
other required clocks via the DT.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 29 +++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index 126ef74d013c..ed7b9cc5a424 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -120,6 +120,7 @@ struct sun4i_usb_phy_cfg {
 	u8 phyctl_offset;
 	bool dedicated_clocks;
 	bool phy0_dual_route;
+	bool needs_phy2_siddq;
 	int missing_phys;
 };
 
@@ -331,6 +332,27 @@ static int sun4i_usb_phy_init(struct phy *_phy)
 		queue_delayed_work(system_wq, &data->detect, 0);
 	}
 
+	/* Some PHYs on some SoCs need the help of PHY2 to work. */
+	if (data->cfg->needs_phy2_siddq && phy->index != 2) {
+		struct sun4i_usb_phy *phy2 = &data->phys[2];
+
+		/*
+		 * This extra clock is just needed to access the
+		 * REG_HCI_PHY_CTL PMU register for PHY2.
+		 */
+		ret = clk_prepare_enable(phy2->clk2);
+		if (ret)
+			return ret;
+
+		if (phy2->pmu && data->cfg->hci_phy_ctl_clear) {
+			val = readl(phy2->pmu + REG_HCI_PHY_CTL);
+			val &= ~data->cfg->hci_phy_ctl_clear;
+			writel(val, phy2->pmu + REG_HCI_PHY_CTL);
+		}
+
+		clk_disable_unprepare(phy->clk2);
+	}
+
 	return 0;
 }
 
@@ -785,6 +807,13 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
 				dev_err(dev, "failed to get clock %s\n", name);
 				return PTR_ERR(phy->clk2);
 			}
+		} else {
+			snprintf(name, sizeof(name), "pmu%d_clk", i);
+			phy->clk2 = devm_clk_get_optional(dev, name);
+			if (IS_ERR(phy->clk2)) {
+				dev_err(dev, "failed to get clock %s\n", name);
+				return PTR_ERR(phy->clk2);
+			}
 		}
 
 		snprintf(name, sizeof(name), "usb%d_reset", i);
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 13/17] phy: sun4i-usb: Add support for the H616 USB PHY
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (11 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file Andre Przywara
                   ` (3 subsequent siblings)
  16 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Kishon Vijay Abraham I, Vinod Koul, linux-phy, linux-usb

The USB PHY used in the Allwinner H616 SoC inherits some traits from its
various predecessors: it has four full PHYs like the H3, needs some
extra bits to be set like the H6, and puts SIDDQ on a different bit like
the A100. Plus it needs this weird PHY2 quirk.

Name all those properties in a new config struct and assign a new
compatible name to it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 drivers/phy/allwinner/phy-sun4i-usb.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c
index ed7b9cc5a424..a55765ad7bad 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -994,6 +994,17 @@ static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
 	.missing_phys = BIT(1) | BIT(2),
 };
 
+static const struct sun4i_usb_phy_cfg sun50i_h616_cfg = {
+	.num_phys = 4,
+	.type = sun50i_h6_phy,
+	.disc_thresh = 3,
+	.phyctl_offset = REG_PHYCTL_A33,
+	.dedicated_clocks = true,
+	.phy0_dual_route = true,
+	.hci_phy_ctl_clear = PHY_CTL_SIDDQ,
+	.needs_phy2_siddq = true,
+};
+
 static const struct of_device_id sun4i_usb_phy_of_match[] = {
 	{ .compatible = "allwinner,sun4i-a10-usb-phy", .data = &sun4i_a10_cfg },
 	{ .compatible = "allwinner,sun5i-a13-usb-phy", .data = &sun5i_a13_cfg },
@@ -1008,6 +1019,7 @@ static const struct of_device_id sun4i_usb_phy_of_match[] = {
 	{ .compatible = "allwinner,sun50i-a64-usb-phy",
 	  .data = &sun50i_a64_cfg},
 	{ .compatible = "allwinner,sun50i-h6-usb-phy", .data = &sun50i_h6_cfg },
+	{ .compatible = "allwinner,sun50i-h616-usb-phy", .data = &sun50i_h616_cfg },
 	{ },
 };
 MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (12 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 13/17] phy: sun4i-usb: Add support for the H616 USB PHY Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-24 12:02   ` Maxime Ripard
  2021-05-19 10:41 ` [PATCH v6 15/17] dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding Andre Przywara
                   ` (2 subsequent siblings)
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree

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.

USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
controller and PHY 2, so we need to include one reset line and one
clock gate from HCI 2 into every other HCI node, plus need some nasty
quirk.

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 | 747 ++++++++++++++++++
 1 file changed, 747 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..30195e4779de
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -0,0 +1,747 @@
+// 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 {
+		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>;
+			status = "okay";
+		};
+
+		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;
+			mmc-ddr-1_8v;
+			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;
+			mmc-ddr-1_8v;
+			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;
+			mmc-ddr-1_8v;
+			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>;
+			};
+		};
+
+		usbotg: usb@5100000 {
+			compatible = "allwinner,sun50i-h616-musb",
+				     "allwinner,sun8i-h3-musb";
+			reg = <0x05100000 0x0400>;
+			clocks = <&ccu CLK_BUS_OTG>;
+			resets = <&ccu RST_BUS_OTG>;
+			interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "mc";
+			phys = <&usbphy 0>;
+			phy-names = "usb";
+			extcon = <&usbphy 0>;
+			status = "disabled";
+		};
+
+		usbphy: phy@5100400 {
+			compatible = "allwinner,sun50i-h616-usb-phy";
+			reg = <0x05100400 0x24>,
+			      <0x05101800 0x14>,
+			      <0x05200800 0x14>,
+			      <0x05310800 0x14>,
+			      <0x05311800 0x14>;
+			reg-names = "phy_ctrl",
+				    "pmu0",
+				    "pmu1",
+				    "pmu2",
+				    "pmu3";
+			clocks = <&ccu CLK_USB_PHY0>,
+				 <&ccu CLK_USB_PHY1>,
+				 <&ccu CLK_USB_PHY2>,
+				 <&ccu CLK_USB_PHY3>,
+				 <&ccu CLK_BUS_EHCI2>;
+			clock-names = "usb0_phy",
+				      "usb1_phy",
+				      "usb2_phy",
+				      "usb3_phy",
+				      "pmu2_clk";
+			resets = <&ccu RST_USB_PHY0>,
+				 <&ccu RST_USB_PHY1>,
+				 <&ccu RST_USB_PHY2>,
+				 <&ccu RST_USB_PHY3>;
+			reset-names = "usb0_reset",
+				      "usb1_reset",
+				      "usb2_reset",
+				      "usb3_reset";
+			status = "disabled";
+			#phy-cells = <1>;
+		};
+
+		ehci0: usb@5101000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05101000 0x100>;
+			interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI0>,
+				 <&ccu CLK_BUS_EHCI0>,
+				 <&ccu CLK_USB_OHCI0>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI0>,
+				 <&ccu RST_BUS_EHCI0>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 0>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci0: usb@5101400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05101400 0x100>;
+			interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI0>,
+				 <&ccu CLK_USB_OHCI0>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI0>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 0>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ehci1: usb@5200000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05200000 0x100>;
+			interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI1>,
+				 <&ccu CLK_BUS_EHCI1>,
+				 <&ccu CLK_USB_OHCI1>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI1>,
+				 <&ccu RST_BUS_EHCI1>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 1>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci1: usb@5200400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05200400 0x100>;
+			interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI1>,
+				 <&ccu CLK_USB_OHCI1>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI1>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 1>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ehci2: usb@5310000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05310000 0x100>;
+			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI2>,
+				 <&ccu CLK_BUS_EHCI2>,
+				 <&ccu CLK_USB_OHCI2>;
+			resets = <&ccu RST_BUS_OHCI2>,
+				 <&ccu RST_BUS_EHCI2>;
+			phys = <&usbphy 2>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci2: usb@5310400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05310400 0x100>;
+			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI2>,
+				 <&ccu CLK_USB_OHCI2>;
+			resets = <&ccu RST_BUS_OHCI2>;
+			phys = <&usbphy 2>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ehci3: usb@5311000 {
+			compatible = "allwinner,sun50i-h616-ehci",
+				     "generic-ehci";
+			reg = <0x05311000 0x100>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI3>,
+				 <&ccu CLK_BUS_EHCI3>,
+				 <&ccu CLK_USB_OHCI3>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI3>,
+				 <&ccu RST_BUS_EHCI3>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 3>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		ohci3: usb@5311400 {
+			compatible = "allwinner,sun50i-h616-ohci",
+				     "generic-ohci";
+			reg = <0x05311400 0x100>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_OHCI3>,
+				 <&ccu CLK_USB_OHCI3>,
+				 <&ccu CLK_USB_PHY2>;
+			resets = <&ccu RST_BUS_OHCI3>,
+				 <&ccu RST_USB_PHY2>;
+			phys = <&usbphy 3>;
+			phy-names = "usb";
+			status = "disabled";
+		};
+
+		rtc: rtc@7000000 {
+			compatible = "allwinner,sun50i-h616-rtc";
+			reg = <0x07000000 0x400>;
+			interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+			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.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 15/17] dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (13 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 16/17] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support Andre Przywara
  16 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index ac750025a2eb..1ca550062a85 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -937,4 +937,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
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 16/17] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (14 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 15/17] dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-19 10:41 ` [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support Andre Przywara
  16 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree

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  | 245 ++++++++++++++++++
 2 files changed, 246 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 41ce680e5f8d..9ba4b5d92657 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
 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-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..a26201288872
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
@@ -0,0 +1,245 @@
+// 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;
+	};
+
+	reg_usb1_vbus: usb1-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb1-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&reg_vcc5v>;
+		enable-active-high;
+		gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
+		status = "okay";
+	};
+};
+
+&ehci1 {
+	status = "okay";
+};
+
+/* USB 2 & 3 are on headers only. */
+
+&emac0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ext_rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-handle = <&ext_rgmii_phy>;
+	phy-supply = <&reg_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 = <&reg_dcdce>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&ohci1 {
+	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 = <&reg_vcc5v>;
+		vinb-supply = <&reg_vcc5v>;
+		vinc-supply = <&reg_vcc5v>;
+		vind-supply = <&reg_vcc5v>;
+		vine-supply = <&reg_vcc5v>;
+		aldoin-supply = <&reg_vcc5v>;
+		bldoin-supply = <&reg_vcc5v>;
+		cldoin-supply = <&reg_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";
+};
+
+&usbotg {
+	/*
+	 * PHY0 pins are connected to a USB-C socket, but a role switch
+	 * is not implemented: both CC pins are pulled to GND.
+	 * The VBUS pins power the device, so a fixed peripheral mode
+	 * is the best choice.
+	 * The board can be powered via GPIOs, in this case port0 *can*
+	 * act as a host (with a cable/adapter ignoring CC), as VBUS is
+	 * then provided by the GPIOs. Any user of this setup would
+	 * need to adjust the DT accordingly: dr_mode set to "host",
+	 * enabling OHCI0 and EHCI0.
+	 */
+	dr_mode = "peripheral";
+	status = "okay";
+};
+
+&usbphy {
+	usb1_vbus-supply = <&reg_usb1_vbus>;
+	status = "okay";
+};
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support
  2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
                   ` (15 preceding siblings ...)
  2021-05-19 10:41 ` [PATCH v6 16/17] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support Andre Przywara
@ 2021-05-19 10:41 ` Andre Przywara
  2021-05-22  7:32   ` Jernej Škrabec
  16 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-19 10:41 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree

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, eMMC and USB 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    | 201 ++++++++++++++++++
 2 files changed, 202 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 9ba4b5d92657..370d24ebaacf 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -37,3 +37,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-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..b960bb310289
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
@@ -0,0 +1,201 @@
+// 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;
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci2 {
+	status = "okay";
+};
+
+&ir {
+	status = "okay";
+};
+
+&mmc0 {
+	vmmc-supply = <&reg_dcdce>;
+	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
+	bus-width = <4>;
+	status = "okay";
+};
+
+&mmc2 {
+	vmmc-supply = <&reg_dcdce>;
+	vqmmc-supply = <&reg_bldo1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	mmc-hs200-1_8v;
+	status = "okay";
+};
+
+&ohci0 {
+	status = "okay";
+};
+
+&ohci2 {
+	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 = <&reg_vcc5v>;
+		vinb-supply = <&reg_vcc5v>;
+		vinc-supply = <&reg_vcc5v>;
+		vind-supply = <&reg_vcc5v>;
+		vine-supply = <&reg_vcc5v>;
+		aldoin-supply = <&reg_vcc5v>;
+		bldoin-supply = <&reg_vcc5v>;
+		cldoin-supply = <&reg_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";
+};
+
+&usbotg {
+	dr_mode = "host";	/* USB A type receptable */
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+};
-- 
2.17.5


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines
  2021-05-19 10:41 ` [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines Andre Przywara
@ 2021-05-19 15:01   ` Lee Jones
  0 siblings, 0 replies; 45+ messages in thread
From: Lee Jones @ 2021-05-19 15:01 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Samuel Holland, Ondrej Jirman, linux-arm-kernel,
	linux-sunxi, linux-sunxi, linux-kernel

On Wed, 19 May 2021, Andre Przywara wrote:

> Currently the AXP chip requires to have its IRQ line connected to some
> interrupt controller, and will fail probing when this is not the case.
> 
> On a new Allwinner SoC (H616) there is no NMI pin anymore, and at
> least one board does not connect the AXP's IRQ pin to anything else,
> so the interrupt functionality of the AXP chip is simply not available.
> 
> Check whether the interrupt line number returned by the platform code is
> valid, before trying to register the irqchip. If not, we skip this
> registration, to avoid the driver to bail out completely.
> Also we need to skip the power key functionality, as this relies on
> a valid IRQ as well.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/mfd/axp20x.c | 24 +++++++++++++++++-------
>  1 file changed, 17 insertions(+), 7 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  2021-05-19 10:41 ` [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) Andre Przywara
@ 2021-05-21  1:39   ` Rob Herring
  2021-05-22 14:46   ` Samuel Holland
  1 sibling, 0 replies; 45+ messages in thread
From: Rob Herring @ 2021-05-21  1:39 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Lee Jones

On Wed, May 19, 2021 at 11:41:36AM +0100, Andre Przywara wrote:
> The AXP305 PMIC used in AXP805 seems to be fully compatible to the
> AXP805 PMIC, so add the proper chain of compatible strings.
> 
> Also at least on one board (Orangepi Zero2) there is no interrupt line
> connected to the CPU, so make the "interrupts" property optional.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Don't you want to convert this to schema? It's one of the last warnings 
for sunxi IIRC.

Acked-by: Rob Herring <robh@kernel.org>

> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 4991a6415796..4fd748101e3c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -26,10 +26,10 @@ Required properties:
>      * "x-powers,axp803"
>      * "x-powers,axp806"
>      * "x-powers,axp805", "x-powers,axp806"
> +    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
>      * "x-powers,axp809"
>      * "x-powers,axp813"
>  - reg: The I2C slave address or RSB hardware address for the AXP chip
> -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - interrupt-controller: The PMIC has its own internal IRQs
>  - #interrupt-cells: Should be set to 1
>  
> @@ -43,6 +43,7 @@ more information:
>  			AXP20x/LDO3: software-based implementation
>  
>  Optional properties:
> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
>  		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
>  		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> -- 
> 2.17.5
> 

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-05-19 10:41 ` [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Andre Przywara
@ 2021-05-21  1:39   ` Rob Herring
  2021-05-21  2:37   ` Samuel Holland
  1 sibling, 0 replies; 45+ messages in thread
From: Rob Herring @ 2021-05-21  1:39 UTC (permalink / raw)
  To: Andre Przywara
  Cc: linux-rtc, linux-kernel, linux-arm-kernel, linux-sunxi,
	Samuel Holland, Alessandro Zummo, Ondrej Jirman, devicetree,
	Chen-Yu Tsai, Icenowy Zheng, Alexandre Belloni, Maxime Ripard,
	Jernej Skrabec, linux-sunxi

On Wed, 19 May 2021 11:41:38 +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string
  2021-05-19 10:41 ` [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string Andre Przywara
@ 2021-05-21  1:40   ` Rob Herring
  0 siblings, 0 replies; 45+ messages in thread
From: Rob Herring @ 2021-05-21  1:40 UTC (permalink / raw)
  To: Andre Przywara
  Cc: David S . Miller, Jernej Skrabec, Chen-Yu Tsai, netdev,
	linux-sunxi, devicetree, Samuel Holland, linux-arm-kernel,
	linux-sunxi, linux-kernel, Icenowy Zheng, Ondrej Jirman,
	Jakub Kicinski, Maxime Ripard

On Wed, 19 May 2021 11:41:41 +0100, Andre Przywara wrote:
> Add the obvious compatible name to the existing EMAC binding, and pair
> it with the existing A64 fallback compatible string, as the devices are
> compatible.
> 
> On the way use enums to group the compatible devices together.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml    | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string
  2021-05-19 10:41 ` [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string Andre Przywara
@ 2021-05-21  1:40   ` Rob Herring
  0 siblings, 0 replies; 45+ messages in thread
From: Rob Herring @ 2021-05-21  1:40 UTC (permalink / raw)
  To: Andre Przywara
  Cc: linux-arm-kernel, Icenowy Zheng, Vinod Koul, linux-kernel,
	devicetree, Maxime Ripard, linux-phy, Chen-Yu Tsai,
	Ondrej Jirman, Jernej Skrabec, linux-sunxi,
	Kishon Vijay Abraham I, linux-usb, linux-sunxi, Samuel Holland

On Wed, 19 May 2021 11:41:43 +0100, Andre Przywara wrote:
> The H616 has four PHYs as the H3, along with their respective clock
> gates and resets, so the property description is identical.
> 
> However the PHYs itself need some special bits, so we need a new
> compatible string for it.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml   | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: Add H616 compatible string
  2021-05-19 10:41 ` [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: " Andre Przywara
@ 2021-05-21  1:40   ` Rob Herring
  0 siblings, 0 replies; 45+ messages in thread
From: Rob Herring @ 2021-05-21  1:40 UTC (permalink / raw)
  To: Andre Przywara
  Cc: devicetree, Samuel Holland, linux-kernel, Greg Kroah-Hartman,
	linux-arm-kernel, Jernej Skrabec, Chen-Yu Tsai, Maxime Ripard,
	linux-sunxi, linux-usb, Icenowy Zheng, linux-sunxi,
	Ondrej Jirman

On Wed, 19 May 2021 11:41:44 +0100, Andre Przywara wrote:
> The H616 MUSB peripheral is compatible to the H3 one (8 endpoints).
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>
> ---
>  .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml      | 3 +++
>  1 file changed, 3 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-05-19 10:41 ` [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Andre Przywara
  2021-05-21  1:39   ` Rob Herring
@ 2021-05-21  2:37   ` Samuel Holland
  2021-06-07 12:59     ` Andre Przywara
  1 sibling, 1 reply; 45+ messages in thread
From: Samuel Holland @ 2021-05-21  2:37 UTC (permalink / raw)
  To: Andre Przywara, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Ondrej Jirman, linux-arm-kernel,
	linux-sunxi, linux-sunxi, linux-kernel, devicetree,
	Alessandro Zummo, Alexandre Belloni, linux-rtc

Andre,

On 5/19/21 5:41 AM, Andre Przywara wrote:
> Add the obvious compatible name to the existing RTC binding.
> The actual RTC part of the device uses a different day/month/year
> storage scheme, so it's not compatible with the previous devices.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> index b1b0ee769b71..178c955f88bf 100644
> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> @@ -26,6 +26,7 @@ properties:
>            - const: allwinner,sun50i-a64-rtc
>            - const: allwinner,sun8i-h3-rtc
>        - const: allwinner,sun50i-h6-rtc
> +      - const: allwinner,sun50i-h616-rtc
>  
>    reg:
>      maxItems: 1
> @@ -97,7 +98,9 @@ allOf:
>        properties:
>          compatible:
>            contains:
> -            const: allwinner,sun50i-h6-rtc
> +            enum:
> +              - allwinner,sun50i-h6-rtc
> +              - allwinner,sun50i-h616-rtc
>  
>      then:
>        properties:
> 

This binding is missing a clock reference for the pll-periph0-2x input
to the 32kHz clock fanout.

It is also missing a clock reference to the RTC register gate (and that
clock is in turn missing from the r_ccu driver).

Regards,
Samuel

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage
  2021-05-19 10:41 ` [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage Andre Przywara
@ 2021-05-22  7:26   ` Jernej Škrabec
  0 siblings, 0 replies; 45+ messages in thread
From: Jernej Škrabec @ 2021-05-22  7:26 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Andre Przywara
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Alessandro Zummo, Alexandre Belloni, linux-rtc

Hi Andre!

Dne sreda, 19. maj 2021 ob 12:41:39 CEST je Andre Przywara napisal(a):
> Newer versions of the Allwinner RTC, as for instance found in the H616
> SoC, no longer store a broken-down day/month/year representation in the
> RTC_DAY_REG, but just a linear day number.
> The user manual does not give any indication about the expected epoch
> time of this day count, but the BSP kernel uses the UNIX epoch, which
> allows easy support due to existing conversion functions in the kernel.
> 
> Allow tagging a compatible string with a flag, and use that to mark
> those new RTCs. Then convert between a UNIX day number (converted into
> seconds) and the broken-down day representation using mktime64() and
> time64_to_tm() in the set_time/get_time functions.
> 
> That enables support for the RTC in those new chips.
> 
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>

Change ^ to Signed-of-by. After that, you can add:
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej



^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support
  2021-05-19 10:41 ` [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support Andre Przywara
@ 2021-05-22  7:29   ` Jernej Škrabec
  2021-05-23  0:06     ` Andre Przywara
  0 siblings, 1 reply; 45+ messages in thread
From: Jernej Škrabec @ 2021-05-22  7:29 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Andre Przywara
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	Alessandro Zummo, Alexandre Belloni, linux-rtc

Hi Andre!

Dne sreda, 19. maj 2021 ob 12:41:40 CEST je Andre Przywara napisal(a):
> The H616 RTC changes its day storage to the newly introduced linear day
> scheme, so pair the new compatible string with this feature flag.
> So far the clock parts seem to be the same as the H6, so combine the
> compatible string with the existing H6 support bits.

There is one more difference - H616 alarm value is now broken down to days, 
hours, minutes and seconds.

Best regards,
Jernej

> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  drivers/rtc/rtc-sun6i.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index 0228e9dfd969..ec0cd0ee539a 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -382,6 +382,8 @@ static void __init sun50i_h6_rtc_clk_init(struct 
device_node *node)
>  }
>  CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
>  		      sun50i_h6_rtc_clk_init);
> +CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
> +		      sun50i_h6_rtc_clk_init);
>  
>  /*
>   * The R40 user manual is self-conflicting on whether the prescaler is
> @@ -773,6 +775,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
>  	{ .compatible = "allwinner,sun8i-v3-rtc" },
>  	{ .compatible = "allwinner,sun50i-h5-rtc" },
>  	{ .compatible = "allwinner,sun50i-h6-rtc" },
> +	{ .compatible = "allwinner,sun50i-h616-rtc",
> +		.data = (void *)RTC_LINEAR_DAY },
>  	{ /* sentinel */ },
>  };
>  MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
> -- 
> 2.17.5
> 
> 



^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support
  2021-05-19 10:41 ` [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support Andre Przywara
@ 2021-05-22  7:32   ` Jernej Škrabec
  0 siblings, 0 replies; 45+ messages in thread
From: Jernej Škrabec @ 2021-05-22  7:32 UTC (permalink / raw)
  To: Maxime Ripard, Chen-Yu Tsai, Andre Przywara
  Cc: Rob Herring, Icenowy Zheng, Samuel Holland, Ondrej Jirman,
	linux-arm-kernel, linux-sunxi, linux-sunxi, linux-kernel,
	devicetree

Hi Andre!

Dne sreda, 19. maj 2021 ob 12:41:52 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
> 
> Add a basic devicetree for it, with SD card, eMMC and USB 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    | 201 ++++++++++++++++++
>  2 files changed, 202 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 9ba4b5d92657..370d24ebaacf 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -37,3 +37,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-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..b960bb310289
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-x96-mate.dts
> @@ -0,0 +1,201 @@
> +// 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";

Please document compatible.

Best regards,
Jernej

> +
> +	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;
> +	};
> +};
> +
> +&ehci0 {
> +	status = "okay";
> +};
> +
> +&ehci2 {
> +	status = "okay";
> +};
> +
> +&ir {
> +	status = "okay";
> +};
> +
> +&mmc0 {
> +	vmmc-supply = <&reg_dcdce>;
> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;	/* PF6 */
> +	bus-width = <4>;
> +	status = "okay";
> +};
> +
> +&mmc2 {
> +	vmmc-supply = <&reg_dcdce>;
> +	vqmmc-supply = <&reg_bldo1>;
> +	bus-width = <8>;
> +	non-removable;
> +	cap-mmc-hw-reset;
> +	mmc-hs200-1_8v;
> +	status = "okay";
> +};
> +
> +&ohci0 {
> +	status = "okay";
> +};
> +
> +&ohci2 {
> +	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 = <&reg_vcc5v>;
> +		vinb-supply = <&reg_vcc5v>;
> +		vinc-supply = <&reg_vcc5v>;
> +		vind-supply = <&reg_vcc5v>;
> +		vine-supply = <&reg_vcc5v>;
> +		aldoin-supply = <&reg_vcc5v>;
> +		bldoin-supply = <&reg_vcc5v>;
> +		cldoin-supply = <&reg_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";
> +};
> +
> +&usbotg {
> +	dr_mode = "host";	/* USB A type receptable */
> +	status = "okay";
> +};
> +
> +&usbphy {
> +	status = "okay";
> +};
> -- 
> 2.17.5
> 
> 



^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  2021-05-19 10:41 ` [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) Andre Przywara
  2021-05-21  1:39   ` Rob Herring
@ 2021-05-22 14:46   ` Samuel Holland
  2021-05-23  0:01     ` Andre Przywara
  1 sibling, 1 reply; 45+ messages in thread
From: Samuel Holland @ 2021-05-22 14:46 UTC (permalink / raw)
  To: Andre Przywara, Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec
  Cc: Rob Herring, Icenowy Zheng, Ondrej Jirman, linux-arm-kernel,
	linux-sunxi, linux-sunxi, linux-kernel, devicetree, Lee Jones

On 5/19/21 5:41 AM, Andre Przywara wrote:
> The AXP305 PMIC used in AXP805 seems to be fully compatible to the
                  ^^^^^^^^^^^^^^
Typo? Do you mean "used with the H616 SoC"?

> AXP805 PMIC, so add the proper chain of compatible strings.
> 
> Also at least on one board (Orangepi Zero2) there is no interrupt line
> connected to the CPU, so make the "interrupts" property optional.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 4991a6415796..4fd748101e3c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -26,10 +26,10 @@ Required properties:
>      * "x-powers,axp803"
>      * "x-powers,axp806"
>      * "x-powers,axp805", "x-powers,axp806"
> +    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"
                   ^^^^^^
This should be x-powers,axp305.

Regards,
Samuel

>      * "x-powers,axp809"
>      * "x-powers,axp813"
>  - reg: The I2C slave address or RSB hardware address for the AXP chip
> -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - interrupt-controller: The PMIC has its own internal IRQs
>  - #interrupt-cells: Should be set to 1
>  
> @@ -43,6 +43,7 @@ more information:
>  			AXP20x/LDO3: software-based implementation
>  
>  Optional properties:
> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
>  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
>  		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
>  		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> 


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ)
  2021-05-22 14:46   ` Samuel Holland
@ 2021-05-23  0:01     ` Andre Przywara
  0 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-23  0:01 UTC (permalink / raw)
  To: Samuel Holland
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Lee Jones

On Sat, 22 May 2021 09:46:23 -0500
Samuel Holland <samuel@sholland.org> wrote:

> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > The AXP305 PMIC used in AXP805 seems to be fully compatible to the  
>                   ^^^^^^^^^^^^^^
> Typo? Do you mean "used with the H616 SoC"?

Ouch, yes. And even more embarrassingly Chen-Yu pointed that out already
in the previous version. Same for the compatible string.

Thanks for having a look!

Cheers,
Andre

> 
> > AXP805 PMIC, so add the proper chain of compatible strings.
> > 
> > Also at least on one board (Orangepi Zero2) there is no interrupt line
> > connected to the CPU, so make the "interrupts" property optional.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> > index 4991a6415796..4fd748101e3c 100644
> > --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> > +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> > @@ -26,10 +26,10 @@ Required properties:
> >      * "x-powers,axp803"
> >      * "x-powers,axp806"
> >      * "x-powers,axp805", "x-powers,axp806"
> > +    * "x-powers,axp803", "x-powers,axp805", "x-powers,axp806"  
>                    ^^^^^^
> This should be x-powers,axp305.
> 
> Regards,
> Samuel
> 
> >      * "x-powers,axp809"
> >      * "x-powers,axp813"
> >  - reg: The I2C slave address or RSB hardware address for the AXP chip
> > -- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >  - interrupt-controller: The PMIC has its own internal IRQs
> >  - #interrupt-cells: Should be set to 1
> >  
> > @@ -43,6 +43,7 @@ more information:
> >  			AXP20x/LDO3: software-based implementation
> >  
> >  Optional properties:
> > +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >  - x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
> >  		      AXP152/20X: range:  750-1875, Default: 1.5 MHz
> >  		      AXP22X/8XX: range: 1800-4050, Default: 3   MHz
> >   
> 
> 


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support
  2021-05-22  7:29   ` Jernej Škrabec
@ 2021-05-23  0:06     ` Andre Przywara
  0 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-05-23  0:06 UTC (permalink / raw)
  To: Jernej Škrabec
  Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Alessandro Zummo, Alexandre Belloni,
	linux-rtc

On Sat, 22 May 2021 09:29:26 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:

Hi,

> Dne sreda, 19. maj 2021 ob 12:41:40 CEST je Andre Przywara napisal(a):
> > The H616 RTC changes its day storage to the newly introduced linear day
> > scheme, so pair the new compatible string with this feature flag.
> > So far the clock parts seem to be the same as the H6, so combine the
> > compatible string with the existing H6 support bits.  
> 
> There is one more difference - H616 alarm value is now broken down to days, 
> hours, minutes and seconds.

That's a good point, that actually requires adjusting the driver in
this respect as well. And contrary to what the manual says ("Counter
Register will down count to zero"), and the previous RTCs do, those alarm
registers now need to be set to the actual wakeup time, not the time
left before wakeup.
Will fix the driver accordingly.

Thanks for the heads up!

Cheers,
Andre

> 
> Best regards,
> Jernej
> 
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  drivers/rtc/rtc-sun6i.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > index 0228e9dfd969..ec0cd0ee539a 100644
> > --- a/drivers/rtc/rtc-sun6i.c
> > +++ b/drivers/rtc/rtc-sun6i.c
> > @@ -382,6 +382,8 @@ static void __init sun50i_h6_rtc_clk_init(struct   
> device_node *node)
> >  }
> >  CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
> >  		      sun50i_h6_rtc_clk_init);
> > +CLK_OF_DECLARE_DRIVER(sun50i_h616_rtc_clk, "allwinner,sun50i-h616-rtc",
> > +		      sun50i_h6_rtc_clk_init);
> >  
> >  /*
> >   * The R40 user manual is self-conflicting on whether the prescaler is
> > @@ -773,6 +775,8 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
> >  	{ .compatible = "allwinner,sun8i-v3-rtc" },
> >  	{ .compatible = "allwinner,sun50i-h5-rtc" },
> >  	{ .compatible = "allwinner,sun50i-h6-rtc" },
> > +	{ .compatible = "allwinner,sun50i-h616-rtc",
> > +		.data = (void *)RTC_LINEAR_DAY },
> >  	{ /* sentinel */ },
> >  };
> >  MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
> > -- 
> > 2.17.5
> > 
> >   
> 
> 


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-05-19 10:41 ` [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk Andre Przywara
@ 2021-05-24 11:59   ` Maxime Ripard
  2021-05-24 12:51     ` Jernej Škrabec
  2021-05-25 11:29     ` Andre Przywara
  0 siblings, 2 replies; 45+ messages in thread
From: Maxime Ripard @ 2021-05-24 11:59 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Kishon Vijay Abraham I, Vinod Koul,
	linux-phy, linux-usb

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

Hi

On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
> At least the Allwinner H616 SoC requires a weird quirk to make most
> USB PHYs work: Only port2 works out of the box, but all other ports
> need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> the PMU PHY control register needs to be cleared. For this register to
> be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> 
> Instead of disguising this as some generic feature, do exactly that
> in our PHY init:
> If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> this one special clock, and clear the SIDDQ bit. We can pull in the
> other required clocks via the DT.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>

What is this SIDDQ bit doing exactly?

I guess we could also expose this using a power-domain if it's relevant?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  2021-05-19 10:41 ` [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file Andre Przywara
@ 2021-05-24 12:02   ` Maxime Ripard
  2021-06-07 12:59     ` Andre Przywara
  0 siblings, 1 reply; 45+ messages in thread
From: Maxime Ripard @ 2021-05-24 12:02 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Hi,

On Wed, May 19, 2021 at 11:41:49AM +0100, Andre Przywara wrote:
> 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.
> 
> USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
> controller and PHY 2, so we need to include one reset line and one
> clock gate from HCI 2 into every other HCI node, plus need some nasty
> quirk.
> 
> 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>

As far as I can see, the IOMMU hasn't changed between the H6 and the
H616, so it would be worth enabling

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-05-24 11:59   ` Maxime Ripard
@ 2021-05-24 12:51     ` Jernej Škrabec
  2021-05-25 11:29     ` Andre Przywara
  1 sibling, 0 replies; 45+ messages in thread
From: Jernej Škrabec @ 2021-05-24 12:51 UTC (permalink / raw)
  To: Andre Przywara, Maxime Ripard
  Cc: Chen-Yu Tsai, Rob Herring, Icenowy Zheng, Samuel Holland,
	Ondrej Jirman, linux-arm-kernel, linux-sunxi, linux-sunxi,
	linux-kernel, Kishon Vijay Abraham I, Vinod Koul, linux-phy,
	linux-usb

Dne ponedeljek, 24. maj 2021 ob 13:59:46 CEST je Maxime Ripard napisal(a):
> Hi
> 
> On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
> > At least the Allwinner H616 SoC requires a weird quirk to make most
> > USB PHYs work: Only port2 works out of the box, but all other ports
> > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > the PMU PHY control register needs to be cleared. For this register to
> > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> > 
> > Instead of disguising this as some generic feature, do exactly that
> > in our PHY init:
> > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > this one special clock, and clear the SIDDQ bit. We can pull in the
> > other required clocks via the DT.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> 
> What is this SIDDQ bit doing exactly?

If this is similar to Rockchip USB PHY, then this bit takes care for powering 
up/down analog parts of USB PHY:
https://elixir.bootlin.com/linux/latest/source/drivers/phy/rockchip/phy-rockchip-usb.c#L83

Best regards,
Jernej

> 
> I guess we could also expose this using a power-domain if it's relevant?
> 
> Maxime





^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-05-24 11:59   ` Maxime Ripard
  2021-05-24 12:51     ` Jernej Škrabec
@ 2021-05-25 11:29     ` Andre Przywara
  2021-06-07 13:22       ` Maxime Ripard
  1 sibling, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-05-25 11:29 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Kishon Vijay Abraham I, Vinod Koul,
	linux-phy, linux-usb

On Mon, 24 May 2021 13:59:46 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

Hi Maxime,

> On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
> > At least the Allwinner H616 SoC requires a weird quirk to make most
> > USB PHYs work: Only port2 works out of the box, but all other ports
> > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > the PMU PHY control register needs to be cleared. For this register to
> > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> > 
> > Instead of disguising this as some generic feature, do exactly that
> > in our PHY init:
> > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > this one special clock, and clear the SIDDQ bit. We can pull in the
> > other required clocks via the DT.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>  
> 
> What is this SIDDQ bit doing exactly?

I probably know as much as you do, but as Jernej pointed out, in some
Rockchip code it's indeed documented as some analogue PHY supply switch:
($ git grep -i siddq drivers/phy/rockchip)

In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.

> I guess we could also expose this using a power-domain if it's relevant?

Mmmh, interesting idea. So are you thinking about registering a genpd
provider in sun4i_usb_phy_probe(), then having a power-domains property
in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
the provider be a subnode of the USB PHY node, with a separate
compatible? That sounds a bit more involved, but would have the
advantage of allowing us to specify the resets and clocks from PHY2
there, and would look a bit cleaner than hacking them into the
other EHCI/OHCI nodes.

I would not touch the existing SoCs (even though it seems to apply to
them as well, just not in the exact same way), but I can give it a
try for the H616. It seems like the other SIDDQ bits (in the other
PHYs) are still needed for operation, but the PD provide could actually
take care of this as well.

Does that make sense or is this a bit over the top for just clearing an
extra bit?

Cheers,
Andre

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-05-21  2:37   ` Samuel Holland
@ 2021-06-07 12:59     ` Andre Przywara
  2021-06-08  4:23       ` Samuel Holland
  0 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-06-07 12:59 UTC (permalink / raw)
  To: Samuel Holland
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Alessandro Zummo,
	Alexandre Belloni, linux-rtc

On Thu, 20 May 2021 21:37:34 -0500
Samuel Holland <samuel@sholland.org> wrote:

Hi,

> On 5/19/21 5:41 AM, Andre Przywara wrote:
> > Add the obvious compatible name to the existing RTC binding.
> > The actual RTC part of the device uses a different day/month/year
> > storage scheme, so it's not compatible with the previous devices.
> > 
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > index b1b0ee769b71..178c955f88bf 100644
> > --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > @@ -26,6 +26,7 @@ properties:
> >            - const: allwinner,sun50i-a64-rtc
> >            - const: allwinner,sun8i-h3-rtc
> >        - const: allwinner,sun50i-h6-rtc
> > +      - const: allwinner,sun50i-h616-rtc
> >  
> >    reg:
> >      maxItems: 1
> > @@ -97,7 +98,9 @@ allOf:
> >        properties:
> >          compatible:
> >            contains:
> > -            const: allwinner,sun50i-h6-rtc
> > +            enum:
> > +              - allwinner,sun50i-h6-rtc
> > +              - allwinner,sun50i-h616-rtc
> >  
> >      then:
> >        properties:
> >   
> 
> This binding is missing a clock reference for the pll-periph0-2x input
> to the 32kHz clock fanout.

Right. So do I get this correctly that we don't model the OSC24M input
explicitly so far in the DT? I only see one possible input clock, which
is for an optional 32K crystal oscillator.
And this means we need to change some code also? Because at the moment
a clock specified is assumed to be the 32K OSC, and having this clock
means we switch to the external 32K OSC.
And who would decide which clock source to use? What would be the
reason to use PLL_PERIPH(2x) over the RC16M based clock or the
divided down 24MHz?

So shall we ignore the PLL based input clock for now, put "0 input
clocks" in the current binding, then later on extend this to allow
choosing the PLL? And have it that way that having the PLL reference
means we use it?

> It is also missing a clock reference to the RTC register gate (and that
> clock is in turn missing from the r_ccu driver).

Do you mean a gate bit somewhere in the PRCM? Do you have any
pointer/documentation for that?

Cheers,
Andre

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
  2021-05-24 12:02   ` Maxime Ripard
@ 2021-06-07 12:59     ` Andre Przywara
  0 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-06-07 12:59 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree

On Mon, 24 May 2021 14:02:20 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

> Hi,
> 
> On Wed, May 19, 2021 at 11:41:49AM +0100, Andre Przywara wrote:
> > 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.
> > 
> > USB is a bit tricky: host controller 0, 1 and 3 depend on some help from
> > controller and PHY 2, so we need to include one reset line and one
> > clock gate from HCI 2 into every other HCI node, plus need some nasty
> > quirk.
> > 
> > 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>  
> 
> As far as I can see, the IOMMU hasn't changed between the H6 and the
> H616, so it would be worth enabling

I would rather not include anything that can't be tested at this point.
IIUC the IOMMU is still only for the video devices, which I omitted at
all so far - the display engine definitely needs code changes (Jernej
has something in the making).
So I'd like to wait for the IOMMU nodes till we get DE or VE support.

Cheers,
Andre

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-05-25 11:29     ` Andre Przywara
@ 2021-06-07 13:22       ` Maxime Ripard
  2021-06-07 14:17         ` Andre Przywara
  0 siblings, 1 reply; 45+ messages in thread
From: Maxime Ripard @ 2021-06-07 13:22 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Kishon Vijay Abraham I, Vinod Koul,
	linux-phy, linux-usb

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

Hi,

On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote:
> On Mon, 24 May 2021 13:59:46 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> Hi Maxime,
> 
> > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
> > > At least the Allwinner H616 SoC requires a weird quirk to make most
> > > USB PHYs work: Only port2 works out of the box, but all other ports
> > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > > the PMU PHY control register needs to be cleared. For this register to
> > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> > > 
> > > Instead of disguising this as some generic feature, do exactly that
> > > in our PHY init:
> > > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > > this one special clock, and clear the SIDDQ bit. We can pull in the
> > > other required clocks via the DT.
> > > 
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>  
> > 
> > What is this SIDDQ bit doing exactly?
> 
> I probably know as much as you do, but as Jernej pointed out, in some
> Rockchip code it's indeed documented as some analogue PHY supply switch:
> ($ git grep -i siddq drivers/phy/rockchip)
> 
> In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
> our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.

Ok

> > I guess we could also expose this using a power-domain if it's relevant?
> 
> Mmmh, interesting idea. So are you thinking about registering a genpd
> provider in sun4i_usb_phy_probe(), then having a power-domains property
> in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
> the provider be a subnode of the USB PHY node, with a separate
> compatible? That sounds a bit more involved, but would have the
> advantage of allowing us to specify the resets and clocks from PHY2
> there, and would look a bit cleaner than hacking them into the
> other EHCI/OHCI nodes.

I'm not sure we need a separate device node, we could just register the
phy driver as a genpd provider, and then with an arg (so with
of_genpd_add_provider_onecell?) the index of the USB controller we want
to power up.

> I would not touch the existing SoCs (even though it seems to apply to
> them as well, just not in the exact same way), but I can give it a
> try for the H616. It seems like the other SIDDQ bits (in the other
> PHYs) are still needed for operation, but the PD provide could actually
> take care of this as well.
> 
> Does that make sense or is this a bit over the top for just clearing an
> extra bit?

Using what I described above should be fairly simple, so if we can fit
in an available and relevant abstraction, yeah, I guess :)

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-06-07 13:22       ` Maxime Ripard
@ 2021-06-07 14:17         ` Andre Przywara
  2021-06-07 14:26           ` [linux-sunxi] " Chen-Yu Tsai
  0 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-06-07 14:17 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Chen-Yu Tsai, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Kishon Vijay Abraham I, Vinod Koul,
	linux-phy, linux-usb

On Mon, 7 Jun 2021 15:22:55 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

Hi Maxime,

> On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote:
> > On Mon, 24 May 2021 13:59:46 +0200
> > Maxime Ripard <maxime@cerno.tech> wrote:
> > 
> > Hi Maxime,
> >   
> > > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:  
> > > > At least the Allwinner H616 SoC requires a weird quirk to make most
> > > > USB PHYs work: Only port2 works out of the box, but all other ports
> > > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > > > the PMU PHY control register needs to be cleared. For this register to
> > > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> > > > 
> > > > Instead of disguising this as some generic feature, do exactly that
> > > > in our PHY init:
> > > > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > > > this one special clock, and clear the SIDDQ bit. We can pull in the
> > > > other required clocks via the DT.
> > > > 
> > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>    
> > > 
> > > What is this SIDDQ bit doing exactly?  
> > 
> > I probably know as much as you do, but as Jernej pointed out, in some
> > Rockchip code it's indeed documented as some analogue PHY supply switch:
> > ($ git grep -i siddq drivers/phy/rockchip)
> > 
> > In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
> > our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.  
> 
> Ok
> 
> > > I guess we could also expose this using a power-domain if it's relevant?  
> > 
> > Mmmh, interesting idea. So are you thinking about registering a genpd
> > provider in sun4i_usb_phy_probe(), then having a power-domains property
> > in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
> > the provider be a subnode of the USB PHY node, with a separate
> > compatible? That sounds a bit more involved, but would have the
> > advantage of allowing us to specify the resets and clocks from PHY2
> > there, and would look a bit cleaner than hacking them into the
> > other EHCI/OHCI nodes.  
> 
> I'm not sure we need a separate device node, we could just register the
> phy driver as a genpd provider, and then with an arg (so with
> of_genpd_add_provider_onecell?) the index of the USB controller we want
> to power up.

Yeah, I figured that myself meanwhile ;-) I now have a fairly nice
implementation, which does away with the extra clocks and resets from
the EHCI/OHCI nodes, and just adds one extra clock to the PHY node. The
rest is power domains properties.

> > I would not touch the existing SoCs (even though it seems to apply to
> > them as well, just not in the exact same way), but I can give it a
> > try for the H616. It seems like the other SIDDQ bits (in the other
> > PHYs) are still needed for operation, but the PD provide could actually
> > take care of this as well.
> > 
> > Does that make sense or is this a bit over the top for just clearing an
> > extra bit?  
> 
> Using what I described above should be fairly simple, so if we can fit
> in an available and relevant abstraction, yeah, I guess :)

Thanks!
I will post what I have, just need to find some solution for the RTC
clock bits.

Cheers,
Andre

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [linux-sunxi] Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-06-07 14:17         ` Andre Przywara
@ 2021-06-07 14:26           ` Chen-Yu Tsai
  2021-06-14  0:20             ` Andre Przywara
  0 siblings, 1 reply; 45+ messages in thread
From: Chen-Yu Tsai @ 2021-06-07 14:26 UTC (permalink / raw)
  To: André Przywara
  Cc: Maxime Ripard, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Kishon Vijay Abraham I, Vinod Koul,
	linux-phy, linux-usb

Hi,

On Mon, Jun 7, 2021 at 10:17 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> On Mon, 7 Jun 2021 15:22:55 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
>
> Hi Maxime,
>
> > On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote:
> > > On Mon, 24 May 2021 13:59:46 +0200
> > > Maxime Ripard <maxime@cerno.tech> wrote:
> > >
> > > Hi Maxime,
> > >
> > > > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:
> > > > > At least the Allwinner H616 SoC requires a weird quirk to make most
> > > > > USB PHYs work: Only port2 works out of the box, but all other ports
> > > > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > > > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > > > > the PMU PHY control register needs to be cleared. For this register to
> > > > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> > > > >
> > > > > Instead of disguising this as some generic feature, do exactly that
> > > > > in our PHY init:
> > > > > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > > > > this one special clock, and clear the SIDDQ bit. We can pull in the
> > > > > other required clocks via the DT.
> > > > >
> > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > >
> > > > What is this SIDDQ bit doing exactly?
> > >
> > > I probably know as much as you do, but as Jernej pointed out, in some
> > > Rockchip code it's indeed documented as some analogue PHY supply switch:
> > > ($ git grep -i siddq drivers/phy/rockchip)
> > >
> > > In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
> > > our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.
> >
> > Ok
> >
> > > > I guess we could also expose this using a power-domain if it's relevant?
> > >
> > > Mmmh, interesting idea. So are you thinking about registering a genpd
> > > provider in sun4i_usb_phy_probe(), then having a power-domains property
> > > in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
> > > the provider be a subnode of the USB PHY node, with a separate
> > > compatible? That sounds a bit more involved, but would have the
> > > advantage of allowing us to specify the resets and clocks from PHY2
> > > there, and would look a bit cleaner than hacking them into the
> > > other EHCI/OHCI nodes.
> >
> > I'm not sure we need a separate device node, we could just register the
> > phy driver as a genpd provider, and then with an arg (so with
> > of_genpd_add_provider_onecell?) the index of the USB controller we want
> > to power up.
>
> Yeah, I figured that myself meanwhile ;-) I now have a fairly nice
> implementation, which does away with the extra clocks and resets from
> the EHCI/OHCI nodes, and just adds one extra clock to the PHY node. The
> rest is power domains properties.

I'm wondering, since SIDDQ refers to the analog power for USB, it shouldn't
really affect the HCIs, only the PHYs. Is there any way to model it like
this and test it?

ChenYu

> > > I would not touch the existing SoCs (even though it seems to apply to
> > > them as well, just not in the exact same way), but I can give it a
> > > try for the H616. It seems like the other SIDDQ bits (in the other
> > > PHYs) are still needed for operation, but the PD provide could actually
> > > take care of this as well.
> > >
> > > Does that make sense or is this a bit over the top for just clearing an
> > > extra bit?
> >
> > Using what I described above should be fairly simple, so if we can fit
> > in an available and relevant abstraction, yeah, I guess :)
>
> Thanks!
> I will post what I have, just need to find some solution for the RTC
> clock bits.
>
> Cheers,
> Andre
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20210607151742.2f05ff95%40slackpad.fritz.box.

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-06-07 12:59     ` Andre Przywara
@ 2021-06-08  4:23       ` Samuel Holland
  2021-06-15 12:24         ` Andre Przywara
  0 siblings, 1 reply; 45+ messages in thread
From: Samuel Holland @ 2021-06-08  4:23 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Alessandro Zummo,
	Alexandre Belloni, linux-rtc, linux-clk

On 6/7/21 7:59 AM, Andre Przywara wrote:
> On Thu, 20 May 2021 21:37:34 -0500
> Samuel Holland <samuel@sholland.org> wrote:
> 
> Hi,
> 
>> On 5/19/21 5:41 AM, Andre Przywara wrote:
>>> Add the obvious compatible name to the existing RTC binding.
>>> The actual RTC part of the device uses a different day/month/year
>>> storage scheme, so it's not compatible with the previous devices.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> index b1b0ee769b71..178c955f88bf 100644
>>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>>> @@ -26,6 +26,7 @@ properties:
>>>            - const: allwinner,sun50i-a64-rtc
>>>            - const: allwinner,sun8i-h3-rtc
>>>        - const: allwinner,sun50i-h6-rtc
>>> +      - const: allwinner,sun50i-h616-rtc
>>>  
>>>    reg:
>>>      maxItems: 1
>>> @@ -97,7 +98,9 @@ allOf:
>>>        properties:
>>>          compatible:
>>>            contains:
>>> -            const: allwinner,sun50i-h6-rtc
>>> +            enum:
>>> +              - allwinner,sun50i-h6-rtc
>>> +              - allwinner,sun50i-h616-rtc
>>>  
>>>      then:
>>>        properties:
>>>   
>>
>> This binding is missing a clock reference for the pll-periph0-2x input
>> to the 32kHz clock fanout.
> 
> Right. So do I get this correctly that we don't model the OSC24M input
> explicitly so far in the DT? I only see one possible input clock, which
> is for an optional 32K crystal oscillator.
> And this means we need to change some code also? Because at the moment
> a clock specified is assumed to be the 32K OSC, and having this clock
> means we switch to the external 32K OSC.

Right. The code would need updates to follow the binding.

> And who would decide which clock source to use? What would be the
> reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> divided down 24MHz?

Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
expects 32768 Hz.

> So shall we ignore the PLL based input clock for now, put "0 input
> clocks" in the current binding, then later on extend this to allow
> choosing the PLL? And have it that way that having the PLL reference
> means we use it?

No, the device tree represents the hardware, not whatever happens to be
used by Linux drivers at the time. It should be in the binding
regardless of what the driver does with it.

Though the circular dependency between the clock providers does cause
problems. We cannot get a clk_hw for the PLL-based clock, so we would
have to hardcode a global name for it, which means we aren't really
using the device tree.

We already see this "not really using the binding" with the other CCUs:
the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
"dcxo24M" for the same clock. So moving that clock into the RTC clock
provider would require using both names in one clk_hw simultaneously (or
rather fixing the CCU drivers to get a clk_hw from the DT instead of
referencing by name).

And trying to deal with optional clocks by index is only going to get
more painful over time. For example, with the R329 and D1, the RTC has
the following inputs:
 * DCXO24M (unless you model it inside the RTC)
 * External OSC32k (optional!)
 * The RTC bus gate/reset from the PRCM
 * R-AHB from the PRCM for the RTC SPI clock domain

So it seems time to start using clock-names in the RTC binding.

>> It is also missing a clock reference to the RTC register gate (and that
>> clock is in turn missing from the r_ccu driver).
> 
> Do you mean a gate bit somewhere in the PRCM? Do you have any
> pointer/documentation for that?

Yes, it's bit 0 of PRCM+0x20c, documented in the BSP[1], used in
mainline[2], and verified by experiment.

[1]:
https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw9.h#L169
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c#n129

> Cheers,
> Andre

Regards,
Samuel

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [linux-sunxi] Re: [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk
  2021-06-07 14:26           ` [linux-sunxi] " Chen-Yu Tsai
@ 2021-06-14  0:20             ` Andre Przywara
  0 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-06-14  0:20 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Maxime Ripard, Jernej Skrabec, Rob Herring, Icenowy Zheng,
	Samuel Holland, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, Kishon Vijay Abraham I, Vinod Koul,
	linux-phy, linux-usb

On Mon, 7 Jun 2021 22:26:02 +0800
Chen-Yu Tsai <wens@csie.org> wrote:

Hi Chen-Yu,

> On Mon, Jun 7, 2021 at 10:17 PM Andre Przywara <andre.przywara@arm.com> wrote:
> >
> > On Mon, 7 Jun 2021 15:22:55 +0200
> > Maxime Ripard <maxime@cerno.tech> wrote:
> >
> > Hi Maxime,
> >  
> > > On Tue, May 25, 2021 at 12:29:01PM +0100, Andre Przywara wrote:  
> > > > On Mon, 24 May 2021 13:59:46 +0200
> > > > Maxime Ripard <maxime@cerno.tech> wrote:
> > > >
> > > > Hi Maxime,
> > > >  
> > > > > On Wed, May 19, 2021 at 11:41:47AM +0100, Andre Przywara wrote:  
> > > > > > At least the Allwinner H616 SoC requires a weird quirk to make most
> > > > > > USB PHYs work: Only port2 works out of the box, but all other ports
> > > > > > need some help from this port2 to work correctly: The CLK_BUS_PHY2 and
> > > > > > RST_USB_PHY2 clock and reset need to be enabled, and the SIDDQ bit in
> > > > > > the PMU PHY control register needs to be cleared. For this register to
> > > > > > be accessible, CLK_BUS_ECHI2 needs to be ungated. Don't ask ....
> > > > > >
> > > > > > Instead of disguising this as some generic feature, do exactly that
> > > > > > in our PHY init:
> > > > > > If the quirk bit is set, and we initialise a PHY other than PHY2, ungate
> > > > > > this one special clock, and clear the SIDDQ bit. We can pull in the
> > > > > > other required clocks via the DT.
> > > > > >
> > > > > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>  
> > > > >
> > > > > What is this SIDDQ bit doing exactly?  
> > > >
> > > > I probably know as much as you do, but as Jernej pointed out, in some
> > > > Rockchip code it's indeed documented as some analogue PHY supply switch:
> > > > ($ git grep -i siddq drivers/phy/rockchip)
> > > >
> > > > In fact we had this pin/bit for ages, it was just hidden as BIT(1) in
> > > > our infamous PMU_UNK1 register. Patch 10/17 drags that into the light.  
> > >
> > > Ok
> > >  
> > > > > I guess we could also expose this using a power-domain if it's relevant?  
> > > >
> > > > Mmmh, interesting idea. So are you thinking about registering a genpd
> > > > provider in sun4i_usb_phy_probe(), then having a power-domains property
> > > > in the ehci/ohci nodes, pointing to the PHY node? And if yes, should
> > > > the provider be a subnode of the USB PHY node, with a separate
> > > > compatible? That sounds a bit more involved, but would have the
> > > > advantage of allowing us to specify the resets and clocks from PHY2
> > > > there, and would look a bit cleaner than hacking them into the
> > > > other EHCI/OHCI nodes.  
> > >
> > > I'm not sure we need a separate device node, we could just register the
> > > phy driver as a genpd provider, and then with an arg (so with
> > > of_genpd_add_provider_onecell?) the index of the USB controller we want
> > > to power up.  
> >
> > Yeah, I figured that myself meanwhile ;-) I now have a fairly nice
> > implementation, which does away with the extra clocks and resets from
> > the EHCI/OHCI nodes, and just adds one extra clock to the PHY node. The
> > rest is power domains properties.  
> 
> I'm wondering, since SIDDQ refers to the analog power for USB, it shouldn't
> really affect the HCIs, only the PHYs. Is there any way to model it like
> this and test it?

That is actually a good point: it is indeed solely a PHY property. The
HCIs already connect to their PHYs, among other reasons to power them
on, so it should really be an internal PHY affair.
Which is actually what this patch here does.
So I can combine the best of both approaches: we already have the
PHY2 clock and reset references in the PHY node, so can just reach out
and enable them as well, alongside the actually associated PHY clock.
This allows us to get rid of the bogus PHY2 clock references from all
HCIs.
So all of this H616 quirk can be fully contained within the PHY driver,
with no impact on the HCI parts and no extra DT properties
(power-domains, clocks) needed there.

Seems to work on a quick test. I will send a version ASAP.

Thanks!
Andre

> 
> ChenYu
> 
> > > > I would not touch the existing SoCs (even though it seems to apply to
> > > > them as well, just not in the exact same way), but I can give it a
> > > > try for the H616. It seems like the other SIDDQ bits (in the other
> > > > PHYs) are still needed for operation, but the PD provide could actually
> > > > take care of this as well.
> > > >
> > > > Does that make sense or is this a bit over the top for just clearing an
> > > > extra bit?  
> > >
> > > Using what I described above should be fairly simple, so if we can fit
> > > in an available and relevant abstraction, yeah, I guess :)  
> >
> > Thanks!
> > I will post what I have, just need to find some solution for the RTC
> > clock bits.
> >
> > Cheers,
> > Andre
> >

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-06-08  4:23       ` Samuel Holland
@ 2021-06-15 12:24         ` Andre Przywara
  2021-06-16  9:07           ` Maxime Ripard
  0 siblings, 1 reply; 45+ messages in thread
From: Andre Przywara @ 2021-06-15 12:24 UTC (permalink / raw)
  To: Samuel Holland
  Cc: Maxime Ripard, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Alessandro Zummo,
	Alexandre Belloni, linux-rtc, linux-clk

On Mon, 7 Jun 2021 23:23:04 -0500
Samuel Holland <samuel@sholland.org> wrote:

Hi Samuel,

> On 6/7/21 7:59 AM, Andre Przywara wrote:
> > On Thu, 20 May 2021 21:37:34 -0500
> > Samuel Holland <samuel@sholland.org> wrote:
> > 
> > Hi,
> >   
> >> On 5/19/21 5:41 AM, Andre Przywara wrote:  
> >>> Add the obvious compatible name to the existing RTC binding.
> >>> The actual RTC part of the device uses a different day/month/year
> >>> storage scheme, so it's not compatible with the previous devices.
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>> ---
> >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> index b1b0ee769b71..178c955f88bf 100644
> >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >>> @@ -26,6 +26,7 @@ properties:
> >>>            - const: allwinner,sun50i-a64-rtc
> >>>            - const: allwinner,sun8i-h3-rtc
> >>>        - const: allwinner,sun50i-h6-rtc
> >>> +      - const: allwinner,sun50i-h616-rtc
> >>>  
> >>>    reg:
> >>>      maxItems: 1
> >>> @@ -97,7 +98,9 @@ allOf:
> >>>        properties:
> >>>          compatible:
> >>>            contains:
> >>> -            const: allwinner,sun50i-h6-rtc
> >>> +            enum:
> >>> +              - allwinner,sun50i-h6-rtc
> >>> +              - allwinner,sun50i-h616-rtc
> >>>  
> >>>      then:
> >>>        properties:
> >>>     
> >>
> >> This binding is missing a clock reference for the pll-periph0-2x input
> >> to the 32kHz clock fanout.  
> > 
> > Right. So do I get this correctly that we don't model the OSC24M input
> > explicitly so far in the DT? I only see one possible input clock, which
> > is for an optional 32K crystal oscillator.
> > And this means we need to change some code also? Because at the moment
> > a clock specified is assumed to be the 32K OSC, and having this clock
> > means we switch to the external 32K OSC.  
> 
> Right. The code would need updates to follow the binding.

I changed the binding for now to not allow any clock, and the code to
ignore any clocks when the H616 compatible is used. This way we can
extend this later without breaking anything.

> > And who would decide which clock source to use? What would be the
> > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > divided down 24MHz?  
> 
> Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> expects 32768 Hz.

I thought about this as well, but this means there is no reason to not
use the PLL? At least not for Linux (normal operation with PLLs
running anyway)? This situation is different for the other SoCs, because
boards *might* have a separate and more precise 32K crystal.
So we could code this similar to the other SoCs: If we have a clock
property defined, we assume it's pointing to the PLL and switch to use
it?

But, looking at the diagram in the manual (and assuming it's
correct), the PLL based clock can only be routed to the pad, but cannot
be used for the RTC. That seems to be also the case for the T5, which
has an external LOSC pin.
 
> > So shall we ignore the PLL based input clock for now, put "0 input
> > clocks" in the current binding, then later on extend this to allow
> > choosing the PLL? And have it that way that having the PLL reference
> > means we use it?  
> 
> No, the device tree represents the hardware, not whatever happens to be
> used by Linux drivers at the time. It should be in the binding
> regardless of what the driver does with it.

I understand that very well, but was just looking for a solution where
we can go ahead with an easier solution *now*. I am afraid implementing
this annoying RTC special snowflake properly will just delay the whole
series.
In the long run your "D1 & friends" extra RTC clock driver looks the
right way out, but it will probably take some more time to get this
merged.
 
> Though the circular dependency between the clock providers does cause
> problems. We cannot get a clk_hw for the PLL-based clock, so we would
> have to hardcode a global name for it, which means we aren't really
> using the device tree.

I start to wonder how much business Linux really has in controlling all
those RTC details. The current code happens to work, because everything
is setup correctly already, on reset.

> We already see this "not really using the binding" with the other CCUs:
> the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
> "dcxo24M" for the same clock. So moving that clock into the RTC clock
> provider would require using both names in one clk_hw simultaneously (or
> rather fixing the CCU drivers to get a clk_hw from the DT instead of
> referencing by name).
> 
> And trying to deal with optional clocks by index is only going to get
> more painful over time. For example, with the R329 and D1, the RTC has
> the following inputs:
>  * DCXO24M (unless you model it inside the RTC)
>  * External OSC32k (optional!)
>  * The RTC bus gate/reset from the PRCM
>  * R-AHB from the PRCM for the RTC SPI clock domain
> 
> So it seems time to start using clock-names in the RTC binding.

Yes, that sounds reasonable. It's just a shame that we keep changing
the RTC bindings, and so creating a lot of incompatibility on the way.

> >> It is also missing a clock reference to the RTC register gate (and that
> >> clock is in turn missing from the r_ccu driver).  
> > 
> > Do you mean a gate bit somewhere in the PRCM? Do you have any
> > pointer/documentation for that?  
> 
> Yes, it's bit 0 of PRCM+0x20c, documented in the BSP[1], used in
> mainline[2], and verified by experiment.

I can confirm this, also by experimentation. And the H6 seems to have
the same bit.
But what purpose would this bit solve? I don't see a good reason to
describe this in the DT, it's more like a turn-off bit for firmware?

Cheers,
Andre

 
> [1]:
> https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-4.9-sun50iw9/drivers/clk/sunxi/clk-sun50iw9.h#L169
> [2]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun50i-a100-r.c#n129
> 
> > Cheers,
> > Andre  
> 
> Regards,
> Samuel


^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-06-15 12:24         ` Andre Przywara
@ 2021-06-16  9:07           ` Maxime Ripard
  2021-06-16 11:28             ` Andre Przywara
  0 siblings, 1 reply; 45+ messages in thread
From: Maxime Ripard @ 2021-06-16  9:07 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Samuel Holland, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Alessandro Zummo,
	Alexandre Belloni, linux-rtc, linux-clk

Hi,

On Tue, Jun 15, 2021 at 01:24:40PM +0100, Andre Przywara wrote:
> > On 6/7/21 7:59 AM, Andre Przywara wrote:
> > > On Thu, 20 May 2021 21:37:34 -0500
> > > Samuel Holland <samuel@sholland.org> wrote:
> > > 
> > > Hi,
> > >   
> > >> On 5/19/21 5:41 AM, Andre Przywara wrote:  
> > >>> Add the obvious compatible name to the existing RTC binding.
> > >>> The actual RTC part of the device uses a different day/month/year
> > >>> storage scheme, so it's not compatible with the previous devices.
> > >>>
> > >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > >>> ---
> > >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > >>> index b1b0ee769b71..178c955f88bf 100644
> > >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > >>> @@ -26,6 +26,7 @@ properties:
> > >>>            - const: allwinner,sun50i-a64-rtc
> > >>>            - const: allwinner,sun8i-h3-rtc
> > >>>        - const: allwinner,sun50i-h6-rtc
> > >>> +      - const: allwinner,sun50i-h616-rtc
> > >>>  
> > >>>    reg:
> > >>>      maxItems: 1
> > >>> @@ -97,7 +98,9 @@ allOf:
> > >>>        properties:
> > >>>          compatible:
> > >>>            contains:
> > >>> -            const: allwinner,sun50i-h6-rtc
> > >>> +            enum:
> > >>> +              - allwinner,sun50i-h6-rtc
> > >>> +              - allwinner,sun50i-h616-rtc
> > >>>  
> > >>>      then:
> > >>>        properties:
> > >>>     
> > >>
> > >> This binding is missing a clock reference for the pll-periph0-2x input
> > >> to the 32kHz clock fanout.  
> > > 
> > > Right. So do I get this correctly that we don't model the OSC24M input
> > > explicitly so far in the DT? I only see one possible input clock, which
> > > is for an optional 32K crystal oscillator.
> > > And this means we need to change some code also? Because at the moment
> > > a clock specified is assumed to be the 32K OSC, and having this clock
> > > means we switch to the external 32K OSC.  
> > 
> > Right. The code would need updates to follow the binding.
> 
> I changed the binding for now to not allow any clock, and the code to
> ignore any clocks when the H616 compatible is used. This way we can
> extend this later without breaking anything.

I'm not really a fan of this: it just creates one more special case that
we'll have to take into account later on, complicating further the logic
that is already way too complicated.

> > > And who would decide which clock source to use? What would be the
> > > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > > divided down 24MHz?  
> > 
> > Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> > expects 32768 Hz.
> 
> I thought about this as well, but this means there is no reason to not
> use the PLL? At least not for Linux (normal operation with PLLs
> running anyway)? This situation is different for the other SoCs, because
> boards *might* have a separate and more precise 32K crystal.
> So we could code this similar to the other SoCs: If we have a clock
> property defined, we assume it's pointing to the PLL and switch to use
> it?

We have another option though: list all the clocks that could be
available for a 32khz source, call clk_get_accuracy on them, and then
use the clock with the best accuracy. We already have the accuracy
requirements in the datasheet for each crystal, so it shouldn't be too
hard to support.

> But, looking at the diagram in the manual (and assuming it's
> correct), the PLL based clock can only be routed to the pad, but cannot
> be used for the RTC. That seems to be also the case for the T5, which
> has an external LOSC pin.
>  
> > > So shall we ignore the PLL based input clock for now, put "0 input
> > > clocks" in the current binding, then later on extend this to allow
> > > choosing the PLL? And have it that way that having the PLL reference
> > > means we use it?  
> > 
> > No, the device tree represents the hardware, not whatever happens to be
> > used by Linux drivers at the time. It should be in the binding
> > regardless of what the driver does with it.
> 
> I understand that very well, but was just looking for a solution where
> we can go ahead with an easier solution *now*. I am afraid implementing
> this annoying RTC special snowflake properly will just delay the whole
> series.
> In the long run your "D1 & friends" extra RTC clock driver looks the
> right way out, but it will probably take some more time to get this
> merged.

To be honest, I'm not entirely sure why we need the rtc in the first
place. If your plan is to figure it out later anyway, why not just model
the 32kHz clock as a fixed clock, and change it later once it's been
entirely figured out?

> > Though the circular dependency between the clock providers does cause
> > problems. We cannot get a clk_hw for the PLL-based clock, so we would
> > have to hardcode a global name for it, which means we aren't really
> > using the device tree.
> 
> I start to wonder how much business Linux really has in controlling all
> those RTC details. The current code happens to work, because everything
> is setup correctly already, on reset.

That's not true for all the SoCs.

> > We already see this "not really using the binding" with the other CCUs:
> > the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
> > "dcxo24M" for the same clock. So moving that clock into the RTC clock
> > provider would require using both names in one clk_hw simultaneously (or
> > rather fixing the CCU drivers to get a clk_hw from the DT instead of
> > referencing by name).
> > 
> > And trying to deal with optional clocks by index is only going to get
> > more painful over time. For example, with the R329 and D1, the RTC has
> > the following inputs:
> >  * DCXO24M (unless you model it inside the RTC)
> >  * External OSC32k (optional!)
> >  * The RTC bus gate/reset from the PRCM
> >  * R-AHB from the PRCM for the RTC SPI clock domain
> > 
> > So it seems time to start using clock-names in the RTC binding.
> 
> Yes, that sounds reasonable. It's just a shame that we keep changing
> the RTC bindings, and so creating a lot of incompatibility on the way.

I mean, we keep changing it because the hardware keeps changing. The RTC
on the A20 had no clock at all. The A31 later on got only a single clock
input, and a single output. If your point is that we should have known
better 9 years ago what the current SoCs would look like, that's a bit
absurd, don't you think?

Maxime

^ permalink raw reply	[flat|nested] 45+ messages in thread

* Re: [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string
  2021-06-16  9:07           ` Maxime Ripard
@ 2021-06-16 11:28             ` Andre Przywara
  0 siblings, 0 replies; 45+ messages in thread
From: Andre Przywara @ 2021-06-16 11:28 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Samuel Holland, Chen-Yu Tsai, Jernej Skrabec, Rob Herring,
	Icenowy Zheng, Ondrej Jirman, linux-arm-kernel, linux-sunxi,
	linux-sunxi, linux-kernel, devicetree, Alessandro Zummo,
	Alexandre Belloni, linux-rtc, linux-clk

On Wed, 16 Jun 2021 11:07:00 +0200
Maxime Ripard <maxime@cerno.tech> wrote:

Hi,

> On Tue, Jun 15, 2021 at 01:24:40PM +0100, Andre Przywara wrote:
> > > On 6/7/21 7:59 AM, Andre Przywara wrote:  
> > > > On Thu, 20 May 2021 21:37:34 -0500
> > > > Samuel Holland <samuel@sholland.org> wrote:
> > > > 
> > > > Hi,
> > > >     
> > > >> On 5/19/21 5:41 AM, Andre Przywara wrote:    
> > > >>> Add the obvious compatible name to the existing RTC binding.
> > > >>> The actual RTC part of the device uses a different day/month/year
> > > >>> storage scheme, so it's not compatible with the previous devices.
> > > >>>
> > > >>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > >>> ---
> > > >>>  .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml     | 5 ++++-
> > > >>>  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> index b1b0ee769b71..178c955f88bf 100644
> > > >>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> > > >>> @@ -26,6 +26,7 @@ properties:
> > > >>>            - const: allwinner,sun50i-a64-rtc
> > > >>>            - const: allwinner,sun8i-h3-rtc
> > > >>>        - const: allwinner,sun50i-h6-rtc
> > > >>> +      - const: allwinner,sun50i-h616-rtc
> > > >>>  
> > > >>>    reg:
> > > >>>      maxItems: 1
> > > >>> @@ -97,7 +98,9 @@ allOf:
> > > >>>        properties:
> > > >>>          compatible:
> > > >>>            contains:
> > > >>> -            const: allwinner,sun50i-h6-rtc
> > > >>> +            enum:
> > > >>> +              - allwinner,sun50i-h6-rtc
> > > >>> +              - allwinner,sun50i-h616-rtc
> > > >>>  
> > > >>>      then:
> > > >>>        properties:
> > > >>>       
> > > >>
> > > >> This binding is missing a clock reference for the pll-periph0-2x input
> > > >> to the 32kHz clock fanout.    
> > > > 
> > > > Right. So do I get this correctly that we don't model the OSC24M input
> > > > explicitly so far in the DT? I only see one possible input clock, which
> > > > is for an optional 32K crystal oscillator.
> > > > And this means we need to change some code also? Because at the moment
> > > > a clock specified is assumed to be the 32K OSC, and having this clock
> > > > means we switch to the external 32K OSC.    
> > > 
> > > Right. The code would need updates to follow the binding.  
> > 
> > I changed the binding for now to not allow any clock, and the code to
> > ignore any clocks when the H616 compatible is used. This way we can
> > extend this later without breaking anything.  
> 
> I'm not really a fan of this: it just creates one more special case that
> we'll have to take into account later on, complicating further the logic
> that is already way too complicated.

I see your point, but that's why I made it a no-clock choice: we can
add clocks any time later, older kernels finding them in newer DTs will
ignore them, older DTs on newer kernels wouldn't instantiate them in
the first place.

> 
> > > > And who would decide which clock source to use? What would be the
> > > > reason to use PLL_PERIPH(2x) over the RC16M based clock or the
> > > > divided down 24MHz?    
> > > 
> > > Because it would be more accurate. 24MHz/750 == 32000 Hz, while the RTC
> > > expects 32768 Hz.  
> > 
> > I thought about this as well, but this means there is no reason to not
> > use the PLL? At least not for Linux (normal operation with PLLs
> > running anyway)? This situation is different for the other SoCs, because
> > boards *might* have a separate and more precise 32K crystal.
> > So we could code this similar to the other SoCs: If we have a clock
> > property defined, we assume it's pointing to the PLL and switch to use
> > it?  
> 
> We have another option though: list all the clocks that could be
> available for a 32khz source, call clk_get_accuracy on them, and then
> use the clock with the best accuracy. We already have the accuracy
> requirements in the datasheet for each crystal, so it shouldn't be too
> hard to support.

That would possibly be an option, yes. What makes this further
complicated though is that there are several LOSC outputs: one going
to the RTC, one going to other peripherals, one going to the pad. And
they can have different sources, at least on the H616: the RTC and
system clock can't be driven by the PLL or divided down HOSC, just by
the RC oscillator. But all three of them can supply the clock to the
pad. I guess another reason to separate clock and actual RTC.

> > But, looking at the diagram in the manual (and assuming it's
> > correct), the PLL based clock can only be routed to the pad, but cannot
> > be used for the RTC. That seems to be also the case for the T5, which
> > has an external LOSC pin.
> >    
> > > > So shall we ignore the PLL based input clock for now, put "0 input
> > > > clocks" in the current binding, then later on extend this to allow
> > > > choosing the PLL? And have it that way that having the PLL reference
> > > > means we use it?    
> > > 
> > > No, the device tree represents the hardware, not whatever happens to be
> > > used by Linux drivers at the time. It should be in the binding
> > > regardless of what the driver does with it.  
> > 
> > I understand that very well, but was just looking for a solution where
> > we can go ahead with an easier solution *now*. I am afraid implementing
> > this annoying RTC special snowflake properly will just delay the whole
> > series.
> > In the long run your "D1 & friends" extra RTC clock driver looks the
> > right way out, but it will probably take some more time to get this
> > merged.  
> 
> To be honest, I'm not entirely sure why we need the rtc in the first
> place. If your plan is to figure it out later anyway, why not just model
> the 32kHz clock as a fixed clock, and change it later once it's been
> entirely figured out?

This would be a way out, at the cost of making newer DTs not work on
this kernel (the H616 RTC compatible wouldn't be recognised). I have to
check how fatal this is, IIRC pinctrl and CCU still work somehow (it's
only needed for debounce, which is optional?)
But if this is the price to pay to get it into 5.14 ... 
 
> > > Though the circular dependency between the clock providers does cause
> > > problems. We cannot get a clk_hw for the PLL-based clock, so we would
> > > have to hardcode a global name for it, which means we aren't really
> > > using the device tree.  
> > 
> > I start to wonder how much business Linux really has in controlling all
> > those RTC details. The current code happens to work, because everything
> > is setup correctly already, on reset.  
> 
> That's not true for all the SoCs.

Yes, this was not meant to be an universal statement, but as you
mention above, we get pretty far with ignoring the RTC completely, even.
 
> > > We already see this "not really using the binding" with the other CCUs:
> > > the H616 CCU hardcodes the name "osc24M", while the A100 CCU hardcodes
> > > "dcxo24M" for the same clock. So moving that clock into the RTC clock
> > > provider would require using both names in one clk_hw simultaneously (or
> > > rather fixing the CCU drivers to get a clk_hw from the DT instead of
> > > referencing by name).
> > > 
> > > And trying to deal with optional clocks by index is only going to get
> > > more painful over time. For example, with the R329 and D1, the RTC has
> > > the following inputs:
> > >  * DCXO24M (unless you model it inside the RTC)
> > >  * External OSC32k (optional!)
> > >  * The RTC bus gate/reset from the PRCM
> > >  * R-AHB from the PRCM for the RTC SPI clock domain
> > > 
> > > So it seems time to start using clock-names in the RTC binding.  
> > 
> > Yes, that sounds reasonable. It's just a shame that we keep changing
> > the RTC bindings, and so creating a lot of incompatibility on the way.  
> 
> I mean, we keep changing it because the hardware keeps changing. The RTC
> on the A20 had no clock at all. The A31 later on got only a single clock
> input, and a single output. If your point is that we should have known
> better 9 years ago what the current SoCs would look like, that's a bit
> absurd, don't you think?

I don't mean changing the binding between SoCs, this is of course not
very reasonable, especially if dealing with Allwinner, who apparently
have little regard to something like "compatibility" and like to spread
new bits around various peripherals that happens to have free space.

I was referring to changing existing bindings for one particular SoC,
like we did in the past when adding the <&rtc 2> clock output.
And I am just afraid this will happen again if we start to support the
RTC "properly" now, for instance for the H6.

Cheers,
Andre

^ permalink raw reply	[flat|nested] 45+ messages in thread

end of thread, other threads:[~2021-06-16 11:29 UTC | newest]

Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-19 10:41 [PATCH v6 00/17] arm64: sunxi: Initial Allwinner H616 SoC support Andre Przywara
2021-05-19 10:41 ` [PATCH v6 01/17] dt-bindings: mfd: axp20x: Add AXP305 compatible (plus optional IRQ) Andre Przywara
2021-05-21  1:39   ` Rob Herring
2021-05-22 14:46   ` Samuel Holland
2021-05-23  0:01     ` Andre Przywara
2021-05-19 10:41 ` [PATCH v6 02/17] mfd: axp20x: Allow AXP 806 chips without interrupt lines Andre Przywara
2021-05-19 15:01   ` Lee Jones
2021-05-19 10:41 ` [PATCH v6 03/17] dt-bindings: rtc: sun6i: Add H616 compatible string Andre Przywara
2021-05-21  1:39   ` Rob Herring
2021-05-21  2:37   ` Samuel Holland
2021-06-07 12:59     ` Andre Przywara
2021-06-08  4:23       ` Samuel Holland
2021-06-15 12:24         ` Andre Przywara
2021-06-16  9:07           ` Maxime Ripard
2021-06-16 11:28             ` Andre Przywara
2021-05-19 10:41 ` [PATCH v6 04/17] rtc: sun6i: Add support for linear day storage Andre Przywara
2021-05-22  7:26   ` Jernej Škrabec
2021-05-19 10:41 ` [PATCH v6 05/17] rtc: sun6i: Add Allwinner H616 support Andre Przywara
2021-05-22  7:29   ` Jernej Škrabec
2021-05-23  0:06     ` Andre Przywara
2021-05-19 10:41 ` [PATCH v6 06/17] dt-bindings: net: sun8i-emac: Add H616 compatible string Andre Przywara
2021-05-21  1:40   ` Rob Herring
2021-05-19 10:41 ` [PATCH v6 07/17] net: stmmac: dwmac-sun8i: Prepare for second EMAC clock register Andre Przywara
2021-05-19 10:41 ` [PATCH v6 08/17] dt-bindings: usb: Add H616 compatible string Andre Przywara
2021-05-21  1:40   ` Rob Herring
2021-05-19 10:41 ` [PATCH v6 09/17] dt-bindings: usb: sunxi-musb: " Andre Przywara
2021-05-21  1:40   ` Rob Herring
2021-05-19 10:41 ` [PATCH v6 10/17] phy: sun4i-usb: Rework HCI PHY (aka. "pmu_unk1") handling Andre Przywara
2021-05-19 10:41 ` [PATCH v6 11/17] phy: sun4i-usb: Allow reset line to be shared Andre Przywara
2021-05-19 10:41 ` [PATCH v6 12/17] phy: sun4i-usb: Introduce port2 SIDDQ quirk Andre Przywara
2021-05-24 11:59   ` Maxime Ripard
2021-05-24 12:51     ` Jernej Škrabec
2021-05-25 11:29     ` Andre Przywara
2021-06-07 13:22       ` Maxime Ripard
2021-06-07 14:17         ` Andre Przywara
2021-06-07 14:26           ` [linux-sunxi] " Chen-Yu Tsai
2021-06-14  0:20             ` Andre Przywara
2021-05-19 10:41 ` [PATCH v6 13/17] phy: sun4i-usb: Add support for the H616 USB PHY Andre Przywara
2021-05-19 10:41 ` [PATCH v6 14/17] arm64: dts: allwinner: Add Allwinner H616 .dtsi file Andre Przywara
2021-05-24 12:02   ` Maxime Ripard
2021-06-07 12:59     ` Andre Przywara
2021-05-19 10:41 ` [PATCH v6 15/17] dt-bindings: arm: sunxi: Add OrangePi Zero 2 binding Andre Przywara
2021-05-19 10:41 ` [PATCH v6 16/17] arm64: dts: allwinner: h616: Add OrangePi Zero 2 board support Andre Przywara
2021-05-19 10:41 ` [PATCH v6 17/17] arm64: dts: allwinner: h616: Add X96 Mate TV box support Andre Przywara
2021-05-22  7:32   ` Jernej Škrabec

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).