* Re: [PATCH v4 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Guenter Roeck @ 2026-06-16 16:03 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu, Conor Dooley
In-Reply-To: <20260612030304.5165-2-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:02AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add devicetree binding documentation for the Silergy SQ24860 eFuse.
>
> The device is a PMBus hardware monitoring device which reports voltage,
> current, power, and temperature telemetry. The board-specific IMON
> resistor value is described with silergy,rimon-micro-ohms.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Applied to hwmon-next (after dropping the extra blank line above).
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 2/3] hwmon: pmbus: Add support for Silergy SQ24860
From: Guenter Roeck @ 2026-06-16 16:04 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260612030304.5165-3-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:03AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add PMBus hwmon support for the Silergy SQ24860 eFuse.
>
> The driver reports input voltage, output voltage, auxiliary voltage,
> input current, input power, and temperature. It also exposes peak,
> average, and minimum history attributes, sample count configuration,
> and maps the manufacturer-specific VIREF register to the generic input
> over-current fault limit attribute.
>
> The IMON resistor value is read from the silergy,rimon-micro-ohms device
> property and used to configure the input current calibration gain.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 3/3] hwmon: Add documentation for SQ24860
From: Guenter Roeck @ 2026-06-16 16:05 UTC (permalink / raw)
To: Ziming Zhu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260612030304.5165-4-zmzhu0630@163.com>
On Fri, Jun 12, 2026 at 11:03:04AM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Document the supported sysfs attributes for the Silergy SQ24860 PMBus
> hwmon driver.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Guenter Roeck @ 2026-06-16 16:06 UTC (permalink / raw)
To: Potin Lai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Zev Weiss,
linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v3-1-decb4f5b0b77@gmail.com>
On Mon, Jun 15, 2026 at 05:49:16PM +0800, Potin Lai wrote:
> Add a 'ti,current-range' string property to configure the device's Current
> Limit (CL) behavior to "high" or "low" via the register, overriding the
> physical CL pin setting.
>
> This configuration is supported on LM25066, LM5064, LM5066, and LM5066i.
> LM25056 is excluded because it does not support configuring the current
> limit via the DEVICE_SETUP register (bit 2 of DEVICE_SETUP is reserved).
>
> The values "low" and "high" map to the respective low/high threshold
> voltages of the chips:
> - LM25066: low = 25 mV, high = 46 mV
> - LM5064, LM5066, LM5066i: low = 26 mV, high = 50 mV
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Conor Dooley @ 2026-06-16 16:07 UTC (permalink / raw)
To: David Lechner (TI)
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260615-iio-adc-ti-ads122c14-v1-1-e6bdadf7cb2b@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 9413 bytes --]
On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
> Add new bindings for ti,ads122c14 and similar devices.
>
> This is an ADC that is primarily intended for use with temperature
> sensors. There are a few unusual properties because of this. In
> particular, the reference voltage source and current output requirements
> can be different for each measurement, so these are included in the
> channel bindings.
>
> The REFP/REFN reference voltage is usually just connected to a resistor
> that is being driven by the ADC's current outputs, so there is special
> property for this case rather than requiring a regulator to be defined
> to represent that.
>
> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
> have preferred an enum of strings).
>
> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> ---
> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
> MAINTAINERS | 7 +
> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
> 3 files changed, 242 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> new file mode 100644
> index 000000000000..dc7f37cad772
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> @@ -0,0 +1,224 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments' ADS112C14 and similar ADC chips
> +
> +description: |
> + Supports the following Texas Instruments' ADC chips:
> + - ADS112C14 (16-bit)
> + - ADS122C14 (24-bit)
> +
> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
> +
> + These chips are primarily designed for use with temperature sensors such as
> + RTDs and thermocouples. The channel bindings reflect this in that each channel
> + represents the conditions required to make a measurement rather than strictly
> + just the physical input channels.
> +
> +maintainers:
> + - David Lechner <dlechner@baylibre.com>
> +
> +unevaluatedProperties: false
Weird positioning of this.
> +
> +properties:
> + compatible:
> + enum:
> + - ti,ads112c14
> + - ti,ads122c14
> +
> + reg:
> + items:
> + - minimum: 0x40
> + maximum: 0x47
> +
> + clocks:
> + maxItems: 1
> + description: Optional external clock connected to GPIO3 pin.
> +
> + avdd-supply: true
> + dvdd-supply: true
> +
> + refp-supply: true
> + refn-supply: true
> +
> + refp-refn-resistor-ohms:
Missing prefix here and elsewhere.
> + description:
> + The resistance of the external resistor between REFP and REFN when using
> + resistor bridge driven by current outputs for RTD measurements.
> +
> + interrupts:
> + minItems: 1
> + items:
> + - description: FAULT interrupt (GPIO2 pin)
> + - description: DRDY interrupt (GPIO3 pin)
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + enum: [fault, drdy]
> +
> + gpio-controller: true
> + '#gpio-cells':
> + const: 2
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + ^channel@[0-7]$:
> + $ref: adc.yaml
> +
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
> +
> + single-channel:
> + maximum: 7
> +
> + diff-channels:
> + items:
> + maximum: 7
> +
> + bipolar:
> + description:
> + Set this flag if the differential input can be negative.
> +
> + excitation-channels:
(here)
> + description: AINx pins used as current output.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 2
> + items:
> + maximum: 7
> +
> + excitation-current-microamp:
(here)
> + description: The current output of the excitation channels in microamps.
> + minimum: 1
> + maximum: 1000
> +
> + current-chopping:
(and here)
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + If provided, the two excitation channels are to be used with current
> + chopping enabled.
> +
> + ti,vref-source:
> + description: |
> + Indicates the source for the reference voltage for this channel.
> + 0 - Internal 2.5V reference
> + 1 - Internal 1.25V reference
> + 2 - External reference (REFP-REFN)
> + 3 - AVDD as reference
My usual complaint here about things you have to make macros for, could
these just be strings from the get-go?
> +
> + For convenience, macros for these values are available in
> + dt-bindings/iio/adc/ti,ads112c14.h.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 3
> + default: 0
> +
> + dependencies:
> + excitation-channels: [ excitation-current-microamp ]
> + excitation-current-microamp: [ excitation-channels ]
> + current-chopping: [ excitation-channels ]
> +
> + oneOf:
> + - required: [ single-channel ]
> + - required: [ diff-channels ]
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - dvdd-supply
> +
> +dependencies:
> + refn-supply: [ refp-supply ]
> +
> +allOf:
> + - oneOf:
"allOf: - oneOf:" is equivalent to just writing "oneOf:"
pw-bot: changes-requested
Thanks,
Conor.
> + - required: [ refp-supply ]
> + - required: [ refp-refn-resistor-ohms ]
> + - properties:
> + refp-supply: false
> + refn-supply: false
> + refp-refn-resistor-ohms: false
> +
> +examples:
> + - |
> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@40 {
> + compatible = "ti,ads112c14";
> + reg = <0x40>;
> +
> + avdd-supply = <&avdd>;
> + dvdd-supply = <&dvdd>;
> +
> + /* 3-Wire RTD: Two IDACs, One Measurement (AIN1-AIN2) */
> +
> + refp-refn-resistor-ohms = <500>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + diff-channels = <1>, <2>;
> + excitation-channels = <0>, <3>;
> + excitation-current-microamp = <500>;
> + current-chopping;
> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> + label = "rtd";
> + };
> + };
> + };
> + - |
> + #include <dt-bindings/iio/adc/ti,ads112c14.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@40 {
> + compatible = "ti,ads112c14";
> + reg = <0x40>;
> +
> + avdd-supply = <&avdd>;
> + dvdd-supply = <&dvdd>;
> +
> + /* Resistive Bridge Measurement With a Thermistor for Temperature Compensation*/
> +
> + refp-supply = <&avdd>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + diff-channels = <6>, <7>;
> + bipolar;
> + ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> + label = "bridge";
> + };
> +
> + channel@1 {
> + reg = <1>;
> + diff-channels = <1>, <2>;
> + ti,vref-source = <ADS112C14_VREF_SOURCE_INTERNAL_2_5V>;
> + label = "thermistor";
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f1caa6e5198b..9ce7c61b0c14 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -26911,6 +26911,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml
> F: drivers/iio/adc/ti-ads1119.c
>
> +TI ADS112C14 ADC DRIVER
> +M: David Lechner <dlechner@baylibre.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
> +F: include/dt-bindings/iio/adc/ti,ads112c14.h
> +
> TI ADS1018 ADC DRIVER
> M: Kurt Borja <kuurtb@gmail.com>
> L: linux-iio@vger.kernel.org
> diff --git a/include/dt-bindings/iio/adc/ti,ads112c14.h b/include/dt-bindings/iio/adc/ti,ads112c14.h
> new file mode 100644
> index 000000000000..96906642fe41
> --- /dev/null
> +++ b/include/dt-bindings/iio/adc/ti,ads112c14.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_TI_ADS112C14_H
> +#define _DT_BINDINGS_TI_ADS112C14_H
> +
> +#define ADS112C14_VREF_SOURCE_INTERNAL_2_5V 0
> +#define ADS112C14_VREF_SOURCE_INTERNAL_1_25V 1
> +#define ADS112C14_VREF_SOURCE_EXTERNAL 2
> +#define ADS112C14_VREF_SOURCE_AVDD 3
> +
> +#endif /* _DT_BINDINGS_TI_ADS112C14_H */
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: (pmbus/lm25066) add current limit configuration support
From: Guenter Roeck @ 2026-06-16 16:07 UTC (permalink / raw)
To: Potin Lai
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Zev Weiss,
linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v3-2-decb4f5b0b77@gmail.com>
On Mon, Jun 15, 2026 at 05:49:17PM +0800, Potin Lai wrote:
> Add support for the 'ti,current-range' devicetree property to configure
> the current limit via the DEVICE_SETUP (0xD9) register, overriding the
> physical CL pin setting.
>
> This configuration is supported on all chips in this driver (LM25066,
> LM5064, LM5066, LM5066i) except LM25056.
>
> The property values "low" and "high" map to:
> - LM25066: low = 25 mV, high = 46 mV
> - LM5064, LM5066, LM5066i: low = 26 mV, high = 50 mV
>
> The Bit 4 mapping to High/Low current limit is handled dynamically on
> probe because it is swapped for LM25066 compared to the other supported
> chips.
>
> Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Applied to hwmon-next.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v9 1/3] dt-bindings: timer: mips,p8700-gcru
From: sashiko-bot @ 2026-06-16 16:08 UTC (permalink / raw)
To: Aleksa Paunovic via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260616-riscv-time-mmio-v9-1-03af7bc8f2d8@htecgroup.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Usage of deprecated vendor prefix 'mips,' for a new compatible string.
--
commit 26c5e0f809bd1633d85e1be068047d23439d144d
Author: Aleksa Paunovic <aleksa.paunovic@htecgroup.com>
dt-bindings: timer: mips,p8700-gcru
Add dt-bindings for the GCR.U memory mapped timer device for RISC-V platforms.
The GCR.U memory region contains shadow copies of the RISC-V mtime register
and the hrtime Global Configuration Register.
> diff --git a/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
> new file mode 100644
> index 0000000000000..e6f25e769f461
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/mips,p8700-gcru.yaml
> @@ -0,0 +1,38 @@
[ ... ]
> +properties:
> + compatible:
> + const: mips,p8700-gcru
[Severity: Low]
Is the mips, vendor prefix deprecated for new device tree bindings?
Looking at Documentation/devicetree/bindings/vendor-prefixes.yaml, the mips
prefix is explicitly marked as deprecated, with recommendations to use mti
or img instead. If this prefix is intended to be reclaimed for new hardware,
does it first need to be formally undeprecated in the vendor prefixes list?
[ ... ]
> +examples:
> + - |
> + timer@1617f050 {
> + compatible = "mips,p8700-gcru";
[Severity: Low]
This example similarly reinforces the use of the potentially deprecated mips,
vendor prefix. Should this be updated to use mti,img, or another approved
vendor prefix to align with subsystem conventions?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-riscv-time-mmio-v9-0-03af7bc8f2d8@htecgroup.com?part=1
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Conor Dooley @ 2026-06-16 16:11 UTC (permalink / raw)
To: Amit Barzilai
Cc: robh, krzk+dt, conor+dt, javierm, devicetree, dri-devel,
linux-kernel, airlied, maarten.lankhorst, mripard, simona,
tzimmermann
In-Reply-To: <20260615175620.88828-1-amit.barzilai22@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
On Mon, Jun 15, 2026 at 08:56:20PM +0300, Amit Barzilai wrote:
> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
> RGB OLED display controller driven over a 4-wire SPI bus. The binding
> builds on the shared solomon,ssd-common.yaml properties already used by
> the other Solomon display controllers.
>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
> ---
> Changes since v1:
> - Drop solomon,width / solomon,height: both are deducible from the
> compatible and are already declared (as optional) by the referenced
> solomon,ssd-common.yaml, so a local override is unnecessary.
> - Drop the rotation property: it has no consumer (rotation is being removed from the driver).
> - Use dt-bindings/gpio/gpio.h flag defines in the example
> (reset-gpios active-low, dc-gpios active-high).
The user for this appears to be in staging. As far as I understand, the
policy is that we only add bindings for staging things when they move
out of staging.
Sure, this is straightforward but why should an exception be made here?
Are you working on moving this out of staging?
Cheers,
Conor.
>
> .../bindings/display/solomon,ssd1351.yaml | 41 +++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
> new file mode 100644
> index 000000000000..39622d74a41d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/solomon,ssd1351.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Solomon SSD1351 OLED Display Controller
> +
> +maintainers:
> + - Amit Barzilai <amit.barzilai22@gmail.com>
> +
> +allOf:
> + - $ref: solomon,ssd-common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - solomon,ssd1351
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + oled@0 {
> + compatible = "solomon,ssd1351";
> + reg = <0x0>;
> + reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>;
> + dc-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
> + spi-max-frequency = <10000000>;
> + };
> + };
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 4/9] net: stmmac: qcom-ethqos: add per-platform NOC clock voting
From: Mohd Ayaan Anwar @ 2026-06-16 16:17 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <45d7faac-7c0f-4f89-808e-06129e8420e4@oss.qualcomm.com>
Hi Konrad,
On Mon, Jun 15, 2026 at 02:13:05PM +0200, Konrad Dybcio wrote:
> On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
> > Some SoCs gate the EMAC's path to the System NOC behind dedicated clocks
> > that must be enabled before the DMA can reach memory. Add
> > ethqos_noc_clk_cfg and the corresponding fields in the driver-data and
> > runtime structs so each compatible can declare its own set with per-clock
> > rates. The clocks are acquired during probe and enabled/disabled
> > alongside the existing link clock in ethqos_clks_config().
>
> Sounds like we should use an OPP table instead, we can't just do
> set_rate() on qcom, as that will not propagate the required perf
> state to the clock controller's supplier power domain (i.e. VDDCX)
>
Understood, I will test this out for v2.
Ayaan
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Javier Martinez Canillas @ 2026-06-16 16:27 UTC (permalink / raw)
To: Conor Dooley, Amit Barzilai
Cc: robh, krzk+dt, conor+dt, devicetree, dri-devel, linux-kernel,
airlied, maarten.lankhorst, mripard, simona, tzimmermann
In-Reply-To: <20260616-nautical-obstinate-a92fd80ef483@spud>
Conor Dooley <conor@kernel.org> writes:
Hello Conor,
> On Mon, Jun 15, 2026 at 08:56:20PM +0300, Amit Barzilai wrote:
>> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
>> RGB OLED display controller driven over a 4-wire SPI bus. The binding
>> builds on the shared solomon,ssd-common.yaml properties already used by
>> the other Solomon display controllers.
>>
>> Assisted-by: Claude:claude-opus-4-8
>> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
>> ---
>> Changes since v1:
>> - Drop solomon,width / solomon,height: both are deducible from the
>> compatible and are already declared (as optional) by the referenced
>> solomon,ssd-common.yaml, so a local override is unnecessary.
>> - Drop the rotation property: it has no consumer (rotation is being removed from the driver).
>> - Use dt-bindings/gpio/gpio.h flag defines in the example
>> (reset-gpios active-low, dc-gpios active-high).
>
> The user for this appears to be in staging. As far as I understand, the
> policy is that we only add bindings for staging things when they move
> out of staging.
> Sure, this is straightforward but why should an exception be made here?
> Are you working on moving this out of staging?
>
This DT binding was part of a series to add support for "solomon,ssd1351"
to drivers/gpu/drm/solomon/ DRM driver. Amit only sent a v2 of the binding
schema because he had some questions about the driver:
https://lore.kernel.org/dri-devel/87cxxqzwxn.fsf@ocarina.mail-host-address-is-not-set/
But yes, I agree that it would had been better for him to post this as a
part of v2 (and I still expect him to do it), otherwise it is confusing.
Specially since as you pointed out, there is an existing fbdev driver for
the same device in staging.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Mohd Ayaan Anwar @ 2026-06-16 16:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <82705420-771d-41bf-a4d9-ed94dff86ff0@lunn.ch>
On Mon, Jun 15, 2026 at 06:48:55PM +0200, Andrew Lunn wrote:
> > > I'm curious how this works at the moment? Do no boards make use of
> > > RGMII ID? Are all current boards broken?
> >
> > Searching through the DTS, I found that we have two boards using "rgmii"
> > (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
> > "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
>
> So this causes problems. We cannot break existing boards, yet it would
> be good to fix the current broken behaviour.
I am trying to track down the sa8155-adp and sa8540p-ride boards. The
EMAC on QCS404 is extremely similar to QCS615 Ride [0], and I got that
board to work with this series (with RGMII ID mode). So I am fairly
confident that QCS404 would not break (if its even booting up with the
upstream kernel currently). Also, I think we could change the phy-mode
for QCS404 to "rgmii-id" from "rgmii" if these fixes go in.
> It could be the best way forward is that you issue a warning when
> "rgmii" is found and pass rgmii-id to the PHY. And you also change the
> two boards to use rgmii-id. Lets think about the rgmii-txid case once
> we better understand it.
>
As Konrad mentioned, it would be great to know if we can test out these
boards. Looking at the different versions of the ETHQOS programming
guide, stopping MAC side delay should be as simple as what we are doing
in this commit. But whether the two boards work directly with the
default PHY delays is unknown.
Ayaan
[0] The proposed RGMII fixes would help enable ethernet on QCS615 Ride
as well. I see that the original series had a lot of issues:
https://lore.kernel.org/all/20250121-dts_qcs615-v3-0-fa4496950d8a@quicinc.com/
^ permalink raw reply
* Re: [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Mohd Ayaan Anwar @ 2026-06-16 16:50 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <2cb658f3-f564-4396-884d-d025eaa674a1@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 11:50:26AM +0200, Konrad Dybcio wrote:
> On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
>
> > +&tlmm {
> > + ethernet0_defaults: ethernet0-defaults-state {
>
> s/defaults/default
>
> Please move this definition to shikra.dtsi
>
The CQM and CQS variants have identical GPIO mapping but the IQS is
different. So should I keep this in shikra.dtsi and overwrite for IQS in
shikra-iqs-evk.dts?
> > +
> > + emac0_phy_en_hog: emac0-phy-en-hog {
> > + gpio-hog;
> > + gpios = <149 GPIO_ACTIVE_HIGH>;
> > + output-high;
> > + line-name = "emac0-phy-en";
> > + };
>
> This looks like a hack - what does this pin actually do?
>
The power supply to both PHYs on Shikra is gated by a GPIO pin. I am
unsure whether they should be modelled as a fixed, enable-on-boot
regulator or just like this. They need to be powered on early so that
MDIO can detect them.
Thank you for the review. I will fix the stylistic issues in v2.
Ayaan
^ permalink raw reply
* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: Kurt Borja @ 2026-06-16 17:26 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <d3270250-ae18-4c0f-a0fe-e0fdabfce046@baylibre.com>
On Tue Jun 16, 2026 at 10:21 AM -05, David Lechner wrote:
> On 6/15/26 7:18 PM, Kurt Borja wrote:
>> Hi David,
>>
>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
>>> This adds support for TI ADS112C14 and ADS122C14 ADC chips.
>>>
>>> The closest thing we've seen to this in the kernel already is ads124s08.
>>> However, that has a completely different register map and the DT
>>> bindings are incomplete and the driver is extremely basic. So I've just
>>> started from scratch here.
>>>
>>> We've also had a similar submission recently for ADS1220 [1]. That chip
>>> is in a similar situation to ads124s08 in that it has a different
>>> register map (but the submitted DT bindings are better than the ones for
>>> ads124s08, even if still a bit incomplete). And literally as I was
>>> writing the previous sentence, another series [2] was sent for yet
>>> another similar family of chips (ADS1262). That one is even more complex
>>> in the feature set than the ones I am working on. I was going to polish
>>> up the driver a bit more before submitting it, but now it seems more
>>> urgent to coordinate with the other two series to align on how we would
>>> like to handle all of these.
>>>
>>> [1]: https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>>> [2]: https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
>>>
>>> All of these chips have in common that they are designed for use with
>>> RTDs and thermocouples and so they look very similar to each other in
>>> terms of wiring and feature set, even if the register maps are
>>> different. They are in the gray area where we could either keep them
>>> separate because they are just different enough, or we could do like
>>> we've done before with ad_sigma_delta and have a bit of an abstraction
>>> layer for the register differences and otherwise try to share as much
>>> code as possible. Normally, I would lean towards keeping them separate,
>>> but in this case, I'm considering trying to share code because the
>>> devicetree bindings for the inputs is complex and is going to be mostly
>>> the same across all of these chips.
>>
>> The channel configuration is indeed very similar for the three chips.
>> All three have IDAC, BOC and VREF configurations.
>
> Hmm... I forgot to include the burnout current in the DT bindings. Following
> the channel = "conditions for measurement" pattern that I have set out here
> I guess that would mean that we would need to have the same inputs twice
> when using the burnout. One "channel" would be the one used to do a "precision"
> measurement and the other would be the one to do open/short circuit detection.
>
>
> i2c {
> #address-cells = <1>;
> #size-cells = <0>;
>
> adc@40 {
> compatible = "ti,ads112c14";
> reg = <0x40>;
>
> avdd-supply = <&avdd>;
> dvdd-supply = <&dvdd>;
>
> refp-supply = <&avdd>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> channel@0 {
> reg = <0>;
> diff-channels = <1>, <2>;
> excitation-channels = <0>, <3>;
> excitation-current-microamp = <500>;
> current-chopping;
> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> label = "rtd-precision";
> };
>
> channel@1 {
> reg = <0>;
> diff-channels = <1>, <2>;
> excitation-channels = <0>, <3>;
> excitation-current-microamp = <500>;
> burnout-current-nanoamp = <1000>;
> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> label = "rtd-diagnostic";
> };
This would mean we wouldn't be able to use iio_chan_spec .channel and
.channel2 to describe inputs because of duplicate sysfs attributes, no?
> };
> };
>
>>
>>>
>>> If we decide to go the route of sharing code, we could still merge this
>>> series as-is and then do the refactoring to add the abstraction layer in
>>> a follow-up series that also adds support for the first of the other
>>> chips.
>>
>> Do you have a proposal of how such an abstraction would look like? I do
>> like the idea of abstracting the firmware parsing, scales and shared
>> calculations.
>
> As mentioned, it would look a bit like the ad_sigma_delta ADC driver.
> Basically, each chip (family with same registers) would still have it's
> own driver that include the chip-specific const info structs. In this
> case, these would also include function pointers for all of the functions
> that need to access registers. And there will be lots of supports_... bool
> flags for the shared code to use.
>
>>
>>>
>>> This series includes just basic support for reading single measurements
>>> from the ADC and gain selection via the scale attribute. I plan to
>>> follow this up with additional series to add support for buffered reads,
>>> filtering/oversampling configuration, event support, gpio controller
>>> support and perhaps a few other things that are slipping my mind right
>>> now.
>>>
>>> The most interesting part about this (that I alluded to above) is the
>>> way channels are handled. These are multipling ADCs with differential
>>> and single-ended inputs. But what sets them apart from other similar
>>> chips is that since they are designed for use with RTDs, there can also
>>> be a current output required to excite the RTD and this current output
>>> might be different for different channels. So the way I conceptualized
>>> the channels is that the devicetree specifies the conditions needed
>>> to take a particular measurement rather than being purely a physical
>>> channel.
>>>
>>> This makes things more flexible, but does make the driver a bit more
>>> complex. For example, knowing when the current output needs to be
>>> enabled or disabled. For now, I have chosen a lazy-enable where they
>>> are not turned on until the first measurement is taken that requires
>>> them, but then they stay on until another measurement is taken that
>>> doesn't require them. This can lead to some oddness with the diagnostic
>>> channels that may be measuring something that indirectly requires the
>>> current output (i.e. the external reference voltage when it is connected
>>> to a resistor rather than a power supply). This means you need to take
>>> a measurement that requires the current output to be enabled before the
>>> diagnostic channels will give accurate readings.
>>
>> This is the same approach I took around the BOC, it feels kinda hacky
>> but it makes sense. Just an idea I thought about just now: What if we
>> have an additional write-only "_enable" sysfs attribute for these
>> channels?
>
> I would not want to make a write-only attribute, we always want to be
> able to read back what the current state is.
Yeah, I don't know why I said WO. Reading would be fine too.
>
> Do you mean an _enable for just the BOC? I think I would do it like I
> suggested above instead.
No, no just the BOC. The BOC, IDAC and rest of side effects. Thinking
about it some more, it would be a bit redundant but clearer if proper
documentation is provided.
>
>>
>> The approach I took for the IDAC was to have a single configuration that
>> it's enabled for all channels. This makes some sense in my device when
>> thinking about optimal software sequencial reads, because of the
>> register layout, but I also see the value in having per-channel IDAC
>> configuration. I think I will take your approach, so we have the same
>> channel configuration around this.
>
> There are only two IDACs but on chips with 8 AIN pins we could have two
> RTDs wired up and if both require 2 IDACs, then we can't have a fixed
> setting for the IDACs. This is why I made it per-channel.
I'll make it per-channel too.
>
>>
>> Have you thought about how to implement the BOC? In the ADS1262 the
>> feature can be found "Sensor Bias". What I did was add per channel DT
>> properties for this too.
>
> See above.
>
>>
>> Another question. When you implement power management in the future,
>> will you enable autosuspend? IDAC currents will be lost if autosuspend
>> is enabled. Is this acceptable? In my case I did enable autosuspend, but
>> I have some doubts about this.
>
> I don't like to implement power management unless I have an application
> that actually requires it. Otherwise, I consider it premature optimization.
> It is difficult to know if we would be implementing it in a way that is
> actually useful for a real-world use case. These chips seem like they
> would mostly be used in an industrial setting, not in battery powered
> applications, so I'm not sure anyone is going to worry about saving a few
> milliamps.
Makes sense. I can probably drop the autosuspend in that case.
>
>>
>>>
>>> I have also pushed a branch to [3] that contains the start of some
>>> documentation for this driver that can give some more insight into how
>>> the implementation works. It still needs some work and also documents
>>> some things that haven't been implemented yet, so I haven't included it
>>> in this series yet.
>>>
>>> [3]: https://github.com/dlech/linux/blob/b4/iio-adc-ti-ads122c14/Documentation/iio/ads112c14.rst
>>>
>>> Signed-off-by: David Lechner <dlechner@baylibre.com>
>>> ---
>>> David Lechner (TI) (4):
>>> dt-bindings: iio: adc: add ti,ads122c14
>>> iio: adc: add ti-ads112c14 driver
>>> iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel
>>> iio: adc: ti-ads112c14: add measurement channel support
>>>
>>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++
>>> MAINTAINERS | 8 +
>>> drivers/iio/adc/Kconfig | 12 +
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/ti-ads112c14.c | 1053 ++++++++++++++++++++
>>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>>> 6 files changed, 1309 insertions(+)
>>> ---
>>> base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
>>> change-id: 20260514-iio-adc-ti-ads122c14-d0b92479334e
>>>
>>> Best regards,
>>> --
>>> David Lechner (TI) <dlechner@baylibre.com>
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
From: Rob Herring (Arm) @ 2026-06-16 17:28 UTC (permalink / raw)
To: Tapio Reijonen
Cc: linux-serial, Conor Dooley, Hugo Villeneuve, Jiri Slaby,
linux-kernel, Greg Kroah-Hartman, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-2-7e79f064bdd7@vaisala.com>
On Mon, 15 Jun 2026 10:27:36 +0000, Tapio Reijonen wrote:
> The MAX310x is a family of one- (max3107, max3108), two- (max3109) and
> four-channel (max14830) UARTs. The binding pulls in
> /schemas/serial/rs485.yaml at the chip level, describing a single set of
> RS-485 properties - enough for the single-channel parts, but a
> multi-channel chip can wire RS-485 differently on each channel.
>
> Split the binding per compatible:
>
> - single-channel parts (max3107, max3108): the chip node is itself the
> serial port and carries the RS-485 properties, as before;
>
> - multi-channel parts (max3109, max14830): the chip node is only a
> container and is no longer a serial node; each channel is a "serial@N"
> subnode that carries the standard serial.yaml/rs485.yaml properties
> (and may host a serial slave device). max3109 has channels 0-1,
> max14830 has 0-3.
>
> This avoids a chip node that is simultaneously a serial node and the
> parent of serial nodes. The driver still reads chip-level RS-485 for
> single-channel and legacy device trees, so existing users are unaffected.
>
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
> ---
> .../devicetree/bindings/serial/maxim,max310x.yaml | 92 +++++++++++++++++++++-
> 1 file changed, 90 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Kurt Borja @ 2026-06-16 17:31 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <88f29dc3-7929-4d94-a1bc-6268c41ee3dd@baylibre.com>
On Tue Jun 16, 2026 at 10:22 AM -05, David Lechner wrote:
> On 6/15/26 7:26 PM, Kurt Borja wrote:
>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
>>> Add new bindings for ti,ads122c14 and similar devices.
>>>
>>> This is an ADC that is primarily intended for use with temperature
>>> sensors. There are a few unusual properties because of this. In
>>> particular, the reference voltage source and current output requirements
>>> can be different for each measurement, so these are included in the
>>> channel bindings.
>>>
>>> The REFP/REFN reference voltage is usually just connected to a resistor
>>> that is being driven by the ADC's current outputs, so there is special
>>> property for this case rather than requiring a regulator to be defined
>>> to represent that.
>>>
>>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>>> have preferred an enum of strings).
>>>
>>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>>> ---
>>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
>>> MAINTAINERS | 7 +
>>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>>> 3 files changed, 242 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>> new file mode 100644
>>> index 000000000000..dc7f37cad772
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>> @@ -0,0 +1,224 @@
>>
>> [...]
>>
>>> +patternProperties:
>>> + ^channel@[0-7]$:
>>> + $ref: adc.yaml
>>> +
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + reg:
>>> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
>>> +
>>> + single-channel:
>>> + maximum: 7
>>> +
>>> + diff-channels:
>>> + items:
>>> + maximum: 7
>>> +
>>> + bipolar:
>>> + description:
>>> + Set this flag if the differential input can be negative.
>>> +
>>> + excitation-channels:
>>
>> I noticed this doesn't have the "ti," prefix. Is your plan to add this
>> to adc.yaml?
>
> I hadn't really though about it. I guess it could make sense.
I think it would be valuable, given that TI is producing quite a few of
this kind of devices.
>
>>
>> Also, do you think excitation-pins might be a better name?
>
> I used -channels to match e.g. diff-channels. The same values apply to
> both properties.
>
>>
>>> + description: AINx pins used as current output.
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + minItems: 1
>>> + maxItems: 2
>>> + items:
>>> + maximum: 7
>>> +
>>> + excitation-current-microamp:
>>> + description: The current output of the excitation channels in microamps.
>>> + minimum: 1
>>> + maximum: 1000
>>> +
>>> + current-chopping:
>>
>> If you agree with the above comment, I think this too should be added.
>> In that case, can we call this something like
>> excitation-current-rotation for less ambiguity?
>
> I think excitation-channel-rotation would be fine.
I like it.
>
>>
>> I say this because my device has an "IDAC rotation mode", but it also has
>> a "Chop Mode" which rotates analog inputs and averages consecutive
>> conversions.
>
> And this one sounds like it could be named input-channel-rotation. Would
> this also need a 2nd set of single-channel or diff-channels to the extra
> inputs?
No, just one set. It rotates the positive and negative inputs.
I'll go with input-channel-rotation then!
>
>>
>>> + $ref: /schemas/types.yaml#/definitions/flag
>>> + description:
>>> + If provided, the two excitation channels are to be used with current
>>> + chopping enabled.
>>> +
>>> + ti,vref-source:
>>> + description: |
>>> + Indicates the source for the reference voltage for this channel.
>>> + 0 - Internal 2.5V reference
>>> + 1 - Internal 1.25V reference
>>> + 2 - External reference (REFP-REFN)
>>> + 3 - AVDD as reference
>>> +
>>> + For convenience, macros for these values are available in
>>> + dt-bindings/iio/adc/ti,ads112c14.h.
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + maximum: 3
>>> + default: 0
>>> +
>>> + dependencies:
>>> + excitation-channels: [ excitation-current-microamp ]
>>> + excitation-current-microamp: [ excitation-channels ]
>>> + current-chopping: [ excitation-channels ]
>>> +
>>> + oneOf:
>>> + - required: [ single-channel ]
>>> + - required: [ diff-channels ]
>>
>> [...]
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: renesas: Describe GPU on D3
From: Niklas Söderlund @ 2026-06-16 17:58 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
Cc: Niklas Söderlund
Hello,
This series adds the needed bindings to operate the PowerVR GPU on R-Car
D3 SoC.
Together with the D3 clock changes [1] and a still OOT patch for the PVR
driver [2], I'm able to load firmware.
powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_22.67.54.30_v1.fw
powervr fd000000.gpu: [drm] FW version v1.0 (build 6889268 OS)
powervr fd000000.gpu: [drm] Unsupported quirks in firmware image
powervr fd000000.gpu: [drm] Unsupported enhancements in firmware image
powervr fd000000.gpu: [drm] Unsupported features in firmware image
[drm] Initialized powervr 1.0.0 for fd000000.gpu on minor 1
I can run vulkaninfo from mesa (need to add the driver to
pvr_drm_configs):
$ PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 meson devenv -C builddir vulkaninfo --summary
WARNING: powervr is not a conformant Vulkan implementation, testing use only.
MESA: warning: Warning: The available RAM is below the minimum required by the Vulkan specification!
MESA: warning: ../src/imagination/vulkan/pvr_border.c:117: FINISHME: Devices without tpu_border_colour_enhanced require entries for compressed formats to be stored in the table pre-compressed.
==========
VULKANINFO
==========
Vulkan Instance Version: 1.4.335
Instance Extensions: count = 20
-------------------------------
VK_EXT_debug_report : extension revision 10
VK_EXT_debug_utils : extension revision 2
VK_EXT_headless_surface : extension revision 1
VK_EXT_surface_maintenance1 : extension revision 1
VK_EXT_swapchain_colorspace : extension revision 5
VK_KHR_device_group_creation : extension revision 1
VK_KHR_display : extension revision 23
VK_KHR_external_fence_capabilities : extension revision 1
VK_KHR_external_memory_capabilities : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2 : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2 : extension revision 1
VK_KHR_portability_enumeration : extension revision 1
VK_KHR_surface : extension revision 25
VK_KHR_surface_protected_capabilities : extension revision 1
VK_KHR_wayland_surface : extension revision 6
VK_KHR_xcb_surface : extension revision 6
VK_KHR_xlib_surface : extension revision 6
VK_LUNARG_direct_driver_loading : extension revision 1
Instance Layers:
----------------
Devices:
========
GPU0:
apiVersion = 1.2.330
driverVersion = 25.99.99
vendorID = 0x1010
deviceID = 0x22054030
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = PowerVR Rogue GE8300
driverID = DRIVER_ID_IMAGINATION_OPEN_SOURCE_MESA
driverName = Imagination open-source Mesa driver
driverInfo = Mesa 26.0.0-devel (git-8fb0621f2d)
conformanceVersion = 1.3.8.4
deviceUUID = 19031a08-e22f-9565-d78b-ddda8240380a
driverUUID = 48685174-7bd0-6840-5716-9d00003566aa
GPU1:
apiVersion = 1.4.330
driverVersion = 25.99.99
vendorID = 0x10005
deviceID = 0x0000
deviceType = PHYSICAL_DEVICE_TYPE_CPU
deviceName = llvmpipe (LLVM 21.1.4, 128 bits)
driverID = DRIVER_ID_MESA_LLVMPIPE
driverName = llvmpipe
driverInfo = Mesa 26.0.0-devel (git-8fb0621f2d) (LLVM 21.1.4)
conformanceVersion = 1.3.1.1
deviceUUID = 6d657361-3236-2e30-2e30-2d6465766500
driverUUID = 6c6c766d-7069-7065-5555-494400000000
I can't run test Vulkan applications such as gears as the PVR driver do
not support all features need for GE8300, for example
simple_internal_parameter_format_v1, see [3].
1. https://lore.kernel.org/linux-renesas-soc/20260616175247.2104891-1-niklas.soderlund+renesas@ragnatech.se
2. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38211#note_3177232
3. https://gitlab.freedesktop.org/imagination/mesa/-/issues/13
Niklas Söderlund (2):
dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas
R-Car D3
arm64: dts: renesas: r8a77995: Add GE8300 GPU node
.../bindings/gpu/img,powervr-rogue.yaml | 14 ++++++++++----
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 15 +++++++++++++++
2 files changed, 25 insertions(+), 4 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
From: Niklas Söderlund @ 2026-06-16 17:58 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
Cc: Niklas Söderlund
In-Reply-To: <20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se>
Document Imagination Technologies PowerVR Rogue GE8300 BNVC 22.67.54.30
present in Renesas R-Car R8A77995 D3 SoCs.
Compared to other R-Car Gen3 SoCs the D3 only have one power domain and
it is always on. Extend the list of special cases for this to also cover
R8A77995 and update the description of it.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
* Changes since v1
- Sort img,img-ge8300 after img,img-ge7800.
- Fold special case for power domain into an existing one and update the
description.
---
.../devicetree/bindings/gpu/img,powervr-rogue.yaml | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a1f54dbae3f3..b93f49f1fa0a 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -25,6 +25,11 @@ properties:
- renesas,r8a779a0-gpu
- const: img,img-ge7800
- const: img,img-rogue
+ - items:
+ - enum:
+ - renesas,r8a77995-gpu
+ - const: img,img-ge8300
+ - const: img,img-rogue
- items:
- enum:
- ti,am62-gpu
@@ -114,6 +119,7 @@ allOf:
contains:
enum:
- img,img-ge7800
+ - img,img-ge8300
- img,img-gx6250
- thead,th1520-gpu
then:
@@ -159,14 +165,14 @@ allOf:
- if:
properties:
compatible:
- contains:
- const: thead,th1520-gpu
+ enum:
+ - renesas,r8a77995-gpu
+ - thead,th1520-gpu
then:
properties:
power-domains:
items:
- - description: The single, unified power domain for the GPU on the
- TH1520 SoC, integrating all internal IP power domains.
+ - description: The single, unified power domain for the GPU.
power-domain-names: false
required:
- power-domains
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: renesas: r8a77995: Add GE8300 GPU node
From: Niklas Söderlund @ 2026-06-16 17:58 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
Cc: Niklas Söderlund
In-Reply-To: <20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se>
Describe Imagination Technologies PowerVR Rogue GE8300 BNVC 22.67.54.30
present in Renesas R-Car R8A77995 D3 SoC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
* Changes since v1
- Use SPI 119 instead of SPI 223.
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 5f3fcef7560c..c42d96540ce7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -1295,6 +1295,21 @@ gic: interrupt-controller@f1010000 {
resets = <&cpg 408>;
};
+ gpu: gpu@fd000000 {
+ compatible = "renesas,r8a77995-gpu",
+ "img,img-ge8300",
+ "img,img-rogue";
+ reg = <0 0xfd000000 0 0x40000>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_CORE R8A77995_CLK_ZG>,
+ <&cpg CPG_CORE R8A77995_CLK_S3D1>,
+ <&cpg CPG_MOD 112>;
+ clock-names = "core", "mem", "sys";
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 112>;
+ status = "disabled";
+ };
+
vspbs: vsp@fe960000 {
compatible = "renesas,vsp2";
reg = <0 0xfe960000 0 0x8000>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access
From: Frieder Schrempf @ 2026-06-16 17:59 UTC (permalink / raw)
To: Frank Li, Frieder Schrempf, Pankaj Gupta
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajFtkysqxuLV8GgF@SMW015318>
On 16.06.26 17:36, Frank Li wrote:
> On Tue, Jun 16, 2026 at 01:52:18PM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> The ELE S400 API provides read and write access to the OCOTP fuse
>> registers. This adds the necessary API functions imx_se_read_fuse()
>> and imx_se_write_fuse() to be used by other drivers such as the
>> OCOTP S400 NVMEM driver.
>>
>> This is ported from the downstream vendor kernel.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> ---
>> drivers/firmware/imx/ele_base_msg.c | 122 ++++++++++++++++++++++++++++++++++++
>> drivers/firmware/imx/ele_base_msg.h | 6 ++
>> include/linux/firmware/imx/se_api.h | 3 +
>> 3 files changed, 131 insertions(+)
>>
> ...
>> +++ b/include/linux/firmware/imx/se_api.h
>> @@ -11,4 +11,7 @@
>> #define SOC_ID_OF_IMX8ULP 0x084d
>> #define SOC_ID_OF_IMX93 0x9300
>>
>> +int imx_se_read_fuse(void *se_if_data, uint16_t fuse_id, u32 *value);
>> +int imx_se_write_fuse(void *se_if_data, uint16_t fuse_id, u32 value);
>> +
>
> This API should implement in fuse drivers. Other consume should use standard
> fuse API to get value. If put here, it may bypass fuse driver.
The reason this is here, is the downstream implementation in linux-imx
and the current code organization. I thought there is some good reason
to have shared functions and it looks like Pankaj structured it like
this so all API functions live in ele_base_msg.c and the internal
structs and defines in ele_base_msg.h and se_ctrl.h are not exposed to
other drivers.
If I would move this into imx-ocotp-ele.c, then I would also need to
change how the code is organized and make the internal se_api functions
exposed to other drivers. I don't know if that is really a good idea.
I get your point but it looks like this contradicts the intention of
having a clean API in the firmware driver.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
From: sashiko-bot @ 2026-06-16 18:05 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: devicetree, robh, dri-devel, conor+dt, wsa+renesas
In-Reply-To: <20260616175835.2109336-2-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect use of `enum:` instead of `contains: enum:` in an `if` block breaks schema matching for `compatible` arrays, bypassing power domain validation.
--
commit 911441282d51eed161459bbab16231d9b1fcbca8
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
dt-bindings: gpu: img, powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
This commit documents the GE8300 GPU present in the Renesas R-Car R8A77995 D3
SoCs. It also updates the power domain constraints to account for the D3
having only one power domain that is always on.
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index a1f54dbae3f31..b93f49f1fa0a6 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
[ ... ]
> @@ -159,14 +165,14 @@ allOf:
> - if:
> properties:
> compatible:
> - contains:
> - const: thead,th1520-gpu
> + enum:
> + - renesas,r8a77995-gpu
> + - thead,th1520-gpu
[Severity: Medium]
Does this change break the schema matching for these compatible strings?
In Device Tree bindings, the compatible property evaluates as an array of
strings. Using "enum:" directly on the compatible array checks if the entire
array itself equals one of the scalar string values, which will always
evaluate to false.
Should this use "contains:" along with "enum:"? By dropping the "contains:"
keyword during the transition from a single const to an enum, this condition
might silently fail to match both the newly added renesas,r8a77995-gpu and
the preexisting thead,th1520-gpu strings. This would bypass the power domain
validation constraints intended by the block.
> then:
> properties:
> power-domains:
> items:
> - - description: The single, unified power domain for the GPU on the
> - TH1520 SoC, integrating all internal IP power domains.
> + - description: The single, unified power domain for the GPU.
> power-domain-names: false
> required:
> - power-domains
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: renesas: r8a77995: Add GE8300 GPU node
From: sashiko-bot @ 2026-06-16 18:11 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: conor+dt, dri-devel, devicetree, wsa+renesas, robh
In-Reply-To: <20260616175835.2109336-3-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added GPU node references core clock R8A77995_CLK_ZG and module clock 112, but neither is implemented in the R8A77995 CPG MSSR clock controller driver.
--
commit cb323f9d0762b84aa5d75f999bf135e4920caed4
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
arm64: dts: renesas: r8a77995: Add GE8300 GPU node
This commit describes the Imagination Technologies PowerVR Rogue GE8300 GPU
node for the Renesas R-Car R8A77995 D3 SoC.
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index 5f3fcef7560cb..c42d96540ce73 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -1295,6 +1295,21 @@ gic: interrupt-controller@f1010000 {
> resets = <&cpg 408>;
> };
>
> + gpu: gpu@fd000000 {
> + compatible = "renesas,r8a77995-gpu",
> + "img,img-ge8300",
> + "img,img-rogue";
> + reg = <0 0xfd000000 0 0x40000>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_CORE R8A77995_CLK_ZG>,
> + <&cpg CPG_CORE R8A77995_CLK_S3D1>,
> + <&cpg CPG_MOD 112>;
[Severity: Medium]
Will this result in a probe failure when the node is enabled by a board?
The newly added GPU node requests the core clock R8A77995_CLK_ZG and module
clock 112, but neither appears to be defined in the R8A77995 CPG MSSR clock
controller driver (drivers/clk/renesas/r8a77995-cpg-mssr.c).
If R8A77995_CLK_ZG is missing from r8a77995_core_clks and index 112 is
missing from r8a77995_mod_clks, the clock requests will return -ENOENT and
prevent the GPU driver from probing successfully.
> + clock-names = "core", "mem", "sys";
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 112>;
> + status = "disabled";
> + };
> +
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se?part=2
^ permalink raw reply
* Re: [PATCH 1/3] of/fdt: fix misleading elfcorehdr reservation success message
From: Sang-Heon Jeon @ 2026-06-16 18:13 UTC (permalink / raw)
To: Rob Herring
Cc: Saravana Kannan, Huacai Chen, WANG Xuerui, Thomas Bogendoerfer,
devicetree, loongarch, linux-mips
In-Reply-To: <20260616131945.GA2236977-robh@kernel.org>
On Tue, Jun 16, 2026 at 10:19 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jun 15, 2026 at 01:15:01AM +0900, Sang-Heon Jeon wrote:
> > fdt_reserve_elfcorehdr() does not check the return value of
> > memblock_reserve(), so a success message is falsely printed when the
> > reservation fails.
> >
> > Check the return value and warn on failure instead.
> >
> > Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> > ---
> > drivers/of/fdt.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 26f66046cc32..d985c07d7c5c 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -479,7 +479,10 @@ static void __init fdt_reserve_elfcorehdr(void)
> > return;
> > }
> >
> > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > + if (memblock_reserve(elfcorehdr_addr, elfcorehdr_size)) {
> > + pr_warn("Failed to reserve memory for elfcorehdr\n");
>
> I would think memblock_reserve() should always succeed and if not it
> should print a message rather than having every caller print a message.
Thanks for reviewing, Rob.
You're right. After taking a closer look, memblock_reserve() either
succeeds or panics before memblock_allow_resize() called.
So the check that I added in this patchset is totally unreachable.
Please drop this patchset. I'll be more careful when sending patches next time.
> Rob
Best Regards,
Sang-Heon Jeon
^ permalink raw reply
* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: David Lechner @ 2026-06-16 18:16 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <DJANEYYA4QTA.1JBN2L78PNXDD@gmail.com>
On 6/16/26 12:26 PM, Kurt Borja wrote:
> On Tue Jun 16, 2026 at 10:21 AM -05, David Lechner wrote:
>> On 6/15/26 7:18 PM, Kurt Borja wrote:
>>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
...
>>>> All of these chips have in common that they are designed for use with
>>>> RTDs and thermocouples and so they look very similar to each other in
>>>> terms of wiring and feature set, even if the register maps are
>>>> different. They are in the gray area where we could either keep them
>>>> separate because they are just different enough, or we could do like
>>>> we've done before with ad_sigma_delta and have a bit of an abstraction
>>>> layer for the register differences and otherwise try to share as much
>>>> code as possible. Normally, I would lean towards keeping them separate,
>>>> but in this case, I'm considering trying to share code because the
>>>> devicetree bindings for the inputs is complex and is going to be mostly
>>>> the same across all of these chips.
>>>
>>> The channel configuration is indeed very similar for the three chips.
>>> All three have IDAC, BOC and VREF configurations.
>>
>> Hmm... I forgot to include the burnout current in the DT bindings. Following
>> the channel = "conditions for measurement" pattern that I have set out here
>> I guess that would mean that we would need to have the same inputs twice
>> when using the burnout. One "channel" would be the one used to do a "precision"
>> measurement and the other would be the one to do open/short circuit detection.
>>
>>
>> i2c {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> adc@40 {
>> compatible = "ti,ads112c14";
>> reg = <0x40>;
>>
>> avdd-supply = <&avdd>;
>> dvdd-supply = <&dvdd>;
>>
>> refp-supply = <&avdd>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> channel@0 {
>> reg = <0>;
>> diff-channels = <1>, <2>;
>> excitation-channels = <0>, <3>;
>> excitation-current-microamp = <500>;
>> current-chopping;
>> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
>> label = "rtd-precision";
>> };
>>
>> channel@1 {
>> reg = <0>;
>> diff-channels = <1>, <2>;
>> excitation-channels = <0>, <3>;
>> excitation-current-microamp = <500>;
>> burnout-current-nanoamp = <1000>;
>> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
>> label = "rtd-diagnostic";
>> };
>
> This would mean we wouldn't be able to use iio_chan_spec .channel and
> .channel2 to describe inputs because of duplicate sysfs attributes, no?
>
Yes, that is a bit unfortunate. At least there the labels to tell them
apart. I guess we would just need to use consecutive channel and channel2
when dynamically allocating the channels to avoid conflict.
>>>> This makes things more flexible, but does make the driver a bit more
>>>> complex. For example, knowing when the current output needs to be
>>>> enabled or disabled. For now, I have chosen a lazy-enable where they
>>>> are not turned on until the first measurement is taken that requires
>>>> them, but then they stay on until another measurement is taken that
>>>> doesn't require them. This can lead to some oddness with the diagnostic
>>>> channels that may be measuring something that indirectly requires the
>>>> current output (i.e. the external reference voltage when it is connected
>>>> to a resistor rather than a power supply). This means you need to take
>>>> a measurement that requires the current output to be enabled before the
>>>> diagnostic channels will give accurate readings.
>>>
>>> This is the same approach I took around the BOC, it feels kinda hacky
>>> but it makes sense. Just an idea I thought about just now: What if we
>>> have an additional write-only "_enable" sysfs attribute for these
>>> channels?
>>
>> I would not want to make a write-only attribute, we always want to be
>> able to read back what the current state is.
>
> Yeah, I don't know why I said WO. Reading would be fine too.
>
>>
>> Do you mean an _enable for just the BOC? I think I would do it like I
>> suggested above instead.
>
> No, no just the BOC. The BOC, IDAC and rest of side effects. Thinking
> about it some more, it would be a bit redundant but clearer if proper
> documentation is provided.
>
I would be interested to see what Jonathan has to say about this too.
Generally, his advice has been to avoid attributes that power things
on and off if we can help it.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
From: Niklas Söderlund @ 2026-06-16 18:28 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
In-Reply-To: <20260616175835.2109336-2-niklas.soderlund+renesas@ragnatech.se>
On 2026-06-16 19:58:34 +0200, Niklas Söderlund wrote:
> Document Imagination Technologies PowerVR Rogue GE8300 BNVC 22.67.54.30
> present in Renesas R-Car R8A77995 D3 SoCs.
>
> Compared to other R-Car Gen3 SoCs the D3 only have one power domain and
> it is always on. Extend the list of special cases for this to also cover
> R8A77995 and update the description of it.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> * Changes since v1
> - Sort img,img-ge8300 after img,img-ge7800.
> - Fold special case for power domain into an existing one and update the
> description.
> ---
> .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index a1f54dbae3f3..b93f49f1fa0a 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -25,6 +25,11 @@ properties:
> - renesas,r8a779a0-gpu
> - const: img,img-ge7800
> - const: img,img-rogue
> + - items:
> + - enum:
> + - renesas,r8a77995-gpu
> + - const: img,img-ge8300
> + - const: img,img-rogue
> - items:
> - enum:
> - ti,am62-gpu
> @@ -114,6 +119,7 @@ allOf:
> contains:
> enum:
> - img,img-ge7800
> + - img,img-ge8300
> - img,img-gx6250
> - thead,th1520-gpu
> then:
> @@ -159,14 +165,14 @@ allOf:
> - if:
> properties:
> compatible:
> - contains:
The 'contains' node should have been kept, my bad. I wonder why 'make
dt_binding_check' or `make dtbs_check' did not catch it. Sorry for the
noise.
> - const: thead,th1520-gpu
> + enum:
> + - renesas,r8a77995-gpu
> + - thead,th1520-gpu
> then:
> properties:
> power-domains:
> items:
> - - description: The single, unified power domain for the GPU on the
> - TH1520 SoC, integrating all internal IP power domains.
> + - description: The single, unified power domain for the GPU.
> power-domain-names: false
> required:
> - power-domains
> --
> 2.54.0
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH 1/4] ASoC: qcom: audioreach: compute active channel maps from channel_map
From: Srinivas Kandagatla @ 2026-06-16 18:52 UTC (permalink / raw)
To: Neil Armstrong, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kancy2333, linux-sound, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <a35d7f95-c158-46d1-b136-b901dcfbf101@linaro.org>
On 6/16/26 4:12 PM, Neil Armstrong wrote:
> On 6/16/26 16:59, Srinivas Kandagatla wrote:
>>
>>
>> On 6/15/26 2:54 PM, Neil Armstrong wrote:
>>> On 6/15/26 11:36, Srinivas Kandagatla wrote:
>>>> On 6/15/26 10:31 AM, Neil Armstrong wrote:
>>>>> On 6/15/26 10:38, Srinivas Kandagatla wrote:
>>>>>>
>>>>>>
>>>>>> On 6/10/26 8:41 AM, Neil Armstrong wrote:
>>>>>>> The Qualcom SM8650 based Ayaneo Pocket S2 gaming device has a set
>>>>>>> of 2 WSA speakers connected on the WSA2 lines.
>>>>>>>
>>>>>>> But the Audioreach DSP only handles WSA2 in pair with the WSA
>>>>>>> interface by using the upper bits of the active_channels_mask
>>>>>>> for WSA2 and the lower bits for WSA:
>>>>>>>
>>>>>>> /-------------------------------------------------\
>>>>>>> | Bits | 3 | 2 | 1 | 0 |
>>>>>>> |-------------------------------------------------|
>>>>>>> | Line | WSA2 Ch2 | WSA2 Ch1 | WSA Ch2 | WSA Ch1 |
>>>>>>> \-------------------------------------------------/
>>>>>>>
>>>>>> No, this is not totally correct, if the setup only has WSA2, then
>>>>>> channel 0 and 1 should be WSA2 channels.
>>>>>>
>>>>>> What is the backend dai id that is in DT, it should be
>>>>>>
>>>>>> sound-dai = <&q6apmbedai WSA2_CODEC_DMA_RX_0>;
>>>>>>
>
> Yeah 0xC0 for active_channels_mask and channel_mapping =
> { PCM_CHANNEL_FL, PCM_CHANNEL_FR };
>
> I tried to keep the leading 0, but since the channel_mapping table is
> allocated with
> the size of the num_channels parameter, you can ony have 2 entries.
>
>>
>> From DSP docs:
>> https://github.com/AudioReach/audioreach-engine/blob/master/fwk/api/
>> modules/media_fmt_api_basic.h#L780
>>
>> Channel[i] mapping describes channel i. Each element i of the array
>> describes channel i inside the buffer where i is less than num_channels.
>> An unused channel is set to 0.
>>
>>
>> So unused channels should be set to zero, but the patch padding the
>> channels starting form zero.
>
> My understanding in my trial and error is that the DSP will map each
> entry of the channel_mapping to the active_channels_mask bits in order
> so you can have a non linear active_channels_mask like b10101010 which
> has 4 channels active and pass a channel_mapping table with 4 entries.
>
You are correct, I was mis-interpreting some of the comments from
modules/media_fmt_api_basic.h specially the channel map comment.
Also confirmed this internally so we are good,
I tested this on T14s,
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
--srini
> The is what I implemented here, and it gives a lot of flexibility on how
> to connect speakers to the interface.
>
> Neil
^ 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