AD7944: Add support for AD7944/85/86 devices

[threexc]

Description

This is the (final) PR for supporting the AD7944, AD7985, and AD7986 devices in pyadi-iio. It features a somewhat new approach to testing the sampling_frequency attribute and some variable logic depending on whether or not SPI offload is enabled in the driver.

Note that it supersedes the work done in #562.

As of right now, new emulation files still need to be added for the AD7944 and AD7986, so it's marked as a draft.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How has this been tested?

• Tested on a Zedboard running Linux with the AD7944/85/86 driver loaded, using pyadi-iio to interact with the device remotely.
• Tested against emulated targets.

Test Configuration:

• Hardware: Zedboard with EVAL-AD7985FMCZ
• OS: Kuiper Linux with custom kernel

Documentation

Documentation is included to reflect the new devices and their functionality.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have signed off all commits and they contain "Signed-off by: "
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[threexc]

@tfcollins I think this is mostly ready to squash, do any extra pre-commit cleanups on, etc. (once I get the ad7944 and ad7986 emulation files updated), but I have a question about tests:

This device's data type and sampling_frequency range both change depending on whether or not SPI offload is configured in the kernel (this is the only way to achieve the maximum sample rate). Right now, everything works only in offload mode, since that's what we expect most users are going to want for best performance. This means that if someone were to try using the code with a non-offload kernel, they'd probably find it doesn't work (as of right now I'm getting timeouts when trying to read data).

Given that the non-offload version also requires a hrtimer trigger to be configured on the host system, it may not be reasonable to include support for that mode. I'm still experimenting...

Is this a problem from a pyadi-iio perspective, if it's documented?

[tfcollins]

Code is fine. Just need to fix lint errors

[threexc]

Updated!

[threexc]

Accidentally hit close. Should be ready to go now.

[threexc]

@tfcollins FYI the XML was updated, but I don't have merge permission.