ARM: dts: Last round of DT schema fixes
Subsystems (26)
v2 cover ARM: dts: Last round of DT schema fixes
Hi,
Here's another round of schema warnings fixes for the Allwinner platform.
There's a fair share of new schemas in there since the schema tools now warn when a compatible is not documented in a schema.
We don't have any warning anymore if we use the OPP binding Rob submitted, and since that means we have all our devices properly validated I don't expect more fixes now, aside from the usual bunch of regressions.
Let me know what you think,
Maxime
Maxime Ripard (52):
ASoC: dt-bindings: Add WM8978 Binding
ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema
ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema
ASoC: dt-bindings: Convert Simple Amplifier binding to a schema
dt-bindings: Convert Reserved Memory binding to a schema
dt-bindings: arm: Convert ARM CCI-400 binding to a schema
dt-bindings: bluetooth: broadcom: Fix clocks check
dt-bindings: bluetooth: realtek: Add missing max-speed
dt-bindings: clocks: Fix typo in the H6 compatible
dt-bindings: display: Move idk-1110wr to panel-lvds
dt-bindings: display: Move idk-2121wr to panel-lvds
dt-bindings: display: Move ee101ia-01d to panel-lvds
dt-bindings: display: aa104xd12: Remove unused vcc-supply
dt-bindings: display: aa104xd12: Fix data-mapping
dt-bindings: display: Move aa104xd12 to panel-lvds
dt-bindings: display: aa121td01: Remove unused vcc-supply
dt-bindings: display: aa121td01: Fix data-mapping
dt-bindings: display: Move aa121td01 to panel-lvds
dt-bindings: display: Move gktw70sdae4se to panel-lvds
dt-bindings: display: panel-lvds: Document missing panel compatibles
dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema
dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema
dt-bindings: hwmon: Add IIO HWMON binding
dt-bindings: input: Convert Silead GSL1680 binding to a schema
dt-bindings: interconnect: sunxi: Add R40 MBUS compatible
dt-bindings: media: ti,cal: Fix example
dt-bindings: media: Convert OV5640 binding to a schema
dt-bindings: mfd: Convert X-Powers AC100 binding to a schema
dt-bindings: mfd: Convert X-Powers AXP binding to a schema
dt-bindings: mmc: Convert MMC Card binding to a schema
dt-bindings: net: dwmac: Fix typo in the R40 compatible
dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema
dt-bindings: regulator: Convert SY8106A binding to a schema
dt-bindings: sunxi: Add CPU Configuration Controller Binding
dt-bindings: sunxi: Add Allwinner A80 PRCM Binding
dt-bindings: usb: Convert SMSC USB3503 binding to a schema
dt-bindings: usb: dwc3: Fix usb-phy check
dt-bindings: w1: Convert 1-Wire GPIO binding to a schema
ARM: dts: sunxi: Rename power-supply names
ARM: dts: sunxi: Rename gpio pinctrl names
ARM: dts: sunxi: Fix OPP arrays
ARM: dts: sunxi: Fix OPPs node name
ARM: dts: sunxi: Fix the SPI NOR node names
ARM: dts: v3s: Remove useless DMA properties
ARM: dts: tbs711: Fix touchscreen compatible
ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible
arm64: dts: allwinner: h5: Fix GPU thermal zone node name
arm64: dts: allwinner: h6: Fix de3 parent clocks ordering
arm64: dts: allwinner: a100: Fix thermal zone node name
arm64: dts: allwinner: pinetab: Change regulator node name to avoid
warning
arm64: dts: allwinner: teres-i: Add missing reg
arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC
.../devicetree/bindings/arm/arm,cci-400.yaml | 216 ++++++++++ .../bindings/arm/cci-control-port.yaml | 38 ++ Documentation/devicetree/bindings/arm/cci.txt | 224 ---------- .../devicetree/bindings/arm/cpus.yaml | 2 + .../arm/sunxi/allwinner,sun4i-a10-mbus.yaml | 1 + .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml | 38 ++ .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml | 33 ++ .../clock/allwinner,sun8i-a83t-de2-clk.yaml | 2 +- .../display/panel/advantech,idk-1110wr.yaml | 69 --- .../display/panel/advantech,idk-2121wr.yaml | 121 ------ .../display/panel/innolux,ee101ia-01d.yaml | 31 -- .../bindings/display/panel/lvds.yaml | 130 +++++- .../display/panel/mitsubishi,aa104xd12.yaml | 75 ---- .../display/panel/mitsubishi,aa121td01.yaml | 74 ---- .../display/panel/sgd,gktw70sdae4se.yaml | 68 --- .../bindings/gnss/u-blox,neo-6m.yaml | 62 +++ .../devicetree/bindings/gnss/u-blox.txt | 45 -- .../devicetree/bindings/gpio/gpio-axp209.txt | 75 ---- .../bindings/gpio/x-powers,axp209-gpio.yaml | 55 +++ .../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 ++ .../i2c/allwinner,sun6i-a31-p2wi.yaml | 2 +- .../input/touchscreen/silead,gsl1680.yaml | 91 ++++ .../input/touchscreen/silead_gsl1680.txt | 44 -- .../devicetree/bindings/media/i2c/ov5640.txt | 92 ---- .../bindings/media/i2c/ovti,ov5640.yaml | 154 +++++++ .../devicetree/bindings/media/ti,cal.yaml | 4 +- .../devicetree/bindings/mfd/ac100.txt | 50 --- .../devicetree/bindings/mfd/axp20x.txt | 273 ------------ .../bindings/mfd/x-powers,ac100.yaml | 116 +++++ .../bindings/mfd/x-powers,axp152.yaml | 400 ++++++++++++++++++ .../devicetree/bindings/mmc/mmc-card.txt | 30 -- .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++ .../bindings/mmc/mmc-controller.yaml | 6 - .../net/allwinner,sun8i-a83t-emac.yaml | 4 +- .../bindings/net/broadcom-bluetooth.yaml | 17 +- .../bindings/net/realtek-bluetooth.yaml | 2 + .../devicetree/bindings/net/snps,dwmac.yaml | 6 +- .../bindings/net/wireless/esp,esp8089.txt | 30 -- .../bindings/net/wireless/esp,esp8089.yaml | 43 ++ .../bindings/regulator/silergy,sy8106a.yaml | 52 +++ .../bindings/regulator/sy8106a-regulator.txt | 23 - .../reserved-memory/memory-region.yaml | 40 ++ .../reserved-memory/reserved-memory.txt | 172 +------- .../reserved-memory/reserved-memory.yaml | 96 +++++ .../reserved-memory/shared-dma-pool.yaml | 87 ++++ .../devicetree/bindings/sound/bt-sco.txt | 13 - .../bindings/sound/linux,bt-sco.yaml | 38 ++ .../bindings/sound/linux,spdif-dit.yaml | 32 ++ .../bindings/sound/simple-amplifier.txt | 17 - .../sound/simple-audio-amplifier.yaml | 45 ++ .../bindings/sound/spdif-transmitter.txt | 10 - .../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++ .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 +++++ .../devicetree/bindings/usb/snps,dwc3.yaml | 10 +- .../devicetree/bindings/usb/usb3503.txt | 39 -- .../devicetree/bindings/w1/w1-gpio.txt | 27 -- .../devicetree/bindings/w1/w1-gpio.yaml | 44 ++ arch/arm/boot/dts/axp209.dtsi | 6 +- arch/arm/boot/dts/axp22x.dtsi | 6 +- arch/arm/boot/dts/axp81x.dtsi | 10 +- .../arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 11 +- arch/arm/boot/dts/sun4i-a10.dtsi | 11 +- arch/arm/boot/dts/sun5i-a13.dtsi | 15 +- arch/arm/boot/dts/sun6i-a31.dtsi | 44 +- arch/arm/boot/dts/sun7i-a20-bananapi.dts | 17 +- arch/arm/boot/dts/sun7i-a20.dtsi | 34 +- arch/arm/boot/dts/sun8i-a33.dtsi | 4 +- arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 2 +- arch/arm/boot/dts/sun8i-a83t.dtsi | 4 +- arch/arm/boot/dts/sun8i-h3.dtsi | 4 +- arch/arm/boot/dts/sun8i-v3-sl631.dtsi | 2 +- arch/arm/boot/dts/sun8i-v3s.dtsi | 2 - arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 2 +- .../boot/dts/sunxi-libretech-all-h3-it.dtsi | 2 +- arch/arm64/boot/dts/allwinner/axp803.dtsi | 10 +- .../arm64/boot/dts/allwinner/sun50i-a100.dtsi | 6 +- .../dts/allwinner/sun50i-a64-cpu-opp.dtsi | 2 +- .../dts/allwinner/sun50i-a64-orangepi-win.dts | 2 +- .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +- .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 3 +- .../boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi | 2 +- arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +- .../boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi | 2 +- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 +- 84 files changed, 2191 insertions(+), 1743 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml delete mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml create mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml delete mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt create mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml create mode 100644 Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml delete mode 100644 Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt create mode 100644 Documentation/devicetree/bindings/reserved-memory/memory-region.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt create mode 100644 Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml delete mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml
Signature · 1 line
2.31.1
A message that is not in the archive (sent off-list or not yet received): 20210901091852.479202-1-maxime-R63rPqgGiG5yDzI6CaY1VQ@public.gmane.org
PATCH v2 5/52 dt-bindings: Convert Reserved Memory binding to a schema
The Reserved Memory mechanism is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Fixed the license
- Added a mention that the file has moved
- Added a documentation for memory-region
- Split the reserved-memory binding in two: one for the generic part and one for shared-dma-pool
--- .../reserved-memory/memory-region.yaml | 40 ++++ .../reserved-memory/reserved-memory.txt | 172 +----------------- .../reserved-memory/reserved-memory.yaml | 96 ++++++++++ .../reserved-memory/shared-dma-pool.yaml | 87 +++++++++ 4 files changed, 224 insertions(+), 171 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/memory-region.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
Documentation/devicetree/bindings/reserved-memory/memory-region.yaml new file +40 -0
@@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/memory-region.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Reserved Memory Region Device Tree Binding + +maintainers: + - Devicetree Specification Mailing List <[email protected]> + +description: | + Regions in the /reserved-memory node may be referenced by other device + nodes by adding a memory-region property to the device node. + +select: true + +properties: + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: > + Phandle to a /reserved-memory child node assigned to the device. + + memory-region-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: > + A list of names, one for each corresponding entry in the + memory-region property + +additionalProperties: true + +examples: + - | + fb0: video@12300000 { + /* ... */ + reg = <0x12300000 0x1000>; + memory-region = <&display_reserved>; + }; + +...
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +1 -171
172 lines not on this page · raw message
Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml new file +96 -0
96 lines not on this page · raw message
Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml new file +87 -0
87 lines not on this page · raw message
Signature · 1 line
2.31.1
A message that is not in the archive (sent off-list or not yet received): 20210901091852.479202-6-maxime-R63rPqgGiG5yDzI6CaY1VQ@public.gmane.org
Re: [PATCH v2 05/52] dt-bindings: Convert Reserved Memory binding to a schema
Quoted 8 lines · Maxime Ripard
The Reserved Memory mechanism is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Mailing List <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Minor request. As device tree bindings are used and valid and applicable outside of Linux, it shouldn't be mentioned in the commit message either. This binding is just as valid for U-Boot, FreeBSD, etc as it is for Linux :) Thanks!
Signature · 1 line
Tom
Re: [PATCH v2 05/52] dt-bindings: Convert Reserved Memory binding to a schema
In reply to a message not in the archiveQuoted 17 lines · Maxime Ripard
The Reserved Memory mechanism is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Mailing List <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Fixed the license
- Added a mention that the file has moved
- Added a documentation for memory-region
- Split the reserved-memory binding in two: one for the generic part and one for shared-dma-pool
Quoted 10 lines
--- .../reserved-memory/memory-region.yaml | 40 ++++ .../reserved-memory/reserved-memory.txt | 172 +----------------- .../reserved-memory/reserved-memory.yaml | 96 ++++++++++ .../reserved-memory/shared-dma-pool.yaml | 87 +++++++++ 4 files changed, 224 insertions(+), 171 deletions(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/memory-region.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml create mode 100644 Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml
I reworked the commit msg and a couple of nits, and applied, thanks!
PATCH v2 1/52 ASoC: dt-bindings: Add WM8978 Binding
In reply to Maxime RipardEven though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
---
Changes from v1:
- Changed the maintainers of the bindings
--- .../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
Documentation/devicetree/bindings/sound/wlf,wm8978.yaml new file +58 -0
@@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wlf,wm8978.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Wolfson WM8978 Codec Device Tree Bindings + +maintainers: + - [email protected] + +properties: + '#sound-dai-cells': + const: 0 + + compatible: + const: wlf,wm8978 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 526000 + +required: + - '#sound-dai-cells' + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + codec@0 { + #sound-dai-cells = <0>; + compatible = "wlf,wm8978"; + reg = <0>; + spi-max-frequency = <500000>; + }; + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@0 { + #sound-dai-cells = <0>; + compatible = "wlf,wm8978"; + reg = <0>; + }; + }; + +...
Signature · 1 line
2.31.1
Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding
Quoted 12 lines · Maxime Ripard
Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Cc Liam Girdwood <[email protected]>Cc Mark Brown <[email protected]>Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Quoted 1 line
---
Thanks,
Charles
Mark Brown
maintainerRe: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding
In reply to Maxime RipardQuoted 3 lines · Maxime Ripard
Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
What's the story with dependencies here? I don't have a cover letter or anything and there seem to be a bunch of tangentially related patches in a series here.
Re: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding
Hi Mark,
Quoted 8 lines · Mark Brown
Quoted 3 lines · Maxime Ripard
Even though we had the wm8978 driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
What's the story with dependencies here? I don't have a cover letter or anything and there seem to be a bunch of tangentially related patches in a series here.
There's no dependency, you can pick the ASoC patches safely
Maxime
Mark Brown
maintainerRe: [PATCH v2 01/52] ASoC: dt-bindings: Add WM8978 Binding
Quoted 7 lines · Maxime Ripard
Quoted 3 lines · Mark Brown
What's the story with dependencies here? I don't have a cover letter or anything and there seem to be a bunch of tangentially related patches in a series here.
There's no dependency, you can pick the ASoC patches safely
Oh, OK. In cases like this it's generally better to not combine random unrelated stuff into one series - as well as making it look like there are dependencies it can also cause problems for tooling (eg, b4 is going to want to fetch the whole series and my personal tooling doesn't like the same series going to more than one of the subsystems I maintain.
PATCH v2 2/52 ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema
In reply to Maxime RipardBluetooth SCO Link are supported by Linux with a matching device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Accept either a 0 or 1 #sound-dai-cells
--- .../devicetree/bindings/sound/bt-sco.txt | 13 ------- .../bindings/sound/linux,bt-sco.yaml | 38 +++++++++++++++++++ 2 files changed, 38 insertions(+), 13 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
Documentation/devicetree/bindings/sound/bt-sco.txt deleted +0 -13
@@ -1,13 +0,0 @@ -Bluetooth-SCO audio CODEC - -This device support generic Bluetooth SCO link. - -Required properties: - - - compatible : "delta,dfbmcs320" or "linux,bt-sco" - -Example: - -codec: bt_sco { - compatible = "delta,dfbmcs320"; -};
Documentation/devicetree/bindings/sound/linux,bt-sco.yaml new file +38 -0
@@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/linux,bt-sco.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bluetooth SCO Audio Codec Device Tree Bindings + +maintainers: + - Mark Brown <[email protected]> + +properties: + '#sound-dai-cells': + enum: + - 0 + + # For Wideband PCM + - 1 + + compatible: + enum: + - delta,dfbmcs320 + - linux,bt-sco + +required: + - '#sound-dai-cells' + - compatible + +additionalProperties: false + +examples: + - | + codec { + #sound-dai-cells = <0>; + compatible = "linux,bt-sco"; + }; + +...
Signature · 1 line
2.31.1
Re: [PATCH v2 02/52] ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema
Quoted 15 lines · Maxime Ripard
Bluetooth SCO Link are supported by Linux with a matching device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Liam Girdwood <[email protected]>Cc Mark Brown <[email protected]>Cc Samuel Holland <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Quoted 9 lines
Changes from v1:
- Accept either a 0 or 1 #sound-dai-cells--- .../devicetree/bindings/sound/bt-sco.txt | 13 ------- .../bindings/sound/linux,bt-sco.yaml | 38 +++++++++++++++++++ 2 files changed, 38 insertions(+), 13 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
PATCH v2 3/52 ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema
In reply to Maxime RipardThe SPDIF Transmitter binding is used by Linux with a matching Device Tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
--- .../bindings/sound/linux,spdif-dit.yaml | 32 +++++++++++++++++++ .../bindings/sound/spdif-transmitter.txt | 10 ------ 2 files changed, 32 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml delete mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt
Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml new file +32 -0
@@ -0,0 +1,32 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/linux,spdif-dit.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dummy SPDIF Transmitter Device Tree Bindings + +maintainers: + - Mark Brown <[email protected]> + +properties: + compatible: + const: linux,spdif-dit + + "#sound-dai-cells": + const: 0 + +required: + - "#sound-dai-cells" + - compatible + +additionalProperties: false + +examples: + - | + spdif-out { + #sound-dai-cells = <0>; + compatible = "linux,spdif-dit"; + }; + +...
Documentation/devicetree/bindings/sound/spdif-transmitter.txt deleted +0 -10
@@ -1,10 +0,0 @@ -Device-Tree bindings for dummy spdif transmitter - -Required properties: - - compatible: should be "linux,spdif-dit". - -Example node: - - codec: spdif-transmitter { - compatible = "linux,spdif-dit"; - };
Signature · 1 line
2.31.1
PATCH v2 4/52 ASoC: dt-bindings: Convert Simple Amplifier binding to a schema
In reply to Maxime RipardSimple audio amplifiers are supported by Linux with a matching device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
--- .../bindings/sound/simple-amplifier.txt | 17 ------- .../sound/simple-audio-amplifier.yaml | 45 +++++++++++++++++++ 2 files changed, 45 insertions(+), 17 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt create mode 100644 Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
Documentation/devicetree/bindings/sound/simple-amplifier.txt deleted +0 -17
@@ -1,17 +0,0 @@ -Simple Amplifier Audio Driver - -Required properties: -- compatible : "dioo,dio2125" or "simple-audio-amplifier" - -Optional properties: -- enable-gpios : the gpio connected to the enable pin of the simple amplifier -- VCC-supply : power supply for the device, as covered - in Documentation/devicetree/bindings/regulator/regulator.txt - -Example: - -amp: analog-amplifier { - compatible = "simple-audio-amplifier"; - VCC-supply = <®ulator>; - enable-gpios = <&gpio GPIOH_3 0>; -};
Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml new file +45 -0
45 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v2 6/52 dt-bindings: arm: Convert ARM CCI-400 binding to a schema
In reply to Maxime RipardThe ARM CCI-400 Interconnect is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Reduced the max number of interrupts
- Comented the pl330 compatible to avoid a warning
- Added cci-control-port to the cpus schemas
--- .../devicetree/bindings/arm/arm,cci-400.yaml | 216 +++++++++++++++++ .../bindings/arm/cci-control-port.yaml | 38 +++ Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------ .../devicetree/bindings/arm/cpus.yaml | 2 + 4 files changed, 256 insertions(+), 224 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
Documentation/devicetree/bindings/arm/arm,cci-400.yaml new file +216 -0
@@ -0,0 +1,216 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/arm,cci-400.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM CCI Cache Coherent Interconnect Device Tree Binding + +maintainers: + - Lorenzo Pieralisi <[email protected]> + +description: > + ARM multi-cluster systems maintain intra-cluster coherency through a cache + coherent interconnect (CCI) that is capable of monitoring bus transactions + and manage coherency, TLB invalidations and memory barriers. + + It allows snooping and distributed virtual memory message broadcast across + clusters, through memory mapped interface, with a global control register + space and multiple sets of interface control registers, one per slave + interface. + +properties: + $nodename: + pattern: "^cci(@[0-9a-f]+)?$" + + compatible: + enum: + - arm,cci-400 + - arm,cci-500 + - arm,cci-550 + + reg: + maxItems: 1 + description: > + Specifies base physical address of CCI control registers common to all + interfaces. + + "#address-cells": true + "#size-cells": true + ranges: true + +patternProperties: + "^slave-if@[0-9a-f]+$": + type: object + + properties: + compatible: + const: arm,cci-400-ctrl-if + + interface-type: + enum: + - ace + - ace-lite + + reg: + maxItems: 1 + + required: + - compatible + - interface-type + - reg + + additionalProperties: false + + "^pmu@[0-9a-f]+$": + type: object + + properties: + compatible: + oneOf: + - const: arm,cci-400-pmu,r0 + - const: arm,cci-400-pmu,r1 + - const: arm,cci-400-pmu + deprecated: true + description: > + Permitted only where OS has secure access to CCI registers + - const: arm,cci-500-pmu,r0 + - const: arm,cci-550-pmu,r0 + + interrupts: + minItems: 1 + maxItems: 8 + description: > + List of counter overflow interrupts, one per counter. The interrupts + must be specified starting with the cycle counter overflow interrupt, + followed by counter0 overflow interrupt, counter1 overflow + interrupt,... ,counterN overflow interrupt. + + The CCI PMU has an interrupt signal for each counter. The number of + interrupts must be equal to the number of counters. + + reg: + maxItems: 1 + + required: + - compatible + - interrupts + - reg + + additionalProperties: false + +required: + - "#address-cells" + - "#size-cells" + - compatible + - ranges + - reg + +additionalProperties: false + +examples: + - | + / { + #address-cells = <2>; + #size-cells = <2>; + + compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress"; + model = "V2P-CA15_CA7"; + arm,hbi = <0x249>; + interrupt-parent = <&gic>; + + /* + * This CCI node corresponds to a CCI component whose control + * registers sits at address 0x000000002c090000. + * + * CCI slave interface @0x000000002c091000 is connected to dma + * controller dma0. + * + * CCI slave interface @0x000000002c094000 is connected to CPUs + * {CPU0, CPU1}; + * + * CCI slave interface @0x000000002c095000 is connected to CPUs + * {CPU2, CPU3}; + */ + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + cci-control-port = <&cci_control1>; + reg = <0x0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + cci-control-port = <&cci_control1>; + reg = <0x1>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + cci-control-port = <&cci_control2>; + reg = <0x100>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + cci-control-port = <&cci_control2>; + reg = <0x101>; + }; + }; + + dma0: dma@3000000 { + /* compatible = "arm,pl330", "arm,primecell"; */ + cci-control-port = <&cci_control0>; + reg = <0x0 0x3000000 0x0 0x1000>; + interrupts = <10>; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + }; + + cci@2c090000 { + compatible = "arm,cci-400"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x0 0x2c090000 0 0x1000>; + ranges = <0x0 0x0 0x2c090000 0x10000>; + + cci_control0: slave-if@1000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace-lite"; + reg = <0x1000 0x1000>; + }; + + cci_control1: slave-if@4000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x4000 0x1000>; + }; + + cci_control2: slave-if@5000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x5000 0x1000>; + }; + + pmu@9000 { + compatible = "arm,cci-400-pmu"; + reg = <0x9000 0x5000>; + interrupts = <0 101 4>, + <0 102 4>, + <0 103 4>, + <0 104 4>, + <0 105 4>; + }; + }; + }; + +...
Documentation/devicetree/bindings/arm/cci-control-port.yaml new file +38 -0
@@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/cci-control-port.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CCI Interconnect Bus Masters binding + +maintainers: + - Lorenzo Pieralisi <[email protected]> + +description: | + Masters in the device tree connected to a CCI port (inclusive of CPUs + and their cpu nodes). + +select: true + +properties: + cci-control-port: + $ref: /schemas/types.yaml#/definitions/phandle + +additionalProperties: true + +examples: + - | + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu@0 { + compatible = "arm,cortex-a15"; + device_type = "cpu"; + cci-control-port = <&cci_control1>; + reg = <0>; + }; + }; + +...
Documentation/devicetree/bindings/arm/cci.txt deleted +0 -224
224 lines not on this page · raw message
Documentation/devicetree/bindings/arm/cpus.yaml +2 -0
@@ -240,6 +240,8 @@ properties: DMIPS/MHz, relative to highest capacity-dmips-mhz in the system. + cci-control-port: true + dynamic-power-coefficient: $ref: '/schemas/types.yaml#/definitions/uint32' description:
Signature · 1 line
2.31.1
Re: [PATCH v2 06/52] dt-bindings: arm: Convert ARM CCI-400 binding to a schema
Quoted 15 lines · Maxime Ripard
The ARM CCI-400 Interconnect is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Lorenzo Pieralisi <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Reduced the max number of interrupts
- Comented the pl330 compatible to avoid a warning
- Added cci-control-port to the cpus schemas
Quoted 10 lines
--- .../devicetree/bindings/arm/arm,cci-400.yaml | 216 +++++++++++++++++ .../bindings/arm/cci-control-port.yaml | 38 +++ Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------ .../devicetree/bindings/arm/cpus.yaml | 2 + 4 files changed, 256 insertions(+), 224 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
Applied, thanks!
PATCH v2 7/52 dt-bindings: bluetooth: broadcom: Fix clocks check
In reply to Maxime RipardThe original binding was mentioning that valid values for the clocks and clock-names property were one or two clocks from extclk, txco and lpo, with extclk being deprecated in favor of txco.
However, the current binding lists a valid array as extclk, txco and lpo, with either one or two items.
While this looks similar, it actually enforces that all the device trees use either ["extclk"], or ["extclk", "txco"]. That doesn't make much sense, since the two clocks are said to be equivalent, with one superseeding the other.
lpo is also not a valid clock anymore, and would be as the third clock of the list, while we could have only this clock in the previous binding (and in DTs).
Let's rework the clock clause to allow to have either:
- extclk, and mark it a deprecated
- txco alone
- lpo alone
- txco, lpo
While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device tree so it's not an issue in practice.
Similarly, ["lpo", "txco"] is still considered invalid, but it's generally considered as a best practice to fix the order of clocks.
--- .../bindings/net/broadcom-bluetooth.yaml | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml +15 -2
@@ -50,16 +50,29 @@ properties: by interrupts and "host-wakeup" interrupt-names clocks: + minItems: 1 maxItems: 2 description: 1 or 2 clocks as defined in clock-names below, in that order clock-names: description: Names of the 1 to 2 supplied clocks - items: + oneOf: + - const: extclk + deprecated: true + description: Deprecated in favor of txco + - const: txco + description: > + external reference clock (not a standalone crystal) + - const: lpo - - const: extclk + description: > + external low power 32.768 kHz clock + + - items: + - const: txco + - const: lpo vbat-supply: description: phandle to regulator supply for VBAT
Signature · 1 line
2.31.1
Re: [PATCH v2 07/52] dt-bindings: bluetooth: broadcom: Fix clocks check
Quoted 29 lines · Maxime Ripard
The original binding was mentioning that valid values for the clocks and clock-names property were one or two clocks from extclk, txco and lpo, with extclk being deprecated in favor of txco.
However, the current binding lists a valid array as extclk, txco and lpo, with either one or two items.
While this looks similar, it actually enforces that all the device trees use either ["extclk"], or ["extclk", "txco"]. That doesn't make much sense, since the two clocks are said to be equivalent, with one superseeding the other.
lpo is also not a valid clock anymore, and would be as the third clock of the list, while we could have only this clock in the previous binding (and in DTs).
Let's rework the clock clause to allow to have either:
- extclk, and mark it a deprecated
- txco alone
- lpo alone
- txco, lpoWhile ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device tree so it's not an issue in practice.
Similarly, ["lpo", "txco"] is still considered invalid, but it's generally considered as a best practice to fix the order of clocks.
Quoted 6 lines
Cc "David S. Miller" <[email protected]>Cc Jakub Kicinski <[email protected]>Cc Linus Walleij <[email protected]>Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Looks good to me!
Yours,
Linus Walleij
PATCH v2 8/52 dt-bindings: bluetooth: realtek: Add missing max-speed
In reply to Maxime RipardadditionalProperties prevent any property not explicitly defined in the binding to be used. Yet, some serial properties like max-speed are valid and validated through the serial/serial.yaml binding.
Even though the ideal solution would be to use unevaluatedProperties instead, it's not pratical due to the way the bus bindings have been described. Let's add max-speed to remove the warning.
--- Documentation/devicetree/bindings/net/realtek-bluetooth.yaml | 2 ++ 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/net/realtek-bluetooth.yaml +2 -0
@@ -34,6 +34,8 @@ properties: maxItems: 1 description: GPIO specifier, used to wakeup the host processor + max-speed: true + required: - compatible
Signature · 1 line
2.31.1
PATCH v2 9/52 dt-bindings: clocks: Fix typo in the H6 compatible
In reply to Maxime RipardEven though both the driver and the device trees all use the allwinner,sun50i-h6-de3-clk, we documented the compatible as allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.
--- .../devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml +1 -1
@@ -24,7 +24,7 @@ properties: - const: allwinner,sun8i-v3s-de2-clk - const: allwinner,sun50i-a64-de2-clk - const: allwinner,sun50i-h5-de2-clk - - const: allwinner,sun50i-h6-de2-clk + - const: allwinner,sun50i-h6-de3-clk - items: - const: allwinner,sun8i-r40-de2-clk - const: allwinner,sun8i-h3-de2-clk
Signature · 1 line
2.31.1
Re: [PATCH v2 09/52] dt-bindings: clocks: Fix typo in the H6 compatible
Dne sreda, 01. september 2021 ob 11:18:09 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
Even though both the driver and the device trees all use the allwinner,sun50i-h6-de3-clk, we documented the compatible as allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 09/52] dt-bindings: clocks: Fix typo in the H6 compatible
Quoted 9 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:09 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
Even though both the driver and the device trees all use the allwinner,sun50i-h6-de3-clk, we documented the compatible as allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 10/52 dt-bindings: display: Move idk-1110wr to panel-lvds
In reply to Maxime RipardThe Advantech IDK-2121WR Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
--- .../display/panel/advantech,idk-1110wr.yaml | 69 ------------------- .../bindings/display/panel/lvds.yaml | 22 ++++-- 2 files changed, 15 insertions(+), 76 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml
Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml deleted +0 -69
@@ -1,69 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/advantech,idk-1110wr.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Advantech IDK-1110WR 10.1" WSVGA LVDS Display Panel - -maintainers: - - Lad Prabhakar <[email protected]> - - Thierry Reding <[email protected]> - -allOf: - - $ref: lvds.yaml# - -properties: - compatible: - items: - - const: advantech,idk-1110wr - - {} # panel-lvds, but not listed here to avoid false select - - data-mapping: - const: jeida-24 - - width-mm: - const: 223 - - height-mm: - const: 125 - - panel-timing: true - port: true - -additionalProperties: false - -required: - - compatible - -examples: - - |+ - panel { - compatible = "advantech,idk-1110wr", "panel-lvds"; - - width-mm = <223>; - height-mm = <125>; - - data-mapping = "jeida-24"; - - panel-timing { - /* 1024x600 @60Hz */ - clock-frequency = <51200000>; - hactive = <1024>; - vactive = <600>; - hsync-len = <240>; - hfront-porch = <40>; - hback-porch = <40>; - vsync-len = <10>; - vfront-porch = <15>; - vback-porch = <10>; - }; - - port { - panel_in: endpoint { - remote-endpoint = <&lvds_encoder>; - }; - }; - }; - -...
Documentation/devicetree/bindings/display/panel/lvds.yaml +15 -7
@@ -28,15 +28,23 @@ description: |+ allOf: - $ref: panel-common.yaml# + - if: + properties: + compatible: + contains: + const: advantech,idk-1110wr + + then: + properties: + data-mapping: + const: jeida-24 properties: compatible: - contains: - const: panel-lvds - description: - Shall contain "panel-lvds" in addition to a mandatory panel-specific - compatible string defined in individual panel bindings. The "panel-lvds" - value shall never be used on its own. + items: + - enum: + - advantech,idk-1110wr + - const: panel-lvds data-mapping: enum:
@@ -112,6 +120,6 @@ oneOf: - required: - ports -additionalProperties: true +unevaluatedProperties: false ...
Signature · 1 line
2.31.1
Rob Herring
maintainerRe: [PATCH v2 10/52] dt-bindings: display: Move idk-1110wr to panel-lvds
Quoted 5 lines · Maxime Ripard
The Advantech IDK-2121WR Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
I'm concerned this change means we can only have LVDS panel schemas in lvds.yaml. Having another LVDS panel schema means 2 things. First, they can't have a 'panel-lvds' compatible. That's probably fine. Second, they will still need to define 'data-mapping' (unless implied) and will need to include it from somewhere. So we still need a common LVDS properties schema and panel schema(s).
Rob
PATCH v2 11/52 dt-bindings: display: Move idk-2121wr to panel-lvds
In reply to Maxime RipardThe Advantech IDK-2121WR Device Tree binding uses most of the panel-lvds binding, aside from a requirement on the data-mapping and the definition of the dual link binding.
The LVDS dual link binding applies to any panel with a dual-link setup, and thus could be made generic, and we can move the data-mapping requirement to a conditional.
Let's move it to the generic panel-lvds binding
--- .../display/panel/advantech,idk-2121wr.yaml | 121 ------------------ .../bindings/display/panel/lvds.yaml | 88 ++++++++++++- 2 files changed, 87 insertions(+), 122 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml
Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml deleted +0 -121
@@ -1,121 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/advantech,idk-2121wr.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Advantech IDK-2121WR 21.5" Full-HD dual-LVDS panel - -maintainers: - - Lad Prabhakar <[email protected]> - - Thierry Reding <[email protected]> - -description: | - The IDK-2121WR from Advantech is a Full-HD dual-LVDS panel. - A dual-LVDS interface is a dual-link connection with even pixels traveling - on one link, and with odd pixels traveling on the other link. - - The panel expects odd pixels on the first port, and even pixels on the - second port, therefore the ports must be marked accordingly (with either - dual-lvds-odd-pixels or dual-lvds-even-pixels). - -properties: - compatible: - items: - - const: advantech,idk-2121wr - - {} # panel-lvds, but not listed here to avoid false select - - width-mm: - const: 476 - - height-mm: - const: 268 - - data-mapping: - const: vesa-24 - - panel-timing: true - - ports: - $ref: /schemas/graph.yaml#/properties/ports - - properties: - port@0: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: The sink for odd pixels. - properties: - dual-lvds-odd-pixels: true - - required: - - dual-lvds-odd-pixels - - port@1: - $ref: /schemas/graph.yaml#/$defs/port-base - unevaluatedProperties: false - description: The sink for even pixels. - properties: - dual-lvds-even-pixels: true - - required: - - dual-lvds-even-pixels - - required: - - port@0 - - port@1 - -additionalProperties: false - -required: - - compatible - - width-mm - - height-mm - - data-mapping - - panel-timing - - ports - -examples: - - |+ - panel-lvds { - compatible = "advantech,idk-2121wr", "panel-lvds"; - - width-mm = <476>; - height-mm = <268>; - - data-mapping = "vesa-24"; - - panel-timing { - clock-frequency = <148500000>; - hactive = <1920>; - vactive = <1080>; - hsync-len = <44>; - hfront-porch = <88>; - hback-porch = <148>; - vfront-porch = <4>; - vback-porch = <36>; - vsync-len = <5>; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dual-lvds-odd-pixels; - panel_in0: endpoint { - remote-endpoint = <&lvds0_out>; - }; - }; - - port@1 { - reg = <1>; - dual-lvds-even-pixels; - panel_in1: endpoint { - remote-endpoint = <&lvds1_out>; - }; - }; - }; - }; - -...
Documentation/devicetree/bindings/display/panel/lvds.yaml +87 -1
109 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v2 12/52 dt-bindings: display: Move ee101ia-01d to panel-lvds
In reply to Maxime RipardThe Innolux EE101IA-01D Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding. Let's move it to the generic panel-lvds binding
--- .../display/panel/innolux,ee101ia-01d.yaml | 31 ------------------- .../bindings/display/panel/lvds.yaml | 1 + 2 files changed, 1 insertion(+), 31 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml deleted +0 -31
@@ -1,31 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/innolux,ee101ia-01d.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Innolux Corporation 10.1" EE101IA-01D WXGA (1280x800) LVDS panel - -maintainers: - - Heiko Stuebner <[email protected]> - - Thierry Reding <[email protected]> - -allOf: - - $ref: lvds.yaml# - -properties: - compatible: - items: - - const: innolux,ee101ia-01d - - {} # panel-lvds, but not listed here to avoid false select - - backlight: true - enable-gpios: true - power-supply: true - width-mm: true - height-mm: true - panel-timing: true - port: true - -additionalProperties: false -...
Documentation/devicetree/bindings/display/panel/lvds.yaml +1 -0
@@ -59,6 +59,7 @@ properties: - enum: - advantech,idk-1110wr - advantech,idk-2121wr + - innolux,ee101ia-01d - const: panel-lvds data-mapping:
Signature · 1 line
2.31.1
PATCH v2 13/52 dt-bindings: display: aa104xd12: Remove unused vcc-supply
In reply to Maxime RipardThe Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.
--- .../bindings/display/panel/mitsubishi,aa104xd12.yaml | 5 ----- 1 file changed, 5 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +0 -5
@@ -19,9 +19,6 @@ properties: - const: mitsubishi,aa104xd12 - {} # panel-lvds, but not listed here to avoid false select - vcc-supply: - description: Reference to the regulator powering the panel VCC pins. - data-mapping: const: jeida-24
@@ -38,14 +35,12 @@ additionalProperties: false required: - compatible - - vcc-supply examples: - |+ panel { compatible = "mitsubishi,aa104xd12", "panel-lvds"; - vcc-supply = <&vcc_3v3>; width-mm = <210>; height-mm = <158>;
Signature · 1 line
2.31.1
Re: [PATCH v2 13/52] dt-bindings: display: aa104xd12: Remove unused vcc-supply
Quoted 5 lines · Maxime Ripard
The Mitsubishi AA140XD12 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.
Quoted 9 lines
Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Cc Thierry Reding <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- .../bindings/display/panel/mitsubishi,aa104xd12.yaml | 5 ----- 1 file changed, 5 deletions(-)
PATCH v2 14/52 dt-bindings: display: aa104xd12: Fix data-mapping
In reply to Maxime RipardThe Mitsubishi AA140XD12 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.
--- .../bindings/display/panel/mitsubishi,aa104xd12.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +2 -2
@@ -20,7 +20,7 @@ properties: - {} # panel-lvds, but not listed here to avoid false select data-mapping: - const: jeida-24 + const: jeida-18 width-mm: const: 210
@@ -45,7 +45,7 @@ examples: width-mm = <210>; height-mm = <158>; - data-mapping = "jeida-24"; + data-mapping = "jeida-18"; panel-timing { /* 1024x768 @65Hz */
Signature · 1 line
2.31.1
Re: [PATCH v2 14/52] dt-bindings: display: aa104xd12: Fix data-mapping
Quoted 4 lines · Maxime Ripard
The Mitsubishi AA140XD12 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.
Quoted 9 lines
Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Cc Thierry Reding <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- .../bindings/display/panel/mitsubishi,aa104xd12.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
PATCH v2 15/52 dt-bindings: display: Move aa104xd12 to panel-lvds
In reply to Maxime RipardThe Mitsubishi AA104XD12 Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
--- .../bindings/display/panel/lvds.yaml | 12 ++++ .../display/panel/mitsubishi,aa104xd12.yaml | 70 ------------------- 2 files changed, 12 insertions(+), 70 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
Documentation/devicetree/bindings/display/panel/lvds.yaml +12 -0
@@ -28,6 +28,17 @@ description: |+ allOf: - $ref: panel-common.yaml# + - if: + properties: + compatible: + contains: + const: mitsubishi,aa104xd12 + + then: + properties: + data-mapping: + const: jeida-18 + - if: properties: compatible:
@@ -60,6 +71,7 @@ properties: - advantech,idk-1110wr - advantech,idk-2121wr - innolux,ee101ia-01d + - mitsubishi,aa104xd12 - const: panel-lvds data-mapping:
Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml deleted +0 -70
70 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v2 16/52 dt-bindings: display: aa121td01: Remove unused vcc-supply
In reply to Maxime RipardThe Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.
--- .../bindings/display/panel/mitsubishi,aa121td01.yaml | 5 ----- 1 file changed, 5 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +0 -5
@@ -19,9 +19,6 @@ properties: - const: mitsubishi,aa121td01 - {} # panel-lvds, but not listed here to avoid false select - vcc-supply: - description: Reference to the regulator powering the panel VCC pins. - data-mapping: const: jeida-24
@@ -38,13 +35,11 @@ additionalProperties: false required: - compatible - - vcc-supply examples: - |+ panel { compatible = "mitsubishi,aa121td01", "panel-lvds"; - vcc-supply = <&vcc_3v3>; width-mm = <261>; height-mm = <163>;
Signature · 1 line
2.31.1
Re: [PATCH v2 16/52] dt-bindings: display: aa121td01: Remove unused vcc-supply
Quoted 5 lines · Maxime Ripard
The Mitsubishi AA121TD01 Device Tree Binding was requiring a vcc-supply property. However, neither the existing device trees using that binding, nor the driver were actually using that property which is also redundant with power-supply. Let's just drop it.
Quoted 9 lines
Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Cc Thierry Reding <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- .../bindings/display/panel/mitsubishi,aa121td01.yaml | 5 ----- 1 file changed, 5 deletions(-)
PATCH v2 17/52 dt-bindings: display: aa121td01: Fix data-mapping
In reply to Maxime RipardThe Mitsubishi AA121TD01 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.
--- .../bindings/display/panel/mitsubishi,aa121td01.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +2 -2
@@ -20,7 +20,7 @@ properties: - {} # panel-lvds, but not listed here to avoid false select data-mapping: - const: jeida-24 + const: jeida-18 width-mm: const: 261
@@ -44,7 +44,7 @@ examples: width-mm = <261>; height-mm = <163>; - data-mapping = "jeida-24"; + data-mapping = "jeida-18"; panel-timing { /* 1280x800 @60Hz */
Signature · 1 line
2.31.1
Re: [PATCH v2 17/52] dt-bindings: display: aa121td01: Fix data-mapping
Quoted 4 lines · Maxime Ripard
The Mitsubishi AA121TD01 Device Tree Binding was requiring a data-mapping property value which was set to another value in the existing Device Trees. Fix this.
Quoted 9 lines
Cc Laurent Pinchart <[email protected]>Cc Sam Ravnborg <[email protected]>Cc Thierry Reding <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- .../bindings/display/panel/mitsubishi,aa121td01.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
PATCH v2 18/52 dt-bindings: display: Move aa121td01 to panel-lvds
In reply to Maxime RipardThe Mitsubishi AA121TD01 Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
--- .../bindings/display/panel/lvds.yaml | 5 +- .../display/panel/mitsubishi,aa121td01.yaml | 69 ------------------- 2 files changed, 4 insertions(+), 70 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
Documentation/devicetree/bindings/display/panel/lvds.yaml +4 -1
@@ -32,7 +32,9 @@ allOf: properties: compatible: contains: - const: mitsubishi,aa104xd12 + enum: + - mitsubishi,aa104xd12 + - mitsubishi,aa121td01 then: properties:
@@ -72,6 +74,7 @@ properties: - advantech,idk-2121wr - innolux,ee101ia-01d - mitsubishi,aa104xd12 + - mitsubishi,aa121td01 - const: panel-lvds data-mapping:
Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml deleted +0 -69
69 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v2 19/52 dt-bindings: display: Move gktw70sdae4se to panel-lvds
In reply to Maxime RipardThe Solomon Goldentek Display GKTW70SDAE4SE Device Tree binding doesn't really add any useful content that is not already present in the panel-lvds binding aside from a requirement on the data-mapping.
Let's move it to the generic panel-lvds binding
--- .../bindings/display/panel/lvds.yaml | 2 + .../display/panel/sgd,gktw70sdae4se.yaml | 68 ------------------- 2 files changed, 2 insertions(+), 68 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
Documentation/devicetree/bindings/display/panel/lvds.yaml +2 -0
@@ -35,6 +35,7 @@ allOf: enum: - mitsubishi,aa104xd12 - mitsubishi,aa121td01 + - sgd,gktw70sdae4se then: properties:
@@ -75,6 +76,7 @@ properties: - innolux,ee101ia-01d - mitsubishi,aa104xd12 - mitsubishi,aa121td01 + - sgd,gktw70sdae4se - const: panel-lvds data-mapping:
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml deleted +0 -68
68 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v2 20/52 dt-bindings: display: panel-lvds: Document missing panel compatibles
In reply to Maxime RipardA few panel-lvds compatibles were never documented. Let's add them.
--- Documentation/devicetree/bindings/display/panel/lvds.yaml | 2 ++ 1 file changed, 2 insertions(+)
Documentation/devicetree/bindings/display/panel/lvds.yaml +2 -0
@@ -73,10 +73,12 @@ properties: - enum: - advantech,idk-1110wr - advantech,idk-2121wr + - auo,b101ew05 - innolux,ee101ia-01d - mitsubishi,aa104xd12 - mitsubishi,aa121td01 - sgd,gktw70sdae4se + - tbs,a711-panel - const: panel-lvds data-mapping:
Signature · 1 line
2.31.1
PATCH v2 21/52 dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema
In reply to Maxime RipardThe UBlox Neo 6M is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Fixed a typo
- Fixed the example node name
--- .../bindings/gnss/u-blox,neo-6m.yaml | 62 +++++++++++++++++++ .../devicetree/bindings/gnss/u-blox.txt | 45 -------------- 2 files changed, 62 insertions(+), 45 deletions(-) create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml new file +62 -0
@@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-blox GNSS Receiver Device Tree Bindings + +maintainers: + - Johan Hovold <[email protected]> + +description: > + The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces. + +properties: + compatible: + enum: + - u-blox,neo-6m + - u-blox,neo-8 + - u-blox,neo-m8 + + reg: + description: > + The DDC Slave Address, SPI chip select address, the number of the USB hub + port or the USB host-controller port to which this device is attached, + depending on the bus used. Required for the DDC, SPI or USB busses. + + vcc-supply: + description: > + Main voltage regulator + + timepulse-gpios: + maxItems: 1 + description: > + Time pulse GPIO + + u-blox,extint-gpios: + maxItems: 1 + description: > + GPIO connected to the "external interrupt" input pin + + v-bckp-supply: + description: > + Backup voltage regulator + + current-speed: true + +required: + - compatible + - vcc-supply + +additionalProperties: false + +examples: + - | + serial { + gnss { + compatible = "u-blox,neo-8"; + v-bckp-supply = <&gnss_v_bckp_reg>; + vcc-supply = <&gnss_vcc_reg>; + }; + };
Documentation/devicetree/bindings/gnss/u-blox.txt deleted +0 -45
45 lines not on this page · raw message
Signature · 1 line
2.31.1
Re: [PATCH v2 21/52] dt-bindings: gnss: Convert UBlox Neo-6M binding to a schema
Quoted 14 lines · Maxime Ripard
The UBlox Neo 6M is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Johan Hovold <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Fixed a typo
- Fixed the example node name
Quoted 7 lines
--- .../bindings/gnss/u-blox,neo-6m.yaml | 62 +++++++++++++++++++ .../devicetree/bindings/gnss/u-blox.txt | 45 -------------- 2 files changed, 62 insertions(+), 45 deletions(-) create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
Applied, thanks!
PATCH v2 22/52 dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema
In reply to Maxime RipardThe X-Powers AXP PMICs feature a GPIO Controller supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Removed the example and moved it in the mfd schema
--- .../devicetree/bindings/gpio/gpio-axp209.txt | 75 ------------------- .../bindings/gpio/x-powers,axp209-gpio.yaml | 55 ++++++++++++++ 2 files changed, 55 insertions(+), 75 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
Documentation/devicetree/bindings/gpio/gpio-axp209.txt deleted +0 -75
@@ -1,75 +0,0 @@ -AXP209 GPIO & pinctrl controller - -This driver follows the usual GPIO bindings found in -Documentation/devicetree/bindings/gpio/gpio.txt - -This driver follows the usual pinctrl bindings found in -Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -This driver employs the per-pin muxing pattern. - -Required properties: -- compatible: Should be one of: - - "x-powers,axp209-gpio" - - "x-powers,axp813-gpio" -- #gpio-cells: Should be two. The first cell is the pin number and the - second is the GPIO flags. -- gpio-controller: Marks the device node as a GPIO controller. - -This node must be a subnode of the axp20x PMIC, documented in -Documentation/devicetree/bindings/mfd/axp20x.txt - -Example: - -axp209: pmic@34 { - compatible = "x-powers,axp209"; - reg = <0x34>; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <1>; - - axp_gpio: gpio { - compatible = "x-powers,axp209-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; -}; - -The GPIOs can be muxed to other functions and therefore, must be a subnode of -axp_gpio. - -Example: - -&axp_gpio { - gpio0_adc: gpio0-adc { - pins = "GPIO0"; - function = "adc"; - }; -}; - -&example_node { - pinctrl-names = "default"; - pinctrl-0 = <&gpio0_adc>; -}; - -GPIOs and their functions -------------------------- - -Each GPIO is independent from the other (i.e. GPIO0 in gpio_in function does -not force GPIO1 and GPIO2 to be in gpio_in function as well). - -axp209 ------- -GPIO | Functions ------------------------- -GPIO0 | gpio_in, gpio_out, ldo, adc -GPIO1 | gpio_in, gpio_out, ldo, adc -GPIO2 | gpio_in, gpio_out - -axp813 ------- -GPIO | Functions ------------------------- -GPIO0 | gpio_in, gpio_out, ldo, adc -GPIO1 | gpio_in, gpio_out, ldo
Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml new file +55 -0
55 lines not on this page · raw message
Signature · 1 line
2.31.1
Re: [PATCH v2 22/52] dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema
Quoted 14 lines · Maxime Ripard
The X-Powers AXP PMICs feature a GPIO Controller supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Bartosz Golaszewski <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Linus Walleij <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Quoted 9 lines
Changes from v1:
- Removed the example and moved it in the mfd schema--- .../devicetree/bindings/gpio/gpio-axp209.txt | 75 ------------------- .../bindings/gpio/x-powers,axp209-gpio.yaml | 55 ++++++++++++++ 2 files changed, 55 insertions(+), 75 deletions(-) delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
This needs to be applied with the MFD schema.
Re: [PATCH v2 22/52] dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema
In reply to Maxime RipardQuoted 7 lines · Maxime Ripard
The X-Powers AXP PMICs feature a GPIO Controller supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Quoted 8 lines
Cc Bartosz Golaszewski <[email protected]>Cc Chen-Yu Tsai <[email protected]>Cc Linus Walleij <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
PATCH v2 23/52 dt-bindings: hwmon: Add IIO HWMON binding
In reply to Maxime RipardEven though we had the iio-hwmon driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
---
Changes from v1:
- Reduced the maximum number of io-channels, and added a comment for the limitation
--- .../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml new file +37 -0
@@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ADC-attached Hardware Sensor Device Tree Bindings + +maintainers: + - Jonathan Cameron <[email protected]> + +description: > + Bindings for hardware monitoring devices connected to ADC controllers + supporting the Industrial I/O bindings. + +properties: + compatible: + const: iio-hwmon + + io-channels: + minItems: 1 + maxItems: 8 # Should be enough + description: > + List of phandles to ADC channels to read the monitoring values + +required: + - compatible + - io-channels + +additionalProperties: false + +examples: + - | + iio-hwmon { + compatible = "iio-hwmon"; + io-channels = <&adc 1>, <&adc 2>; + };
Signature · 1 line
2.31.1
Re: [PATCH v2 23/52] dt-bindings: hwmon: Add IIO HWMON binding
Quoted 12 lines · Maxime Ripard
Even though we had the iio-hwmon driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Cc Guenter Roeck <[email protected]>Cc Jean Delvare <[email protected]>Cc Jonathan Cameron <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Quoted 8 lines
Changes from v1:
- Reduced the maximum number of io-channels, and added a comment for the limitation--- .../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
Guenter Roeck
maintainerRe: [PATCH v2 23/52] dt-bindings: hwmon: Add IIO HWMON binding
In reply to Maxime RipardQuoted 10 lines · Maxime Ripard
Even though we had the iio-hwmon driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Cc Guenter Roeck <[email protected]>Cc Jean Delvare <[email protected]>Cc Jonathan Cameron <[email protected]>Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Rob Herring <[email protected]>
Applied (assuming this is supposed to be pushed through hwmon).
Thanks,
Guenter
PATCH v2 24/52 dt-bindings: input: Convert Silead GSL1680 binding to a schema
In reply to Maxime RipardThe Silead GSL1680 Touchscreen Controller is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Added maximum to the number of fingers
--- .../input/touchscreen/silead,gsl1680.yaml | 91 +++++++++++++++++++ .../input/touchscreen/silead_gsl1680.txt | 44 --------- 2 files changed, 91 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +91 -0
@@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silead GSL1680 Touchscreen Controller Device Tree Bindings + +maintainers: + - Dmitry Torokhov <[email protected]> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - silead,gsl1680 + - silead,gsl1688 + - silead,gsl3670 + - silead,gsl3675 + - silead,gsl3692 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-gpios: + maxItems: 1 + + firmware: + $ref: /schemas/types.yaml#/definitions/string + description: > + File basename for board specific firmware + + silead,max-fingers: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 5 + description: > + Maximum number of fingers the touchscreen can detect + + silead,home-button: + type: boolean + description: > + Does the device have a capacitive home-button build into the + touchscreen? + + avdd-supply: + description: > + Regulator phandle for controller AVDD + + vddio-supply: + description: > + Regulator phandle for controller VDDIO + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - power-gpios + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@40 { + compatible = "silead,gsl1680"; + reg = <0x40>; + interrupt-parent = <&pio>; + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; + touchscreen-size-x = <480>; + touchscreen-size-y = <800>; + touchscreen-inverted-x; + touchscreen-swapped-x-y; + silead,max-fingers = <5>; + }; + }; + +...
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt deleted +0 -44
44 lines not on this page · raw message
Signature · 1 line
2.31.1
Rob Herring
maintainerRe: [PATCH v2 24/52] dt-bindings: input: Convert Silead GSL1680 binding to a schema
Quoted 50 lines · Maxime Ripard
The Silead GSL1680 Touchscreen Controller is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Dmitry Torokhov <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Added maximum to the number of fingers--- .../input/touchscreen/silead,gsl1680.yaml | 91 +++++++++++++++++++ .../input/touchscreen/silead_gsl1680.txt | 44 --------- 2 files changed, 91 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txtDocumentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +23
-0@@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/silead,gsl1680.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silead GSL1680 Touchscreen Controller Device Tree Bindings + +maintainers: + - Dmitry Torokhov <[email protected]> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - silead,gsl1680 + - silead,gsl1688 + - silead,gsl3670 + - silead,gsl3675 + - silead,gsl3692 +
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml line 33
Quoted 10 lines
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +10
-0+ reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-gpios: + maxItems: 1 + + firmware:
Should be 'firmware-name'
Quoted 112 lines
Documentation/devicetree/bindings/input/touchscreen/silead,gsl1680.yaml new file +58
-0+ $ref: /schemas/types.yaml#/definitions/string + description: > + File basename for board specific firmware + + silead,max-fingers: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 5 + description: > + Maximum number of fingers the touchscreen can detect + + silead,home-button: + type: boolean + description: > + Does the device have a capacitive home-button build into the + touchscreen? + + avdd-supply: + description: > + Regulator phandle for controller AVDD + + vddio-supply: + description: > + Regulator phandle for controller VDDIO + +unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - power-gpios + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@40 { + compatible = "silead,gsl1680"; + reg = <0x40>; + interrupt-parent = <&pio>; + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; + touchscreen-size-x = <480>; + touchscreen-size-y = <800>; + touchscreen-inverted-x; + touchscreen-swapped-x-y; + silead,max-fingers = <5>; + }; + }; + +...Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt deleted +0
-44@@ -1,44 +0,0 @@ -* GSL 1680 touchscreen controller - -Required properties: -- compatible : Must be one of the following, depending on the model: - "silead,gsl1680" - "silead,gsl1688" - "silead,gsl3670" - "silead,gsl3675" - "silead,gsl3692" -- reg : I2C slave address of the chip (0x40) -- interrupts : interrupt specification for the gsl1680 interrupt -- power-gpios : Specification for the pin connected to the gsl1680's - shutdown input. This needs to be driven high to take the - gsl1680 out of its low power state -- touchscreen-size-x : See touchscreen.txt -- touchscreen-size-y : See touchscreen.txt - -Optional properties: -- firmware-name : File basename (string) for board specific firmware -- touchscreen-inverted-x : See touchscreen.txt -- touchscreen-inverted-y : See touchscreen.txt -- touchscreen-swapped-x-y : See touchscreen.txt -- silead,max-fingers : maximum number of fingers the touchscreen can detect -- silead,home-button : Boolean, set to true on devices which have a - capacitive home-button build into the touchscreen -- vddio-supply : regulator phandle for controller VDDIO -- avdd-supply : regulator phandle for controller AVDD - -Example: - -i2c@00000000 { - gsl1680: touchscreen@40 { - compatible = "silead,gsl1680"; - reg = <0x40>; - interrupt-parent = <&pio>; - interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; - power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; - touchscreen-size-x = <480>; - touchscreen-size-y = <800>; - touchscreen-inverted-x; - touchscreen-swapped-x-y; - silead,max-fingers = <5>; - }; -};Signature · 1 line
2.31.1
PATCH v2 25/52 dt-bindings: interconnect: sunxi: Add R40 MBUS compatible
In reply to Maxime RipardThe R40 MBUS compatible was introduced recently but it was never documented.
--- .../devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml | 1 + 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml +1 -0
@@ -30,6 +30,7 @@ properties: enum: - allwinner,sun5i-a13-mbus - allwinner,sun8i-h3-mbus + - allwinner,sun8i-r40-mbus - allwinner,sun50i-a64-mbus reg:
Signature · 1 line
2.31.1
Re: [PATCH v2 25/52] dt-bindings: interconnect: sunxi: Add R40 MBUS compatible
Dne sreda, 01. september 2021 ob 11:18:25 CEST je Maxime Ripard napisal(a):
Quoted 5 lines
The R40 MBUS compatible was introduced recently but it was never documented.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: (subset) [PATCH v2 25/52] dt-bindings: interconnect: sunxi: Add R40 MBUS compatible
In reply to Maxime RipardQuoted 4 lines · Maxime Ripard
The R40 MBUS compatible was introduced recently but it was never documented.
Applied to sunxi/linux.git (sunxi/dt-for-5.16).
Thanks!
Maxime
PATCH v2 26/52 dt-bindings: media: ti,cal: Fix example
In reply to Maxime RipardThe OV5640 sensor used in the example doesn't follow the binding and omits the regulators. Add some to make the example valid.
--- Documentation/devicetree/bindings/media/ti,cal.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Documentation/devicetree/bindings/media/ti,cal.yaml +3 -1
@@ -154,7 +154,9 @@ examples: camera-sensor@3c { compatible = "ovti,ov5640"; reg = <0x3c>; - + AVDD-supply = <®_2p8v>; + DOVDD-supply = <®_1p8v>; + DVDD-supply = <®_1p5v>; clocks = <&clk_ov5640_fixed>; clock-names = "xclk";
Signature · 1 line
2.31.1
Re: [PATCH v2 26/52] dt-bindings: media: ti,cal: Fix example
Quoted 8 lines · Maxime Ripard
The OV5640 sensor used in the example doesn't follow the binding and omits the regulators. Add some to make the example valid.
Signed-off-by Maxime Ripard <[email protected]>--- Documentation/devicetree/bindings/media/ti,cal.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks!
PATCH v2 27/52 dt-bindings: media: Convert OV5640 binding to a schema
In reply to Maxime RipardThe Omnivision OV5640 is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
--- .../devicetree/bindings/media/i2c/ov5640.txt | 92 ----------- .../bindings/media/i2c/ovti,ov5640.yaml | 154 ++++++++++++++++++ 2 files changed, 154 insertions(+), 92 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml
Documentation/devicetree/bindings/media/i2c/ov5640.txt deleted +0 -92
@@ -1,92 +0,0 @@ -* Omnivision OV5640 MIPI CSI-2 / parallel sensor - -Required Properties: -- compatible: should be "ovti,ov5640" -- clocks: reference to the xclk input clock. -- clock-names: should be "xclk". -- DOVDD-supply: Digital I/O voltage supply, 1.8 volts -- AVDD-supply: Analog voltage supply, 2.8 volts -- DVDD-supply: Digital core voltage supply, 1.5 volts - -Optional Properties: -- reset-gpios: reference to the GPIO connected to the reset pin, if any. - This is an active low signal to the OV5640. -- powerdown-gpios: reference to the GPIO connected to the powerdown pin, - if any. This is an active high signal to the OV5640. -- rotation: as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt, - valid values are 0 (sensor mounted upright) and 180 (sensor - mounted upside down). - -The device node must contain one 'port' child node for its digital output -video port, in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. - -OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint. - -Endpoint node required properties for CSI-2 connection are: -- remote-endpoint: a phandle to the bus receiver's endpoint node. -- clock-lanes: should be set to <0> (clock lane on hardware lane 0) -- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported) - -Endpoint node required properties for parallel connection are: -- remote-endpoint: a phandle to the bus receiver's endpoint node. -- bus-width: shall be set to <8> for 8 bits parallel bus - or <10> for 10 bits parallel bus -- data-shift: shall be set to <2> for 8 bits parallel bus - (lines 9:2 are used) or <0> for 10 bits parallel bus -- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. -- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. -- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock - signal. - -Examples: - -&i2c1 { - ov5640: camera@3c { - compatible = "ovti,ov5640"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ov5640>; - reg = <0x3c>; - clocks = <&clks IMX6QDL_CLK_CKO>; - clock-names = "xclk"; - DOVDD-supply = <&vgen4_reg>; /* 1.8v */ - AVDD-supply = <&vgen3_reg>; /* 2.8v */ - DVDD-supply = <&vgen2_reg>; /* 1.5v */ - powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; - rotation = <180>; - - port { - /* MIPI CSI-2 bus endpoint */ - ov5640_to_mipi_csi2: endpoint { - remote-endpoint = <&mipi_csi2_from_ov5640>; - clock-lanes = <0>; - data-lanes = <1 2>; - }; - }; - }; -}; - -&i2c1 { - ov5640: camera@3c { - compatible = "ovti,ov5640"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ov5640>; - reg = <0x3c>; - clocks = <&clk_ext_camera>; - clock-names = "xclk"; - - port { - /* Parallel bus endpoint */ - ov5640_to_parallel: endpoint { - remote-endpoint = <¶llel_from_ov5640>; - bus-width = <8>; - data-shift = <2>; /* lines 9:2 are used */ - hsync-active = <0>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; - }; -};
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +154 -0
154 lines not on this page · raw message
Signature · 1 line
2.31.1
Rob Herring
maintainerRe: [PATCH v2 27/52] dt-bindings: media: Convert OV5640 binding to a schema
Quoted 165 lines · Maxime Ripard
The Omnivision OV5640 is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Mauro Carvalho Chehab <[email protected]>Cc Steve Longerbeam <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- .../devicetree/bindings/media/i2c/ov5640.txt | 92 ----------- .../bindings/media/i2c/ovti,ov5640.yaml | 154 ++++++++++++++++++ 2 files changed, 154 insertions(+), 92 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yamlDocumentation/devicetree/bindings/media/i2c/ov5640.txt deleted +0
-92@@ -1,92 +0,0 @@ -* Omnivision OV5640 MIPI CSI-2 / parallel sensor - -Required Properties: -- compatible: should be "ovti,ov5640" -- clocks: reference to the xclk input clock. -- clock-names: should be "xclk". -- DOVDD-supply: Digital I/O voltage supply, 1.8 volts -- AVDD-supply: Analog voltage supply, 2.8 volts -- DVDD-supply: Digital core voltage supply, 1.5 volts - -Optional Properties: -- reset-gpios: reference to the GPIO connected to the reset pin, if any. - This is an active low signal to the OV5640. -- powerdown-gpios: reference to the GPIO connected to the powerdown pin, - if any. This is an active high signal to the OV5640. -- rotation: as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt, - valid values are 0 (sensor mounted upright) and 180 (sensor - mounted upside down). - -The device node must contain one 'port' child node for its digital output -video port, in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. - -OV5640 can be connected to a MIPI CSI-2 bus or a parallel bus endpoint. - -Endpoint node required properties for CSI-2 connection are: -- remote-endpoint: a phandle to the bus receiver's endpoint node. -- clock-lanes: should be set to <0> (clock lane on hardware lane 0) -- data-lanes: should be set to <1> or <1 2> (one or two CSI-2 lanes supported) - -Endpoint node required properties for parallel connection are: -- remote-endpoint: a phandle to the bus receiver's endpoint node. -- bus-width: shall be set to <8> for 8 bits parallel bus - or <10> for 10 bits parallel bus -- data-shift: shall be set to <2> for 8 bits parallel bus - (lines 9:2 are used) or <0> for 10 bits parallel bus -- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH respectively. -- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH respectively. -- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock - signal. - -Examples: - -&i2c1 { - ov5640: camera@3c { - compatible = "ovti,ov5640"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ov5640>; - reg = <0x3c>; - clocks = <&clks IMX6QDL_CLK_CKO>; - clock-names = "xclk"; - DOVDD-supply = <&vgen4_reg>; /* 1.8v */ - AVDD-supply = <&vgen3_reg>; /* 2.8v */ - DVDD-supply = <&vgen2_reg>; /* 1.5v */ - powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; - rotation = <180>; - - port { - /* MIPI CSI-2 bus endpoint */ - ov5640_to_mipi_csi2: endpoint { - remote-endpoint = <&mipi_csi2_from_ov5640>; - clock-lanes = <0>; - data-lanes = <1 2>; - }; - }; - }; -}; - -&i2c1 { - ov5640: camera@3c { - compatible = "ovti,ov5640"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_ov5640>; - reg = <0x3c>; - clocks = <&clk_ext_camera>; - clock-names = "xclk"; - - port { - /* Parallel bus endpoint */ - ov5640_to_parallel: endpoint { - remote-endpoint = <¶llel_from_ov5640>; - bus-width = <8>; - data-shift = <2>; /* lines 9:2 are used */ - hsync-active = <0>; - vsync-active = <0>; - pclk-sample = <1>; - }; - }; - }; -};Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +44
-0@@ -0,0 +1,154 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov5640.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV5640 Image Sensor Device Tree Bindings + +maintainers: + - Steve Longerbeam <[email protected]> + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + +properties: + compatible: + const: ovti,ov5640 + + reg: + maxItems: 1 + + clocks: + description: XCLK Input Clock + + clock-names: + const: xclk + + AVDD-supply: + description: Analog voltage supply, 2.8 volts + + DVDD-supply: + description: Digital core voltage supply, 1.5 volts + + DOVDD-supply: + description: Digital I/O voltage supply, 1.8 volts + + powerdown-gpios: + maxItems: 1 + description: > + Reference to the GPIO connected to the powerdown pin, if any. + + reset-gpios: + maxItems: 1 + description: >
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml line 54
Quoted 10 lines
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +10
-0+ Reference to the GPIO connected to the reset pin, if any. + + rotation: + enum: + - 0 + - 180 + + port: + description: Digital Output Port + $ref: /schemas/graph.yaml#/properties/port
This needs to be /schemas/graph.yaml#/$defs/port-base
Otherwise, it will fail when we start checking unevaluatedProperties.
Quoted 104 lines
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +100
-0+ additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + const: 0 + + data-lanes: + minItems: 1 + maxItems: 2 + items: + enum: [1, 2] + + bus-width: + enum: [8, 10] + + data-shift: + enum: [0, 2] + +required: + - compatible + - reg + - clocks + - clock-names + - AVDD-supply + - DVDD-supply + - DOVDD-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx6qdl-clock.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@3c { + compatible = "ovti,ov5640"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ov5640>; + reg = <0x3c>; + clocks = <&clks IMX6QDL_CLK_CKO>; + clock-names = "xclk"; + DOVDD-supply = <&vgen4_reg>; /* 1.8v */ + AVDD-supply = <&vgen3_reg>; /* 2.8v */ + DVDD-supply = <&vgen2_reg>; /* 1.5v */ + powerdown-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; + rotation = <180>; + + port { + /* MIPI CSI-2 bus endpoint */ + ov5640_to_mipi_csi2: endpoint { + remote-endpoint = <&mipi_csi2_from_ov5640>; + clock-lanes = <0>; + data-lanes = <1 2>; + }; + }; + }; + }; + + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@3c { + compatible = "ovti,ov5640"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ov5640>; + reg = <0x3c>; + clocks = <&clk_ext_camera>; + clock-names = "xclk"; + DOVDD-supply = <&vgen4_reg>; /* 1.8v */ + AVDD-supply = <&vgen3_reg>; /* 2.8v */ + DVDD-supply = <&vgen2_reg>; /* 1.5v */ + + port { + /* Parallel bus endpoint */ + ov5640_to_parallel: endpoint { + remote-endpoint = <¶llel_from_ov5640>; + bus-width = <8>; + data-shift = <2>; /* lines 9:2 are used */ + hsync-active = <0>; + vsync-active = <0>; + pclk-sample = <1>; + }; + }; + }; + }; + +...Signature · 1 line
2.31.1
Re: [PATCH v2 27/52] dt-bindings: media: Convert OV5640 binding to a schema
In reply to Maxime RipardHi Maxime,
Quoted 10 lines · Maxime Ripard
The Omnivision OV5640 is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Mauro Carvalho Chehab <[email protected]>Cc Steve Longerbeam <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Thanks for your patch!
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml line 49
Quoted 6 lines
Documentation/devicetree/bindings/media/i2c/ovti,ov5640.yaml new file +3
-0+ rotation: + enum: + - 0
git am: warning: 1 line adds whitespace errors.
Quoted 1 line
+ - 180
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
PATCH v2 28/52 dt-bindings: mfd: Convert X-Powers AC100 binding to a schema
In reply to Maxime RipardThe X-Powers AC100 hybrid devices are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Added maximum number of clocks properties
--- .../devicetree/bindings/mfd/ac100.txt | 50 -------- .../bindings/mfd/x-powers,ac100.yaml | 116 ++++++++++++++++++ 2 files changed, 116 insertions(+), 50 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
Documentation/devicetree/bindings/mfd/ac100.txt deleted +0 -50
@@ -1,50 +0,0 @@ -X-Powers AC100 Codec/RTC IC Device Tree bindings - -AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are -separated, including power supplies and interrupt lines, but share -a common register address space and host interface. - -Required properties: -- compatible: "x-powers,ac100" -- reg: The I2C slave address or RSB hardware address for the chip -- sub-nodes: - - codec - - compatible: "x-powers,ac100-codec" - - interrupts: SoC NMI / GPIO interrupt connected to the - IRQ_AUDIO pin - - #clock-cells: Shall be 0 - - clock-output-names: "4M_adda" - - - see clock/clock-bindings.txt for common clock bindings - - - rtc - - compatible: "x-powers,ac100-rtc" - - clocks: A phandle to the codec's "4M_adda" clock - - #clock-cells: Shall be 1 - - clock-output-names: "cko1_rtc", "cko2_rtc", "cko3_rtc" - - - see clock/clock-bindings.txt for common clock bindings - -Example: - -ac100: codec@e89 { - compatible = "x-powers,ac100"; - reg = <0xe89>; - - ac100_codec: codec { - compatible = "x-powers,ac100-codec"; - interrupt-parent = <&r_pio>; - interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */ - #clock-cells = <0>; - clock-output-names = "4M_adda"; - }; - - ac100_rtc: rtc { - compatible = "x-powers,ac100-rtc"; - interrupt-parent = <&nmi_intc>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - clocks = <&ac100_codec>; - #clock-cells = <1>; - clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc"; - }; -};
Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml new file +116 -0
116 lines not on this page · raw message
Signature · 1 line
2.31.1
Re: [PATCH v2 28/52] dt-bindings: mfd: Convert X-Powers AC100 binding to a schema
Quoted 12 lines · Maxime Ripard
The X-Powers AC100 hybrid devices are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Lee Jones <[email protected]>Acked-by Chen-Yu Tsai <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Quoted 9 lines
Changes from v1:
- Added maximum number of clocks properties--- .../devicetree/bindings/mfd/ac100.txt | 50 -------- .../bindings/mfd/x-powers,ac100.yaml | 116 ++++++++++++++++++ 2 files changed, 116 insertions(+), 50 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/ac100.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,ac100.yaml
PATCH v2 29/52 dt-bindings: mfd: Convert X-Powers AXP binding to a schema
In reply to Maxime RipardThe X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay
--- .../i2c/allwinner,sun6i-a31-p2wi.yaml | 2 +- .../devicetree/bindings/mfd/axp20x.txt | 273 ------------ .../bindings/mfd/x-powers,axp152.yaml | 400 ++++++++++++++++++ 3 files changed, 401 insertions(+), 274 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml +1 -1
@@ -55,7 +55,7 @@ examples: #size-cells = <0>; axp221: pmic@68 { - compatible = "x-powers,axp221"; + /* compatible = "x-powers,axp221"; */ reg = <0x68>; }; };
Documentation/devicetree/bindings/mfd/axp20x.txt deleted +0 -273
273 lines not on this page · raw message
Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml new file +400 -0
400 lines not on this page · raw message
Signature · 1 line
2.31.1
Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema
Quoted 15 lines · Maxime Ripard
The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Chen-Yu Tsai <[email protected]>Cc Lee Jones <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay
Quoted 8 lines
--- .../i2c/allwinner,sun6i-a31-p2wi.yaml | 2 +- .../devicetree/bindings/mfd/axp20x.txt | 273 ------------ .../bindings/mfd/x-powers,axp152.yaml | 400 ++++++++++++++++++ 3 files changed, 401 insertions(+), 274 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Note that the gpio child schema needs to be applied with this one.
Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema
Quoted 25 lines · Rob Herring
Quoted 15 lines · Maxime Ripard
The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Chen-Yu Tsai <[email protected]>Cc Lee Jones <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delayQuoted 8 lines
--- .../i2c/allwinner,sun6i-a31-p2wi.yaml | 2 +- .../devicetree/bindings/mfd/axp20x.txt | 273 ------------ .../bindings/mfd/x-powers,axp152.yaml | 400 ++++++++++++++++++ 3 files changed, 401 insertions(+), 274 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Quoted 3 lines
Reviewed-by Rob Herring <[email protected]>Note that the gpio child schema needs to be applied with this one.
Not sure I'm in possession of that.
Signature · 4 lines
Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema
Quoted 27 lines · Lee Jones
Quoted 25 lines · Rob Herring
Quoted 23 lines · Maxime Ripard
The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Chen-Yu Tsai <[email protected]>Cc Lee Jones <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay--- .../i2c/allwinner,sun6i-a31-p2wi.yaml | 2 +- .../devicetree/bindings/mfd/axp20x.txt | 273 ------------ .../bindings/mfd/x-powers,axp152.yaml | 400 ++++++++++++++++++ 3 files changed, 401 insertions(+), 274 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Quoted 5 lines
Quoted 3 lines
Reviewed-by Rob Herring <[email protected]>Note that the gpio child schema needs to be applied with this one.
Not sure I'm in possession of that.
So, how do you want to merge that? Through the DT tree?
Maxime
Rob Herring
maintainerRe: [PATCH v2 29/52] dt-bindings: mfd: Convert X-Powers AXP binding to a schema
Quoted 29 lines · Maxime Ripard
Quoted 27 lines · Lee Jones
Quoted 25 lines · Rob Herring
Quoted 23 lines · Maxime Ripard
The X-Powers AXP PMICs are supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Chen-Yu Tsai <[email protected]>Cc Lee Jones <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Add GPIO example
- Remove the limitation on regulator-ramp-delay--- .../i2c/allwinner,sun6i-a31-p2wi.yaml | 2 +- .../devicetree/bindings/mfd/axp20x.txt | 273 ------------ .../bindings/mfd/x-powers,axp152.yaml | 400 ++++++++++++++++++ 3 files changed, 401 insertions(+), 274 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt create mode 100644 Documentation/devicetree/bindings/mfd/x-powers,axp152.yaml
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Reviewed-by Rob Herring <[email protected]>Note that the gpio child schema needs to be applied with this one.
Not sure I'm in possession of that.
So, how do you want to merge that? Through the DT tree?
Resend the MFD and child patches in a series to Lee.
Rob
PATCH v2 30/52 dt-bindings: mmc: Convert MMC Card binding to a schema
In reply to Maxime RipardMMC Cards can have an optional Device Tree binding to add non-discoverable properties.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Some of these properties were already described in the MMC controller binding, even though they are not generic and do not apply to any device, so we took the occasion to fix this.
---
Changes from v1:
- Fixed additionalProperties
--- .../devicetree/bindings/mmc/mmc-card.txt | 30 ------------ .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++++++++++++++++++ .../bindings/mmc/mmc-controller.yaml | 6 --- 3 files changed, 48 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
Documentation/devicetree/bindings/mmc/mmc-card.txt deleted +0 -30
@@ -1,30 +0,0 @@ -mmc-card / eMMC bindings ------------------------- - -This documents describes the devicetree bindings for a mmc-host controller -child node describing a mmc-card / an eMMC, see "Use of Function subnodes" -in mmc.txt - -Required properties: --compatible : Must be "mmc-card" --reg : Must be <0> - -Optional properties: --broken-hpi : Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used - -Example: - -&mmc2 { - pinctrl-names = "default"; - pinctrl-0 = <&mmc2_pins_a>; - vmmc-supply = <®_vcc3v3>; - bus-width = <8>; - non-removable; - - mmccard: mmccard@0 { - reg = <0>; - compatible = "mmc-card"; - broken-hpi; - }; -};
Documentation/devicetree/bindings/mmc/mmc-card.yaml new file +48 -0
48 lines not on this page · raw message
Documentation/devicetree/bindings/mmc/mmc-controller.yaml +0 -6
@@ -333,12 +333,6 @@ patternProperties: subnode describes. A value of 0 denotes the memory SD function, values from 1 to 7 denote the SDIO functions. - broken-hpi: - $ref: /schemas/types.yaml#/definitions/flag - description: - Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used. - required: - reg
Signature · 1 line
2.31.1
Re: [PATCH v2 30/52] dt-bindings: mmc: Convert MMC Card binding to a schema
Quoted 18 lines · Maxime Ripard
MMC Cards can have an optional Device Tree binding to add non-discoverable properties.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Some of these properties were already described in the MMC controller binding, even though they are not generic and do not apply to any device, so we took the occasion to fix this.
Cc Ulf Hansson <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Fixed additionalProperties
Quoted 8 lines
--- .../devicetree/bindings/mmc/mmc-card.txt | 30 ------------ .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++++++++++++++++++ .../bindings/mmc/mmc-controller.yaml | 6 --- 3 files changed, 48 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yaml
Ulf Hansson
AppliedRe: [PATCH v2 30/52] dt-bindings: mmc: Convert MMC Card binding to a schema
In reply to Maxime RipardQuoted 7 lines · Maxime Ripard
MMC Cards can have an optional Device Tree binding to add non-discoverable properties.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Quoted 8 lines
Some of these properties were already described in the MMC controller binding, even though they are not generic and do not apply to any device, so we took the occasion to fix this.
Cc Ulf Hansson <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Queued for v5.16 on the temporary devel branch, thanks!
Kind regards
Uffe
Quoted 122 lines
---
Changes from v1:
- Fixed additionalProperties--- .../devicetree/bindings/mmc/mmc-card.txt | 30 ------------ .../devicetree/bindings/mmc/mmc-card.yaml | 48 +++++++++++++++++++ .../bindings/mmc/mmc-controller.yaml | 6 --- 3 files changed, 48 insertions(+), 36 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.txt create mode 100644 Documentation/devicetree/bindings/mmc/mmc-card.yamlDocumentation/devicetree/bindings/mmc/mmc-card.txt deleted +0
-30@@ -1,30 +0,0 @@ -mmc-card / eMMC bindings ------------------------- - -This documents describes the devicetree bindings for a mmc-host controller -child node describing a mmc-card / an eMMC, see "Use of Function subnodes" -in mmc.txt - -Required properties: --compatible : Must be "mmc-card" --reg : Must be <0> - -Optional properties: --broken-hpi : Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used - -Example: - -&mmc2 { - pinctrl-names = "default"; - pinctrl-0 = <&mmc2_pins_a>; - vmmc-supply = <®_vcc3v3>; - bus-width = <8>; - non-removable; - - mmccard: mmccard@0 { - reg = <0>; - compatible = "mmc-card"; - broken-hpi; - }; -};Documentation/devicetree/bindings/mmc/mmc-card.yaml new file +48
-0@@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/mmc-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MMC Card / eMMC Generic Device Tree Bindings + +maintainers: + - Ulf Hansson <[email protected]> + +description: | + This documents describes the devicetree bindings for a mmc-host controller + child node describing a mmc-card / an eMMC. + +properties: + compatible: + const: mmc-card + + reg: + const: 0 + + broken-hpi: + $ref: /schemas/types.yaml#/definitions/flag + description: + Use this to indicate that the mmc-card has a broken hpi + implementation, and that hpi should not be used. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + mmc { + #address-cells = <1>; + #size-cells = <0>; + + card@0 { + compatible = "mmc-card"; + reg = <0>; + broken-hpi; + }; + }; + +...Documentation/devicetree/bindings/mmc/mmc-controller.yaml +0
-7@@ -333,12 +333,6 @@ patternProperties: subnode describes. A value of 0 denotes the memory SD function, values from 1 to 7 denote the SDIO functions. - broken-hpi: - $ref: /schemas/types.yaml#/definitions/flag - description: - Use this to indicate that the mmc-card has a broken hpi - implementation, and that hpi should not be used. - required: - reg --2.31.1
PATCH v2 31/52 dt-bindings: net: dwmac: Fix typo in the R40 compatible
In reply to Maxime RipardEven though both the driver and the device trees all use the allwinner,sun8i-r40-gmac compatible, we documented the compatible as allwinner,sun8i-r40-emac in the binding. Let's fix this.
--- .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++-- Documentation/devicetree/bindings/net/snps,dwmac.yaml | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +2 -2
@@ -15,7 +15,7 @@ properties: oneOf: - const: allwinner,sun8i-a83t-emac - const: allwinner,sun8i-h3-emac - - const: allwinner,sun8i-r40-emac + - const: allwinner,sun8i-r40-gmac - const: allwinner,sun8i-v3s-emac - const: allwinner,sun50i-a64-emac - items:
@@ -91,7 +91,7 @@ allOf: compatible: contains: enum: - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac then: properties:
Documentation/devicetree/bindings/net/snps,dwmac.yaml +3 -3
@@ -49,7 +49,7 @@ properties: - allwinner,sun7i-a20-gmac - allwinner,sun8i-a83t-emac - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - loongson,ls2k-dwmac
@@ -316,7 +316,7 @@ allOf: - allwinner,sun7i-a20-gmac - allwinner,sun8i-a83t-emac - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - ingenic,jz4775-mac
@@ -364,7 +364,7 @@ allOf: - allwinner,sun7i-a20-gmac - allwinner,sun8i-a83t-emac - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-emac + - allwinner,sun8i-r40-gmac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac - loongson,ls2k-dwmac
Signature · 1 line
2.31.1
Re: [PATCH v2 31/52] dt-bindings: net: dwmac: Fix typo in the R40 compatible
Dne sreda, 01. september 2021 ob 11:18:31 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
Even though both the driver and the device trees all use the allwinner,sun8i-r40-gmac compatible, we documented the compatible as allwinner,sun8i-r40-emac in the binding. Let's fix this.
Quoted 8 lines
Cc Alexandre Torgue <[email protected]>Cc "David S. Miller" <[email protected]>Cc Giuseppe Cavallaro <[email protected]>Cc Jakub Kicinski <[email protected]>Cc Jose Abreu <[email protected]>Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
PATCH v2 32/52 dt-bindings: net: wireless: Convert ESP ESP8089 binding to a schema
In reply to Maxime RipardThe ESP8089 Wireless Chip is supported by Linux (through an out-of-tree driver) thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
--- .../bindings/net/wireless/esp,esp8089.txt | 30 ------------- .../bindings/net/wireless/esp,esp8089.yaml | 43 +++++++++++++++++++ 2 files changed, 43 insertions(+), 30 deletions(-) delete mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt create mode 100644 Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml
Documentation/devicetree/bindings/net/wireless/esp,esp8089.txt deleted +0 -30
@@ -1,30 +0,0 @@ -Espressif ESP8089 wireless SDIO devices - -This node provides properties for controlling the ESP8089 wireless device. -The node is expected to be specified as a child node to the SDIO controller -that connects the device to the system. - -Required properties: - - - compatible : Should be "esp,esp8089". - -Optional properties: - - esp,crystal-26M-en: Integer value for the crystal_26M_en firmware parameter - -Example: - -&mmc1 { - #address-cells = <1>; - #size-cells = <0>; - - vmmc-supply = <®_dldo1>; - mmc-pwrseq = <&wifi_pwrseq>; - bus-width = <4>; - non-removable; - - esp8089: sdio_wifi@1 { - compatible = "esp,esp8089"; - reg = <1>; - esp,crystal-26M-en = <2>; - }; -};
Documentation/devicetree/bindings/net/wireless/esp,esp8089.yaml new file +43 -0
43 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v2 33/52 dt-bindings: regulator: Convert SY8106A binding to a schema
In reply to Maxime RipardThe Silergy SY8106A is a regulator controlled through i2c supported by Linux with a matching device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
--- .../bindings/regulator/silergy,sy8106a.yaml | 52 +++++++++++++++++++ .../bindings/regulator/sy8106a-regulator.txt | 23 -------- 2 files changed, 52 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml delete mode 100644 Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt
Documentation/devicetree/bindings/regulator/silergy,sy8106a.yaml new file +52 -0
@@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/silergy,sy8106a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silergy SY8106A Voltage Regulator Device Tree Bindings + +maintainers: + - Ondrej Jirman <[email protected]> + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + const: silergy,sy8106a + + reg: + maxItems: 1 + + silergy,fixed-microvolt: + description: > + The voltage when I2C regulating is disabled (set by external resistor + like a fixed voltage) + +required: + - compatible + - reg + - silergy,fixed-microvolt + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@65 { + compatible = "silergy,sy8106a"; + reg = <0x65>; + regulator-name = "sy8106a-vdd"; + silergy,fixed-microvolt = <1200000>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + regulator-always-on; + }; + }; + +...
Documentation/devicetree/bindings/regulator/sy8106a-regulator.txt deleted +0 -23
@@ -1,23 +0,0 @@ -SY8106A Voltage regulator - -Required properties: -- compatible: Must be "silergy,sy8106a" -- reg: I2C slave address - must be <0x65> -- silergy,fixed-microvolt - the voltage when I2C regulating is disabled (set - by external resistor like a fixed voltage) - -Any property defined as part of the core regulator binding, defined in -./regulator.txt, can also be used. - -Example: - - sy8106a { - compatible = "silergy,sy8106a"; - reg = <0x65>; - regulator-name = "sy8106a-vdd"; - silergy,fixed-microvolt = <1200000>; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1400000>; - regulator-boot-on; - regulator-always-on; - };
Signature · 1 line
2.31.1
PATCH v2 34/52 dt-bindings: sunxi: Add CPU Configuration Controller Binding
In reply to Maxime RipardEven though we've used the CPU configuration driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
--- .../sunxi/allwinner,sun6i-a31-cpuconfig.yaml | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml new file +38 -0
@@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun6i-a31-cpuconfig.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner CPU Configuration Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <[email protected]> + - Maxime Ripard <[email protected]> + +properties: + compatible: + enum: + - allwinner,sun6i-a31-cpuconfig + - allwinner,sun8i-a23-cpuconfig + - allwinner,sun8i-a83t-cpucfg + - allwinner,sun8i-a83t-r-cpucfg + - allwinner,sun9i-a80-cpucfg + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + cpucfg@1f01c00 { + compatible = "allwinner,sun6i-a31-cpuconfig"; + reg = <0x01f01c00 0x300>; + }; + +...
Signature · 1 line
2.31.1
Re: [PATCH v2 34/52] dt-bindings: sunxi: Add CPU Configuration Controller Binding
Dne sreda, 01. september 2021 ob 11:18:34 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
Even though we've used the CPU configuration driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 34/52] dt-bindings: sunxi: Add CPU Configuration Controller Binding
Quoted 9 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:34 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
Even though we've used the CPU configuration driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 35/52 dt-bindings: sunxi: Add Allwinner A80 PRCM Binding
In reply to Maxime RipardEven though we've used the A80 PRCM driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
--- .../arm/sunxi/allwinner,sun9i-a80-prcm.yaml | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun9i-a80-prcm.yaml new file +33 -0
@@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/sunxi/allwinner,sun9i-a80-prcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A80 PRCM Device Tree Bindings + +maintainers: + - Chen-Yu Tsai <[email protected]> + - Maxime Ripard <[email protected]> + +properties: + compatible: + const: allwinner,sun9i-a80-prcm + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + prcm@8001400 { + compatible = "allwinner,sun9i-a80-prcm"; + reg = <0x08001400 0x200>; + }; + +...
Signature · 1 line
2.31.1
Re: [PATCH v2 35/52] dt-bindings: sunxi: Add Allwinner A80 PRCM Binding
Dne sreda, 01. september 2021 ob 11:18:35 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
Even though we've used the A80 PRCM driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 35/52] dt-bindings: sunxi: Add Allwinner A80 PRCM Binding
Quoted 9 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:35 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
Even though we've used the A80 PRCM driver for some time and a number of boards using it already, we never had a binding for it. Let's add it based on what the driver expects and the boards are providing.
Reviewed-by Rob Herring <[email protected]>Signed-off-by Maxime Ripard <[email protected]>Reviewed-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 36/52 dt-bindings: usb: Convert SMSC USB3503 binding to a schema
In reply to Maxime RipardThe SMSC USB3503 USB Hub Controller is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Added maximum number of items for clocks and gpios
- Fixed the example node name
--- .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 ++++++++++++++++++ .../devicetree/bindings/usb/usb3503.txt | 39 ------- 2 files changed, 108 insertions(+), 39 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
Documentation/devicetree/bindings/usb/smsc,usb3503.yaml new file +108 -0
@@ -0,0 +1,108 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/smsc,usb3503.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SMSC USB3503 High-Speed Hub Controller Device Tree Bindings + +maintainers: + - Dongjin Kim <[email protected]> + +properties: + compatible: + enum: + - smsc,usb3503 + - smsc,usb3503a + + reg: + maxItems: 1 + + connect-gpios: + maxItems: 1 + description: > + GPIO for connect + + intn-gpios: + maxItems: 1 + description: > + GPIO for interrupt + + reset-gpios: + maxItems: 1 + description: > + GPIO for reset + + disabled-ports: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 3 + items: + minimum: 1 + maximum: 3 + description: > + Specifies the ports unused using their port number. Do not describe this + property if all ports have to be enabled. + + initial-mode: + enum: [1, 2] + description: > + Specifies initial mode. 1 for Hub mode, 2 for standby mode. + + clocks: + maxItems: 1 + description: > + Clock used for driving REFCLK signal. If not provided the driver assumes + that clock signal is always available, its rate is specified by REF_SEL + pins and a value from the primary reference clock frequencies table is + used. + + clock-names: + const: refclk + + refclk-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + Frequency of the REFCLK signal as defined by REF_SEL pins. If not + provided, driver will not set rate of the REFCLK signal and assume that a + value from the primary reference clock frequencies table is used. + +required: + - compatible + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + usb-hub@8 { + compatible = "smsc,usb3503"; + reg = <0x08>; + connect-gpios = <&gpx3 0 1>; + disabled-ports = <2 3>; + intn-gpios = <&gpx3 4 1>; + reset-gpios = <&gpx3 5 1>; + initial-mode = <1>; + clocks = <&clks 80>; + clock-names = "refclk"; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + + usb-hub { + /* I2C is not connected */ + compatible = "smsc,usb3503"; + initial-mode = <1>; /* initialize in HUB mode */ + disabled-ports = <1>; + intn-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ + reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */ + connect-gpios = <&pio 4 17 GPIO_ACTIVE_HIGH>; /* PE17 */ + refclk-frequency = <19200000>; + }; + +...
Documentation/devicetree/bindings/usb/usb3503.txt deleted +0 -39
@@ -1,39 +0,0 @@ -SMSC USB3503 High-Speed Hub Controller - -Required properties: -- compatible: Should be "smsc,usb3503" or "smsc,usb3503a". - -Optional properties: -- reg: Specifies the i2c slave address, it is required and should be 0x08 - if I2C is used. -- connect-gpios: Should specify GPIO for connect. -- disabled-ports: Should specify the ports unused. - '1' or '2' or '3' are available for this property to describe the port - number. 1~3 property values are possible to be described. - Do not describe this property if all ports have to be enabled. -- intn-gpios: Should specify GPIO for interrupt. -- reset-gpios: Should specify GPIO for reset. -- initial-mode: Should specify initial mode. - (1 for HUB mode, 2 for STANDBY mode) -- refclk: Clock used for driving REFCLK signal (optional, if not provided - the driver assumes that clock signal is always available, its - rate is specified by REF_SEL pins and a value from the primary - reference clock frequencies table is used). Use clocks and - clock-names in order to assign it -- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL - pins (optional, if not provided, driver will not set rate of the - REFCLK signal and assume that a value from the primary reference - clock frequencies table is used) - -Examples: - usb3503@8 { - compatible = "smsc,usb3503"; - reg = <0x08>; - connect-gpios = <&gpx3 0 1>; - disabled-ports = <2 3>; - intn-gpios = <&gpx3 4 1>; - reset-gpios = <&gpx3 5 1>; - initial-mode = <1>; - clocks = <&clks 80>; - clock-names = "refclk"; - };
Signature · 1 line
2.31.1
Re: [PATCH v2 36/52] dt-bindings: usb: Convert SMSC USB3503 binding to a schema
Quoted 16 lines · Maxime Ripard
The SMSC USB3503 USB Hub Controller is supported by Linux thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Dongjin Kim <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Added maximum number of items for clocks and gpios
- Fixed the example node name
Quoted 7 lines
--- .../devicetree/bindings/usb/smsc,usb3503.yaml | 108 ++++++++++++++++++ .../devicetree/bindings/usb/usb3503.txt | 39 ------- 2 files changed, 108 insertions(+), 39 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/smsc,usb3503.yaml delete mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
PATCH v2 37/52 dt-bindings: usb: dwc3: Fix usb-phy check
In reply to Maxime RipardThe original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.
However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.
Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.
--- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +5 -5
@@ -73,15 +73,15 @@ properties: phys: minItems: 1 - items: - - description: USB2/HS PHY - - description: USB3/SS PHY + maxItems: 2 phy-names: minItems: 1 + maxItems: 2 items: - - const: usb2-phy - - const: usb3-phy + enum: + - usb2-phy + - usb3-phy resets: minItems: 1
Signature · 1 line
2.31.1
Re: [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check
Quoted 25 lines · Maxime Ripard
The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.
However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.
Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.
Cc Felipe Balbi <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)Documentation/devicetree/bindings/usb/snps,dwc3.yaml +0
-0
Documentation/devicetree/bindings/usb/snps,dwc3.yaml properties: · line 76
Quoted 7 lines
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +1
-3@@ -73,15 +73,15 @@ properties: phys: minItems: 1 - items: - - description: USB2/HS PHY - - description: USB3/SS PHY + maxItems: 2
I'm not sure you should enforce a maximum of 2 PHYs. Some systems may use more than one USB2 PHY to take care of different parts of the USB link.
IIRC N900 was a USB2-only system which shipped with two USB2 PHYs: one handling the communication proper and one handling charger detection and the like.
Signature · 6 lines
balbi _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Rob Herring
maintainerRe: [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check
Quoted 29 lines · Felipe Balbi
Quoted 26 lines · Maxime Ripard
The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.
However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.
Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.
Cc Felipe Balbi <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)Documentation/devicetree/bindings/usb/snps,dwc3.yaml +0
-0@@ -73,15 +73,15 @@ properties:
Quoted 10 lines
Documentation/devicetree/bindings/usb/snps,dwc3.yaml properties: · line 76
Quoted 6 lines
Documentation/devicetree/bindings/usb/snps,dwc3.yaml +1
-3phys: minItems: 1 - items: - - description: USB2/HS PHY - - description: USB3/SS PHY + maxItems: 2I'm not sure you should enforce a maximum of 2 PHYs. Some systems may use more than one USB2 PHY to take care of different parts of the USB link.
It was already limited to 2. This change doesn't change that.
Rob
Re: [PATCH v2 37/52] dt-bindings: usb: dwc3: Fix usb-phy check
In reply to Maxime RipardQuoted 12 lines · Maxime Ripard
The original binding was allowing any combination of usb2-phy and usb3-phy in the phys and phy-names properties.
However, the current binding enforces that those properties must be a list of usb2-phy and usb3-phy, with exactly one element, effectively making usb2-phy the only value being valid.
Let's rework the properties description to allow either one or two element picked with values either usb2-phy or usb3-phy. The rest of the tooling makes sure that we don't get any duplicate value, so this should be what we want.
Quoted 8 lines
Cc Felipe Balbi <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Signed-off-by Maxime Ripard <[email protected]>--- Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
PATCH v2 38/52 dt-bindings: w1: Convert 1-Wire GPIO binding to a schema
In reply to Maxime RipardBitbanged 1-Wire buses are supported by Linux thanks to their device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
---
Changes from v1:
- Changed additionalproperties to make sure all the other items in the schema are nodes
--- .../devicetree/bindings/w1/w1-gpio.txt | 27 ------------ .../devicetree/bindings/w1/w1-gpio.yaml | 44 +++++++++++++++++++ 2 files changed, 44 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml
Documentation/devicetree/bindings/w1/w1-gpio.txt deleted +0 -27
@@ -1,27 +0,0 @@ -w1-gpio devicetree bindings - -Required properties: - - - compatible: "w1-gpio" - - gpios: one or two GPIO specs: - - the first one is used as data I/O pin - - the second one is optional. If specified, it is used as - enable pin for an external pin pullup. - -Optional properties: - - - linux,open-drain: if specified, the data pin is considered in - open-drain mode. - -Also refer to the generic w1.txt document. - -Examples: - - onewire { - compatible = "w1-gpio"; - gpios = <&gpio 0 GPIO_ACTIVE_HIGH>; - - battery { - // ... - }; - };
Documentation/devicetree/bindings/w1/w1-gpio.yaml new file +44 -0
44 lines not on this page · raw message
Signature · 1 line
2.31.1
Re: [PATCH v2 38/52] dt-bindings: w1: Convert 1-Wire GPIO binding to a schema
Quoted 15 lines · Maxime Ripard
Bitbanged 1-Wire buses are supported by Linux thanks to their device tree binding.
Now that we have the DT validation in place, let's convert the device tree bindings for that driver over to a YAML schema.
Cc Daniel Mack <[email protected]>Cc Evgeniy Polyakov <[email protected]>Signed-off-by Maxime Ripard <[email protected]>---
Changes from v1:
- Changed additionalproperties to make sure all the other items in the schema are nodes
Quoted 7 lines
--- .../devicetree/bindings/w1/w1-gpio.txt | 27 ------------ .../devicetree/bindings/w1/w1-gpio.yaml | 44 +++++++++++++++++++ 2 files changed, 44 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.txt create mode 100644 Documentation/devicetree/bindings/w1/w1-gpio.yaml
Applied, thanks!
PATCH v2 39/52 ARM: dts: sunxi: Rename power-supply names
In reply to Maxime RipardThe name of our PMIC power supply names conflict with the generic regulator supply check that matches anything called *-supply, including the nodes, and then makes sure it's a phandle.
A node is obviously not a phandle, so let's change our power supplies names to avoid any conflict.
--- arch/arm/boot/dts/axp209.dtsi | 6 +++--- arch/arm/boot/dts/axp22x.dtsi | 6 +++--- arch/arm/boot/dts/axp81x.dtsi | 6 +++--- arch/arm64/boot/dts/allwinner/axp803.dtsi | 6 +++--- 4 files changed, 12 insertions(+), 12 deletions(-)
arch/arm/boot/dts/axp209.dtsi +3 -3
@@ -53,7 +53,7 @@ &axp209 { interrupt-controller; #interrupt-cells = <1>; - ac_power_supply: ac-power-supply { + ac_power_supply: ac-power { compatible = "x-powers,axp202-ac-power-supply"; status = "disabled"; };
@@ -69,7 +69,7 @@ axp_gpio: gpio { #gpio-cells = <2>; }; - battery_power_supply: battery-power-supply { + battery_power_supply: battery-power { compatible = "x-powers,axp209-battery-power-supply"; status = "disabled"; };
@@ -112,7 +112,7 @@ reg_ldo5: ldo5 { }; }; - usb_power_supply: usb-power-supply { + usb_power_supply: usb-power { compatible = "x-powers,axp202-usb-power-supply"; status = "disabled"; };
arch/arm/boot/dts/axp22x.dtsi +3 -3
@@ -52,7 +52,7 @@ &axp22x { interrupt-controller; #interrupt-cells = <1>; - ac_power_supply: ac-power-supply { + ac_power_supply: ac-power { compatible = "x-powers,axp221-ac-power-supply"; status = "disabled"; };
@@ -62,7 +62,7 @@ axp_adc: adc { #io-channel-cells = <1>; }; - battery_power_supply: battery-power-supply { + battery_power_supply: battery-power { compatible = "x-powers,axp221-battery-power-supply"; status = "disabled"; };
@@ -163,7 +163,7 @@ reg_drivevbus: drivevbus { }; }; - usb_power_supply: usb_power_supply { + usb_power_supply: usb-power { compatible = "x-powers,axp221-usb-power-supply"; status = "disabled"; };
arch/arm/boot/dts/axp81x.dtsi +3 -3
@@ -48,7 +48,7 @@ &axp81x { interrupt-controller; #interrupt-cells = <1>; - ac_power_supply: ac-power-supply { + ac_power_supply: ac-power { compatible = "x-powers,axp813-ac-power-supply"; status = "disabled"; };
@@ -74,7 +74,7 @@ gpio1_ldo: gpio1-ldo { }; }; - battery_power_supply: battery-power-supply { + battery_power_supply: battery-power { compatible = "x-powers,axp813-battery-power-supply"; status = "disabled"; };
@@ -172,7 +172,7 @@ reg_drivevbus: drivevbus { }; }; - usb_power_supply: usb-power-supply { + usb_power_supply: usb-power { compatible = "x-powers,axp813-usb-power-supply"; }; };
arch/arm64/boot/dts/allwinner/axp803.dtsi +3 -3
@@ -10,7 +10,7 @@ &axp803 { interrupt-controller; #interrupt-cells = <1>; - ac_power_supply: ac-power-supply { + ac_power_supply: ac-power { compatible = "x-powers,axp803-ac-power-supply", "x-powers,axp813-ac-power-supply"; status = "disabled";
@@ -37,7 +37,7 @@ gpio1_ldo: gpio1-ldo { }; }; - battery_power_supply: battery-power-supply { + battery_power_supply: battery-power { compatible = "x-powers,axp803-battery-power-supply", "x-powers,axp813-battery-power-supply"; status = "disabled";
@@ -147,7 +147,7 @@ reg_drivevbus: drivevbus { }; }; - usb_power_supply: usb-power-supply { + usb_power_supply: usb-power { compatible = "x-powers,axp803-usb-power-supply", "x-powers,axp813-usb-power-supply"; status = "disabled";
Signature · 1 line
2.31.1
Re: [PATCH v2 39/52] ARM: dts: sunxi: Rename power-supply names
Dne sreda, 01. september 2021 ob 11:18:39 CEST je Maxime Ripard napisal(a):
Quoted 8 lines
The name of our PMIC power supply names conflict with the generic regulator supply check that matches anything called *-supply, including the nodes, and then makes sure it's a phandle.
A node is obviously not a phandle, so let's change our power supplies names to avoid any conflict.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 39/52] ARM: dts: sunxi: Rename power-supply names
Quoted 11 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:39 CEST je Maxime Ripard napisal(a):
Quoted 8 lines
The name of our PMIC power supply names conflict with the generic regulator supply check that matches anything called *-supply, including the nodes, and then makes sure it's a phandle.
A node is obviously not a phandle, so let's change our power supplies names to avoid any conflict.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 40/52 ARM: dts: sunxi: Rename gpio pinctrl names
In reply to Maxime RipardWe've had a pinctrl node name convention for a while now, let's follow it for the AXP pinctrl nodes as well.
--- arch/arm/boot/dts/axp81x.dtsi | 4 ++-- arch/arm64/boot/dts/allwinner/axp803.dtsi | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm/boot/dts/axp81x.dtsi +2 -2
@@ -63,12 +63,12 @@ axp_gpio: gpio { gpio-controller; #gpio-cells = <2>; - gpio0_ldo: gpio0-ldo { + gpio0_ldo: gpio0-ldo-pin { pins = "GPIO0"; function = "ldo"; }; - gpio1_ldo: gpio1-ldo { + gpio1_ldo: gpio1-ldo-pin { pins = "GPIO1"; function = "ldo"; };
arch/arm64/boot/dts/allwinner/axp803.dtsi +2 -2
@@ -26,12 +26,12 @@ axp_gpio: gpio { gpio-controller; #gpio-cells = <2>; - gpio0_ldo: gpio0-ldo { + gpio0_ldo: gpio0-ldo-pin { pins = "GPIO0"; function = "ldo"; }; - gpio1_ldo: gpio1-ldo { + gpio1_ldo: gpio1-ldo-pin { pins = "GPIO1"; function = "ldo"; };
Signature · 1 line
2.31.1
Re: [PATCH v2 40/52] ARM: dts: sunxi: Rename gpio pinctrl names
Dne sreda, 01. september 2021 ob 11:18:40 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
We've had a pinctrl node name convention for a while now, let's follow it for the AXP pinctrl nodes as well.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 40/52] ARM: dts: sunxi: Rename gpio pinctrl names
Quoted 7 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:40 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
We've had a pinctrl node name convention for a while now, let's follow it for the AXP pinctrl nodes as well.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 41/52 ARM: dts: sunxi: Fix OPP arrays
In reply to Maxime RipardEven though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each OPP, which in turns create a validation warning.
Let's fix this.
--- .../arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 11 +++-- arch/arm/boot/dts/sun4i-a10.dtsi | 11 +++-- arch/arm/boot/dts/sun5i-a13.dtsi | 15 +++---- arch/arm/boot/dts/sun6i-a31.dtsi | 44 +++++++++---------- arch/arm/boot/dts/sun7i-a20-bananapi.dts | 17 ++++--- arch/arm/boot/dts/sun7i-a20.dtsi | 34 +++++++------- 6 files changed, 61 insertions(+), 71 deletions(-)
arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts +5 -6
@@ -91,12 +91,11 @@ &cpu0 { /* * The A10-Lime is known to be unstable when running at 1008 MHz */ - operating-points = < - /* kHz uV */ - 912000 1350000 - 864000 1300000 - 624000 1250000 - >; + operating-points = + /* kHz uV */ + <912000 1350000>, + <864000 1300000>, + <624000 1250000>; }; &de {
arch/arm/boot/dts/sun4i-a10.dtsi +5 -6
@@ -115,13 +115,12 @@ cpu0: cpu@0 { reg = <0x0>; clocks = <&ccu CLK_CPU>; clock-latency = <244144>; /* 8 32k periods */ - operating-points = < + operating-points = /* kHz uV */ - 1008000 1400000 - 912000 1350000 - 864000 1300000 - 624000 1250000 - >; + <1008000 1400000>, + <912000 1350000>, + <864000 1300000>, + <624000 1250000>; #cooling-cells = <2>; }; };
arch/arm/boot/dts/sun5i-a13.dtsi +7 -8
@@ -102,15 +102,14 @@ &ccu { &cpu0 { clock-latency = <244144>; /* 8 32k periods */ - operating-points = < + operating-points = /* kHz uV */ - 1008000 1400000 - 912000 1350000 - 864000 1300000 - 624000 1200000 - 576000 1200000 - 432000 1200000 - >; + <1008000 1400000>, + <912000 1350000>, + <864000 1300000>, + <624000 1200000>, + <576000 1200000>, + <432000 1200000>; #cooling-cells = <2>; };
arch/arm/boot/dts/sun6i-a31.dtsi +20 -24
72 lines not on this page · raw message
arch/arm/boot/dts/sun7i-a20-bananapi.dts +8 -9
@@ -104,16 +104,15 @@ &codec { &cpu0 { cpu-supply = <®_dcdc2>; - operating-points = < + operating-points = /* kHz uV */ - 960000 1400000 - 912000 1400000 - 864000 1350000 - 720000 1250000 - 528000 1150000 - 312000 1100000 - 144000 1050000 - >; + <960000 1400000>, + <912000 1400000>, + <864000 1350000>, + <720000 1250000>, + <528000 1150000>, + <312000 1100000>, + <144000 1050000>; }; &de {
arch/arm/boot/dts/sun7i-a20.dtsi +16 -18
@@ -106,16 +106,15 @@ cpu0: cpu@0 { reg = <0>; clocks = <&ccu CLK_CPU>; clock-latency = <244144>; /* 8 32k periods */ - operating-points = < + operating-points = /* kHz uV */ - 960000 1400000 - 912000 1400000 - 864000 1300000 - 720000 1200000 - 528000 1100000 - 312000 1000000 - 144000 1000000 - >; + <960000 1400000>, + <912000 1400000>, + <864000 1300000>, + <720000 1200000>, + <528000 1100000>, + <312000 1000000>, + <144000 1000000>; #cooling-cells = <2>; };
@@ -125,16 +124,15 @@ cpu1: cpu@1 { reg = <1>; clocks = <&ccu CLK_CPU>; clock-latency = <244144>; /* 8 32k periods */ - operating-points = < + operating-points = /* kHz uV */ - 960000 1400000 - 912000 1400000 - 864000 1300000 - 720000 1200000 - 528000 1100000 - 312000 1000000 - 144000 1000000 - >; + <960000 1400000>, + <912000 1400000>, + <864000 1300000>, + <720000 1200000>, + <528000 1100000>, + <312000 1000000>, + <144000 1000000>; #cooling-cells = <2>; }; };
Signature · 1 line
2.31.1
Re: [PATCH v2 41/52] ARM: dts: sunxi: Fix OPP arrays
Dne sreda, 01. september 2021 ob 11:18:41 CEST je Maxime Ripard napisal(a):
Quoted 7 lines
Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each OPP, which in turns create a validation warning.
Let's fix this.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 41/52] ARM: dts: sunxi: Fix OPP arrays
Quoted 10 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:41 CEST je Maxime Ripard napisal(a):
Quoted 7 lines
Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each OPP, which in turns create a validation warning.
Let's fix this.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
PATCH v2 42/52 ARM: dts: sunxi: Fix OPPs node name
In reply to Maxime RipardThe operating-points-v2 nodes are named inconsistently, but mostly either opp_table0 or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it.
--- arch/arm/boot/dts/sun8i-a33.dtsi | 4 ++-- arch/arm/boot/dts/sun8i-a83t.dtsi | 4 ++-- arch/arm/boot/dts/sun8i-h3.dtsi | 4 ++-- arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi | 2 +- arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi | 2 +- arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-)
arch/arm/boot/dts/sun8i-a33.dtsi +2 -2
@@ -46,7 +46,7 @@ #include <dt-bindings/thermal/thermal.h> / { - cpu0_opp_table: opp_table0 { + cpu0_opp_table: opp-table-cpu { compatible = "operating-points-v2"; opp-shared;
@@ -164,7 +164,7 @@ iio-hwmon { io-channels = <&ths>; }; - mali_opp_table: gpu-opp-table { + mali_opp_table: opp-table-gpu { compatible = "operating-points-v2"; opp-144000000 {
arch/arm/boot/dts/sun8i-a83t.dtsi +2 -2
@@ -200,7 +200,7 @@ de: display-engine { status = "disabled"; }; - cpu0_opp_table: opp_table0 { + cpu0_opp_table: opp-table-cluster0 { compatible = "operating-points-v2"; opp-shared;
@@ -253,7 +253,7 @@ opp-1200000000 { }; }; - cpu1_opp_table: opp_table1 { + cpu1_opp_table: opp-table-cluster1 { compatible = "operating-points-v2"; opp-shared;
arch/arm/boot/dts/sun8i-h3.dtsi +2 -2
@@ -44,7 +44,7 @@ #include <dt-bindings/thermal/thermal.h> / { - cpu0_opp_table: opp_table0 { + cpu0_opp_table: opp-table-cpu { compatible = "operating-points-v2"; opp-shared;
@@ -112,7 +112,7 @@ cpu3: cpu@3 { }; }; - gpu_opp_table: gpu-opp-table { + gpu_opp_table: opp-table-gpu { compatible = "operating-points-v2"; opp-120000000 {
arch/arm64/boot/dts/allwinner/sun50i-a64-cpu-opp.dtsi +1 -1
@@ -4,7 +4,7 @@ */ / { - cpu0_opp_table: opp_table0 { + cpu0_opp_table: opp-table-cpu { compatible = "operating-points-v2"; opp-shared;
arch/arm64/boot/dts/allwinner/sun50i-h5-cpu-opp.dtsi +1 -1
@@ -2,7 +2,7 @@ // Copyright (C) 2020 Chen-Yu Tsai <[email protected]> / { - cpu_opp_table: cpu-opp-table { + cpu_opp_table: opp-table-cpu { compatible = "operating-points-v2"; opp-shared;
arch/arm64/boot/dts/allwinner/sun50i-h6-cpu-opp.dtsi +1 -1
@@ -3,7 +3,7 @@ // Copyright (C) 2020 Clément Péron <[email protected]> / { - cpu_opp_table: cpu-opp-table { + cpu_opp_table: opp-table-cpu { compatible = "allwinner,sun50i-h6-operating-points"; nvmem-cells = <&cpu_speed_grade>; opp-shared;
Signature · 1 line
2.31.1
Re: [PATCH v2 42/52] ARM: dts: sunxi: Fix OPPs node name
Dne sreda, 01. september 2021 ob 11:18:42 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
The operating-points-v2 nodes are named inconsistently, but mostly either
opp_table0or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it.Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 42/52] ARM: dts: sunxi: Fix OPPs node name
Quoted 9 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:42 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
The operating-points-v2 nodes are named inconsistently, but mostly either
opp_table0or gpu-opp-table. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called opp-table-*. Let's fix it.Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 43/52 ARM: dts: sunxi: Fix the SPI NOR node names
In reply to Maxime RipardAccording to the SPI NOR bindings, the flash node names are supposed to be flash@<address>. Let's fix our users to use that new scheme.
--- arch/arm/boot/dts/sun8i-v3-sl631.dtsi | 2 +- arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi | 2 +- arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
arch/arm/boot/dts/sun8i-v3-sl631.dtsi +1 -1
@@ -115,7 +115,7 @@ ®_ldo2 { &spi0 { status = "okay"; - spi-flash@0 { + flash@0 { reg = <0>; compatible = "jedec,spi-nor"; spi-max-frequency = <50000000>;
arch/arm/boot/dts/sunxi-libretech-all-h3-it.dtsi +1 -1
@@ -156,7 +156,7 @@ &r_pio { &spi0 { status = "okay"; - spiflash@0 { + flash@0 { compatible = "jedec,spi-nor"; reg = <0>; spi-max-frequency = <50000000>;
arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts +1 -1
@@ -343,7 +343,7 @@ &sound { &spi0 { status = "okay"; - spi-flash@0 { + flash@0 { compatible = "mxicy,mx25l1606e", "jedec,spi-nor"; reg = <0>; spi-max-frequency = <80000000>;
Signature · 1 line
2.31.1
Re: [PATCH v2 43/52] ARM: dts: sunxi: Fix the SPI NOR node names
Dne sreda, 01. september 2021 ob 11:18:43 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
According to the SPI NOR bindings, the flash node names are supposed to be flash@<address>. Let's fix our users to use that new scheme.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 43/52] ARM: dts: sunxi: Fix the SPI NOR node names
Quoted 7 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:43 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
According to the SPI NOR bindings, the flash node names are supposed to be flash@<address>. Let's fix our users to use that new scheme.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 44/52 ARM: dts: v3s: Remove useless DMA properties
In reply to Maxime RipardThe crypto engine binding doesn't allow for any DMA property, yet the v3s define some. Remove them.
--- arch/arm/boot/dts/sun8i-v3s.dtsi | 2 -- 1 file changed, 2 deletions(-)
arch/arm/boot/dts/sun8i-v3s.dtsi +0 -2
@@ -285,8 +285,6 @@ crypto@1c15000 { interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>; clock-names = "ahb", "mod"; - dmas = <&dma 16>, <&dma 16>; - dma-names = "rx", "tx"; resets = <&ccu RST_BUS_CE>; reset-names = "ahb"; };
Signature · 1 line
2.31.1
Jernej Škrabec
maintainerRe: [PATCH v2 44/52] ARM: dts: v3s: Remove useless DMA properties
Hi Maxime!
Dne sreda, 01. september 2021 ob 11:18:44 CEST je Maxime Ripard napisal(a):
arch/arm/boot/dts/sun8i-
Quoted 9 lines
The crypto engine binding doesn't allow for any DMA property, yet the v3s define some. Remove them.
Signed-off-by Maxime Ripard <[email protected]>--- arch/arm/boot/dts/sun8i-v3s.dtsi | 2 -- 1 file changed, 2 deletions(-)arch/arm/boot/dts/sun8i- renamed from arch/arm/boot/dts/sun8i-v3s.dtsi +0
-0
v3s.dtsi
arch/arm/boot/dts/sun8i-v3s.dtsi crypto@1c15000 { · line 285
Quoted 5 lines
index
b30bc1a25ebb..44382e36e825100644arch/arm/boot/dts/sun8i-v3s.dtsi +0
-0@@ -285,8 +285,6 @@ crypto@1c15000 { interrupts = <GIC_SPI 80
IRQ_TYPE_LEVEL_HIGH>;
arch/arm/boot/dts/sun8i-v3s.dtsi crypto@1c15000 { · line 289
Quoted 4 lines
arch/arm/boot/dts/sun8i-v3s.dtsi +0
-2clocks = <&ccu CLK_BUS_CE>, <&ccu CLK_CE>; clock-names = "ahb", "mod"; - dmas = <&dma 16>, <&dma 16>; - dma-names = "rx", "tx";
Since V3s documentation mentions those DMA channels, wouldn't be better to update bindings instead?
Best regards,
Jernej
Quoted 7 lines
arch/arm/boot/dts/sun8i-v3s.dtsi +0
-0resets = <&ccu RST_BUS_CE>; reset-names = "ahb"; };Signature · 1 line
2.31.1
PATCH v2 45/52 ARM: dts: tbs711: Fix touchscreen compatible
In reply to Maxime RipardThe edt,edt-ft5x06 compatible has never been a valid compatible according to the binding. Let's change for one that is.
--- arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts +1 -1
@@ -169,7 +169,7 @@ &i2c0 { status = "okay"; touchscreen@38 { - compatible = "edt,edt-ft5x06"; + compatible = "edt,edt-ft5206"; reg = <0x38>; interrupt-parent = <&r_pio>; interrupts = <0 7 IRQ_TYPE_EDGE_FALLING>; /* PL7 */
Signature · 1 line
2.31.1
Re: [PATCH v2 45/52] ARM: dts: tbs711: Fix touchscreen compatible
Dne sreda, 01. september 2021 ob 11:18:45 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
The edt,edt-ft5x06 compatible has never been a valid compatible according to the binding. Let's change for one that is.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 45/52] ARM: dts: tbs711: Fix touchscreen compatible
Quoted 7 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:45 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
The edt,edt-ft5x06 compatible has never been a valid compatible according to the binding. Let's change for one that is.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 46/52 ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible
In reply to Maxime RipardThe dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used together according to the binding.
Since the corpro gm7123 is a drop-in replacement for the adv7123, let's remove dumb-vga-dac from our compatible list.
--- arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts +1 -1
@@ -87,7 +87,7 @@ vga_con_in: endpoint { }; vga-dac { - compatible = "corpro,gm7123", "adi,adv7123", "dumb-vga-dac"; + compatible = "corpro,gm7123", "adi,adv7123"; vdd-supply = <®_dcdc1>; ports {
Signature · 1 line
2.31.1
Re: [PATCH v2 46/52] ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible
Dne sreda, 01. september 2021 ob 11:18:46 CEST je Maxime Ripard napisal(a):
Quoted 8 lines
The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used together according to the binding.
Since the corpro gm7123 is a drop-in replacement for the adv7123, let's remove dumb-vga-dac from our compatible list.
Reviewed-by Chen-Yu Tsai <[email protected]>Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 46/52] ARM: dts: cubieboard4: Remove the dumb-vga-dac compatible
Quoted 11 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:46 CEST je Maxime Ripard napisal(a):
Quoted 8 lines
The dumb-vga-dac and adi,adv7123 compatibles are not supposed to be used together according to the binding.
Since the corpro gm7123 is a drop-in replacement for the adv7123, let's remove dumb-vga-dac from our compatible list.
Reviewed-by Chen-Yu Tsai <[email protected]>Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 47/52 arm64: dts: allwinner: h5: Fix GPU thermal zone node name
In reply to Maxime RipardThe GPU thermal zone is named gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.
--- arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi +1 -1
@@ -217,7 +217,7 @@ cpu-hot-limit { }; }; - gpu_thermal { + gpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 1>;
Signature · 1 line
2.31.1
Re: [PATCH v2 47/52] arm64: dts: allwinner: h5: Fix GPU thermal zone node name
Dne sreda, 01. september 2021 ob 11:18:47 CEST je Maxime Ripard napisal(a):
Quoted 5 lines
The GPU thermal zone is named
gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 47/52] arm64: dts: allwinner: h5: Fix GPU thermal zone node name
Quoted 8 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:47 CEST je Maxime Ripard napisal(a):
Quoted 5 lines
The GPU thermal zone is named
gpu_thermal. However, the underscore is an invalid character for a node name and the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 48/52 arm64: dts: allwinner: h6: Fix de3 parent clocks ordering
In reply to Maxime RipardWhile it doesn't really matter from a functional point of view in this driver's case, it's usually a good practice to list the clocks in a driver in the same driver across all its users.
The H6 is using the inverse order than all the other users, so let's make it consistent.
--- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi +4 -4
@@ -119,10 +119,10 @@ bus@1000000 { display_clocks: clock@0 { compatible = "allwinner,sun50i-h6-de3-clk"; reg = <0x0 0x10000>; - clocks = <&ccu CLK_DE>, - <&ccu CLK_BUS_DE>; - clock-names = "mod", - "bus"; + clocks = <&ccu CLK_BUS_DE>, + <&ccu CLK_DE>; + clock-names = "bus", + "mod"; resets = <&ccu RST_BUS_DE>; #clock-cells = <1>; #reset-cells = <1>;
Signature · 1 line
2.31.1
Re: [PATCH v2 48/52] arm64: dts: allwinner: h6: Fix de3 parent clocks ordering
Dne sreda, 01. september 2021 ob 11:18:48 CEST je Maxime Ripard napisal(a):
Quoted 8 lines
While it doesn't really matter from a functional point of view in this driver's case, it's usually a good practice to list the clocks in a driver in the same driver across all its users.
The H6 is using the inverse order than all the other users, so let's make it consistent.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 48/52] arm64: dts: allwinner: h6: Fix de3 parent clocks ordering
Quoted 11 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:48 CEST je Maxime Ripard napisal(a):
Quoted 8 lines
While it doesn't really matter from a functional point of view in this driver's case, it's usually a good practice to list the clocks in a driver in the same driver across all its users.
The H6 is using the inverse order than all the other users, so let's make it consistent.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 49/52 arm64: dts: allwinner: a100: Fix thermal zone node name
In reply to Maxime RipardThe thermal zones one the A100 are called $device-thermal-zone.
However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.
--- arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi +3 -3
@@ -343,19 +343,19 @@ r_i2c1: i2c@7081800 { }; thermal-zones { - cpu-thermal-zone { + cpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 0>; }; - ddr-thermal-zone { + ddr-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 2>; }; - gpu-thermal-zone { + gpu-thermal { polling-delay-passive = <0>; polling-delay = <0>; thermal-sensors = <&ths 1>;
Signature · 1 line
2.31.1
Re: [PATCH v2 49/52] arm64: dts: allwinner: a100: Fix thermal zone node name
Dne sreda, 01. september 2021 ob 11:18:49 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
The thermal zones one the A100 are called $device-thermal-zone.
However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 49/52] arm64: dts: allwinner: a100: Fix thermal zone node name
Quoted 10 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:49 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
The thermal zones one the A100 are called $device-thermal-zone.
However, the thermal zone binding explicitly requires that zones are called *-thermal. Let's fix it.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 50/52 arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning
In reply to Maxime RipardThe fixed regulator clock name has a unit address, but no reg property, which generates a warning in DTC. Change its name to remove its useless unit address.
--- arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts +1 -1
@@ -77,7 +77,7 @@ speaker_amp: audio-amplifier { sound-name-prefix = "Speaker Amp"; }; - vdd_bl: regulator@0 { + vdd_bl: regulator { compatible = "regulator-fixed"; regulator-name = "bl-3v3"; regulator-min-microvolt = <3300000>;
Signature · 1 line
2.31.1
Re: [PATCH v2 50/52] arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning
Dne sreda, 01. september 2021 ob 11:18:50 CEST je Maxime Ripard napisal(a):
Quoted 5 lines
The fixed regulator clock name has a unit address, but no reg property, which generates a warning in DTC. Change its name to remove its useless unit address.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 50/52] arm64: dts: allwinner: pinetab: Change regulator node name to avoid warning
Quoted 8 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:50 CEST je Maxime Ripard napisal(a):
Quoted 5 lines
The fixed regulator clock name has a unit address, but no reg property, which generates a warning in DTC. Change its name to remove its useless unit address.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 51/52 arm64: dts: allwinner: teres-i: Add missing reg
In reply to Maxime RipardThe anx6345 bridge mandates that the input port is named port@0. Since we have a unit-address, this implies that we need a reg property with the same value, but it was found to be missing in the Teres-I device tree. Make sure it's there.
--- arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts +2 -0
@@ -139,6 +139,8 @@ ports { #size-cells = <0>; port@0 { + reg = <0>; + anx6345_in: endpoint { remote-endpoint = <&tcon0_out_anx6345>; };
Signature · 1 line
2.31.1
Re: [PATCH v2 51/52] arm64: dts: allwinner: teres-i: Add missing reg
Dne sreda, 01. september 2021 ob 11:18:51 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
The anx6345 bridge mandates that the input port is named port@0. Since we have a unit-address, this implies that we need a reg property with the same value, but it was found to be missing in the Teres-I device tree. Make sure it's there.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 51/52] arm64: dts: allwinner: teres-i: Add missing reg
Quoted 9 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:51 CEST je Maxime Ripard napisal(a):
Quoted 6 lines
The anx6345 bridge mandates that the input port is named port@0. Since we have a unit-address, this implies that we need a reg property with the same value, but it was found to be missing in the Teres-I device tree. Make sure it's there.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
PATCH v2 52/52 arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC
In reply to Maxime RipardNeither the binding nor the driver make any use of the wakeup-source property for the AXP803. Remove it.
--- arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts | 1 - 1 file changed, 1 deletion(-)
arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts +0 -1
@@ -208,7 +208,6 @@ axp803: pmic@3a3 { reg = <0x3a3>; interrupt-parent = <&r_intc>; interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_LOW>; - wakeup-source; }; };
Signature · 1 line
2.31.1
Re: [PATCH v2 52/52] arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC
Dne sreda, 01. september 2021 ob 11:18:52 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
Neither the binding nor the driver make any use of the wakeup-source property for the AXP803. Remove it.
Signed-off-by Maxime Ripard <[email protected]>
Best regards,
Jernej
Maxime Ripard
AppliedRe: [PATCH v2 52/52] arm64: dts: allwinner: teres-i: Remove wakekup-source from the PMIC
Quoted 7 lines · Jernej Škrabec
Dne sreda, 01. september 2021 ob 11:18:52 CEST je Maxime Ripard napisal(a):
Quoted 4 lines
Neither the binding nor the driver make any use of the wakeup-source property for the AXP803. Remove it.
Signed-off-by Maxime Ripard <[email protected]>Acked-by Jernej Skrabec <[email protected]>
Applied, thanks
Maxime
Mark Brown
maintainerRe: (subset) [PATCH v2 00/52] ARM: dts: Last round of DT schema fixes
In reply to Maxime RipardQuoted 10 lines · Maxime Ripard
Here's another round of schema warnings fixes for the Allwinner platform.
There's a fair share of new schemas in there since the schema tools now warn when a compatible is not documented in a schema.
We don't have any warning anymore if we use the OPP binding Rob submitted, and since that means we have all our devices properly validated I don't expect more fixes now, aside from the usual bunch of regressions.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[01/52] ASoC: dt-bindings: Add WM8978 Binding
commit: 5bd5699c494f42a3c23e377bb35be5d716b85012
[02/52] ASoC: dt-bindings: Convert Bluetooth SCO Link binding to a schema
commit: 6ef239699102580b104bfca11d9b94abfbc8caec
[03/52] ASoC: dt-bindings: Convert SPDIF Transmitter binding to a schema
commit: 1c02b74ba20838ba194850beb0adfc6b5e11bb2a
[04/52] ASoC: dt-bindings: Convert Simple Amplifier binding to a schema
commit: 50a41ce8c56d07f42a97112077acbaeda8b86ed9All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks,
Mark