From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jyoti Bhayana <jbhayana@google.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Rob Herring <robh@kernel.org>,
"Lukas Bulwahn" <lukas.bulwahn@gmail.com>,
<linux-kernel@vger.kernel.org>, <linux-iio@vger.kernel.org>,
<cristian.marussi@arm.com>, <sudeep.holla@arm.com>,
<egranata@google.com>, <mikhail.golubev@opensynergy.com>,
<Igor.Skalkin@opensynergy.com>, <Peter.hilber@opensynergy.com>,
<ankitarora@google.com>
Subject: Re: Reply to [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors
Date: Wed, 6 Jan 2021 10:29:17 +0000 [thread overview]
Message-ID: <20210106102917.0000332c@Huawei.com> (raw)
In-Reply-To: <20210105230920.769144-1-jbhayana@google.com>
On Tue, 5 Jan 2021 23:09:20 +0000
Jyoti Bhayana <jbhayana@google.com> wrote:
> Hi Jonathan,
>
> > So, sensor_max_range can effectively be exposed as a combination of
> > scale and the *_raw_avail for a raw read (via the read_avail callback in IIO).
> > We'll ignore the fact the interface assumes a single value (so I assume symmetric?)
>
> Based on the SCMI specification the sensor min range and max range are 64 bits signed number.
>
> looks like IIO_AVAIL_RANGE can only take the following
> types of data which all looks like 32 bit. IIO_VAL_FRACTIONAL
> also takes two int type numbers.
> How can I send 64 bit sensor range using this and read_avail callback?
>
> #define IIO_VAL_INT 1
> #define IIO_VAL_INT_PLUS_MICRO 2
> #define IIO_VAL_INT_PLUS_NANO 3
> #define IIO_VAL_INT_PLUS_MICRO_DB 4
> #define IIO_VAL_INT_MULTIPLE 5
> #define IIO_VAL_FRACTIONAL 10
> #define IIO_VAL_FRACTIONAL_LOG2 11
> #define IIO_VAL_CHAR 12
Hmm It is a bit unfortunate that SCMI decided to pretend that real sensor resolutions were
greater than 32 bits. I doubt they will ever actually be any (as such accurate measurements
are completely pointless) and they aren't anywhere near that today. Only way it might end
up looking a bit like that would be result of a highly non linear sensor being shoved through
an interface that pretends it isn't (goody).
Having said that, specifications are what they are and we have to cope with that.
There is no real problem with defining a new value type except for the fact that any
legacy userspace won't necessarily expect to see values that large. Given we need the full
64 bits it would have to be something like
IIO_VAL_INT_H32_L32 with the 64 bit values split up appropriately and put back together
at time of formatting. Not particularly pretty but I'm not keep to put that much effort
in to support something like this for one driver (so not interesting in changing that
the read_raw_* interfaces)
Jonathan
>
>
>
> Thanks,
> Jyoti
>
next prev parent reply other threads:[~2021-01-06 10:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-24 3:19 [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors Jyoti Bhayana
2020-12-24 3:19 ` [RFC PATCH v2 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors Jyoti Bhayana
2020-12-30 13:41 ` Jonathan Cameron
2020-12-30 16:09 ` Lars-Peter Clausen
2020-12-30 12:37 ` [RFC PATCH v2 0/1] Adding support for IIO SCMI based sensors Jonathan Cameron
2021-01-05 23:09 ` Reply to " Jyoti Bhayana
2021-01-06 10:29 ` Jonathan Cameron [this message]
2021-01-06 11:26 ` Cristian Marussi
2021-01-06 14:36 ` Jonathan Cameron
2021-01-06 16:12 ` Cristian Marussi
2021-01-06 21:23 ` Jyoti Bhayana
2021-01-09 19:01 ` Jonathan Cameron
2021-01-11 6:44 ` Jyoti Bhayana
2021-01-11 12:33 ` Jonathan Cameron
2021-01-11 21:17 ` Jyoti Bhayana
2021-01-16 19:33 ` Jonathan Cameron
2021-01-17 7:15 ` Jyoti Bhayana
2021-01-17 11:56 ` Jonathan Cameron
2021-01-17 21:02 ` Jyoti Bhayana
2021-01-18 13:42 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210106102917.0000332c@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Igor.Skalkin@opensynergy.com \
--cc=Peter.hilber@opensynergy.com \
--cc=ankitarora@google.com \
--cc=cristian.marussi@arm.com \
--cc=davem@davemloft.net \
--cc=egranata@google.com \
--cc=jbhayana@google.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mchehab+huawei@kernel.org \
--cc=mikhail.golubev@opensynergy.com \
--cc=pmeerw@pmeerw.net \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox