Use with reference clock inputs to report if lock is currently lost. Also
supports reporting the clearable lock lost register which is useful for
reporting if lock has ever been lost but possibly regained without knowing

Board layout for RFSoC4x2 connects SDO pin of the LMX IC to STATUS_LD2. Reading
back the register status requires then configuring a different register than on
the other platforms. This register is R366 and needs to have the
PLL2_LD_MUX/PLL2_LD_TYPE set correctly to readback.

LMX readback is not implemented yet but it looks like something similar may need
to happen to just make sure the correct register setup on the LMX chip is
properly configured before reading back.

(still probably not ideal how they coexist)

realized rfsoc4x2 doesn't support LMK/LMX PLL readback beacsue the PLL
`LD_STATUS` pins are pin strapped to only LEDs.

The reamining spi code that was added is just convenient to keep around

tested to at least program the rfsoc4x2 and not break the zcu216. Read back is
not currently working on rfsoc4x2 but seems to still be working on zcu216

rfsoc4x2 uses spi directly while the other rfsoc boards have used an i2c to spi
bridge. So this is a brute force hack to just get spi in there.

might be worthwhile to rethink the implementation since it is becoming unweildy
to have the different cases based on platform

makefiles include the platform instead of having to define PLATFORM in the
source or change `alpaca_platform.h` everytime

determinstic names are now assigned by the device tree i2c aliases. These
changes come from those new aliases

zcu111 phy clk clode changed to target zrf16 i2c dev, could generalize to a
single method for both platforms since both are si chips. Would also work for
any of the si chips on all of these rfsoc platforms

extend `alpaca_rfclks` methods to include readbacks for lmk/lmx, and to add
support for generalized i2c packet lengts. This allows for supporting the lmk on
the zcu111. Tested on all 3 platforms.

All 3 platform files to program the lmk and lmx only differ in how the
i2c/peripheral hardware is initialized and the number of plls their program
(e.g., zcu111/zrf16 both have 2 lmx adc plls, zcu216/208 only have one).

*does not compile* (shame on me), should have done an intermediate commit
as soon as getting this zcu111 script to work, but began to move common
functionality for all boards in `alpaca_rfclks` but wanted to track some specifc
version of the zcu111

had a bug when comparing pll type look for the lmx, compared against the wrong
enum and would have segfaulted.

Also fixed number of lmk regsiters coming out for lmk04828b. Seems tics outputs
136 instead of what I thought was 128, not sure where that came from.

a little better read code in the while-loop to at least make sure we don't read
off and access past the length we malloc'd

*Extend `rfclks` module to have a common program method callable to program an
lmk (on the zcu216/208 and HTG boards -- need to check on zcu111) or an lmx

* Move implementation of reading TICS text file to a common module method.
  implement the difference between reading an LMK and LMX (i.e., setup program
  sequence for LMX since it requires to duplicate and apply reset)

* update `prg_pll`, `zcu216_rfclks` and `htg_rfclks` to use the new common
  methods

* extend `prg_pll` to program either the zcu216 lmk or lmx with a command line
  switch

* still need to implement a readback

(also updates to continue to add i2c infrastructure and pynq2x2 definitions)

Take all of the rfpll platform specific definitions from the test standalone and
make a single header and implementations that builds definitions based on the
rfsoc platform definition. A new platform header is used to be included for the
different hardware peripherals (first i2c and now lmk/lmx plls).

The implementation in the test files has not changed, just pulling out what can
be consolodated. From here would be to continue to make clk programming methods.

includes zrf16 and zcu216 i2c structure, simple programming for lmk/lmx on both
boards and test probing the sfp/qsfp cages

The struct really represents a i2c device sitting on a mux more than a generic
i2c device. This struct and i2c write/read methods would not work because they
expect to write to a mux to talk to a device

Making an i2c driver that is extendable has its problems when needing to be
versatile to different scenarios and configurations. In this context is the i2c
coniguration for the rfsoc boards where the mpsoc has i2c buses each with mux to
extend attached i2c devices. For the rf clocking htg uses i2c0 and xilinx eval
boards use i2c1. The inital code only targeted i2c1 and now really need both.

Not just in the context of the rf clocks either, but all board i2c peripherals.
So it makes sense to just always instance both since generally both busses are
configured in mpsoc boards (although not guaranteed).

So staging these commits before I start hacking and testing a way to determine
parent device. My first thought is to just have a parent fd object in my struct
but I am not sure if this will cause problems when a device doesn't sit on a
mux.

took the htg i2c code and reworked it to use the new i2c utils that will
hopefully be able to extendable across different rfsoc platforms. This depends
on the LMK_LMX_config.h definition of LMK/LMX registers that are not committed
her just yet

and fix of typo in test platform description for htg i2c rfpll devices

So far this looks like eit will work failry well. However, I am having a
hardtime seeing if extending the the LMK/LMX chips that this device structure
will work out because the IO expander and SPI CS signals also need to be
configured. This should reasonably fit within a definition targeting the lmk/lmx

The hope and idea is that this will extend both maintainability and the
extendability to other platforms

include init bus/device methods