* [PATCH] dt-bindings: net: meson-dwmac: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:25 UTC (permalink / raw)
To: robh+dt
Cc: Neil Armstrong, martin.blumenstingl, devicetree, netdev,
linux-amlogic, linux-arm-kernel, linux-kernel
Now that we have the DT validation in place, let's convert the device tree
bindings for the Synopsys DWMAC Glue for Amlogic SoCs over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Rob,
I keep getting :
.../devicetree/bindings/net/amlogic,meson-dwmac.example.dt.yaml: ethernet@c9410000: reg: [[3376480256, 65536], [3364046144, 8]] is too long
for the example DT
and for the board DT :
../amlogic/meson-gxl-s905x-libretech-cc.dt.yaml: ethernet@c9410000: reg: [[0, 3376480256, 0, 65536, 0, 3364046144, 0, 4]] is too short
../amlogic/meson-gxl-s905x-nexbox-a95x.dt.yaml: soc: ethernet@c9410000:reg:0: [0, 3376480256, 0, 65536, 0, 3364046144, 0, 4] is too long
and I don't know how to get rid of it.
What should I do for reg ?
Neil
.../bindings/net/amlogic,meson-dwmac.yaml | 113 ++++++++++++++++++
.../devicetree/bindings/net/meson-dwmac.txt | 71 -----------
.../devicetree/bindings/net/snps,dwmac.yaml | 5 +
3 files changed, 118 insertions(+), 71 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
delete mode 100644 Documentation/devicetree/bindings/net/meson-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
new file mode 100644
index 000000000000..ae91aa9d8616
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/amlogic,meson-dwmac.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson DWMAC Ethernet controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+ - Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+# We need a select here so we don't match all nodes with 'snps,dwmac'
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ required:
+ - compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+
+ then:
+ properties:
+ clocks:
+ items:
+ - description: GMAC main clock
+ - description: First parent clock of the internal mux
+ - description: Second parent clock of the internal mux
+
+ clock-names:
+ minItems: 3
+ maxItems: 3
+ items:
+ - const: stmmaceth
+ - const: clkin0
+ - const: clkin1
+
+ amlogic,tx-delay-ns:
+ $ref: /schemas/types.yaml#definitions/uint32
+ description:
+ The internal RGMII TX clock delay (provided by this driver) in
+ nanoseconds. Allowed values are 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX delay should be
+ explicitly configured. When not configured a fallback of 2ns is
+ used. When the phy-mode is set to either "rgmii-id" or "rgmii-txid"
+ the TX clock delay is already provided by the PHY. In that case
+ this property should be set to 0ns (which disables the TX clock
+ delay in the MAC to prevent the clock from going off because both
+ PHY and MAC are adding a delay).
+ Any configuration is ignored when the phy-mode is set to "rmii".
+
+properties:
+ compatible:
+ additionalItems: true
+ maxItems: 3
+ items:
+ - enum:
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
+ contains:
+ enum:
+ - snps,dwmac-3.70a
+ - snps,dwmac
+
+ reg:
+ items:
+ - description:
+ The first register range should be the one of the DWMAC controller
+ - description:
+ The second range is is for the Amlogic specific configuration
+ (for example the PRG_ETHERNET register range on Meson8b and newer)
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+ - phy-mode
+
+examples:
+ - |
+ ethmac: ethernet@c9410000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0xc9410000 0x10000>, <0xc8834540 0x8>;
+ interrupts = <8>;
+ interrupt-names = "macirq";
+ clocks = <&clk_eth>, <&clkc_fclk_div2>, <&clk_mpll2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ phy-mode = "rgmii";
+ };
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
deleted file mode 100644
index 1321bb194ed9..000000000000
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-* Amlogic Meson DWMAC Ethernet controller
-
-The device inherits all the properties of the dwmac/stmmac devices
-described in the file stmmac.txt in the current directory with the
-following changes.
-
-Required properties on all platforms:
-
-- compatible: Depending on the platform this should be one of:
- - "amlogic,meson6-dwmac"
- - "amlogic,meson8b-dwmac"
- - "amlogic,meson8m2-dwmac"
- - "amlogic,meson-gxbb-dwmac"
- - "amlogic,meson-axg-dwmac"
- Additionally "snps,dwmac" and any applicable more
- detailed version number described in net/stmmac.txt
- should be used.
-
-- reg: The first register range should be the one of the DWMAC
- controller. The second range is is for the Amlogic specific
- configuration (for example the PRG_ETHERNET register range
- on Meson8b and newer)
-
-Required properties on Meson8b, Meson8m2, GXBB and newer:
-- clock-names: Should contain the following:
- - "stmmaceth" - see stmmac.txt
- - "clkin0" - first parent clock of the internal mux
- - "clkin1" - second parent clock of the internal mux
-
-Optional properties on Meson8b, Meson8m2, GXBB and newer:
-- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
- by this driver) in nanoseconds. Allowed values
- are: 0ns, 2ns, 4ns, 6ns.
- When phy-mode is set to "rgmii" then the TX
- delay should be explicitly configured. When
- not configured a fallback of 2ns is used.
- When the phy-mode is set to either "rgmii-id"
- or "rgmii-txid" the TX clock delay is already
- provided by the PHY. In that case this
- property should be set to 0ns (which disables
- the TX clock delay in the MAC to prevent the
- clock from going off because both PHY and MAC
- are adding a delay).
- Any configuration is ignored when the phy-mode
- is set to "rmii".
-
-Example for Meson6:
-
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson6-dwmac", "snps,dwmac";
- reg = <0xc9410000 0x10000
- 0xc1108108 0x4>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clk81>;
- clock-names = "stmmaceth";
- }
-
-Example for GXBB:
- ethmac: ethernet@c9410000 {
- compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
- reg = <0x0 0xc9410000 0x0 0x10000>,
- <0x0 0xc8834540 0x0 0x8>;
- interrupts = <0 8 1>;
- interrupt-names = "macirq";
- clocks = <&clkc CLKID_ETH>,
- <&clkc CLKID_FCLK_DIV2>,
- <&clkc CLKID_MPLL2>;
- clock-names = "stmmaceth", "clkin0", "clkin1";
- phy-mode = "rgmii";
- };
diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
index 76fea2be66ac..ff1dc662a4e3 100644
--- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
@@ -50,6 +50,11 @@ properties:
- allwinner,sun8i-r40-emac
- allwinner,sun8i-v3s-emac
- allwinner,sun50i-a64-emac
+ - amlogic,meson6-dwmac
+ - amlogic,meson8b-dwmac
+ - amlogic,meson8m2-dwmac
+ - amlogic,meson-gxbb-dwmac
+ - amlogic,meson-axg-dwmac
- snps,dwmac
- snps,dwmac-3.50a
- snps,dwmac-3.610
--
2.22.0
^ permalink raw reply related
* Re: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Clément Péron @ 2019-08-05 12:16 UTC (permalink / raw)
To: megous, Chen-Yu Tsai, Alessandro Zummo, Alexandre Belloni,
Rob Herring, Mark Rutland, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <20190805111037.76vmanzcurffpbdf@core.my.home>
Hi,
On Mon, 5 Aug 2019 at 13:10, Ondřej Jirman <megous@megous.com> wrote:
>
> On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous@megous.com> wrote:
> > >
[snip]
>
> Interesting. :) I have the BSP I was using saved here:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649
>
> It's based of 4.9.119
>
> https://megous.com/git/linux/log/?h=h6-4.9-bsp
>
> I don't remember where I found it. But I imported it fairly recently, and
> the code you pointed to looks like an older version that I can found in some
> beta H6 BSP, that I imported way earlier and is based on 4.9.56:
The last recent that I know is from OrangePi H6 but it's based on 4.9.118.
https://github.com/orangepi-xunlong/OrangePiH6_Linux4_9
Regards,
Clément
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
> https://megous.com/git/linux/log/?h=linux-h6
>
> Hmm, archeology. :)
>
> > > For older BSPs, the init sequence looked like this:
> > >
> > > 482 /*
> > > 483 * Step1: select RTC clock source
> > > 484 */
> > > 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> > > 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > > 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > > 488 tmp_data |= (EXT_LOSC_GSM);
> > > 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> > > 490
> > >
> > > EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> > > gain for the oscillator's amplifier in the feedback loop of the circuit.
> > >
> > > So the new code, for some reason changed from single write to sequence
> > > of individual writes/config steps:
> > >
> > > 1) disable auto-switch and enable auto-switch bypass
> > > 2) select RTC clock source (to LOSC)
> > > (wait)
> >
> > Maybe it's possible to glitch if these two are combined?
>
> That's what I thought too. Or the programmer thought so, and was just
> programming defensively, and there's no real problem in the practice.
>
> But that specific delay() seems like someone trying to solve a real issue. Of
> course there's no knowing if it was on H6 or on some other SoC.
>
> regards,
> o.
>
> >
> > > 3) configure gain on the LOSC
> > >
> > > regards,
> > > o.
> > >
> > > > ChenYu
> > >
> > > --
> > > 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/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
>
> --
> 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/20190805111037.76vmanzcurffpbdf%40core.my.home.
^ permalink raw reply
* [RFCv2 9/9] dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-watchdog, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic GXBB Watchdog timer over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../watchdog/amlogic,meson-gxbb-wdt.yaml | 37 +++++++++++++++++++
.../bindings/watchdog/meson-gxbb-wdt.txt | 16 --------
2 files changed, 37 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
new file mode 100644
index 000000000000..d7352f709b37
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/watchdog/amlogic,meson-gxbb-wdt.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Meson GXBB SoCs Watchdog timer
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxbb-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description:
+ A phandle to the clock of this PHY
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ watchdog@98d0 {
+ compatible = "amlogic,meson-gxbb-wdt";
+ reg = <0x98d0 0x10>;
+ clocks = <&xtal>;
+ };
diff --git a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
deleted file mode 100644
index c7fe36fa739c..000000000000
--- a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Meson GXBB SoCs Watchdog timer
-
-Required properties:
-
-- compatible : should be "amlogic,meson-gxbb-wdt"
-- reg : Specifies base physical address and size of the registers.
-- clocks : Should be a phandle to the Watchdog clock source, for GXBB the xtal
- is the default clock source.
-
-Example:
-
-wdt: watchdog@98d0 {
- compatible = "amlogic,meson-gxbb-wdt";
- reg = <0 0x98d0 0x0 0x10>;
- clocks = <&xtal>;
-};
--
2.22.0
^ permalink raw reply related
* [RFCv2 8/9] dt-bindings: serial: meson-uart: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-arm-kernel, linux-serial,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic UART Serial controller over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/serial/amlogic,meson-uart.txt | 38 ----------
.../bindings/serial/amlogic,meson-uart.yaml | 73 +++++++++++++++++++
2 files changed, 73 insertions(+), 38 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
deleted file mode 100644
index c06c045126fc..000000000000
--- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-Amlogic Meson SoC UART Serial Interface
-=======================================
-
-The Amlogic Meson SoC UART Serial Interface is present on a large range
-of SoCs, and can be present either in the "Always-On" power domain or the
-"Everything-Else" power domain.
-
-The particularity of the "Always-On" Serial Interface is that the hardware
-is active since power-on and does not need any clock gating and is usable
-as very early serial console.
-
-Required properties:
-- compatible : compatible: value should be different for each SoC family as :
- - Meson6 : "amlogic,meson6-uart"
- - Meson8 : "amlogic,meson8-uart"
- - Meson8b : "amlogic,meson8b-uart"
- - GX (GXBB, GXL, GXM) : "amlogic,meson-gx-uart"
- eventually followed by : "amlogic,meson-ao-uart" if this UART interface
- is in the "Always-On" power domain.
-- reg : offset and length of the register set for the device.
-- interrupts : identifier to the device interrupt
-- clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock names.
-- clock-names :
- * "xtal" for external xtal clock identifier
- * "pclk" for the bus core clock, either the clk81 clock or the gate clock
- * "baud" for the source of the baudrate generator, can be either the xtal
- or the pclk.
-
-e.g.
-uart_A: serial@84c0 {
- compatible = "amlogic,meson-gx-uart";
- reg = <0x0 0x84c0 0x0 0x14>;
- interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
- /* Use xtal as baud rate clock source */
- clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
- clock-names = "xtal", "pclk", "baud";
-};
diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
new file mode 100644
index 000000000000..5d48a8c04aa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/serial/amlogic,meson-uart.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SoC UART Serial Interface
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Amlogic Meson SoC UART Serial Interface is present on a large range
+ of SoCs, and can be present either in the "Always-On" power domain or the
+ "Everything-Else" power domain.
+
+ The particularity of the "Always-On" Serial Interface is that the hardware
+ is active since power-on and does not need any clock gating and is usable
+ as very early serial console.
+
+properties:
+ compatible:
+ oneOf:
+ - description: Allways-on power domain UART controller
+ items:
+ - enum:
+ - amlogic,meson6-uart
+ - amlogic,meson8-uart
+ - amlogic,meson8b-uart
+ - amlogic,meson-gx-uart
+ - const: amlogic,meson-ao-uart
+ - description: Everything-Else power domain UART controller
+ enum:
+ - amlogic,meson6-uart
+ - amlogic,meson8-uart
+ - amlogic,meson8b-uart
+ - amlogic,meson-gx-uart
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: external xtal clock identifier
+ - description: the bus core clock, either the clk81 clock or the gate clock
+ - description: the source of the baudrate generator, can be either the xtal or the pclk
+
+ clock-names:
+ items:
+ - const: xtal
+ - const: pclk
+ - const: baud
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ serial@84c0 {
+ compatible = "amlogic,meson-gx-uart";
+ reg = <0x84c0 0x14>;
+ interrupts = <26>;
+ clocks = <&xtal>, <&pclk>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ };
--
2.22.0
^ permalink raw reply related
* [RFCv2 7/9] dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt; +Cc: linux-amlogic, devicetree, kishon, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic G12A USB3 + PCIE Combo PHY over to a YAML schemas.
While the original phy bindings specifies phy-supply as required,
the examples and implementations makes it optional, thus phy-supply
is not present in the properties and required lists.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../phy/amlogic,meson-g12a-usb3-pcie-phy.yaml | 57 +++++++++++++++++++
.../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 -------
2 files changed, 57 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
new file mode 100644
index 000000000000..346f9c35427c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic G12A USB3 + PCIE Combo PHY
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-usb3-pcie-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: ref_clk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+examples:
+ - |
+ phy@46000 {
+ compatible = "amlogic,meson-g12a-usb3-pcie-phy";
+ reg = <0x46000 0x2000>;
+ clocks = <&ref_clk>;
+ clock-names = "ref_clk";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
deleted file mode 100644
index 7cfc17e2df31..000000000000
--- a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic G12A USB3 + PCIE Combo PHY binding
-
-Required properties:
-- compatible: Should be "amlogic,meson-g12a-usb3-pcie-phy"
-- #phys-cells: must be 1. The cell number is used to select the phy mode
- as defined in <dt-bindings/phy/phy.h> between PHY_TYPE_USB3 and PHY_TYPE_PCIE
-- reg: The base address and length of the registers
-- clocks: a phandle to the 100MHz reference clock of this PHY
-- clock-names: must be "ref_clk"
-- resets: phandle to the reset lines for the PHY control
-- reset-names: must be "phy"
-
-Example:
- usb3_pcie_phy: phy@46000 {
- compatible = "amlogic,g12a-usb3-pcie-phy";
- reg = <0x0 0x46000 0x0 0x2000>;
- clocks = <&clkc CLKID_PCIE_PLL>;
- clock-names = "ref_clk";
- resets = <&reset RESET_PCIE_PHY>;
- reset-names = "phy";
- #phy-cells = <1>;
- };
--
2.22.0
^ permalink raw reply related
* [RFCv2 6/9] dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt; +Cc: linux-amlogic, devicetree, kishon, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic G12A USB2 PHY over to a YAML schemas.
While the original phy bindings specifies phy-supply as required,
the examples and implementations makes it optional, thus phy-supply
is not in the required list of attributes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../phy/amlogic,meson-g12a-usb2-phy.yaml | 63 +++++++++++++++++++
.../bindings/phy/meson-g12a-usb2-phy.txt | 22 -------
2 files changed, 63 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
new file mode 100644
index 000000000000..51254b4e65dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/amlogic,meson-g12a-usb2-phy.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic G12A USB2 PHY
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-g12a-usb2-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: xtal
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: phy
+
+ "#phy-cells":
+ const: 0
+
+ phy-supply:
+ maxItems: 1
+ description:
+ Phandle to a regulator that provides power to the PHY. This
+ regulator will be managed during the PHY power on/off sequence.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+ - "#phy-cells"
+
+examples:
+ - |
+ phy@36000 {
+ compatible = "amlogic,meson-g12a-usb2-phy";
+ reg = <0x36000 0x2000>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ resets = <&phy_reset>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
deleted file mode 100644
index a6ebc3dea159..000000000000
--- a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic G12A USB2 PHY binding
-
-Required properties:
-- compatible: Should be "amlogic,meson-g12a-usb2-phy"
-- reg: The base address and length of the registers
-- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
-- clocks: a phandle to the clock of this PHY
-- clock-names: must be "xtal"
-- resets: a phandle to the reset line of this PHY
-- reset-names: must be "phy"
-- phy-supply: see phy-bindings.txt in this directory
-
-Example:
- usb2_phy0: phy@36000 {
- compatible = "amlogic,g12a-usb2-phy";
- reg = <0x0 0x36000 0x0 0x2000>;
- clocks = <&xtal>;
- clock-names = "xtal";
- resets = <&reset RESET_USB_PHY21>;
- reset-names = "phy";
- #phy-cells = <0>;
- };
--
2.22.0
^ permalink raw reply related
* [RFCv2 5/9] dt-bindings: arm: amlogic: amlogic, meson-gx-ao-secure: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt; +Cc: linux-amlogic, devicetree, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Always-On Secure Registers over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../amlogic/amlogic,meson-gx-ao-secure.txt | 28 ----------
.../amlogic/amlogic,meson-gx-ao-secure.yaml | 52 +++++++++++++++++++
2 files changed, 52 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
deleted file mode 100644
index c67d9f48fb91..000000000000
--- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Amlogic Meson Firmware registers Interface
-------------------------------------------
-
-The Meson SoCs have a register bank with status and data shared with the
-secure firmware.
-
-Required properties:
- - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon"
-
-Properties should indentify components of this register interface :
-
-Meson GX SoC Information
-------------------------
-A firmware register encodes the SoC type, package and revision information on
-the Meson GX SoCs.
-If present, the following property should be added :
-
-Optional properties:
- - amlogic,has-chip-id: If present, the interface gives the current SoC version.
-
-Example
--------
-
-ao-secure@140 {
- compatible = "amlogic,meson-gx-ao-secure", "syscon";
- reg = <0x0 0x140 0x0 0x140>;
- amlogic,has-chip-id;
-};
diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
new file mode 100644
index 000000000000..853d7d2b56f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Firmware registers Interface
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Meson SoCs have a register bank with status and data shared with the
+ secure firmware.
+
+# We need a select here so we don't match all nodes with 'syscon'
+select:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,meson-gx-ao-secure
+ required:
+ - compatible
+
+properties:
+ compatible:
+ items:
+ - const: amlogic,meson-gx-ao-secure
+ - const: syscon
+
+ reg:
+ maxItems: 1
+
+ amlogic,has-chip-id:
+ description: |
+ A firmware register encodes the SoC type, package and revision
+ information on the Meson GX SoCs. If present, the interface gives
+ the current SoC version.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ ao-secure@140 {
+ compatible = "amlogic,meson-gx-ao-secure", "syscon";
+ reg = <0x140 0x140>;
+ amlogic,has-chip-id;
+ };
--
2.22.0
^ permalink raw reply related
* [RFCv2 4/9] dt-bindings: reset: amlogic,meson-reset: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, p.zabel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Reset controller over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/reset/amlogic,meson-reset.txt | 19 ----------
.../bindings/reset/amlogic,meson-reset.yaml | 37 +++++++++++++++++++
2 files changed, 37 insertions(+), 19 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
deleted file mode 100644
index 28ef6c295c76..000000000000
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-Amlogic Meson SoC Reset Controller
-=======================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or
- "amlogic,meson-axg-reset".
-- reg: should contain the register address base
-- #reset-cells: 1, see below
-
-example:
-
-reset: reset-controller {
- compatible = "amlogic,meson-gxbb-reset";
- reg = <0x0 0x04404 0x0 0x20>;
- #reset-cells = <1>;
-};
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
new file mode 100644
index 000000000000..00917d868d58
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/amlogic,meson-reset.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SoC Reset Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson8b-reset # Reset Controller on Meson8b and compatible SoCs
+ - amlogic,meson-gxbb-reset # Reset Controller on GXBB and compatible SoCs
+ - amlogic,meson-axg-reset # Reset Controller on AXG and compatible SoCs
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+examples:
+ - |
+ reset-controller@c884404 {
+ compatible = "amlogic,meson-gxbb-reset";
+ reg = <0xc884404 0x20>;
+ #reset-cells = <1>;
+ };
--
2.22.0
^ permalink raw reply related
* [RFCv2 3/9] dt-bindings: spi: meson: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-spi, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic SPI controllers over to two separate YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/spi/amlogic,meson-gx-spicc.yaml | 67 +++++++++++++++++++
.../bindings/spi/amlogic,meson6-spifc.yaml | 53 +++++++++++++++
.../devicetree/bindings/spi/spi-meson.txt | 55 ---------------
3 files changed, 120 insertions(+), 55 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-meson.txt
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
new file mode 100644
index 000000000000..49b617c98ae7
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/amlogic,meson-gx-spicc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SPI Communication Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ The Meson SPICC is a generic SPI controller for general purpose Full-Duplex
+ communications with dedicated 16 words RX/TX PIO FIFOs.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gx-spicc # SPICC controller on Amlogic GX and compatible SoCs
+ - amlogic,meson-axg-spicc # SPICC controller on Amlogic AXG and compatible SoCs
+
+ interrupts:
+ maxItems: 1
+
+ reg:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ description: input clock for the baud rate generator
+ items:
+ - const: core
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+examples:
+ - |
+ spi@c1108d80 {
+ compatible = "amlogic,meson-gx-spicc";
+ reg = <0xc1108d80 0x80>;
+ interrupts = <112>;
+ clocks = <&clk81>;
+ clock-names = "core";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995m";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
new file mode 100644
index 000000000000..67dcedc81a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/spi/amlogic,meson6-spifc.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson SPI Flash Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+description: |
+ The Meson SPIFC is a controller optimized for communication with SPI
+ NOR memories, without DMA support and a 64-byte unified transmit /
+ receive buffer.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson6-spifc # SPI Flash Controller on Meson6 and compatible SoCs
+ - amlogic,meson-gxbb-spifc # SPI Flash Controller on GXBB and compatible SoCs
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ spi@c1108c80 {
+ compatible = "amlogic,meson6-spifc";
+ reg = <0xc1108c80 0x80>;
+ clocks = <&clk81>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash: m25p80@0 {
+ compatible = "spansion,m25p80", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+ };
+ };
+
diff --git a/Documentation/devicetree/bindings/spi/spi-meson.txt b/Documentation/devicetree/bindings/spi/spi-meson.txt
deleted file mode 100644
index b7f5e86fed22..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-meson.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-Amlogic Meson SPI controllers
-
-* SPIFC (SPI Flash Controller)
-
-The Meson SPIFC is a controller optimized for communication with SPI
-NOR memories, without DMA support and a 64-byte unified transmit /
-receive buffer.
-
-Required properties:
- - compatible: should be "amlogic,meson6-spifc" or "amlogic,meson-gxbb-spifc"
- - reg: physical base address and length of the controller registers
- - clocks: phandle of the input clock for the baud rate generator
- - #address-cells: should be 1
- - #size-cells: should be 0
-
- spi@c1108c80 {
- compatible = "amlogic,meson6-spifc";
- reg = <0xc1108c80 0x80>;
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
-* SPICC (SPI Communication Controller)
-
-The Meson SPICC is generic SPI controller for general purpose Full-Duplex
-communications with dedicated 16 words RX/TX PIO FIFOs.
-
-Required properties:
- - compatible: should be:
- "amlogic,meson-gx-spicc" on Amlogic GX and compatible SoCs.
- "amlogic,meson-axg-spicc" on Amlogic AXG and compatible SoCs
- - reg: physical base address and length of the controller registers
- - interrupts: The interrupt specifier
- - clock-names: Must contain "core"
- - clocks: phandle of the input clock for the baud rate generator
- - #address-cells: should be 1
- - #size-cells: should be 0
-
-Optional properties:
- - resets: phandle of the internal reset line
-
-See ../spi/spi-bus.txt for more details on SPI bus master and slave devices
-required and optional properties.
-
-Example :
- spi@c1108d80 {
- compatible = "amlogic,meson-gx-spicc";
- reg = <0xc1108d80 0x80>;
- interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "core";
- clocks = <&clk81>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
--
2.22.0
^ permalink raw reply related
* [RFCv2 2/9] dt-bindings: rng: amlogic,meson-rng: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, linux-crypto, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic Random Number generator over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../bindings/rng/amlogic,meson-rng.txt | 21 -----------
.../bindings/rng/amlogic,meson-rng.yaml | 37 +++++++++++++++++++
2 files changed, 37 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
deleted file mode 100644
index 4d403645ac9b..000000000000
--- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Amlogic Meson Random number generator
-=====================================
-
-Required properties:
-
-- compatible : should be "amlogic,meson-rng"
-- reg : Specifies base physical address and size of the registers.
-
-Optional properties:
-
-- clocks : phandle to the following named clocks
-- clock-names: Name of core clock, must be "core"
-
-Example:
-
-rng {
- compatible = "amlogic,meson-rng";
- reg = <0x0 0xc8834000 0x0 0x4>;
- clocks = <&clkc CLKID_RNG0>;
- clock-names = "core";
-};
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
new file mode 100644
index 000000000000..a9ff3cb35c5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/rng/amlogic,meson-rng.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Random number generator
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-rng
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: core
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ rng@c8834000 {
+ compatible = "amlogic,meson-rng";
+ reg = <0xc8834000 0x4>;
+ };
--
2.22.0
^ permalink raw reply related
* [RFCv2 1/9] dt-bindings: mailbox: meson-mhu: convert to yaml
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: linux-amlogic, devicetree, jassisinghbrar, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190805120320.32282-1-narmstrong@baylibre.com>
Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic MHU controller over to a YAML schemas.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../mailbox/amlogic,meson-gxbb-mhu.yaml | 53 +++++++++++++++++++
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ------------
2 files changed, 53 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
delete mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
diff --git a/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
new file mode 100644
index 000000000000..2536a0082cff
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/mailbox/amlogic,meson-gxbb-mhu.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic Meson Message-Handling-Unit Controller
+
+maintainers:
+ - Neil Armstrong <narmstrong@baylibre.com>
+
+description: |
+ The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
+ that has 3 independent channels/links to communicate with remote processor(s).
+ MHU links are hardwired on a platform. A link raises interrupt for any
+ received data. However, there is no specified way of knowing if the sent
+ data has been read by the remote. This driver assumes the sender polls
+ STAT register and the remote clears it after having read the data.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-gxbb-mhu
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+ description:
+ Contains the interrupt information corresponding to each of the 3 links
+ of MHU.
+
+ "#mbox-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#mbox-cells"
+
+examples:
+ - |
+ mailbox@c883c404 {
+ compatible = "amlogic,meson-gxbb-mhu";
+ reg = <0xc883c404 0x4c>;
+ interrupts = <208>, <209>, <210>;
+ #mbox-cells = <1>;
+ };
+
diff --git a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt b/Documentation/devicetree/bindings/mailbox/meson-mhu.txt
deleted file mode 100644
index a530310772b9..000000000000
--- a/Documentation/devicetree/bindings/mailbox/meson-mhu.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Amlogic Meson MHU Mailbox Driver
-================================
-
-The Amlogic's Meson SoCs Message-Handling-Unit (MHU) is a mailbox controller
-that has 3 independent channels/links to communicate with remote processor(s).
-MHU links are hardwired on a platform. A link raises interrupt for any
-received data. However, there is no specified way of knowing if the sent
-data has been read by the remote. This driver assumes the sender polls
-STAT register and the remote clears it after having read the data.
-
-Mailbox Device Node:
-====================
-
-Required properties:
---------------------
-- compatible: Shall be "amlogic,meson-gxbb-mhu"
-- reg: Contains the mailbox register address range (base
- address and length)
-- #mbox-cells Shall be 1 - the index of the channel needed.
-- interrupts: Contains the interrupt information corresponding to
- each of the 2 links of MHU.
-
-Example:
---------
-
- mailbox: mailbox@c883c404 {
- #mbox-cells = <1>;
- compatible = "amlogic,meson-gxbb-mhu";
- reg = <0 0xc883c404 0 0x4c>;
- interrupts = <0 208 IRQ_TYPE_EDGE_RISING>,
- <0 209 IRQ_TYPE_EDGE_RISING>,
- <0 210 IRQ_TYPE_EDGE_RISING>;
- #mbox-cells = <1>;
- };
--
2.22.0
^ permalink raw reply related
* [RFCv2 0/9] dt-bindings: first tentative of conversion to yaml format
From: Neil Armstrong @ 2019-08-05 12:03 UTC (permalink / raw)
To: robh+dt
Cc: p.zabel, devicetree, linux-watchdog, Neil Armstrong,
jassisinghbrar, linux-spi, linux-crypto, linux-serial,
linux-amlogic, kishon, linux-arm-kernel
This is a first tentative to convert some of the simplest Amlogic
dt-bindings to the yaml format.
All have been tested using :
$ make ARCH=arm64 dtbs_check
Issues with the amlogic arm64 DTs has already been identified thanks
to the validation scripts. The DT fixes will be pushed once these yaml
bindings are acked.
Changes since rfc v1:
- Fixed bindings according to Rob's comments
- Added commit log
- renamed yaml files using amlogic prefix
Neil Armstrong (9):
dt-bindings: mailbox: meson-mhu: convert to yaml
dt-bindings: rng: amlogic,meson-rng: convert to yaml
dt-bindings: spi: meson: convert to yaml
dt-bindings: reset: amlogic,meson-reset: convert to yaml
dt-bindings: arm: amlogic: amlogic,meson-gx-ao-secure: convert to yaml
dt-bindings: phy: meson-g12a-usb2-phy: convert to yaml
dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
dt-bindings: serial: meson-uart: convert to yaml
dt-bindings: watchdog: meson-gxbb-wdt: convert to yaml
.../amlogic/amlogic,meson-gx-ao-secure.txt | 28 -------
.../amlogic/amlogic,meson-gx-ao-secure.yaml | 52 +++++++++++++
.../mailbox/amlogic,meson-gxbb-mhu.yaml | 53 ++++++++++++++
.../devicetree/bindings/mailbox/meson-mhu.txt | 34 ---------
.../phy/amlogic,meson-g12a-usb2-phy.yaml | 63 ++++++++++++++++
.../phy/amlogic,meson-g12a-usb3-pcie-phy.yaml | 57 +++++++++++++++
.../bindings/phy/meson-g12a-usb2-phy.txt | 22 ------
.../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 ------
.../bindings/reset/amlogic,meson-reset.txt | 19 -----
.../bindings/reset/amlogic,meson-reset.yaml | 37 ++++++++++
.../bindings/rng/amlogic,meson-rng.txt | 21 ------
.../bindings/rng/amlogic,meson-rng.yaml | 37 ++++++++++
.../bindings/serial/amlogic,meson-uart.txt | 38 ----------
.../bindings/serial/amlogic,meson-uart.yaml | 73 +++++++++++++++++++
.../bindings/spi/amlogic,meson-gx-spicc.yaml | 67 +++++++++++++++++
.../bindings/spi/amlogic,meson6-spifc.yaml | 53 ++++++++++++++
.../devicetree/bindings/spi/spi-meson.txt | 55 --------------
.../watchdog/amlogic,meson-gxbb-wdt.yaml | 37 ++++++++++
.../bindings/watchdog/meson-gxbb-wdt.txt | 16 ----
19 files changed, 529 insertions(+), 255 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt
create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
create mode 100644 Documentation/devicetree/bindings/mailbox/amlogic,meson-gxbb-mhu.yaml
delete mode 100644 Documentation/devicetree/bindings/mailbox/meson-mhu.txt
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
delete mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-reset.yaml
delete mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.yaml
delete mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.txt
create mode 100644 Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml
create mode 100644 Documentation/devicetree/bindings/spi/amlogic,meson6-spifc.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-meson.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/amlogic,meson-gxbb-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
--
2.22.0
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: Add SC7180 pinctrl binding
From: Linus Walleij @ 2019-08-05 11:35 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Bjorn Andersson, MSM, Andy Gross, Rob Herring,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, Jitendra Sharma, Vivek Gautam
In-Reply-To: <CACRpkdYLb-WWSEL8yG3yy8Qq7bOKP9JjUGV51mY6=aEwrQAJvg@mail.gmail.com>
On Mon, Aug 5, 2019 at 1:34 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Aug 1, 2019 at 12:07 PM Rajendra Nayak <rnayak@codeaurora.org> wrote:
>
> > From: Jitendra Sharma <shajit@codeaurora.org>
> >
> > Add the binding for the TLMM pinctrl block found in the SC7180 platform
> >
> > Signed-off-by: Jitendra Sharma <shajit@codeaurora.org>
> > Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
> > [rnayak: Fix some copy-paste issues, sort and fix functions]
> > Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
>
> Patch applied with Bjorn's ACK.
Ooops there is v2 and even v3 coming, OK I wait for v3 and
backed this out.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom: Add SC7180 pinctrl binding
From: Linus Walleij @ 2019-08-05 11:34 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Bjorn Andersson, MSM, Andy Gross, Rob Herring,
open list:GPIO SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, Jitendra Sharma, Vivek Gautam
In-Reply-To: <20190801100717.23333-1-rnayak@codeaurora.org>
On Thu, Aug 1, 2019 at 12:07 PM Rajendra Nayak <rnayak@codeaurora.org> wrote:
> From: Jitendra Sharma <shajit@codeaurora.org>
>
> Add the binding for the TLMM pinctrl block found in the SC7180 platform
>
> Signed-off-by: Jitendra Sharma <shajit@codeaurora.org>
> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
> [rnayak: Fix some copy-paste issues, sort and fix functions]
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Patch applied with Bjorn's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: rockchip: Add support for TB-96AI board
From: Manivannan Sadhasivam @ 2019-08-05 11:28 UTC (permalink / raw)
To: Elon Zhang
Cc: heiko, mark.rutland, robh+dt, linux-rockchip, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20190805015755.26017-1-zhangzj@rock-chips.com>
Hi Elon,
Thanks for the v2. Still the DT needs to be cleaned up a bit. I have tested this
patch on TB96-AI SOM/Carrier board and found that the USB ports are not working
at all! Do we need to change any switch settings?
Comments are inline.
On Mon, Aug 05, 2019 at 09:57:55AM +0800, Elon Zhang wrote:
> Add devicetree support for RK3399Pro TB-96AI board, one of
> the 96Boards family.
>
> The TB-96AI board is a 96Boards Compute SOM design, launched
> by Linaro, Rockchip and Beiqicloud.
>
> More information can be obtained from the following websites:
> 1.https://www.96boards.org/product/tb-96ai/
> 2.http://t.rock-chips.com/
> 3.http://www.beiqicloud.com/
>
> This patch add basic node for the board and support booting up
> to Fedora.
>
> Signed-off-by: Elon Zhang <zhangzj@rock-chips.com>
> ---
> changes since v1:
> - remove needless node
> - using a standard LED formats for 96Boards
>
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3399pro-tb-96ai.dts | 560 ++++++++++++++++++
> 2 files changed, 561 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 5f2687acbf94..3d6c8d4363b5 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -27,3 +27,4 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-tb-96ai.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> new file mode 100644
> index 000000000000..767b37b854ba
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3399pro-tb-96ai.dts
> @@ -0,0 +1,560 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +#include "rk3399pro.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + compatible = "beiqi,rk3399pro-tb-96ai", "rockchip,rk3399pro";
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + xin32k: xin32k {
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "xin32k";
> + #clock-cells = <0>;
> + };
> +
> + vcc5v0_sys: vccsys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + leds {
Still the LEDs are not defined as per the format I shared before...
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&work_led1>,<&work_led2>,<&work_led3>;
> +
> + work_led1 {
> + gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>;
> + label = "system_work_led1";
> + retain-state-suspended;
> + };
> +
> + work_led2 {
> + gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
> + label = "system_work_led2";
> + retain-state-suspended;
> + };
> +
> + work_led3 {
> + gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>;
> + label = "system_work_led3";
> + retain-state-suspended;
> + };
> + };
> +};
> +
> +&cpu_l0 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> + i2c-scl-rising-time-ns = <180>;
> + i2c-scl-falling-time-ns = <30>;
> + clock-frequency = <400000>;
> +
> + rk809: pmic@20 {
> + compatible = "rockchip,rk809";
> + reg = <0x20>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <RK_PC2 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default", "pmic-sleep",
> + "pmic-power-off", "pmic-reset";
Does these pinctrl configs useful other than default?
> + pinctrl-0 = <&pmic_int_l>;
> + pinctrl-1 = <&soc_slppin_slp>, <&rk809_slppin_slp>;
> + pinctrl-2 = <&soc_slppin_gpio>, <&rk809_slppin_pwrdn>;
> + pinctrl-3 = <&soc_slppin_gpio>,<&rk809_slppin_null>;
> + rockchip,system-power-controller;
> + pmic-reset-func = <1>;
> + wakeup-source;
> + #clock-cells = <1>;
> + clock-output-names = "rk808-clkout1", "rk808-clkout2";
> +
> + vcc1-supply = <&vcc5v0_sys>;
> + vcc2-supply = <&vcc5v0_sys>;
> + vcc3-supply = <&vcc5v0_sys>;
> + vcc4-supply = <&vcc5v0_sys>;
> + vcc5-supply = <&vcc_buck5>;
> + vcc6-supply = <&vcc_buck5>;
> + vcc7-supply = <&vcc3v3_sys>;
> + vcc8-supply = <&vcc3v3_sys>;
> + vcc9-supply = <&vcc5v0_sys>;
> +
> + pwrkey {
> + status = "okay";
No compatible needed?
> + };
> +
> + rtc {
> + status = "okay";
No compatible needed?
> + };
> +
> + pinctrl_rk8xx: pinctrl_rk8xx {
Mainline MFD driver has no pinctrl support for RK809.
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + rk809_slppin_null: rk809_slppin_null {
> + pins = "gpio_slp";
> + function = "pin_fun0";
> + };
> +
> + rk809_slppin_slp: rk809_slppin_slp {
> + pins = "gpio_slp";
> + function = "pin_fun1";
> + };
> +
> + rk809_slppin_pwrdn: rk809_slppin_pwrdn {
> + pins = "gpio_slp";
> + function = "pin_fun2";
> + };
> +
> + rk809_slppin_rst: rk809_slppin_rst {
> + pins = "gpio_slp";
> + function = "pin_fun3";
> + };
> + };
> +
> + regulators {
> + vdd_center: DCDC_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-initial-mode = <0x2>;
> + regulator-name = "vdd_center";
Please match the regulator names with schematic.
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <900000>;
> + };
> + };
> +
> + vdd_cpu_l: DCDC_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-initial-mode = <0x2>;
> + regulator-name = "vdd_cpu_l";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "vcc_ddr";
> + regulator-initial-mode = <0x2>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc3v3_sys: DCDC_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-initial-mode = <0x2>;
> + regulator-name = "vcc3v3_sys";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_buck5: DCDC_REG5 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <2200000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-name = "vcc_buck5";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <2200000>;
> + };
> + };
> +
> + vcca_0v9: LDO_REG1 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + regulator-name = "vcca_0v9";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v8: LDO_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-name = "vcc_1v8";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc0v9_soc: LDO_REG3 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-name = "vcc0v9_soc";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <900000>;
> + };
> + };
> +
> + vcca_1v8: LDO_REG4 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-name = "vcca_1v8";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd1v5_dvp: LDO_REG5 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> +
> + regulator-name = "vdd1v5_dvp";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v5: LDO_REG6 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> +
> + regulator-name = "vcc_1v5";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_3v0: LDO_REG7 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-name = "vcc_3v0";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vccio_sd: LDO_REG8 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-name = "vccio_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_sd: LDO_REG9 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-name = "vcc_sd";
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc5v0_usb: SWITCH_REG1 {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> +
> + regulator-name = "vcc5v0_usb";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vccio_3v3: SWITCH_REG2 {
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-name = "vccio_3v3";
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> + };
> + };
> +
> + vdd_cpu_b: regulator@1c {
> + compatible = "fcs,fan53555";
> + reg = <0x1c>;
> + vin-supply = <&vcc5v0_sys>;
> + pinctrl-0 = <&vsel1_gpio>;
> + vsel-gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vdd_cpu_b";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <2300>;
> + fcs,suspend-voltage-selector = <1>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-initial-state = <3>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: regulator@10 {
> + compatible = "fcs,fan53555";
> + status = "okay";
> + reg = <0x10>;
> + vin-supply = <&vcc5v0_sys>;
> + pinctrl-0 = <&vsel2_gpio>;
> + vsel-gpios = <&gpio1 RK_PB6 GPIO_ACTIVE_HIGH>;
> + regulator-name = "vdd_gpu";
> + regulator-min-microvolt = <735000>;
> + regulator-max-microvolt = <1400000>;
> + regulator-ramp-delay = <2300>;
> + fcs,suspend-voltage-selector = <1>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c8 {
> + status = "okay";
> + i2c-scl-rising-time-ns = <345>;
> + i2c-scl-falling-time-ns = <11>;
> + clock-frequency = <100000>;
> +};
> +
> +&io_domains {
> + status = "okay";
> + bt656-supply = <&vcca_1v8>; /* APIO2_VDD */
> + audio-supply = <&vcca_1v8>; /* APIO5_VDD */
> + sdmmc-supply = <&vccio_sd>; /* SDMMC0_VDD */
> + gpio1830-supply = <&vcc_1v8>; /* APIO4_VDD */
> +};
> +
> +&pinctrl {
> + pinctrl-names = "default";
> + pinctrl-0 = <&npu_ref_clk>;
> +
> + leds {
> + work_led1: work_led1 {
> + rockchip,pins =
> + <2 5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + work_led2: work_led2 {
> + rockchip,pins =
> + <2 4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + work_led3: work_led3 {
> + rockchip,pins =
> + <2 3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + npu_clk {
> + npu_ref_clk: npu-ref-clk {
> + rockchip,pins =
> + <0 RK_PA2 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins =
> + <1 RK_PC2 0 &pcfg_pull_up>;
> + };
> +
> + soc_slppin_gpio: soc-slppin-gpio {
> + rockchip,pins =
> + <1 RK_PA5 0 &pcfg_output_low>;
> + };
> +
> + soc_slppin_slp: soc-slppin-slp {
> + rockchip,pins =
> + <1 RK_PA5 1 &pcfg_pull_down>;
> + };
> +
> + vsel1_gpio: vsel1-gpio {
> + rockchip,pins =
> + <1 RK_PC1 0 &pcfg_pull_down>;
> + };
> +
> + vsel2_gpio: vsel2-gpio {
> + rockchip,pins =
> + <1 RK_PB6 0 &pcfg_pull_down>;
> + };
> + };
> +
> + usb3 {
> + usb3_host_en: usb3-host-en {
> + rockchip,pins =
> + <2 RK_PA2 RK_FUNC_GPIO &pcfg_output_high>;
> + };
> + };
> +};
> +
> +&pmu_io_domains {
> + status = "okay";
> + pmu1830-supply = <&vcc_1v8>;
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + status = "okay";
> + vref-supply = <&vcc_1v8>;
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + mmc-hs400-1_8v;
> + non-removable;
> + keep-power-in-suspend;
> + mmc-hs400-enhanced-strobe;
> + status = "okay";
> +};
> +
> +&tcphy1 {
No tcphy0? I can see this used in schematics.
> + status = "okay";
> +};
> +
> +&tsadc {
> + rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
> + rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
> + status = "okay";
> +};
> +
> +&u2phy1 {
No u2phy0?
> + status = "okay";
> +
> + u2phy1_otg: otg-port {
> + status = "okay";
> + };
> +
> + u2phy1_host: host-port {
> + phy-supply = <&vcc5v0_usb>;
> + status = "okay";
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_xfer &uart0_cts>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&uart4 {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host1_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
> +
> +&usb_host1_ohci {
> + status = "okay";
> +};
> +
> +&usbdrd3_1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb3_host_en>;
> +};
> +
> +&usbdrd_dwc3_0 {
No usbdrd3_0?
Thanks,
Mani
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + snps,dis-u3-autosuspend-quirk;
> + status = "okay";
> +};
> +
> --
> 2.17.1
>
>
>
^ permalink raw reply
* Re: [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Chen-Yu Tsai @ 2019-08-05 11:21 UTC (permalink / raw)
To: Ondřej Jirman, Chen-Yu Tsai, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Maxime Ripard,
linux-rtc-u79uwXL29TY76Z2rM5mHXA, devicetree, linux-arm-kernel,
linux-kernel, linux-sunxi
In-Reply-To: <20190805111037.76vmanzcurffpbdf-9v8tmBix7cb9zxVx7UNMDg@public.gmane.org>
On Mon, Aug 5, 2019 at 7:10 PM Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
>
> On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> > On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> > >
> > > On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > > > <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> wrote:
> > > > >
> > > > > From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
> > > > >
> > > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > > mostly in features that are not yet supported by this driver.
> > > > >
> > > > > Some differences are already stated in the comments in existing code.
> > > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > > >
> > > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > > external low speed oscillator is working correctly.
> > > > >
> > > > > This patch adds support for enabling LOSC when necessary:
> > > > >
> > > > > - during reparenting
> > > > > - when probing the clock
> > > > >
> > > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > > external crystal oscillator, to internal RC oscillator, if external
> > > > > oscillator fails. This is enabled by default. Disable it during
> > > > > probe.
> > > > >
> > > > > Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
> > > > > ---
> > > > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > > index 11f56de52179..7375a530c565 100644
> > > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > > @@ -41,9 +41,11 @@
> > > > > /* Control register */
> > > > > #define SUN6I_LOSC_CTRL 0x0000
> > > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> > > >
> > > > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> > > >
> > > > The rest looks ok.
> > >
> > > To give you more information. This is a new thing in H6 BSP, compared
> > > to BSPs for previous SoCs (H5/H3).
> > >
> > > 20 #define REG_CLK32K_AUTO_SWT_EN BIT(14)
> > > 21 #define REG_CLK32K_AUTO_SWT_BYPASS BIT(15)
> > >
> > > Init sequence changed in H6 BSP to:
> > >
> > > 646 /*
> > > 647 * Step1: select RTC clock source
> > > 648 */
> > > 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > > 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > > 651
> > > 652 /* Disable auto switch function */
> > > 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> > > 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > > 655
> > > 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > > 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > > 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > > 659
> > > 660 /* We need to set GSM after change clock source */
> > > 661 udelay(10);
> > > 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > > 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> > > 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > > 665
> >
> > I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
> > The link was from linux-sunxi wiki's H6 page.
> >
> > The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
> >
> > https://github.com/Allwinner-Homlet/H6-BSP4.9-linux
>
> Interesting. :) I have the BSP I was using saved here:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649
>
> It's based of 4.9.119
>
> https://megous.com/git/linux/log/?h=h6-4.9-bsp
>
> I don't remember where I found it. But I imported it fairly recently, and
> the code you pointed to looks like an older version that I can found in some
> beta H6 BSP, that I imported way earlier and is based on 4.9.56:
>
> https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
> https://megous.com/git/linux/log/?h=linux-h6
>
> Hmm, archeology. :)
That's good enough for me. I suppose if we do have any more doubts we could
ask them directly.
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> > > For older BSPs, the init sequence looked like this:
> > >
> > > 482 /*
> > > 483 * Step1: select RTC clock source
> > > 484 */
> > > 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> > > 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > > 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > > 488 tmp_data |= (EXT_LOSC_GSM);
> > > 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> > > 490
> > >
> > > EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> > > gain for the oscillator's amplifier in the feedback loop of the circuit.
> > >
> > > So the new code, for some reason changed from single write to sequence
> > > of individual writes/config steps:
> > >
> > > 1) disable auto-switch and enable auto-switch bypass
> > > 2) select RTC clock source (to LOSC)
> > > (wait)
> >
> > Maybe it's possible to glitch if these two are combined?
>
> That's what I thought too. Or the programmer thought so, and was just
> programming defensively, and there's no real problem in the practice.
>
> But that specific delay() seems like someone trying to solve a real issue. Of
> course there's no knowing if it was on H6 or on some other SoC.
It's probably for the clock waveform to stabilize. Why they do it _after_
switching to the clock is weird though.
> regards,
> o.
>
> >
> > > 3) configure gain on the LOSC
> > >
> > > regards,
> > > o.
> > >
> > > > ChenYu
> > >
> > > --
> > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
>
> --
> 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805111037.76vmanzcurffpbdf%40core.my.home.
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAGb2v65vEK0k3grQyXzzJ0mTXNZZQxg1FPAES6x2z8ZhyhNftA%40mail.gmail.com.
^ permalink raw reply
* Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings
From: Linus Walleij @ 2019-08-05 11:15 UTC (permalink / raw)
To: Harish Jenny K N
Cc: Rob Herring, Bartosz Golaszewski, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Balasubramani Vivekanandan
In-Reply-To: <f1616784-4dbf-d0fa-b33e-c85fd569383a@mentor.com>
On Wed, Jul 10, 2019 at 10:28 AM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
> On 09/07/19 9:38 PM, Rob Herring wrote:
> >> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
> >
> > We already define the active state of GPIOs in the consumers. If
> > there's an inverter in the middle, the consumer active state is simply
> > inverted. I don't agree that that is a hack as Linus said without some
> > reasoning why an inverter needs to be modeled in DT. Anything about
> > what 'userspace' needs is not a reason. That's a Linux thing that has
> > little to do with hardware description.
There is some level of ambition here which is inherently a bit fuzzy
around the edges. ("How long is the coast of Britain?" comes to mind.)
Surely the intention of device tree is not to recreate the schematic
in all detail. What we want is a model of the hardware that will
suffice for the operating system usecases.
But sometimes the DTS files will become confusing: why is this
component using GPIO_ACTIVE_LOW when another system
doesn't have that flag? If there is an explicit inverter, the
DTS gets more readable for a human.
But arguable that is case for adding inverters as syntactic
sugar in the DTS compiler instead...
> Yes we are talking about the hardware level inversions here.
> The usecase is for those without the gpio consumer driver.
> The usecase started with the concept of allowing an abstraction
> of the underlying hardware for the userland controlling program
> such that this program does not care whether the GPIO lines
> are inverted or not physically. In other words, a single userland
> controlling program can work unmodified across a variety of
> hardware platforms with the device tree mapping the logical
> to physical relationship of the GPIO hardware.
> I totally understand anything about what 'userspace' needs is
> not a reason, but this is not restricted to userspace alone as
> kernel drivers may need this just as much. Also we are
> just modelling/describing the hardware state in the device tree.
The kernel also has a need to model inverters and it has come
up from time to time, but I don't remember these instances
right off the top of my head.
I am not sure userspace needs are of zero concerns either.
Sure, for anything reimplementing what I have listed in
Documentation/driver-api/gpio/drivers-on-gpio.rst
it is just abuse of the ABI, but things like industrial control
systems and other one-offs have this need to run the
same binary unmodified for measuring the trigger level
of water in some tank or so, they can't create kernel
drivers for that kind of stuff.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Mark Brown @ 2019-08-05 11:13 UTC (permalink / raw)
To: Ashish Kumar
Cc: devicetree@vger.kernel.org, Han Xu, bbrezillon@kernel.org,
Kuldeep Singh, linux-mtd@lists.infradead.org, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB4015C2C9407598EFEEB4CB2D95DA0@VI1PR04MB4015.eurprd04.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1037 bytes --]
On Mon, Aug 05, 2019 at 09:08:17AM +0000, Ashish Kumar wrote:
> Could you please send this patch[1] from your spi tree, It applies seamlessly on
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/
>
> [1]: http://patchwork.ozlabs.org/patch/1118636/
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [Patch v3 2/2] dt-bindings: spi: spi-fsl-qspi: Add bindings of ls1088a and ls1012a
From: Mark Brown @ 2019-08-05 11:13 UTC (permalink / raw)
To: Ashish Kumar
Cc: devicetree@vger.kernel.org, Han Xu, bbrezillon@kernel.org,
Kuldeep Singh, linux-mtd@lists.infradead.org, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <VI1PR04MB401579932CF0E7D4AE80E0C995DA0@VI1PR04MB4015.eurprd04.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1037 bytes --]
On Mon, Aug 05, 2019 at 09:07:47AM +0000, Ashish Kumar wrote:
> Could you please send this patch[1] from your spi tree, It applies seamlessly on
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/
>
> [1]: http://patchwork.ozlabs.org/patch/1118637/
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Ondřej Jirman @ 2019-08-05 11:10 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Maxime Ripard, linux-rtc-u79uwXL29TY76Z2rM5mHXA, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <CAGb2v67pcxdxjdRX_HN4133A32eA566DDtUJUKV7pqzxDtOaeg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 05, 2019 at 06:54:17PM +0800, Chen-Yu Tsai wrote:
> On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org> wrote:
> >
> > On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > > <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> wrote:
> > > >
> > > > From: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
> > > >
> > > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > > mostly in features that are not yet supported by this driver.
> > > >
> > > > Some differences are already stated in the comments in existing code.
> > > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > > >
> > > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > > external low speed oscillator is working correctly.
> > > >
> > > > This patch adds support for enabling LOSC when necessary:
> > > >
> > > > - during reparenting
> > > > - when probing the clock
> > > >
> > > > H6 also has capacbility to automatically reparent RTC clock from
> > > > external crystal oscillator, to internal RC oscillator, if external
> > > > oscillator fails. This is enabled by default. Disable it during
> > > > probe.
> > > >
> > > > Signed-off-by: Ondrej Jirman <megous-5qf/QAjKc83QT0dZR+AlfA@public.gmane.org>
> > > > ---
> > > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > > index 11f56de52179..7375a530c565 100644
> > > > --- a/drivers/rtc/rtc-sun6i.c
> > > > +++ b/drivers/rtc/rtc-sun6i.c
> > > > @@ -41,9 +41,11 @@
> > > > /* Control register */
> > > > #define SUN6I_LOSC_CTRL 0x0000
> > > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> > >
> > > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> > >
> > > The rest looks ok.
> >
> > To give you more information. This is a new thing in H6 BSP, compared
> > to BSPs for previous SoCs (H5/H3).
> >
> > 20 #define REG_CLK32K_AUTO_SWT_EN BIT(14)
> > 21 #define REG_CLK32K_AUTO_SWT_BYPASS BIT(15)
> >
> > Init sequence changed in H6 BSP to:
> >
> > 646 /*
> > 647 * Step1: select RTC clock source
> > 648 */
> > 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > 651
> > 652 /* Disable auto switch function */
> > 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> > 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 655
> > 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 659
> > 660 /* We need to set GSM after change clock source */
> > 661 udelay(10);
> > 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> > 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> > 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> > 665
>
> I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
> The link was from linux-sunxi wiki's H6 page.
>
> The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
>
> https://github.com/Allwinner-Homlet/H6-BSP4.9-linux
Interesting. :) I have the BSP I was using saved here:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=h6-4.9-bsp#n649
It's based of 4.9.119
https://megous.com/git/linux/log/?h=h6-4.9-bsp
I don't remember where I found it. But I imported it fairly recently, and
the code you pointed to looks like an older version that I can found in some
beta H6 BSP, that I imported way earlier and is based on 4.9.56:
https://megous.com/git/linux/tree/drivers/rtc/rtc-sunxi.c?h=linux-h6
https://megous.com/git/linux/log/?h=linux-h6
Hmm, archeology. :)
> > For older BSPs, the init sequence looked like this:
> >
> > 482 /*
> > 483 * Step1: select RTC clock source
> > 484 */
> > 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> > 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> > 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> > 488 tmp_data |= (EXT_LOSC_GSM);
> > 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> > 490
> >
> > EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> > gain for the oscillator's amplifier in the feedback loop of the circuit.
> >
> > So the new code, for some reason changed from single write to sequence
> > of individual writes/config steps:
> >
> > 1) disable auto-switch and enable auto-switch bypass
> > 2) select RTC clock source (to LOSC)
> > (wait)
>
> Maybe it's possible to glitch if these two are combined?
That's what I thought too. Or the programmer thought so, and was just
programming defensively, and there's no real problem in the practice.
But that specific delay() seems like someone trying to solve a real issue. Of
course there's no knowing if it was on H6 or on some other SoC.
regards,
o.
>
> > 3) configure gain on the LOSC
> >
> > regards,
> > o.
> >
> > > ChenYu
> >
> > --
> > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
--
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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20190805111037.76vmanzcurffpbdf%40core.my.home.
^ permalink raw reply
* Re: [PATCH v2 3/3] soc/tegra: regulators: Add regulators coupler for Tegra30
From: Dmitry Osipenko @ 2019-08-05 11:03 UTC (permalink / raw)
To: Peter De Schrijver
Cc: Rob Herring, Thierry Reding, Jonathan Hunter, Mark Brown,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <20190805083325.GE3883@pdeschrijver-desktop.Nvidia.com>
05.08.2019 11:33, Peter De Schrijver пишет:
> On Fri, Aug 02, 2019 at 05:39:23PM +0300, Dmitry Osipenko wrote:
>> 02.08.2019 17:05, Peter De Schrijver пишет:
>>> On Thu, Jul 25, 2019 at 06:18:32PM +0300, Dmitry Osipenko wrote:
>>>> Add regulators coupler for Tegra30 SoCs that performs voltage balancing
>>>> of a coupled regulators and thus provides voltage scaling functionality.
>>>>
>>>> There are 2 coupled regulators on all Tegra30 SoCs: CORE and CPU. The
>>>> coupled regulator voltages shall be in a range of 300mV from each other
>>>> and CORE voltage shall be higher than the CPU by N mV, where N depends
>>>> on the CPU voltage.
>>>>
>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>> ---
>>>> drivers/soc/tegra/Kconfig | 4 +
>>>> drivers/soc/tegra/Makefile | 1 +
>>>> drivers/soc/tegra/regulators-tegra30.c | 316 +++++++++++++++++++++++++
>>>> 3 files changed, 321 insertions(+)
>>>> create mode 100644 drivers/soc/tegra/regulators-tegra30.c
>>>>
>>> ...
>>>
>>>> +
>>>> +static int tegra30_core_cpu_limit(int cpu_uV)
>>>> +{
>>>> + if (cpu_uV < 800000)
>>>> + return 950000;
>>>> +
>>>> + if (cpu_uV < 900000)
>>>> + return 1000000;
>>>> +
>>>> + if (cpu_uV < 1000000)
>>>> + return 1100000;
>>>> +
>>>> + if (cpu_uV < 1100000)
>>>> + return 1200000;
>>>> +
>>>> + if (cpu_uV < 1250000) {
>>>> + switch (tegra_sku_info.cpu_speedo_id) {
>>>> + case 0 ... 1:
>>> Aren't we supposed to add /* fall through */ here now?
>>
>> There is no compiler warning if there is nothing in-between of the
>> case-switches, so annotation isn't really necessary here. Of course it
>> is possible to add an explicit annotation just to make clear the
>> fall-through intention.
>>
>
> Ah. Ok. Whatever you want then :)
I'll add the comments if there will be a need to re-spin this series.
>>>> + case 4:
>>>> + case 7 ... 8:
>>>> + return 1200000;
>>>> +
>>>> + default:
>>>> + return 1300000;
>>>> + }
>>>> + }
>>>> +
>>>
>>> Other than that, this looks ok to me.
>>
>> Awesome, thank you very much! Explicit ACK will be appreciated as well.
>
> Acked-By: Peter De Schrijver <pdeschrijver@nvidia.com>
Thank you again! Could you please also clarify whether the ACK is for
this patch only or for all of three patches?
^ permalink raw reply
* Re: [linux-sunxi] [PATCH 2/3] rtc: sun6i: Add support for H6 RTC
From: Chen-Yu Tsai @ 2019-08-05 10:54 UTC (permalink / raw)
To: Ondřej Jirman, Chen-Yu Tsai, Alessandro Zummo,
Alexandre Belloni, Rob Herring, Mark Rutland, Maxime Ripard,
linux-rtc, devicetree, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20190805104529.z3mex3m2tss7lzlr@core.my.home>
On Mon, Aug 5, 2019 at 6:45 PM Ondřej Jirman <megous@megous.com> wrote:
>
> On Mon, Aug 05, 2019 at 06:16:14PM +0800, Chen-Yu Tsai wrote:
> > On Fri, Apr 12, 2019 at 8:07 PM megous via linux-sunxi
> > <linux-sunxi@googlegroups.com> wrote:
> > >
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > RTC on H6 is mostly the same as on H5 and H3. It has slight differences
> > > mostly in features that are not yet supported by this driver.
> > >
> > > Some differences are already stated in the comments in existing code.
> > > One other difference is that H6 has extra bit in LOSC_CTRL_REG, called
> > > EXT_LOSC_EN to enable/disable external low speed crystal oscillator.
> > >
> > > It also has bit EXT_LOSC_STA in LOSC_AUTO_SWT_STA_REG, to check whether
> > > external low speed oscillator is working correctly.
> > >
> > > This patch adds support for enabling LOSC when necessary:
> > >
> > > - during reparenting
> > > - when probing the clock
> > >
> > > H6 also has capacbility to automatically reparent RTC clock from
> > > external crystal oscillator, to internal RC oscillator, if external
> > > oscillator fails. This is enabled by default. Disable it during
> > > probe.
> > >
> > > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > > ---
> > > drivers/rtc/rtc-sun6i.c | 40 ++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> > > index 11f56de52179..7375a530c565 100644
> > > --- a/drivers/rtc/rtc-sun6i.c
> > > +++ b/drivers/rtc/rtc-sun6i.c
> > > @@ -41,9 +41,11 @@
> > > /* Control register */
> > > #define SUN6I_LOSC_CTRL 0x0000
> > > #define SUN6I_LOSC_CTRL_KEY (0x16aa << 16)
> > > +#define SUN6I_LOSC_CTRL_AUTO_SWT_BYPASS BIT(15)
> >
> > Manual says bit 14? Or is this different from LOSC_AUTO_SWT_EN?
> >
> > The rest looks ok.
>
> To give you more information. This is a new thing in H6 BSP, compared
> to BSPs for previous SoCs (H5/H3).
>
> 20 #define REG_CLK32K_AUTO_SWT_EN BIT(14)
> 21 #define REG_CLK32K_AUTO_SWT_BYPASS BIT(15)
>
> Init sequence changed in H6 BSP to:
>
> 646 /*
> 647 * Step1: select RTC clock source
> 648 */
> 649 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> 650 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> 651
> 652 /* Disable auto switch function */
> 653 tmp_data |= REG_CLK32K_AUTO_SWT_BYPASS;
> 654 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> 655
> 656 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> 657 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> 658 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> 659
> 660 /* We need to set GSM after change clock source */
> 661 udelay(10);
> 662 tmp_data = readl(chip->base + SUNXI_LOSC_CTRL);
> 663 tmp_data |= (EXT_LOSC_GSM | REG_LOSCCTRL_MAGIC);
> 664 writel(tmp_data, chip->base + SUNXI_LOSC_CTRL);
> 665
I don't have this in my H6 BSPs. One is H6 Lichee v1.1 downloaded from Pine64.
The link was from linux-sunxi wiki's H6 page.
The other is a 4.9 kernel tree, which I believe is from Allwinner's github:
https://github.com/Allwinner-Homlet/H6-BSP4.9-linux
> For older BSPs, the init sequence looked like this:
>
> 482 /*
> 483 * Step1: select RTC clock source
> 484 */
> 485 tmp_data = sunxi_rtc_read(SUNXI_LOSC_CTRL_REG);
> 486 tmp_data &= (~REG_CLK32K_AUTO_SWT_EN);
> 487 tmp_data |= (RTC_SOURCE_EXTERNAL | REG_LOSCCTRL_MAGIC);
> 488 tmp_data |= (EXT_LOSC_GSM);
> 489 sunxi_rtc_write(tmp_data, SUNXI_LOSC_CTRL_REG);
> 490
>
> EXT_LOSC_GSM has values 4 values from low to high, and I guess it configures
> gain for the oscillator's amplifier in the feedback loop of the circuit.
>
> So the new code, for some reason changed from single write to sequence
> of individual writes/config steps:
>
> 1) disable auto-switch and enable auto-switch bypass
> 2) select RTC clock source (to LOSC)
> (wait)
Maybe it's possible to glitch if these two are combined?
> 3) configure gain on the LOSC
>
> regards,
> o.
>
> > ChenYu
>
> --
> 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/20190805104529.z3mex3m2tss7lzlr%40core.my.home.
^ permalink raw reply
* Re: [PATCH v7 01/20] pinctrl: tegra: Add suspend and resume support
From: Dmitry Osipenko @ 2019-08-05 10:50 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree, rjw, viresh.kumar, linux-pm
In-Reply-To: <1564607463-28802-2-git-send-email-skomatineni@nvidia.com>
01.08.2019 0:10, Sowjanya Komatineni пишет:
> This patch adds support for Tegra pinctrl driver suspend and resume.
>
> During suspend, context of all pinctrl registers are stored and
> on resume they are all restored to have all the pinmux and pad
> configuration for normal operation.
>
> Acked-by: Thierry Reding <treding@nvidia.com>
> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
> drivers/pinctrl/tegra/pinctrl-tegra.c | 59 +++++++++++++++++++++++++++++++++++
> drivers/pinctrl/tegra/pinctrl-tegra.h | 3 ++
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c
> index 186ef98e7b2b..e3a237534281 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> @@ -631,6 +631,58 @@ static void tegra_pinctrl_clear_parked_bits(struct tegra_pmx *pmx)
> }
> }
>
> +static size_t tegra_pinctrl_get_bank_size(struct device *dev,
> + unsigned int bank_id)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, bank_id);
> +
> + return resource_size(res) / 4;
> +}
> +
> +static int tegra_pinctrl_suspend(struct device *dev)
> +{
> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
> + u32 *backup_regs = pmx->backup_regs;
> + u32 *regs;
> + size_t bank_size;
> + unsigned int i, k;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + bank_size = tegra_pinctrl_get_bank_size(dev, i);
> + regs = pmx->regs[i];
> + for (k = 0; k < bank_size; k++)
> + *backup_regs++ = readl_relaxed(regs++);
> + }
> +
> + return pinctrl_force_sleep(pmx->pctl);
> +}
> +
> +static int tegra_pinctrl_resume(struct device *dev)
> +{
> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
> + u32 *backup_regs = pmx->backup_regs;
> + u32 *regs;
> + size_t bank_size;
> + unsigned int i, k;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + bank_size = tegra_pinctrl_get_bank_size(dev, i);
> + regs = pmx->regs[i];
> + for (k = 0; k < bank_size; k++)
> + writel_relaxed(*backup_regs++, regs++);
> + }
I'm now curious whether any kind of barrier is needed after the
writings. The pmx_writel() doesn't insert a barrier after the write and
seems it just misuses writel, which actually should be writel_relaxed()
+ barrier, IIUC.
It's also not obvious whether PINCTRL HW has any kind of write-FIFO and
thus maybe read-back + rmb() is needed in order ensure that writes are
actually completed.
The last thing which is not obvious is when the new configuration
actually takes into effect, does it happen immediately or maybe some
delay is needed?
[snip]
^ permalink raw reply
* [PATCH v14 5/5] arm64: dts: mt8183: add scp node
From: Pi-Hsun Shih @ 2019-08-05 10:49 UTC (permalink / raw)
Cc: Pi-Hsun Shih, Eddie Huang, Erin Lo, Rob Herring, Mark Rutland,
Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list
In-Reply-To: <20190805104932.96745-1-pihsun@chromium.org>
From: Eddie Huang <eddie.huang@mediatek.com>
Add scp node to mt8183 and mt8183-evb
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Signed-off-by: Eddie Huang <eddie.huang@mediatek.com>
---
Changes from v13:
- Change the size of the cfg register region.
Changes from v12, v11, v10:
- No change.
Changes from v9:
- Remove extra reserve-memory-vpu_share node.
Changes from v8:
- New patch.
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +++++++++++
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 ++++++++++++
2 files changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index d8e555cbb5d3..e46e34ce3159 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -24,6 +24,17 @@
chosen {
stdout-path = "serial0:921600n8";
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ scp_mem_reserved: scp_mem_region {
+ compatible = "shared-dma-pool";
+ reg = <0 0x50000000 0 0x2900000>;
+ no-map;
+ };
+ };
};
&auxadc {
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index c2749c4631bc..871754c2f477 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -254,6 +254,18 @@
clock-names = "spi", "wrap";
};
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x19080>;
+ reg-names = "sram", "cfg";
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ memory-region = <&scp_mem_reserved>;
+ status = "disabled";
+ };
+
auxadc: auxadc@11001000 {
compatible = "mediatek,mt8183-auxadc",
"mediatek,mt8173-auxadc";
--
2.22.0.770.g0f2c4a37fd-goog
^ permalink raw reply related
* [PATCH v14 1/5] dt-bindings: Add a binding for Mediatek SCP
From: Pi-Hsun Shih @ 2019-08-05 10:49 UTC (permalink / raw)
Cc: Pi-Hsun Shih, Erin Lo, Rob Herring, Ohad Ben-Cohen,
Bjorn Andersson, Rob Herring, Mark Rutland, Matthias Brugger,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support, open list
In-Reply-To: <20190805104932.96745-1-pihsun@chromium.org>
From: Erin Lo <erin.lo@mediatek.com>
Add a DT binding documentation of SCP for the
MT8183 SoC from Mediatek.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes from v13, v12, v11, v10, v9, v8, v7, v6:
- No change.
Changes from v5:
- Remove dependency on CONFIG_RPMSG_MTK_SCP.
Changes from v4:
- Add detail of more properties.
- Document the usage of mtk,rpmsg-name in subnode from the new design.
Changes from v3:
- No change.
Changes from v2:
- No change. I realized that for this patch series, there's no need to
add anything under the mt8183-scp node (neither the mt8183-rpmsg or
the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
created by SCP name service.
Changes from v1:
- No change.
---
.../bindings/remoteproc/mtk,scp.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
new file mode 100644
index 000000000000..3ba668bab14b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
@@ -0,0 +1,36 @@
+Mediatek SCP Bindings
+----------------------------------------
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+Mediatek SoCs.
+
+Required properties:
+- compatible Should be "mediatek,mt8183-scp"
+- reg Should contain the address ranges for the two memory
+ regions, SRAM and CFG.
+- reg-names Contains the corresponding names for the two memory
+ regions. These should be named "sram" & "cfg".
+- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-names Contains the corresponding name for the clock. This
+ should be named "main".
+
+Subnodes
+--------
+
+Subnodes of the SCP represent rpmsg devices. The names of the devices are not
+important. The properties of these nodes are defined by the individual bindings
+for the rpmsg devices - but must contain the following property:
+
+- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match
+ the subnode to rpmsg device announced by SCP.
+
+Example:
+
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x5000>;
+ reg-names = "sram", "cfg";
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ };
--
2.22.0.770.g0f2c4a37fd-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox