* Re: [PATCH V2] dt-bindings: regulator: Convert anatop regulator to json-schema
From: Mark Brown @ 2020-05-29 22:43 UTC (permalink / raw)
To: lgirdwood, robh+dt, Anson Huang, linux-kernel, devicetree,
paul.liu
Cc: Linux-imx
In-Reply-To: <1590717551-20772-1-git-send-email-Anson.Huang@nxp.com>
On Fri, 29 May 2020 09:59:11 +0800, Anson Huang wrote:
> Convert the anatop regulator binding to DT schema format using json-schema.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] dt-bindings: regulator: Convert anatop regulator to json-schema
commit: 81227f49bd272cbcd9bb4650b250519c8aa22065
All 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
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Rob Herring @ 2020-05-29 22:22 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, Linus Walleij, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Ray Jui, Stefan Wahren, Matti Vaittinen,
linux-kernel, open list:PIN CONTROL SUBSYSTEM,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529191522.27938-3-f.fainelli@gmail.com>
On Fri, 29 May 2020 12:15:20 -0700, Florian Fainelli wrote:
> BCM7211 supports wake-up interrupts in the form of optional interrupt
> lines, one per bank, plus the "all banks" interrupt line.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> .../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: Merge gpio-usb-b-connector with usb-connector
From: Rob Herring @ 2020-05-29 22:21 UTC (permalink / raw)
To: Thierry Reding
Cc: Prashant Malani, Rob Herring, linux-usb, devicetree,
Greg Kroah-Hartman, linux-kernel
In-Reply-To: <20200529180631.3200680-1-thierry.reding@gmail.com>
On Fri, 29 May 2020 20:06:31 +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> The binding for usb-connector is a superset of gpio-usb-b-connector. One
> major difference is that gpio-usb-b-connector requires at least one of
> the vbus-gpios and id-gpios properties to be specified. Merge the two
> bindings by adding the compatible string combination for the GPIO USB-B
> variant and an extra conditional for the required properties list to the
> usb-connector.yaml file.
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> .../bindings/connector/usb-connector.yaml | 39 +++++++++++++++++--
> .../devicetree/bindings/usb/usb-conn-gpio.txt | 30 --------------
> 2 files changed, 35 insertions(+), 34 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Mark Brown @ 2020-05-29 22:21 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Serge Semin, Ekaterina Skachko, Feng Tang,
devicetree, Thomas Bogendoerfer, Georgy Vlasov, Pavel Parkhomenko,
Alexey Kolotnikov, linux-spi, linux-kernel, Vadim Vlasov,
Alexey Malahov, linux-mips, Andy Shevchenko, Ramil Zaripov,
Arnd Bergmann, Maxim Kaurkin
In-Reply-To: <20200529212226.GA2984630@bogus>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
On Fri, May 29, 2020 at 03:22:26PM -0600, Rob Herring wrote:
> On Fri, May 29, 2020 at 06:33:25PM +0100, Mark Brown wrote:
> > Please rebase. TBH I'd not noticed Rob's review so I just left it
> > waiting for that, there's such a huge backlog there it didn't occur to
> > me that it might've been reviewed.
> Hey, I'm down to about 10 patches now. I think I'll take the rest of the
> week off.
Ah, nice! Good to hear.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v7 01/20] dt-bindings: mtd: Document nand-ecc-placement
From: Rob Herring @ 2020-05-29 22:21 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Mark Rutland, devicetree, Boris Brezillon, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
In-Reply-To: <20200529002517.3546-2-miquel.raynal@bootlin.com>
On Fri, May 29, 2020 at 02:24:58AM +0200, Miquel Raynal wrote:
> This optional property defines where the ECC bytes are expected to be
> stored. No value defaults to an unknown location, while these
> locations can be explicitly set to OOB or interleaved depending if
> the ECC bytes are entirely stored in the OOB area or mixed with
> regular data in the main area (also sometimes referred as
> "syndrome").
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> .../devicetree/bindings/mtd/nand-controller.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> index d261b7096c69..4a0798247d2d 100644
> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> @@ -56,6 +56,16 @@ patternProperties:
> (Linux will handle the calculations). soft_bch is deprecated
> and should be replaced by soft and nand-ecc-algo.
>
> + nand-ecc-placement:
> + allOf:
You can drop using allOf now, but it still works as is.
Acked-by: Rob Herring <robh@kernel.org>
> + - $ref: /schemas/types.yaml#/definitions/string
> + - enum: [ oob, interleaved ]
> + description:
> + Location of the ECC bytes. This location is unknown by default
> + but can be explicitly set to "oob", if all ECC bytes are
> + known to be stored in the OOB area, or "interleaved" if ECC
> + bytes will be interleaved with regular data in the main area.
> +
> nand-ecc-algo:
> allOf:
> - $ref: /schemas/types.yaml#/definitions/string
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v12 3/4] dt-bindings: power: Add the bindings for the bq2515x family of chargers.
From: Rob Herring @ 2020-05-29 22:18 UTC (permalink / raw)
To: Ricardo Rivera-Matos
Cc: sre, pali, afd, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
In-Reply-To: <20200528225350.661-4-r-rivera-matos@ti.com>
On Thu, May 28, 2020 at 05:53:49PM -0500, Ricardo Rivera-Matos wrote:
> The BQ2515X family of devices are highly integrated battery management
> ICs that integrate the most common functions for wearable devices
> namely a charger, an output voltage rail, ADC for battery and system
> monitoring, and a push-button controller.
>
> Datasheets:
> http://www.ti.com/lit/ds/symlink/bq25150.pdf
> http://www.ti.com/lit/ds/symlink/bq25155.pdf
>
> Signed-off-by: Ricardo Rivera-Matos <r-rivera-matos@ti.com>
> ---
> .../bindings/power/supply/bq2515x.yaml | 91 +++++++++++++++++++
> 1 file changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/bq2515x.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/bq2515x.yaml b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
> new file mode 100644
> index 000000000000..19cb336d581e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/bq2515x.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/power/supply/bq2515x.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: TI bq2515x 500-mA Linear charger family
> +
> +maintainers:
> + - Dan Murphy <dmurphy@ti.com>
> + - Ricardo Rivera-Matos <r-rivera-matos@ti.com>
> +
> +description: |
> + The BQ2515x family is a highly integrated battery charge management IC that
> + integrates the most common functions for wearable devices, namely a charger,
> + an output voltage rail, ADC for battery and system monitoring, and
> + push-button controller.
> +
> + Specifications about the charger can be found at:
> + http://www.ti.com/lit/ds/symlink/bq25150.pdf
> + http://www.ti.com/lit/ds/symlink/bq25155.pdf
> +
> +properties:
> + compatible:
> + enum:
> + - ti,bq25150
> + - ti,bq25155
> +
> + reg:
> + maxItems: 1
> + description: I2C address of the charger.
> +
> + ac-detect-gpios:
> + description: |
> + GPIO used for connecting the bq2515x device PG (AC Detect)
> + pin.
> + maxItems: 1
> +
> + reset-gpios:
> + description: GPIO used for hardware reset.
> + maxItems: 1
> +
> + powerdown-gpios:
> + description: GPIO used for low power mode of IC.
> + maxItems: 1
> +
> + charge-enable-gpios:
> + description: GPIO used to turn on and off charging.
> + maxItems: 1
> +
> + input-current-limit-microamp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Maximum input current in micro Amps.
> + minimum: 50000
> + maximum: 500000
> +
> + monitored-battery:
> + $ref: battery.yaml#
This doesn't work. It's saying monitored-battery is a node containing
all the properties in battery.yaml.
> +
> +required:
> + - compatible
> + - reg
How is the battery optional?
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bat: battery {
> + compatible = "simple-battery";
> + constant-charge-current-max-microamp = <50000>;
> + precharge-current-microamp = <2500>;
> + constant-charge-voltage-max-microvolt = <4000000>;
> + };
> + #include <dt-bindings/gpio/gpio.h>
> + i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + bq25150: charger@6b {
> + compatible = "ti,bq25150";
> + reg = <0x6b>;
> + monitored-battery = <&bat>;
> + input-current-limit-microamp = <100000>;
> +
> + ac-detect-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
> + powerdown-gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>;
> + charge-enable-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + };
> + };
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v12 2/4] dt-bindings: power: Convert battery.txt to battery.yaml
From: Rob Herring @ 2020-05-29 22:16 UTC (permalink / raw)
To: Ricardo Rivera-Matos
Cc: sre, pali, afd, dmurphy, linux-pm, linux-kernel, devicetree,
sspatil
In-Reply-To: <20200528225350.661-3-r-rivera-matos@ti.com>
On Thu, May 28, 2020 at 05:53:48PM -0500, Ricardo Rivera-Matos wrote:
> From: Dan Murphy <dmurphy@ti.com>
>
> Convert the battery.txt file to yaml and fix up the examples.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../bindings/power/supply/battery.txt | 82 +---------
> .../bindings/power/supply/battery.yaml | 143 ++++++++++++++++++
> 2 files changed, 144 insertions(+), 81 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
> index 3049cf88bdcf..b9a81621ce59 100644
> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
> @@ -1,81 +1 @@
> -Battery Characteristics
> -
> -The devicetree battery node provides static battery characteristics.
> -In smart batteries, these are typically stored in non-volatile memory
> -on a fuel gauge chip. The battery node should be used where there is
> -no appropriate non-volatile memory, or it is unprogrammed/incorrect.
> -
> -Upstream dts files should not include battery nodes, unless the battery
> -represented cannot easily be replaced in the system by one of a
> -different type. This prevents unpredictable, potentially harmful,
> -behavior should a replacement that changes the battery type occur
> -without a corresponding update to the dtb.
> -
> -Required Properties:
> - - compatible: Must be "simple-battery"
> -
> -Optional Properties:
> - - voltage-min-design-microvolt: drained battery voltage
> - - voltage-max-design-microvolt: fully charged battery voltage
> - - energy-full-design-microwatt-hours: battery design energy
> - - charge-full-design-microamp-hours: battery design capacity
> - - precharge-current-microamp: current for pre-charge phase
> - - charge-term-current-microamp: current for charge termination phase
> - - constant-charge-current-max-microamp: maximum constant input current
> - - constant-charge-voltage-max-microvolt: maximum constant input voltage
> - - factory-internal-resistance-micro-ohms: battery factory internal resistance
> - - ocv-capacity-table-0: An array providing the open circuit voltage (OCV)
> - of the battery and corresponding battery capacity percent, which is used
> - to look up battery capacity according to current OCV value. And the open
> - circuit voltage unit is microvolt.
> - - ocv-capacity-table-1: Same as ocv-capacity-table-0
> - ......
> - - ocv-capacity-table-n: Same as ocv-capacity-table-0
> - - ocv-capacity-celsius: An array containing the temperature in degree Celsius,
> - for each of the battery capacity lookup table. The first temperature value
> - specifies the OCV table 0, and the second temperature value specifies the
> - OCV table 1, and so on.
> - - resistance-temp-table: An array providing the temperature in degree Celsius
> - and corresponding battery internal resistance percent, which is used to look
> - up the resistance percent according to current temperature to get a accurate
> - batterty internal resistance in different temperatures.
> -
> -Battery properties are named, where possible, for the corresponding
> -elements in enum power_supply_property, defined in
> -https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/power_supply.h
> -
> -Batteries must be referenced by chargers and/or fuel-gauges
> -using a phandle. The phandle's property should be named
> -"monitored-battery".
> -
> -Example:
> -
> - bat: battery {
> - compatible = "simple-battery";
> - voltage-min-design-microvolt = <3200000>;
> - voltage-max-design-microvolt = <4200000>;
> - energy-full-design-microwatt-hours = <5290000>;
> - charge-full-design-microamp-hours = <1430000>;
> - precharge-current-microamp = <256000>;
> - charge-term-current-microamp = <128000>;
> - constant-charge-current-max-microamp = <900000>;
> - constant-charge-voltage-max-microvolt = <4200000>;
> - factory-internal-resistance-micro-ohms = <250000>;
> - ocv-capacity-celsius = <(-10) 0 10>;
> - ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>, ...;
> - ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>, ...;
> - ocv-capacity-table-2 = <4250000 100>, <4200000 95>, <4185000 90>, ...;
> - resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
> - };
> -
> - charger: charger@11 {
> - ....
> - monitored-battery = <&bat>;
> - ...
> - };
> -
> - fuel_gauge: fuel-gauge@22 {
> - ....
> - monitored-battery = <&bat>;
> - ...
> - };
> +The contents of this file has been moved to battery.yaml
> diff --git a/Documentation/devicetree/bindings/power/supply/battery.yaml b/Documentation/devicetree/bindings/power/supply/battery.yaml
> new file mode 100644
> index 000000000000..f0b544a22219
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/battery.yaml
> @@ -0,0 +1,143 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/supply/battery.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Battery Characteristics
> +
> +maintainers:
> + - Sebastian Reichel <sre@kernel.org>
> +
> +description: |
> + The devicetree battery node provides static battery characteristics.
> + In smart batteries, these are typically stored in non-volatile memory
> + on a fuel gauge chip. The battery node should be used where there is
> + no appropriate non-volatile memory, or it is unprogrammed/incorrect.
> +
> + Upstream dts files should not include battery nodes, unless the battery
> + represented cannot easily be replaced in the system by one of a
> + different type. This prevents unpredictable, potentially harmful,
> + behavior should a replacement that changes the battery type occur
> + without a corresponding update to the dtb.
> +
> + Battery properties are named, where possible, for the corresponding elements
> + in enum power_supply_property, defined in include/linux/power_supply.h
> +
> + Batteries must be referenced by chargers and/or fuel-gauges using a phandle.
> + The phandle's property should be named "monitored-battery".
> +
> +properties:
> + compatible:
> + const: simple-battery
I suspect we'll need a battery.yaml and simple-battery.yaml schema if
these properties are used for other batteries. Not sure really, so fine
for now.
> +
> + voltage-min-design-microvolt:
> + $ref: /schemas/types.yaml#/definitions/uint32
Don't need types on many of these as standard units have a type already.
> + description: drained battery voltage
> +
> + voltage-max-design-microvolt:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: fully charged battery voltage
> +
> + energy-full-design-microwatt-hours:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: battery design energy
> +
> + charge-full-design-microamp-hours:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: battery design capacity
> +
> + precharge-current-microamp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: current for pre-charge phase
> +
> + charge-term-current-microamp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: current for charge termination phase
> +
> + constant-charge-current-max-microamp:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: maximum constant input current
> +
> + constant-charge-voltage-max-microvolt:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: maximum constant input voltage
> +
> + factory-internal-resistance-micro-ohms:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: battery factory internal resistance
> +
> + ocv-capacity-table-0:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description: |
> + An array providing the open circuit voltage (OCV)
> + of the battery and corresponding battery capacity percent, which is used
> + to look up battery capacity according to current OCV value. And the open
> + circuit voltage unit is microvolt.
> +
> + ocv-capacity-table-1:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description: Same as ocv-capacity-table-0
> +
> + ocv-capacity-table-n:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description: Same as ocv-capacity-table-0
Make this a pattern under patternProperties: '^ocv-capacity-table-[0-9]$'
Is 10 enough or maybe you need more.
maxItems: 100 ?? I asssume 1% granularity would be enough for everyone?
items:
items:
- description: open circuit voltage (OCV) in microvolts
- description: battery capacity percent
maximum: 100
> +
> + ocv-capacity-celsius:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array containing the temperature in degree Celsius,
> + for each of the battery capacity lookup table. The first temperature value
> + specifies the OCV table 0, and the second temperature value specifies the
> + OCV table 1, and so on.
> +
> + resistance-temp-table:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description: |
> + An array providing the temperature in degree Celsius
> + and corresponding battery internal resistance percent, which is used to
> + look up the resistance percent according to current temperature to get an
> + accurate batterty internal resistance in different temperatures.
Similar definition needed here.
> +
> + monitored-battery:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle to the battery node being monitored
As this is the battery node, this property doesn't belong here.
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + power {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + battery:battery {
> + compatible = "simple-battery";
> + voltage-min-design-microvolt = <3200000>;
> + voltage-max-design-microvolt = <4200000>;
> + energy-full-design-microwatt-hours = <5290000>;
> + charge-full-design-microamp-hours = <1430000>;
> + precharge-current-microamp = <256000>;
> + charge-term-current-microamp = <128000>;
> + constant-charge-current-max-microamp = <900000>;
> + constant-charge-voltage-max-microvolt = <4200000>;
> + factory-internal-resistance-micro-ohms = <250000>;
> + ocv-capacity-celsius = <(-10) 0 10>;
> + ocv-capacity-table-0 = <4185000 100>, <4113000 95>, <4066000 90>;
> + ocv-capacity-table-1 = <4200000 100>, <4185000 95>, <4113000 90>;
> + resistance-temp-table = <20 100>, <10 90>, <0 80>, <(-10) 60>;
> + };
> +
> + charger:charger@11 {
Drop unused labels.
> + reg = <0x11>;
> + monitored-battery = <&battery>;
> + };
> +
> + fuel_gauge:fuel-gauge@22 {
> + reg = <0x22>;
> + monitored-battery = <&battery>;
> + };
> + };
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH] i2c: add 'single-master' property to generic bindings
From: Rob Herring @ 2020-05-29 22:02 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, devicetree, Laine Jaakko EXT
In-Reply-To: <20200527113039.5380-1-wsa+renesas@sang-engineering.com>
On Wed, May 27, 2020 at 01:30:39PM +0200, Wolfram Sang wrote:
> It is useful to know if we are the only master on a given bus. Because
> this is a HW description of the bus, add it to the generic bindings.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: Laine Jaakko EXT <ext-jaakko.laine@vaisala.com>
> ---
>
> We added 'multi-master' back then because most busses are single-master
> and 'multi-master' was the exception. In hindsight, however, this was a
> bad choice because 'multi-master' should be the default, i.e. if you
> know nothing, you should assume there could be another master.
>
> So, we can't deduce that a missing 'multi-master' property automatically
> means 'single-master'. That's why we need this new property.
>
> I am a bit tempted to mark 'multi-master' as deprecated because the
> default should be multi-master. However, it might also be a bit more
> descriptive to let "no property" still mean "we don't know". I'd be
> thankful for more opinions here.
Could you just have different timeouts for clearing stalled bus. You
know quickly if 'single-master' is set, but have to wait longer if not?
Note that we need to add a bunch of these properties to dt-schema
i2c-controller.yaml. I hadn't done that because I want to dual license
in the process, but lots of folks have touched i2c.txt IIRC.
Reviewed-by: Rob Herring <robh@kernel.org>
> Thanks and happy hacking,
>
> Wolfram
>
> Documentation/devicetree/bindings/i2c/i2c.txt | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> index 819436b48fae..438ae123107e 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> @@ -70,7 +70,12 @@ wants to support one of the below features, it should adapt these bindings.
> - multi-master
> states that there is another master active on this bus. The OS can use
> this information to adapt power management to keep the arbitration awake
> - all the time, for example.
> + all the time, for example. Can not be combined with 'single-master'.
> +
> +- single-master
> + states that there is no other master active on this bus. The OS can use
> + this information to detect a stalled bus more reliably, for example.
> + Can not be combined with 'multi-master'.
>
> Required properties (per child device)
> --------------------------------------
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: chrome: Add cros-ec-typec mux props
From: Rob Herring @ 2020-05-29 21:54 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Prashant Malani, linux-kernel@vger.kernel.org, twawrzynczak,
Benson Leung,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Enric Balletbo i Serra, Guenter Roeck
In-Reply-To: <20200512134154.GC2085641@kuha.fi.intel.com>
On Tue, May 12, 2020 at 7:42 AM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> Hi guys,
>
> On Mon, May 11, 2020 at 01:46:35PM -0700, Prashant Malani wrote:
> > Hi Rob,
> >
> > Thank you for reviewing the patch. Kindly see my comments inline:
> >
> > On Mon, May 11, 2020 at 02:28:00PM -0500, Rob Herring wrote:
> > > On Wed, Apr 22, 2020 at 03:22:39PM -0700, Prashant Malani wrote:
> > > > Add properties for mode, orientation and USB data role switches for
> > > > Type C connectors. When available, these will allow the Type C connector
> > > > class port driver to configure the various switches according to USB PD
> > > > information (like orientation, alt mode etc.) provided by the Chrome OS
> > > > EC controller.
> > > >
> > > > Signed-off-by: Prashant Malani <pmalani@chromium.org>
> > > > ---
> > > > .../bindings/chrome/google,cros-ec-typec.yaml | 27 ++++++++++++++++++-
> > > > 1 file changed, 26 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> > > > index 6d7396ab8bee..b5814640aa32 100644
> > > > --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> > > > +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> > > > @@ -21,7 +21,21 @@ properties:
> > > > const: google,cros-ec-typec
> > > >
> > > > connector:
> > > > - $ref: /schemas/connector/usb-connector.yaml#
> > > > + allOf:
> > > > + - $ref: /schemas/connector/usb-connector.yaml#
> > > > + - type: object
> > > > + properties:
> > >
> > > These don't seem CrOS EC specific, so why document them as such.
> >
> > Are you referring to the "mode-switch", "orientation-switch" and
> > "usb-role-switch" properties? If so, then yes, they aren't Cros EC
> > specific. The Type C connector class framework requires the nodes to be
> > named like this, and the cros-ec-typec driver uses this framework, hence
> > the description here (the Type C connector class framework doesn't have
> > any bindings).
> >
> > Would it be better to add in the description string that Type Connector
> > class expects these switches to be named this way? :
> >
> > " Reference to a DT node for the USB Type C Multiplexer controlling the
> > data lines routing for this connector. This switch is assumed registered
> > with the Type C connector class framework, which requires it to be named
> > this way."
> > >
> > > > + mode-switch:
> > > > + description: Reference to a DT node for the USB Type C Multiplexer
> > > > + controlling the data lines routing for this connector.
> > >
> > > This is for alternate mode muxing I presume.
> >
> > Yes, that's right.
> > >
> > > We already have a mux-control binding. Why not use that here?
> >
> > Heikki might be able to offer more insight into why this is the case,
> > since the connector class framework seems to expect a phandle and for
> > the device driver to implement a "set" command. Heikki, would you happen to know?
>
> The mode-switch here would actually represent the "consumer" part in
> the mux-control bindings. So the mux-controls would describe the
> relationship between the "mode-switch" and the mux controller(s),
> while the mode-switch property describes the relationship between
> something like USB Type-C Port Manager (or this cros_ec function) and
> the "mux consumer".
The "USB Type-C Port Manager" is not just the parent node in your case?
Can you point me to what you expect your DT to look like showing the
mode switch node, the connector, the USB host(s), and the DP/HDMI
bridge/output?
Rob
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: pinctrl: Document 7211 compatible for brcm, bcm2835-gpio.txt
From: Rob Herring @ 2020-05-29 21:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Geert Uytterhoeven, Stefan Wahren, Scott Branden, Matti Vaittinen,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne, open list:PIN CONTROL SUBSYSTEM,
linux-kernel, Rob Herring, Linus Walleij, Ray Jui
In-Reply-To: <20200529191522.27938-2-f.fainelli@gmail.com>
On Fri, 29 May 2020 12:15:19 -0700, Florian Fainelli wrote:
> Document the brcm,bcm7211-gpio compatible string in the
> brcm,bcm2835-gpio.txt document.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH dt-schema] Fix interrupt controllers with interrupt-map
From: Rob Herring @ 2020-05-29 21:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAMuHMdU-FKoO+8cM2FOZRvENTuCEK02C=Si-bUiNCVrrp10qBA@mail.gmail.com>
On Fri, May 29, 2020 at 10:02 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Fri, May 29, 2020 at 5:54 PM Rob Herring <robh+dt@kernel.org> wrote:
> > On Thu, May 28, 2020 at 7:23 AM Geert Uytterhoeven
> > <geert+renesas@glider.be> wrote:
> > > When an interrupt controller has an "interrupt-map" property, an "is
> > > valid under each of" error is triggered.
> > >
> > > Fix this by allowing "interrupt-controller" and "interrupt-map" to
> > > coexist, in both the interrrupts meta-schema and the
> > > interrupt-controller schema.
> >
> > But both should not be present. If 'interrupt-controller' is present,
>
> Why not?
Well, maybe I'm wrong. If you have more than just transparent
remapping (i.e. mask/unmask/clear), then perhaps both are appropriate
because you want get the irq domain for the first irq parent.
> > the Linux irq parsing code will ignore 'interrupt-map'. Seems like
> > that's backwards, but this parsing code is older than dirt and we'd
> > probably break some 1990s machine changing it.
>
> That's fine. rza1_irqc_parse_map() parses the interrupt-map itself,
> to map from downstream to upstream interrupts.
You shouldn't really be parsing interrupt-map yourself. The code there
doesn't account for #address-cells which can be a factor for
interrupt-map. dtc is gaining some checks for 'interrupt-map', so
let's hope you have it right.
Rob
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: timer: renesas: cmt: Convert to json-schema
From: Rob Herring @ 2020-05-29 21:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Laurent Pinchart, linux-kernel,
devicetree, linux-renesas-soc
In-Reply-To: <20200505155127.4836-1-geert+renesas@glider.be>
On Tue, May 05, 2020 at 05:51:27PM +0200, Geert Uytterhoeven wrote:
> Convert the Renesas Compare Match Timer (CMT) Device Tree binding
> documentation to json-schema.
>
> Document missing properties.
> Update the example to match reality.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> - Add missing "additionalProperties: false",
> - Add Reviewed-by.
> ---
> .../devicetree/bindings/timer/renesas,cmt.txt | 110 -----------
> .../bindings/timer/renesas,cmt.yaml | 182 ++++++++++++++++++
> 2 files changed, 182 insertions(+), 110 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/renesas,cmt.txt
> create mode 100644 Documentation/devicetree/bindings/timer/renesas,cmt.yaml
Looks like this didn't get applied yet, so I've applied it.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: net: wireless: mt76: add power-limits node
From: Rob Herring @ 2020-05-29 21:26 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, devicetree
In-Reply-To: <20200529161929.24751-1-nbd@nbd.name>
On Fri, May 29, 2020 at 06:19:27PM +0200, Felix Fietkau wrote:
> This subnode can be used to set per-rate tx power limits either per
> country code / regdomain or globally.
> These limits are typically provided by the device manufacturers and are
> used to limit sideband emissions and stay within regulatory limits
How do other WiFi chips handle this? If this is added to DT, then it
should be common for all WiFi h/w.
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> .../bindings/net/wireless/mediatek,mt76.txt | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> index ab7e7a00e534..9d9ace0cfbf9 100644
> --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -36,6 +36,7 @@ Optional nodes:
> - led: Properties for a connected LED
> Optional properties:
> - led-sources: See Documentation/devicetree/bindings/leds/common.txt
> +- power-limits: contains per-regdomain/channel rate power limit subnodes
>
> &pcie {
> pcie0 {
> @@ -76,3 +77,49 @@ wmac: wmac@18000000 {
>
> power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
> };
> +
> +
> +Subnodes of power-limits:
> +
> +Properties:
> +- country: One or more country codes, as used by the cfg80211 regdomain code
> +- regdomain: "FCC", "ETSI" or "JP"
> +
> +If neither country, nor regdomain is specified, the power limits node is used
> +as a fallback when no other subnode matches.
> +
> +Subnodes txpower-2g, txpower-5g:
> +
> +Properties:
> +- channels: pairs of first and last channel number
> +- cck: 4 half-dBm per-rate power limit values
> +- ofdm: 8 half-dBm per-rate power limit values
> +- mcs:
> + sets of per-rate power limit values for 802.11n/802.11ac rates for
> + multiple channel bandwidth settings.
> + Each set starts with the number of channel bandwidth settings for
> + which the rate set applies, followed by either 8 (MT7603/MT7628) or
> + 10 (all other chips) power limit values.
> + The order of the channel bandwidth settings is: 20, 40, 80, 160 MHz.
> +
> +
> +power-limit example:
> +
> +power-limits {
> + r0 {
> + regdomain = "FCC";
> + txpower-5g {
> + r1 {
> + channels = <36 48>;
> + ofdm = <23 23 23 23 23 23 23 23>;
> + mcs = <1 23 23 23 23 23 23 23 23 23 23>,
> + <3 22 22 22 22 22 22 22 22 22 22>;
> + };
> + r2 {
> + channels = <100 181>;
> + ofdm = <14 14 14 14 14 14 14 14>;
> + mcs = <4 14 14 14 14 14 14 14 14 14 14>;
> + };
> + };
> + };
> +};
> --
> 2.24.0
>
^ permalink raw reply
* Re: [PATCH v5 02/11] dt-bindings: dma: dw: Add max burst transaction length property
From: Rob Herring @ 2020-05-29 21:24 UTC (permalink / raw)
To: Serge Semin
Cc: linux-mips, Serge Semin, dmaengine, Arnd Bergmann, Alexey Malahov,
Andy Shevchenko, devicetree, Rob Herring, Viresh Kumar,
linux-kernel, Thomas Bogendoerfer, Vinod Koul
In-Reply-To: <20200529144054.4251-3-Sergey.Semin@baikalelectronics.ru>
On Fri, 29 May 2020 17:40:45 +0300, Serge Semin wrote:
> This array property is used to indicate the maximum burst transaction
> length supported by each DMA channel.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Rearrange SoBs.
> - Move $ref to the root level of the properties. So do with the
> constraints.
> - Set default max-burst-len to 256 TR-WIDTH words.
>
> Changelog v3:
> - Add more details into the property description about what limitations
> snps,max-burst-len defines.
> ---
> .../bindings/dma/snps,dma-spear1340.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Rob Herring @ 2020-05-29 21:22 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Serge Semin, Ekaterina Skachko, Feng Tang,
devicetree, Thomas Bogendoerfer, Georgy Vlasov, Pavel Parkhomenko,
Alexey Kolotnikov, linux-spi, linux-kernel, Vadim Vlasov,
Alexey Malahov, linux-mips, Andy Shevchenko, Ramil Zaripov,
Arnd Bergmann, Maxim Kaurkin
In-Reply-To: <20200529173325.GR4610@sirena.org.uk>
On Fri, May 29, 2020 at 06:33:25PM +0100, Mark Brown wrote:
> On Fri, May 29, 2020 at 08:26:42PM +0300, Serge Semin wrote:
>
> > You must have missed the patch 16:
> > 0e8332aaf059 dt-bindings: spi: Convert DW SPI binding to DT schema
> > As you can see it has been acked by Rob. So you can also merge it into your
> > repo. Though It has to be rebased first due to the Dinh Nguyen patches
> > recently merged in. Do you want me to do the rebasing?
>
> Please rebase. TBH I'd not noticed Rob's review so I just left it
> waiting for that, there's such a huge backlog there it didn't occur to
> me that it might've been reviewed.
Hey, I'm down to about 10 patches now. I think I'll take the rest of the
week off.
Rob
^ permalink raw reply
* Re: [PATCH v3 6/6] dt-bindings: hwmon: Add bindings for ADM1266
From: Rob Herring @ 2020-05-29 21:17 UTC (permalink / raw)
To: alexandru.tachici; +Cc: linux-hwmon, linux-kernel, devicetree, linux
In-Reply-To: <20200529130506.73511-7-alexandru.tachici@analog.com>
On Fri, May 29, 2020 at 04:05:06PM +0300, alexandru.tachici@analog.com wrote:
> From: Alexandru Tachici <alexandru.tachici@analog.com>
>
> Add bindings for the Analog Devices ADM1266 sequencer.
>
> Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
> ---
> .../bindings/hwmon/adi,adm1266.yaml | 56 +++++++++++++++++++
> 1 file changed, 56 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
> new file mode 100644
> index 000000000000..76b62be48d56
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1266.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/adi,adm1266.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADM1266 Cascadable Super Sequencer with Margin
> + Control and Fault Recording
> +
> +maintainers:
> + - Alexandru Tachici <alexandru.tachici@analog.com>
> +
> +description: |
> + Analog Devices ADM1266 Cascadable Super Sequencer with Margin
> + Control and Fault Recording.
> + https://www.analog.com/media/en/technical-documentation/data-sheets/ADM1266.pdf
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adm1266
> +
> + reg:
> + description: |
> + I2C address of slave device.
> + items:
> + minimum: 0x40
> + maximum: 0x4F
> +
> + avcc-supply:
> + description: |
> + Phandle to the Avcc power supply.
> +
> + adi,master-adm1266:
> + description: |
> + Represents phandle of a master ADM1266 device cascaded through the IDB.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> +required:
> + - compatible
> + - reg
Add:
additionalProperties: false
> +
> +examples:
> + - |
> + i2c0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adm1266@40 {
> + compatible = "adi,adm1266";
> + reg = <0x40>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +...
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v3 02/25] dt-bindings: clock: Add a binding for the RPi Firmware clocks
From: Stephen Boyd @ 2020-05-29 21:17 UTC (permalink / raw)
To: Maxime Ripard, Nicolas Saenz Julienne
Cc: linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel, Dave Stevenson, Tim Gover, Phil Elwell,
Maxime Ripard, Michael Turquette, Rob Herring, linux-clk,
devicetree
In-Reply-To: <919e2f2f13583d4d53d0e95b81fc3fb8a7606107.1590594293.git-series.maxime@cerno.tech>
Quoting Maxime Ripard (2020-05-27 08:44:58)
> The firmware running on the RPi VideoCore can be used to discover and
> change the various clocks running in the BCM2711. Since devices will
> need to use them through the DT, let's add a pretty simple binding.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index cec540c052b6..b48ed875eb8e 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -22,6 +22,25 @@ properties:
> Phandle to the firmware device's Mailbox.
> (See: ../mailbox/mailbox.txt for more information)
>
> + clocks:
> + type: object
> +
> + properties:
> + compatible:
> + const: raspberrypi,firmware-clocks
> +
> + "#clock-cells":
> + const: 1
> + description: >
Just curious if this is the same as the | syntax? I haven't seen this
used before.
> + The argument is the ID of the clocks contained by the
> + firmware messages.
> +
^ permalink raw reply
* Re: [PATCH] dt-bindings: thermal: Convert qoriq to json-schema
From: Rob Herring @ 2020-05-29 21:16 UTC (permalink / raw)
To: Anson Huang
Cc: rui.zhang, daniel.lezcano, amit.kucheria, hongtao.jia, linux-pm,
devicetree, linux-kernel, Linux-imx
In-Reply-To: <1590737338-7318-1-git-send-email-Anson.Huang@nxp.com>
On Fri, May 29, 2020 at 03:28:58PM +0800, Anson Huang wrote:
> Convert the qoriq thermal binding to DT schema format using json-schema
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/thermal/qoriq-thermal.txt | 71 -------------
> .../devicetree/bindings/thermal/qoriq-thermal.yaml | 111 +++++++++++++++++++++
> 2 files changed, 111 insertions(+), 71 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.txt
> create mode 100644 Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> new file mode 100644
> index 0000000..bfbfa04
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml
> @@ -0,0 +1,111 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/qoriq-thermal.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Thermal Monitoring Unit (TMU) on Freescale QorIQ SoCs
> +
> +maintainers:
> + - Hongtao Jia <hongtao.jia@freescale.com>
> +
> +properties:
> + compatible:
> + description: |
> + The version of the device is determined by the TMU IP Block Revision
> + Register (IPBRR0) at offset 0x0BF8.
> + Table of correspondences between IPBRR0 values and example chips:
> + Value Device
> + ---------- -----
> + 0x01900102 T1040
> + enum:
> + - fsl,qoriq-tmu
> + - fsl,imx8mq-tmu
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + fsl,tmu-range:
> + $ref: '/schemas/types.yaml#/definitions/uint32-array'
> + description: |
> + The values to be programmed into TTRnCR, as specified by the SoC
> + reference manual. The first cell is TTR0CR, the second is TTR1CR, etc.
Is there a maximum number?
> +
> + fsl,tmu-calibration:
> + $ref: '/schemas/types.yaml#/definitions/uint32-array'
> + description: |
> + A list of cell pairs containing temperature calibration data, as
> + specified by the SoC reference manual. The first cell of each pair
> + is the value to be written to TTCFGR, and the second is the value
> + to be written to TSCFGR.
That's a uint32-matrix, not an array:
minItmes: ??
maxItems: ??
items:
items:
- description: value for TTCFGR
- description: value for TSCFGR
> +
> + little-endian:
> + description: |
> + boolean, if present, the TMU registers are little endian. If absent,
> + the default is big endian.
> + type: boolean
> +
> + clocks:
> + maxItems: 1
> +
> + "#thermal-sensor-cells":
> + const: 1
> + description: |
> + Number of cells required to uniquely identify the thermal sensors. This
> + is set to 1 for multiple sensors.
No need to redefine common properties.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - fsl,tmu-range
> + - fsl,tmu-calibration
> + - '#thermal-sensor-cells'
> +
> +examples:
> + - |
> + tmu@f0000 {
> + compatible = "fsl,qoriq-tmu";
> + reg = <0xf0000 0x1000>;
> + interrupts = <18 2 0 0>;
> + fsl,tmu-range = <0x000a0000 0x00090026 0x0008004a 0x0001006a>;
> + fsl,tmu-calibration = <0x00000000 0x00000025
> + 0x00000001 0x00000028
> + 0x00000002 0x0000002d
> + 0x00000003 0x00000031
> + 0x00000004 0x00000036
> + 0x00000005 0x0000003a
> + 0x00000006 0x00000040
> + 0x00000007 0x00000044
> + 0x00000008 0x0000004a
> + 0x00000009 0x0000004f
> + 0x0000000a 0x00000054
> +
> + 0x00010000 0x0000000d
> + 0x00010001 0x00000013
> + 0x00010002 0x00000019
> + 0x00010003 0x0000001f
> + 0x00010004 0x00000025
> + 0x00010005 0x0000002d
> + 0x00010006 0x00000033
> + 0x00010007 0x00000043
> + 0x00010008 0x0000004b
> + 0x00010009 0x00000053
> +
> + 0x00020000 0x00000010
> + 0x00020001 0x00000017
> + 0x00020002 0x0000001f
> + 0x00020003 0x00000029
> + 0x00020004 0x00000031
> + 0x00020005 0x0000003c
> + 0x00020006 0x00000042
> + 0x00020007 0x0000004d
> + 0x00020008 0x00000056
> +
> + 0x00030000 0x00000012
> + 0x00030001 0x0000001d>;
> + #thermal-sensor-cells = <1>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v13 3/7] dt-bindings: clock: Add documentation for X1830 bindings.
From: Stephen Boyd @ 2020-05-29 21:11 UTC (permalink / raw)
To: Rob Herring, Zhou Yanjie
Cc: mturquette, robh+dt, aric.pzqi, rick.tyliu, yanfei.li, zhenwenjin,
sernia.zhou, paul, dongsheng.qiu, devicetree, linux-clk,
linux-kernel
In-Reply-To: <20200529191431.GA2779176@bogus>
Quoting Rob Herring (2020-05-29 12:14:31)
>
> Acked-by: Rob Herring <robh@kernel.org>
Please apply to bindings tree Rob. The yaml conversion is in your tree.
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: Convert i.MX8QXP LPCG to json-schema
From: Rob Herring @ 2020-05-29 21:11 UTC (permalink / raw)
To: Anson Huang
Cc: s.hauer, linux-arm-kernel, mturquette, kernel, robh+dt, sboyd,
aisheng.dong, festevam, linux-clk, shawnguo, devicetree,
linux-kernel, Linux-imx
In-Reply-To: <1590733299-12051-1-git-send-email-Anson.Huang@nxp.com>
On Fri, 29 May 2020 14:21:39 +0800, Anson Huang wrote:
> Convert the i.MX8QXP LPCG binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> .../devicetree/bindings/clock/imx8qxp-lpcg.txt | 51 ---------------
> .../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 72 ++++++++++++++++++++++
> 2 files changed, 72 insertions(+), 51 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
> create mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2] usb/phy-generic: Add support for OTG VBUS supply control
From: Rob Herring @ 2020-05-29 21:08 UTC (permalink / raw)
To: Mike Looijmans; +Cc: linux-usb, gregkh, balbi, devicetree, linux-kernel
In-Reply-To: <20200529060045.25556-1-mike.looijmans@topic.nl>
On Fri, May 29, 2020 at 08:00:45AM +0200, Mike Looijmans wrote:
> This enables support for VBUS on boards where the power is supplied
> by a regulator. The regulator is enabled when the USB port enters
> HOST mode.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
> ---
> v2: Added missing "return 0;" in set_vbus method
>
> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 3 ++
> drivers/usb/phy/phy-generic.c | 46 ++++++++++++++++++-
> drivers/usb/phy/phy-generic.h | 2 +
> 3 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> index 4dc6a8ee3071..775a19fdb613 100644
> --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
> @@ -16,6 +16,9 @@ Optional properties:
>
> - vcc-supply: phandle to the regulator that provides power to the PHY.
>
> +- vbus-supply: phandle to the regulator that provides the VBUS power for when
> + the device is in HOST mode.
> +
I'm going to say no to expanding this binding...
First, there sure are a lot of controls on a NOP tranceiver.
Second, unless Vbus is supplying the PHY, then this belongs in a
connector node for which this is already supported.
> - reset-gpios: Should specify the GPIO for reset.
>
> - vbus-detect-gpio: should specify the GPIO detecting a VBus insertion
^ permalink raw reply
* Re: [PATCH v7] dt-bindings: spi: Convert DW SPI binding to DT schema
From: Mark Brown @ 2020-05-29 21:06 UTC (permalink / raw)
To: Serge Semin, Rob Herring
Cc: Thomas Bogendoerfer, Feng Tang, linux-kernel, Serge Semin,
linux-mips, Georgy Vlasov, Arnd Bergmann, linux-spi,
Ramil Zaripov, devicetree, Rob Herring, Alexey Malahov,
Andy Shevchenko
In-Reply-To: <20200529182544.9807-1-Sergey.Semin@baikalelectronics.ru>
On Fri, 29 May 2020 21:25:43 +0300, Serge Semin wrote:
> Modern device tree bindings are supposed to be created as YAML-files
> in accordance with dt-schema. This commit replaces two DW SPI legacy
> bare text bindings with YAML file. As before the bindings file states
> that the corresponding dts node is supposed to be compatible either
> with generic DW APB SSI controller or with Microsemi/Amazon/Renesas/Intel
> vendors-specific controllers, to have registers, interrupts and clocks
> properties. Though in case of Microsemi version of the controller
> there must be two registers resources specified. Properties like
> clock-names, reg-io-width, cs-gpio, num-cs, DMA and slave device
> sub-nodes are optional.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: Convert DW SPI binding to DT schema
commit: 164c05f03ffabe36564cb8959c1fad7c56f294dd
All 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
^ permalink raw reply
* Re: [PATCH 0/2] RZ/G1H enable sound support
From: Mark Brown @ 2020-05-29 21:05 UTC (permalink / raw)
To: Lad Prabhakar, Magnus Damm, Liam Girdwood, Rob Herring,
Geert Uytterhoeven
Cc: linux-kernel, Prabhakar, linux-renesas-soc, devicetree,
alsa-devel
In-Reply-To: <1590526904-13855-1-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Tue, 26 May 2020 22:01:42 +0100, Lad Prabhakar wrote:
> This patch series adds support for sound in R8A7742 SoC DT.
>
> Cheers,
> Prabhakar
>
> Lad Prabhakar (2):
> dt-bindings: ASoC: renesas,rsnd: Add r8a7742 support
> ARM: dts: r8a7742: Add audio support
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] dt-bindings: ASoC: renesas,rsnd: Add r8a7742 support
commit: b6f10d3f2e6dfccf58c54e81c8af586b66a80ce4
[2/2] ARM: dts: r8a7742: Add audio support
(no commit info)
All 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
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mips: Document two Loongson generic boards
From: Rob Herring @ 2020-05-29 21:04 UTC (permalink / raw)
To: Jiaxun Yang
Cc: maz, Thomas Bogendoerfer, Huacai Chen, linux-mips, devicetree,
linux-kernel
In-Reply-To: <20200529034338.1137776-2-jiaxun.yang@flygoat.com>
On Fri, May 29, 2020 at 11:43:18AM +0800, Jiaxun Yang wrote:
> Document loongson3-8core-ls7a and loongson3-r4-ls7a, with
> two boards LS7A PCH.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
> .../devicetree/bindings/mips/loongson/devices.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mips/loongson/devices.yaml b/Documentation/devicetree/bindings/mips/loongson/devices.yaml
> index 74ed4e397a78..6164b0fcb493 100644
> --- a/Documentation/devicetree/bindings/mips/loongson/devices.yaml
> +++ b/Documentation/devicetree/bindings/mips/loongson/devices.yaml
> @@ -24,4 +24,12 @@ properties:
> - description: Generic Loongson3 Octa Core + RS780E
> items:
> - const: loongson,loongson3-8core-rs780e
> +
> + - description: Generic Loongson3 Quad Core + LS7A
Quad or..
> + items:
> + - const: loongson,loongson3-8core-ls7a
8 core?
> +
> + - description: Generic Loongson3 Release 4 + LS7A
> + items:
> + - const: loongson,loongson3-r4-ls7a
> ...
> --
> 2.27.0.rc0
>
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: Add ch7322 media i2c device
From: Rob Herring @ 2020-05-29 21:02 UTC (permalink / raw)
To: Jeff Chase; +Cc: linux-media, mchehab, hverkuil-cisco, devicetree
In-Reply-To: <20200529030012.254592-2-jnchase@google.com>
On Thu, May 28, 2020 at 11:00:11PM -0400, Jeff Chase wrote:
> The ch7322 is a Chrontel CEC controller.
>
> Signed-off-by: Jeff Chase <jnchase@google.com>
> ---
> .../bindings/media/i2c/chrontel,ch7322.yaml | 65 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> MAINTAINERS | 7 ++
> 3 files changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
> new file mode 100644
> index 000000000000..d5706e08164c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: Chrontel HDMI-CEC Controller
> +
> +maintainers:
> + - Jeff Chase <jnchase@google.com>
> +
> +description: |-
Can drop the '|-' as you don't need any formatting.
> + The Chrontel CH7322 is a discrete HDMI-CEC controller. It is
> + programmable through I2C and drives a single CEC line.
> +
> +properties:
> + compatible:
> + const: chrontel,ch7322
> +
> + reg:
> + description: I2C device address
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + description: |-
> + Reference to the GPIO connected to the RESET pin, if any. This
> + pin is active-low.
How many? (maxItems: 1)
> +
> + standby-gpios:
How many?
> + description: |-
> + Reference to the GPIO connected to the OE pin, if any. When low
> + the device will respond to power status requests with "standby"
> + if in auto mode.
> +
> + # see ../cec.txt
> + hdmi-phandle:
> + description: phandle to the HDMI controller
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ch7322@75 {
> + compatible = "chrontel,ch7322";
> + reg = <0x75>;
> + interrupts = <47 IRQ_TYPE_EDGE_RISING>;
> + standby-gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
> + reset-gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> + hdmi-phandle = <&hdmi>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index d3891386d671..7794ffccd325 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -187,6 +187,8 @@ patternProperties:
> description: ChipOne
> "^chipspark,.*":
> description: ChipSPARK
> + "^chrontel,.*":
> + description: Chrontel, Inc.
> "^chrp,.*":
> description: Common Hardware Reference Platform
> "^chunghwa,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d633a131dcd7..34c6d30e61e5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4047,6 +4047,13 @@ F: drivers/power/supply/cros_usbpd-charger.c
> N: cros_ec
> N: cros-ec
>
> +CHRONTEL CH7322 CEC DRIVER
> +M: Jeff Chase <jnchase@google.com>
> +L: linux-media@vger.kernel.org
> +S: Maintained
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/chontel,ch7322.yaml
> +
> CIRRUS LOGIC AUDIO CODEC DRIVERS
> M: James Schulman <james.schulman@cirrus.com>
> M: David Rhodes <david.rhodes@cirrus.com>
> --
> 2.27.0.rc0.183.gde8f92d652-goog
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox