iio display large numbers

iio display large numbers

[Henk]

Hi,

I derived the LTC6951 driver from an existing analog devices LTC6952 driver.
However for my situation this clock synthesis/buffer uses quite large 
output frequencies (2.5GHz) which does not fit in the IIO_VAL_INT size 
when retrieved with iio_info.

I wonder if there is a way to represent such long integers within the 
iio_framework. I believe currently there isn't right?

Regards,

Henk

-- 
“Do. Or do not. There is no try.”...

Re: iio display large numbers

[Jonathan Cameron]

On Tue, 7 Dec 2021 13:40:19 +0100
Henk <yoda@deathstar2.nl> wrote:

> Hi,
> 
> I derived the LTC6951 driver from an existing analog devices LTC6952 driver.
> However for my situation this clock synthesis/buffer uses quite large 
> output frequencies (2.5GHz) which does not fit in the IIO_VAL_INT size 
> when retrieved with iio_info.
> 
> I wonder if there is a way to represent such long integers within the 
> iio_framework. I believe currently there isn't right?
> 
> Regards,
> 
> Henk
> 

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.

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.

Hope that helps,

Jonathan

Re: iio display large numbers

[Henk]

Hi Jonathan,


> 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.

I agree although a lot of existing drivers already use this granularity.
It is commonly used in Analog Devices IIO drivers, especially the 
frequency generating products.

> 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.
Great!
I will probably patch my adi kernel sources to use this approach for the 
time being
>
> Hope that helps,
>
> Jonathan

Tnx,

Henk

Re: iio display large numbers

[Andy Shevchenko]

On Wed, Dec 8, 2021 at 2:56 AM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
> On Tue, 7 Dec 2021 13:40:19 +0100
> Henk <yoda@deathstar2.nl> 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 :-)

> 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

Re: iio display large numbers

[Alexandru Ardelean]

On Wed, Dec 8, 2021 at 11:33 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Dec 8, 2021 at 2:56 AM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> > On Tue, 7 Dec 2021 13:40:19 +0100
> > Henk <yoda@deathstar2.nl> 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

Re: iio display large numbers

[Henk]

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@gmail.com> wrote:
>> On Wed, Dec 8, 2021 at 2:56 AM Jonathan Cameron
>> <Jonathan.Cameron@huawei.com> wrote:
>>> On Tue, 7 Dec 2021 13:40:19 +0100
>>> Henk <yoda@deathstar2.nl> 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.”...

Re: iio display large numbers

[Andy Shevchenko]

On Wed, Dec 8, 2021 at 2:23 PM Henk <yoda@deathstar2.nl> 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@gmail.com> wrote:
> >> On Wed, Dec 8, 2021 at 2:56 AM Jonathan Cameron
> >> <Jonathan.Cameron@huawei.com> wrote:
> >>> On Tue, 7 Dec 2021 13:40:19 +0100
> >>> Henk <yoda@deathstar2.nl> 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