Not yet confirmed - noticed this while working on a712304f02b49dd53c042ddbad715ae2ff434adb, jotting it down here as a reminder for further investigation.
If the device is tuned in a manner that changes between the high and low band, and then loopback mode is exited, the output PLL buffers (SELOUT[1:0]) may be left in an incorrect state. Specifically, SELOUT[1:0] will have the output buffer configured for the band we started in since we don't touch SELOUT[1:0] while in loopback, as this must remain set for LNA N in rf_lnaN loopback modes.
A potential workaround for libbladeRF users would be to make a call to bladerf_set_frequency() upon exiting loopback mode. This result in write_pll_config() being called in lms_set_frequency().
A potential solution might be to call lms_set_frequency() on our way out of loopback, but I still need to check if there are any other items that could be left in a potentially incorrect state.
Not yet confirmed - noticed this while working on a712304f02b49dd53c042ddbad715ae2ff434adb, jotting it down here as a reminder for further investigation.
If the device is tuned in a manner that changes between the high and low band, and then loopback mode is exited, the output PLL buffers (SELOUT[1:0]) may be left in an incorrect state. Specifically, SELOUT[1:0] will have the output buffer configured for the band we started in since we don't touch SELOUT[1:0] while in loopback, as this must remain set for LNA N in rf_lnaN loopback modes.
A potential workaround for libbladeRF users would be to make a call to bladerf_set_frequency() upon exiting loopback mode. This result in write_pll_config() being called in lms_set_frequency().
A potential solution might be to call lms_set_frequency() on our way out of loopback, but I still need to check if there are any other items that could be left in a potentially incorrect state.