> > +.. list-table:: Driver attributes > > + :header-rows: 1 > > + > > + * - Attribute > > + - Description > > + * - ``in_voltage0_raw`` > > + - Raw ADC voltage value > > + * - ``in_voltage0_oversampling_ratio`` > > + - Enable the device's burst averaging mode to over sample using > > + the internal sample rate. > > + * - ``in_voltage0_oversampling_ratio_available`` > > + - List of available oversampling values. Value 0 disable the burst > > + averaging mode. > > + * - ``sample_rate`` > > + - Device internal sample rate used in the burst averaging mode. > > + * - ``sample_rate_available`` > > + - List of available sample rates. > > Why not using the standard sampling_frequency[_available] attributes? Because sampling_frequency is the sampling frequency for the pwm trigger during buffer readings. sample_rate is the internal device clock used during monitor and burst averaging modes. > > + > > +Threshold events > > +================ > > + > > +The ADC supports a monitoring mode to raise threshold events. > > +The driver supports a single interrupt for both rising and falling > > +readings. > > + > > +During monitor mode, the device is busy since other transactions > > +require to put the device in configuration mode first. > > This isn't so clear to me. Is this saying that events do not work > while doing a buffered read? Do you need to do need to read the > in_voltage0_raw input to trigger an event? > No, the device monitor mode and trigger mode autonomously samples using the internal clock set with the sample rate property. I rephrased that to: The feature is enabled/disabled by setting ``thresh_either_en``. During monitor mode, the device continuously operate in autonomous mode until put back in configuration mode, due to this, the device returns busy until the feature is disabled. The reasoning is that during configuration mode no ADC conversion is done, including if the previous mode was autonomous. If instead of return busy the driver hided this and resumed monitor mode after the access, a hidden (to the user) monitoring down-time would and thresholds crossings could be lost, undermining the feature. > > +SPI offload support > > +=================== > > + > > +To be able to achieve the maximum sample rate, the driver can be used with the > > +`AXI SPI Engine`_ to provide SPI offload support. > > + > > +.. _AXI SPI Engine: http://analogdevicesinc.github.io/hdl/projects/ad4052_ardz/index.html > > This diagram show a PWM connected to the CNV pin on the ADC, but I > didn't see a pwms property in the DT bindings to describe this. > It is not clear to me where the pwm property should be in the DT bindings, since the PWM node now belongs to the offload-capable SPI controller. > I didn't have time to read the full datasheet or look at the driver > code yet, but can do that next week. Ok, thank you for the review Jorge
