Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil
Date: Tue Jun 09 2026 - 10:57:11 EST
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.
Best Regards,
Janani Sunil