ADF4350 driver issues on master
rgetz opened this issue · comments
booting a master kernel with a 2019R1 device tree on ZedBoard + FMCOMMS3, gives me this during boot:
adf4350 spi1.0: spi1.0 supply vcc not found, using dummy regulator
adf4350 spi1.0: Linked as a consumer to regulator.0
adf4350 spi1.1: spi1.1 supply vcc not found, using dummy regulator
adf4350 spi1.1: Linked as a consumer to regulator.0
which is fine - this device has no way to tell if it is there or not (it's a write only device), if device tree says it is there - it is.
two issues:
wrong IIO name
names shouldn't be the spi bus - it should be the device name.
iio_attr -c
IIO context has 8 devices:
iio:device0, ad7291: found 9 channels
iio:device1, ad9361-phy: found 11 channels
iio:device2, xadc: found 9 channels
iio:device3, spi1.0: found 1 channels
iio:device4, spi1.1: found 1 channels
iio:device5, cf-ad9361-dds-core-lpc: found 12 channels
iio:device6, cf-ad9361-lpc: found 4 channels
iio_sysfs_trigger: found 0 channels
Why is it in device tree?
dtc -I fs /sys/firmware/devicetree/base | less
adf4351-udc-rx-pmod@1 {
adf4351-udc-tx-pmod@0 {
why is that in the FMCOMMS2/3 device tree? That should only be in the FMCOMMS5.
Wrong IIO name - this used to work. See here:
https://wiki.analog.com/resources/tools-software/linux-drivers/iio-pll/adf4350#driver_testing
I guess this broke by the patch which added of bindings, and the way we instantiate the device.
Why is it in device tree?
It's the UP DOWN converter, which is in those projects the PMOD header supports it by the HDL.
Thanks - makes sense on the ADF4351.
Someone will look into the naming issue?
This should be easy to fix.
PR #1026 was merged