From: Jyoti Bhayana <jbhayana@google.com>
To: Vasyl Vavrychuk <vasyl.vavrychuk@opensynergy.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
Jonathan Cameron <jic23@kernel.org>,
Andriy Tryshnivskyy <andriy.tryshnivskyy@opensynergy.com>
Subject: Re: [PATCH v3 0/1] iio/scmi: Add reading "raw" attribute.
Date: Tue, 5 Oct 2021 17:16:21 -0700 [thread overview]
Message-ID: <CA+=V6c10xE-1uUzGWusBiGVMV2Fwy93dGGHA9FH0PC4tYggVUQ@mail.gmail.com> (raw)
In-Reply-To: <650ec3b8-c970-604c-9be6-577c46d3e762@opensynergy.com>
Hi Vasyl,
Regarding below question, yes reading raw attribute should be blocked
if buffer is enabled for that sensor.
> 1. Should we block reading raw attribute and IIO buffer enabled, for for
> SCMI sensor it can coexist?
PLease see https://elixir.bootlin.com/linux/latest/source/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c#L667
as well. It has
case IIO_CHAN_INFO_RAW:
ret = iio_device_claim_direct_mode(indio_dev);
if (ret)
return ret;
mutex_lock(&st->lock);
ret = inv_mpu6050_read_channel_data(indio_dev, chan, val);
mutex_unlock(&st->lock);
iio_device_release_direct_mode(indio_dev);
return ret;
Regarding the question below, the answer is yes.
> 2. Should we wrap reading raw attribute implementation in iio_dev->mlock
> mutex?
Thanks, Jyoti
On Tue, Oct 5, 2021 at 5:52 AM Vasyl Vavrychuk
<vasyl.vavrychuk@opensynergy.com> wrote:
>
> Hi, Jyoti,
>
> > In the code below, why is the logic of enabling and disabling the
> > sensor in this function? Generally the function to read the sensor
> > value is just used for the code to read the sensor values ? and not
> > enable/disable the sensor
>
> But to read sensor value we have to enable it first. Other way to enable
> sensor we found is, for example:
>
> echo 1 > /sys/bus/iio/devices/.../scan_elements/in_anglvel_x_en
>
> But, this command is related to IIO buffers use.
>
> Other sensors drivers enable/disable sensor in read raw too, for
> example, drivers/iio/accel/kxcjk-1013.c has:
>
> case IIO_CHAN_INFO_RAW:
> mutex_lock(&data->mutex);
> if (iio_buffer_enabled(indio_dev))
> ret = -EBUSY;
> else {
> ret = kxcjk1013_set_power_state(data, true);
> ... reading ...
> ret = kxcjk1013_set_power_state(data, false);
> }
> mutex_unlock(&data->mutex);
>
> But, after looking on this code I have some questions:
>
> 1. Should we block reading raw attribute and IIO buffer enabled, for for
> SCMI sensor it can coexist?
> 2. Should we wrap reading raw attribute implementation in iio_dev->mlock
> mutex?
>
> >> case IIO_CHAN_INFO_RAW:
> >> + sensor_config = FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
> >> + SCMI_SENS_CFG_SENSOR_ENABLE);
> >> + err = sensor->sensor_ops->config_set(
> >> + sensor->ph, sensor->sensor_info->id, sensor_config);
> >> + if (err) {
> >> + dev_err(&iio_dev->dev,
> >> + "Error in enabling sensor %s err %d",
> >> + sensor->sensor_info->name, err);
> >> + return err;
> >> + }
> >> +
> >> + err = sensor->sensor_ops->reading_get_timestamped(
> >> + sensor->ph, sensor->sensor_info->id,
> >> + sensor->sensor_info->num_axis, readings);
> >> + if (err) {
> >> + dev_err(&iio_dev->dev,
> >> + "Error in reading raw attribute for sensor %s err %d",
> >> + sensor->sensor_info->name, err);
> >> + return err;
> >> + }
> >> +
> >> + sensor_config = FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
> >> + SCMI_SENS_CFG_SENSOR_DISABLE);
> >> + err = sensor->sensor_ops->config_set(
> >> + sensor->ph, sensor->sensor_info->id, sensor_config);
> >> + if (err) {
> >> + dev_err(&iio_dev->dev,
> >> + "Error in enabling sensor %s err %d",
> >> + sensor->sensor_info->name, err);
> >> + return err;
> >> + }
> >> + /* Check if raw value fits 32 bits */
> >> + if (readings[ch->scan_index].value < INT_MIN ||
> >> + readings[ch->scan_index].value > INT_MAX)
> >> + return -ERANGE;
> >> + /* Use 32-bit value, since practically there is no need in 64 bits */
> >> + *val = (int)readings[ch->scan_index].value;
> >>
> >> + return IIO_VAL_INT;
next prev parent reply other threads:[~2021-10-06 0:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 16:19 [PATCH v3 0/1] iio/scmi: Add reading "raw" attribute Andriy Tryshnivskyy
2021-09-28 16:19 ` [PATCH v3 1/1] " Andriy Tryshnivskyy
2021-09-30 16:40 ` [PATCH v3 0/1] " Jonathan Cameron
2021-10-04 23:51 ` Jyoti Bhayana
2021-10-05 12:51 ` Vasyl Vavrychuk
2021-10-06 0:16 ` Jyoti Bhayana [this message]
2021-10-08 11:32 ` Andriy Tryshnivskyy
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='CA+=V6c10xE-1uUzGWusBiGVMV2Fwy93dGGHA9FH0PC4tYggVUQ@mail.gmail.com' \
--to=jbhayana@google.com \
--cc=andriy.tryshnivskyy@opensynergy.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vasyl.vavrychuk@opensynergy.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;
as well as URLs for NNTP newsgroup(s).