From: Vasileios Amoiridis <vassilisamir@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: lars@metafoo.de, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, andriy.shevchenko@linux.intel.com,
ang.iglesiasg@gmail.com, linus.walleij@linaro.org,
biju.das.jz@bp.renesas.com, javier.carrasco.cruz@gmail.com,
semen.protsenko@linaro.org, 579lpy@gmail.com, ak@it-klinger.de,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, christophe.jaillet@wanadoo.fr
Subject: Re: [PATCH v8 3/4] iio: pressure: bmp280: Add data ready trigger support
Date: Mon, 14 Oct 2024 22:10:06 +0200 [thread overview]
Message-ID: <Zw16nvYqbYFD8rpY@vamoirid-laptop> (raw)
In-Reply-To: <20241012170823.3c6d3df9@jic23-huawei>
On Sat, Oct 12, 2024 at 05:08:23PM +0100, Jonathan Cameron wrote:
> On Mon, 7 Oct 2024 21:49:44 +0200
> Vasileios Amoiridis <vassilisamir@gmail.com> wrote:
>
> > The BMP3xx and BMP5xx sensors have an interrupt pin which can be used as
> > a trigger for when there are data ready in the sensor for pick up.
> >
> > This use case is used along with NORMAL_MODE in the sensor, which allows
> > the sensor to do consecutive measurements depending on the ODR rate value.
> >
> > The trigger pin can be configured to be open-drain or push-pull and either
> > rising or falling edge.
> >
> > No support is added yet for interrupts for FIFO, WATERMARK and out of range
> > values.
> >
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Vasileios Amoiridis <vassilisamir@gmail.com>
>
> Hi Vasileios,
>
> One questing about locking below. What you have is probably correct
> but might be tighter than it needs to be, or need a comment to say why
> for future readers.
>
> I hate register reads with side effects btw. It's an 'optimization'
> hardware designers thing is nice, but makes for really ugly software
> interfaces.
>
Hi Jonathan,
> > @@ -2429,6 +2564,88 @@ static int bmp580_chip_config(struct bmp280_data *data)
> > return 0;
> > }
> >
> > +static void bmp580_trigger_reenable(struct iio_trigger *trig)
> > +{
> > + struct bmp280_data *data = iio_trigger_get_drvdata(trig);
> > + unsigned int tmp;
> > + int ret;
> > +
> > + ret = regmap_read(data->regmap, BMP580_REG_INT_STATUS, &tmp);
> As below. Seems this read has side effects (horrible!)
> I'm not sure if this is related to the locking though.
Yes indeed, this read is needed in order to clear the interrupt. In that
way the interrupt is kind of resetted so it can get triggered again. It
is actually the 1st line in page 28 of [1].
[1]: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmp585-ds003.pdf
> > + if (ret)
> > + dev_err(data->dev, "Failed to reset interrupt.\n");
> > +}
>
> > +static int bmp580_int_pin_config(struct bmp280_data *data)
> > +{
> > + int pin_drive_cfg = FIELD_PREP(BMP580_INT_CONFIG_OPEN_DRAIN,
> > + data->trig_open_drain);
> > + int pin_level_cfg = FIELD_PREP(BMP580_INT_CONFIG_LEVEL,
> > + data->trig_active_high);
> > + int ret, int_pin_cfg = pin_drive_cfg | pin_level_cfg;
> int int_pin_cfg = pin...
> int ret;
>
> Is easier to follow.
>
ACK.
> > +
> > + ret = regmap_update_bits(data->regmap, BMP580_REG_INT_CONFIG,
> > + BMP580_INT_CONFIG_MASK, int_pin_cfg);
> > + if (ret) {
> > + dev_err(data->dev, "Could not set interrupt settings.\n");
> > + return ret;
> > + }
> > +
> > + ret = regmap_set_bits(data->regmap, BMP580_REG_INT_SOURCE,
> > + BMP580_INT_SOURCE_DRDY);
> > + if (ret)
> > + dev_err(data->dev, "Could not set interrupt source.\n");
> > +
> > + return ret;
> > +}
> > +
> > +static irqreturn_t bmp580_irq_thread_handler(int irq, void *p)
> > +{
> > + struct iio_dev *indio_dev = p;
> > + struct bmp280_data *data = iio_priv(indio_dev);
> > + unsigned int int_ctrl;
> > + int ret;
> > +
> > + scoped_guard(mutex, &data->lock) {
> > + ret = regmap_read(data->regmap, BMP580_REG_INT_STATUS, &int_ctrl);
> What are you locking against here? Seems this read may have side effects?
> If not the regmap internal locking should be enough for a register read.
I had a 2nd look and the lock is redundant indeed. This came from the
fact that I use the lock in the oneshot captures becasue when we do
reads of pressure or humidity (BME280) measurements, the temp regs are
read first, they are processed and later the pressure/humidity regs are
read so this operation should be kept serialized. But here there is no
problem.
Cheers,
Vasilis
> > + if (ret)
> > + return IRQ_NONE;
> > + }
>
>
next prev parent reply other threads:[~2024-10-14 20:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 19:49 [PATCH v8 0/4] pressure: bmp280: Minor cleanup and interrupt support Vasileios Amoiridis
2024-10-07 19:49 ` [PATCH v8 1/4] iio: pressure: bmp280: Use sleep and forced mode for oneshot captures Vasileios Amoiridis
2024-10-11 4:32 ` kernel test robot
2024-10-11 10:53 ` Andy Shevchenko
2024-10-11 17:35 ` Vasileios Aoiridis
2024-10-12 16:03 ` Jonathan Cameron
2024-10-14 19:50 ` Vasileios Amoiridis
2024-10-07 19:49 ` [PATCH v8 2/4] dt-bindings: iio: pressure: bmp085: Add interrupts for BMP3xx and BMP5xx devices Vasileios Amoiridis
2024-10-07 19:49 ` [PATCH v8 3/4] iio: pressure: bmp280: Add data ready trigger support Vasileios Amoiridis
2024-10-12 16:08 ` Jonathan Cameron
2024-10-14 20:10 ` Vasileios Amoiridis [this message]
2024-10-07 19:49 ` [PATCH v8 4/4] iio: pressure: bmp280: Move bmp085 interrupt to new configuration Vasileios Amoiridis
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=Zw16nvYqbYFD8rpY@vamoirid-laptop \
--to=vassilisamir@gmail.com \
--cc=579lpy@gmail.com \
--cc=ak@it-klinger.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ang.iglesiasg@gmail.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=javier.carrasco.cruz@gmail.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=semen.protsenko@linaro.org \
/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