The ABI defined for this driver has some subtleties that were previously discussed in this RFC [1]. This might not be the final state but, hopefully, we are close to it: toggle mode channels: * out_voltageY_toggle_en * out_voltageY_raw1 * out_voltageY_symbol dither mode channels: * out_voltageY_dither_en * out_voltageY_dither_raw * out_voltageY_dither_raw_available * out_voltageY_dither_frequency * out_voltageY_dither_frequency_available * out_voltageY_dither_phase * out_voltageY_dither_phase_available Default channels won't have any of the above ABIs. A channel is toggle capable if the devicetree 'adi,toggle-mode' flag is set. For dither, the assumption is more silent. If 'adi,toggle-mode' is not given and a channel is associated with a TGPx pin through 'adi,toggle-dither-input', then the channel is assumed to be dither capable (there's no point in having a dither capable channel without an input clock). There are some stuff where I'm still not 100% convinced though: 1. out_voltageY_dither_raw refers to the dither amplitude. There are some differences but in essence, the same scale as the raw attr applies. That is not true for the offset as it's always 0. This is stated in the ABI file and being an amplitude is more or less obvious. However, I'm not sure if it's still valuable to have an ut_voltageY_dither_offset? 2. For now, if 'adi,toggle-dither-input' is given, a correspondent clock as to be given as well. While this makes sense for dither channels, I'm not so sure for toggle ones. I can easily see a toggled channel being controlled by, for example, an host GPIO. 3. Dither capable channels are being silently "assumed" by the driver. Not sure if an "adi,mode" dt property would make sense. Having this explicitly could make it easier to express some dependencies in the bindings file. 4. For now the clocks property is not part of the channels object. The reason for this is that we only have 3 possible clocks for 16 channels so I wanted to avoid getting and enabling the same clock more than once. But that is not really an issue and together with 3) it could, again, make it easier to express some dependencies in the bindings file. That said, I'm pending in doing this property a channel one (as it truly is) unless I get feedback otherwise. [1]: https://marc.info/?l=linux-iio&m=163662843603265&w=2 Nuno Sá (3): iio: dac: add support for ltc2688 iio: ABI: add ABI file for the LTC2688 DAC dt-bindings: iio: Add ltc2688 documentation .../ABI/testing/sysfs-bus-iio-dac-ltc2688 | 67 + .../bindings/iio/dac/adi,ltc2688.yaml | 146 +++ MAINTAINERS | 9 + drivers/iio/dac/Kconfig | 11 + drivers/iio/dac/Makefile | 1 + drivers/iio/dac/ltc2688.c | 1081 +++++++++++++++++ 6 files changed, 1315 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml create mode 100644 drivers/iio/dac/ltc2688.c -- 2.17.1
