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

[Jonathan Cameron]

On Tue, 14 Apr 2026 12:52:49 -0500
David Lechner <dlechner@xxxxxxxxxxxx> wrote:

> 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()" ?
I tweaked this a bit and applied.

J
> >   
> >>> 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.