* iio display large numbers @ 2021-12-07 12:40 Henk 2021-12-07 16:13 ` Jonathan Cameron 0 siblings, 1 reply; 7+ messages in thread From: Henk @ 2021-12-07 12:40 UTC (permalink / raw) To: linux-iio 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.”... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iio display large numbers 2021-12-07 12:40 iio display large numbers Henk @ 2021-12-07 16:13 ` Jonathan Cameron 2021-12-08 6:20 ` Andy Shevchenko 0 siblings, 1 reply; 7+ messages in thread From: Jonathan Cameron @ 2021-12-07 16:13 UTC (permalink / raw) To: Henk; +Cc: linux-iio 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iio display large numbers 2021-12-07 16:13 ` Jonathan Cameron @ 2021-12-08 6:20 ` Andy Shevchenko 2021-12-08 9:49 ` Alexandru Ardelean 0 siblings, 1 reply; 7+ messages in thread From: Andy Shevchenko @ 2021-12-08 6:20 UTC (permalink / raw) To: Jonathan Cameron; +Cc: Henk, linux-iio 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iio display large numbers 2021-12-08 6:20 ` Andy Shevchenko @ 2021-12-08 9:49 ` Alexandru Ardelean 2021-12-08 12:23 ` Henk 0 siblings, 1 reply; 7+ messages in thread From: Alexandru Ardelean @ 2021-12-08 9:49 UTC (permalink / raw) To: Andy Shevchenko; +Cc: Jonathan Cameron, Henk, linux-iio 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iio display large numbers 2021-12-08 9:49 ` Alexandru Ardelean @ 2021-12-08 12:23 ` Henk 2021-12-08 12:31 ` Andy Shevchenko 0 siblings, 1 reply; 7+ messages in thread From: Henk @ 2021-12-08 12:23 UTC (permalink / raw) To: Alexandru Ardelean, Andy Shevchenko; +Cc: Jonathan Cameron, linux-iio 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.”... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: iio display large numbers 2021-12-08 12:23 ` Henk @ 2021-12-08 12:31 ` Andy Shevchenko 0 siblings, 0 replies; 7+ messages in thread From: Andy Shevchenko @ 2021-12-08 12:31 UTC (permalink / raw) To: Henk; +Cc: Alexandru Ardelean, Jonathan Cameron, linux-iio 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <16f1078c-bbff-40ae-08b3-b1384aeb5313@deathstar2.nl>]
* Re: iio display large numbers [not found] <16f1078c-bbff-40ae-08b3-b1384aeb5313@deathstar2.nl> @ 2021-12-07 16:54 ` Henk 0 siblings, 0 replies; 7+ messages in thread From: Henk @ 2021-12-07 16:54 UTC (permalink / raw) To: linux-iio 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-12-08 12:33 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-07 12:40 iio display large numbers Henk
2021-12-07 16:13 ` Jonathan Cameron
2021-12-08 6:20 ` Andy Shevchenko
2021-12-08 9:49 ` Alexandru Ardelean
2021-12-08 12:23 ` Henk
2021-12-08 12:31 ` Andy Shevchenko
[not found] <16f1078c-bbff-40ae-08b3-b1384aeb5313@deathstar2.nl>
2021-12-07 16:54 ` Henk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.