On Fri, 4 Nov 2022 11:28:01 +0200 Antoniu Miclaus <antoniu.miclaus@xxxxxxxxxx> wrote: > Add documentation for the use of the output frequency and muxout select. > > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@xxxxxxxxxx> Hi Antoniu, A few questions inline. > --- > .../testing/sysfs-bus-iio-frequency-adf4377 | 32 +++++++++++++++++++ > 1 file changed, 32 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4377 > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4377 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4377 > new file mode 100644 > index 000000000000..0324de5c9328 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4377 > @@ -0,0 +1,32 @@ > +What: /sys/bus/iio/devices/iio:deviceX/frequency > +KernelVersion: > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + Stores the PLL frequency in Hz for output channels. > + Reading returns the frequency in Hz. I'm a little confused. Should we not tie this to the output channels? out_altvoltageX_frequency > + > +What: /sys/bus/iio/devices/iio:deviceX/muxout_select Why would userspace change this? I'd sort of expect this to typically be chosen by what it is physically wired up to. You could treat muxout_low and muxout_high as a gpio (possibly high_z as well). If that were the case, then device tree binding should allow you detect that usecase. Lock detector is normally wired to a GPI so that software can check if the lock is successful (or it's wired to some other circuits we can't see). The two clock dividers should be represented as a clock provider. Note this is partly driven by my desire to keep custom ABI to the minimum because it is rare that userspace has a clue what to do with it. That is probably less of a consideration here though as I doubt this device is going to be much used with software stacks that don't know exactly what it is. Jonathan > +KernelVersion: > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + The mux output allows the user to access various internal points on > + the chip. Valid values that can be written are: > + * high_z -> high impedance output > + * lock_detect -> digital lock detector output > + * muxout_low -> low output > + * f_div_rclk_2 -> fdiv_rclk/2 > + * f_div_nclk_2 -> fdiv_nclk/2 > + * muxout_high -> high output > + > +What: /sys/bus/iio/devices/iio:deviceX/muxout_select_available > +KernelVersion: > +Contact: linux-iio@xxxxxxxxxxxxxxx > +Description: > + Reading this returns the valid values that can be written to the > + muxout_mode attribute: > + * high_z > + * lock_detect > + * muxout_low > + * f_div_rclk_2 > + * f_div_nclk_2 > + * muxout_high
