iio: adc: ad7380: fix SPI offload trigger rate

[dlech]

This is backporting a fix that was just accepted upstream.

PR Description

Add a special case to double the SPI offload trigger rate when all channels of a single-ended chip are enabled in a buffered read.

The single-ended chips in the AD738x family can only do simultaneous sampling of half their channels and have a multiplexer to allow reading the other half. To comply with the IIO definition of sampling_frequency, we need to trigger twice as often when the sequencer is enabled to so that both banks can be read in a single sample period.

Fixes: bbeaec8 ("iio: ad7380: add support for SPI offload")

Cc: Stable@vger.kernel.org

(cherry picked from commit 6327573)

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly (if there is the case)

[machschmitt]

I think the rationale for this patch is correct.
Though, shouldn't we also call spi_offload_trigger_validate() to allow the underlying trigger source to be adjusted (e.g. PWM period update)?
I see this has been accepted for the upstream kernel so, even if the fix needs a fix, I see no reason to diverge from IIO tree in this case.

[dlech]

That is a thoughtful question to ask. 😄

I considered that, but in this function, we call spi_offload_trigger_enable() almost immediately after modifying the value and it should fail just the same. So I didn't see any benefit to the extra validation call in this case. The validate function is mostly useful when we can call it in a different code path to get an early failure.

Calling spi_offload_trigger_validate() doesn't change any state. It only asks, if we did enable right now, what would the result be without actually doing anything.

[machschmitt]

I considered that, but in this function, we call spi_offload_trigger_enable() almost immediately after modifying the value and it should fail just the same. So I didn't see any benefit to the extra validation call in this case. The validate function is mostly useful when we can call it in a different code path to get an early failure.

Ah, makes sense.

Calling spi_offload_trigger_validate() doesn't change any state. It only asks, if we did enable right now, what would the result be without actually doing anything.

Yeah, it will apply the PWM waveform anyway on spi_offload_trigger_enable(). Okay, I see your point. Thanks for clarifying that out.