| Message ID | cover.1712585500.git.marcelo.schmitt@analog.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for AD4000 series | expand |
On Mon, Apr 8, 2024 at 9:31 AM Marcelo Schmitt <marcelo.schmitt@analog.com> wrote: > > This is more like an RFC patch set since configuration read/write is currently > buggy. > > Change log v1 -> v2: > - Took device tree provided by David. > - Dropped ABI additions in favor of device tree properties. > - Set differential IIO channel subtype for differential ADCs. > - Set scan_type shift bits to mask out correct real bits from buffer. > - Added __aligned(8) to buffer timestamp. > - Used union to reduce buffer memory usage for 16-bit devices. > - Used SPI transfer functions rather than SPI message. > - Used c99 style structure initialization. > - Used iio_device_claim_direct_scoped(). > - Removed unneeded pointer casts. > - Added other power supplies (VDD and VIO). > > Link to v1: https://lore.kernel.org/linux-iio/cover.1711131830.git.marcelo.schmitt@analog.com/ > > Additional topics: > > - Why there is no different handling for the different SPI wiring modes? > It looks like there is no need for different handling of "4-wire" and "3-wire" > modes. > If in "4-wire" (dt default mode), SDI is connected to SPI controller CS and > CNV is active high. We can activate the CNV GPIO then let the SPI controller > bring CS (connected to SDI) down when starting the transfer. > If in "3-wire" (dt single mode), if we have a CNV (active low) GPIO we activate > it and then proceed with with the transfer. If controller CS is connected to > CNV it works the same way. > I'm thinking it's better if we can support these devices in similar way > other SPI ADCs are supported. Does that make sense? In the AD7944 driver, I handled the "3-wire" mode separately because the sample conversion is triggered on the rising edge of the CNV line. In "4-wire" mode, since we have a GPIO connected to CNV, we can just toggle the GPIO from low to high, wait for the conversion time (t_CONV) and then read the sample (SPI xfer) then toggle the CNV line low again. In 3-wire mode, the CS line is connected to the CNV pin, so in order to get an up-to-date sample, we need to to toggle the CS line from low to high to trigger a conversion (spi xfer with no data, only delay), then wait for the conversion time, then read the sample (2nd spi xfer). So in "4-wire" mode, the CS line is getting toggled once per sample, but in "3-wire" mode, it is getting toggled twice per sample. I didn't add support for "3-wire" mode where CNV is connected to GPIO because we can't get max sample rate that way and it is unusual to not have CS connected to something. But if we do that here, the timing has to be different from 4-wire mode in order to not get stale data. > To me, the "3-wire" mode with controller CS to ADC CNV is what most resembles > conventional SPI. The only important distinction is that the > controller must be able to keep ADC SDI line high during conversions. > Although, while the spi-engine implementation provided to me can keep SDI up > during conversions, I'm not sure its a thing all SPI controllers can do. > I tried a raspberry pi 4 some time ago and it was leaving the SDI line low if > no tx buffer was provided. Even with a tx full of 1s the controller would > bring SDI down between each 8 bits of transfer. This is a good point. It sounds like additional bindings are needed to describe the various wiring cases of the SDI line. It sounds like possibilities are: 1. SDI is hard-wired high -> can't write to registers, CNV is connected to SPI controller CS, chip is in "3-wire" mode. Currently adi,spi-mode="single" 2. SDI is connected to SDO of another chip, SDI of last chip is hard-wired low -> can't write to registers, CNV is connected to SPI controller CS, chips are in daisy chain mode. Currently adi,spi-mode="chain" 3. SDI is connected to SPI controller CS -> can't write registers, chip can operate in 4-wire mode with CNV connected to GPIO, Currently adi,spi-mode omitted. 4. SDI is connected to SPI controller SDO -> can write registers, and support all writing modes (3-wire, 4-wire, daisy chain) as long as SPI controller SDO line can be kept high or low at the appropriate time. Currently not handled. 5. There could be a pin mux that switches between the one of the first three and the 4th option (needed to avoid the issue with SPI controller not being able to place the SDI pin in the correct state during conversion trigger as described above). On AD7944, the proposed adi,spi-mode property was sufficient to describe what was wired to the SDI pin because we only had the first 3 options (the AD7944 doesn't have SPI registers to write to). Also see related comments in my reply to the DT bindings patch. (From the complete bindings point of view, we should probably also consider the possibility of variations of 1. and 2. where CS of the SPI controller is not wired and CNV is connected to a GPIO - this can be determined by the combination of the adi,spi-mode property and the presence or absence of the cnv-gpios property.) > Anyway, single-shot and buffered reads work with the spi-engine controller > with ADC in "3-wire"/single mode with controller CS line connected to ADC CNV > pin which is how I've been testing it. Technically, yes data can be captured in "3-wire" mode with a single CS toggle, but then the data is stale and doesn't correspond to the soft timestamp because it is reading the data from the previous conversion triggered by the last SPI xfer, whenever that was. Since it is trivial to avoid this by adding the extra CS/CNV toggle I describe above, I don't see any reason not to. But the way the driver is written now, it is actually only supporting the unnamed wiring option 4 from above, so now I understand the confusion about 3-wire vs. 4-wire mode in that context. > > - Why did not make vref regulator optional? > Other SAR ADCs I've seen needed a voltage reference otherwise they simply > could not provide any reasonable readings. Isn't it preferable to fail rather > than having a device that can't provide reliable data? In the device tree bindings, making vref-supply required makes sense since there is no internal reference. In the driver, as discussed in V1, it will fail if vref-supply in regulator_get_voltage() if vref-supply is missing and we use devm_regulator_get() instead of devm_regulator_get_optional(). So leaving it as-is is fine. We have a plan to clean this up later anyway. > > - Why did not split into AD and ADAQ patches? > The main difference between AD and ADAQ is the amplifier in front of the ADC. > If only supporting AD, we could probably avoid the scale table since it would > only have two possible values per ADC. But then the handling of span compression > scale would need refactoring to be in the scale table when adding ADAQ. > I'm not excited to implement something knowing it will need rework in the > following patch. Will do if required. If it isn't that much work, it seems worth it to me. If the driver work is too much, maybe just split the DT patch? > > - Span compression and offset. > For non-differential ADCs, enabling the span compression requires an input offset. > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD4000-4004-4008.pdf > page 18 > and > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4002-4006-4010.pdf > page 19 > I updated the _offset attribute for those ADCs according to span compression > being enabled or not. Is it okay to have an attribute update cause an update to > another one? > Maybe also make the span compression a dt property and have it fixed after probe? This doesn't sound like something that belongs in DT since it doesn't depend on the physical properties of what is wired to the input. But the fact that offset should not be read until after scale is set sounds like a quirk that would be worth documenting in some chip-specific docs. > > - Configuration register > Despite it doing single-shot and buffered captures, read and writes to the > configuration register are currently buggy. It is as if the register was > "floating". I tried setting up buffers like ad7768-1, adxl355_core, bma220_spi, > bma400_core, and mcp3911. If the ADC CNV pin is connected to a GPIO and the ADC SDI pin is connected to SDO of the SPI controller, then nothing is connected to CS of the SPI controller, so that might be the problem. > > > Thanks, > Marcelo > > Marcelo Schmitt (2): > dt-bindings: iio: adc: Add AD4000 > iio: adc: Add support for AD4000 > > .../bindings/iio/adc/adi,ad4000.yaml | 201 ++++++ > MAINTAINERS | 8 + > drivers/iio/adc/Kconfig | 12 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/ad4000.c | 649 ++++++++++++++++++ > 5 files changed, 871 insertions(+) > create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml > create mode 100644 drivers/iio/adc/ad4000.c > > -- > 2.43.0 > >
On 04/08, David Lechner wrote: > On Mon, Apr 8, 2024 at 9:31 AM Marcelo Schmitt > <marcelo.schmitt@analog.com> wrote: > > > > This is more like an RFC patch set since configuration read/write is currently > > buggy. > > > > Change log v1 -> v2: > > - Took device tree provided by David. > > - Dropped ABI additions in favor of device tree properties. > > - Set differential IIO channel subtype for differential ADCs. > > - Set scan_type shift bits to mask out correct real bits from buffer. > > - Added __aligned(8) to buffer timestamp. > > - Used union to reduce buffer memory usage for 16-bit devices. > > - Used SPI transfer functions rather than SPI message. > > - Used c99 style structure initialization. > > - Used iio_device_claim_direct_scoped(). > > - Removed unneeded pointer casts. > > - Added other power supplies (VDD and VIO). > > > > Link to v1: https://lore.kernel.org/linux-iio/cover.1711131830.git.marcelo.schmitt@analog.com/ > > > > Additional topics: > > > > - Why there is no different handling for the different SPI wiring modes? > > It looks like there is no need for different handling of "4-wire" and "3-wire" > > modes. > > If in "4-wire" (dt default mode), SDI is connected to SPI controller CS and > > CNV is active high. We can activate the CNV GPIO then let the SPI controller > > bring CS (connected to SDI) down when starting the transfer. > > If in "3-wire" (dt single mode), if we have a CNV (active low) GPIO we activate > > it and then proceed with with the transfer. If controller CS is connected to > > CNV it works the same way. > > I'm thinking it's better if we can support these devices in similar way > > other SPI ADCs are supported. Does that make sense? > > In the AD7944 driver, I handled the "3-wire" mode separately because > the sample conversion is triggered on the rising edge of the CNV line. > In "4-wire" mode, since we have a GPIO connected to CNV, we can just > toggle the GPIO from low to high, wait for the conversion time > (t_CONV) and then read the sample (SPI xfer) then toggle the CNV line > low again. In 3-wire mode, the CS line is connected to the CNV pin, so > in order to get an up-to-date sample, we need to to toggle the CS line > from low to high to trigger a conversion (spi xfer with no data, only > delay), then wait for the conversion time, then read the sample (2nd > spi xfer). So in "4-wire" mode, the CS line is getting toggled once > per sample, but in "3-wire" mode, it is getting toggled twice per > sample. I didn't add support for "3-wire" mode where CNV is connected > to GPIO because we can't get max sample rate that way and it is > unusual to not have CS connected to something. But if we do that here, > the timing has to be different from 4-wire mode in order to not get > stale data. Yes, that's also the case for ad4000 series. The rising edge of CNV triggers the conversion which causes a latency/delay of one read if CNV is connected to a chip select. I thought it was okay to just accept the latency since it's intrinsic to the ADC start conversion on CNV rising edge and latency would be less noticeable when doing continuous sampling. Although, this indeed causes the timestamps to be disarranged, which is making me rethink the implementation. Yet, if we choose to have extra pulse of CNV for the sake of getting correct timesamps, that might also impact performance for high sample rates (unless split sample handling into different cases for single-shot and buffered readings). I'll give it try and do it like ad7944. > > > To me, the "3-wire" mode with controller CS to ADC CNV is what most resembles > > conventional SPI. The only important distinction is that the > > controller must be able to keep ADC SDI line high during conversions. > > Although, while the spi-engine implementation provided to me can keep SDI up > > during conversions, I'm not sure its a thing all SPI controllers can do. > > I tried a raspberry pi 4 some time ago and it was leaving the SDI line low if > > no tx buffer was provided. Even with a tx full of 1s the controller would > > bring SDI down between each 8 bits of transfer. > > This is a good point. It sounds like additional bindings are needed to > describe the various wiring cases of the SDI line. > > It sounds like possibilities are: > > 1. SDI is hard-wired high -> can't write to registers, CNV is > connected to SPI controller CS, chip is in "3-wire" mode. Currently > adi,spi-mode="single" > 2. SDI is connected to SDO of another chip, SDI of last chip is > hard-wired low -> can't write to registers, CNV is connected to SPI > controller CS, chips are in daisy chain mode. Currently > adi,spi-mode="chain" > 3. SDI is connected to SPI controller CS -> can't write registers, > chip can operate in 4-wire mode with CNV connected to GPIO, Currently > adi,spi-mode omitted. > 4. SDI is connected to SPI controller SDO -> can write registers, and > support all writing modes (3-wire, 4-wire, daisy chain) as long as SPI > controller SDO line can be kept high or low at the appropriate time. > Currently not handled. > 5. There could be a pin mux that switches between the one of the first > three and the 4th option (needed to avoid the issue with SPI > controller not being able to place the SDI pin in the correct state > during conversion trigger as described above). > > On AD7944, the proposed adi,spi-mode property was sufficient to > describe what was wired to the SDI pin because we only had the first 3 > options (the AD7944 doesn't have SPI registers to write to). > > Also see related comments in my reply to the DT bindings patch. > > (From the complete bindings point of view, we should probably also > consider the possibility of variations of 1. and 2. where CS of the > SPI controller is not wired and CNV is connected to a GPIO - this can > be determined by the combination of the adi,spi-mode property and the > presence or absence of the cnv-gpios property.) This sounds reasonable to me. I also think the comments on DT patch are good. Will comment there too. > > > Anyway, single-shot and buffered reads work with the spi-engine controller > > with ADC in "3-wire"/single mode with controller CS line connected to ADC CNV > > pin which is how I've been testing it. > > Technically, yes data can be captured in "3-wire" mode with a single > CS toggle, but then the data is stale and doesn't correspond to the > soft timestamp because it is reading the data from the previous > conversion triggered by the last SPI xfer, whenever that was. Since it > is trivial to avoid this by adding the extra CS/CNV toggle I describe > above, I don't see any reason not to. Okay, will make it do the extra pulse to CNV for "3-wire" mode. > > But the way the driver is written now, it is actually only supporting > the unnamed wiring option 4 from above, so now I understand the > confusion about 3-wire vs. 4-wire mode in that context. > > > > > - Why did not make vref regulator optional? > > Other SAR ADCs I've seen needed a voltage reference otherwise they simply > > could not provide any reasonable readings. Isn't it preferable to fail rather > > than having a device that can't provide reliable data? > > In the device tree bindings, making vref-supply required makes sense > since there is no internal reference. In the driver, as discussed in > V1, it will fail if vref-supply in regulator_get_voltage() if > vref-supply is missing and we use devm_regulator_get() instead of > devm_regulator_get_optional(). So leaving it as-is is fine. We have a > plan to clean this up later anyway. > Not sure I understand the idea here. Should the driver use devm_regulator_get_optional() instead of devm_regulator_get() because the optional call would fail immediately if no vref-supply while the regular call would only fail at regulator_get_voltage()? Why? This looks very counter intuitive to me. > > > > - Why did not split into AD and ADAQ patches? > > The main difference between AD and ADAQ is the amplifier in front of the ADC. > > If only supporting AD, we could probably avoid the scale table since it would > > only have two possible values per ADC. But then the handling of span compression > > scale would need refactoring to be in the scale table when adding ADAQ. > > I'm not excited to implement something knowing it will need rework in the > > following patch. Will do if required. > > If it isn't that much work, it seems worth it to me. If the driver > work is too much, maybe just split the DT patch? > > > > > - Span compression and offset. > > For non-differential ADCs, enabling the span compression requires an input offset. > > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD4000-4004-4008.pdf > > page 18 > > and > > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4002-4006-4010.pdf > > page 19 > > I updated the _offset attribute for those ADCs according to span compression > > being enabled or not. Is it okay to have an attribute update cause an update to > > another one? > > Maybe also make the span compression a dt property and have it fixed after probe? > > This doesn't sound like something that belongs in DT since it doesn't > depend on the physical properties of what is wired to the input. > > But the fact that offset should not be read until after scale is set > sounds like a quirk that would be worth documenting in some > chip-specific docs. > > > > > - Configuration register > > Despite it doing single-shot and buffered captures, read and writes to the > > configuration register are currently buggy. It is as if the register was > > "floating". I tried setting up buffers like ad7768-1, adxl355_core, bma220_spi, > > bma400_core, and mcp3911. > > If the ADC CNV pin is connected to a GPIO and the ADC SDI pin is > connected to SDO of the SPI controller, then nothing is connected to > CS of the SPI controller, so that might be the problem. ADC CNV is connected to controller CS and ADC SDI to controller SDO. Think it's something to do with buffer alignment. Will try the changes suggested in reply to driver patch. > > > > > > > Thanks, > > Marcelo > > > > Marcelo Schmitt (2): > > dt-bindings: iio: adc: Add AD4000 > > iio: adc: Add support for AD4000 > > > > .../bindings/iio/adc/adi,ad4000.yaml | 201 ++++++ > > MAINTAINERS | 8 + > > drivers/iio/adc/Kconfig | 12 + > > drivers/iio/adc/Makefile | 1 + > > drivers/iio/adc/ad4000.c | 649 ++++++++++++++++++ > > 5 files changed, 871 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad4000.yaml > > create mode 100644 drivers/iio/adc/ad4000.c > > > > -- > > 2.43.0 > > > >
On Tue, Apr 9, 2024 at 9:59 AM Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote: > > On 04/08, David Lechner wrote: > > On Mon, Apr 8, 2024 at 9:31 AM Marcelo Schmitt > > <marcelo.schmitt@analog.com> wrote: > > > ... > > > > > > - Why did not make vref regulator optional? > > > Other SAR ADCs I've seen needed a voltage reference otherwise they simply > > > could not provide any reasonable readings. Isn't it preferable to fail rather > > > than having a device that can't provide reliable data? > > > > In the device tree bindings, making vref-supply required makes sense > > since there is no internal reference. In the driver, as discussed in > > V1, it will fail if vref-supply in regulator_get_voltage() if > > vref-supply is missing and we use devm_regulator_get() instead of > > devm_regulator_get_optional(). So leaving it as-is is fine. We have a > > plan to clean this up later anyway. > > > > Not sure I understand the idea here. Should the driver use > devm_regulator_get_optional() instead of devm_regulator_get() because > the optional call would fail immediately if no vref-supply while the regular > call would only fail at regulator_get_voltage()? Why? This looks very counter > intuitive to me. Right. I'm saying just leave it the way it is for now. (I have a plan to simplify it later, but still working on that.)
> > > > - Span compression and offset. > > For non-differential ADCs, enabling the span compression requires an input offset. > > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD4000-4004-4008.pdf > > page 18 > > and > > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad4002-4006-4010.pdf > > page 19 > > I updated the _offset attribute for those ADCs according to span compression > > being enabled or not. Is it okay to have an attribute update cause an update to > > another one? Yes. Happens all the time and it's not possible in general to define an ABI where this doesn't happen on some combinations. scale in particular can be affected in lots of fun non linear ways by other attributes. How you handle it is a bit up to the driver writer and interpretation of what is most natural for a given combination. Sometimes: a) Stash previously set value of the other attributes and try to find a new value as near as possible give constraint of whatever else was just written b) Just use whatever the register value now corresponds to given the other attribute changed Either way userspace needs to take another look at other attributes to see if they changed after changing anything that might have an influence. It can then update them however it likes. > > Maybe also make the span compression a dt property and have it fixed after probe? > > This doesn't sound like something that belongs in DT since it doesn't > depend on the physical properties of what is wired to the input. > > But the fact that offset should not be read until after scale is set > sounds like a quirk that would be worth documenting in some > chip-specific docs. Agreed - it is useful to hint at this but in general software has to check everything as there are lots of these sorts of interactions :( Jonathan