Hi,
Wouldn't it be an option to extend the IIO framework with a unit
description like Hz, kHz, MHz, GHz....
Otherwise I am happy with the IIO_VAL_INT_64 for the time being.
Btw... software developers should not decide which precision is a real
world issue or not :) but only decide to support the need.
For the time being it is a bit stupid that my 2.5 GHz output from my
LTC6951 shows up as a negative frequency :)
Regards,
Henk Medenblik
On 12/8/21 10:49 AM, Alexandru Ardelean wrote:
On Wed, Dec 8, 2021 at 11:33 AM Andy Shevchenko
<andy.shevchenko@xxxxxxxxx> wrote:
On Wed, Dec 8, 2021 at 2:56 AM Jonathan Cameron
<Jonathan.Cameron@xxxxxxxxxx> wrote:
On Tue, 7 Dec 2021 13:40:19 +0100
Henk <yoda@xxxxxxxxxxxxx> wrote:
...
Two options for this. If the thing we are controlling is the raw channel then
we have the option to provide _scale reflecting the fact that a large value
e.g. GHz is not normally controlled at a Hz granularity.
But some sensors can be really high-precision ones, although I
couldn't imagine a value that requires more than 32-bit for that in
general engineering. Where one may ask for more is something like very
precise physics experiments in CERN :-)
Yeah, and this is where IIO and some sensors and clock generators seem to go.
Research and military, 5G networks, aerospace, etc.
It's a bit tricky to pin certain sub-systems (for some of them).
Like, the clock-framework can only represent up to 4 (or 2) billion HZ
(I forget if it's u32 or i32).
So, this creates limitations/discussions with some clock-chips and
where they need to go (IIO or CCF).
On the other end, there was a discussion [a few months back] about
needing lower than nano scales in IIO.
So, this opens up a new set of discussions, like:
1. How should people use Linux for these types of devices?
1a. Should people use Linux for these types of devices?
2. [If 1 is Yes, then] Which sub-system to use?
3. Once a sub-system has been chosen, how to do it?
3a. Extend the common framework (and how?) to support these new sets of devices?
3b. Or do some custom attributes?
On point 3, a lot of times 3b is the chosen route [by chip vendors],
because these new chips seem to come out faster than the ability to
extend these common frameworks.
To me, it has become obvious [a few years ago] that the Linux kernel
has been very good at serving computing needs mostly targeted towards
data-centers (big physical servers, lots of VMs, networking and all).
We're probably going to see more of these specialized devices trying
to slowly pop up.
And it will be an interesting journey to see (after all of it unfolds).
Where that doesn't apply or the range is really very big we do have the
slightly nasty option of IIO_VAL_INT_64
https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/commit/?h=testing&id=6bb835f3d00467c9a5e35f4955afa29df96a404e
This is very new, so not in mainline yet, though it is queued up for the
next merge window and should be linux-next.
--
With Best Regards,
Andy Shevchenko
--
“Do. Or do not. There is no try.”...
