From: Jonathan Cameron <jic23@kernel.org>
To: Yash Suthar <yashsuthar983@gmail.com>
Cc: dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
andriy.shevchenko@intel.com, grondon@gmail.com,
linusw@kernel.org, hexlabsecurity@proton.me,
sakari.ailus@linux.intel.com,
srinivas.pandruvada@linux.intel.com, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] iio: accel: bmc150: use DMA-safe buffers for regmap bulk reads
Date: Sat, 22 Aug 2026 23:06:43 +0100 [thread overview]
Message-ID: <20260822230643.2b7e1dc0@jic23-huawei> (raw)
In-Reply-To: <20260815175728.99541-3-yashsuthar983@gmail.com>
On Sat, 15 Aug 2026 23:27:27 +0530
Yash Suthar <yashsuthar983@gmail.com> wrote:
> The FIFO and read_raw buffers are passed to regmap bulk/raw reads
> ,which is not DMA-safe.Moved them into struct bmc150_accel_data
Move the comma up a line.
> after scan, each aligned to IIO_DMA_MINALIGN.
>
> Suggested-by: Jonathan Cameron <jic23@kernel.org>
> Signed-off-by: Yash Suthar <yashsuthar983@gmail.com>
My main question here is around locking and whether we need
to space all 3 buffers out in a cache line each. That is painful
on some architectures. If we ensure that DMA to one of these
never overlaps with the CPU accessing a different one, then we can
just mark the first one as IIO_DMA_MINALIGN.
Jonathan
> ---
> drivers/iio/accel/bmc150-accel-core.c | 14 ++++++--------
> drivers/iio/accel/bmc150-accel.h | 5 +++++
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel-core.c b/drivers/iio/accel/bmc150-accel-core.c
> index 89a475ef9a9b..e8d27fd1be3f 100644
> --- a/drivers/iio/accel/bmc150-accel-core.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -125,7 +125,6 @@
> #define BMC150_ACCEL_REG_FIFO_CONFIG0 0x30
> #define BMC150_ACCEL_REG_FIFO_CONFIG1 0x3E
> #define BMC150_ACCEL_REG_FIFO_DATA 0x3F
> -#define BMC150_ACCEL_FIFO_LENGTH 32
>
> enum bmc150_accel_axis {
> AXIS_X,
> @@ -622,7 +621,6 @@ static int bmc150_accel_get_axis(struct bmc150_accel_data *data,
> struct device *dev = regmap_get_device(data->regmap);
> int ret;
> int axis = chan->scan_index;
> - __le16 raw_val;
>
> mutex_lock(&data->mutex);
> ret = bmc150_accel_set_power_state(data, true);
> @@ -632,14 +630,14 @@ static int bmc150_accel_get_axis(struct bmc150_accel_data *data,
> }
>
> ret = regmap_bulk_read(data->regmap, BMC150_ACCEL_AXIS_TO_REG(axis),
> - &raw_val, sizeof(raw_val));
> + &data->regval, sizeof(data->regval));
> if (ret < 0) {
> dev_err(dev, "Error reading axis %d\n", axis);
> bmc150_accel_set_power_state(data, false);
> mutex_unlock(&data->mutex);
> return ret;
> }
> - *val = sign_extend32(le16_to_cpu(raw_val) >> chan->scan_type.shift,
> + *val = sign_extend32(le16_to_cpu(data->regval) >> chan->scan_type.shift,
> chan->scan_type.realbits - 1);
> ret = bmc150_accel_set_power_state(data, false);
> mutex_unlock(&data->mutex);
> @@ -918,7 +916,7 @@ static int bmc150_accel_set_watermark(struct iio_dev *indio_dev, unsigned val)
> * frame data is discarded.
> */
> static int bmc150_accel_fifo_transfer(struct bmc150_accel_data *data,
> - char *buffer, int samples)
> + void *buffer, int samples)
> {
> struct device *dev = regmap_get_device(data->regmap);
> int sample_length = 3 * 2;
> @@ -941,7 +939,6 @@ static int __bmc150_accel_fifo_flush(struct iio_dev *indio_dev,
> struct device *dev = regmap_get_device(data->regmap);
> int ret, i;
> u8 count;
> - u16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3];
> int64_t tstamp;
> uint64_t sample_period;
> unsigned int val;
> @@ -993,7 +990,7 @@ static int __bmc150_accel_fifo_flush(struct iio_dev *indio_dev,
>
> count = min_t(u8, count, BMC150_ACCEL_FIFO_LENGTH);
>
> - ret = bmc150_accel_fifo_transfer(data, (u8 *)buffer, count);
> + ret = bmc150_accel_fifo_transfer(data, data->fifo_buff, count);
> if (ret)
> return ret;
>
> @@ -1008,7 +1005,8 @@ static int __bmc150_accel_fifo_flush(struct iio_dev *indio_dev,
>
> j = 0;
> iio_for_each_active_channel(indio_dev, bit)
> - memcpy(&data->scan.channels[j++], &buffer[i * 3 + bit],
> + memcpy(&data->scan.channels[j++],
> + &data->fifo_buff[i * 3 + bit],
> sizeof(data->scan.channels[0]));
>
> iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
> diff --git a/drivers/iio/accel/bmc150-accel.h b/drivers/iio/accel/bmc150-accel.h
> index 9deff256aed5..8f64b24339e4 100644
> --- a/drivers/iio/accel/bmc150-accel.h
> +++ b/drivers/iio/accel/bmc150-accel.h
> @@ -56,6 +56,8 @@ enum bmc150_accel_trigger_id {
> BMC150_ACCEL_TRIGGERS,
> };
>
> +#define BMC150_ACCEL_FIFO_LENGTH 32
> +
> struct bmc150_accel_data {
> struct regmap *regmap;
> int irq;
> @@ -81,6 +83,9 @@ struct bmc150_accel_data {
> __le16 channels[3];
> aligned_s64 ts;
> } scan __aligned(IIO_DMA_MINALIGN);
> + /* DMA-safe buffers for bulk/raw reads */
> + __le16 fifo_buff[BMC150_ACCEL_FIFO_LENGTH * 3] __aligned(IIO_DMA_MINALIGN);
> + __le16 regval __aligned(IIO_DMA_MINALIGN);
This is potentially a lot of padding that might not be necessary.
What locking protects these? I'd kind of expect all 3 to be used
under a single lock. If that's the case and locks are held for all
such usage, then we can just force alignment of the first one.
> };
>
> int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int irq,
next prev parent reply other threads:[~2026-08-22 22:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 17:57 [PATCH v2 0/3] iio: accel: bmc150: DMA-safe buffers and use iio_push_to_buffers_with_ts() Yash Suthar
2026-08-15 17:57 ` [PATCH v2 1/3] iio: accel: bmc150: use aligned scan buffer for both trigger and fifo Yash Suthar
2026-08-17 12:15 ` Linus Walleij
2026-08-22 21:55 ` Jonathan Cameron
2026-08-22 22:02 ` Jonathan Cameron
2026-08-15 17:57 ` [PATCH v2 2/3] iio: accel: bmc150: use DMA-safe buffers for regmap bulk reads Yash Suthar
2026-08-17 12:15 ` Linus Walleij
2026-08-22 22:06 ` Jonathan Cameron [this message]
2026-08-24 19:36 ` Yash Suthar
2026-08-15 17:57 ` [PATCH v2 3/3] iio: accel: bmc150: use iio_push_to_buffers_with_ts() Yash Suthar
2026-08-17 12:15 ` Linus Walleij
2026-08-16 23:46 ` [PATCH v2 0/3] iio: accel: bmc150: DMA-safe buffers and " Gabriel Rondon
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=20260822230643.2b7e1dc0@jic23-huawei \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=grondon@gmail.com \
--cc=hexlabsecurity@proton.me \
--cc=linusw@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=sakari.ailus@linux.intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=yashsuthar983@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