Linux IIO development
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Rupesh Majhi <zoone.rupert@gmail.com>
Cc: linux-iio@vger.kernel.org, eajames@linux.ibm.com
Subject: Re: [PATCH] iio: pressure: dps310: add FIFO support
Date: Mon, 18 May 2026 19:58:38 +0100	[thread overview]
Message-ID: <20260518195838.7afa1808@jic23-huawei> (raw)
In-Reply-To: <20260518165320.1301071-1-zoone.rupert@gmail.com>

On Mon, 18 May 2026 19:53:20 +0300
Rupesh Majhi <zoone.rupert@gmail.com> wrote:

> The DPS310 has a 32-sample hardware FIFO that buffers interleaved
> pressure and temperature measurements in background mode. The FIFO_EN
> bit was already defined but unused.
> 
> Add register defines for the FIFO status register and sample type
> encoding, implement FIFO enabled/flush helpers, and wire FIFO initialization
> into the probe path after dps310_startup() has established background
> measurement mode.
> 
> FIFO initialization failure is treated as non-fatal so the driver continues
> to operate via single reads if FIFO enable fails.

I'm not sure I understand why one would enable this?  You've not
modified any of the reading paths. Normally we'd expect a hardware fifo
to be connected up to an IIO buffered interface (via chrdev) and provide
things like watermark control.

There are lots of examples in tree of how to handle fifos. This seems
to be maybe the 1st 5% of what's needed.  Was it perhaps meant to be
an RFC with some questions?

Jonathan

> 
> Signed-off-by: Rupesh Majhi <zoone.rupert@gmail.com>
> ---
>  drivers/iio/pressure/dps310.c | 73 +++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 
> diff --git a/drivers/iio/pressure/dps310.c b/drivers/iio/pressure/dps310.c
> index 8edaa4d10a70..5b031c9573d0 100644
> --- a/drivers/iio/pressure/dps310.c
> +++ b/drivers/iio/pressure/dps310.c
> @@ -53,6 +53,19 @@
>  #define  DPS310_PRS_SHIFT_EN	BIT(4)
>  #define  DPS310_FIFO_EN		BIT(5)
>  #define  DPS310_SPI_EN		BIT(6)
> +/* FIFO status register */
> +#define DPS310_FIFO_STS		0x0B
> +#define DPS310_FIFO_EMPTY	BIT(0)
> +#define DPS310_FIFO_FULL	BIT(1)
> +
> +/* FIFO samples are read from DPS310_PRS_BASE (0x00). The lower 2 bits

Wrong comment style.

> + * of the third byte encode the sample type; the remaining bits are
> + * the signed measurement value.
> + */
> +#define DPS310_FIFO_TYPE_MASK	GENMASK(0, 0)

Smells like a BIT(0)  We don't use genmask for single bits.
However, you mention 2 bits.



> +#define DPS310_FIFO_TMP_SAMPLE	0x00
> +#define DPS310_FIFO_PRS_SAMPLE	0x01
If it's only 2 bits (or maybe 1?) then 0  / 1 
is fine.

> +
>  #define DPS310_RESET		0x0c
>  #define  DPS310_RESET_MAGIC	0x09
>  #define DPS310_COEF_BASE	0x10
> @@ -90,6 +103,7 @@ struct dps310_data {
>  	s32 pressure_raw;
>  	s32 temp_raw;
>  	bool timeout_recovery_failed;
> +	bool fifo_enabled;
>  };
>  
>  static const struct iio_chan_spec dps310_channels[] = {
> @@ -843,6 +857,61 @@ static const struct iio_info dps310_info = {
>  	.write_raw = dps310_write_raw,
>  };
>  
> +static int dps310_fifo_flush(struct dps310_data *data)
> +{
> +	int rc;
> +
> +	rc = regmap_write_bits(data->regmap, DPS310_CFG_REG,
> +			DPS310_FIFO_EN, 0);
> +	if (rc)
> +		return rc;
> +
> +	data->fifo_enabled = false;
> +	return 0;
> +}
> +
> +static int __maybe_unused dps310_fifo_read_sample(struct dps310_data *data)

Given the fairly obvious __maybe_unused what is the point?

> +{
> +	int rc;
> +	u8 val[3];
> +	s32 raw;
> +	u8 type;
> +
> +	rc = regmap_bulk_read(data->regmap, DPS310_PRS_BASE,
> +			val, sizeof(val));
> +	if (rc)
> +		return rc;
> +
> +	type = val[2] & DPS310_FIFO_TYPE_MASK;
> +	raw = (val[0] << 16) | (val[1] << 8) | (val[2] & ~DPS310_FIFO_TYPE_MASK);
get_unaligned_be24() and then mask.  However - why not also shift right to
drop those 0s?

> +	raw = sign_extend32(raw, 23);
> +
> +	if (type == DPS310_FIFO_TMP_SAMPLE)
> +		data->temp_raw = raw;
> +	else
> +		data->pressure_raw = raw;
> +
> +	return 0;
> +}
> +
> +static int dps310_fifo_init(struct dps310_data *data)
> +{
> +	int rc;
> +
> +	rc = dps310_fifo_flush(data);
> +	if (rc)
> +		return rc;
> +
> +	rc = regmap_write_bits(data->regmap, DPS310_CFG_REG,
> +			DPS310_FIFO_EN, DPS310_FIFO_EN);

Align to just after (

> +
No blank line here.
> +	if (rc)
> +		return rc;
> +
> +	data->fifo_enabled = true;
> +	return 0;
> +}
> +
>  static int dps310_probe(struct i2c_client *client)
>  {
>  	const struct i2c_device_id *id = i2c_client_get_device_id(client);
> @@ -877,6 +946,10 @@ static int dps310_probe(struct i2c_client *client)
>  	if (rc)
>  		return rc;
>  
> +	rc = dps310_fifo_init(data);
> +	if (rc)
> +		dev_warn(&client->dev,
> +			"FIFO init failed (%d), continuing without FIFO\n", rc);

Why continue?  The hardware either has a fifo or it doesn't. Any failure
in here smells like dead hardware to me. Hence just fail.

>  	rc = devm_iio_device_register(&client->dev, iio);
>  	if (rc)
>  		return rc;


  reply	other threads:[~2026-05-18 18:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 16:53 [PATCH] iio: pressure: dps310: add FIFO support Rupesh Majhi
2026-05-18 18:58 ` Jonathan Cameron [this message]
     [not found]   ` <CABpb+S7rW5c_40eCLesRq8yVeUziQYK9x8Uy-FBJ4z_JqhGPDQ@mail.gmail.com>
2026-05-21 12:25     ` Rupert Zoone
  -- strict thread matches above, loose matches on Subject: below --
2026-07-18 21:17 Rupesh Majhi
2026-07-18 21:44 ` 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=20260518195838.7afa1808@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=eajames@linux.ibm.com \
    --cc=linux-iio@vger.kernel.org \
    --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