AnsweredAssumed Answered

AD9361 not detected in Linux 4.9 (ADI branch)

Question asked by kalden on Sep 27, 2017
Latest reply on Sep 27, 2017 by larsc

I have a system with two AD9361 chips and an Arria10 processor running linux.  With the 4.0 Linux branch from Analog Devices, everything is working fine.  We are upgrading to 4.9 and now we are getting errors while the driver probes for the second 9361.

 

Here is dmesg output when using the 4.0 kernel:

# dmesg | grep spi
[ 0.995152] spi_altera ff208060.spi: base f012a060, irq 43
[ 1.001310] spi_altera ff208080.spi: base f012c080, irq 32
[ 1.187731] ad9361 spi32766.0: ad9361_probe : enter
[ 1.195613] spi spi32766.0: Driver ad9361 requests probe deferral
[ 1.201795] ad9361 spi32766.1: ad9361_probe : enter
[ 1.209813] spi spi32766.1: Driver ad9361 requests probe deferral
[ 1.216324] spi32765.0 supply vcc not found, using dummy regulator
[ 1.476443] ad9361 spi32766.0: ad9361_probe : enter
[ 1.749687] ad9361 spi32766.0: ad9361_probe : AD9361 Rev 2 successfully initialized
[ 1.757434] ad9361 spi32766.1: ad9361_probe : enter
[ 2.033187] ad9361 spi32766.1: ad9361_probe : AD9361 Rev 2 successfully initialized

 

When we move to the 4.9 kernel, we see this:

# dmesg | grep spi
[ 1.069869] spi_altera ff208060.spi: base f0920060, irq 44
[ 1.076255] spi_altera ff208080.spi: base f0922080, irq 33
[ 1.536329] ad9361 spi32766.0: ad9361_probe : enter (ad9361-2x)
[ 1.545747] ad9361 spi32766.1: ad9361_probe : enter (ad9361)
[ 1.557654] spi32765.0 supply vcc not found, using dummy regulator
[ 1.732215] ad9361 spi32766.0: ad9361_probe : enter (ad9361-2x)
[ 2.022455] ad9361 spi32766.0: ad9361_probe : AD936x Rev 2 successfully initialized
[ 2.030329] ad9361 spi32766.1: ad9361_probe : enter (ad9361)
[ 2.037002] ad9361: probe of spi32766.1 failed with error -16

 

 

We have traced this back to line 8876 of ad9361.c:

 

/* Optional: next three used for MCS synchronization */
phy->pdata->sync_gpio = devm_gpiod_get_optional(&spi->dev, "sync",
GPIOD_OUT_LOW);
if (IS_ERR(phy->pdata->sync_gpio))
return PTR_ERR(phy->pdata->sync_gpio);

 

 

I'm not sure why this line would succeed for the first transceiver, but fail for the second.  This worked in kernel 4.0 just fine.  Both transceiver sections in the DTB has the following line:

sync-gpios = <&alt_gpio2 0 0>;

 

If we comment out the sync-gpios line from the second transceiver, the error goes away.  I'm not sure if this will have a negative impact on MCS sync functionality though.

 

for reference, alt_gpio2 looks like this:

 

alt_gpio2: gpio@0x100040800 {
compatible = "altr,pio-15.0", "altr,pio-1.0";
reg = <0x00000001 0x00040800 0x00000020>;
altr,gpio-bank-width = <5>;
resetvalue = <0>;
#gpio-cells = <2>;
gpio-controller;
clocks = <&clock100>;
};

 

 

Thanks in advance for any help.

Outcomes