Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R

[Janani Sunil <jan.sun97@gmail.com>]

On 6/14/26 21:44, Jonathan Cameron wrote:
> On Tue, 9 Jun 2026 16:47:23 +0200
> Janani Sunil <jan.sun97@gmail.com> wrote:
>
>> On 5/26/26 15:11, Rodrigo Alencar wrote:
>>> On 26/05/19 05:42PM, Janani Sunil wrote:
>>>> Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
>>>> buffered voltage output digital-to-analog converter (DAC) with an
>>>> integrated precision reference.
>>> ...
>>> Probably others may comment on that, but...
>>>
>>> This parent node may support device addressing for multi-device support through
>>> those ID pins. I suppose that each device may have its own power supplies or
>>> other resources like the toggle pins or reset and enable.
>>>
>>> That way I suppose that an example would look like...
>>>   
>>>> +
>>>> +patternProperties:
>>>> +  "^channel@([0-9]|1[0-5])$":
>>>> +    type: object
>>>> +    description: Child nodes for individual channel configuration
>>>> +
>>>> +    properties:
>>>> +      reg:
>>>> +        description: Channel number.
>>>> +        minimum: 0
>>>> +        maximum: 15
>>>> +
>>>> +      adi,output-range-microvolt:
>>>> +        description: |
>>>> +          Output voltage range for this channel as [min, max] in microvolts.
>>>> +          If not specified, defaults to 0V to 5V range.
>>>> +        oneOf:
>>>> +          - items:
>>>> +              - const: 0
>>>> +              - enum: [5000000, 10000000, 20000000, 40000000]
>>>> +          - items:
>>>> +              - const: -5000000
>>>> +              - const: 5000000
>>>> +          - items:
>>>> +              - const: -10000000
>>>> +              - const: 10000000
>>>> +          - items:
>>>> +              - const: -15000000
>>>> +              - const: 15000000
>>>> +          - items:
>>>> +              - const: -20000000
>>>> +              - const: 20000000
>>>> +
>>>> +    required:
>>>> +      - reg
>>>> +
>>>> +    additionalProperties: false
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +  - vdd-supply
>>>> +  - avdd-supply
>>>> +  - hvdd-supply
>>>> +
>>>> +dependencies:
>>>> +  spi-cpha: [ spi-cpol ]
>>>> +  spi-cpol: [ spi-cpha ]
>>>> +
>>>> +allOf:
>>>> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>> +
>>>> +    spi {
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        dac@0 {
>>>> +            compatible = "adi,ad5529r-16";
>>>> +            reg = <0>;
>>>> +            spi-max-frequency = <25000000>;
>>>> +
>>>> +            vdd-supply = <&vdd_regulator>;
>>>> +            avdd-supply = <&avdd_regulator>;
>>>> +            hvdd-supply = <&hvdd_regulator>;
>>>> +            hvss-supply = <&hvss_regulator>;
>>>> +
>>>> +            reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>> +
>>>> +            #address-cells = <1>;
>>>> +            #size-cells = <0>;
>>>> +
>>>> +            channel@0 {
>>>> +                reg = <0>;
>>>> +                adi,output-range-microvolt = <0 5000000>;
>>>> +            };
>>>> +
>>>> +            channel@1 {
>>>> +                reg = <1>;
>>>> +                adi,output-range-microvolt = <(-10000000) 10000000>;
>>>> +            };
>>>> +
>>>> +            channel@2 {
>>>> +                reg = <2>;
>>>> +                adi,output-range-microvolt = <0 40000000>;
>>>> +            };
>>>> +        };
>>>> +    };
>>> ...
>>>
>>> 	spi {
>>> 		#address-cells = <1>;
>>> 		#size-cells = <0>;
>>>
>>> 		multi-dac@0 {
>>> 			compatible = "adi,ad5529r-16";
>>> 			reg = <0>;
>>> 			spi-max-frequency = <25000000>;
>>>
>>> 			#address-cells = <1>;
>>> 			#size-cells = <0>;
>>>
>>> 			dac@0 {
>>> 				reg = <0>;
>>> 				vdd-supply = <&vdd_regulator>;
>>> 				avdd-supply = <&avdd_regulator>;
>>> 				hvdd-supply = <&hvdd_regulator>;
>>> 				hvss-supply = <&hvss_regulator>;
>>>
>>> 				reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
>>>
>>> 				#address-cells = <1>;
>>> 				#size-cells = <0>;
>>>
>>> 				channel@0 {
>>> 					reg = <0>;
>>> 					adi,output-range-microvolt = <0 5000000>;
>>> 				};
>>>
>>> 				channel@1 {
>>> 					reg = <1>;
>>> 					adi,output-range-microvolt = <(-10000000) 10000000>;
>>> 				};
>>>
>>> 				channel@2 {
>>> 					reg = <2>;
>>> 					adi,output-range-microvolt = <0 40000000>;
>>> 				};
>>> 			}
>>>
>>> 			dac@1 {
>>> 				reg = <1>;
>>> 				vdd-supply = <&vdd_regulator>;
>>> 				avdd-supply = <&avdd_regulator>;
>>> 				hvdd-supply = <&hvdd_regulator>;
>>> 				hvss-supply = <&hvss_regulator>;
>>>
>>> 				reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
>>>
>>> 				#address-cells = <1>;
>>> 				#size-cells = <0>;
>>>
>>> 				channel@0 {
>>> 					reg = <0>;
>>> 					adi,output-range-microvolt = <0 5000000>;
>>> 				};
>>>
>>> 				channel@1 {
>>> 					reg = <1>;
>>> 					adi,output-range-microvolt = <(-10000000) 10000000>;
>>> 				};
>>> 			}
>>> 		};
>>> 	};
>>>
>>> then you might need something like:
>>>
>>> 	patternProperties:
>>> 		"^dac@[0-3]$":
>>>
>>> and put most of the things under this node pattern.
>>>
>>> So the main driver that you're putting together might need to handle up to four instances.
>>> Even if your current driver cannot handle this, the dt-bindings might need cover that.
>>>
>>> Need to double check if each dac node needs a separate compatible, so you would maybe populate
>>> a platform data to be shared with the child nodes, which would be a separate driver.
>>> (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
>> Hi Rodrigo,
>>
>> Thank you for looking at this.
>>
>> For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
>> hardware/use case we have only needs one device node and the driver is written around that model as well.
>> While the device addressing pins could allow multi-device topology, we do not have an actual platform using
>> that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
>> speculatively without a validating use case.
> Interesting feature - kind of similar to address control on a typical i2c bus device, or
> looking at it another way a kind of distributed SPI mux.
>
> Challenge of a binding is we need to anticipate the future.  So I think we do need something
> like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> That would leave the path open to supporting the addressing at a later date.
> An alternative might be to look at it like a chained device setup. In those we pretend there
> is just one device with a lot of channels etc.  The snag is that here things are more loosely
> coupled whereas for those devices it tends to be you have to read / write the same register
> in all devices in the chain as one big SPI message.
>
> +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> - Each of these device has 2 ID pins.  The SPI transfers have to contain the 2 bit
> value that matches that or they are ignored.  Thus a single bus + 1 chip select can
> be used to talk to 4 devices.  Question is what that looks like in device tree + I guess
> longer term how to support it cleanly in SPI.
>
> Jonathan

Hi Jonathan, Rob, Krzysztof, Conor,

One possible model that would also allow mixing the 12-bit and 16-bit variants would be to treat the parent node
as the shared SPI transport only, and let each dac@N child carry its own compatible.

Rob, Krzysztof, Conor — wanted to get your input on whether this is an acceptable binding pattern.

properties:
   compatible:
     const: adi,ad5529r-bus

patternProperties:
   "^dac@[0-3]$":
     type: object
     properties:
       compatible:
         enum:
           - adi,ad5529r-16
           - adi,ad5529r-12
       reg:
         minimum: 0
         maximum: 3

With a DT example such as:

ad5529r@0 {
         compatible = "adi,ad5529r-bus";
         reg = <0>;

         dac@0 {
                 compatible = "adi,ad5529r-16";
                 reg = <0>;
         };

         dac@1 {
                 compatible = "adi,ad5529r-12";
                 reg = <1>;
         };
};

The downside is that it introduces adi,ad5529r-bus as a compatible that does not correspond to an actual
standalone device variant - it would require a parent driver to manage the shared SPI transport and enumerate the
child devices. The actual DAC functionality is handled by the matching per-child compatibles(12 or 16 bit).
Is this an acceptable pattern, or is there a preferred way to model this type of addressing scheme?

Regards,
Janani Sunil