AD7904 returns "Input/Output Error" for all connected voltage lines (Using AD7923 Driver)

mhennerich Your author of the driver. Has this been tested for all 4 models?

I'm running out of ideas besides the driver just crapping out. I probed all the lines and they work! I see data coming to and from the part and the cs going low. However, the driver will always EIO, which only seems to appear if the address pins are wrong but how can that be?

Reading scale returns error since the regulator issn't connected.

Can you check if you kernel is CONFIG_REGULATOR_FIXED_VOLTAGE enabled?

Regarding -EIO on raw reads, this can only be related to read the data via SPI.

Can you add this debug print and read all channels:

pr_err("%s:%d: ret = 0x%X", __func__, __LINE__, ret;)

if (chan->address == EXTRACT(ret, 12, 4))
    *val = EXTRACT(ret, 0, 12);
else
    return -EIO;

-Michael

Ah, probably because I declared inside the spi {} instead of outside of it..

So vcc-supply is listed as a requirement, however we currently use a AD dac (ad5676) that doesn't include a vcc-supply parameter and it operates fine. So are these parameters actually necessary?

mhennerich  I finally got my printk's working and the return is always 0. That explains why in_voltage0_raw always works fine but none of the others.

Probing the spi lines like I said all look good. Suggestions? Would not having a regulator referenced affect it?

Here is the diff from the git patch.

@@ -274,8 +274,12 @@ static int ad7923_read_raw(struct iio_dev *indio_dev,
                if (chan->address == EXTRACT(ret, 12, 4))
                        *val = EXTRACT(ret, 0, 12);
                else
+               {
+                       printk(KERN_ALERT "chan->address= %ld\n", chan->address);
+                       printk(KERN_ALERT "read ret=%d\n",EXTRACT(ret, 12, 4));
+                       printk(KERN_ALERT "address pins don't match read value.\n");
                        return -EIO;
-
+               }
                return IIO_VAL_INT;
        case IIO_CHAN_INFO_SCALE:
                ret = ad7923_get_range(st);
@@ -334,12 +338,16 @@ static int ad7923_probe(struct spi_device *spi)
 
        st->reg = devm_regulator_get(&spi->dev, "refin");
        if (IS_ERR(st->reg))
+       {
+               printk(KERN_ALERT "refin ptr_err!");
                return PTR_ERR(st->reg);
-
+       }
        ret = regulator_enable(st->reg);
        if (ret)
+       {
+               printk(KERN_ALERT "regulator enable error");
                return ret;
-
+       }
        ret = iio_triggered_buffer_setup(indio_dev, NULL,
                                         &ad7923_trigger_handler, NULL);
        if (ret)
-- 
2.28.0

Here you're printing the raw samples returned from spi_sync(), so the regulator should matter here.

When looking at the SPI signals you're seeing none zero samples on MISO?

With the channel ID, and likely some LSB flickering?

Can you try changing the SPI modes using spi-cpha, spi-cpol?

Please see here:

elixir.bootlin.com/.../spi-bus.txt

-Michael

This is an image of the MISO line when calling a cat in_voltage2_raw. First one looks right, but not sure why I'm getting two blocks of 16clock cycles. Shouldn't it just be 1?

I got the regulator hooked up correctly I believe. Vref is 2.5v. voltage_scale now populates, however raws still throw error.

root@pif:~# cat /sys/bus/iio/devices/iio\:device2/in_voltage0_raw
0
root@pif:~# cat /sys/bus/iio/devices/iio\:device2/in_voltage_scale
9.765625000
root@pif:~# cat /sys/bus/iio/devices/iio\:device2/in_voltage_scale
9.765625000
root@pif:~# cat /sys/bus/iio/devices/iio\:device2/in_voltage1_raw
cat: '/sys/bus/iio/devices/iio:device2/in_voltage1_raw': Input/output error

I'll go ahead and try changing those spi modes and report back.

ViaRiker said:

First one looks right, but not sure why I'm getting two blocks of 16clock cycles. Shouldn't it just be 1?

Looks like the device supports different modes of operation.

This code here:

https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad7923.c#L323

Creates these two messages.

-Michael

mhennerich 
Update with spi signals

cat in_voltage1_raw -> Showing CH3 to CH1

cat in_voltage2_raw -> Showing CH1 to CH2

cat in_voltage3_raw -> Showing CH2 to CH3

Device functions correctly, however the driver seems to be unable to parse the data and can't get the address correctly, returning -EIO.

Again, try to print the raw samples.

It might not be an IIO/ADC driver issue, but maybe somewhere in your SoC HW or SPI driver.

Can you disconnect MISO from the ADC and either assert HIGH or LOW and verify that your getting 0xFFFF or 0x0000?

-Michael 

mhennerich 

It's all zero. There is another device that uses this spi bus (gpioe) and it works fine. So not sure what is going on. I'm running on Zynq uP

I cannot disconnect. This isn't eval board. The device is already built into the pcb

I cannot disconnect. This isn't eval board. The device is already built into the pcb

In function ad7923_scan_direct can you print st->rx_buf[0], st->rx_buf[1], st->rx_buf[2], st->rx_buf[3]  after spi_sync() ? 

-Michael

 mhennerich 

Could you enlighten me on how rx_buf is supposed to be getting populated? I see it read from multiple times but nowhere is it being asssigned. Is spi_sync just supposed to know based on your

ad7923_scan_direct() uses st->scan_single_msg which is composed here:

https://github.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad7923.c#L323

There are two transfers each two bytes long (len=2) with a CS change in between.

The first message is a SPI write which uses  st->tx_buf, the following message is a read using st->rx_buf.

-Michael