* [PATCH v4 2/3] dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens,
Krzysztof Kozlowski
In-Reply-To: <20260622221550.374235-1-jakubszczudlo40@gmail.com>
Register layouts are the same as for ADS1100 but ADS1110 have different
data rates and have internal voltage reference that is always 2.048V.
Also correct order of ads so they will be sorted alphabetically.
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/iio/adc/ti,ads1100.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
index 970ccab15e1e..28c5e2dd0ad6 100644
--- a/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1100.yaml
@@ -4,19 +4,23 @@
$id: http://devicetree.org/schemas/iio/adc/ti,ads1100.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: TI ADS1100/ADS1000 single channel I2C analog to digital converter
+title: TI ADS1100 and similar single channel I2C Analog to Digital Converters
maintainers:
- Mike Looijmans <mike.looijmans@topic.nl>
description: |
- Datasheet at: https://www.ti.com/lit/gpn/ads1100
+ Datasheets:
+ - https://www.ti.com/lit/gpn/ads1000
+ - https://www.ti.com/lit/gpn/ads1100
+ - https://www.ti.com/lit/gpn/ads1110
properties:
compatible:
enum:
- - ti,ads1100
- ti,ads1000
+ - ti,ads1100
+ - ti,ads1110
reg:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v4 1/3] iio: adc: Fix incorrect reading when datarate changed in single mode
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens
In-Reply-To: <20260622221550.374235-1-jakubszczudlo40@gmail.com>
When device is suspended and it is in single mode then changing
datarate doesn't make it actual wait for new measurement, so to
be sure that read after change is correct functions that changes
datarate and gain will wait for new data.
Fixes: 541880542f2b ("iio: adc: Add TI ADS1100 and ADS1000")
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
drivers/iio/adc/ti-ads1100.c | 74 ++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ti-ads1100.c b/drivers/iio/adc/ti-ads1100.c
index 9fe8d54cce83..e3c801381434 100644
--- a/drivers/iio/adc/ti-ads1100.c
+++ b/drivers/iio/adc/ti-ads1100.c
@@ -15,6 +15,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/i2c.h>
+#include <linux/iopoll.h>
#include <linux/mutex.h>
#include <linux/property.h>
#include <linux/pm_runtime.h>
@@ -43,6 +44,9 @@
static const int ads1100_data_rate[] = { 128, 32, 16, 8 };
static const int ads1100_data_rate_bits[] = { 12, 14, 15, 16 };
+/* Timeout based on the minimum sample rate of 8 SPS (7.5s) */
+#define ADS1100_MAX_DRDY_TIMEOUT_US 7500000
+
struct ads1100_data {
struct i2c_client *client;
struct regulator *reg_vdd;
@@ -123,10 +127,49 @@ static int ads1100_get_adc_result(struct ads1100_data *data, int chan, int *val)
return 0;
}
+static bool ads1100_new_data_not_ready(struct ads1100_data *data)
+{
+ int ret;
+ u8 buffer[3];
+
+ ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
+ if (ret < 0) {
+ dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
+ return true;
+ } else if (ret < 3) {
+ dev_err(&data->client->dev, "Short I2C read\n");
+ return true;
+ }
+
+ return FIELD_GET(ADS1100_CFG_ST_BSY, buffer[2]);
+}
+
+static int ads1100_poll_data_ready(struct ads1100_data *data)
+{
+ int ret;
+ u8 buffer[3];
+ bool data_ready;
+ int datarate = ads1100_data_rate[FIELD_GET(ADS1100_DR_MASK, data->config)];
+ /* To be sure we wait 5 times more than datarate */
+ unsigned long wait_time = DIV_ROUND_CLOSEST(MICRO, 5 * datarate);
+
+ /* To be sure that polled value will have value after config change */
+ ret = i2c_master_recv(data->client, (char *)&buffer, sizeof(buffer));
+ if (ret < 0) {
+ dev_err(&data->client->dev, "I2C read fail: %d\n", ret);
+ return ret;
+ }
+
+ return read_poll_timeout(ads1100_new_data_not_ready, data_ready,
+ !data_ready, wait_time,
+ ADS1100_MAX_DRDY_TIMEOUT_US, false, data);
+}
+
static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
{
int microvolts;
int gain;
+ int ret;
/* With Vdd between 2.7 and 5V, the scale is always below 1 */
if (val)
@@ -135,6 +178,12 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
if (!val2)
return -EINVAL;
+ PM_RUNTIME_ACQUIRE_AUTOSUSPEND(&data->client->dev, pm);
+
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
+ return ret;
+
microvolts = regulator_get_voltage(data->reg_vdd);
/*
* val2 is in 'micro' units, n = val2 / 1000000
@@ -149,19 +198,36 @@ static int ads1100_set_scale(struct ads1100_data *data, int val, int val2)
ads1100_set_config_bits(data, ADS1100_PGA_MASK, ffs(gain) - 1);
- return 0;
+ ret = ads1100_poll_data_ready(data);
+
+ return ret;
}
static int ads1100_set_data_rate(struct ads1100_data *data, int chan, int rate)
{
unsigned int i;
unsigned int size;
+ int ret;
size = data->supports_data_rate ? ARRAY_SIZE(ads1100_data_rate) : 1;
for (i = 0; i < size; i++) {
- if (ads1100_data_rate[i] == rate)
- return ads1100_set_config_bits(data, ADS1100_DR_MASK,
- FIELD_PREP(ADS1100_DR_MASK, i));
+ if (ads1100_data_rate[i] != rate)
+ continue;
+
+ PM_RUNTIME_ACQUIRE_AUTOSUSPEND(&data->client->dev, pm);
+
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
+ return ret;
+
+ ret = ads1100_set_config_bits(data, ADS1100_DR_MASK,
+ FIELD_PREP(ADS1100_DR_MASK, i));
+ if (ret)
+ return ret;
+
+ ret = ads1100_poll_data_ready(data);
+
+ return ret;
}
return -EINVAL;
--
2.47.3
^ permalink raw reply related
* [PATCH v4 0/3] iio: adc: Add support for TI ADS1110 to ti-ads1100 driver
From: Jakub Szczudlo @ 2026-06-22 22:15 UTC (permalink / raw)
To: linux-iio
Cc: andy, antoniu.miclaus, conor+dt, devicetree, dlechner, duje,
jic23, jishnu.prakash, jorge.marques, joshua.crofts1, krzk+dt,
linusw, jakubszczudlo40, linux-kernel, marcelo.schmitt,
mazziesaccount, mike.looijmans, nuno.sa, robh, sakari.ailus, wens
Add support for the TI ADS1110 to the existing ADS1100 ADC IIO driver.
The ADS1110 is pin-to-pin compatible with the ADS1100 while providing
higher resolution and an internal voltage reference. This patch series
extends driver support for ADS1110, updates device tree bindings and
Kconfig text, and improves the overall hardware description for the
TI ADS1100 family.
Tested on: Raspberry pi 3b+ with 7.0 stable kernel
Signed-off-by: Jakub Szczudlo <jakubszczudlo40@gmail.com>
---
V3 -> V4:
- make fixes patch the first change in the series
- correct error handling when short read
- use ACQUIRE macros from pm_runtime.h in new functions
- Link to v3: https://lore.kernel.org/linux-iio/20260613190957.654798-1-jakubszczudlo40@gmail.com/
V2 -> V3:
- clean patch from unreleated changes
- divide adding support for ads1110 into separate patch
- add missing changelog
- Link to v2: https://lore.kernel.org/linux-iio/20260607183542.368184-1-jakubszczudlo40@gmail.com/
V1 -> V2:
- go from creating new driver to extending ADS1100 driver to support ADS1110
- Link to v1: https://lore.kernel.org/linux-iio/20260527164312.355729-1-jakubszczudlo40@gmail.com/
Jakub Szczudlo (3):
iio: adc: Fix incorrect reading when datarate changed in single mode
dt-bindings: iio: adc: ti,ads1100: add support for ADS1110
iio: adc: Add ti-ads1110 support to ti-ads1100 driver
.../bindings/iio/adc/ti,ads1100.yaml | 10 +-
drivers/iio/adc/Kconfig | 6 +-
drivers/iio/adc/ti-ads1100.c | 153 +++++++++++++++---
3 files changed, 140 insertions(+), 29 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH 2/2] arm64: tegra: Fix CMDQV interrupt type on Tegra264
From: Nicolin Chen @ 2026-06-22 20:58 UTC (permalink / raw)
To: Ashish Mhetre
Cc: joro, will, robin.murphy, robh, krzk+dt, conor+dt, jonathanh,
thierry.reding, iommu, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260622065410.2780215-2-amhetre@nvidia.com>
On Mon, Jun 22, 2026 at 06:54:10AM +0000, Ashish Mhetre wrote:
> The CMDQV interrupts on Tegra264 are described as level-triggered, but
> per the hardware interrupt documentation these interrupts are actually
> edge-triggered.
>
> Correct the interrupt type for all CMDQV nodes from IRQ_TYPE_LEVEL_HIGH
> to IRQ_TYPE_EDGE_RISING.
>
> Fixes: fe57d0ac4835 ("arm64: tegra: Add nodes for CMDQV")
> Reported-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: Fix interrupt type in example
From: Nicolin Chen @ 2026-06-22 20:52 UTC (permalink / raw)
To: Ashish Mhetre
Cc: joro, will, robin.murphy, robh, krzk+dt, conor+dt, jonathanh,
thierry.reding, iommu, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260622065410.2780215-1-amhetre@nvidia.com>
On Mon, Jun 22, 2026 at 06:54:09AM +0000, Ashish Mhetre wrote:
> The CMDQV interrupt on Tegra264 is edge-triggered per the hardware
> interrupt documentation, but the binding example describes it as
> level-triggered. Correct the example to use IRQ_TYPE_EDGE_RISING so
> that it does not propagate the wrong trigger type.
>
> Fixes: 8a59954192eb ("dt-bindings: iommu: Add NVIDIA Tegra CMDQV support")
> Reported-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Acked-by: Nicolin Chen <nicolinc@nvidia.com>
^ permalink raw reply
* Re: [PATCH v5 2/3] counter: add GPIO-based counter driver
From: Wadim Mueller @ 2026-06-22 20:51 UTC (permalink / raw)
To: William Breathitt Gray
Cc: Oleksij Rempel, kernel, conor+dt, krzk+dt, robh, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260617074929.333876-1-wbg@kernel.org>
On Wed, 17 Jun 2026 16:49:25 +0900
William Breathitt Gray <wbg@kernel.org> wrote:
Hi William,
thanks for the review. Three things before I spin v6.
> One change I consider is whether to make Signal B optional. [...]
> I wonder whether this is substantially different enough from
> simply using the interrupt-cnt module on the respective IRQ?
> I'm CCing Oleksij and the Pengutronix team in case they wish to
> comment.
I want to keep signal-b mandatory in v6 (if no concerns from Oleksij). The single-line case is
already covered by interrupt-cnt.
> In such a configuration, we would have two Counts: Count 1 [...]
> Count 2 supports only increase/decrease modes with a Synapse for
> Signal B.
Just to confirm, plan for v6 is:
Count 0 "AB Count": A + B + optional index0, all 8 functions
Count 1 "B Count": B + optional index1, increase/decrease only
One counter_ops, dispatch on count->id. Per-count state in
struct gpio_counter_count_priv (value, ceiling, preset, preset_enabled,
enabled, function, direction), held in priv->count_priv[2] as you
suggested. prev_a/prev_b stay on priv (they describe the wire, not
the count).
For the second Index in DT I would just let index-gpios take 1..2
entries (first = count0, second = count1), no new property. Ok for
you and Conor?
> Hmm, is it a problem that priv->enabled is changed to a false state
> before the IRQs are actually disabled? Do any issues arise if an IRQ
> is handled during that brief period of time?
I guess it is a race. In v6 I will reorder:
enable=1: enable_irq(); lock; enabled = true; unlock;
enable=0: lock; enabled = false; unlock; disable_irq();
Plus a mutex around enable_write so two writers can not interleave
(disable_irq() can not run under the spinlock).
All other points from your review (kill *_delta, STATE_CHANGED for
all quadrature modes, INC/DEC both edges, drop prev_a check in
pulse-direction, ...) go into v6 too.
action_write and floor in a follow-up, as you suggested.
Thanks,
Wadim
^ permalink raw reply
* Re: [PATCH 3/4] memory: brcmstb_dpfe: support DPFE API v4
From: Markus Mayer @ 2026-06-22 20:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Florian Fainelli, Rob Herring, Conor Dooley,
Linux ARM Kernel List, Device Tree Mailing List,
Linux Kernel Mailing List
In-Reply-To: <CAGt4E5tGHJFXswic6vTx-ThN2K9xBtO8oA4ybrXg+q5cA6GYCA@mail.gmail.com>
On Thu, 28 May 2026 at 14:45, Markus Mayer <mmayer@broadcom.com> wrote:
> > > Thanks for providing justification, quite reasonable. A pity that none
> > > of the commit msgs answered this way.
> >
> > The real pity is how this API was designed, making all of this
> > necessary in the first place.
> >
> > We can definitely spell out more clearly in the commit messages what
> > is going on and why all of this is needed. I'll pull all the pieces
> > together from the various responses. As long as there's a way we can
> > reasonably implement what we need, we'll be happy.
>
> It has been a minute, but we'd like to resume this effort[1] to
> upstream these changes or some variation thereof.
>
> What are the best steps to resume this undertaking? There are still a
> few topics where I am not entirely clear on how to better explain
> things or how to address the feedback provided. My apologies for that.
> I will do my best to address whatever concerns there are.
>
> Should I put together a new pull request that contains improved commit
> messages and addresses some of the feedback and we hash out whatever
> questions remain on the new thread? Or would it be better for me to
> reply to the old thread with some of the questions that remain before
> sending a revised series?
Any advice on how to best proceed from here?
Thanks,
-Markus
> [1] https://lore.kernel.org/all/20231205184741.3092376-1-mmayer@broadcom.com/
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Sebastian Reichel @ 2026-06-22 20:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Javier Martinez Canillas, Liam Girdwood, Mark Brown,
Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
Hi,
On Mon, Jun 22, 2026 at 12:16:08PM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> ---
[...]
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
[...]
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 20:05 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <f7aae511-0e23-41cf-a5b0-27782caac30b@baylibre.com>
On Mon Jun 22, 2026 at 3:01 PM -05, David Lechner wrote:
> On 6/22/26 2:58 PM, Kurt Borja wrote:
>> On Mon Jun 22, 2026 at 2:38 PM -05, David Lechner wrote:
>>> On 6/22/26 2:30 PM, Kurt Borja wrote:
>>>> Hi all,
>>>>
>>>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>>>> I was made aware by David [2] that at least two more chip families,
>>>> ads1220 [3] and ads1x2c14, share very similar features (though these
>>>> chips are not really compatible between them). After that, I found one
>>>> more chip with the same features which is already upstream, the
>>>> AD4170-4.
>>>>
>>>> As David explained in [2], these chips are intended to be used with
>>>> RTDs, thermocouples or other resistive sensors so they share the
>>>> following per-channel features:
>>>>
>>>> - Configurable reference selection
>>>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>>>> - Excitation current sources (usually called IDACs TI) for sensor
>>>> current biasing
>>>>
>>>> Given that these three features are present in all four devices and
>>>> three of these drivers are still under review, my proposal is to have
>>>> these features be described in adc.yaml and have this series merged
>>>> before the three others [1] [2] [3].
>>>>
>>>> This series is sent as RFC because I still don't have much experience
>>>> with dt-bindings and I don't know if this approach or the properties are
>>>> general enough to be described like this.
>>>
>>> It will probably be easier if I just include these patches when I do
>>> v2 of my series (if you don't mind me tweaking them a bit).
>>
>> Sure, that's fine by me. I'll add a dependency to your series with b4.
>>
>> Want me to send one more version addressing your comments before you
>> take it in?
>>
>
> No need. I don't mind fixing it up.
Thanks :)
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: David Lechner @ 2026-06-22 20:01 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <DJFUE81GZEEG.35TP4FFBVE63B@gmail.com>
On 6/22/26 2:58 PM, Kurt Borja wrote:
> On Mon Jun 22, 2026 at 2:38 PM -05, David Lechner wrote:
>> On 6/22/26 2:30 PM, Kurt Borja wrote:
>>> Hi all,
>>>
>>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>>> I was made aware by David [2] that at least two more chip families,
>>> ads1220 [3] and ads1x2c14, share very similar features (though these
>>> chips are not really compatible between them). After that, I found one
>>> more chip with the same features which is already upstream, the
>>> AD4170-4.
>>>
>>> As David explained in [2], these chips are intended to be used with
>>> RTDs, thermocouples or other resistive sensors so they share the
>>> following per-channel features:
>>>
>>> - Configurable reference selection
>>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>>> - Excitation current sources (usually called IDACs TI) for sensor
>>> current biasing
>>>
>>> Given that these three features are present in all four devices and
>>> three of these drivers are still under review, my proposal is to have
>>> these features be described in adc.yaml and have this series merged
>>> before the three others [1] [2] [3].
>>>
>>> This series is sent as RFC because I still don't have much experience
>>> with dt-bindings and I don't know if this approach or the properties are
>>> general enough to be described like this.
>>
>> It will probably be easier if I just include these patches when I do
>> v2 of my series (if you don't mind me tweaking them a bit).
>
> Sure, that's fine by me. I'll add a dependency to your series with b4.
>
> Want me to send one more version addressing your comments before you
> take it in?
>
No need. I don't mind fixing it up.
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 19:58 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <42e544b8-f2da-450b-92bb-99c41f1c72fe@baylibre.com>
On Mon Jun 22, 2026 at 2:38 PM -05, David Lechner wrote:
> On 6/22/26 2:30 PM, Kurt Borja wrote:
>> Hi all,
>>
>> After submitting a patch series adding support for TI ADS126X ADCs [1],
>> I was made aware by David [2] that at least two more chip families,
>> ads1220 [3] and ads1x2c14, share very similar features (though these
>> chips are not really compatible between them). After that, I found one
>> more chip with the same features which is already upstream, the
>> AD4170-4.
>>
>> As David explained in [2], these chips are intended to be used with
>> RTDs, thermocouples or other resistive sensors so they share the
>> following per-channel features:
>>
>> - Configurable reference selection
>> - Burn-out Current Sources (BOCS) for diagnostic purpuses
>> - Excitation current sources (usually called IDACs TI) for sensor
>> current biasing
>>
>> Given that these three features are present in all four devices and
>> three of these drivers are still under review, my proposal is to have
>> these features be described in adc.yaml and have this series merged
>> before the three others [1] [2] [3].
>>
>> This series is sent as RFC because I still don't have much experience
>> with dt-bindings and I don't know if this approach or the properties are
>> general enough to be described like this.
>
> It will probably be easier if I just include these patches when I do
> v2 of my series (if you don't mind me tweaking them a bit).
Sure, that's fine by me. I'll add a dependency to your series with b4.
Want me to send one more version addressing your comments before you
take it in?
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH v4 01/16] spi: dt-bindings: add spi-max-post-config-frequency property
From: Conor Dooley @ 2026-06-22 19:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Santhosh Kumar K, broonie, robh, krzk+dt, conor+dt, miquel.raynal,
richard, vigneshr, pratyush, mwalle, takahiro.kuwano, linux-spi,
devicetree, linux-kernel, linux-mtd, praneeth, u-kumar1, a-dutta
In-Reply-To: <20260622-private-curly-fennec-7e1ad0@quoll>
[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]
On Mon, Jun 22, 2026 at 11:14:32AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jun 18, 2026 at 01:07:10PM +0530, Santhosh Kumar K wrote:
> > Add spi-max-post-config-frequency, a generic uint32 property for SPI
> > peripherals that support two distinct clock rates: a conservative rate
> > always reachable without controller configuration, and a higher rate
> > reachable only after controller-side configuration such as PHY tuning.
> >
> > When both properties are present, spi-max-frequency gives the
> > conservative pre-configuration rate and spi-max-post-config-frequency
> > gives the higher post-configuration target.
> >
> > Signed-off-by: Santhosh Kumar K <s-k6@ti.com>
> > ---
> > .../devicetree/bindings/spi/spi-peripheral-props.yaml | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > index 880a9f624566..ece86f65930f 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> > @@ -45,6 +45,12 @@ properties:
> > description:
> > Maximum SPI clocking speed of the device in Hz.
> >
> > + spi-max-post-config-frequency:
>
> -hz
Ah d'oh. I was hung up on matching the existing property that I didn't
include -hz in my original suggestion, sorry!
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml
>
> and you need maxItems: 1.
>
> Now, please take time and think if this should not be an array instead
> (maxItems: ...) to cover other possible cases, e.g. different tuning
> levels? IOW, having single spi-max-frequency turned out to be
> insufficient. You address that insufficiency with one more frequency,
> but what if this is going to be insufficient next month as well?
>
> I don't know, answer is rather for domain experts.
>
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Maximum SPI clock frequency in Hz achievable post controller-side
> > + configuration.
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 3/3] dt-bindings: iio: adc: Add burn-out current properties
From: David Lechner @ 2026-06-22 19:44 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-3-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Some ADCs incorporate burn-out current sources that provide current to
> the channel's input pins for open-circuit or short-circuit detection.
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> index 160a8cfa9842a86..9240f569d4ab7af 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> @@ -105,6 +105,12 @@ properties:
> This array describes the current configuration of the excitation current
> sources or the single matched current for all sources.
>
> + burn-out-current-microamp:
This also needs to be nanoamp.
> + maxItems: 1
> + description:
> + Burn-out current sources provide current to the channel's input pins for
> + open-circuit or short-circuit detection.
> +
> anyOf:
> - oneOf:
> - required:
>
^ permalink raw reply
* Re: [PATCH RFC v2 2/3] dt-bindings: iio: adc: Add excitation current sources properties
From: David Lechner @ 2026-06-22 19:42 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-2-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Some ADCs incorporate current sources that provide excitation current to
> resistive temperature devices (RTDs), thermistors, diodes and other
> resistive sensors that require constant current biasing.
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> index fdad6b8276c934c..160a8cfa9842a86 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> @@ -86,6 +86,25 @@ properties:
> source. If two values are provided, the first one corresponds to the
> positive source and the second to the negative source.
>
> + excitation-channels:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Excitation current sources provide current to resistive temperature
> + devices (RTDs), thermistors, diodes and other resistive sensors that
> + require constant current biasing.
> +
> + This array describes the mux configuration of the excitation current
> + sources.
> +
> + excitation-current-microamp:
As seen in adi,ltc2983.yaml, this actually needs to be nanoamp to be able
to be flexible for all parts.
> + description:
> + Excitation current sources provide current to resistive temperature
> + devices (RTDs), thermistors, diodes and other resistive sensors that
> + require constant current biasing.
> +
> + This array describes the current configuration of the excitation current
> + sources or the single matched current for all sources.
> +
> anyOf:
> - oneOf:
> - required:
>
^ permalink raw reply
* Re: [PATCH RFC v2 1/3] dt-bindings: iio: adc: Add reference-source property
From: David Lechner @ 2026-06-22 19:40 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-1-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Some ADCs have configurable voltage reference sources for each channel.
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> index b9bc02b5b07a4c7..fdad6b8276c934c 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
> @@ -73,6 +73,19 @@ properties:
> device design and can interact with other characteristics such as
> settling time.
>
> + reference-source:
Since this is an array, the name should be `reference-sources`.
> + $ref: /schemas/types.yaml#/definitions/string-array
> + maxItems: 2
> + minItems: 1
Maybe minItems here is OK, but I don't think we should put maxItems here.
This way, it stays more flexible for other use cases.
> + description:
> + Indicates the voltage reference source or sources for this channel. Some
> + ADCs usually allow choosing between internal reference sources or a pair
> + of external pins.
> +
> + If a single value is provided, it represents a single voltage reference
> + source. If two values are provided, the first one corresponds to the
> + positive source and the second to the negative source.
> +
> anyOf:
> - oneOf:
> - required:
>
^ permalink raw reply
* Re: [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: David Lechner @ 2026-06-22 19:38 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
On 6/22/26 2:30 PM, Kurt Borja wrote:
> Hi all,
>
> After submitting a patch series adding support for TI ADS126X ADCs [1],
> I was made aware by David [2] that at least two more chip families,
> ads1220 [3] and ads1x2c14, share very similar features (though these
> chips are not really compatible between them). After that, I found one
> more chip with the same features which is already upstream, the
> AD4170-4.
>
> As David explained in [2], these chips are intended to be used with
> RTDs, thermocouples or other resistive sensors so they share the
> following per-channel features:
>
> - Configurable reference selection
> - Burn-out Current Sources (BOCS) for diagnostic purpuses
> - Excitation current sources (usually called IDACs TI) for sensor
> current biasing
>
> Given that these three features are present in all four devices and
> three of these drivers are still under review, my proposal is to have
> these features be described in adc.yaml and have this series merged
> before the three others [1] [2] [3].
>
> This series is sent as RFC because I still don't have much experience
> with dt-bindings and I don't know if this approach or the properties are
> general enough to be described like this.
It will probably be easier if I just include these patches when I do
v2 of my series (if you don't mind me tweaking them a bit).
>
> No dependencies between properties were provided because not all devices
> may be able to configure each one of them.
>
> [1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
> [2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
> [3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>
> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
> ---
> v2:
> - reference-source is now a string-array and now presents a couple of
> quick examples
> - excitation-* properties now do not enforce arbitrary limits
> - Dropped burn-out-current-polarity because it was not general enough
> - I kept burn-out-current-microamp because the discussion around it is
> still ongoing
>
> v1: https://patch.msgid.link/20260618-new-channel-props-v1-0-963c1b5cf40a@gmail.com
>
> ---
> Kurt Borja (3):
> dt-bindings: iio: adc: Add reference-source property
> dt-bindings: iio: adc: Add excitation current sources properties
> dt-bindings: iio: adc: Add burn-out current properties
>
> Documentation/devicetree/bindings/iio/adc/adc.yaml | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> ---
> base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
> change-id: 20260618-new-channel-props-4fbd52020da2
>
^ permalink raw reply
* [PATCH RFC v2 3/3] dt-bindings: iio: adc: Add burn-out current properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
Some ADCs incorporate burn-out current sources that provide current to
the channel's input pins for open-circuit or short-circuit detection.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index 160a8cfa9842a86..9240f569d4ab7af 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -105,6 +105,12 @@ properties:
This array describes the current configuration of the excitation current
sources or the single matched current for all sources.
+ burn-out-current-microamp:
+ maxItems: 1
+ description:
+ Burn-out current sources provide current to the channel's input pins for
+ open-circuit or short-circuit detection.
+
anyOf:
- oneOf:
- required:
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v2 2/3] dt-bindings: iio: adc: Add excitation current sources properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
Some ADCs incorporate current sources that provide excitation current to
resistive temperature devices (RTDs), thermistors, diodes and other
resistive sensors that require constant current biasing.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index fdad6b8276c934c..160a8cfa9842a86 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -86,6 +86,25 @@ properties:
source. If two values are provided, the first one corresponds to the
positive source and the second to the negative source.
+ excitation-channels:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Excitation current sources provide current to resistive temperature
+ devices (RTDs), thermistors, diodes and other resistive sensors that
+ require constant current biasing.
+
+ This array describes the mux configuration of the excitation current
+ sources.
+
+ excitation-current-microamp:
+ description:
+ Excitation current sources provide current to resistive temperature
+ devices (RTDs), thermistors, diodes and other resistive sensors that
+ require constant current biasing.
+
+ This array describes the current configuration of the excitation current
+ sources or the single matched current for all sources.
+
anyOf:
- oneOf:
- required:
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v2 1/3] dt-bindings: iio: adc: Add reference-source property
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
In-Reply-To: <20260622-new-channel-props-v2-0-aafd5369f253@gmail.com>
Some ADCs have configurable voltage reference sources for each channel.
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
Documentation/devicetree/bindings/iio/adc/adc.yaml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
index b9bc02b5b07a4c7..fdad6b8276c934c 100644
--- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
@@ -73,6 +73,19 @@ properties:
device design and can interact with other characteristics such as
settling time.
+ reference-source:
+ $ref: /schemas/types.yaml#/definitions/string-array
+ maxItems: 2
+ minItems: 1
+ description:
+ Indicates the voltage reference source or sources for this channel. Some
+ ADCs usually allow choosing between internal reference sources or a pair
+ of external pins.
+
+ If a single value is provided, it represents a single voltage reference
+ source. If two values are provided, the first one corresponds to the
+ positive source and the second to the negative source.
+
anyOf:
- oneOf:
- required:
--
2.54.0
^ permalink raw reply related
* [PATCH RFC v2 0/3] dt-bindings: iio: adc: Add reference, excitation and burn-out properties
From: Kurt Borja @ 2026-06-22 19:30 UTC (permalink / raw)
To: Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner
Cc: Nuno Sá, Andy Shevchenko, linux-iio, devicetree,
linux-kernel, Kurt Borja
Hi all,
After submitting a patch series adding support for TI ADS126X ADCs [1],
I was made aware by David [2] that at least two more chip families,
ads1220 [3] and ads1x2c14, share very similar features (though these
chips are not really compatible between them). After that, I found one
more chip with the same features which is already upstream, the
AD4170-4.
As David explained in [2], these chips are intended to be used with
RTDs, thermocouples or other resistive sensors so they share the
following per-channel features:
- Configurable reference selection
- Burn-out Current Sources (BOCS) for diagnostic purpuses
- Excitation current sources (usually called IDACs TI) for sensor
current biasing
Given that these three features are present in all four devices and
three of these drivers are still under review, my proposal is to have
these features be described in adc.yaml and have this series merged
before the three others [1] [2] [3].
This series is sent as RFC because I still don't have much experience
with dt-bindings and I don't know if this approach or the properties are
general enough to be described like this.
No dependencies between properties were provided because not all devices
may be able to configure each one of them.
[1] https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
[2] https://lore.kernel.org/linux-iio/20260615-iio-adc-ti-ads122c14-v1-0-e6bdadf7cb2b@baylibre.com/
[3] https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
Signed-off-by: Kurt Borja <kuurtb@gmail.com>
---
v2:
- reference-source is now a string-array and now presents a couple of
quick examples
- excitation-* properties now do not enforce arbitrary limits
- Dropped burn-out-current-polarity because it was not general enough
- I kept burn-out-current-microamp because the discussion around it is
still ongoing
v1: https://patch.msgid.link/20260618-new-channel-props-v1-0-963c1b5cf40a@gmail.com
---
Kurt Borja (3):
dt-bindings: iio: adc: Add reference-source property
dt-bindings: iio: adc: Add excitation current sources properties
dt-bindings: iio: adc: Add burn-out current properties
Documentation/devicetree/bindings/iio/adc/adc.yaml | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
---
base-commit: a50909aa46dec46de3c73235fc15a7d6f763d996
change-id: 20260618-new-channel-props-4fbd52020da2
--
Thanks,
~ Kurt
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: qcom: sm8250-xiaomi-elish: add ov8856 front camera
From: Xin Xu @ 2026-06-22 18:52 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
powered by pm8008 LDOs and other supplies.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v2:
- Fix coding style (property order)
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index c514478cba4f..262cb9f29ebc 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/usb/pd.h>
@@ -531,6 +532,61 @@ vreg_l7f_1p8: ldo7 {
};
};
+&camss {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+
+ ports {
+ port@4 {
+ csiphy4_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&ov8856_front_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera_front: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ avdd-supply = <&vreg_l5p>;
+ dovdd-supply = <&vreg_l1c_1p8>;
+ dvdd-supply = <&vreg_l1p>;
+
+ clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ clock-names = "xvclk";
+ assigned-clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&mclk3_active &camera_front_active>;
+ pinctrl-names = "default";
+
+ orientation = <0>; /* Front facing */
+ rotation = <270>;
+
+ port {
+ ov8856_front_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64
+ <720000000 360000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
&cdsp {
firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
status = "okay";
@@ -877,6 +933,20 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ camera_front_active: camera-front-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ mclk3_active: mclk3-active-state {
+ pins = "gpio97";
+ function = "cam_mclk";
+ bias-disable;
+ drive-strength = <4>;
+ };
+
pm8008_default: pm8008-default-state {
int-pins {
pins = "gpio84";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Xin Xu @ 2026-06-22 18:46 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
Add the pm8008 PMIC node on i2c15 with seven LDOs,
using GPIO84 as interrupt and GPIO76 as reset.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v2:
- Fix coding style (blank line, interrupts-extended, property order,
drop output-high)
- Correct voltage constraints for ldo1 and ldo2
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 93 +++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 51b57c697a75..c514478cba4f 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -571,6 +571,82 @@ fuel-gauge@55 {
};
};
+&i2c15 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ pm8008: pmic@8 {
+ compatible = "qcom,pm8008";
+ reg = <0x8>;
+
+ interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&tlmm 76 GPIO_ACTIVE_LOW>;
+
+ vdd-l1-l2-supply = <&vreg_s8c_1p35>;
+ vdd-l3-l4-supply = <&vreg_bob>;
+ vdd-l5-supply = <&vreg_bob>;
+ vdd-l6-supply = <&vreg_bob>;
+ vdd-l7-supply = <&vreg_bob>;
+
+ pinctrl-0 = <&pm8008_default>;
+ pinctrl-names = "default";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pm8008 0 0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ #thermal-sensor-cells = <0>;
+
+ regulators {
+ vreg_l1p: ldo1 {
+ regulator-name = "vreg_l1p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l2p: ldo2 {
+ regulator-name = "vreg_l2p";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vreg_l3p: ldo3 {
+ regulator-name = "vreg_l3p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l4p: ldo4 {
+ regulator-name = "vreg_l4p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l5p: ldo5 {
+ regulator-name = "vreg_l5p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+
+ vreg_l6p: ldo6 {
+ regulator-name = "vreg_l6p";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vreg_l7p: ldo7 {
+ regulator-name = "vreg_l7p";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2900000>;
+ };
+ };
+ };
+};
+
&i2c11 {
clock-frequency = <400000>;
status = "okay";
@@ -801,6 +877,23 @@ bt_en_state: bt-default-state {
bias-pull-up;
};
+ pm8008_default: pm8008-default-state {
+ int-pins {
+ pins = "gpio84";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ input-enable;
+ };
+
+ reset-pins {
+ pins = "gpio76";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 0/2] Add support for StarFive JHB100 SPI
From: Mark Brown @ 2026-06-19 17:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Changhuang Liang
Cc: linux-spi, linux-kernel, devicetree
In-Reply-To: <20260619143443.22267-1-changhuang.liang@starfivetech.com>
On Fri, 19 Jun 2026 07:34:41 -0700, Changhuang Liang wrote:
> Add support for StarFive JHB100 SPI
>
> The StarFive JHB100 SPI is based on the Synopsys DesignWare SSI version 2.00.
>
> changes since v1:
> PATCH 1:
> - Add "starfive,jhb100-spi" and support falling back to
> "snps,dwc-ssi-2.00a" or "snps,dwc-ssi-1.01a".
> - using subject lines reflecting the style for the
> spi subsystem.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2
Thanks!
[1/2] spi: dt-bindings: snps,dw-apb-ssi: Add starfive,jhb100-spi
https://git.kernel.org/broonie/spi/c/07f251e0ed0b
[2/2] spi: dw: Add support for snps,dwc-ssi-2.00a
https://git.kernel.org/broonie/spi/c/914e708e3049
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-22 18:39 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Nuno Sá, Rodrigo Alencar, Janani Sunil, 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: <20260622172911.48259a0c@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
On Mon, Jun 22, 2026 at 05:29:11PM +0100, Jonathan Cameron wrote:
> > > > 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).
> >
> > 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.
>
> Agreed - if we have messages that address both devices at once that needs
> to be a unified driver and given they are about triggering simultaneous
> update of all channels it needs to look like one big device.
> This ends up similar to how we handle daisy chain devices.
>
> The question of what to do on devices that don't have this feature
> is rather different. Good thing you read the datasheet :)
I'm not sure it really is, the intent for the microchip devices I think
is pretty similar. The mcp3911 datasheet cites three-phase power
metering using three devices as a typical use-case, for example.
Probably creating an amalgamated device is a good fit there too?
I assume an amalgamated device for this ADI product means per-channel ID
properties? If so, I think they should be made generic and the Microchip
products retrofitted to use them, with a fallback to the proprietary
property. Not going to ask for the support for multiple devices in those
drivers, since the current way doesn't work and there'd be no loss of
support. Someone from Microchip can do that. The proprietary property
to generic conversion should be straightforward and provides weight to
an argument for this being generic, since that'd be three devices that
can all share?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/3] regulator: dt-bindings: Add Unisoc SC2730 PMIC
From: Mark Brown @ 2026-06-22 18:23 UTC (permalink / raw)
To: Otto Pflüger
Cc: Krzysztof Kozlowski, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Orson Zhai, Baolin Wang,
Chunyan Zhang, Lee Jones, linux-kernel, devicetree,
Krzysztof Kozlowski
In-Reply-To: <ajl8YparXoIXL0wm@abscue.de>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Mon, Jun 22, 2026 at 08:18:10PM +0200, Otto Pflüger wrote:
> Also, is it generally a rule now that the comatible is left out for MFD
> child nodes, or is there a reason why this is only done for regulators?
> Is this related to the (non-)existence of a reg property in the child?
It happens more for regulators because I tend to bring up that people
are encoding Linux internals rather than describing the hardware.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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