Re: [PATCH] iio: adc: ti-ads7950: use spi_optimize_message()

[David Lechner]

On 4/14/26 11:31 AM, Andy Shevchenko wrote:
> On Tue, Apr 14, 2026 at 08:29:29AM -0500, David Lechner wrote:
>> On 4/14/26 4:54 AM, Andy Shevchenko wrote:
>>> On Sat, Apr 11, 2026 at 05:13:33PM -0500, David Lechner wrote:
>>>> Use spi_optimize_message() to reduce CPU usage during buffered reads.
>>>>
>>>> On hardware with support for SPI_CS_WORD, this reduced the CPU usage
>>>> of the threaded interrupt by about 5%. On hardware without support, this
>>>> should reduce CPU usage even more since it won't have to split the SPI
>>>> transfers each time the interrupt handler is called.
>>>>
>>>> The update_scan_mode callback hand to be moved to the buffer preenable
>>
>> s/hand/had/
>>
>>>> callback since the SPI transfer mode can't be changed after
>>>> spi_optimize_message() has been called. (The buffer postenable callback
>>>> can't be used because it happens after the trigger is enabled, so the
>>>> SPI message needs to be optimized before that.)
>>>>
>>>> The indent of ti_ads7950_read_raw is changed since there is no longer
>>>> anything else in the struct to align with since we removed
>>>> ti_ads7950_update_scan_mode.
>>>
>>> Some of the func() are mentioned w/o parentheses and I got lost which one is
>>> which. Also callbacks usually mentioned as .callback() (with a leading dot).
>>
>> I didn't put () in the last paragraph because I was talking about the function
>> pointer, not the function. I guess I missed update_scan_mode() though.
> 
> Then probably spell it as "pointer to func()" ?
> 
>>> The second paragraph doesn't tell me clearly if there is a behaviour change
>>> from user perspective.
>>
>> It is not clear that the difference the user can notice is that there are
>> some CPU cycles freed up for other tasks?
> 
> He-he :-)
> 
> I asked more about possible behaviour changes in ABI (note, that [significant]
> delays moved around might affect ABI if some user's program times out due to
> that). But I think it's not the case here.
> 

No, I don't expect any other changes either.