AnsweredAssumed Answered

AD9361 SPI driver GPIO control

Question asked by bistromat on Dec 9, 2014
Latest reply on Dec 9, 2014 by mhennerich

Hi,

 

I've got a modified FMCOMMS2 reference design up and running on a custom board, great. I've got a little bit of a chicken-and-egg problem on initialization, however. There are a couple of GPIOs on my board controlling power to the 9361 subsystem, connected to EMIO. There's no way to specify a default GPIO setting (on/off) in the device tree, so the board boots with no power to the 9361 subsystem. This causes 9361 SPI probing to fail. Yes, I could put a pullup on the power enables, but bear with me here as I'd like to have software control from the driver.

 

First question: Is there a way to manually probe the 9361 driver after it's failed to find a device at boot?

 

My first thought was to modify the 9361 kernel driver to set those GPIOs before attempting a SPI probe. This made sense as there were several other entries in the adi-fmcomms2.dts device tree related to the 9361 device GPIOs:

 

* en_agc-gpios

* sync-gpios

* reset-gpios

* enable-gpios

* txnrx-gpios

 

...and I could just add a couple more into the devicetree and initialize them alongside those five. The problem is, I can't find those entries being used anywhere in the 9361 driver (or anywhere else, for that matter). Upon closer examination the five GPIO definitions reside in the axi-ad9361 section, which implies the AXI driver is responsible for them, but I can't find anything in that driver controlling those pins, either. Are these pins used in the reference design, and if so can you point me to where those definitions in the devicetree are read into the driver configuration?

 

Thanks,

Nick

Outcomes