* Re: [PATCH 1/2] dt-bindings: clock: ast2700: add PECI clock
From: Conor Dooley @ 2026-06-24 16:29 UTC (permalink / raw)
To: Ryan Chen
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260624-peci_clk-v1-1-ee28b92e22e9@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: sashiko-bot @ 2026-06-24 16:07 UTC (permalink / raw)
To: David Heidelberg via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incorrect `$id` path in the YAML schema breaks cross-referencing.
- [Low] Undefined properties in the dt-schema example cause validation failure.
--
commit 637d0c2cb3168267adcc3eaf3f2d6a7d9fd028f5
Author: David Heidelberg <david@ixit.cz>
ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
This commit converts the CS35L36 Speaker Amplifier device tree binding from
plain text to YAML schema. It also includes the dai-common.yaml schema for
sound DAI cells and prefix.
> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> new file mode 100644
> index 0000000000000..af0acaaefb68e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
> @@ -0,0 +1,224 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
[Severity: Medium]
Does this $id field break schema cross-referencing? Since this file is located
in the sound/ subdirectory, shouldn't the path exactly match the file location
(e.g., http://devicetree.org/schemas/sound/cirrus,cs35l36.yaml#) to allow
dt_binding_check to resolve references properly?
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - VA-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
[ ... ]
> + cirrus,boost-ind-nanohenry = <1000>;
> + cirrus,boost-ctl-millivolt = <10000>;
> + cirrus,boost-peak-milliamp = <4500>;
> + cirrus,boost-ctl-select = <0x00>;
> + cirrus,weak-fet-delay = <4>;
> + cirrus,weak-fet-thld = <0x01>;
[Severity: Low]
Will this example fail validation with dt_binding_check due to the
unevaluatedProperties: false restriction?
The example uses cirrus,weak-fet-delay and cirrus,weak-fet-thld, but the
schema defined earlier specifies these properties as cirrus,classh-wk-fet-delay
and cirrus,classh-weak-fet-thld-millivolt.
Additionally, is <0x01> a valid value for the millivolt threshold enum?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-dt-cirrus-cs35l36-v2-1-74eccdbd8fe4@ixit.cz?part=1
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema
From: David Heidelberg via B4 Relay @ 2026-06-24 16:02 UTC (permalink / raw)
To: David Rhodes, Richard Fitzgerald, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, patches,
Bjorn Helgaas
Cc: David Rhodes, linux-sound, devicetree, linux-kernel, phone-devel,
David Heidelberg
From: David Heidelberg <david@ixit.cz>
Convert CS35L36 Speaker Amplifier to yaml.
Changes:
- maintainers email to the generic Cirrus email
- Both the codec and downstream worked just fine without
VP-supply provided. Align with datasheet for similar models.
- add dai-common.yaml to cover for '#sound-dai-cells',
'sound-name-prefix'
Reviewed-by: David Rhodes <David.Rhodes@cirrus.com>
Co-developed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Relevant for Pixel 3 / 3XL / 4.
---
Changes in v2:
- Rename the commit. (Mark)
- Link to v1: https://lore.kernel.org/r/20260618-dt-cirrus-cs35l36-v1-1-1a43515666ad@ixit.cz
---
.../devicetree/bindings/sound/cirrus,cs35l36.yaml | 224 +++++++++++++++++++++
.../devicetree/bindings/sound/cs35l36.txt | 168 ----------------
2 files changed, 224 insertions(+), 168 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
new file mode 100644
index 0000000000000..af0acaaefb68e
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
@@ -0,0 +1,224 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cirrus Logic CS35L36 Speaker Amplifier
+
+maintainers:
+ - patches@opensource.cirrus.com
+ - Bjorn Helgaas <bhelgaas@google.com>
+
+description: |
+ CS35L36 is a boosted mono Class D amplifier
+
+allOf:
+ - $ref: /schemas/sound/dai-common.yaml#
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs35l36
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ VA-supply:
+ description: Voltage regulator of analog internal section
+
+ VP-supply:
+ description: Voltage regulator of boost converter
+
+ reset-gpios:
+ maxItems: 1
+
+ cirrus,boost-ctl-millivolt:
+ description: Boost converter output voltage in millivolts (step 50)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 2550
+ maximum: 12000
+
+ cirrus,boost-peak-milliamp:
+ description: Boost-converter peak current limit in mA (step 50)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 4500
+ minimum: 1600
+ maximum: 4500
+
+ cirrus,boost-ind-nanohenry:
+ description: Initial inductor estimation reference value in nanohenry (1000=1μH, 1200=1.2μH)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1000
+
+ cirrus,multi-amp-mode:
+ description: Hi-Z ASP port when more than one amplifier in system.
+ type: boolean
+
+ cirrus,boost-ctl-select:
+ description: Boost converter control source selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x01
+ enum:
+ - 0x00 # Control Port
+ - 0x01 # Class
+ - 0x10 # Sync
+
+ cirrus,amp-pcm-inv:
+ description: Invert incoming PCM data when true.
+ type: boolean
+
+ cirrus,imon-pol-inv:
+ description: Invert polarity of outbound IMON feedback when true.
+ type: boolean
+
+ cirrus,vmon-pol-inv:
+ description: Invert polarity of outbound VMON feedback when true.
+ type: boolean
+
+ cirrus,dcm-mode-enable:
+ description: Enable boost converter automatic Discontinuous Conduction Mode.
+ type: boolean
+
+ cirrus,weak-fet-disable:
+ description: Reduce output driver strength in Weak-FET Drive Mode when true.
+ type: boolean
+
+ cirrus,classh-wk-fet-delay:
+ description: Weak-FET entry delay in ms
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 100
+ enum:
+ - 0 # 0
+ - 1 # 5
+ - 2 # 10
+ - 3 # 50
+ - 4 # 100
+ - 5 # 200
+ - 6 # 500
+ - 7 # 1000
+
+ cirrus,classh-weak-fet-thld-millivolt:
+ description: Weak-FET drive threshold in mV
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [50, 100, 150, 200, 250, 300, 350, 400, 450, 500, 550, 600, 650, 700]
+
+ cirrus,temp-warn-threshold:
+ description: Overtemperature warning threshold
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 2
+ enum:
+ - 0 # 105°C
+ - 1 # 115°C
+ - 2 # 125°C
+ - 3 # 135°C
+
+ cirrus,irq-drive-select:
+ description: Interrupt output driver type
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 1
+ enum:
+ - 0 # open-drain
+ - 1 # push-pull
+
+ cirrus,irq-gpio-select:
+ description: Programmable IRQ pin selection
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # PDM_DATA/SWIRE_SD/INT
+ - 1 # GPIO
+
+ cirrus,vpbr-config:
+ description: Brownout prevention configuration sub-node
+ type: object
+ additionalProperties: false
+
+ properties:
+ cirrus,vpbr-en:
+ description: VBST brownout prevention enable
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ enum:
+ - 0 # disabled
+ - 1 # enabled
+
+ cirrus,vpbr-thld:
+ description: Initial VPBR threshold voltage
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-atk-rate:
+ description: Attenuation attack step rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-atk-vol:
+ description: VP brownout prevention step size
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-max-attn:
+ description: Maximum attenuation during VP brownout prevention
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-wait:
+ description: Delay between brownout clearance and attenuation release
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-rel-rate:
+ description: Attenuation release step rate
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ cirrus,vpbr-mute-en:
+ description: Mute audio if maximum attenuation reached
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - VA-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ codec@40 {
+ compatible = "cirrus,cs35l36";
+ reg = <0x40>;
+ VA-supply = <&dummy_vreg>;
+ VP-supply = <&dummy_vreg>;
+ reset-gpios = <&gpio0 54 GPIO_ACTIVE_HIGH>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ cirrus,boost-ind-nanohenry = <1000>;
+ cirrus,boost-ctl-millivolt = <10000>;
+ cirrus,boost-peak-milliamp = <4500>;
+ cirrus,boost-ctl-select = <0x00>;
+ cirrus,weak-fet-delay = <4>;
+ cirrus,weak-fet-thld = <0x01>;
+ cirrus,temp-warn-threshold = <1>;
+ cirrus,multi-amp-mode;
+ cirrus,irq-drive-select = <1>;
+ cirrus,irq-gpio-select = <0x01>;
+
+ cirrus,vpbr-config {
+ cirrus,vpbr-en = <0>;
+ cirrus,vpbr-thld = <0x05>;
+ cirrus,vpbr-atk-rate = <0x02>;
+ cirrus,vpbr-atk-vol = <0x01>;
+ cirrus,vpbr-max-attn = <0x09>;
+ cirrus,vpbr-wait = <0x01>;
+ cirrus,vpbr-rel-rate = <0x05>;
+ cirrus,vpbr-mute-en = <0x00>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/sound/cs35l36.txt b/Documentation/devicetree/bindings/sound/cs35l36.txt
deleted file mode 100644
index d34117b8558e5..0000000000000
--- a/Documentation/devicetree/bindings/sound/cs35l36.txt
+++ /dev/null
@@ -1,168 +0,0 @@
-CS35L36 Speaker Amplifier
-
-Required properties:
-
- - compatible : "cirrus,cs35l36"
-
- - reg : the I2C address of the device for I2C
-
- - VA-supply, VP-supply : power supplies for the device,
- as covered in
- Documentation/devicetree/bindings/regulator/regulator.txt.
-
- - cirrus,boost-ctl-millivolt : Boost Voltage Value. Configures the boost
- converter's output voltage in mV. The range is from 2550mV to 12000mV with
- increments of 50mV.
- (Default) VP
-
- - cirrus,boost-peak-milliamp : Boost-converter peak current limit in mA.
- Configures the peak current by monitoring the current through the boost FET.
- Range starts at 1600mA and goes to a maximum of 4500mA with increments of
- 50mA.
- (Default) 4.50 Amps
-
- - cirrus,boost-ind-nanohenry : Inductor estimation LBST reference value.
- Seeds the digital boost converter's inductor estimation block with the initial
- inductance value to reference.
-
- 1000 = 1uH (Default)
- 1200 = 1.2uH
-
-Optional properties:
- - cirrus,multi-amp-mode : Boolean to determine if there are more than
- one amplifier in the system. If more than one it is best to Hi-Z the ASP
- port to prevent bus contention on the output signal
-
- - cirrus,boost-ctl-select : Boost converter control source selection.
- Selects the source of the BST_CTL target VBST voltage for the boost
- converter to generate.
- 0x00 - Control Port Value
- 0x01 - Class H Tracking (Default)
- 0x10 - MultiDevice Sync Value
-
- - cirrus,amp-pcm-inv : Boolean to determine Amplifier will invert incoming
- PCM data
-
- - cirrus,imon-pol-inv : Boolean to determine Amplifier will invert the
- polarity of outbound IMON feedback data
-
- - cirrus,vmon-pol-inv : Boolean to determine Amplifier will invert the
- polarity of outbound VMON feedback data
-
- - cirrus,dcm-mode-enable : Boost converter automatic DCM Mode enable.
- This enables the digital boost converter to operate in a low power
- (Discontinuous Conduction) mode during low loading conditions.
-
- - cirrus,weak-fet-disable : Boolean : The strength of the output drivers is
- reduced when operating in a Weak-FET Drive Mode and must not be used to drive
- a large load.
-
- - cirrus,classh-wk-fet-delay : Weak-FET entry delay. Controls the delay
- (in ms) before the Class H algorithm switches to the weak-FET voltage
- (after the audio falls and remains below the value specified in WKFET_AMP_THLD).
-
- 0 = 0ms
- 1 = 5ms
- 2 = 10ms
- 3 = 50ms
- 4 = 100ms (Default)
- 5 = 200ms
- 6 = 500ms
- 7 = 1000ms
-
- - cirrus,classh-weak-fet-thld-millivolt : Weak-FET amplifier drive threshold.
- Configures the signal threshold at which the PWM output stage enters
- weak-FET operation. The range is 50mV to 700mV in 50mV increments.
-
- - cirrus,temp-warn-threshold : Amplifier overtemperature warning threshold.
- Configures the threshold at which the overtemperature warning condition occurs.
- When the threshold is met, the overtemperature warning attenuation is applied
- and the TEMP_WARN_EINT interrupt status bit is set.
- If TEMP_WARN_MASK = 0, INTb is asserted.
-
- 0 = 105C
- 1 = 115C
- 2 = 125C (Default)
- 3 = 135C
-
- - cirrus,irq-drive-select : Selects the driver type of the selected interrupt
- output.
-
- 0 = Open-drain
- 1 = Push-pull (Default)
-
- - cirrus,irq-gpio-select : Selects the pin to serve as the programmable
- interrupt output.
-
- 0 = PDM_DATA / SWIRE_SD / INT (Default)
- 1 = GPIO
-
-Optional properties for the "cirrus,vpbr-config" Sub-node
-
- - cirrus,vpbr-en : VBST brownout prevention enable. Configures whether the
- VBST brownout prevention algorithm is enabled or disabled.
-
- 0 = VBST brownout prevention disabled (default)
- 1 = VBST brownout prevention enabled
-
- See Section 7.31.1 VPBR Config for configuration options & further details
-
- - cirrus,vpbr-thld : Initial VPBR threshold. Configures the VP brownout
- threshold voltage
-
- - cirrus,cirrus,vpbr-atk-rate : Attenuation attack step rate. Configures the
- amount delay between consecutive volume attenuation steps when a brownout
- condition is present and the VP brownout condition is in an attacking state.
-
- - cirrus,vpbr-atk-vol : VP brownout prevention step size. Configures the VP
- brownout prevention attacking attenuation step size when operating in either
- digital volume or analog gain modes.
-
- - cirrus,vpbr-max-attn : Maximum attenuation that the VP brownout prevention
- can apply to the audio signal.
-
- - cirrus,vpbr-wait : Configures the delay time between a brownout condition
- no longer being present and the VP brownout prevention entering an attenuation
- release state.
-
- - cirrus,vpbr-rel-rate : Attenuation release step rate. Configures the delay
- between consecutive volume attenuation release steps when a brownout condition
- is not longer present and the VP brownout is in an attenuation release state.
-
- - cirrus,vpbr-mute-en : During the attack state, if the vpbr-max-attn value
- is reached, the error condition still remains, and this bit is set, the audio
- is muted.
-
-Example:
-
-cs35l36: cs35l36@40 {
- compatible = "cirrus,cs35l36";
- reg = <0x40>;
- VA-supply = <&dummy_vreg>;
- VP-supply = <&dummy_vreg>;
- reset-gpios = <&gpio0 54 0>;
- interrupt-parent = <&gpio8>;
- interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
-
- cirrus,boost-ind-nanohenry = <1000>;
- cirrus,boost-ctl-millivolt = <10000>;
- cirrus,boost-peak-milliamp = <4500>;
- cirrus,boost-ctl-select = <0x00>;
- cirrus,weak-fet-delay = <0x04>;
- cirrus,weak-fet-thld = <0x01>;
- cirrus,temp-warn-threshold = <0x01>;
- cirrus,multi-amp-mode;
- cirrus,irq-drive-select = <0x01>;
- cirrus,irq-gpio-select = <0x01>;
-
- cirrus,vpbr-config {
- cirrus,vpbr-en = <0x00>;
- cirrus,vpbr-thld = <0x05>;
- cirrus,vpbr-atk-rate = <0x02>;
- cirrus,vpbr-atk-vol = <0x01>;
- cirrus,vpbr-max-attn = <0x09>;
- cirrus,vpbr-wait = <0x01>;
- cirrus,vpbr-rel-rate = <0x05>;
- cirrus,vpbr-mute-en = <0x00>;
- };
-};
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-dt-cirrus-cs35l36-99c466fb13fd
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply related
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Daniel Lezcano @ 2026-06-24 15:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gaurav Kohli
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi,
Dmitry Baryshkov
In-Reply-To: <5b0f1f39-ddaa-4a2e-ab29-34aacc9ff672@kernel.org>
On 6/24/26 12:42, Krzysztof Kozlowski wrote:
[ ... ]
> Therefore I still do not see the need of tmd-names. You know the name of
> cooling device, because you have strict one-to-one mapping.
There is one remote proc with one or multiple cooling devices attached.
We describe those in the remoteproc node with the tmd-names.
Anyway, we should be able to list the tmd names in the driver itself if
we ensure a consistency with the index by defining them in a shared
header eg. include/dt-bindings/firmware/qcom,cdsp.h
#define HAMOA_TMD_CDSP_SW 0
#define HAMOA_TMD_CDSP_HW 1
#define HAMOA_TMD_CP0UV_RESTRICTION_COLD 2
In the driver:
struct tmd_name {
const char *name;
int id;
bool disabled;
};
static struct tmd_name tmd_names[] = {
{ .name = "cdsp_sw", HAMOA_TMD_CDSP_SW },
{ .name = "cdsp_hw", HAMOA_TMD_CDSP_HW, .disabled = true },
{ .name = "cpuv_restriction_cold", HAMOA_TMD_CP0UV_RESTRICTION_COLD,
.disabled = true },
};
...
for (int i = 0; i < ARRAY_SIZE(tmd_names); i++) {
if (tmd_names[i].disabled)
continue;
devm_cooling_of_device_register(rprocdev,
tmd_names[i].name, tmd_names[i].id, ...);
}
In the device tree:
cooling-maps = <&rproc HAMOA_TMD_CDSP_SW min max>;
I think that is somehow what Konrad and Dmitry were suggesting
Does it sound better ?
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: interrupt-controller: ti,irq-crossbar: Convert to DT schema
From: Rob Herring @ 2026-06-24 15:49 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bhargav Joshi, simona.toaca, Krzysztof Kozlowski, m-chawdhry,
daniel.baluta, Thomas Gleixner, Sricharan R, linux-kernel,
devicetree, Conor Dooley, goledhruva
In-Reply-To: <42760292-3a29-4600-8676-6a79d3b5d7a4@kernel.org>
On Wed, Jun 24, 2026 at 6:22 AM Konrad Dybcio <konradybcio@kernel.org> wrote:
>
> On 6/15/26 11:01 PM, Rob Herring (Arm) wrote:
> >
> > On Fri, 12 Jun 2026 02:42:29 +0530, Bhargav Joshi wrote:
> >> Convert TI irq-crossbar binding from text format to DT schema.
> >>
> >> As part of conversion following changes are made:
> >> - Add '#interrupt-cells' as a required property which was missing in
> >> text binding
> >> - As irq-crossbar is interrupt-controller. Move binding from
> >> bindings/arm/omap to bindings/interrupt-controller
> >>
> >> Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
> >> ---
> >> Changes in v3:
> >> - Fixed typo in property description
> >> - Link to v2: https://lore.kernel.org/r/20260611-crossbar-v2-1-231d4f88298e@gmail.com
> >>
> >> Changes in v2:
> >> - Dropped property name change and driver updates.
> >> - Link to v1: https://lore.kernel.org/r/20260606-crossbar-v1-0-f67f7cb9ee50@gmail.com
> >> ---
> >> .../devicetree/bindings/arm/omap/crossbar.txt | 55 -------------
> >> .../interrupt-controller/ti,irq-crossbar.yaml | 96 ++++++++++++++++++++++
> >> 2 files changed, 96 insertions(+), 55 deletions(-)
> >>
> >
> > Applied, thanks!
>
> With:
>
> $ dt-validate --version
> 2026.4
There is 2026.6 now which fixes this.
>
> on next-20260623
>
> I'm getting:
>
> $ LC_ALL=C make ARCH=arm64 LLVM=1 -j24 dt_binding_check
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> Traceback (most recent call last):
> File "/home/konrad/.local/bin/dt-mk-schema", line 6, in <module>
> sys.exit(main())
> ~~~~^^
> File "/home/konrad/.local/share/pipx/venvs/dtschema/lib/python3.14/site-packages/dtschema/mk_schema.py", line 28, in main
> schemas = dtschema.DTValidator(args.schemas).schemas
> ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
> File "/home/konrad/.local/share/pipx/venvs/dtschema/lib/python3.14/site-packages/dtschema/validator.py", line 399, in __init__
> self.make_property_type_cache()
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
> File "/home/konrad/.local/share/pipx/venvs/dtschema/lib/python3.14/site-packages/dtschema/validator.py", line 528, in make_property_type_cache
> self.check_duplicate_property_types()
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
> File "/home/konrad/.local/share/pipx/venvs/dtschema/lib/python3.14/site-packages/dtschema/validator.py", line 522, in check_duplicate_property_types
> print(f"{self.schemas[sch_id]['$filename']}: {p}: multiple incompatible types: {v['type']}", file=sys.stderr)
> ~~~~~~~~~~~~^^^^^^^^
> KeyError: 'http://devicetree.org/schemas/interrupt-controller/ti,irq-crossbar.yaml#'
> make[2]: *** [Documentation/devicetree/bindings/Makefile:75: Documentation/devicetree/bindings/processed-schema.json] Błąd 1
> make[2]: *** Kasuję plik 'Documentation/devicetree/bindings/processed-schema.json'
> make[1]: *** [<snip>/linux/Makefile:1672: dt_binding_schemas] Błąd 2
> make: *** [Makefile:248: __sub-make] Error 2
We should fix this to avoid the splat, but that would still be a new
tool version.
So we either need to revert this and delay adding this schema or force
people to upgrade.
Rob
^ permalink raw reply
* Re: [PATCH net] dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
From: Andrew Lunn @ 2026-06-24 15:47 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Niklas Söderlund, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Sergei Shtylyov, netdev,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260624150250.131966-2-robh@kernel.org>
On Wed, Jun 24, 2026 at 10:02:50AM -0500, Rob Herring (Arm) wrote:
> Fix the Micrel PHY in the example which shouldn't have the
> fallback "ethernet-phy-ieee802.3-c22" compatible:
>
> Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 \
> (ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long
> from schema $id: http://devicetree.org/schemas/net/micrel.yaml
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Fixes: 37a2fce09001 ("dt-bindings: sh_eth convert bindings to json-schema")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable i2c3 on 40-pin header
From: Ricardo Pardini via B4 Relay @ 2026-06-24 15:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Ricardo Pardini
In-Reply-To: <20260624-nio-12l-add-i2c-40-pin-v2-0-cf3707a6aaf1@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
i2c3 (SDA3/SCL3 on GPIO14/GPIO15) is routed to the 40-pin GPIO header,
exposed on the blue-colored pins 27 (SCL3) and 28 (SDA3). Enable the
controller and add the corresponding pin configuration in the pinctrl
node so users can use external I2C devices.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index 589a5f07d5dde..9b0966c271cb5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -371,6 +371,14 @@ it5205_sbu_mux: endpoint {
};
};
+/* Exposed on 40-pin header (blue-colored pins 27:SCL3 28:SDA3) */
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&i2c4 {
clock-frequency = <400000>;
pinctrl-0 = <&i2c4_pins>;
@@ -788,6 +796,15 @@ pins-bus {
};
};
+ i2c3_pins: i2c3-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO14__FUNC_SDA3>,
+ <PINMUX_GPIO15__FUNC_SCL3>;
+ bias-pull-up = <1000>;
+ drive-strength-microamp = <1000>;
+ };
+ };
+
i2c4_pins: i2c4-pins {
pins-bus {
pinmux = <PINMUX_GPIO16__FUNC_SDA4>,
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: mediatek: mt8395-radxa-nio-12l: Drop redundant i2c2 drive-strength
From: Ricardo Pardini via B4 Relay @ 2026-06-24 15:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Ricardo Pardini
In-Reply-To: <20260624-nio-12l-add-i2c-40-pin-v2-0-cf3707a6aaf1@pardini.net>
From: Ricardo Pardini <ricardo@pardini.net>
The i2c2_pins node specifies both drive-strength (mA, standard driving)
and drive-strength-microamp (uA, advanced driving). These are mutually
exclusive: the generic pinconf parser logs "cannot have multiple drive
strength properties" at boot, and on MediaTek the advanced driving enable
bit makes the uA value authoritative, leaving the mA value dead.
Drop the redundant drive-strength, keeping only drive-strength-microamp,
matching i2c4_pins.
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
Assisted-by: Claude:claude-opus-4-8 # vs Sashiko review of upcoming i2c3
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index bf91305e8e4a5..589a5f07d5dde 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -784,7 +784,6 @@ pins-bus {
pinmux = <PINMUX_GPIO12__FUNC_SDA2>,
<PINMUX_GPIO13__FUNC_SCL2>;
bias-pull-up = <1000>;
- drive-strength = <6>;
drive-strength-microamp = <1000>;
};
};
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable i2c3 on 40-pin header
From: Ricardo Pardini via B4 Relay @ 2026-06-24 15:45 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Ricardo Pardini
The Radxa NIO 12L exposes i2c3 (SDA3/SCL3, GPIO14/GPIO15) on its 40-pin
GPIO header, on the blue-colored pins 27 (SCL3) and 28 (SDA3).
Enable the i2c3 controller, add the matching pinctrl configuration and run
the bus at 400 kHz, matching the other I2C buses already enabled on this
board.
While at it, drop a pre-existing redundant drive-strength from i2c2_pins
that was also about to be copied into i2c3: specifying both drive-strength
(mA) and drive-strength-microamp (uA) makes the generic pinconf parser log
"cannot have multiple drive strength properties" at boot, and the advanced
(uA) setting wins in hardware, leaving the mA value dead.
Tested using a SD1306 I2C OLED display.
---
Changes in v2:
- Add a drive-by patch dropping the redundant drive-strength in i2c2_pins
(via Claude, reported by Sashiko).
- i2c3: use only drive-strength-microamp, as per Sashiko's review.
- Link to v1: https://patch.msgid.link/20260624-nio-12l-add-i2c-40-pin-v1-1-f6c11ed2184c@pardini.net
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: Ricardo Pardini <ricardo@pardini.net>
---
Ricardo Pardini (2):
arm64: dts: mediatek: mt8395-radxa-nio-12l: Drop redundant i2c2 drive-strength
arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable i2c3 on 40-pin header
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260624-nio-12l-add-i2c-40-pin-19e0482fd835
Best regards,
--
Ricardo Pardini <ricardo@pardini.net>
^ permalink raw reply
* Re: [PATCH 7/7] ARM: dts: rockchip: Add Alientek DLRV1126
From: Andrew Lunn @ 2026-06-24 15:44 UTC (permalink / raw)
To: Yanan He
Cc: robh, krzk+dt, conor+dt, heiko, andrew+netdev, davem, edumazet,
kuba, pabeni, david.wu, mcoquelin.stm32, alexandre.torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-7-dc42d99f75a7@gmail.com>
> The board consists of a CLRV1126F core module and a DLRV1126 carrier
> board. The core module contains the RV1126 SoC, eMMC and RK809 PMIC,
> while the carrier board provides Ethernet, SD card, AP6212 WiFi and
> Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and audio connectors.
>
> The board has been tested with Ethernet/NFS boot, eMMC, SD card, SDIO
> WiFi enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and
> RK809 audio card registration.
Ah, here is the networking nodes. But why was it not threaded to the
rest of the series?
> +&gmac {
> + phy-mode = "rgmii";
> + clock_in_out = "input";
> + assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
> + <&cru CLK_GMAC_ETHERNET_OUT>;
> + assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>,
> + <&cru RGMII_MODE_CLK>;
> + assigned-clock-rates = <125000000>, <0>, <25000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4
> + &clk_out_ethernetm1_pins>;
> + tx_delay = <0x2a>;
> + rx_delay = <0x1a>;
As i predicted, this is wrong.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
Please try removing rx_delay, rx_delay and setting phy-mode to
rgmii-id.
Andrew
^ permalink raw reply
* Re: [PATCH 6/7] ARM: dts: rockchip: Add RV1126 I2C5
From: Andrew Lunn @ 2026-06-24 15:42 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-6-5aef608a3f64@gmail.com>
On Wed, Jun 24, 2026 at 04:44:43PM +0800, Yanan He wrote:
> The controller is present in the SoC and can be used by boards for
> external peripherals, such as an RTC on the Alientek DLRV1126 carrier
> board.
This has nothing to do with networking, so please post it separately.
What i would actually like to see is the patch adding networking
nodes, because my guess is, you have the RGMII delays wrong.
Andrew
^ permalink raw reply
* Re: [PATCH 4/7] net: stmmac: dwmac-rk: Enable refout clock for RGMII
From: Andrew Lunn @ 2026-06-24 15:39 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue,
devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-4-5aef608a3f64@gmail.com>
On Wed, Jun 24, 2026 at 04:44:41PM +0800, Yanan He wrote:
> Some Rockchip GMAC integrations use clk_mac_refout as an external PHY
> reference clock even when the MAC is configured for RGMII.
>
> RV1126 boards can route CLK_GMAC_ETHERNET_OUT to the external PHY as a
> 25 MHz reference clock. If the driver does not acquire and enable this
> clock in RGMII mode, the common clock framework may disable it as unused
> and the PHY can lose its reference clock.
>
> Enable the refout clock handling for RGMII in addition to RMII.
>
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> index 8d7042e68926..f6fdc0c5b475 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
> @@ -1112,7 +1112,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
> bsp_priv->clk_enabled = false;
>
> bsp_priv->num_clks = ARRAY_SIZE(rk_clocks);
> - if (phy_iface == PHY_INTERFACE_MODE_RMII)
> + if (phy_iface == PHY_INTERFACE_MODE_RMII ||
> + phy_iface == PHY_INTERFACE_MODE_RGMII)
Apart from Heiko commenting that this patch is completely wrong, there
are 4 RGMII modes, not one. You should of used
phy_interface_mode_is_rgmii().
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: David Lechner @ 2026-06-24 15:27 UTC (permalink / raw)
To: Lukas, Andy Shevchenko
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-iio,
devicetree
In-Reply-To: <ajvt5J5Cs5cOdTLt@berta-MS-7693>
On 6/24/26 9:47 AM, Lukas wrote:
> Thanks a lot for all the comments.
>
> On Tue, Jun 23, 2026 at 10:39:23PM +0300, Andy Shevchenko wrote:
>
>>> + dev_dbg(dev, "%s: val=%d val2=%d\n", __func__, val, val2);
Trimming down the reply is good, but in this case, it would have been
helpful to leave a bit more context. I usually keep the full function
in a reply to have enough context if it isn't too long.
>>
>> No. Is it RFC? PoC? Or production-ready? If not the latter, come when it will
>> be production-ready.
>>
>
> I will remove the debug print. I tried my best to make this driver production-ready.
> I saw that other drivers also have similar debug messages so i didnt
This one jumped out to both of us as odd because of the __func__ and the
fact that it is in a very common operation (raw write). Usually debug is
for catching odd things that happen, not normal things.
> remove it after my first tests and thought it is ok to leave it in
> there. My intention was to try to apply the suggestions and comments i
> get and send a second revision. Do you think thats the right way?
Yes, you are doing it right. For a new driver like this, it is best
to wait about a week before submitting the next revision to give ample
time for review. Your replies so far where you think a suggestion was
wrong or have asked for clarification are spot on as to what we expect
for the review process.
^ permalink raw reply
* Re: [PATCH v5 14/16] media: iris: add Gen2 firmware support on the Agatti platform
From: Vikash Garodia @ 2026-06-24 15:24 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-14-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
>
> Agatti platform is using HFI Gen1 firmware, which is considered to be
> legacy firmware branch. Follow the example of the SC7280 platform and
> extend the driver with supporting both HFI Gen1 and Gen2 firmwares for
> this platform. Like HFI Gen1 this firmware doesn't have PIPE property
> (but unlike Gen1 buffer sizes are calculated on the driver side).
>
> Signed-off-by: Dikshita Agarwal<dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov<dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_hfi_gen2.c | 613 +++++++++++++++++++++
> .../platform/qcom/iris/iris_platform_common.h | 1 +
> .../platform/qcom/iris/iris_platform_vpu_ar50lt.c | 11 +-
> 3 files changed, 623 insertions(+), 2 deletions(-)
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-24 15:16 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <25d7d3a1-58e0-4f25-a73a-59a978130c47@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:
[...]
> > Why does it fail ? power management ? hw broken ? Is it really AMBA or
> > do you pretend that to be an AMBA device by faking the CID/PID?
>
> The CID reads as 0 from the register, which I suspect is a hardware design
> issue. I have not yet confirmed this with the hardware team. As a
> workaround, I provided a fake periphid via a DT property to bypass
> amba_read_periphid.
>
>
> Leo commented in other thread:
> >>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
> >>be registered as a platform device instead?
>
> The platform driver is intended for the interconnect TraceNoC device and is
> not designed to allocate an ATID. The issue is that the TPDM device borrows
> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
> associated with an interconnect NoC device.
>
> However, I believe it is acceptable to allocate an ATID for the itNoC device
> and the issue can be fixed with this way.
I think so.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: David Lechner @ 2026-06-24 15:13 UTC (permalink / raw)
To: Janani Sunil, Jonathan Cameron, Rodrigo Alencar
Cc: Nuno Sá, Conor Dooley, Janani Sunil, Lars-Peter Clausen,
Michael Hennerich, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan, linux-iio, devicetree, linux-kernel, linux-doc,
Mark Brown
In-Reply-To: <9abc53d0-432f-48fc-9e21-4d9a3c5e129f@gmail.com>
>>>>>
>>>>>> But yes, I do feel that the whole feature is for aggregation so seeing
>>>>>> one device with 32 channels is the expectation here? Rather than seeing
>>>>>> two devices with 16 channels.
>>>>> Yes, I think aggregation is the whole point there... so that the IIO driver
>>>>> is multi-device-aware.
>>>> Which makes me feel that different pins per device might be possible
>>>> from an HW point of view but does not make much sense. For example, for
>>>> the buffer example I would expect LDAC to be shared between all the
>>>> devices.
>>> That is why I would still suggest the multi-dac node in the middle...
>>> the parent node can hold shared resources, while the dac children can
>>> have their own, overriding or inheriting stuff.
>>>
>> Before going down that path I'd want confirmation this is something we
>> actually think anyone will build.
>>
>> Jonathan
>
> To directly answer your question- we currently do not have a platform that supports multi device topology with independent supplies or reset lines.
> Given that, I agree to start with the parallel wiring assumption and defer per chip resource variation under there is a solid use case. I will also drop the "adi,resolution" proposal and proceed with "adi,device-addrs" in the AD5529R binding.
> With all of the above, the proposed binding for the multi-device follow up series would look like:
>
>
> dac@0 {
> compatible = "adi,ad5529r-16";
> reg = <0>;
> adi,device-addrs = <0 1>;
> reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> vdd-supply = <&vdd_reg>;
> hvdd-supply = <&hvdd_reg>;
>
> channel@0 { reg = <0>; adi,output-range-microvolt = <0 5000000>; };
> channel@16 { reg = <16>; adi,output-range-microvolt = <0 40000000>; };
> };
>
> Does this look reasonable to everyone?
>
> Regards,
> Janani Sunil
>
LGTM. Seems like the simplest way to handle it and should cover most
use cases.
^ permalink raw reply
* Re: [PATCH v5 13/16] media: iris: Introduce buffer size calculations for AR50LT
From: Vikash Garodia @ 2026-06-24 15:10 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-13-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> Introduces AR50LT buffer size calculation for both encoder and
> decoder. Reuse the buffer size calculation which are common, while
> adding the AR50LT specific ones separately.
>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 401 +++++++++++++++++++++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 37 ++
> 2 files changed, 438 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> index 4a39b8fef52b..ca03d6570513 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> @@ -50,6 +50,32 @@ static u32 hfi_buffer_bin_h264d(u32 frame_width, u32 frame_height, u32 num_vpp_p
> return size_h264d_hw_bin_buffer(n_aligned_w, n_aligned_h, num_vpp_pipes);
> }
>
> +static u32 size_h264d_hw_bin_buffer_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_yuv, size_bin_hdr, size_bin_res;
> +
> + size_yuv = ((frame_width * frame_height * 3) >> 1);
> + if (size_yuv <= 1920 * 1088 * 3 / 2) {
> + size_bin_hdr = size_yuv * H264_CABAC_HDR_RATIO_SM_TOT;
> + size_bin_res = size_yuv * H264_CABAC_RES_RATIO_SM_TOT;
> + } else {
> + size_bin_hdr = (size_yuv * 3) / 5;
> + size_bin_res = (size_yuv * 3) / 2;
> + }
> + size_bin_hdr = ALIGN(size_bin_hdr, DMA_ALIGNMENT);
> + size_bin_res = ALIGN(size_bin_res, DMA_ALIGNMENT);
> +
> + return size_bin_hdr + size_bin_res;
> +}
> +
> +static u32 hfi_buffer_bin_h264d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 n_aligned_h = ALIGN(frame_height, 16);
> + u32 n_aligned_w = ALIGN(frame_width, 16);
> +
> + return size_h264d_hw_bin_buffer_ar50lt(n_aligned_w, n_aligned_h, num_vpp_pipes);
> +}
> +
> static u32 size_av1d_hw_bin_buffer(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> {
> u32 size_yuv, size_bin_hdr, size_bin_res;
> @@ -103,6 +129,21 @@ static u32 hfi_buffer_bin_vp9d(u32 frame_width, u32 frame_height, u32 num_vpp_pi
> return _size * num_vpp_pipes;
> }
>
> +static u32 hfi_buffer_bin_vp9d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_yuv, size;
> +
> + size_yuv = ALIGN(frame_width, 16) * ALIGN(frame_height, 16) * 3 / 2;
> + size_yuv = ALIGN(size_yuv, DMA_ALIGNMENT);
> +
> + size = ALIGN(((((MAX(size_yuv, VPX_DECODER_FRAME_BIN_BUFFER_SIZE)) * 6) / 5) /
MAX() or max() ?
> + num_vpp_pipes), DMA_ALIGNMENT) +
> + ALIGN((((MAX(size_yuv, VPX_DECODER_FRAME_BIN_BUFFER_SIZE)) * 4) / num_vpp_pipes),
> + DMA_ALIGNMENT);
> +
> + return size * num_vpp_pipes;
> +}
> +
> static u32 hfi_buffer_bin_h265d(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> {
> u32 n_aligned_w = ALIGN(frame_width, 16);
> @@ -111,6 +152,32 @@ static u32 hfi_buffer_bin_h265d(u32 frame_width, u32 frame_height, u32 num_vpp_p
> return size_h265d_hw_bin_buffer(n_aligned_w, n_aligned_h, num_vpp_pipes);
> }
>
> +static u32 size_h265d_hw_bin_buffer_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_yuv, size_bin_hdr, size_bin_res;
> +
> + size_yuv = ((frame_width * frame_height * 3) >> 1);
> + if (size_yuv <= ((BIN_BUFFER_THRESHOLD * 3) >> 1)) {
> + size_bin_hdr = size_yuv * H265_CABAC_HDR_RATIO_SM_TOT;
> + size_bin_res = size_yuv * H265_CABAC_RES_RATIO_SM_TOT;
> + } else {
> + size_bin_hdr = (size_yuv * 41) / 50;
> + size_bin_res = (size_yuv * 59) / 50;
> + }
> + size_bin_hdr = ALIGN(size_bin_hdr, DMA_ALIGNMENT);
> + size_bin_res = ALIGN(size_bin_res, DMA_ALIGNMENT);
> +
> + return size_bin_hdr + size_bin_res;
> +}
> +
> +static u32 hfi_buffer_bin_h265d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 n_aligned_w = ALIGN(frame_width, 16);
> + u32 n_aligned_h = ALIGN(frame_height, 16);
> +
> + return size_h265d_hw_bin_buffer_ar50lt(n_aligned_w, n_aligned_h, num_vpp_pipes);
> +}
> +
> static u32 hfi_buffer_comv_h264d(u32 frame_width, u32 frame_height, u32 _comv_bufcount)
> {
> u32 frame_height_in_mbs = DIV_ROUND_UP(frame_height, 16);
> @@ -174,6 +241,14 @@ static u32 size_h264d_bse_cmd_buf(u32 frame_height)
> SIZE_H264D_BSE_CMD_PER_BUF;
> }
>
> +static u32 size_h264d_bse_cmd_buf_ar50lt(u32 frame_height)
> +{
> + u32 height = ALIGN(frame_height, 32);
> +
> + return min_t(u32, (DIV_ROUND_UP(height, 16) * 12), H264D_MAX_SLICE) *
> + SIZE_H264D_BSE_CMD_PER_BUF;
> +}
> +
> static u32 size_h265d_bse_cmd_buf(u32 frame_width, u32 frame_height)
> {
> u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> @@ -185,6 +260,18 @@ static u32 size_h265d_bse_cmd_buf(u32 frame_width, u32 frame_height)
> return _size;
> }
>
> +static u32 size_h265d_bse_cmd_buf_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> + (ALIGN(frame_height, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS)) *
> + NUM_HW_PIC_BUF, DMA_ALIGNMENT);
> +
> + _size = min_t(u32, _size, H265D_MAX_SLICE_AR50LT + 1);
> + _size = 2 * _size * SIZE_H265D_BSE_CMD_PER_BUF;
> +
> + return _size;
> +}
> +
> static u32 hfi_buffer_persist_h265d(u32 rpu_enabled)
> {
> return ALIGN((SIZE_SLIST_BUF_H265 * NUM_SLIST_BUF_H265 +
> @@ -195,6 +282,13 @@ static u32 hfi_buffer_persist_h265d(u32 rpu_enabled)
> DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_persist_h265d_ar50lt(void)
> +{
> + return ALIGN((SIZE_SLIST_BUF_H265 * NUM_SLIST_BUF_H265 +
> + H265_NUM_TILE * sizeof(u32) + NUM_HW_PIC_BUF * SIZE_SEI_USERDATA),
> + DMA_ALIGNMENT);
> +}
> +
> static inline
> u32 hfi_iris3_vp9d_comv_size(void)
> {
> @@ -212,6 +306,13 @@ static u32 hfi_buffer_persist_vp9d(void)
> HDR10_HIST_EXTRADATA_SIZE;
> }
>
> +static u32 hfi_buffer_persist_vp9d_ar50lt(void)
> +{
> + return ALIGN(VP9_NUM_PROBABILITY_TABLE_BUF * VP9_PROB_TABLE_SIZE, DMA_ALIGNMENT) +
> + ALIGN(hfi_iris3_vp9d_comv_size(), DMA_ALIGNMENT) +
> + ALIGN(MAX_SUPERFRAME_HEADER_LEN, DMA_ALIGNMENT);
> +}
> +
> static u32 size_h264d_vpp_cmd_buf(u32 frame_height)
> {
> u32 size, height = ALIGN(frame_height, 32);
> @@ -222,6 +323,16 @@ static u32 size_h264d_vpp_cmd_buf(u32 frame_height)
> return size > VPP_CMD_MAX_SIZE ? VPP_CMD_MAX_SIZE : size;
> }
>
> +static u32 size_h264d_vpp_cmd_buf_ar50lt(u32 frame_height)
> +{
> + u32 size, height = ALIGN(frame_height, 32);
> +
> + size = min_t(u32, (DIV_ROUND_UP(height, 16) * 12), H264D_MAX_SLICE) *
> + SIZE_H264D_VPP_CMD_PER_BUF;
> +
> + return size > VPP_CMD_MAX_SIZE ? VPP_CMD_MAX_SIZE : size;
> +}
> +
> static u32 hfi_buffer_persist_h264d(void)
> {
> return ALIGN(SIZE_SLIST_BUF_H264 * NUM_SLIST_BUF_H264 +
> @@ -230,6 +341,11 @@ static u32 hfi_buffer_persist_h264d(void)
> DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_persist_h264d_ar50lt(void)
> +{
> + return ALIGN((SIZE_SLIST_BUF_H264 * NUM_SLIST_BUF_H264), DMA_ALIGNMENT);
> +}
> +
> static u32 hfi_buffer_persist_av1d(u32 max_width, u32 max_height, u32 total_ref_count)
> {
> u32 comv_size, size;
> @@ -255,6 +371,17 @@ static u32 hfi_buffer_non_comv_h264d(u32 frame_width, u32 frame_height, u32 num_
> return ALIGN(size, DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_non_comv_h264d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_bse = size_h264d_bse_cmd_buf_ar50lt(frame_height);
> + u32 size_vpp = size_h264d_vpp_cmd_buf_ar50lt(frame_height);
> + u32 size = ALIGN(size_bse, DMA_ALIGNMENT) +
> + ALIGN(size_vpp, DMA_ALIGNMENT) +
> + ALIGN(SIZE_HW_PIC(SIZE_H264D_HW_PIC_T), DMA_ALIGNMENT);
> +
> + return ALIGN(size, DMA_ALIGNMENT);
> +}
> +
> static u32 size_h265d_vpp_cmd_buf(u32 frame_width, u32 frame_height)
> {
> u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> @@ -269,6 +396,20 @@ static u32 size_h265d_vpp_cmd_buf(u32 frame_width, u32 frame_height)
> return _size;
> }
>
> +static u32 size_h265d_vpp_cmd_buf_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> + (ALIGN(frame_height, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS)) *
> + NUM_HW_PIC_BUF, DMA_ALIGNMENT);
> + _size = min_t(u32, _size, H265D_MAX_SLICE_AR50LT + 1);
> + _size = ALIGN(_size, 4);
> + _size = 2 * _size * SIZE_H265D_VPP_CMD_PER_BUF_AR50LT;
> + if (_size > VPP_CMD_MAX_SIZE)
> + _size = VPP_CMD_MAX_SIZE;
> +
> + return _size;
> +}
> +
> static u32 hfi_buffer_non_comv_h265d(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> {
> u32 _size_bse = size_h265d_bse_cmd_buf(frame_width, frame_height);
> @@ -285,6 +426,20 @@ static u32 hfi_buffer_non_comv_h265d(u32 frame_width, u32 frame_height, u32 num_
> return ALIGN(_size, DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_non_comv_h265d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 _size_bse = size_h265d_bse_cmd_buf_ar50lt(frame_width, frame_height);
> + u32 _size_vpp = size_h265d_vpp_cmd_buf_ar50lt(frame_width, frame_height);
> + u32 _size = ALIGN(_size_bse, DMA_ALIGNMENT) +
> + ALIGN(_size_vpp, DMA_ALIGNMENT) +
> + ALIGN(2 * sizeof(u16) *
> + (ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> + (ALIGN(frame_height, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS), DMA_ALIGNMENT) +
> + ALIGN(SIZE_HW_PIC(SIZE_H265D_HW_PIC_T), DMA_ALIGNMENT);
> +
> + return ALIGN(_size, DMA_ALIGNMENT);
> +}
> +
> static u32 size_vpss_lb(u32 frame_width, u32 frame_height)
> {
> u32 opb_lb_wr_llb_y_buffer_size, opb_lb_wr_llb_uv_buffer_size;
> @@ -317,6 +472,13 @@ u32 size_h265d_lb_fe_top_data(u32 frame_width, u32 frame_height)
> (ALIGN(frame_width, 64) + 8) * 2;
> }
>
> +static inline
> +u32 size_h265d_lb_fe_top_data_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return ALIGN(MAX_FE_NBR_DATA_LUMA_LINE_BUFFER_SIZE *
> + (ALIGN(frame_width, 64) + 8), DMA_ALIGNMENT) * 2;
> +}
> +
> static inline
> u32 size_h265d_lb_fe_top_ctrl(u32 frame_width, u32 frame_height)
> {
> @@ -348,6 +510,17 @@ u32 size_h265d_lb_se_left_ctrl(u32 frame_width, u32 frame_height)
> MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
> }
>
> +static inline
> +u32 size_h265d_lb_se_left_ctrl_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return max_t(u32, ((frame_height + 16 - 1) / 8) *
> + MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE_AR50LT,
> + max_t(u32, ((frame_height + 32 - 1) / 8) *
> + MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE_AR50LT,
> + ((frame_height + 64 - 1) / 8) *
> + MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE_AR50LT));
> +}
> +
> static inline
> u32 size_h265d_lb_pe_top_data(u32 frame_width, u32 frame_height)
> {
> @@ -355,6 +528,13 @@ u32 size_h265d_lb_pe_top_data(u32 frame_width, u32 frame_height)
> (ALIGN(frame_width, LCU_MIN_SIZE_PELS) / LCU_MIN_SIZE_PELS);
> }
>
> +static inline
> +u32 size_h265d_lb_pe_top_data_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return MAX_PE_NBR_DATA_LCU64_LINE_BUFFER_SIZE_AR50LT *
> + (ALIGN(frame_width, LCU_MIN_SIZE_PELS) / LCU_MIN_SIZE_PELS);
> +}
> +
> static inline
> u32 size_h265d_lb_vsp_top(u32 frame_width, u32 frame_height)
> {
> @@ -404,6 +584,29 @@ u32 hfi_buffer_line_h265d(u32 frame_width, u32 frame_height, bool is_opb, u32 nu
> return ALIGN((_size + vpss_lb_size), DMA_ALIGNMENT);
> }
>
> +static inline
> +u32 hfi_buffer_line_h265d_ar50lt(u32 frame_width, u32 frame_height, bool is_opb, u32 num_vpp_pipes)
> +{
> + u32 size;
> +
> + size = ALIGN(size_h265d_lb_fe_top_data_ar50lt(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_fe_top_ctrl(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_fe_left_ctrl(frame_width, frame_height),
> + DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h265d_lb_se_left_ctrl_ar50lt(frame_width, frame_height),
> + DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h265d_lb_se_top_ctrl(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_pe_top_data_ar50lt(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_vsp_top(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_vsp_left(frame_width, frame_height),
> + DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h265d_lb_recon_dma_metadata_wr(frame_width, frame_height),
> + DMA_ALIGNMENT) * 4 +
> + ALIGN(size_h265d_qp(frame_width, frame_height), DMA_ALIGNMENT);
> +
> + return ALIGN(size, DMA_ALIGNMENT);
> +}
> +
> static inline
> u32 size_vpxd_lb_fe_left_ctrl(u32 frame_width, u32 frame_height)
> {
> @@ -438,6 +641,17 @@ u32 size_vpxd_lb_se_left_ctrl(u32 frame_width, u32 frame_height)
> MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
> }
>
> +static inline
> +u32 size_vpxd_lb_se_left_ctrl_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return max_t(u32, ((frame_height + 15) >> 4) *
> + MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE_AR50LT,
> + max_t(u32, ((frame_height + 31) >> 5) *
> + MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE_AR50LT,
> + ((frame_height + 63) >> 6) *
> + MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE_AR50LT));
> +}
> +
> static inline
> u32 size_vpxd_lb_recon_dma_metadata_wr(u32 frame_width, u32 frame_height)
> {
> @@ -492,6 +706,19 @@ u32 hfi_iris3_vp9d_lb_size(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> ALIGN(size_vp9d_qp(frame_width, frame_height), DMA_ALIGNMENT);
> }
>
> +static inline
> +u32 hfi_ar50lt_vp9d_lb_size(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + return ALIGN(size_vpxd_lb_fe_left_ctrl(frame_width, frame_height), DMA_ALIGNMENT) *
> + num_vpp_pipes +
> + ALIGN(size_vpxd_lb_se_left_ctrl_ar50lt(frame_width, frame_height), DMA_ALIGNMENT) *
> + num_vpp_pipes +
> + ALIGN(size_vp9d_lb_vsp_top(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_vpxd_lb_se_top_ctrl(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_vp9d_lb_pe_top_data(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_vp9d_lb_fe_top_data(frame_width, frame_height), DMA_ALIGNMENT);
> +}
> +
> static inline
> u32 hfi_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yuv_bufcount_min, bool is_opb,
> u32 num_vpp_pipes)
> @@ -507,6 +734,13 @@ u32 hfi_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yuv_bufcount_mi
> return _lb_size + vpss_lb_size + 4096;
> }
>
> +static inline
> +u32 hfi_buffer_line_vp9d_ar50lt(u32 frame_width, u32 frame_height, u32 _yuv_bufcount_min,
> + bool is_opb, u32 num_vpp_pipes)
> +{
> + return hfi_ar50lt_vp9d_lb_size(frame_width, frame_height, num_vpp_pipes);
pls keep same name across like "hfi_buffer_line_vp9d_ar50lt" and
"hfi_ar50lt_vp9d_lb_size" or combine these 2 apis, as the one just calls
the other.
> +}
> +
> static u32 hfi_buffer_line_h264d(u32 frame_width, u32 frame_height,
> bool is_opb, u32 num_vpp_pipes)
> {
> @@ -529,6 +763,25 @@ static u32 hfi_buffer_line_h264d(u32 frame_width, u32 frame_height,
> return ALIGN((size + vpss_lb_size), DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_line_h264d_ar50lt(u32 frame_width, u32 frame_height,
> + bool is_opb, u32 num_vpp_pipes)
> +{
> + u32 size;
> +
> + size = ALIGN(size_h264d_lb_fe_top_data_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_fe_top_ctrl_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_fe_left_ctrl(frame_height), DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h264d_lb_se_top_ctrl_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_se_left_ctrl_ar50lt(frame_height), DMA_ALIGNMENT) *
> + num_vpp_pipes +
> + ALIGN(size_h264d_lb_pe_top_data_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_vsp_top(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_recon_dma_metadata_wr(frame_height), DMA_ALIGNMENT) * 2 +
> + ALIGN(size_h264d_qp(frame_width, frame_height), DMA_ALIGNMENT);
> +
> + return ALIGN(size, DMA_ALIGNMENT);
> +}
> +
> static u32 size_av1d_lb_opb_wr1_nv12_ubwc(u32 frame_width, u32 frame_height)
> {
> u32 size, y_width, y_width_a = 128;
> @@ -724,6 +977,23 @@ static u32 iris_vpu_dec_bin_size(struct iris_inst *inst)
> return 0;
> }
>
> +static u32 iris_vpu_ar50lt_dec_bin_size(struct iris_inst *inst)
> +{
> + u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
> + struct v4l2_format *f = inst->fmt_src;
> + u32 height = f->fmt.pix_mp.height;
> + u32 width = f->fmt.pix_mp.width;
> +
> + if (inst->codec == V4L2_PIX_FMT_H264)
> + return hfi_buffer_bin_h264d_ar50lt(width, height, num_vpp_pipes);
> + else if (inst->codec == V4L2_PIX_FMT_HEVC)
> + return hfi_buffer_bin_h265d_ar50lt(width, height, num_vpp_pipes);
> + else if (inst->codec == V4L2_PIX_FMT_VP9)
> + return hfi_buffer_bin_vp9d_ar50lt(width, height, num_vpp_pipes);
> +
> + return 0;
> +}
> +
> static u32 iris_vpu_dec_comv_size(struct iris_inst *inst)
> {
> u32 num_comv = VIDEO_MAX_FRAME;
> @@ -785,6 +1055,18 @@ static u32 iris_vpu_dec_persist_size(struct iris_inst *inst)
> return 0;
> }
>
> +static u32 iris_vpu_ar50lt_dec_persist_size(struct iris_inst *inst)
> +{
> + if (inst->codec == V4L2_PIX_FMT_H264)
> + return hfi_buffer_persist_h264d_ar50lt();
> + else if (inst->codec == V4L2_PIX_FMT_HEVC)
> + return hfi_buffer_persist_h265d_ar50lt();
> + else if (inst->codec == V4L2_PIX_FMT_VP9)
> + return hfi_buffer_persist_vp9d_ar50lt();
> +
> + return 0;
> +}
> +
> static u32 iris_vpu_dec_dpb_size(struct iris_inst *inst)
> {
> if (iris_split_mode_enabled(inst))
> @@ -808,6 +1090,21 @@ static u32 iris_vpu_dec_non_comv_size(struct iris_inst *inst)
> return 0;
> }
>
> +static u32 iris_vpu_ar50lt_dec_non_comv_size(struct iris_inst *inst)
> +{
> + u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
neither of below api uses this variable ?
> + struct v4l2_format *f = inst->fmt_src;
> + u32 height = f->fmt.pix_mp.height;
> + u32 width = f->fmt.pix_mp.width;
> +
> + if (inst->codec == V4L2_PIX_FMT_H264)
> + return hfi_buffer_non_comv_h264d_ar50lt(width, height, num_vpp_pipes);
> + else if (inst->codec == V4L2_PIX_FMT_HEVC)
> + return hfi_buffer_non_comv_h265d_ar50lt(width, height, num_vpp_pipes);
> +
> + return 0;
> +}
> +
> static u32 iris_vpu_dec_line_size(struct iris_inst *inst)
> {
> u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
> @@ -833,6 +1130,29 @@ static u32 iris_vpu_dec_line_size(struct iris_inst *inst)
> return 0;
> }
>
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
From: Jonathan Cameron @ 2026-06-24 15:09 UTC (permalink / raw)
To: me
Cc: github.com, Andy Shevchenko, David Lechner, Nuno Sá,
Andy Shevchenko, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Denis Ciocca, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Denis Ciocca,
Linus Walleij, linux-iio, linux-kernel, llvm, devicetree
In-Reply-To: <edcf262b530a88ee602fa07edc8382ac@herrie.org>
On Wed, 24 Jun 2026 06:18:45 +0200
me@herrie.org wrote:
> On 2026-06-23 21:49, Andy Shevchenko wrote:
> > On Tue, Jun 23, 2026 at 08:29:16PM +0100, Jonathan Cameron wrote:
> >> On Tue, 16 Jun 2026 15:02:06 +0200
> >> Herman van Hazendonk <github.com@herrie.org> wrote:
> >>
> >> > The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
> >> > highest-sensitivity full-scale supported by the chip -- as the
> >> > starting range. For the LSM303DLH that is +/-1.3 G; for the
> >> > LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
> >> >
> >> > That is the right default for "minimal noise floor at a desk", but
> >> > it leaves no margin for boards that pick up appreciable DC bias from
> >> > nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
> >> > LSM303DLH magnetometer is mounted close enough to the surrounding
> >> > power planes that X reads back as the chip's 0xF000 overflow
> >> > sentinel (== -4096 raw, the value the chip publishes when the ADC
> >> > saturates) on every sample at the chip-default range, while Y and Z
> >> > fall well within the +/-1.3 G window.
> >> >
> >> > Parse the st,fullscale-milligauss device-tree property (documented
> >> > separately in dt-bindings/iio/st,st-sensors.yaml) in the
> >> > magnetometer common probe to select the initial fs_avl entry by its
> >> > mg value. The DT binding pins the accepted value set per compatible
> >> > via allOf/if-then enum clauses, so a malformed mg value fails
> >> > dt_binding_check rather than reaching the driver. Sensors with a
> >> > fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
> >> > register to switch and the property is rejected outright for them
> >> > in the binding; the parse block is additionally gated on fs.addr as
> >> > defence in depth against stale DTBs.
> >> >
> >> > Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
> >> > LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
> >> > 4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
> >> > they are 4000, 8000, 12000, 16000.
> >> >
> >> > Empirical scale sweep on the HP TouchPad confirmed that on this
> >> > board any fs_avl >= 1 produces non-saturated X readings:
> >> >
> >> > scale (0.001 G/LSB) | X raw Y raw Z raw
> >> > --------------------+-------------------------------
> >> > 1.100 | -4096 44 46 (X saturated)
> >> > 0.855 | -547 37 37 (clean)
> >> > 0.670 | -433 94 103 (clean)
> >> > 0.450 | -266 44 71 (clean)
> >> > 0.400 | -235 34 65 (clean)
> >> > 0.330 | -196 27 56 (clean)
> >> > 0.230 | -145 15 40 (clean)
> >> >
> >> > 2500 mg is the natural choice for tenderloin: comfortably outside
> >> > the saturation regime while keeping useful precision for compass
> >> > applications.
> >> >
> >> > Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch
> >> > Assisted-by: Sashiko:claude-opus-4-7
> >> Hmm. First time I remember seeing Sashiko credited like this. Seems
> >> like pretty much
> >> every patch series of any complexity would end up crediting sashiko.
> >> Out of curiosity were you just looking at reports, or were you running
> >> it locally to
> >> help with development?
> >
> > I believe it's the second one, because LKML version uses Gemini (as far
> > as I
> > understand the case). At least that's why I haven't commented on this
> > tag.
> I have the whole toolchain running locally to avoid too many submissions
> and
> feedback from Sashiko with Gemini after submitting. For small drivers I
> can run
> Gemini locally as well, usually stick with Claude Opus 4.7 since that's
> what I
> have a subscription for. For very complicated and large drivers Claude
> Opus
> tends to time out even with 1 or 2 hour, so I fall back to Claude Haiku
> 4.5
> (which catches quite a few things, but is not as thorough as Opus or
> Gemini).
>
> Seeing Sashiko tends to provide different feedback on different rounds,
> I try
> to only submit when Sashiko and all others are clean.
>
> Hope this clarifies!
Thank! I loose track of all these models :) So the summary is very
useful. I've been meaning to get a similar flow in place myself for
checking local stuff (not that I'm doing any development at the moment)
Jonathan
>
> Herman
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 15:08 UTC (permalink / raw)
To: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <471d7a92-3629-4274-a303-8906d3626037@arm.com>
On 6/24/2026 9:51 PM, Suzuki K Poulose wrote:
> On 24/06/2026 14:48, Jie Gan wrote:
>>
>>
>> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>>> its probe function if the arm,primecell-periphid property is absent.
>>>> This causes a deferred probe issue for the TraceNoC device, as the
>>>> CID/PID cannot be read from the periphid register.
>>>
>>> Why does it probe defer?
>>>
>>
>> For an AMBA device, the periphid is mandatory for probing. In the
>> amba_match function, AMBA attempts to read the periphid from the CID/
>> PID registers if the arm,primecell-periphid property is absent in the
>> device tree. If this read fails, it returns -EPROBE_DEFER, and the
>> probe ultimately fails.
>
> Why does it fail ? power management ? hw broken ? Is it really AMBA or
> do you pretend that to be an AMBA device by faking the CID/PID?
The CID reads as 0 from the register, which I suspect is a hardware
design issue. I have not yet confirmed this with the hardware team. As a
workaround, I provided a fake periphid via a DT property to bypass
amba_read_periphid.
Leo commented in other thread:
>>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't
>>it
>>be registered as a platform device instead?
The platform driver is intended for the interconnect TraceNoC device and
is not designed to allocate an ATID. The issue is that the TPDM device
borrows the ATID from the TraceNoC device, resulting in the ATID always
being 0 when associated with an interconnect NoC device.
However, I believe it is acceptable to allocate an ATID for the itNoC
device and the issue can be fixed with this way.
Thanks,
Jie
>
> Suzuki
>
>
>> Most AMBA devices expose valid CID/PID registers, so specifying
>> arm,primecell-periphid in the device tree is usually unnecessary.
>> However, for the TraceNoC device in this case, AMBA cannot reliably
>> read the periphid from the corresponding registers.
>>
>>> And is this required for all TNOC devices?
>>
>> So far, the TNOC device has been added to sm8750, Glymur, and
>> Kaanapali platforms, and all exhibit probe failures due to the same
>> root cause.
>>
>> I prefer to fix it on Kaanapali first.
>>
>> Thanks,
>> Jie
>>
>>>
>>> Konrad
>>
>
^ permalink raw reply
* Re: [PATCH v5 2/3] clk: qcom: camcc-glymur: Add camera clock controller driver
From: sashiko-bot @ 2026-06-24 15:08 UTC (permalink / raw)
To: Jagadeesh Kona; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260624-glymur_camcc-v5-2-a321df74b1a1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect register offsets for CSI4 clocks due to a copy-paste error.
- [High] Missing `cam_cc_pll2_out_even` struct definition resulting in incorrect CCF frequency calculation for EVEN PLL output.
--
commit 4ff3f366f401331dcb96c0eb65a3236a34345740
Author: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
clk: qcom: camcc-glymur: Add camera clock controller driver
Add support for the camera clock controller for camera clients
to be able to request for camcc clocks on Glymur platform.
> diff --git a/drivers/clk/qcom/camcc-glymur.c b/drivers/clk/qcom/camcc-glymur.c
> new file mode 100644
> index 0000000000000..a80f05b7bc484
> --- /dev/null
> +++ b/drivers/clk/qcom/camcc-glymur.c
[ ... ]
> @@ -0,0 +1,2280 @@
[ ... ]
> +static const struct parent_map cam_cc_parent_map_1[] = {
> + { P_BI_TCXO, 0 },
> + { P_CAM_CC_PLL2_OUT_EVEN, 3 },
> + { P_CAM_CC_PLL2_OUT_MAIN, 5 },
> +};
> +
> +static const struct clk_parent_data cam_cc_parent_data_1[] = {
> + { .index = DT_BI_TCXO },
> + { .hw = &cam_cc_pll2.clkr.hw },
> + { .hw = &cam_cc_pll2.clkr.hw },
[Severity: High]
Does this code miss the cam_cc_pll2_out_even struct definition?
Index 1 should point to &cam_cc_pll2_out_even.clkr.hw to represent the divided
EVEN output of the PLL. The duplicated pointer results in the Common Clock
Framework seeing the raw PLL rate without division. When a clock relying on this
parent map switches to the EVEN hardware mux, the framework might calculate the
downstream clock is running at twice its actual hardware frequency.
> +};
[ ... ]
> +static struct clk_rcg2 cam_cc_csi4phytimer_clk_src = {
> + .cmd_rcgr = 0x15124,
[Severity: High]
Are these register offsets correct for the CSI4 PHY timer clock source?
On identical or highly similar reference hardware designs, offsets 0x15124,
0x15250, and 0x15254 map to the CSI2 PHY branch and timer clocks, while
CSI4 is typically mapped to 0x1538c, 0x154b8, and 0x154bc.
Writing configuration to these offsets for CSI4 might incorrectly modify CSI2
clock registers, preventing the CSI4 camera interface from being clocked
properly and potentially inducing unintended behavior on the CSI2 IP block.
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = cam_cc_parent_map_0,
> + .freq_tbl = ftbl_cam_cc_csi0phytimer_clk_src,
[ ... ]
> +static struct clk_branch cam_cc_csi4phytimer_clk = {
> + .halt_reg = 0x15250,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x15250,
[Severity: High]
Could this offset be incorrect as well? As mentioned above, 0x15250 usually
corresponds to the CSI2 PHY timer branch clock.
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "cam_cc_csi4phytimer_clk",
[ ... ]
> +static struct clk_branch cam_cc_csiphy4_clk = {
> + .halt_reg = 0x15254,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x15254,
[Severity: High]
Is this the correct offset for the CSI4 PHY branch clock? It seems this might
also be pointing to the CSI2 PHY branch clock.
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "cam_cc_csiphy4_clk",
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-glymur_camcc-v5-0-a321df74b1a1@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH V13 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: Jonathan Cameron @ 2026-06-24 15:06 UTC (permalink / raw)
To: Chris Morgan
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <PH0PR19MB99733833C502FDB1FA4927B8DEA5EE2@PH0PR19MB997338.namprd19.prod.outlook.com>
On Tue, 23 Jun 2026 13:08:02 -0500
Chris Morgan <macromorgan@hotmail.com> wrote:
> On Mon, Jun 22, 2026 at 09:34:10PM -0500, Chris Morgan wrote:
> > On Sun, Jun 21, 2026 at 06:19:48PM +0100, Jonathan Cameron wrote:
> > > On Mon, 15 Jun 2026 12:25:48 -0500
> > > Chris Morgan <macroalpha82@gmail.com> wrote:
> > >
> > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > >
> > > > Add power management support for the ICM42607 device driver.
> > > >
> > > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > > A few things from taking a look at the sashiko report:
> > > https://sashiko.dev/#/patchset/20260615172554.160910-1-macroalpha82%40gmail.com
> > >
> > > > ---
> > > > drivers/iio/imu/inv_icm42607/inv_icm42607.h | 18 +++
> > > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 139 ++++++++++++++++++
> > > > .../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 1 +
> > > > .../iio/imu/inv_icm42607/inv_icm42607_spi.c | 1 +
> > > > 4 files changed, 159 insertions(+)
> > > >
> > > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > > index a6a58571935f..4f4f541027dc 100644
> > > > --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > >
> > > > @@ -334,11 +345,18 @@ struct inv_icm42607_state {
> > > > #define INV_ICM42607_GYRO_STOP_TIME_MS 45
> > > > #define INV_ICM42607_TEMP_STARTUP_TIME_MS 77
> > > >
> > > > +/*
> > > > + * Suspend delay assumed from other icm42600 series device, not
> > > > + * documented in datasheet.
> > > > + */
> > > > +#define INV_ICM42607_SUSPEND_DELAY_MS (2 * USEC_PER_MSEC)
> > >
> > > Sashiko had a valid comment on this. MSEC_PER_SEC seems more
> > > appropriate given this is 2 seconds in milli seconds.
> > >
> > > > +
> > > > typedef int (*inv_icm42607_bus_setup)(struct inv_icm42607_state *);
> > > >
> > > > extern const struct regmap_config inv_icm42607_regmap_config;
> > > > extern const struct inv_icm42607_hw inv_icm42607_hw_data;
> > > > extern const struct inv_icm42607_hw inv_icm42607p_hw_data;
> > > > +extern const struct dev_pm_ops inv_icm42607_pm_ops;
> > > >
> > > > int inv_icm42607_core_probe(struct regmap *regmap,
> > > > const struct inv_icm42607_hw *hw,
> > > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > index 4b8e19091786..64f5d263de4f 100644
> > > > --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > @@ -4,6 +4,7 @@
> > > > */
> > > >
> > > > #include <linux/bitfield.h>
> > > > +#include <linux/cleanup.h>
> > > > #include <linux/delay.h>
> > > > #include <linux/dev_printk.h>
> > > > #include <linux/device/devres.h>
> > > > @@ -11,6 +12,7 @@
> > > > #include <linux/iio/iio.h>
> > > > #include <linux/module.h>
> > > > #include <linux/mutex.h>
> > > > +#include <linux/pm_runtime.h>
> > > > #include <linux/regmap.h>
> > > > #include <linux/regulator/consumer.h>
> > > > #include <linux/time.h>
> > > > @@ -103,6 +105,63 @@ const struct inv_icm42607_hw inv_icm42607p_hw_data = {
> > > > };
> > > > EXPORT_SYMBOL_NS_GPL(inv_icm42607p_hw_data, "IIO_ICM42607");
> > > >
> > > > +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> > > > + enum inv_icm42607_sensor_mode gyro,
> > > > + enum inv_icm42607_sensor_mode accel,
> > > > + bool temp, unsigned int *sleep_ms)
> > > > +{
> > > > + enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
> > > > + enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
> > > > + bool oldtemp = st->conf.temp_en;
> > > > + unsigned int sleepval_ms;
> > > > + unsigned int val;
> > > > + int ret;
> > > > +
> > > > + if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
> > > > + return 0;
> > > > +
> > > > + /*
> > > > + * Datasheet on page 14.26 says we need to ensure the gyro sensor is on
> > > > + * for a minimum of 45ms. So if we transition from an on state to an
> > > > + * off state wait 45ms to ensure a sufficient pause before power off.
> > >
> > > Sashiko commented on this.. I think what we could do with adding to the
> > > comment is what the path is that didn't pass through this function which would
> > > ensure we have been on for 30 of this msecs already.
> >
> > I'm going to track whatever time the gyro started, and then if less
> > than 45ms has elapsed just pause the remaining amount of time.
> >
> > >
> > > > + */
> > > > + if (!gyro && oldgyro)
> > > > + fsleep(INV_ICM42607_GYRO_STOP_TIME_MS * USEC_PER_MSEC);
> > > > +
> > > > + val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
> > > > + val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
> > > > + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + st->conf.gyro.mode = gyro;
> > > > + st->conf.accel.mode = accel;
> > > > + st->conf.temp_en = temp;
> > > > +
> > > > + /*
> > > > + * If a state change occurs from off to on, sleep for the startup
> > > > + * time of the sensor, unless a sleep_ms is specified. Since more
> > > > + * than one sensor can be transitioned from off to on, select the
> > > > + * maximum time from each of the sensors changing from off to on.
> > > > + */
> > > > + sleepval_ms = 0;
> > > > + if (temp && !oldtemp)
> > > > + sleepval_ms = max(sleepval_ms, INV_ICM42607_TEMP_STARTUP_TIME_MS);
> > > > +
> > > > + if (accel && !oldaccel)
> > > > + sleepval_ms = max(sleepval_ms, INV_ICM42607_ACCEL_STARTUP_TIME_MS);
> > > > +
> > > > + if (gyro && !oldgyro)
> > > > + sleepval_ms = max(sleepval_ms, INV_ICM42607_GYRO_STARTUP_TIME_MS);
> > > > +
> > > > + if (sleep_ms)
> > > > + *sleep_ms = sleepval_ms;
> > > > + else if (sleepval_ms)
> > > > + fsleep(sleepval_ms * USEC_PER_MSEC);
> > > > +
> > > > + return 0;
> > > > +}
> > >
> > > >
> > > > int inv_icm42607_core_probe(struct regmap *regmap,
> > > > @@ -236,6 +305,8 @@ int inv_icm42607_core_probe(struct regmap *regmap,
> > > > if (!st)
> > > > return -ENOMEM;
> > > >
> > > > + dev_set_drvdata(dev, st);
> > > > +
> > > > ret = devm_mutex_init(dev, &st->lock);
> > > > if (ret)
> > > > return ret;
> > > > @@ -271,10 +342,78 @@ int inv_icm42607_core_probe(struct regmap *regmap,
> > > > if (ret)
> > > > return ret;
> > > >
> > > > + ret = devm_pm_runtime_set_active_enabled(dev);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + pm_runtime_set_autosuspend_delay(dev, INV_ICM42607_SUSPEND_DELAY_MS);
> > > > + pm_runtime_use_autosuspend(dev);
> > > Sashiko does put out some stuff here. Please take a look and work out or
> > > test if it is right (I think not but haven't checked that carefully!)
> > > From a quick look I think that the auto disabling of autosuspend does a
> > > rpm_idle() that should result in it suspending...
> > >
> >
> > I see a few other drivers adding one more call to
> > devm_pm_runtime_enable() so I'm going to see how that works out.
>
> Obviously that didn't work, but digging in much deeper into the PM code
> I see that devm_pm_runtime_set_active_enabled() returns
> devm_pm_runtime_enable(), which sets devm_add_action_or_reset() on
> pm_runtime_disable_action(), which calls
> pm_runtime_dont_use_autosuspend() and pm_runtime_disable(). Shouldn't
> this work, or am I missing something? Basically when the driver
> detaches shouldn't this chain end up calling
> pm_runtime_dont_use_autosuspend()?
Agreed. That was how I read things. The only thing I didn't entirely
confirm (states involved were fiddly enough I'd want to check it
with the actual driver!) was that pm_runtime_dont_use_autosuspend()
ends up calling rpm_idle() in this case.
Jonathan
>
> Thank you,
> Chris
>
> >
> > >
> > > > +
> > > > return 0;
> > > > }
> > > > EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
> >
> > Thank you,
> > Chris
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Rob Herring @ 2026-06-24 15:05 UTC (permalink / raw)
To: Mark Brown
Cc: Otto Pflüger, Liam Girdwood, Krzysztof Kozlowski,
Conor Dooley, Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones,
linux-kernel, devicetree, Krzysztof Kozlowski
In-Reply-To: <878f8f38-2294-4097-9d08-2aa04bfe773b@sirena.org.uk>
On Wed, Jun 24, 2026 at 9:13 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Wed, Jun 24, 2026 at 08:06:13AM -0500, Rob Herring wrote:
> > On Sat, Jun 20, 2026 at 10:54:00AM +0200, Otto Pflüger wrote:
> > > Add bindings for the regulators found in the Spreadtrum/Unisoc SC2730
> > > PMIC, used e.g. with the UMS512 and UMS9230 SoCs.
> > >
> > > Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> > > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > > ---
> > > .../bindings/regulator/sprd,sc2730-regulator.yaml | 44 ++++++++++++++++++++++
> > > 1 file changed, 44 insertions(+)
>
> > Applied for rc1 to fix the warnings.
>
> Warnings?
Well, one warning:
Documentation/devicetree/bindings/mfd/sprd,sc2731.yaml: Unresolvable
reference: /schemas/regulator/sprd,sc2730-regulator.yaml#
^ permalink raw reply
* [PATCH net] dt-bindings: net: renesas,ether: Drop example "ethernet-phy-ieee802.3-c22" fallback
From: Rob Herring (Arm) @ 2026-06-24 15:02 UTC (permalink / raw)
To: Niklas Söderlund, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Sergei Shtylyov
Cc: netdev, linux-renesas-soc, devicetree, linux-kernel
Fix the Micrel PHY in the example which shouldn't have the
fallback "ethernet-phy-ieee802.3-c22" compatible:
Documentation/devicetree/bindings/net/renesas,ether.example.dtb: ethernet-phy@1 \
(ethernet-phy-id0022.1537): compatible: ['ethernet-phy-id0022.1537', 'ethernet-phy-ieee802.3-c22'] is too long
from schema $id: http://devicetree.org/schemas/net/micrel.yaml
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/net/renesas,ether.yaml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ether.yaml b/Documentation/devicetree/bindings/net/renesas,ether.yaml
index f0a52f47f95a..dd7187f12a67 100644
--- a/Documentation/devicetree/bindings/net/renesas,ether.yaml
+++ b/Documentation/devicetree/bindings/net/renesas,ether.yaml
@@ -121,8 +121,7 @@ examples:
#size-cells = <0>;
phy1: ethernet-phy@1 {
- compatible = "ethernet-phy-id0022.1537",
- "ethernet-phy-ieee802.3-c22";
+ compatible = "ethernet-phy-id0022.1537";
reg = <1>;
interrupt-parent = <&irqc0>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-06-24 15:01 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar
Cc: Nuno Sá, Conor Dooley, Janani Sunil, Lars-Peter Clausen,
Michael Hennerich, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-doc, Mark Brown
In-Reply-To: <20260623155732.318f34f2@jic23-huawei>
On 6/23/26 16:57, Jonathan Cameron wrote:
> On Tue, 23 Jun 2026 09:09:14 +0100
> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
>
>> On 22/06/26 13:20, Nuno Sá wrote:
>>> On Mon, Jun 22, 2026 at 12:51:20PM +0100, Rodrigo Alencar wrote:
>>>> On 22/06/26 11:29, Nuno Sá wrote:
>>>>> On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
>>>>>> On 21/06/26 15:33, Jonathan Cameron wrote:
>>>>>>> On Fri, 19 Jun 2026 16:54:11 +0100
>>>>>>> Nuno Sá <noname.nuno@gmail.com> wrote:
>>>>>>>
>>>>>>>> On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
>>>>>>>>> On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
>>>>>>>>>> On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
>>>>>>>>>>> On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
>>>>>>>>>>>> On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
>>>>>>>>>>>>> On 6/14/26 21:44, Jonathan Cameron wrote:
>>>>>>>>>>>>>> On Tue, 9 Jun 2026 16:47:23 +0200
>>>>>>>>>>>>>> Janani Sunil <jan.sun97@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/26/26 15:11, Rodrigo Alencar wrote:
>>>>>>>>>>>>>>>> On 26/05/19 05:42PM, Janani Sunil wrote:
>>>>>>>>>>>>>>>>> Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
>>>>>>>>>>>>>>>>> buffered voltage output digital-to-analog converter (DAC) with an
>>>>>>>>>>>>>>>>> integrated precision reference.
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>> Probably others may comment on that, but...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This parent node may support device addressing for multi-device support through
>>>>>>>>>>>>>>>> those ID pins. I suppose that each device may have its own power supplies or
>>>>>>>>>>>>>>>> other resources like the toggle pins or reset and enable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That way I suppose that an example would look like...
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +patternProperties:
>>>>>>>>>>>>>>>>> + "^channel@([0-9]|1[0-5])$":
>>>>>>>>>>>>>>>>> + type: object
>>>>>>>>>>>>>>>>> + description: Child nodes for individual channel configuration
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + properties:
>>>>>>>>>>>>>>>>> + reg:
>>>>>>>>>>>>>>>>> + description: Channel number.
>>>>>>>>>>>>>>>>> + minimum: 0
>>>>>>>>>>>>>>>>> + maximum: 15
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + adi,output-range-microvolt:
>>>>>>>>>>>>>>>>> + description: |
>>>>>>>>>>>>>>>>> + Output voltage range for this channel as [min, max] in microvolts.
>>>>>>>>>>>>>>>>> + If not specified, defaults to 0V to 5V range.
>>>>>>>>>>>>>>>>> + oneOf:
>>>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>>>> + - const: 0
>>>>>>>>>>>>>>>>> + - enum: [5000000, 10000000, 20000000, 40000000]
>>>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>>>> + - const: -5000000
>>>>>>>>>>>>>>>>> + - const: 5000000
>>>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>>>> + - const: -10000000
>>>>>>>>>>>>>>>>> + - const: 10000000
>>>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>>>> + - const: -15000000
>>>>>>>>>>>>>>>>> + - const: 15000000
>>>>>>>>>>>>>>>>> + - items:
>>>>>>>>>>>>>>>>> + - const: -20000000
>>>>>>>>>>>>>>>>> + - const: 20000000
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + required:
>>>>>>>>>>>>>>>>> + - reg
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + additionalProperties: false
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +required:
>>>>>>>>>>>>>>>>> + - compatible
>>>>>>>>>>>>>>>>> + - reg
>>>>>>>>>>>>>>>>> + - vdd-supply
>>>>>>>>>>>>>>>>> + - avdd-supply
>>>>>>>>>>>>>>>>> + - hvdd-supply
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +dependencies:
>>>>>>>>>>>>>>>>> + spi-cpha: [ spi-cpol ]
>>>>>>>>>>>>>>>>> + spi-cpol: [ spi-cpha ]
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +allOf:
>>>>>>>>>>>>>>>>> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +unevaluatedProperties: false
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> +examples:
>>>>>>>>>>>>>>>>> + - |
>>>>>>>>>>>>>>>>> + #include <dt-bindings/gpio/gpio.h>
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + spi {
>>>>>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + dac@0 {
>>>>>>>>>>>>>>>>> + compatible = "adi,ad5529r-16";
>>>>>>>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>>>>>>>> + spi-max-frequency = <25000000>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>>>>> + avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>>>>> + hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>>>>> + hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>>>>>>>>> + #size-cells = <0>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + channel@0 {
>>>>>>>>>>>>>>>>> + reg = <0>;
>>>>>>>>>>>>>>>>> + adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + channel@1 {
>>>>>>>>>>>>>>>>> + reg = <1>;
>>>>>>>>>>>>>>>>> + adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + channel@2 {
>>>>>>>>>>>>>>>>> + reg = <2>;
>>>>>>>>>>>>>>>>> + adi,output-range-microvolt = <0 40000000>;
>>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> spi {
>>>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> multi-dac@0 {
>>>>>>>>>>>>>>>> compatible = "adi,ad5529r-16";
>>>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>>>> spi-max-frequency = <25000000>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> dac@0 {
>>>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>>>> vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>>>> avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>>>> hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>>>> hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> channel@0 {
>>>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>>>> adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> channel@1 {
>>>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>>>> adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> channel@2 {
>>>>>>>>>>>>>>>> reg = <2>;
>>>>>>>>>>>>>>>> adi,output-range-microvolt = <0 40000000>;
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> dac@1 {
>>>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>>>> vdd-supply = <&vdd_regulator>;
>>>>>>>>>>>>>>>> avdd-supply = <&avdd_regulator>;
>>>>>>>>>>>>>>>> hvdd-supply = <&hvdd_regulator>;
>>>>>>>>>>>>>>>> hvss-supply = <&hvss_regulator>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> #address-cells = <1>;
>>>>>>>>>>>>>>>> #size-cells = <0>;
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> channel@0 {
>>>>>>>>>>>>>>>> reg = <0>;
>>>>>>>>>>>>>>>> adi,output-range-microvolt = <0 5000000>;
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> channel@1 {
>>>>>>>>>>>>>>>> reg = <1>;
>>>>>>>>>>>>>>>> adi,output-range-microvolt = <(-10000000) 10000000>;
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> then you might need something like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> patternProperties:
>>>>>>>>>>>>>>>> "^dac@[0-3]$":
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> and put most of the things under this node pattern.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So the main driver that you're putting together might need to handle up to four instances.
>>>>>>>>>>>>>>>> Even if your current driver cannot handle this, the dt-bindings might need cover that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Need to double check if each dac node needs a separate compatible, so you would maybe populate
>>>>>>>>>>>>>>>> a platform data to be shared with the child nodes, which would be a separate driver.
>>>>>>>>>>>>>>>> (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
>>>>>>>>>>>>>>> Hi Rodrigo,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you for looking at this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
>>>>>>>>>>>>>>> hardware/use case we have only needs one device node and the driver is written around that model as well.
>>>>>>>>>>>>>>> While the device addressing pins could allow multi-device topology, we do not have an actual platform using
>>>>>>>>>>>>>>> that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
>>>>>>>>>>>>>>> speculatively without a validating use case.
>>>>>>>>>>>>>> Interesting feature - kind of similar to address control on a typical i2c bus device, or
>>>>>>>>>>>>>> looking at it another way a kind of distributed SPI mux.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Challenge of a binding is we need to anticipate the future. So I think we do need something
>>>>>>>>>>>>>> like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
>>>>>>>>>>>>>> That would leave the path open to supporting the addressing at a later date.
>>>>>>>>>>>>>> An alternative might be to look at it like a chained device setup. In those we pretend there
>>>>>>>>>>>>>> is just one device with a lot of channels etc. The snag is that here things are more loosely
>>>>>>>>>>>>>> coupled whereas for those devices it tends to be you have to read / write the same register
>>>>>>>>>>>>>> in all devices in the chain as one big SPI message.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +CC Mark Brown as he may know of some precedence for this feature. For his reference..
>>>>>>>>>>>>>> - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
>>>>>>>>>>>>>> value that matches that or they are ignored. Thus a single bus + 1 chip select can
>>>>>>>>>>>>>> be used to talk to 4 devices. Question is what that looks like in device tree + I guess
>>>>>>>>>>>>>> longer term how to support it cleanly in SPI.
>>>>>>>>>>>> I'd swear I have seen this before, from some Microchip devices. Let me
>>>>>>>>>>>> see if I can find what I am thinking of...
>>>>>>>>>>>
>>>>>>>>>>> microchip,mcp3911 and microchip,mcp3564 both seem to do this with
>>>>>>>>>>> slightly different properties.
>>>>>>>>>>>
>>>>>>>>>>> microchip,device-addr:
>>>>>>>>>>> description: Device address when multiple MCP3911 chips are present on the same SPI bus.
>>>>>>>>>>> $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>>>>> enum: [0, 1, 2, 3]
>>>>>>>>>>> default: 0
>>>>>>>>>>>
>>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> microchip,hw-device-address:
>>>>>>>>>>> $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>>>>>> minimum: 0
>>>>>>>>>>> maximum: 3
>>>>>>>>>>> description:
>>>>>>>>>>> The address is set on a per-device basis by fuses in the factory,
>>>>>>>>>>> configured on request. If not requested, the fuses are set for 0x1.
>>>>>>>>>>> The device address is part of the device markings to avoid
>>>>>>>>>>> potential confusion. This address is coded on two bits, so four possible
>>>>>>>>>>> addresses are available when multiple devices are present on the same
>>>>>>>>>>> SPI bus with only one Chip Select line for all devices.
>>>>>>>>>>> Each device communication starts by a CS falling edge, followed by the
>>>>>>>>>>> clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
>>>>>>>>>>> which is first one on the wire).
>>>>>>>>>>>
>>>>>>>>>>> This sounds exactly like the sort of feature that you're dealing with
>>>>>>>>>>> here?
>>>>>>>>>>>
>>>>>>>>>> The core idea yes but for this chip, things are a bit more annoying (but
>>>>>>>>>> Janani can correct me if I'm wrong). Here, each device can, in theory,
>>>>>>>>>> have it's own supplies, pins and at the very least, channels with maybe
>>>>>>>>>> different scales. That is why Janani is proposing dac nodes. Given I
>>>>>>>>>> honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
>>>>>>>>>> about solving this at the spi level.
>>>>>>>>>>
>>>>>>>>>> Ah and to make it more annoying, we can also mix 12 and 16 bits variants
>>>>>>>>>> together in the same bus.
>>>>>>>>> I'm definitely missing something, because that property for the
>>>>>>>>> microchip devices is not impacted what else is on the bus. AFAICT, you
>>>>>>>>> could have an mcp3911 and an mcp3564 on the same bus even though both
>>>>>>>>> are completely different devices with different drivers. They have
>>>>>>>>> individual device nodes and their own supplies etc etc. These aren't
>>>>>>>>> per-channel properties on an adc or dac, they're per child device on a
>>>>>>>>> spi bus.
>>>>>>>> Maybe I'm the one missing something :). IIRC, spi would not allow two
>>>>>>>> devices on the same CS right? Because for this chip we would need
>>>>>>>> something like:
>>>>>>>>
>>>>>>>> spi {
>>>>>>>> dac@0 {
>>>>>>>> reg = <0>;
>>>>>>>> adi,pin-id = <0>;
>>>>>>>> };
>>>>>>>>
>>>>>>>> dac@1 {
>>>>>>>> reg = <0>; // which seems already problematic?
>>>>>>>> adi,pin-id <1>;
>>>>>>>> };
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> //up to 4
>>>>>>>> };
>>>>>>> Yeah. It's not clear to me how that works for the microchip devices
>>>>>>> (I suspect it doesn't!)
>>>>>>>
>>>>>>> Just thinking as I type, but could we do something a bit nasty with
>>>>>>> a gpio mux that doesn't actually switch but represents the GPIO being
>>>>>>> shared? Given this is all tied to the spi bus that should all happen
>>>>>>> under serializing locks.
>>>>>>>
>>>>>>> Agreed though that this would be nicer as an SPI thing that let
>>>>>>> us specify that a single CS is share by multiple devices and their
>>>>>>> is some other signal acting to select which one we are talking to.
>>>>>>>
>>>>>> If the device-addressing on the same chip-select is to be handled
>>>>>> by the spi framework, wouldn't we lose device-specific features?
>>>>>>
>>>>>> I understand that this multi-device feature is there mostly to extend the
>>>>>> channel count from 16 to 32, 48 or 64. I suppose the command:
>>>>>>
>>>>>> "MULTI DEVICE SW LDAC MODE"
>>>>>>
>>>>>> exists so that software can update channel values accross multiple devices.
>>>>> Right! You do have a point! I agree the main driver for a feature like
>>>>> this is likely to extend the channel count and effectively "aggregate"
>>>>> devices.
>>>>>
>>>>> But I would say that even with the spi solution the MULTI DEVICE stuff
>>>>> should be doable (as we still need a sort of adi,pin-id property).
>>>> I don't think we can have something like an IIO buffer shared by multiple
>>>> devices. Synchronizing separate devices would be doable with proper hardware
>>>> support for this (probably involving an FGPA).
>>> True!
>>>
>>>>
>>>>> But yes, I do feel that the whole feature is for aggregation so seeing
>>>>> one device with 32 channels is the expectation here? Rather than seeing
>>>>> two devices with 16 channels.
>>>> Yes, I think aggregation is the whole point there... so that the IIO driver
>>>> is multi-device-aware.
>>> Which makes me feel that different pins per device might be possible
>>> from an HW point of view but does not make much sense. For example, for
>>> the buffer example I would expect LDAC to be shared between all the
>>> devices.
>> That is why I would still suggest the multi-dac node in the middle...
>> the parent node can hold shared resources, while the dac children can
>> have their own, overriding or inheriting stuff.
>>
> Before going down that path I'd want confirmation this is something we
> actually think anyone will build.
>
> Jonathan
To directly answer your question- we currently do not have a platform that supports multi device topology with independent supplies or reset lines.
Given that, I agree to start with the parallel wiring assumption and defer per chip resource variation under there is a solid use case. I will also drop the "adi,resolution" proposal and proceed with "adi,device-addrs" in the AD5529R binding.
With all of the above, the proposed binding for the multi-device follow up series would look like:
dac@0 {
compatible = "adi,ad5529r-16";
reg = <0>;
adi,device-addrs = <0 1>;
reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
vdd-supply = <&vdd_reg>;
hvdd-supply = <&hvdd_reg>;
channel@0 { reg = <0>; adi,output-range-microvolt = <0 5000000>; };
channel@16 { reg = <16>; adi,output-range-microvolt = <0 40000000>; };
};
Does this look reasonable to everyone?
Regards,
Janani Sunil
^ permalink raw reply
* Re: [PATCH v16 04/14] lib: kstrtox: add initial value to _parse_integer_limit()
From: Jonathan Cameron @ 2026-06-24 14:54 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
linux, David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Petr Mladek, Steven Rostedt,
Andy Shevchenko, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260614210044.19dfc8df@jic23-huawei>
On Sun, 14 Jun 2026 21:00:44 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Thu, 4 Jun 2026 11:09:33 +0100
> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
>
> > On 26/06/04 10:58AM, Rodrigo Alencar via B4 Relay wrote:
> > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >
> > > Add init parameter to _parse_integer_limit() that defines an initial
> > > value for the accumulated result when parsing an 64-bit integer. The
> > > new function prototype is adjusted so that the _parse_integer() macros
> > > stay consistent allowing for one more argument, which defaults to 0.
> >
> > ...
> >
> > > noinline
> > > unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *p,
> > > - size_t max_chars)
> > > + size_t max_chars, unsigned long long init)
> > > {
> > > unsigned long long res;
> > > unsigned int rv;
> > >
> > > - res = 0;
> > > + res = init;
> >
> > This might generate conflict, as the code around have changed in linux-next.
> > It is an easy fix though.
> >
> Thanks for the heads up. Hopefully that will all fall out when I rebase testing
> on rc1 once that is out.
I've done a mid merge cycle rebase as the char-misc branches have merged.
So this should be resolve on my testing branch now.
Thanks
Jonathan
>
> Jonathan
>
> > > rv = 0;
> > > while (max_chars--) {
> > > unsigned int c = *s;
> >
>
>
^ 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