Skip to content

iio: dac: add ad5706 (part 2) #3327

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
actorreno wants to merge 3 commits into
base: dev_ad5706r_1
Choose a base branch
from
+501 −7
Open

iio: dac: add ad5706 (part 2) #3327

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d8194f4
dt-bindings: iio: dac: ad5706r: add address attribute
actorreno May 25, 2026
24aa62e
iio: dac: ad5706r: add device attributes
actorreno May 19, 2026
103bf88
Documentation: ABI: testing: add ad5706r
actorreno May 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions Documentation/ABI/testing/sysfs-bus-iio-dac-ad5706r
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
What: /sys/bus/iio/devices/iio:deviceX/hw_ldac_tg_state

@rodrigo455 rodrigo455 May 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want others to comment on this too...

Maybe we could leverage channel hierarchy (where iio channels may have subchannels) here:
(This is something we are discussing upstream in the AD9910 patches)

  • current channel 10
    • label attr: phy1
    • en attr: powerdown control
    • raw attr: INPUT A (Async Load Mode - immediate DAC data update)
    • current channel 11 (child channel)
      • label attr: toggle1
      • en attr: enable toggle function
      • raw attr: INPUT B
      • sampling_frequency: toggling freq of the pwm
    • current channel 12 (child channel)
      • label attr: dither1
      • en attr: enable dither function
      • phase attr: $\phi_0$
      • frequency attr: $2\pi/N$ (controls a divider of the sample rate)
      • sampling_frequency attr: pwm frequency
      • raw attr: INPUT B
  • current channel 20
    • label attr: phy2
    • en attr: powerdown control
    • raw attr: INPUT A (Async Load Mode - immediate DAC data update)
    • current channel 21 (child channel)
      • label attr: toggle2
      • en attr: enable toggle function
      • raw attr: INPUT B
      • sampling_frequency: toggling freq of the pwm
    • current channel 22 (child channel)
      • label attr: dither2
      • en attr: enable dither function
      • phase attr: $\phi_0$
      • frequency attr: $2\pi/N$ (controls a divider of the sample rate)
      • sampling_frequency attr: pwm frequency
      • raw attr: INPUT B
        ...

I might be getting things wrong, so this is just a draft. when both enables for toggle and/or
dither are disabled, we may assume that LDAC load is the default. This is an idea to include the
support for toggle and dither modes.

I suppose LDAC control might not need to be exposed to the user... the signal could be ignored
for regular sysfs attr control (using Async mode). When using buffers we might want to have
the LDAC pin toggling in HW mode (or using SW mode when no pin is available). The LDAC handling
with buffers will allow to synchronize the update of multiple channels when they are enabled for
buffer transmission.
Manual toggling is preferred if we are sending the (multi-channel) data with triggered buffers.
If sending the data with DMA, offloading the spi, probably toggling control should be done in
hardware (in FPGA), not by a PWM, unless it is the sync source for the spi write cadence.

channel hierarchy is not upstream yet, but opens up for a lot of possibilities and ABI reuse.

@actorreno actorreno May 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok will wait for other comments, this feels like a relatively big(?) change if ever

KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Hardware LDAC trigger GPIO state. Controls the logical state of the LDAC trigger pin when using GPIO control. Valid values are:
- "low": LDAC pin driven low
- "high": LDAC pin driven high

Setting this on any value overrides the status of hw_ldac_tg_pwm.

Requires optional PWM device tree configuration for LDAC control.

What: /sys/bus/iio/devices/iio:deviceX/hw_ldac_tg_state_available
KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Returns the available LDAC GPIO states: "low high"

What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency
KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
PWM frequency in Hz for hardware LDAC triggering. Sets the period
of the PWM output used to trigger DAC updates. Valid range depends on PWM hardware capabilities. Default is 1 MHz.

Requires optional PWM device tree configuration.

What: /sys/bus/iio/devices/iio:deviceX/hw_ldac_tg_pwm
KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Enable or disable PWM output for hardware LDAC triggering. Valid
values are:
- "disable": PWM disabled (duty cycle = recent value of hw_ldac_tg_state)
- "enable": PWM enabled with 50% duty cycle

Requires optional PWM device tree configuration.

What: /sys/bus/iio/devices/iio:deviceX/hw_ldac_tg_pwm_available
KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Returns the available PWM states: "disable enable"

What: /sys/bus/iio/devices/iio:deviceX/multi_dac_input_a

@rodrigo455 rodrigo455 May 25, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How you are doing multi-DAC selection? I am not sure how this can be supported properly. I understand that Multi INPUT_A treats INPUT_A for all the selected channels as the same register.
Maybe a single multi_en attribute for each channel is enough... and you would treat the RAW attribute to write to this register 0x5C if that is selected, instead of the dedicated channel input A.

@actorreno actorreno May 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the selector is in the channel attributes which I reserved for part 3.
I suppose yeah... in part 2 this is unusable.

KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Multi-DAC Input A register value in a 16bit hexadecimal format.
When used with multi-DAC selection, this value is loaded into the
selected channels' input registers. Write operations update the
Multi-DAC Input A register (0x5C).

What: /sys/bus/iio/devices/iio:deviceX/multi_dac_sw_ldac_trigger

@rodrigo455 rodrigo455 May 25, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure why you need this. LDAC trigger seems to be a separate feature compared to the multi input one.

@actorreno actorreno May 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure what you mean by this
the software trigger for multidac and just ldac are on separate registers.
the sw_ldac is under channel attributes so it would be part of part 3 PR.

KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Software trigger for multi-DAC LDAC update. Writing "trigger" triggers a software LDAC pulse that simultaneously updates all selected DAC channels. This corresponds to writing to the Multi-DAC SW LDAC register (0x5A).

What: /sys/bus/iio/devices/iio:deviceX/multi_dac_sw_ldac_trigger_available
KernelVersion: 6.10
Contact: linux-iio@vger.kernel.org
Description:
Returns the available trigger option: "low trigger"
11 changes: 11 additions & 0 deletions Documentation/devicetree/bindings/iio/dac/adi,ad5706r.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,6 +49,17 @@ properties:
Optional external 2.5V voltage reference. If not provided, the
internal 2.5V reference is used.

adi,device-address:

@rodrigo455 rodrigo455 May 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again (#3325 (comment)), we might want comments from others, but device addressing is normally achieved with #address-cells in a parent and reg in child nodes. If you don't plan the feature for now, assume that it is 0 and don't even create this property. I understand that device-tree bindings is also to be treated as an ABI... so once it becomes available to users, the only thing you can do is to extend it. So you might want to get this right from the beginning. How would you get a second device to be supported with property? Isn't it locking the multiple-device feature?

@actorreno actorreno May 26, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that makes sense...this would lock it out
ok, i'll wait for other comments for the meantime

description: |
Hardware device address (0-3) configured via A[1:0] address pins.
This must match the physical pin configuration. Used in SPI frame
bits [13:12] to select the device. Required for accessing registers
beyond address 0x11. Defaults to 0 if not specified.
$ref: /schemas/types.yaml#/definitions/uint8
minimum: 0
maximum: 3
default: 0

pwms:
maxItems: 1
description:
Expand Down
Loading
Loading