Re: [PATCH v3 2/9] iio: adc: add the ti-ads1262 driver

On Mon Aug 10, 2026 at 11:42 AM -05, David Lechner wrote:
> On 8/9/26 3:26 AM, Kurt Borja wrote:
>> On Sat Aug 8, 2026 at 1:39 PM -05, David Lechner wrote:
>>> On 8/7/26 10:58 PM, Kurt Borja wrote:
>>>> Add the ti-ads1262 driver with initial support for the primary ADC
>>>> (ADC1). The ADS1263 auxiliary ADC (ADC2) is handled by a separate driver
>>>> and interoperability considerations were taken into account.
>>>
>
> ...
>
>>>> +static int ads1262_dev_reset(struct ads1262 *st)
>>>> +{
>>>> +	int ret;
>>>> +
>>>> +	if (st->reset_gpiod) {
>>>> +		ret = gpiod_set_value_cansleep(st->reset_gpiod, 1);
>>>> +		if (ret)
>>>> +			return ret;
>>>> +
>>>> +		/*
>>>> +		 * The RESET pulse timing requirement is 4 clock cycles, at the
>>>> +		 * minimum clock rate this is 4 microseconds.
>>>> +		 */
>>>> +		fsleep(4);
>>>
>>> How long do we have to hold reset before the chip powers down?
>> 
>> For power down 65536 clk cycles. Less than that is simple reset.
>
> How long is 65536 clk cycles in microseconds at the fasted clock rate?
> Hopefully won't accidentally shut down the chip here even if fsleep()
> goes significantly longer than requested.

That would be 8192 microseconds. Do you think there is a risk we end up
turning off the device?

>
>> 
>> [...]
>> 
>>>> +static int ads1262_wait_for_conversion(struct ads1262 *st)
>>>> +{
>>>> +	u64 max_lat_ms;
>>>> +	long ret;
>>>> +
>>>> +	/*
>>>> +	 * The first conversion latency is affected by the channel's data rate,
>>>> +	 * filter, the configurable conversion delay and whether chop mode
>>>> +	 * and/or IDAC rotation mode are enabled.
>>>> +	 *
>>>> +	 * The worst possible latency is calculated by taking the lowest data
>>>> +	 * rate (2.5 SPS) and the sinc4 filter. This gives a latency of 1600 ms
>>>> +	 * (Table 9-13). Then we scale it by the actual clock rate and multiply
>>>> +	 * by 4 to account for chop and IDAC rotation modes (Equation 20).
>>>> +	 */
>>>> +	max_lat_ms = 4 * div_u64(mul_u32_u32(1600, 7372800), st->clk_rate);
>>>
>>> These are constant values, so don't need mul_u32_u32(). Also, given the wide
>>> range of possible sampling rates, I would include the current sampling rate
>>> in the calculation. No need to wate 1.6 seconds for something that should
>>> take a few 10s of microseconds.
>> 
>> Can we leave it like this until I implement the settlingtime? That way I
>> can calculate the actual first conversion latency.
>> 
> Sure. Just maybe mention it below the --- in the comment message on the
> next revision to remind us.

Sure!

-- 
Thanks,
 ~ Kurt