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

I also get this message during the boot process:

[ 14.454752] ad7923 spi5.1: supply refin not found, using dummy regulator

Even though I explicitly define the reference voltage in the DT.

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

HI Michael! First off thank you for responding.

I went into the config and added 

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