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

[David Lechner <dlechner@baylibre.com>]

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.

> 
> [...]
> 
>>> +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.