* 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
* Re: [PATCH net-next v4 1/4] dt-bindings: net: Add tx and rx internal delays
From: Rob Herring @ 2020-05-29 20:58 UTC (permalink / raw)
To: Dan Murphy
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David Miller,
netdev, linux-kernel@vger.kernel.org, devicetree
In-Reply-To: <b8a0b1e8-c7fb-d38b-5c43-c6c4116a3349@ti.com>
On Fri, May 29, 2020 at 1:24 PM Dan Murphy <dmurphy@ti.com> wrote:
>
> Rob
>
> On 5/29/20 1:25 PM, Rob Herring wrote:
> > On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
> >> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> >> capable devices.
> >>
> >> These properties are used when the phy-mode or phy-controller is set to
> >> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
> >> controller that the PHY will add the internal delay for the connection.
> >>
> >> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> >> ---
> >> .../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
> >> 1 file changed, 14 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> >> index ac471b60ed6a..70702a4ef5e8 100644
> >> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> >> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> >> @@ -143,6 +143,20 @@ properties:
> >> Specifies the PHY management type. If auto is set and fixed-link
> >> is not specified, it uses MDIO for management.
> >>
> >> + rx-internal-delay-ps:
> >> + $ref: /schemas/types.yaml#definitions/uint32
> >> + description: |
> >> + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
> >> + PHY's that have configurable RX internal delays. This property is only
> >> + used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
> > Isn't this a property of the phy (this is the controller schema)? Looks
> > like we have similar properties already and they go in phy nodes. Would
> > be good to have a standard property, but let's be clear where it goes.
> >
> > We need to add '-ps' as a standard unit suffix (in dt-schema) and then a
> > type is not needed here.
>
> This is a PHY specific property.
>
> I will move them.
>
> Dumb question but you can just point me to the manual about how and
> where to add the '-ps' to the dt-schema
Here[1], but looks like I already added it. I'd checked the old kernel
version (property-units.txt) which didn't have it.
Rob
[1] https://github.com/devicetree-org/dt-schema/blob/master/schemas/property-units.yaml#L48
^ permalink raw reply
* Re: [PATCH 3/3] hwrng: ba431-rng: add support for BA431 hwrng
From: Olivier Sobrie @ 2020-05-29 20:33 UTC (permalink / raw)
To: Rob Herring
Cc: Arnd Bergmann, Matt Mackall, Herbert Xu, Greg Kroah-Hartman,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, DTML,
linux-kernel@vger.kernel.org, Waleed Ziad, sebastien.rabou
In-Reply-To: <20200529171231.GA2581035@bogus>
On Fri, May 29, 2020 at 11:12:31AM -0600, Rob Herring wrote:
> On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> > On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> > <olivier.sobrie@silexinsight.com> wrote:
> > >
> > > Silex insight BA431 is an IP designed to generate random numbers that
> > > can be integrated in various FPGA.
> > > This driver adds support for it through the hwrng interface.
> > >
> > > This driver is used in Silex Insight Viper OEM boards.
> > >
> > > Signed-off-by: Olivier Sobrie <olivier.sobrie@silexinsight.com>
> > > Signed-off-by: Waleed Ziad <waleed94ziad@gmail.com>
> >
> > The driver looks good to me.
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > > drivers/char/hw_random/Kconfig | 10 ++
> > > drivers/char/hw_random/Makefile | 1 +
> > > drivers/char/hw_random/ba431-rng.c | 240 +++++++++++++++++++++++++++++
> >
> > I wonder if we should move drivers/char/hw_random to its own top-level drivers
> > subsystem outside of drivers/char. It seems to be growing steadily and is larger
> > than a lot of other subsystems with currently 34 drivers in there.
> >
> > Not your problem though.
> >
> > > + /* Wait until the state changed */
> > > + for (i = 0; i < BA431_RESET_READ_STATUS_RETRIES; ++i) {
> > > + state = ba431_trng_get_state(ba431);
> > > + if (state >= BA431_STATE_STARTUP)
> > > + break;
> > > +
> > > + udelay(BA431_RESET_READ_STATUS_INTERVAL);
> > > + }
> >
> > Looking for something to improve, I noticed that this loop can take over
> > a millisecond to time out, and it always runs in non-atomic context.
> > It may be better to use usleep_range() than udelay().
>
> Or better yet, use the register polling helpers.
Indeed, thanks for the suggestion.
I'll replace this loop by the readx_poll_timeout() macro.
Olivier
^ permalink raw reply
* Re: [PATCH 3/3] power: supply: max17040: Set rcomp value
From: Jonathan Bakker @ 2020-05-29 20:09 UTC (permalink / raw)
To: Sebastian Reichel; +Cc: linux-pm, linux-kernel, robh+dt, devicetree
In-Reply-To: <20200528170230.62c7jvmyjkhpoykj@earth.universe>
Hi Sebastian,
I'm sorry, I messed up my rebase on top of the low battery alert and it somehow
slipped through my pre-submit checklist.
Before resubmitting, do you want the rcomp changed in any manner (where the
datasheet doesn't specify if its the full 16 bits or only 8 bites for max17040
but does for the later max17043/max77836 where its only 8 bits)?
Thanks and sorry for the issues,
Jonathan
On 2020-05-28 10:02 a.m., Sebastian Reichel wrote:
> Hi,
>
> This patch does not even compile, how did you test it?
>
> -- Sebastian
>
> On Mon, May 04, 2020 at 03:13:00PM -0700, Jonathan Bakker wrote:
>> According to the datasheet (1), the rcomp parameter can
>> vary based on the typical operating temperature and the
>> battery chemistry. If provided, make sure we set it after
>> we reset the chip on boot.
>>
>> 1) https://datasheets.maximintegrated.com/en/ds/MAX17040-MAX17041.pdf
>>
>> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
>> ---
>> drivers/power/supply/max17040_battery.c | 33 +++++++++++++++++++++----
>> 1 file changed, 28 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
>> index 48aa44665e2f..f66e2fdc0a8a 100644
>> --- a/drivers/power/supply/max17040_battery.c
>> +++ b/drivers/power/supply/max17040_battery.c
>> @@ -10,6 +10,7 @@
>> #include <linux/init.h>
>> #include <linux/platform_device.h>
>> #include <linux/mutex.h>
>> +#include <linux/property.h>
>> #include <linux/err.h>
>> #include <linux/i2c.h>
>> #include <linux/delay.h>
>> @@ -31,6 +32,8 @@
>>
>> #define MAX17040_ATHD_MASK 0xFFC0
>> #define MAX17040_ATHD_DEFAULT_POWER_UP 4
>> +#define MAX17040_RCOMP_MASK 0xFF
>> +#define MAX17040_RCOMP_DEFAULT_POWER_UP 0x97
>>
>> struct max17040_chip {
>> struct i2c_client *client;
>> @@ -48,6 +51,8 @@ struct max17040_chip {
>> int status;
>> /* Low alert threshold from 32% to 1% of the State of Charge */
>> u32 low_soc_alert;
>> + /* Optimization for specific chemistries */
>> + u8 rcomp_value;
>> };
>>
>> static int max17040_get_property(struct power_supply *psy,
>> @@ -119,6 +124,20 @@ static int max17040_set_low_soc_alert(struct i2c_client *client, u32 level)
>> return ret;
>> }
>>
>> +static int max17040_set_rcomp(struct i2c_client *client, u32 val)
>> +{
>> + int ret;
>> + u16 data;
>> +
>> + data = max17040_read_reg(client, MAX17040_RCOMP);
>> + /* clear the rcomp val and set MSb 8 bits */
>> + data &= MAX17040_RCOMP_MASK;
>> + data |= val << 8;
>> + ret = max17040_write_reg(client, MAX17040_RCOMP, data);
>> +
>> + return ret;
>> +}
>> +
>> static void max17040_get_vcell(struct i2c_client *client)
>> {
>> struct max17040_chip *chip = i2c_get_clientdata(client);
>> @@ -190,8 +209,14 @@ static int max17040_get_of_data(struct max17040_chip *chip)
>> "maxim,alert-low-soc-level",
>> &chip->low_soc_alert);
>>
>> - if (chip->low_soc_alert <= 0 || chip->low_soc_alert >= 33)
>> + if (chip->low_soc_alert <= 0 || chip->low_soc_alert >= 33) {
>> + dev_err(&client->dev,
>> + "failed: low SOC alert OF data out of bounds\n");
>> return -EINVAL;
>> + }
>> +
>> + chip->rcomp_value = MAX17040_RCOMP_DEFAULT_POWER_UP;
>> + device_property_read_u8(dev, "maxim,rcomp-value", &chip->rcomp_value);
>>
>> return 0;
>> }
>> @@ -289,11 +314,8 @@ static int max17040_probe(struct i2c_client *client,
>> chip->client = client;
>> chip->pdata = client->dev.platform_data;
>> ret = max17040_get_of_data(chip);
>> - if (ret) {
>> - dev_err(&client->dev,
>> - "failed: low SOC alert OF data out of bounds\n");
>> + if (ret)
>> return ret;
>> - }
>>
>> i2c_set_clientdata(client, chip);
>> psy_cfg.drv_data = chip;
>> @@ -307,6 +329,7 @@ static int max17040_probe(struct i2c_client *client,
>>
>> max17040_reset(client);
>> max17040_get_version(client);
>> + max17040_set_rcomp(client, chip->rcomp_value);
>>
>> /* check interrupt */
>> if (client->irq && of_device_is_compatible(client->dev.of_node,
>> --
>> 2.20.1
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: timer: renesas,cmt: Document r8a7742 CMT support
From: Geert Uytterhoeven @ 2020-05-29 19:48 UTC (permalink / raw)
To: Rob Herring
Cc: Lad Prabhakar, Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <20200529191402.GA2771130@bogus>
Hi Rob,
On Fri, May 29, 2020 at 9:14 PM Rob Herring <robh@kernel.org> wrote:
> On Fri, May 29, 2020 at 02:53:02PM +0200, Geert Uytterhoeven wrote:
> > On Wed, May 27, 2020 at 11:19 PM Lad Prabhakar
> > <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > > Document SoC specific compatible strings for r8a7742. No driver change
> > > is needed as the fallback strings will activate the right code.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Please note this DT binding is under yamlization, cfr.
> > "[PATCH v2] dt-bindings: timer: renesas: cmt: Convert to json-schema"
> > (20200505155127.4836-1-geert+renesas@glider.be).
>
> Do I need to pick that one up? Doesn't look like it's been applied
> AFAICT.
Would be nice. Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply
* Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver
From: Grygorii Strashko @ 2020-05-29 19:39 UTC (permalink / raw)
To: santosh.shilimkar, Arnd Bergmann
Cc: Santosh Shilimkar, Tero Kristo, Rob Herring, Lokesh Vutla, DTML,
Dave Gerlach, Sekhar Nori, Linux ARM,
linux-kernel@vger.kernel.org, Nishanth Menon
In-Reply-To: <cb980673-d3ad-53b8-9351-196ff3f47c45@oracle.com>
On 29/05/2020 22:19, santosh.shilimkar@oracle.com wrote:
> On 5/29/20 11:34 AM, Arnd Bergmann wrote:
>> On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
>> <grygorii.strashko@ti.com> wrote:
>>> On 12/05/2020 15:34, Grygorii Strashko wrote:
>>
>>>> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
>>>> drivers/soc/ti/Kconfig | 10 ++
>>>> drivers/soc/ti/Makefile | 1 +
>>>> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
>>>> 4 files changed, 203 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>>>> create mode 100644 drivers/soc/ti/k3-socinfo.c
>>>>
>>>
>>> Any chances you can pick this up?
>>
>> I merged a version of this driver from Santosh's pull request into the
>> arm/drviers tree yesterday.
>>
>> Is there something missing?
>>
> Nope. I was going to reply on the thread but missed it.
Oh. Thanks. I've missed that it was already picked up.
Thanks again.
--
Best regards,
grygorii
^ permalink raw reply
* Re: [PATCH V3] dt-bindings: timer: Convert i.MX GPT to json-schema
From: Rob Herring @ 2020-05-29 19:36 UTC (permalink / raw)
To: Anson Huang
Cc: linux-arm-kernel, s.hauer, robh+dt, daniel.lezcano, shawnguo,
Linux-imx, festevam, kernel, devicetree, linux-kernel, tglx
In-Reply-To: <1590717882-20922-1-git-send-email-Anson.Huang@nxp.com>
On Fri, 29 May 2020 10:04:42 +0800, Anson Huang wrote:
> Convert the i.MX GPT binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V2:
> - in compatible properties, group all the ones with the same
> fallback to a single 'items' list using enum for the first entry.
> ---
> .../devicetree/bindings/timer/fsl,imxgpt.txt | 45 --------------
> .../devicetree/bindings/timer/fsl,imxgpt.yaml | 72 ++++++++++++++++++++++
> 2 files changed, 72 insertions(+), 45 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.txt
> create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:36 UTC (permalink / raw)
To: Rob Herring, Florian Fainelli
Cc: linux-kernel, Linus Walleij, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529193315.GA2807797@bogus>
On 5/29/20 12:33 PM, Rob Herring wrote:
> On Thu, May 28, 2020 at 12:21:10PM -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(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> index dfc67b90591c..5682b2010e50 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
>> @@ -16,7 +16,9 @@ Required properties:
>> second cell is used to specify optional parameters:
>> - bit 0 specifies polarity (0 for normal, 1 for inverted)
>> - interrupts : The interrupt outputs from the controller. One interrupt per
>> - individual bank followed by the "all banks" interrupt.
>> + individual bank followed by the "all banks" interrupt. For BCM7211, an
>> + additional set of per-bank interrupt line and an "all banks" wake-up
>> + interrupt may be specified.
>
> Is 'all banks' the name? Generally 'wakeup' is used for a wake up irq.
The firmware provided DTB on 7211 names the interrupts "gpio_%d" for the
standard interrupts, including the "all banks" which is then "gpio_3"
and the wake-up interrupts are named "gpio_%d_wake", and the all banks
wake-up is "gpio_3_wake".
--
Florian
^ 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