On Mon Aug 16, 2021 at 4:08 AM EDT, Andy Shevchenko wrote:

On Mon, Aug 16, 2021 at 12:35 AM Liam Beguin [off-list ref]
wrote:

quoted

While working on another series[1] I ran into issues where my SPI
controller would fail to handle 14-bit and 16-bit SPI messages. This
addresses that issue and adds support for selecting a different voltage
reference source from the devicetree.

v1 was base on a series[2] that seems to not have made it all the way,
and was tested on an ad7689.

v6 drops support for per channel vref selection.
After switching the voltage reference, readings take a little while to
stabilize, invalidating consecutive readings.

This could've been addressed by adding more dummy cycles at the expense
of speed, but discussing the issue with colleagues more involved in
hardware design, it turns out these circuits are usually designed with a
single vref in mind.

[1] https://patchwork.kernel.org/project/linux-iio/list/?series=511545
[2] https://patchwork.kernel.org/project/linux-iio/list/?series=116971&state=%2A&archive=both

Changes since v5:
- rename defines: s/AD7949_CFG_BIT_/AD7949_CFG_MASK_/g
- rename AD7949_MASK_TOTAL to match other defines

quoted

- make vref selection global instead of per channel, and update
  dt-bindings

Hi Andy,

Same as per v5: is it a hardware limitation?
It's unclear to me what happened here.

I tried to provide more details in the last paragraph above.

After switching the voltage reference, readings take a little while to
stabilize invalidating consecutive readings.

One option was to add more dummy cycles, but in addition to making
things slower it was brought to my attention that this kind of circuit
is usually designed with a single vref in mind.

For those reasons and because I didn't have an explicit need for it, I
decided to drop that part.

Liam

quoted

- reword commits 2/5, 3/5, and 4/5
- move bits_per_word configuration to struct spi_device, and switch to
  spi_{read,write}.

--
With Best Regards,
Andy Shevchenko