AnsweredAssumed Answered

AD9361: notifying driver of external LO changes

Question asked by jtrimble on Sep 22, 2015
Latest reply on Sep 24, 2015 by jtrimble

I'd like someone (maybe mhennerich) to verify my reasoning below:

 

In our system, we've got an LO generator that drives the RX_EXT_LO_IN pin of several AD9361's, and we've arranged the 9361's in an MCS configuration.

 

It appears that when the AD9361 is configured to take in the external LO (either by setting adi,external-rx-lo-enable in the devicetree or by setting out_altvoltage0_RX_LO_external to '1' in the IIO device), the driver no longer has direct knowledge of the LO frequency, which is important since the LO frequency it is used when looking up settings to apply when changing the gain or setting up offset tracking (and perhaps some other things as well?).

 

In my case, I haven't specified an "ext_rx_lo" in the AD9361's "clock-names" array in my devicetree, so the AD9361 driver is instantiating a "*-rx_lo_dummy" clock which is treated as the parent of "*-rx_rfpll" when configured to use the external LO.

 

It seems, then, that I should be somehow notifying the AD9361 driver when I'm changing the frequency of my external LO.

 

I see two ways to do this:

  1. If the external LO is being driven by a device with a kernel driver that implements the clk API, I should add a phandle to that clock in the 9361's "clocks" attribute (with a matching "ext_rx_lo" in the "clock-names" attribute) in the devicetree.
  2. Otherwise, if my external LO is not controlled by a kernel driver, I should be writing the new LO frequency (twice the RF center freq.) to out_altvoltage0_RX_LO_frequency whenever I change the external LO frequency while out_altvoltage0_RX_LO_external == 1.

 

Did I get that right?  Are there any other pitfalls to watch out for?  Does this in any way interact with MCS (I suspect not, as long as I'm driving the same LO into all of my AD9361's, right)?

Outcomes