From: Arnav Kapoor <kapoorarnav43@gmail.com>
To: Rupesh Majhi <zoone.rupert@gmail.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Eddie James" <eajames@linux.ibm.com>,
"Jonathan Cameron" <jonathan.cameron@oss.qualcomm.com>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iio: pressure: dps310: don't wait for new temperature in trigger handler
Date: Fri, 13 Nov 2026 03:19:29 +0530 [thread overview]
Message-ID: <20261112214929.497589-1-kapoorarnav43@gmail.com> (raw)
In-Reply-To: <20261111195118.36853-1-zoone.rupert@gmail.com>
On Wed, Nov 11, 2026 at 09:51:18PM +0200, Rupesh Majhi wrote:
> + if (test_bit(DPS310_SCAN_PRESSURE, scan_mask)) {
> + rc = dps310_read_pres_raw_locked(data);
> + if (rc)
> + return rc;
> +
> + /* Waiting here would hold scans to the temperature rate */
> + dps310_refresh_temp_locked(data);
Maybe I'm getting this wrong, but isn't there a case the new path
doesn't cover? Nothing reads a temperature at probe, so if a pressure
only buffer is enabled shortly after probe and the first pressure
result is ready before any temperature result,
dps310_refresh_temp_locked() finds TMP_RDY clear and the pressure is
compensated with temp_raw still 0.
I think the FIFO path handles this case by dps310_fifo_hold() keeping
pressure entries until fifo_temp_valid is set by the first
temperature. Would it make sense to do the same here with a flag set
when a temperature has been read, and wait for one temperature in
dps310_refresh_temp_locked() only while it's unset? That would cover
direct pressure reads and after the first sample the scans stay at the
pressure rate as your patch intends.
Thanks,
Arnav
prev parent reply other threads:[~2026-11-12 21:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 19:51 Rupesh Majhi
2026-11-12 21:49 ` Arnav Kapoor [this message]
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=20261112214929.497589-1-kapoorarnav43@gmail.com \
--to=kapoorarnav43@gmail.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=eajames@linux.ibm.com \
--cc=jic23@kernel.org \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=zoone.rupert@gmail.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
all inboxes | Powered by JetHome®