* [PATCH 1/2] dt-bindings: iio: adc: ad4080: add AD4884 support
From: Antoniu Miclaus @ 2026-05-22 11:53 UTC (permalink / raw)
To: Nuno Sá, Michael Hennerich, Antoniu Miclaus,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260522115337.18188-1-antoniu.miclaus@analog.com>
Add AD4884 compatible string to the AD4080 devicetree binding.
The AD4884 is a dual-channel, 16-bit, 40 MSPS SAR ADC, sharing the same
register map and interface as the AD4080 family. Like the AD4880, it
requires two SPI chip selects and two io-backends for its independent
ADC channels.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
index 9c6a56c7c8ef..4a3f7d3e05c3 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
@@ -39,6 +39,7 @@ properties:
- adi,ad4087
- adi,ad4088
- adi,ad4880
+ - adi,ad4884
reg:
minItems: 1
@@ -99,7 +100,9 @@ allOf:
properties:
compatible:
contains:
- const: adi,ad4880
+ enum:
+ - adi,ad4880
+ - adi,ad4884
then:
properties:
reg:
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] iio: adc: ad4080: add support for AD4884
From: Antoniu Miclaus @ 2026-05-22 11:53 UTC (permalink / raw)
To: Nuno Sá, Michael Hennerich, Antoniu Miclaus,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux, linux-iio, devicetree, linux-kernel
Add support for the AD4884, a dual-channel, 16-bit, 40 MSPS SAR ADC,
to the ad4080 driver family.
Patch 1 adds the AD4884 compatible string to the devicetree binding.
Patch 2 adds the chip info and device ID to the driver.
Antoniu Miclaus (2):
dt-bindings: iio: adc: ad4080: add AD4884 support
iio: adc: ad4080: add support for AD4884
.../bindings/iio/adc/adi,ad4080.yaml | 5 ++++-
drivers/iio/adc/ad4080.c | 18 ++++++++++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v12 0/6] iio: adc: ad4691: add driver for AD4691 multichannel SAR ADC family
From: Jonathan Cameron @ 2026-05-22 11:51 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc, Conor Dooley
In-Reply-To: <20260519-ad4692-multichannel-sar-adc-driver-v12-0-5b335162aa51@analog.com>
On Tue, 19 May 2026 15:20:21 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> This series adds support for the Analog Devices AD4691 family of
> high-speed, low-power multichannel successive approximation register
> (SAR) ADCs with an SPI-compatible serial interface.
>
> The family includes:
> - AD4691: 16-channel, 500 kSPS
> - AD4692: 16-channel, 1 MSPS
> - AD4693: 8-channel, 500 kSPS
> - AD4694: 8-channel, 1 MSPS
>
> The devices support two operating modes, auto-detected from the device
> tree:
> - CNV Burst Mode: external PWM drives CNV independently of SPI;
> DATA_READY on a GP pin signals end of conversion
> - Manual Mode: CNV tied to SPI CS; each SPI transfer reads
> the previous conversion result and starts the
> next (pipelined N+1 scheme)
>
> A new driver is warranted rather than extending ad4695: the AD4691
> data path uses an accumulator-register model — results are read from
> AVG_IN registers, with ACC_MASK, ADC_SETUP, DEVICE_SETUP, and
> GPIO_MODE registers controlling the sequencer — none of which exist
> in AD4695. CNV Burst Mode (PWM drives CNV independently of SPI) and
> Manual Mode (pipelined N+1 transfers) also have no equivalent in
> AD4695's command-embedded single-cycle protocol.
>
> The series is structured as follows:
> 1/6 - DT bindings (YAML schema) and MAINTAINERS entry
> 2/6 - Initial driver: register map via custom regmap callbacks,
> IIO read_raw/write_raw, both operating modes, single-channel
> reads via internal oscillator (Autonomous Mode)
> 3/6 - Triggered buffer support: IRQ-driven (DATA_READY on a GP pin
> selected via interrupt-names) for CNV Burst Mode; external IIO
> trigger for Manual Mode to handle the pipelined N+1 SPI protocol
> 4/6 - SPI Engine offload support: DMA-backed high-throughput
> capture path using the SPI offload subsystem
> 5/6 - Per-channel oversampling ratio support for CNV Burst Mode
> 6/6 - Driver documentation (Documentation/iio/ad4691.rst)
>
> Datasheets:
> https://www.analog.com/en/products/ad4691.html
> https://www.analog.com/en/products/ad4692.html
> https://www.analog.com/en/products/ad4693.html
> https://www.analog.com/en/products/ad4694.html
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
I only plan to check the bit you've called out for v13. Series looks very
nice to me. Hopefully I'll remember that and not reread the whole thing
again! FWIW I'll be offline from end of today until Tuesday so it won't
get queued up until then at the earliest.
Jonathan
^ permalink raw reply
* Re: [PATCH v12 3/6] iio: adc: ad4691: add triggered buffer support
From: Jonathan Cameron @ 2026-05-22 11:46 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260519-ad4692-multichannel-sar-adc-driver-v12-3-5b335162aa51@analog.com>
On Tue, 19 May 2026 15:20:24 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add buffered capture support using the IIO triggered buffer framework.
>
> CNV Burst Mode: the GP pin identified by interrupt-names in the device
> tree is configured as DATA_READY output. The IRQ handler stops
> conversions and fires the IIO trigger; the trigger handler executes a
> pre-built SPI message that reads all active channels from the AVG_IN
> accumulator registers and then resets accumulator state and restarts
> conversions for the next cycle.
>
> Manual Mode: CNV is tied to SPI CS so each transfer simultaneously
> reads the previous result and starts the next conversion (pipelined
> N+1 scheme). At preenable time a pre-built, optimised SPI message of
> N+1 transfers is constructed (N channel reads plus one NOOP to drain
> the pipeline). The trigger handler executes the message in a single
> spi_sync() call and collects the results. An external trigger (e.g.
> iio-trig-hrtimer) is required to drive the trigger at the desired
> sample rate.
>
> Both modes share the same trigger handler and push a complete scan —
> one big-endian 16-bit (__be16) slot per active channel, densely packed
> in scan_index order, followed by a timestamp.
>
> The CNV Burst Mode sampling frequency (PWM period) is exposed as a
> buffer-level attribute via IIO_DEVICE_ATTR.
>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
I didn't spot anything in my read through and most of what Sashiko
is commenting on is wrong or not a driver specific problem
(the trigger leak is a core problem)
One small thing Sashiko did pick up on though that I think could be a little nicer.
You may well already have this in hand as I know you are checking there
as well!
> +static void ad4691_read_scan(struct iio_dev *indio_dev, s64 ts)
> +{
> + struct ad4691_state *st = iio_priv(indio_dev);
> +
> + guard(mutex)(&st->lock);
> +
> + spi_sync(st->spi, &st->scan_msg);
One thing from sashiko. If this fails we shouldn't push data and we should
make it clear somewhere (rate limited print or similar).
> +
> + /*
> + * rx_buf pointers in scan_xfers point directly into scan.vals, so no
> + * copy is needed. The scan_msg already includes a STATE_RESET at the
> + * end (appended in preenable), so no explicit reset is needed here.
> + */
> + iio_push_to_buffers_with_ts(indio_dev, st->vals, sizeof(st->vals), ts);
> +}
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Jian Hu @ 2026-05-22 11:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <7c458070-a56a-4d49-89fc-efeb388beffc@kernel.org>
On 5/22/2026 5:16 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On 22/05/2026 08:20, Jian Hu wrote:
>> Hi Krzysztof,
>>
>> Thanks for your review.
>>
>> On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>>>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>>>
>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>>> ---
>>>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>>>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>>>> 2 files changed, 165 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>>> new file mode 100644
>>>> index 000000000000..4ee6013ba1a1
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>>> @@ -0,0 +1,110 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Amlogic A9 Series PLL Clock Controller
>>>> +
>>>> +maintainers:
>>>> + - Neil Armstrong <neil.armstrong@linaro.org>
>>>> + - Jerome Brunet <jbrunet@baylibre.com>
>>>> + - Jian Hu <jian.hu@amlogic.com>
>>>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + enum:
>>>> + - amlogic,a9-gp0-pll
>>>> + - amlogic,a9-hifi0-pll
>>>> + - amlogic,a9-hifi1-pll
>>>> + - amlogic,a9-mclk0-pll
>>>> + - amlogic,a9-mclk1-pll
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + '#clock-cells':
>>>> + const: 1
>>>> +
>>>> + clocks:
>>>> + items:
>>>> + - description: pll input oscillator gate
>>>> + - description: fixed input clock source for mclk_sel_0
>>>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
>>> Second clock is also optional. Drop "(optional)" comment, just
>>> confusing.
>>
>> GP0 has only one parent clock, while MCLK has three.
>>
>> The second and third parent entries of GP0 are vacant,
>>
>> so they need to be marked optional.
>>
>> I will add the optional property for the second clock in the next revision.
> How? Read the previous feedback...
>
> Best regards,
> Krzysztof
My apologies, I misunderstood your previous comment.
I will drop "(optional)" from the clock descriptions.
It will be updated as:
clocks:
items:
- description: pll input oscillator gate
- description: fixed input clock source for mclk_sel_0
- description: u3p2pll input clock source for mclk_sel_0
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v3 7/8] dt-bindings: iio: temperature: Add ADT7604 support to adi,ltc2983
From: Liviu Stan @ 2026-05-22 11:42 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Antoniu Miclaus, Liviu Stan, Francesco Lavra, linux-iio,
linux-kernel, linux, devicetree
In-Reply-To: <20260521182308.4E2731F000E9@smtp.kernel.org>
On Thu, 21 May 2026 18:23:07 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] The new compatible string 'adi,adt7604' is omitted from the existing conditional block that disables '^temp@' nodes, violating subsystem guidelines.
> - [Low] The schema allows invalid 'adi,sensor-type' values in '^rtd@' and '^thermistor@' nodes for the ADT7604.
> --
>
> commit fbbcd3bcbfbb106e48a6545868dd2b27a56b39b5
> Author: Liviu Stan <liviu.stan@analog.com>
>
> dt-bindings: iio: temperature: Add ADT7604 support to adi,ltc2983
>
> This commit adds support for the ADT7604 to the LTC2983 binding schema. It
> introduces the adi,adt7604 compatible string and adds two new sensor node
> types: copper-trace@ and leak-detector@. It also adds conditional checks to
> restrict unsupported nodes for the ADT7604 device.
>
> > diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> > index a22725f7619b7..14cfa28809edd 100644
> > --- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> > +++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
> [ ... ]
> > @@ -477,6 +597,22 @@ allOf:
> > patternProperties:
> > '^temp@': false
> >
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: adi,adt7604
> > + then:
> > + patternProperties:
> > + '^thermocouple@': false
> > + '^diode@': false
> > + '^adc@': false
> > + '^temp@': false
>
> [Severity: Low]
> Since ADT7604 shares the ^temp@: false constraint with the existing devices,
> should adi,adt7604 be added to the existing compatible enum block instead of
> duplicating the ^temp@ restriction in this new conditional?
I think keeping all ADT7604 related constraints in one block is more readable.
For the block above it's different because ltc2984 and ltc2983 share the same
constraints.
>
> [Severity: Low]
> The commit message mentions that ADT7604 repurposes the custom RTD sensor type
> (18) and custom thermistor type (27).
>
> However, the schema doesn't restrict adi,sensor-type = <18> inside ^rtd@ nodes
> or adi,sensor-type = <27> inside ^thermistor@ nodes for the adi,adt7604
> compatible.
>
> Should these restrictions be added to this block to prevent invalid device
> tree configurations from passing validation?
>
This makes sense, we could restrict sensor type 18 and 27 for the ADT7604, even
though the driver's supported_sensors bitmask already rejects them.
I could add something like:
- if:
properties:
compatible:
contains:
const: adi,adt7604
then:
patternProperties:
'^thermocouple@': false
'^diode@': false
'^adc@': false
'^temp@': false
'^rtd@':
properties:
adi,sensor-type:
not:
const: 18
'^thermistor@':
properties:
adi,sensor-type:
not:
const: 27
What do you think?
Thanks,
Liviu
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: sashiko-bot @ 2026-05-22 11:41 UTC (permalink / raw)
To: Laurentiu Mihalcea; +Cc: robh, conor+dt, devicetree, imx, Frank.Li
In-Reply-To: <20260522111849.783-2-laurentiumihalcea111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `memory-region-names` schema constraints are overly restrictive, breaking schema validation for valid configurations and conflicting with driver logic.
--
commit 12da0dd2e4416ad44eae563e32a0db35b3b96bb4
Author: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
This commit adds documentation for the optional "memory-region-names"
property to the fsl,imx-rproc devicetree binding. It restricts the allowed
names to "rsc-table" and names matching the vdev buffer/vring pattern.
> diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> index c18f71b648890..6679b10f9da5a 100644
> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
[ ... ]
> @@ -62,6 +62,14 @@ properties:
> minItems: 1
> maxItems: 32
>
> + memory-region-names:
> + minItems: 1
> + maxItems: 32
> + items:
> + oneOf:
> + - const: rsc-table
> + - pattern: '^vdev[0-9](buffer|vring[0-9])$'
[Severity: Medium]
Are these schema constraints overly restrictive for generic memory carveouts?
Remoteproc device trees commonly use memory-region to pass generic memory
carveouts like system memory or firmware. Because memory-region-names must
have a one-to-one mapping with memory-region, attempting to name these
generic carveouts (such as 'sysmem') will cause schema validation failures
in dtbs_check.
If a developer instead names a generic carveout with a 'vdev' prefix just
to pass validation, the driver's initialization in imx_rproc_addr_init()
will skip mapping the region because it ignores any region starting with
'vdev'.
Does this leave the user with no correct way to name and map their generic
carveouts?
> +
> power-domains:
> minItems: 2
> maxItems: 8
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522111849.783-1-laurentiumihalcea111@gmail.com?part=1
^ permalink raw reply
* RE: [PATCH v12 5/6] iio: adc: ad4691: add oversampling support
From: Sabau, Radu bogdan @ 2026-05-22 11:38 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260522121628.21bf03f9@jic23-huawei>
> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Friday, May 22, 2026 2:16 PM
...
> > >
> > > + iio_for_each_active_channel(indio_dev, bit) {
> > > + ret = regmap_write(st->regmap,
> > > AD4691_ACC_DEPTH_IN(bit), st->osr[bit]);
> >
> > Unfortunately enough, I think a v13 will come, too...
> >
> > Had a look again on what Sashiko had to say, and seeing the sampling
> frequency
> > shared_by_all comment again made me have a deeper look see how the
> code could
> > be commented so he wouldn't complain about this anymore, and...
> >
> > Perhaps he is a bit right after all. I found a section stating that in standard
> > sequencer mode (which the driver uses right now), all the channels actually
> use
> > the ACC_DEPTH_IN0 for osr, and so changing ACC_DEPTH_INn for other
> channels
> > doesn't really do much. And so I tested this selecting both voltage0 and
> voltage1
> > for sampling with osr4 for voltage0 and osr1 for voltage1 and with a 100kHz
> osc freq
> > indeed DR fell after approximately 80us which points out both channels were
> actually
> > using OSR of 4. Perhaps the OSR should be shared by all and therefore the
> > sampling frequency would also be shared by all, right?
>
> I kind of lost track on the modes. What are the chances we later move to or
> add
> support for a mode where the different OSRs do matter? If that's a possibility
> we should avoid ABI change by allowing for it from the start.
>
> Then if we are in this mode, they'll have separate controls but change any,
> changes
> them all, if we are in a different mode that connection breaks.
> If that's the case, just throw in a comment saying something to the effect this
> may change.
>
> It's not wrong ABI to do this, it's just less intuitive for users which is why
> we prefer the shared_by stuff where there isn't a disadvantage. That is at
> most
> a hint to what actually happens. A simple example is where different
> channels have one OSR field but they aren't the same - i.e. channel 1 is twice
> the OSR of channel 2. Hence we can't share the attribute but any change
> effects
> both.
>
Hi Jonathan,
I don't think a mode where different OSR will matter will be added in the future. Better
yet, this advanced sequencer functionality is not really mode dependent and is actually
something that allows you to manually rearrange channels and samples in the
sequence, and unless this functionality is active (it is not by default nor is it used by
the driver, since we use the standard sequencer).
Personally, I don't see any reason to have this advanced sequencer stuff implemented
since DR is only falling at the end of the sequence no matter if it is standard config or not,
the only "disadvantage" to say so is that the standard sequencer uses the same OSR field
for all channels. But that advanced sequencer stuff would only complicate the buffer
enable/disable functions even more, which I don't think it's worth the effort.
So, with this in mind. Letting the driver use standard sequencer would ultimately mean
that the osr would be the same for all the channels, and then effective rate the same for
all channels, which I suggest having it like that from initial driver patch to the end, so no
ABI change mid-patch series. This change will simplify the driver.
Radu
^ permalink raw reply
* Re: [PATCH v12 2/6] iio: adc: ad4691: add initial driver for AD4691 family
From: Jonathan Cameron @ 2026-05-22 11:35 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc
In-Reply-To: <20260519-ad4692-multichannel-sar-adc-driver-v12-2-5b335162aa51@analog.com>
On Tue, 19 May 2026 15:20:23 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add support for the Analog Devices AD4691 family of high-speed,
> low-power multichannel SAR ADCs: AD4691 (16-ch, 500 kSPS),
> AD4692 (16-ch, 1 MSPS), AD4693 (8-ch, 500 kSPS) and
> AD4694 (8-ch, 1 MSPS).
>
> The driver implements a custom regmap layer over raw SPI to handle the
> device's mixed 1/2/3/4-byte register widths and uses the standard IIO
> read_raw/write_raw interface for single-channel reads.
>
> The chip idles in Autonomous Mode so that single-shot read_raw can use
> the internal oscillator without disturbing the hardware configuration.
>
> Three voltage supply domains are managed: avdd (required), vio, and a
> reference supply on either the REF pin (ref-supply, external buffer)
> or the REFIN pin (refin-supply, uses the on-chip reference buffer;
> REFBUF_EN is set accordingly). Hardware reset is performed by asserting
> the reset-gpios GPIO line for at least 300 µs then deasserting it;
> a software reset via SPI_CONFIG_A is used as fallback when no reset
> GPIO is provided.
>
> Accumulator channel masking for single-shot reads uses ACC_MASK_REG via
> an ADDR_DESCENDING SPI write, which covers both mask bytes in a single
> 16-bit transfer.
>
> IIO_CHAN_INFO_SAMP_FREQ is exposed as info_mask_separate. The oscillator
> is shared hardware — writing any channel's sampling_frequency attribute
> sets it for all others — but per-channel attributes are used throughout
> the series to avoid an ABI change when per-channel oversampling ratios
> are introduced in a later commit, at which point the effective output
> rate (osc_freq / osr[N]) becomes genuinely per-channel.
>
> Reviewed-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
One really small thing given you mention you'll be doing a v13.
> diff --git a/drivers/iio/adc/ad4691.c b/drivers/iio/adc/ad4691.c
> new file mode 100644
> index 000000000000..2d58df862142
> --- /dev/null
> +++ b/drivers/iio/adc/ad4691.c
> +static int ad4691_reset(struct ad4691_state *st)
> +{
> + struct device *dev = regmap_get_device(st->regmap);
> + struct reset_control *rst;
> + int ret;
> +
> + rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> + if (IS_ERR(rst))
> + return dev_err_probe(dev, PTR_ERR(rst), "Failed to get reset\n");
> +
> + if (rst) {
> + /*
> + * Assert the reset line to guarantee a clean reset pulse on
> + * every probe, including driver reloads where the line may
> + * already be deasserted (reset_control_put() does not
> + * re-assert on release). tRESETL (minimum pulse width) = 10 ns
> + * (Table 5); kernel function-call overhead alone exceeds this,
> + * so no explicit delay is needed between assert and deassert.
> + */
> + reset_control_assert(rst);
> + ret = reset_control_deassert(rst);
> + if (ret)
> + return ret;
Really trivial but seems like this could be refactored to share the sleep
code + perhaps more usefully the comment.
} else {
/* No hardware reset available, fall back to software reset. */
ret = regmap_write(st->regmap, AD4691_SPI_CONFIG_A_REG, AD4691_SW_RESET);
if (ret)
return ret;
}
/*
* Wait tHWR = 300 µs (Table 5) for the device to complete its
* internal reset sequence before accepting SPI commands.
*/
fsleep(300);
return 0;
}
> + /*
> + * Wait tHWR = 300 µs (Table 5) for the device to complete its
> + * internal reset sequence before accepting SPI commands.
> + */
> + fsleep(300);
> + return 0;
> + }
> +
> + /* No hardware reset available, fall back to software reset. */
> + ret = regmap_write(st->regmap, AD4691_SPI_CONFIG_A_REG, AD4691_SW_RESET);
> + if (ret)
> + return ret;
> + /*
> + * Wait tSWR = 300 µs (Table 5) for the device to complete its
> + * internal reset sequence before accepting SPI commands.
> + */
> + fsleep(300);
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH 14/14] arm64: dts: imx8mp: add VC8000E encoder node
From: Fabio Estevam @ 2026-05-22 11:28 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-media,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Nicolas Dufresne,
Benjamin Gaignard, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Marco Felsch, Michael Tretter
In-Reply-To: <20260522101653.2565125-15-paulk@sys-base.io>
Hi Paul,
Thanks for working on this.
On Fri, May 22, 2026 at 7:49 AM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> From: Marco Felsch <m.felsch@pengutronix.de>
>
> Add support for the Versilicon VC8000E multi-codec stateless encoder.
Typo: Verisilicon
> The IP integrated on the i.MX8MP supports H.264 and H.265 encoding.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
You need to add your Signed-off-by tag as well.
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index a3de6604e29f..4e63c2b16c1a 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -2290,6 +2290,17 @@ vpu_g2: video-codec@38310000 {
> power-domains = <&vpumix_blk_ctrl IMX8MP_VPUBLK_PD_G2>;
> };
>
> + vpu_vc8000e: video-codec@38320000 {
> + compatible = "nxp,imx8mp-vpu-vc8000e";
This compatible must be documented in a dt-bindings yaml file.
^ permalink raw reply
* Re: [PATCH v12 1/6] dt-bindings: iio: adc: add AD4691 family
From: Jonathan Cameron @ 2026-05-22 11:23 UTC (permalink / raw)
To: Radu Sabau via B4 Relay
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Uwe Kleine-König, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Philipp Zabel,
Jonathan Corbet, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-pwm, linux-gpio, linux-doc, Conor Dooley
In-Reply-To: <20260519-ad4692-multichannel-sar-adc-driver-v12-1-5b335162aa51@analog.com>
On Tue, 19 May 2026 15:20:22 +0300
Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org> wrote:
> From: Radu Sabau <radu.sabau@analog.com>
>
> Add DT bindings for the Analog Devices AD4691 family of multichannel
> SAR ADCs (AD4691, AD4692, AD4693, AD4694).
>
> The binding describes the hardware connections:
>
> - Power domains: avdd-supply (required), vio-supply, ref-supply or
> refin-supply (external reference; the REFIN path enables the
> internal reference buffer). Digital core VDD is supplied either
> externally via vdd-supply, or generated by the on-chip LDO fed
> from ldo-in-supply; the two are mutually exclusive and one must
> be present.
>
> - Optional PWM on the CNV pin selects CNV Burst Mode; when absent,
> Manual Mode is assumed with CNV tied to SPI CS.
>
> - An optional reset GPIO (reset-gpios) for hardware reset.
>
> - Up to four GP pins (gp0..gp3) usable as interrupt sources,
> identified in firmware via interrupt-names "gp0".."gp3".
>
> - gpio-controller with #gpio-cells = <2> for GP pin GPIO usage.
>
> - #trigger-source-cells = <1>: one cell selecting the GP pin number
> (0-3) used as the SPI offload trigger source.
>
> Two binding examples are provided: CNV Burst Mode with SPI offload
> (DMA data acquisition driven by DATA_READY on a GP pin), and Manual
> Mode for CPU-driven triggered-buffer or single-shot capture.
Doesn't really matter, but why include so much detail that is easy enough
seen in the binding? If there is information we need to capture it better
be in the binding!
Not actually worth the effort of changing it though - more something
for future reference (unless someone else is asking for this levle
of detail).
>
> The four variants are not compatible with each other: AD4691/AD4692 have
> 16 analog input channels while AD4693/AD4694 have 8, and AD4691/AD4693
> top out at 500 kSPS while AD4692/AD4694 reach 1 MSPS. These differences
> in channel count and maximum sample rate require distinct compatible
> strings so the driver can select the correct channel configuration and
> rate limits.
This bit indeed belongs here.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> ---
^ permalink raw reply
* [PATCH 1/1] arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in sound card as well
From: Alexander Stein @ 2026-05-22 11:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Alexander Stein, Shawn Guo
Cc: linux, devicetree, imx, linux-arm-kernel, linux-kernel
With deferrable card binding the sound card driver tries to
get the mclk configuration before it is setup in sai3 node.
Fix this by setting the mclk config for the sound card as well.
Fixes: d8f9d8126582 ("arm64: dts: imx8mp: Add analog audio output on i.MX8MP TQMa8MPxL/MBa8MPxL")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 890d1e525a489..1ea1da735762f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -246,6 +246,9 @@ sound {
"IN1_R", "Line In Jack",
"Line Out Jack", "LOL",
"Line Out Jack", "LOR";
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
};
sound-hdmi {
--
2.43.0
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add RPMSG DT overlay for the MX95-15x15-FRDM board. This overlay is meant
to be used with the mx95evkrpmsg system manager configuration for
remoteproc and audio over rpmsg-usecases.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 3 +
.../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
2 files changed, 68 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 513f61eb27b8..a30a99e42426 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx943-evk-pcie0-ep.dtb imx943-evk-pcie1-ep.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-ab2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-rpmsg.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
@@ -539,6 +540,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-yavia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-zinnia.dtb
+imx95-15x15-frdm-rpmsg-dtbs = imx95-15x15-frdm.dtb imx95-15x15-frdm-rpmsg.dtbo
+
imx95-15x15-evk-pcie-dtbs += imx95-15x15-evk.dtb imx-m2-pcie.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
new file mode 100644
index 000000000000..b39444dde66e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ *
+ * This DT overlay is meant to be used alongside the mx95evkrpmsg SM
+ * configuration for remoteproc and audio over rpmsg.
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ vdev0vring0: memory@88000000 {
+ reg = <0 0x88000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: memory@88008000 {
+ reg = <0 0x88008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0buffer: memory@88020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x88020000 0 0x100000>;
+ no-map;
+ };
+
+ rsc_table: memory@88220000 {
+ reg = <0 0x88220000 0 0x1000>;
+ no-map;
+ };
+ };
+
+ sound-micfil {
+ status = "disabled";
+ };
+};
+
+&cm7 {
+ memory-region = <&vdev0buffer>, <&vdev0vring0>,
+ <&vdev0vring1>, <&rsc_table>;
+ memory-region-names = "vdev0buffer", "vdev0vring0",
+ "vdev0vring1", "rsc-table";
+ status = "okay";
+};
+
+&edma1 {
+ /* reserved for M7 */
+ dma-channel-mask = <0x40>;
+};
+
+&edma2 {
+ /* reserved for M7 and V2X */
+ dma-channel-mask = <0xf>;
+};
+
+&micfil {
+ /* reserved for M7 */
+ status = "disabled";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: freescale: imx95-15x15-frdm: remove common rmem regions
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Remove the reserved memory regions that are common to the MX95-19x19-EVK,
MX95-15x15-FRDM, and MX95-15x15-EVK platforms and are used for remoteproc.
At the moment, these regions are not used for anything and can be included
in an RPMSG-specific DTS.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../boot/dts/freescale/imx95-15x15-frdm.dts | 21 -------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
index 0f43e3be7058..f9b0e266754d 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
@@ -188,16 +188,6 @@ linux_cma: linux,cma {
linux,cma-default;
};
- vdev0vring0: memory@88000000 {
- reg = <0 0x88000000 0 0x8000>;
- no-map;
- };
-
- vdev0vring1: memory@88008000 {
- reg = <0 0x88008000 0 0x8000>;
- no-map;
- };
-
vdev1vring0: memory@88010000 {
reg = <0 0x88010000 0 0x8000>;
no-map;
@@ -208,17 +198,6 @@ vdev1vring1: memory@88018000 {
no-map;
};
- vdevbuffer: memory@88020000 {
- compatible = "shared-dma-pool";
- reg = <0 0x88020000 0 0x100000>;
- no-map;
- };
-
- rsc_table: memory@88220000 {
- reg = <0 0x88220000 0 0x1000>;
- no-map;
- };
-
vpu_boot: memory@a0000000 {
reg = <0 0xa0000000 0 0x100000>;
no-map;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The CM7 remoteproc configuration is common to multiple MX95-based
platforms (e.g. MX95-19x19-EVK, MX95-15x15-FRDM, SMARC-IMX95, etc.).
Therefore, move the node to the MX95 SoC DTSI. While at it, split the mbox
channels using <>.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 14 ++++++--------
arch/arm64/boot/dts/freescale/imx95.dtsi | 7 +++++++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7d760470201f..c94a63a3bf8f 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -145,14 +145,6 @@ reg_wifi_en: regulator-wifi-en {
startup-delay-us = <2000>;
};
- remoteproc-cm7 {
- compatible = "fsl,imx95-cm7";
- mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
- mbox-names = "tx", "rx", "rxdb";
- memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
- <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
- };
-
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -204,6 +196,12 @@ vdevbuffer: vdevbuffer@88020000 {
};
};
+&cm7 {
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
+ status = "okay";
+};
+
/* SMARC GBE0 */
&enetc_port0 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 3e35c956a4d7..f8760ac067fa 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -272,6 +272,13 @@ opp-1000000000 {
};
};
+ cm7: remoteproc-cm7 {
+ compatible = "fsl,imx95-cm7";
+ mboxes = <&mu7 0 1>, <&mu7 1 1>, <&mu7 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ status = "disabled";
+ };
+
clk_ext1: clock-ext1 {
compatible = "fixed-clock";
#clock-cells = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH 2/5] remoteproc: imx_rpoc: fix carveout name parsing
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The imx remoteproc driver assumes that the names of the reserved memory
regions reflect their usage (e.g. "vdevbuffer", "vdev0vring0", etc.). This
conflicts with the devicetree specification's recommendation, which states
that the names of the devicetree nodes should be generic.
Therefore, instead of relying on the node names, use the names passed via
the "memory-region-names" property if present. Otherwise, keep the old
behavior.
The definition of imx_rproc_rmem_to_resource() is added to a common place
as imx_dsp_rproc.c can also use it given that it suffers from the same
aforementioned problem.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 7 +++++--
drivers/remoteproc/imx_rproc.h | 19 +++++++++++++++++++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7f54322244ac..1ee1c658dcc1 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -672,7 +672,7 @@ static int imx_rproc_prepare(struct rproc *rproc)
int err;
struct resource res;
- err = of_reserved_mem_region_to_resource(np, i++, &res);
+ err = imx_rproc_rmem_to_resource(np, i++, &res);
if (err)
break;
@@ -850,11 +850,14 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (nph <= 0)
return 0;
+ if (!of_property_present(np, "memory-region-names"))
+ dev_warn(dev, "using node names for carveouts should be avoided\n");
+
/* remap optional addresses */
for (a = 0; a < nph; a++) {
struct resource res;
- err = of_reserved_mem_region_to_resource(np, a, &res);
+ err = imx_rproc_rmem_to_resource(np, a, &res);
if (err) {
dev_err(dev, "unable to resolve memory region\n");
return err;
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index 0d7d48352a10..58e9daa41afe 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -45,4 +45,23 @@ struct imx_rproc_dcfg {
u32 reset_vector_mask;
};
+static inline int imx_rproc_rmem_to_resource(struct device_node *np,
+ int index,
+ struct resource *res)
+{
+ int ret;
+
+ ret = of_reserved_mem_region_to_resource(np, index, res);
+ if (ret)
+ return ret;
+
+ /* "memory-region-names" is optional */
+ ret = of_property_read_string_index(np, "memory-region-names",
+ index, &res->name);
+ if (ret == -EINVAL)
+ return 0;
+
+ return ret;
+}
+
#endif /* _IMX_RPROC_H */
--
2.43.0
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Document the optional "memory-region-names" property.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index c18f71b64889..6679b10f9da5 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -62,6 +62,14 @@ properties:
minItems: 1
maxItems: 32
+ memory-region-names:
+ minItems: 1
+ maxItems: 32
+ items:
+ oneOf:
+ - const: rsc-table
+ - pattern: '^vdev[0-9](buffer|vring[0-9])$'
+
power-domains:
minItems: 2
maxItems: 8
--
2.43.0
^ permalink raw reply related
* [PATCH 0/5] Add RPROC support for the MX95-15x15-FRDM board
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Hi folks,
As you can see from the title, this series attempts to introduce/enable
RPROC support for the MX95-15x15-FRDM board.
For a while now, the imx_rproc driver has been using the reserved memory
DT nodes as the carveout names, which would force DT writers to go against
the DT specification's recommendation and use non-generic names (e.g.
"vdev0vring0", "vdev0vring1", etc...). This series also tries to fix this
issue by introducing the "memory-region-names" property and using it in
the imx_rproc driver to figure out the carveout names. The driver will
still allow the old way of doing things (i.e. no "memory-region-names"
property) but a warning will now be printed since this should be
discouraged.
Laurentiu Mihalcea (5):
dt-bindings: remoteproc: imx_rproc: document optional
"memory-region-names"
remoteproc: imx_rpoc: fix carveout name parsing
arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
arm64: dts: freescale: imx95-15x15-frdm: remove common rmem regions
arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
.../bindings/remoteproc/fsl,imx-rproc.yaml | 8 +++
arch/arm64/boot/dts/freescale/Makefile | 3 +
.../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
.../boot/dts/freescale/imx95-15x15-frdm.dts | 21 ------
.../dts/freescale/imx95-toradex-smarc.dtsi | 14 ++--
arch/arm64/boot/dts/freescale/imx95.dtsi | 7 ++
drivers/remoteproc/imx_rproc.c | 7 +-
drivers/remoteproc/imx_rproc.h | 19 ++++++
8 files changed, 113 insertions(+), 31 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
--
2.43.0
^ permalink raw reply
* Re: [PATCH v12 5/6] iio: adc: ad4691: add oversampling support
From: Jonathan Cameron @ 2026-05-22 11:16 UTC (permalink / raw)
To: Sabau, Radu bogdan
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414CA3DB26235605C9323E5F70E2@LV9PR03MB8414.namprd03.prod.outlook.com>
On Thu, 21 May 2026 11:32:42 +0000
"Sabau, Radu bogdan" <Radu.Sabau@analog.com> wrote:
> > -----Original Message-----
> > From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> > Sent: Tuesday, May 19, 2026 3:20 PM
>
> ...
>
> >
> > + iio_for_each_active_channel(indio_dev, bit) {
> > + ret = regmap_write(st->regmap,
> > AD4691_ACC_DEPTH_IN(bit), st->osr[bit]);
>
> Unfortunately enough, I think a v13 will come, too...
>
> Had a look again on what Sashiko had to say, and seeing the sampling frequency
> shared_by_all comment again made me have a deeper look see how the code could
> be commented so he wouldn't complain about this anymore, and...
>
> Perhaps he is a bit right after all. I found a section stating that in standard
> sequencer mode (which the driver uses right now), all the channels actually use
> the ACC_DEPTH_IN0 for osr, and so changing ACC_DEPTH_INn for other channels
> doesn't really do much. And so I tested this selecting both voltage0 and voltage1
> for sampling with osr4 for voltage0 and osr1 for voltage1 and with a 100kHz osc freq
> indeed DR fell after approximately 80us which points out both channels were actually
> using OSR of 4. Perhaps the OSR should be shared by all and therefore the
> sampling frequency would also be shared by all, right?
I kind of lost track on the modes. What are the chances we later move to or add
support for a mode where the different OSRs do matter? If that's a possibility
we should avoid ABI change by allowing for it from the start.
Then if we are in this mode, they'll have separate controls but change any, changes
them all, if we are in a different mode that connection breaks.
If that's the case, just throw in a comment saying something to the effect this
may change.
It's not wrong ABI to do this, it's just less intuitive for users which is why
we prefer the shared_by stuff where there isn't a disadvantage. That is at most
a hint to what actually happens. A simple example is where different
channels have one OSR field but they aren't the same - i.e. channel 1 is twice
the OSR of channel 2. Hence we can't share the attribute but any change effects
both.
Jonathan
>
> The usage of internal_osc_freq and pre-computed freq values depending on osr would
> stay the same since those are still correct anyway.
>
> What's your opinion on this?
> Radu
>
^ permalink raw reply
* Re: [PATCH 3/5] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Stephan Gerhold @ 2026-05-22 11:15 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Maulik Shah (mkshah), Dmitry Baryshkov, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thomas Gleixner, Linus Walleij, linux-arm-msm, devicetree,
linux-kernel, linux-gpio, Sneh Mankad, Johan Hovold
In-Reply-To: <0df69fd0-92f0-4daa-af15-56163b812741@oss.qualcomm.com>
On Fri, Mar 13, 2026 at 12:49:22PM +0100, Konrad Dybcio wrote:
> On 3/13/26 7:40 AM, Maulik Shah (mkshah) wrote:
> > On 3/13/2026 7:52 AM, Dmitry Baryshkov wrote:
> >> On Thu, Mar 12, 2026 at 09:26:37PM +0530, Maulik Shah wrote:
>
> [...]
>
> >>> All the SoCs so far default uses pass through mode with the exception of
> >>
> >> Is it something that must be configured by the bootloaders?
> >
> > yes, currently changing the the mode can be done from secure world either at boot
> > or after boot via scm write.
>
> ..which won't work on almost any X1E devices, except CRD and IOT..
>
FWIW: The "actively-maintained" X1E Windows laptops (e.g. T14s, Dell
XPS) have received support for the new SCM call through BIOS updates
sometime last year when the BSP was upgraded. There will, however,
always be devices that are stuck at their original launch time BIOS,
unfortunately. Those will not be able to use the SCM call.
> >>> x1e. x1e PDC may be set to secondary controller mode for builds on CRD
> >>> boards whereas it may be set to pass through mode for IoT-EVK.
> >>>
> >>> There is no way to read which current mode it is set to and make PDC work
> >>> in respective mode as the read access is not opened up for non secure
> >>> world. There is though write access opened up via SCM write API to set the
> >>> mode.
> >>
> >> What are going to loose? The ability to latch the wakeup sources on the
> >> CRD?
> >
> > CXPC (SoC level low power mode) would be lost if the device can not wake up from GPIO wakeup sources.
>
> To the best of my understanding, that's only because your approach chooses
> to ignore supporting the secondary controller mode and force-reconfigure,
> since GPIO wakeup functionality is otherwise available regardless of the
> mode.
>
> >>> Configure PDC mode to pass through mode for all x1e based boards via SCM
> >>> write.
> >>
> >> Would it make sense to always use the secondary mode instead?
> >
> > No, it would not make sense to support the secondary mode in Linux.
>
> Why?
>
> [...]
>
> >>> + * - Inform TLMM to monitor GPIO IRQs (same as MPM)
> >>> + * - Prevent SoC low power mode (CxPC) as PDC is not
> >>> + * monitoring GPIO IRQs which may be needed to wake
> >>> + * the SoC from low power mode.
> >>
> >> This doesn't quite match the description of "latches the GPIO IRQs".
> >
> > It does, PDC would continue to still latch the GPIO IRQs (as the mode change failed)
> > but PDC won't forward them to parent GIC as they are masked at PDC with __pdc_mask_intr().
>
> Can you not refrain from masking them then, and clear them upon reception,
> with a write to IRQ_i_CFG[IRQ_STATUS]?
>
> The HPG states that this mechanism is only engaged for GPIO IRQs and that
> the forwarded interrupt will be of LEVEL_HIGH type (which is what TLMM
> accepts anyway)
>
> FWIW, some related work:
> c7984dc0a2b9 ("pinctrl: qcom: Add test case for TLMM interrupt handling")
>
All these changes actually exist already. I created 3 different patch
sets for the PDC on X1E at some point:
1. SCM call only with "no deep suspend wakeup" for older firmwares
2. Support for secondary/auxiliary interrupt controller with fallback
to SCM call if supported
3. Unconditional use of secondary/auxiliary interrupt controller for
all firmware versions
If I remember correctly, the preferred option in discussions with
Bjorn/Johan back then was to go with option (3). We wanted to support
all X1E laptops and the additional effort of supporting two different
interrupt handling approaches on a single platform did not seem worth
it. In addition, there were reported crashes when resuming from suspend
when using the SCM call approach (but not using the secondary interrupt
controller feature). The crashdump was pointing to unrelated SMMU
problems, but perhaps that was just coincidental. It could be perhaps
related to the recently fixed USB clock issue [1]. Not sure, but if we
end up using the SCM call we should test that to be sure.
I was not able to post these patches upstream back then because of
ongoing discussions about the errata handling etc, but I think Maulik
should have a copy of them. I was close to submitting option (3), it
passes all tlmm-test cases except one related to latching of interrupts
while disabled. The intended behavior of that is not well-defined in the
Linux API.
I pushed the latest draft to a public repo sometime last year. That repo
is not available anymore, but I have now restored the branch here:
https://github.com/stephan-gh/linux/commits/wip/x1e80100-6.15-pdc/
You can find details about the open test failure in this commit:
https://github.com/stephan-gh/linux/commit/59ca2a7335ede83e4a7cf02704dd7c469c725c14
Thanks,
Stephan
[1]: https://lore.kernel.org/linux-arm-msm/36bbe3c6-e83d-48be-8a9c-9cbc5b26e064@oss.qualcomm.com/
^ permalink raw reply
* Re: [PATCH v2 08/10] arm64: dts: qcom: sc8280xp-arcata: model the PMU of the on-board wcn6855
From: sashiko-bot @ 2026-05-22 11:13 UTC (permalink / raw)
To: Jérôme de Bretagne via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260522-surface-sp9-5g-for-next-v2-8-dd9d477407f5@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `bluetooth` node incorrectly retains the deprecated `vddrfa1p7-supply` property instead of updating to the required `vddrfa1p8-supply` during PMU migration, causing a schema validation failure.
--
commit 76c3a5c815bb3aad1ccb11de6a36790f3b5d30ec
Author: Jérôme de Bretagne <jerome.debretagne@gmail.com>
arm64: dts: qcom: sc8280xp-arcata: model the PMU of the on-board wcn6855
This commit aligns the Surface Pro 9 5G device tree with other sc8280xp
models by adding a node for the WCN6855 PMU. It reworks the inputs of the
wifi and bluetooth nodes to consume the PMU outputs and delegates power
sequencing to the PMU driver.
Link: https://lore.kernel.org/all/20241018-sc8280xp-pwrseq-v6-0-8da8310d9564@linaro.org/
> Use the fixed BT vddrfa1p7-supply supply name to align with bindings.
[Severity: Medium]
Does this description mistakenly mention vddrfa1p7-supply instead of
vddbtcmx-supply? The qcom,wcn6855-bt binding actually deprecates
vddrfa1p7-supply in favor of vddrfa1p8-supply.
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-arcata.dts
[ ... ]
> @@ -820,20 +892,16 @@ &uart2 {
> bluetooth {
> compatible = "qcom,wcn6855-bt";
>
> - vddio-supply = <&vreg_s10b>;
> - vddbtcxmx-supply = <&vreg_s12b>;
> - vddrfacmn-supply = <&vreg_s12b>;
> - vddrfa0p8-supply = <&vreg_s12b>;
> - vddrfa1p2-supply = <&vreg_s11b>;
> - vddrfa1p7-supply = <&vreg_s1c>;
> + vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
> + vddaon-supply = <&vreg_pmu_aon_0p8>;
> + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
> + vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
> + vddbtcmx-supply = <&vreg_pmu_btcmx_0p8>;
> + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
> + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
> + vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
[Severity: Medium]
Should this property be updated to vddrfa1p8-supply to complete the PMU
migration?
The wifi node was correctly updated to use vddrfa1p8-supply earlier in the
patch, but retaining the deprecated vddrfa1p7-supply here in the bluetooth
node will cause schema validation to fail during dt_binding_check.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-surface-sp9-5g-for-next-v2-0-dd9d477407f5@gmail.com?part=8
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: lemans: Remove the gold_cpu_sleep idle state
From: Navya Malempati @ 2026-05-22 11:10 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Navya Malempati
In-Reply-To: <20260522-ml_cpuidle-v1-0-fd311cf33fb4@oss.qualcomm.com>
Firmware supports both CPU power collapse (gold_cpu_sleep_0) and
CPU PLL/rail power collapse (gold_rail_cpu_sleep_0) idle states.
However, CPU power collapse mode is not utilized in favor of performance,
so remove it for lemans, aligning with SM8350/SM8450/SM8550/SM8650.
Rename gold_rail_cpu_sleep_0 from cpu-sleep-1 to cpu-sleep-0 since it is
now the only CPU idle state in use.
Signed-off-by: Navya Malempati <navya.malempati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 36 +++++++++---------------------------
1 file changed, 9 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans.dtsi b/arch/arm64/boot/dts/qcom/lemans.dtsi
index bc7b4f65ad5e..cfca4895e9ec 100644
--- a/arch/arm64/boot/dts/qcom/lemans.dtsi
+++ b/arch/arm64/boot/dts/qcom/lemans.dtsi
@@ -297,17 +297,7 @@ core3 {
idle-states {
entry-method = "psci";
- gold_cpu_sleep_0: cpu-sleep-0 {
- compatible = "arm,idle-state";
- idle-state-name = "gold-power-collapse";
- arm,psci-suspend-param = <0x40000003>;
- entry-latency-us = <549>;
- exit-latency-us = <901>;
- min-residency-us = <1774>;
- local-timer-stop;
- };
-
- gold_rail_cpu_sleep_0: cpu-sleep-1 {
+ gold_rail_cpu_sleep_0: cpu-sleep-0 {
compatible = "arm,idle-state";
idle-state-name = "gold-rail-power-collapse";
arm,psci-suspend-param = <0x40000004>;
@@ -566,57 +556,49 @@ psci {
cpu_pd0: power-domain-cpu0 {
#power-domain-cells = <0>;
power-domains = <&cluster_0_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd1: power-domain-cpu1 {
#power-domain-cells = <0>;
power-domains = <&cluster_0_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd2: power-domain-cpu2 {
#power-domain-cells = <0>;
power-domains = <&cluster_0_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd3: power-domain-cpu3 {
#power-domain-cells = <0>;
power-domains = <&cluster_0_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd4: power-domain-cpu4 {
#power-domain-cells = <0>;
power-domains = <&cluster_1_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd5: power-domain-cpu5 {
#power-domain-cells = <0>;
power-domains = <&cluster_1_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd6: power-domain-cpu6 {
#power-domain-cells = <0>;
power-domains = <&cluster_1_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cpu_pd7: power-domain-cpu7 {
#power-domain-cells = <0>;
power-domains = <&cluster_1_pd>;
- domain-idle-states = <&gold_cpu_sleep_0>,
- <&gold_rail_cpu_sleep_0>;
+ domain-idle-states = <&gold_rail_cpu_sleep_0>;
};
cluster_0_pd: power-domain-cluster0 {
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: qcom: monaco: Remove the little/big_cpu_sleep_0 idle states
From: Navya Malempati @ 2026-05-22 11:10 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Navya Malempati
In-Reply-To: <20260522-ml_cpuidle-v1-0-fd311cf33fb4@oss.qualcomm.com>
Firmware supports both CPU power collapse (little/big_cpu_sleep_0) and
CPU PLL/rail power collapse (little/big_cpu_sleep_1) idle states.
However, CPU power collapse modes are often not utilized in favor of
performance, so remove the CPU power collapse modes for monaco,
aligning with SM8350/SM8450/SM8550/SM8650.
Rename little/big_cpu_sleep_1 as little/big_cpu_sleep_0 since it is now
the only CPU idle state in use.
Signed-off-by: Navya Malempati <navya.malempati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 36 ++++++++----------------------------
1 file changed, 8 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index ce6ff259cb4a..fed94cdbe41d 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -309,16 +309,6 @@ idle-states {
entry-method = "psci";
little_cpu_sleep_0: cpu-sleep-0-0 {
- compatible = "arm,idle-state";
- idle-state-name = "silver-power-collapse";
- arm,psci-suspend-param = <0x40000003>;
- entry-latency-us = <449>;
- exit-latency-us = <801>;
- min-residency-us = <1574>;
- local-timer-stop;
- };
-
- little_cpu_sleep_1: cpu-sleep-0-1 {
compatible = "arm,idle-state";
idle-state-name = "silver-rail-power-collapse";
arm,psci-suspend-param = <0x40000004>;
@@ -329,16 +319,6 @@ little_cpu_sleep_1: cpu-sleep-0-1 {
};
big_cpu_sleep_0: cpu-sleep-1-0 {
- compatible = "arm,idle-state";
- idle-state-name = "gold-power-collapse";
- arm,psci-suspend-param = <0x40000003>;
- entry-latency-us = <549>;
- exit-latency-us = <901>;
- min-residency-us = <1774>;
- local-timer-stop;
- };
-
- big_cpu_sleep_1: cpu-sleep-1-1 {
compatible = "arm,idle-state";
idle-state-name = "gold-rail-power-collapse";
arm,psci-suspend-param = <0x40000004>;
@@ -681,49 +661,49 @@ psci {
cpu_pd0: power-domain-cpu0 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd0>;
- domain-idle-states = <&big_cpu_sleep_0 &big_cpu_sleep_1>;
+ domain-idle-states = <&big_cpu_sleep_0>;
};
cpu_pd1: power-domain-cpu1 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd0>;
- domain-idle-states = <&big_cpu_sleep_0 &big_cpu_sleep_1>;
+ domain-idle-states = <&big_cpu_sleep_0>;
};
cpu_pd2: power-domain-cpu2 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd0>;
- domain-idle-states = <&big_cpu_sleep_0 &big_cpu_sleep_1>;
+ domain-idle-states = <&big_cpu_sleep_0>;
};
cpu_pd3: power-domain-cpu3 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd0>;
- domain-idle-states = <&big_cpu_sleep_0 &big_cpu_sleep_1>;
+ domain-idle-states = <&big_cpu_sleep_0>;
};
cpu_pd4: power-domain-cpu4 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd1>;
- domain-idle-states = <&little_cpu_sleep_0 &little_cpu_sleep_1>;
+ domain-idle-states = <&little_cpu_sleep_0>;
};
cpu_pd5: power-domain-cpu5 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd1>;
- domain-idle-states = <&little_cpu_sleep_0 &little_cpu_sleep_1>;
+ domain-idle-states = <&little_cpu_sleep_0>;
};
cpu_pd6: power-domain-cpu6 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd1>;
- domain-idle-states = <&little_cpu_sleep_0 &little_cpu_sleep_1>;
+ domain-idle-states = <&little_cpu_sleep_0>;
};
cpu_pd7: power-domain-cpu7 {
#power-domain-cells = <0>;
power-domains = <&cluster_pd1>;
- domain-idle-states = <&little_cpu_sleep_0 &little_cpu_sleep_1>;
+ domain-idle-states = <&little_cpu_sleep_0>;
};
cluster_pd0: power-domain-cluster0 {
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] Remove gold/silver_cpu_sleep idle states for lemans and monaco
From: Navya Malempati @ 2026-05-22 11:10 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Navya Malempati
Firmware supports both CPU power collapse and CPU PLL/rail power collapse
idle states. However, CPU power collapse mode is often not utilized in
favor of performance. Remove CPU power collapse modes for lemans and
monaco as well aligning with SM8350/SM8450/SM8550/SM8650.
---
Navya Malempati (2):
arm64: dts: qcom: monaco: Remove the little/big_cpu_sleep_0 idle states
arm64: dts: qcom: lemans: Remove the gold_cpu_sleep idle state
arch/arm64/boot/dts/qcom/lemans.dtsi | 36 +++++++++---------------------------
arch/arm64/boot/dts/qcom/monaco.dtsi | 36 ++++++++----------------------------
2 files changed, 17 insertions(+), 55 deletions(-)
---
base-commit: 550604d6c9b9efc8d068aff94dc301694a7afdee
change-id: 20260522-ml_cpuidle-da0377956dc0
Best regards,
--
Navya Malempati <navya.malempati@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 6/7] arm64: dts: qcom: kodiak: consolidate IPA properties
From: Konrad Dybcio @ 2026-05-22 11:08 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alex Elder,
cros-qcom-dts-watchers
Cc: linux-arm-msm, devicetree, linux-kernel, Stanislav Zaikin
In-Reply-To: <20260517-ipa-loader-v1-6-3c3764c1b4a3@oss.qualcomm.com>
On 5/17/26 4:56 PM, Dmitry Baryshkov wrote:
> Move generic IPA-related properties to the base DTSI file. The herobrine
> has special software configuration, so delete the memory-region property
> which wasn't set for it beforehand. Also delete the property for several
> IoT devices, which don't enable IPA memory at this point (and don't
> seem to have IPA supported by the modem firmware).
>
> Co-developed-by: Stanislav Zaikin <zstaseg@gmail.com>
> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
[...]
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -504,6 +504,10 @@ &i2c13 {
> status = "okay";
> };
>
> +&ipa {
> + /delete-property/ memory-region;
> +};
On QC*S* parts, wouldn't IPA be disabled anyway?
That's what downstream did historically on APQ-ish SoCs, anyway
Konrad
^ 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