On Wed, Dec 8, 2021 at 2:23 PM Henk <yoda@xxxxxxxxxxxxx> wrote: > Wouldn't it be an option to extend the IIO framework with a unit > description like Hz, kHz, MHz, GHz.... You probably meant SI scale factors. Because units may be way different and sometimes behind physics (as a science) standards. But even with this you may lose precision if, let's say, units are Hz and you need to measure in a range of 10GHz:s you would still need 64-bit value for high precision measurements. > 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 :) P.S. Please avoid top postings. > 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.”... > -- With Best Regards, Andy Shevchenko
