• Andrea Merello's avatar
    iio: ad7949: fix channels mixups · 3b71f6b5
    Andrea Merello authored
    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: default avatarAndrea Merello <andrea.merello@gmail.com>
    Reviewed-by: default avatarCharles-Antoine Couret <charles-antoine.couret@essensium.com>
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
    3b71f6b5
ad7949.c 8.13 KB