Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
On Fri, 29 Jan 2021 14:50:20 -0800
Jyoti Bhayana wrote:
> Hi Peter,
>
> I have modified the comments in v4 of that patch. Regarding your
> suggestion of this driver handling a greater value range
> by adjusting the scale accordingly, it would also require the driver
> to change the sensor readings as well based on the updated scale and
> the accuracy of the sensor reading will be lost as the sensor readings
> are 64 bit integers and not float.
> If the IIO driver needs to support a 64 bit sensor range, then I would
> prefer to add a new IIO val type for 64 bit fractional value which
> takes 4 int vals: val_high,val_low, val2_high and val2_low.
The problem with that sort of change is that you have to make
all various users of callbacks in the kernel deal with more parameters.
read_raw gets called form a lot of places.
I'm really not keen to do that. It means making a big mess to deal
with this one case of too many layers of abstraction and values claiming
considerably more precision than they actually have. We decided on
an integer pair a long time back as it provides more than enough precision
for any real sensor.
Given that you are using fractional values to generate a sysfs string
(for direct exposure to userspace anyway), just do the maths inside
the driver to fit it into a INT_PLUS_MICRO or similar.
Jonathan
>
> Thanks,
> Jyoti
>
> On Tue, Jan 26, 2021 at 7:29 AM Peter Hilber
> wrote:
> >
> > On 22.01.21 00:21, Jyoti Bhayana wrote:
> >
> >
> >
> > > +
> > > +static int scmi_iio_get_sensor_max_range(struct iio_dev *iio_dev, int
> > > *val,
> > > + int *val2)
> > > +{
> > > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > + int max_range_high, max_range_low;
> > > + long long max_range;
> > > +
> > > + /*
> > > + * All the axes are supposed to have the same value for max range.
> > > + * We are just using the values from the Axis 0 here.
> > > + */
> > > + if (sensor->sensor_info->axis[0].extended_attrs) {
> > > + max_range = sensor->sensor_info->axis[0].attrs.max_range;
> > > + max_range_high = H32(max_range);
> > > + max_range_low = L32(max_range);
> > > +
> > > + /*
> > > + * As IIO Val types have no provision for 64 bit values,
> > > + * and currently there are no known sensors using 64 bit
> > > + * for the range, this driver only supports sensor with
> > > + * 32 bit range value.
> > > + */
> > This comment and the corresponding one in
> > scmi_iio_get_sensor_min_range() seem to be misleading to me. The extrema
> > will probably exceed 32 bits even for physical sensors which do have
> > less than 32 bits of resolution. The reason is that the SCMI sensor
> > management protocol does not transmit a `scale' value as used by IIO.
> > Instead, SCMI transmits an exponent with base ten.
> >
> > So, an SCMI sensor with a unit/LSB value which is not a power of ten
> > will have its unit/LSB value split into an exponent (with base ten) and
> > a mantissa.
> >
> > The SCMI platform (which exposes the physical sensor) will have to
> > incorporate the mantissa into the sensor value. The simplest approach is
> > to just multiply the mantissa with the raw physical sensor value, which
> > will use more bits than the raw physical sensor value, depending on the
> > unit/LSB value (and on the split of the unit/LSB value into exponent and
> > mantissa).
> >
> > So I think the comment should at least make clear that the overflow may
> > also happen for physical sensors with less than 32 bit of resolution,
> > since it cannot be assumed that SCMI platforms will, without any
> > apparent need, restrict the values to 32 bits, when that would mean
> > additional complexity and potential loss of accuracy. (And in the long
> > term this driver could IMHO try to handle a greater value range by
> > adjusting the `scale' value accordingly.)
> >
> > Best regards,
> >
> > Peter
> >
> > > + if (max_range_high != 0)
> > > + return -EINVAL;
> > > +
> > > + *val = max_range_low;
> > > + *val2 = 1;
> > > + }
> > > + return 0;
> > > +}
> > > +
> > > +static void scmi_iio_get_sensor_resolution(struct iio_dev *iio_dev, int
> > > *val,
> > > +int *val2)
> > > +{
> > > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > +
> > > + /*
> > > + * All the axes are supposed to have the same value for resolution
> > > + * and exponent. We are just using the values from the Axis 0 here.
> > > + */
> > > + if (sensor->sensor_info->axis[0].extended_attrs) {
> > > + uint resolution = sensor->sensor_info->axis[0].resolution;
> > > + s8 exponent = sensor->sensor_info->axis[0].exponent;
> > > + s8 scale = sensor->sensor_info->axis[0].scale;
> > > +
> > > + /*
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
On Sat, 30 Jan 2021 21:21:41 + Cristian Marussi wrote: > Hi Jyoti, > > On Fri, Jan 29, 2021 at 02:43:13PM -0800, Jyoti Bhayana wrote: > > Hi Christian, > > > > I have addressed your feedback in v4 of the patch. Please find below > > the answers to some of your questions: > > >The initial sensor_config ORed here is NOT initialized nor zeroed. > > > > There is no need to initialize as it is already initialized to 0 when > > defined. > > > > True for the sensor_config in scmi_iio_buffer_postdisable(), BUT it is > not indeed zero-initialized at definition time in the other similar > function scmi_iio_buffer_preenable(), that is what the above comment was > referred to. > > > > being not so familiar with IIO, may I ask when and how much frequently > > > these ops are called ? (given they include a register/unregister + > > > enable/disable every time) > > > > These are called whenever the sensor is enabled/disabled by writing > > to buffer/enable sysfs node > > > > Ok, thanks. > > > >AFAIU this is called during IIO init and derives a modifier from the name > > >of the sensors which are passed by the platform fw with sensor descriptors, > > >so I would not trust them to be weell formed (:D) and try to be picky about > > >*name as it was user-input to validate. > > > > The SCMI specification has mentioned the naming convention for the > > axis as below . > > "A NULL terminated UTF-8 format string with the sensor axis name, of > > up to 16 bytes. It is recommended that the name ends with ‘_’ followed > > by the axis of the sensor in uppercase. For example, the name for the > > x-axis of a triaxial accelerometer could be “acc_X” or “_X” > > > > If there is any other better way to get the modifier, please let me know. > > > > What I was trying to say was simply that, despite what the spec says, > you cannot trust the fw/platform produced values (fw buggy ? data on channel > corrupted ? malicious pkt injections ? fuzzing ? ) and so you should be picky > and validate them also against any possible out-of-spec data, since the Kernel > must not crash even if presented with unreasonable out-of-spec garbage-like > data, thing that indeed you did in v4 by adding the check for NULL against > name param. :D (the other case of a malformed name like "acc_" seemed to > me handled properly already by the kernel strcmp) > > > > why not a break to a final 'return ret;' (with ret properly set) ? > > > > According to Jonathan, direct returns are preferred. > > > > Ok > > > >Not familiar with IIO, but is it fine to setup ops and modes AFTER > > >having attached the buffer to the scmi_iiodev ? > > >Is is not 'racy-possible' that the buffer is already operational without > > >any ops immediately after being attached ? > > > > I have looked at other IIO drivers and they all do it this way. > > > > Ok. There is a good logical flow in setting the ops before attaching, but in reality it doesn't matter because all that attach is actually doing is connecting up some internals for the iio_device_register() to act on later. Until that's called no access to the buffer ops can be made (there are no userspace or inkernel interfaces available). Jonathan > > Thanks, I'll have a look at v4. > > Cristian > > > Thanks, > > Jyoti > > > > > > > > > > > > > > > > On Fri, Jan 22, 2021 at 5:37 AM Cristian Marussi > > wrote: > > > > > > Hi Jyoti, > > > > > > a few remarks below. > > > > > > On Thu, Jan 21, 2021 at 11:21:47PM +, Jyoti Bhayana wrote: > > > > This change provides ARM SCMI Protocol based IIO device. > > > > This driver provides support for Accelerometer and Gyroscope using > > > > new SCMI Sensor Protocol defined by the upcoming SCMIv3.0 > > > > > > I'd say: > > > > > > new SCMI Sensor Protocol extension added by the upcoming SCMIv3.0 > > > > > > given that SCMI Sensor existed already in SCMIv2.0 > > > > > > > ARM specification > > > > > > > > Signed-off-by: Jyoti Bhayana > > > > --- > > > > MAINTAINERS| 6 + > > > > drivers/iio/common/Kconfig | 1 + > > > > drivers/iio/common/Makefile| 1 + > > > > drivers/iio/common/scmi_sensors/Kconfig| 18 + > > > > drivers/iio/common/scmi_sensors/Makefile | 5 + > > > > drivers/iio/common/scmi_sensors/scmi_iio.c | 736 + > > > > 6 files changed, 767 insertions(+) > > > > create mode 100644 drivers/iio/common/scmi_sensors/Kconfig > > > > create mode 100644 drivers/iio/common/scmi_sensors/Makefile > > > > create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index b516bb34a8d5..ccf37d43ab41 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -8567,6 +8567,12 @@ S: Maintained > > > > F: > > > > Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt > > > > F: drivers/iio/multiplexer/iio-mux.c > > > > > > > > +I
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
Hi Jyoti, On Fri, Jan 29, 2021 at 02:43:13PM -0800, Jyoti Bhayana wrote: > Hi Christian, > > I have addressed your feedback in v4 of the patch. Please find below > the answers to some of your questions: > >The initial sensor_config ORed here is NOT initialized nor zeroed. > > There is no need to initialize as it is already initialized to 0 when > defined. > True for the sensor_config in scmi_iio_buffer_postdisable(), BUT it is not indeed zero-initialized at definition time in the other similar function scmi_iio_buffer_preenable(), that is what the above comment was referred to. > > being not so familiar with IIO, may I ask when and how much frequently > > these ops are called ? (given they include a register/unregister + > > enable/disable every time) > > These are called whenever the sensor is enabled/disabled by writing > to buffer/enable sysfs node > Ok, thanks. > >AFAIU this is called during IIO init and derives a modifier from the name > >of the sensors which are passed by the platform fw with sensor descriptors, > >so I would not trust them to be weell formed (:D) and try to be picky about > >*name as it was user-input to validate. > > The SCMI specification has mentioned the naming convention for the > axis as below . > "A NULL terminated UTF-8 format string with the sensor axis name, of > up to 16 bytes. It is recommended that the name ends with ‘_’ followed > by the axis of the sensor in uppercase. For example, the name for the > x-axis of a triaxial accelerometer could be “acc_X” or “_X” > > If there is any other better way to get the modifier, please let me know. > What I was trying to say was simply that, despite what the spec says, you cannot trust the fw/platform produced values (fw buggy ? data on channel corrupted ? malicious pkt injections ? fuzzing ? ) and so you should be picky and validate them also against any possible out-of-spec data, since the Kernel must not crash even if presented with unreasonable out-of-spec garbage-like data, thing that indeed you did in v4 by adding the check for NULL against name param. :D (the other case of a malformed name like "acc_" seemed to me handled properly already by the kernel strcmp) > > why not a break to a final 'return ret;' (with ret properly set) ? > > According to Jonathan, direct returns are preferred. > Ok > >Not familiar with IIO, but is it fine to setup ops and modes AFTER > >having attached the buffer to the scmi_iiodev ? > >Is is not 'racy-possible' that the buffer is already operational without > >any ops immediately after being attached ? > > I have looked at other IIO drivers and they all do it this way. > Ok. Thanks, I'll have a look at v4. Cristian > Thanks, > Jyoti > > > > > > > > On Fri, Jan 22, 2021 at 5:37 AM Cristian Marussi > wrote: > > > > Hi Jyoti, > > > > a few remarks below. > > > > On Thu, Jan 21, 2021 at 11:21:47PM +, Jyoti Bhayana wrote: > > > This change provides ARM SCMI Protocol based IIO device. > > > This driver provides support for Accelerometer and Gyroscope using > > > new SCMI Sensor Protocol defined by the upcoming SCMIv3.0 > > > > I'd say: > > > > new SCMI Sensor Protocol extension added by the upcoming SCMIv3.0 > > > > given that SCMI Sensor existed already in SCMIv2.0 > > > > > ARM specification > > > > > > Signed-off-by: Jyoti Bhayana > > > --- > > > MAINTAINERS| 6 + > > > drivers/iio/common/Kconfig | 1 + > > > drivers/iio/common/Makefile| 1 + > > > drivers/iio/common/scmi_sensors/Kconfig| 18 + > > > drivers/iio/common/scmi_sensors/Makefile | 5 + > > > drivers/iio/common/scmi_sensors/scmi_iio.c | 736 + > > > 6 files changed, 767 insertions(+) > > > create mode 100644 drivers/iio/common/scmi_sensors/Kconfig > > > create mode 100644 drivers/iio/common/scmi_sensors/Makefile > > > create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index b516bb34a8d5..ccf37d43ab41 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -8567,6 +8567,12 @@ S: Maintained > > > F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt > > > F: drivers/iio/multiplexer/iio-mux.c > > > > > > +IIO SCMI BASED DRIVER > > > +M: Jyoti Bhayana > > > +L: linux-...@vger.kernel.org > > > +S: Maintained > > > +F: drivers/iio/common/scmi_sensors/scmi_iio.c > > > + > > > IIO SUBSYSTEM AND DRIVERS > > > M: Jonathan Cameron > > > R: Lars-Peter Clausen > > > diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig > > > index 2b9ee9161abd..0334b4954773 100644 > > > --- a/drivers/iio/common/Kconfig > > > +++ b/drivers/iio/common/Kconfig > > > @@ -6,5 +6,6 @@ > > > source "drivers/iio/common/cros_ec_sensors/Kconfig" > > > source "drivers/iio/common/hid-sensors/Kconfig" > > > source "drivers/iio/common/ms_sensors/Kconfig" > > > +source "drivers/iio/common/scmi_senso
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
Hi Peter,
I have modified the comments in v4 of that patch. Regarding your
suggestion of this driver handling a greater value range
by adjusting the scale accordingly, it would also require the driver
to change the sensor readings as well based on the updated scale and
the accuracy of the sensor reading will be lost as the sensor readings
are 64 bit integers and not float.
If the IIO driver needs to support a 64 bit sensor range, then I would
prefer to add a new IIO val type for 64 bit fractional value which
takes 4 int vals: val_high,val_low, val2_high and val2_low.
Thanks,
Jyoti
On Tue, Jan 26, 2021 at 7:29 AM Peter Hilber
wrote:
>
> On 22.01.21 00:21, Jyoti Bhayana wrote:
>
>
>
> > +
> > +static int scmi_iio_get_sensor_max_range(struct iio_dev *iio_dev, int *val,
> > + int *val2)
> > +{
> > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > + int max_range_high, max_range_low;
> > + long long max_range;
> > +
> > + /*
> > + * All the axes are supposed to have the same value for max range.
> > + * We are just using the values from the Axis 0 here.
> > + */
> > + if (sensor->sensor_info->axis[0].extended_attrs) {
> > + max_range = sensor->sensor_info->axis[0].attrs.max_range;
> > + max_range_high = H32(max_range);
> > + max_range_low = L32(max_range);
> > +
> > + /*
> > + * As IIO Val types have no provision for 64 bit values,
> > + * and currently there are no known sensors using 64 bit
> > + * for the range, this driver only supports sensor with
> > + * 32 bit range value.
> > + */
> This comment and the corresponding one in
> scmi_iio_get_sensor_min_range() seem to be misleading to me. The extrema
> will probably exceed 32 bits even for physical sensors which do have
> less than 32 bits of resolution. The reason is that the SCMI sensor
> management protocol does not transmit a `scale' value as used by IIO.
> Instead, SCMI transmits an exponent with base ten.
>
> So, an SCMI sensor with a unit/LSB value which is not a power of ten
> will have its unit/LSB value split into an exponent (with base ten) and
> a mantissa.
>
> The SCMI platform (which exposes the physical sensor) will have to
> incorporate the mantissa into the sensor value. The simplest approach is
> to just multiply the mantissa with the raw physical sensor value, which
> will use more bits than the raw physical sensor value, depending on the
> unit/LSB value (and on the split of the unit/LSB value into exponent and
> mantissa).
>
> So I think the comment should at least make clear that the overflow may
> also happen for physical sensors with less than 32 bit of resolution,
> since it cannot be assumed that SCMI platforms will, without any
> apparent need, restrict the values to 32 bits, when that would mean
> additional complexity and potential loss of accuracy. (And in the long
> term this driver could IMHO try to handle a greater value range by
> adjusting the `scale' value accordingly.)
>
> Best regards,
>
> Peter
>
> > + if (max_range_high != 0)
> > + return -EINVAL;
> > +
> > + *val = max_range_low;
> > + *val2 = 1;
> > + }
> > + return 0;
> > +}
> > +
> > +static void scmi_iio_get_sensor_resolution(struct iio_dev *iio_dev, int
> > *val,
> > +int *val2)
> > +{
> > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > +
> > + /*
> > + * All the axes are supposed to have the same value for resolution
> > + * and exponent. We are just using the values from the Axis 0 here.
> > + */
> > + if (sensor->sensor_info->axis[0].extended_attrs) {
> > + uint resolution = sensor->sensor_info->axis[0].resolution;
> > + s8 exponent = sensor->sensor_info->axis[0].exponent;
> > + s8 scale = sensor->sensor_info->axis[0].scale;
> > +
> > + /*
> > + * To provide the raw value for the resolution to the
> > userspace,
> > + * need to divide the resolution exponent by the sensor scale
> > + */
> > + exponent = exponent - scale;
> > + if (exponent >= 0) {
> > + *val = resolution * int_pow(10, exponent);
> > + *val2 = 1;
> > + } else {
> > + *val = resolution;
> > + *val2 = int_pow(10, abs(exponent));
> > + }
> > + }
> > +}
> > +
> > +static int scmi_iio_get_sensor_min_range(struct iio_dev *iio_dev, int *val,
> > + int *val2)
> > +{
> > + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > + int min_range_high, min_range_low;
> > + long long min_range;
> > +
> > + /*
> > + * All the axes are supposed to have the same value for min range.
> > + * We are just
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
Hi Christian, I have addressed your feedback in v4 of the patch. Please find below the answers to some of your questions: >The initial sensor_config ORed here is NOT initialized nor zeroed. There is no need to initialize as it is already initialized to 0 when defined. > being not so familiar with IIO, may I ask when and how much frequently > these ops are called ? (given they include a register/unregister + > enable/disable every time) These are called whenever the sensor is enabled/disabled by writing to buffer/enable sysfs node >AFAIU this is called during IIO init and derives a modifier from the name >of the sensors which are passed by the platform fw with sensor descriptors, >so I would not trust them to be weell formed (:D) and try to be picky about >*name as it was user-input to validate. The SCMI specification has mentioned the naming convention for the axis as below . "A NULL terminated UTF-8 format string with the sensor axis name, of up to 16 bytes. It is recommended that the name ends with ‘_’ followed by the axis of the sensor in uppercase. For example, the name for the x-axis of a triaxial accelerometer could be “acc_X” or “_X” If there is any other better way to get the modifier, please let me know. > why not a break to a final 'return ret;' (with ret properly set) ? According to Jonathan, direct returns are preferred. >Not familiar with IIO, but is it fine to setup ops and modes AFTER >having attached the buffer to the scmi_iiodev ? >Is is not 'racy-possible' that the buffer is already operational without >any ops immediately after being attached ? I have looked at other IIO drivers and they all do it this way. Thanks, Jyoti On Fri, Jan 22, 2021 at 5:37 AM Cristian Marussi wrote: > > Hi Jyoti, > > a few remarks below. > > On Thu, Jan 21, 2021 at 11:21:47PM +, Jyoti Bhayana wrote: > > This change provides ARM SCMI Protocol based IIO device. > > This driver provides support for Accelerometer and Gyroscope using > > new SCMI Sensor Protocol defined by the upcoming SCMIv3.0 > > I'd say: > > new SCMI Sensor Protocol extension added by the upcoming SCMIv3.0 > > given that SCMI Sensor existed already in SCMIv2.0 > > > ARM specification > > > > Signed-off-by: Jyoti Bhayana > > --- > > MAINTAINERS| 6 + > > drivers/iio/common/Kconfig | 1 + > > drivers/iio/common/Makefile| 1 + > > drivers/iio/common/scmi_sensors/Kconfig| 18 + > > drivers/iio/common/scmi_sensors/Makefile | 5 + > > drivers/iio/common/scmi_sensors/scmi_iio.c | 736 + > > 6 files changed, 767 insertions(+) > > create mode 100644 drivers/iio/common/scmi_sensors/Kconfig > > create mode 100644 drivers/iio/common/scmi_sensors/Makefile > > create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index b516bb34a8d5..ccf37d43ab41 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -8567,6 +8567,12 @@ S: Maintained > > F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt > > F: drivers/iio/multiplexer/iio-mux.c > > > > +IIO SCMI BASED DRIVER > > +M: Jyoti Bhayana > > +L: linux-...@vger.kernel.org > > +S: Maintained > > +F: drivers/iio/common/scmi_sensors/scmi_iio.c > > + > > IIO SUBSYSTEM AND DRIVERS > > M: Jonathan Cameron > > R: Lars-Peter Clausen > > diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig > > index 2b9ee9161abd..0334b4954773 100644 > > --- a/drivers/iio/common/Kconfig > > +++ b/drivers/iio/common/Kconfig > > @@ -6,5 +6,6 @@ > > source "drivers/iio/common/cros_ec_sensors/Kconfig" > > source "drivers/iio/common/hid-sensors/Kconfig" > > source "drivers/iio/common/ms_sensors/Kconfig" > > +source "drivers/iio/common/scmi_sensors/Kconfig" > > source "drivers/iio/common/ssp_sensors/Kconfig" > > source "drivers/iio/common/st_sensors/Kconfig" > > diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile > > index 4bc30bb548e2..fad40e1e1718 100644 > > --- a/drivers/iio/common/Makefile > > +++ b/drivers/iio/common/Makefile > > @@ -11,5 +11,6 @@ > > obj-y += cros_ec_sensors/ > > obj-y += hid-sensors/ > > obj-y += ms_sensors/ > > +obj-y += scmi_sensors/ > > obj-y += ssp_sensors/ > > obj-y += st_sensors/ > > diff --git a/drivers/iio/common/scmi_sensors/Kconfig > > b/drivers/iio/common/scmi_sensors/Kconfig > > new file mode 100644 > > index ..67e084cbb1ab > > --- /dev/null > > +++ b/drivers/iio/common/scmi_sensors/Kconfig > > @@ -0,0 +1,18 @@ > > +# > > +# IIO over SCMI > > +# > > +# When adding new entries keep the list in alphabetical order > > + > > +menu "IIO SCMI Sensors" > > + > > +config IIO_SCMI > > + tristate "IIO SCMI" > > +depends on ARM_SCMI_PROTOCOL > > +select IIO_BUFFER > > +select IIO_KFIFO_BUF > > + help > > + Say yes here to build support for IIO SCMI Driver. > > + This provides ARM
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
On 22.01.21 00:21, Jyoti Bhayana wrote:
> +
> +static int scmi_iio_get_sensor_max_range(struct iio_dev *iio_dev, int *val,
> + int *val2)
> +{
> + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> + int max_range_high, max_range_low;
> + long long max_range;
> +
> + /*
> + * All the axes are supposed to have the same value for max range.
> + * We are just using the values from the Axis 0 here.
> + */
> + if (sensor->sensor_info->axis[0].extended_attrs) {
> + max_range = sensor->sensor_info->axis[0].attrs.max_range;
> + max_range_high = H32(max_range);
> + max_range_low = L32(max_range);
> +
> + /*
> + * As IIO Val types have no provision for 64 bit values,
> + * and currently there are no known sensors using 64 bit
> + * for the range, this driver only supports sensor with
> + * 32 bit range value.
> + */
This comment and the corresponding one in
scmi_iio_get_sensor_min_range() seem to be misleading to me. The extrema
will probably exceed 32 bits even for physical sensors which do have
less than 32 bits of resolution. The reason is that the SCMI sensor
management protocol does not transmit a `scale' value as used by IIO.
Instead, SCMI transmits an exponent with base ten.
So, an SCMI sensor with a unit/LSB value which is not a power of ten
will have its unit/LSB value split into an exponent (with base ten) and
a mantissa.
The SCMI platform (which exposes the physical sensor) will have to
incorporate the mantissa into the sensor value. The simplest approach is
to just multiply the mantissa with the raw physical sensor value, which
will use more bits than the raw physical sensor value, depending on the
unit/LSB value (and on the split of the unit/LSB value into exponent and
mantissa).
So I think the comment should at least make clear that the overflow may
also happen for physical sensors with less than 32 bit of resolution,
since it cannot be assumed that SCMI platforms will, without any
apparent need, restrict the values to 32 bits, when that would mean
additional complexity and potential loss of accuracy. (And in the long
term this driver could IMHO try to handle a greater value range by
adjusting the `scale' value accordingly.)
Best regards,
Peter
> + if (max_range_high != 0)
> + return -EINVAL;
> +
> + *val = max_range_low;
> + *val2 = 1;
> + }
> + return 0;
> +}
> +
> +static void scmi_iio_get_sensor_resolution(struct iio_dev *iio_dev, int *val,
> +int *val2)
> +{
> + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> +
> + /*
> + * All the axes are supposed to have the same value for resolution
> + * and exponent. We are just using the values from the Axis 0 here.
> + */
> + if (sensor->sensor_info->axis[0].extended_attrs) {
> + uint resolution = sensor->sensor_info->axis[0].resolution;
> + s8 exponent = sensor->sensor_info->axis[0].exponent;
> + s8 scale = sensor->sensor_info->axis[0].scale;
> +
> + /*
> + * To provide the raw value for the resolution to the userspace,
> + * need to divide the resolution exponent by the sensor scale
> + */
> + exponent = exponent - scale;
> + if (exponent >= 0) {
> + *val = resolution * int_pow(10, exponent);
> + *val2 = 1;
> + } else {
> + *val = resolution;
> + *val2 = int_pow(10, abs(exponent));
> + }
> + }
> +}
> +
> +static int scmi_iio_get_sensor_min_range(struct iio_dev *iio_dev, int *val,
> + int *val2)
> +{
> + struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> + int min_range_high, min_range_low;
> + long long min_range;
> +
> + /*
> + * All the axes are supposed to have the same value for min range.
> + * We are just using the values from the Axis 0 here.
> + */
> + if (sensor->sensor_info->axis[0].extended_attrs) {
> + min_range = sensor->sensor_info->axis[0].attrs.min_range;
> + min_range_high = H32(min_range);
> + min_range_low = L32(min_range);
> +
> + /*
> + * As IIO Val types have no provision for 64 bit values,
> + * and currently there are no known sensors using 64 bit
> + * for the range, this driver only supports sensor with
> + * 32 bit range value.
> + */
> + if (min_range_high != 0x)
> + return -EINVAL;
> +
> + *val = min_range_low;
> + *val2 = 1;
> + }
> + return 0;
> +}
> +
> +static int scmi_iio_set_sensor_range_avail(struct iio_dev *iio_dev)
> +{
> +
Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
Hi Jyoti,
a few remarks below.
On Thu, Jan 21, 2021 at 11:21:47PM +, Jyoti Bhayana wrote:
> This change provides ARM SCMI Protocol based IIO device.
> This driver provides support for Accelerometer and Gyroscope using
> new SCMI Sensor Protocol defined by the upcoming SCMIv3.0
I'd say:
new SCMI Sensor Protocol extension added by the upcoming SCMIv3.0
given that SCMI Sensor existed already in SCMIv2.0
> ARM specification
>
> Signed-off-by: Jyoti Bhayana
> ---
> MAINTAINERS| 6 +
> drivers/iio/common/Kconfig | 1 +
> drivers/iio/common/Makefile| 1 +
> drivers/iio/common/scmi_sensors/Kconfig| 18 +
> drivers/iio/common/scmi_sensors/Makefile | 5 +
> drivers/iio/common/scmi_sensors/scmi_iio.c | 736 +
> 6 files changed, 767 insertions(+)
> create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
> create mode 100644 drivers/iio/common/scmi_sensors/Makefile
> create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b516bb34a8d5..ccf37d43ab41 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8567,6 +8567,12 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
> F: drivers/iio/multiplexer/iio-mux.c
>
> +IIO SCMI BASED DRIVER
> +M: Jyoti Bhayana
> +L: linux-...@vger.kernel.org
> +S: Maintained
> +F: drivers/iio/common/scmi_sensors/scmi_iio.c
> +
> IIO SUBSYSTEM AND DRIVERS
> M: Jonathan Cameron
> R: Lars-Peter Clausen
> diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
> index 2b9ee9161abd..0334b4954773 100644
> --- a/drivers/iio/common/Kconfig
> +++ b/drivers/iio/common/Kconfig
> @@ -6,5 +6,6 @@
> source "drivers/iio/common/cros_ec_sensors/Kconfig"
> source "drivers/iio/common/hid-sensors/Kconfig"
> source "drivers/iio/common/ms_sensors/Kconfig"
> +source "drivers/iio/common/scmi_sensors/Kconfig"
> source "drivers/iio/common/ssp_sensors/Kconfig"
> source "drivers/iio/common/st_sensors/Kconfig"
> diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
> index 4bc30bb548e2..fad40e1e1718 100644
> --- a/drivers/iio/common/Makefile
> +++ b/drivers/iio/common/Makefile
> @@ -11,5 +11,6 @@
> obj-y += cros_ec_sensors/
> obj-y += hid-sensors/
> obj-y += ms_sensors/
> +obj-y += scmi_sensors/
> obj-y += ssp_sensors/
> obj-y += st_sensors/
> diff --git a/drivers/iio/common/scmi_sensors/Kconfig
> b/drivers/iio/common/scmi_sensors/Kconfig
> new file mode 100644
> index ..67e084cbb1ab
> --- /dev/null
> +++ b/drivers/iio/common/scmi_sensors/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# IIO over SCMI
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "IIO SCMI Sensors"
> +
> +config IIO_SCMI
> + tristate "IIO SCMI"
> +depends on ARM_SCMI_PROTOCOL
> +select IIO_BUFFER
> +select IIO_KFIFO_BUF
> + help
> + Say yes here to build support for IIO SCMI Driver.
> + This provides ARM SCMI Protocol based IIO device.
> + This driver provides support for accelerometer and gyroscope
> + sensors available on SCMI based platforms.
> +endmenu
> diff --git a/drivers/iio/common/scmi_sensors/Makefile
> b/drivers/iio/common/scmi_sensors/Makefile
> new file mode 100644
> index ..f13140a2575a
> --- /dev/null
> +++ b/drivers/iio/common/scmi_sensors/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX - License - Identifier : GPL - 2.0 - only
> +#
> +# Makefile for the IIO over SCMI
> +#
> +obj-$(CONFIG_IIO_SCMI) += scmi_iio.o
> diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c
> b/drivers/iio/common/scmi_sensors/scmi_iio.c
> new file mode 100644
> index ..3b76cc54511c
> --- /dev/null
> +++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
> @@ -0,0 +1,736 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * System Control and Management Interface(SCMI) based IIO sensor driver
> + *
> + * Copyright (C) 2020 Google LLC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ilog10(x) (ilog2(x) / const_ilog2(10))
> +#define UHZ_PER_HZ 100UL
> +#define ODR_EXPAND(odr, uodr) (((odr) * 100ULL) + (uodr))
> +#define MAX_NUM_OF_CHANNELS 4
> +#define H32(x) (((x) & 0xLL) >> 32)
> +#define L32(x) ((x) & 0xLL)
Probaly you want to use GENMASK here to define the masks, and not sure
but maybe there are already similar macros in linux to extract
upper/lower 32 bits.
> +
> +struct scmi_iio_priv {
> + struct scmi_handle *handle;
> + const struct scmi_sensor_info *sensor_info;
> + struct iio_dev *indio_dev;
> + long long iio_buf[MAX_NUM_OF_CHANNELS];
> + struct notifier_block sensor_update_nb;
> + u32 *freq_avail;
> + /*
> + * range_avail = [minRange resolution maxRange]
> + *
[RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors
This change provides ARM SCMI Protocol based IIO device.
This driver provides support for Accelerometer and Gyroscope using
new SCMI Sensor Protocol defined by the upcoming SCMIv3.0
ARM specification
Signed-off-by: Jyoti Bhayana
---
MAINTAINERS| 6 +
drivers/iio/common/Kconfig | 1 +
drivers/iio/common/Makefile| 1 +
drivers/iio/common/scmi_sensors/Kconfig| 18 +
drivers/iio/common/scmi_sensors/Makefile | 5 +
drivers/iio/common/scmi_sensors/scmi_iio.c | 736 +
6 files changed, 767 insertions(+)
create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
create mode 100644 drivers/iio/common/scmi_sensors/Makefile
create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b516bb34a8d5..ccf37d43ab41 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8567,6 +8567,12 @@ S: Maintained
F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
F: drivers/iio/multiplexer/iio-mux.c
+IIO SCMI BASED DRIVER
+M: Jyoti Bhayana
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/common/scmi_sensors/scmi_iio.c
+
IIO SUBSYSTEM AND DRIVERS
M: Jonathan Cameron
R: Lars-Peter Clausen
diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
index 2b9ee9161abd..0334b4954773 100644
--- a/drivers/iio/common/Kconfig
+++ b/drivers/iio/common/Kconfig
@@ -6,5 +6,6 @@
source "drivers/iio/common/cros_ec_sensors/Kconfig"
source "drivers/iio/common/hid-sensors/Kconfig"
source "drivers/iio/common/ms_sensors/Kconfig"
+source "drivers/iio/common/scmi_sensors/Kconfig"
source "drivers/iio/common/ssp_sensors/Kconfig"
source "drivers/iio/common/st_sensors/Kconfig"
diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
index 4bc30bb548e2..fad40e1e1718 100644
--- a/drivers/iio/common/Makefile
+++ b/drivers/iio/common/Makefile
@@ -11,5 +11,6 @@
obj-y += cros_ec_sensors/
obj-y += hid-sensors/
obj-y += ms_sensors/
+obj-y += scmi_sensors/
obj-y += ssp_sensors/
obj-y += st_sensors/
diff --git a/drivers/iio/common/scmi_sensors/Kconfig
b/drivers/iio/common/scmi_sensors/Kconfig
new file mode 100644
index ..67e084cbb1ab
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/Kconfig
@@ -0,0 +1,18 @@
+#
+# IIO over SCMI
+#
+# When adding new entries keep the list in alphabetical order
+
+menu "IIO SCMI Sensors"
+
+config IIO_SCMI
+ tristate "IIO SCMI"
+depends on ARM_SCMI_PROTOCOL
+select IIO_BUFFER
+select IIO_KFIFO_BUF
+ help
+ Say yes here to build support for IIO SCMI Driver.
+ This provides ARM SCMI Protocol based IIO device.
+ This driver provides support for accelerometer and gyroscope
+ sensors available on SCMI based platforms.
+endmenu
diff --git a/drivers/iio/common/scmi_sensors/Makefile
b/drivers/iio/common/scmi_sensors/Makefile
new file mode 100644
index ..f13140a2575a
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/Makefile
@@ -0,0 +1,5 @@
+# SPDX - License - Identifier : GPL - 2.0 - only
+#
+# Makefile for the IIO over SCMI
+#
+obj-$(CONFIG_IIO_SCMI) += scmi_iio.o
diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c
b/drivers/iio/common/scmi_sensors/scmi_iio.c
new file mode 100644
index ..3b76cc54511c
--- /dev/null
+++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
@@ -0,0 +1,736 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * System Control and Management Interface(SCMI) based IIO sensor driver
+ *
+ * Copyright (C) 2020 Google LLC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ilog10(x) (ilog2(x) / const_ilog2(10))
+#define UHZ_PER_HZ 100UL
+#define ODR_EXPAND(odr, uodr) (((odr) * 100ULL) + (uodr))
+#define MAX_NUM_OF_CHANNELS 4
+#define H32(x) (((x) & 0xLL) >> 32)
+#define L32(x) ((x) & 0xLL)
+
+struct scmi_iio_priv {
+ struct scmi_handle *handle;
+ const struct scmi_sensor_info *sensor_info;
+ struct iio_dev *indio_dev;
+ long long iio_buf[MAX_NUM_OF_CHANNELS];
+ struct notifier_block sensor_update_nb;
+ u32 *freq_avail;
+ /*
+* range_avail = [minRange resolution maxRange]
+* with IIO val type as IIO_VAL_FRACTIONAL.
+* Hence, array of size 6.
+*/
+ int range_avail[6];
+};
+
+static int scmi_iio_sensor_update_cb(struct notifier_block *nb,
+unsigned long event, void *data)
+{
+ struct scmi_sensor_update_report *sensor_update = data;
+ struct iio_dev *scmi_iio_dev;
+ struct scmi_iio_priv *sensor;
+ s8 tstamp_scale;
+ u64 time, time_ns;
+ int i;
+
+ if (sensor_update->readings_count == 0)
+ return NOTIFY_DONE;
+
+ sensor = container_of(nb, struct scmi_iio_priv, sensor_up
