The TI TLA 2528 is a simple 8 channel, 12-bit ADC? Add a binding
documentation for it.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
.../bindings/iio/adc/ti,tla2528.yaml | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
new file mode 100644
index 000000000000..0ee326d77014
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/ti,tla2528.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TLA2528 8-channel 12bit I2C ADC
+
+maintainers:
+ - Maxime Chevallier <maxime.chevallier@bootlin.com>
+
+description: |
+ 12bit 8-channel I2C ADC.
+
+properties:
+ compatible:
+ const: ti,tla2528
+
+ reg:
+ maxItems: 1
+
+ vref-supply:
+ description: Supply for 2.35V to 5.5V reference voltage
+
+ "#io-channel-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - vref-supply
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ adc@17 {
+ compatible = "ti,tla2528";
+ reg = <0x17>;
+ vref-supply = <®_adc_supply>;
+ #io-channel-cells = <1>;
+ };
+ };
+...
--
2.49.0On 12/23/25 9:55 AM, Maxime Chevallier wrote:
> The TI TLA 2528 is a simple 8 channel, 12-bit ADC? Add a binding
TLA2528 (no space). Also, why the "?"?
> documentation for it.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
> .../bindings/iio/adc/ti,tla2528.yaml | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
> new file mode 100644
> index 000000000000..0ee326d77014
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/ti,tla2528.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments TLA2528 8-channel 12bit I2C ADC
12-bit
> +
> +maintainers:
> + - Maxime Chevallier <maxime.chevallier@bootlin.com>
> +
> +description: |
> + 12bit 8-channel I2C ADC.
The title already says this. Either drop it or add new info.
Also, don't need the |.
> +
> +properties:
> + compatible:
> + const: ti,tla2528
> +
> + reg:
> + maxItems: 1
> +
> + vref-supply:
> + description: Supply for 2.35V to 5.5V reference voltage
According the the datasheet, there are AVDD and DVDD supplies.
Nothing named VREF or REF.
So instead:
avdd-supply: true
dvdd-supply: true
It looks like inputs can also be used as GPIOs, so
gpio-controller: true
#gpio-cells:
const: 2
would be appropriate (it doesn't matter if the driver doesn't
implement it, we know what the correct bindings are).
> +
> + "#io-channel-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - vref-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@17 {
> + compatible = "ti,tla2528";
> + reg = <0x17>;
> + vref-supply = <®_adc_supply>;
> + #io-channel-cells = <1>;
> + };
> + };
> +...
On 23/12/2025 19:26, David Lechner wrote:
> On 12/23/25 9:55 AM, Maxime Chevallier wrote:
>> The TI TLA 2528 is a simple 8 channel, 12-bit ADC? Add a binding
>
> TLA2528 (no space). Also, why the "?"?
that's a typo :) thanks for spotting
>
>> documentation for it.
>>
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> ---
>> .../bindings/iio/adc/ti,tla2528.yaml | 48 +++++++++++++++++++
>> 1 file changed, 48 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
>> new file mode 100644
>> index 000000000000..0ee326d77014
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml
>> @@ -0,0 +1,48 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/ti,tla2528.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments TLA2528 8-channel 12bit I2C ADC
>
> 12-bit
>
>> +
>> +maintainers:
>> + - Maxime Chevallier <maxime.chevallier@bootlin.com>
>> +
>> +description: |
>> + 12bit 8-channel I2C ADC.
>
> The title already says this. Either drop it or add new info.
>
> Also, don't need the |.
>
>> +
>> +properties:
>> + compatible:
>> + const: ti,tla2528
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + vref-supply:
>> + description: Supply for 2.35V to 5.5V reference voltage
>
> According the the datasheet, there are AVDD and DVDD supplies.
> Nothing named VREF or REF.
>
> So instead:
>
> avdd-supply: true
> dvdd-supply: true
Sure thing, I'll add both instead
>
>
> It looks like inputs can also be used as GPIOs, so
>
> gpio-controller: true
> #gpio-cells:
> const: 2
>
> would be appropriate (it doesn't matter if the driver doesn't
> implement it, we know what the correct bindings are).
Ack, makes a lot of sense
>
>> +
>> + "#io-channel-cells":
>> + const: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - vref-supply
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + i2c {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + adc@17 {
>> + compatible = "ti,tla2528";
>> + reg = <0x17>;
>> + vref-supply = <®_adc_supply>;
>> + #io-channel-cells = <1>;
>> + };
>> + };
>> +...
>
Thank you for reviewing,
Maxime
On 23/12/2025 20:26, David Lechner wrote: > On 12/23/25 9:55 AM, Maxime Chevallier wrote: >> The TI TLA 2528 is a simple 8 channel, 12-bit ADC? Add a binding > > TLA2528 (no space). Also, why the "?"? > >> documentation for it. >> >> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> >> --- >> .../bindings/iio/adc/ti,tla2528.yaml | 48 +++++++++++++++++++ >> 1 file changed, 48 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml >> >> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml >> new file mode 100644 >> index 000000000000..0ee326d77014 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iio/adc/ti,tla2528.yaml >> @@ -0,0 +1,48 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/iio/adc/ti,tla2528.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Texas Instruments TLA2528 8-channel 12bit I2C ADC > > 12-bit > >> + >> +maintainers: >> + - Maxime Chevallier <maxime.chevallier@bootlin.com> >> + >> +description: | >> + 12bit 8-channel I2C ADC. > > The title already says this. Either drop it or add new info. > > Also, don't need the |. > >> + >> +properties: >> + compatible: >> + const: ti,tla2528 >> + >> + reg: >> + maxItems: 1 >> + >> + vref-supply: >> + description: Supply for 2.35V to 5.5V reference voltage > > According the the datasheet, there are AVDD and DVDD supplies. > Nothing named VREF or REF. > > So instead: > > avdd-supply: true > dvdd-supply: true > > > It looks like inputs can also be used as GPIOs, so > > gpio-controller: true > #gpio-cells: > const: 2 > > would be appropriate (it doesn't matter if the driver doesn't > implement it, we know what the correct bindings are). > >> + >> + "#io-channel-cells": >> + const: 1 I didn't check the data-sheet, but if the pins can be set to be GPIOs or ADC inputs, then I would require channels to be specified. It's only 8 channels, so always listing channels that are present shouldn't be that big of a problem - and it should avoid one to add extra properties to denote channels used for GPIO if GPIOs need to be supported. Well, I am not insisting this, there are folks that know this stuff better than I :) Yours, -- Matti --- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
On Mon, Dec 29, 2025 at 10:04 AM Matti Vaittinen <mazziesaccount@gmail.com> wrote: > On 23/12/2025 20:26, David Lechner wrote: > > On 12/23/25 9:55 AM, Maxime Chevallier wrote: ... > > It looks like inputs can also be used as GPIOs, so > > > > gpio-controller: true > > #gpio-cells: > > const: 2 > > > > would be appropriate (it doesn't matter if the driver doesn't > > implement it, we know what the correct bindings are). > > > >> + > >> + "#io-channel-cells": > >> + const: 1 > > I didn't check the data-sheet, but if the pins can be set to be GPIOs or > ADC inputs, then I would require channels to be specified. It's only 8 > channels, so always listing channels that are present shouldn't be that > big of a problem - and it should avoid one to add extra properties to > denote channels used for GPIO if GPIOs need to be supported. > > Well, I am not insisting this, there are folks that know this stuff > better than I :) Why would we need an extra property for that? GPIO controller has a property for valid_mask, should be enough to handle this case, no? -- With Best Regards, Andy Shevchenko
On 29/12/2025 11:31, Andy Shevchenko wrote: > On Mon, Dec 29, 2025 at 10:04 AM Matti Vaittinen > <mazziesaccount@gmail.com> wrote: >> On 23/12/2025 20:26, David Lechner wrote: >>> On 12/23/25 9:55 AM, Maxime Chevallier wrote: > > ... > >>> It looks like inputs can also be used as GPIOs, so >>> >>> gpio-controller: true >>> #gpio-cells: >>> const: 2 >>> >>> would be appropriate (it doesn't matter if the driver doesn't >>> implement it, we know what the correct bindings are). >>> >>>> + >>>> + "#io-channel-cells": >>>> + const: 1 >> >> I didn't check the data-sheet, but if the pins can be set to be GPIOs or >> ADC inputs, then I would require channels to be specified. It's only 8 >> channels, so always listing channels that are present shouldn't be that >> big of a problem - and it should avoid one to add extra properties to >> denote channels used for GPIO if GPIOs need to be supported. >> >> Well, I am not insisting this, there are folks that know this stuff >> better than I :) > > Why would we need an extra property for that? GPIO controller has a > property for valid_mask, should be enough to handle this case, no? > Ah. You're right. The "valid_mask" should be perfectly usable. I might still require the channel information to make it explicit - but as I said, I leave this for others to decide :) Yours, -- Matti --- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~
Hi David, Matti, Andy, On 29/12/2025 14:23, Matti Vaittinen wrote: > On 29/12/2025 11:31, Andy Shevchenko wrote: >> On Mon, Dec 29, 2025 at 10:04 AM Matti Vaittinen >> <mazziesaccount@gmail.com> wrote: >>> On 23/12/2025 20:26, David Lechner wrote: >>>> On 12/23/25 9:55 AM, Maxime Chevallier wrote: >> >> ... >> >>>> It looks like inputs can also be used as GPIOs, so >>>> >>>> gpio-controller: true >>>> #gpio-cells: >>>> const: 2 >>>> >>>> would be appropriate (it doesn't matter if the driver doesn't >>>> implement it, we know what the correct bindings are). >>>> >>>>> + >>>>> + "#io-channel-cells": >>>>> + const: 1 >>> >>> I didn't check the data-sheet, but if the pins can be set to be GPIOs or >>> ADC inputs, then I would require channels to be specified. It's only 8 >>> channels, so always listing channels that are present shouldn't be that >>> big of a problem - and it should avoid one to add extra properties to >>> denote channels used for GPIO if GPIOs need to be supported. >>> >>> Well, I am not insisting this, there are folks that know this stuff >>> better than I :) >> >> Why would we need an extra property for that? GPIO controller has a >> property for valid_mask, should be enough to handle this case, no? >> > Ah. You're right. The "valid_mask" should be perfectly usable. > > I might still require the channel information to make it explicit - but > as I said, I leave this for others to decide :) Thanks a lot for these suggestions, I'll add all of that in the next iteration :) Thanks everyone, Maxime
© 2016 - 2026 Red Hat, Inc.