From: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
To: "Ardelean, Alexandru" <alexandru.Ardelean@analog.com>
Cc: "denis.ciocca@st.com" <denis.ciocca@st.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 1/5] iio:common: introduce st_sensors_buffer_preenable/predisable functions
Date: Mon, 5 Aug 2019 16:35:34 +0100 [thread overview]
Message-ID: <20190805163534.68c00bf3@archlinux> (raw)
In-Reply-To: <20190805162135.68dc97c4@archlinux>
On Mon, 5 Aug 2019 16:21:35 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Thu, 1 Aug 2019 08:24:10 +0000
> "Ardelean, Alexandru" <alexandru.Ardelean@analog.com> wrote:
>
> > On Wed, 2019-07-31 at 14:52 -0700, Denis Ciocca wrote:
> > > [External]
> > >
> > > This patch is introducing preenable/postdisable in the common
> > > st_sensors_buffer code in order to remove the memory allocation /
> > > de-allocation from each single st driver.
> > >
> >
> > Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> >
> > > Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
>
> As a rework, this is clearly reasonable, however, if we are going to
> touch this code at all, there are a few things I would like to tidy
> up about it.
>
> Firstly it's one of relatively few drivers that actually touch scan_bytes
> in the first place. That is supposed to be internal state to the core
> subsystem and not used by drivers (see INTERN marking in iio.h).
> It bled across the boundary in too many places where I wasn't looking.
>
> Secondly these allocations are small. You would be better off just
> making them part of the main state structure and not dynamically allocated
> at all.
>
> So move buffer_data to the end of struct st_sensor_data and make it
> whatever the maximum size needed is - I'm thinking probably 32 bytes
> but haven't checked.
Maths escapes me today, probably only 16 bytes as 3 channel devices
mostly 16 bits max + timestamp.
J
>
> You call the bulk regmap API against it so you also need to ensure
> it's in it's own cacheline. Use the __cacheline_aligned magic
> to enforce that. The iio_priv region is always aligned appropriately
> to allow iio_priv accessed structures to pull this trick.
>
> That way we don't need to do any memory handling on demand at all.
> We may or many not save memory as will depend on exactly how big
> that structure already is and what mood the allocator is in.
>
> I don't think I'm missing a reason we can't take the approach of
> embedding the buffer and it definitely makes the code simpler.
>
> Thanks,
>
> Jonathan
>
>
> > > ---
> > > .../iio/common/st_sensors/st_sensors_buffer.c | 22 +++++++++++++++++++
> > > include/linux/iio/common/st_sensors.h | 2 ++
> > > 2 files changed, 24 insertions(+)
> > >
> > > diff --git a/drivers/iio/common/st_sensors/st_sensors_buffer.c b/drivers/iio/common/st_sensors/st_sensors_buffer.c
> > > index eee30130ae23..9da1c8104883 100644
> > > --- a/drivers/iio/common/st_sensors/st_sensors_buffer.c
> > > +++ b/drivers/iio/common/st_sensors/st_sensors_buffer.c
> > > @@ -81,6 +81,28 @@ irqreturn_t st_sensors_trigger_handler(int irq, void *p)
> > > }
> > > EXPORT_SYMBOL(st_sensors_trigger_handler);
> > >
> > > +int st_sensors_buffer_preenable(struct iio_dev *indio_dev)
> > > +{
> > > + struct st_sensor_data *sdata = iio_priv(indio_dev);
> > > +
> > > + sdata->buffer_data = kmalloc(indio_dev->scan_bytes,
> > > + GFP_DMA | GFP_KERNEL);
> > > + if (!sdata->buffer_data)
> > > + return -ENOMEM;
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(st_sensors_buffer_preenable);
> > > +
> > > +int st_sensors_buffer_postdisable(struct iio_dev *indio_dev)
> > > +{
> > > + struct st_sensor_data *sdata = iio_priv(indio_dev);
> > > +
> > > + kfree(sdata->buffer_data);
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL(st_sensors_buffer_postdisable);
> > > +
> > > MODULE_AUTHOR("Denis Ciocca <denis.ciocca@st.com>");
> > > MODULE_DESCRIPTION("STMicroelectronics ST-sensors buffer");
> > > MODULE_LICENSE("GPL v2");
> > > diff --git a/include/linux/iio/common/st_sensors.h b/include/linux/iio/common/st_sensors.h
> > > index 28fc1f9fa7d5..c66ebb236a15 100644
> > > --- a/include/linux/iio/common/st_sensors.h
> > > +++ b/include/linux/iio/common/st_sensors.h
> > > @@ -254,6 +254,8 @@ struct st_sensor_data {
> > >
> > > #ifdef CONFIG_IIO_BUFFER
> > > irqreturn_t st_sensors_trigger_handler(int irq, void *p);
> > > +int st_sensors_buffer_preenable(struct iio_dev *indio_dev);
> > > +int st_sensors_buffer_postdisable(struct iio_dev *indio_dev);
> > > #endif
> > >
> > > #ifdef CONFIG_IIO_TRIGGER
>
next prev parent reply other threads:[~2019-08-05 15:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 21:52 [PATCH 0/5] move buffer allocation into st_sensors_buffer Denis Ciocca
2019-07-31 21:52 ` [PATCH 1/5] iio:common: introduce st_sensors_buffer_preenable/predisable functions Denis Ciocca
2019-08-01 8:24 ` Ardelean, Alexandru
2019-08-05 15:21 ` Jonathan Cameron
2019-08-05 15:35 ` Jonathan Cameron [this message]
2019-08-05 17:18 ` Denis CIOCCA
2019-08-05 17:40 ` Denis CIOCCA
2019-07-31 21:52 ` [PATCH 2/5] iio:accel: do not allocate/de-allocate buffer here but link setup_ops to st_sensors_buffer Denis Ciocca
2019-08-01 8:24 ` Ardelean, Alexandru
2019-07-31 21:52 ` [PATCH 3/5] iio:gyro: " Denis Ciocca
2019-08-01 8:25 ` Ardelean, Alexandru
2019-07-31 21:52 ` [PATCH 4/5] iio:magn: " Denis Ciocca
2019-08-01 8:25 ` Ardelean, Alexandru
2019-07-31 21:52 ` [PATCH 5/5] iio:pressure: " Denis Ciocca
2019-08-01 8:25 ` Ardelean, Alexandru
2019-08-01 8:23 ` [PATCH 0/5] move buffer allocation into st_sensors_buffer Ardelean, Alexandru
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=20190805163534.68c00bf3@archlinux \
--to=jic23@jic23.retrosnub.co.uk \
--cc=alexandru.Ardelean@analog.com \
--cc=denis.ciocca@st.com \
--cc=linux-iio@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).