Re: FAILED: patch "[PATCH] iio: ad7949: fix channels mixups" failed to apply to 5.4-stable tree

[Sasha Levin <sashal@kernel.org>]

On Sun, Dec 15, 2019 at 10:31:14AM +0100, gregkh@linuxfoundation.org wrote:
>
>The patch below does not apply to the 5.4-stable tree.
>If someone wants it applied there, or to any other stable or longterm
>tree, then please email the backport, including the original git commit
>id to <stable@vger.kernel.org>.
>
>thanks,
>
>greg k-h
>
>------------------ original commit in Linus's tree ------------------
>
>From 3b71f6b59508b1c9befcb43de434866aafc76520 Mon Sep 17 00:00:00 2001
>From: Andrea Merello <andrea.merello@gmail.com>
>Date: Mon, 2 Dec 2019 15:13:36 +0100
>Subject: [PATCH] iio: ad7949: fix channels mixups
>
>Each time we need to read a sample (from the sysfs interface, since the
>driver supports only it) the driver writes the configuration register
>with the proper settings needed to perform the said read, then it runs
>another xfer to actually read the resulting value. Most notably the
>configuration register is updated to set the ADC internal MUX depending by
>which channel the read targets.
>
>Unfortunately this seems not enough to ensure correct operation because
>the ADC works in a pipelined-like fashion and the new configuration isn't
>applied in time.
>
>The ADC alternates two phases: acquisition and conversion. During the
>acquisition phase the ADC samples the analog signal in an internal
>capacitor; in the conversion phase the ADC performs the actual analog to
>digital conversion of the stored voltage. Note that of course the MUX
>needs to be set to the proper channel when the acquisition phase is
>performed.
>
>Once the conversion phase has been completed, the device automatically
>switches back to a new acquisition; on the other hand the device switches
>from acquisition to conversion on the rising edge of SPI cs signal (that
>is when the xfer finishes).
>
>Only after both two phases have been completed (with the proper settings
>already written in the configuration register since the beginning) it is
>possible to read the outcome from SPI bus.
>
>With the current driver implementation, we end up in the following
>situation:
>
>        _______  1st xfer ____________  2nd xfer ___________________
>SPI cs..       \_________/            \_________/
>SPI rd.. idle  |(val N-2)+    idle    | val N-1 +   idle ...
>SPI wr.. idle  |  cfg N  +    idle    |   (X)   +   idle ...
>------------------------ + -------------------- + ------------------
>  AD  ..   acq  N-1      + cnv N-1 |  acq N     +  cnv N  | acq N+1
>
>As shown in the diagram above, the value we read in the Nth read belongs
>to configuration setting N-1.
>
>In case the configuration is not changed (config[N] == config[N-1]), then
>we still get correct data, but in case the configuration changes (i.e.
>switching the MUX on another channel), we get wrong data (data from the
>previously selected channel).
>
>This patch fixes this by performing one more "dummy" transfer in order to
>ending up in reading the data when it's really ready, as per the following
>timing diagram.
>
>        _______  1st xfer ____________  2nd xfer ___________  3rd xfer ___
>SPI cs..       \_________/            \_________/           \_________/
>SPI rd.. idle  |(val N-2)+    idle    |(val N-1)+    idle   |  val N  + ..
>SPI wr.. idle  |  cfg N  +    idle    |   (X)   +    idle   |   (X)   + ..
>------------------------ + -------------------- + ------------------- + --
>  AD  ..   acq  N-1      + cnv N-1 |  acq N     +  cnv N  | acq N+1   | ..
>
>NOTE: in the latter case (cfg changes), the acquisition phase for the
>value to be read begins after the 1st xfer, that is after the read request
>has been issued on sysfs. On the other hand, if the cfg doesn't change,
>then we can refer to the fist diagram assuming N == (N - 1); the
>acquisition phase _begins_ before the 1st xfer (potentially a lot of time
>before the read has been issued via sysfs, but it _ends_ after the 1st
>xfer, that is _after_ the read has started. This should guarantee a
>reasonably fresh data, which value represents the voltage that the sampled
>signal has after the read start or maybe just around it.
>
>Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
>Reviewed-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com>
>Cc: <Stable@vger.kernel.org>
>Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

I took in the following as a depndency and queued for 5.4-4.19:

	c270bbf7bb9d ("iio: ad7949: kill pointless "readback"-handling code")

-- 
Thanks,
Sasha