Re: [PATCH] i2c: mux: Remove class argument from i2c_mux_add_adapter()

[Jonathan Cameron]

On Thu, 18 Apr 2024 22:55:39 +0200
Heiner Kallweit  wrote:

> 99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
> instantiation") removed the last call to i2c_mux_add_adapter() with a
> non-null class argument. Therefore the class argument can be removed.
> 
> Note: Class-based device instantiation is a legacy mechanism which
> shouldn't be used in new code, so we can rule out that this argument
> may be needed again in the future.
> 
> Signed-off-by: Heiner Kallweit 

For iio

Acked-by: Jonathan Cameron 

> ---
>  drivers/gpu/drm/bridge/sii902x.c   |  2 +-
>  drivers/i2c/i2c-mux.c  | 24 +-
>  drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  2 +-
>  drivers/i2c/muxes/i2c-mux-gpio.c   |  2 +-
>  drivers/i2c/muxes/i2c-mux-gpmux.c  |  2 +-
>  drivers/i2c/muxes/i2c-mux-ltc4306.c|  2 +-
>  drivers/i2c/muxes/i2c-mux-mlxcpld.c|  2 +-
>  drivers/i2c/muxes/i2c-mux-pca9541.c|  2 +-
>  drivers/i2c/muxes/i2c-mux-pca954x.c|  2 +-
>  drivers/i2c/muxes/i2c-mux-pinctrl.c|  2 +-
>  drivers/i2c/muxes/i2c-mux-reg.c|  2 +-
>  drivers/iio/gyro/mpu3050-i2c.c |  2 +-
>  drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c  |  2 +-
>  drivers/media/dvb-frontends/af9013.c   |  2 +-
>  drivers/media/dvb-frontends/lgdt3306a.c|  2 +-
>  drivers/media/dvb-frontends/m88ds3103.c|  2 +-
>  drivers/media/dvb-frontends/rtl2830.c  |  2 +-
>  drivers/media/dvb-frontends/rtl2832.c  |  2 +-
>  drivers/media/dvb-frontends/si2168.c   |  2 +-
>  drivers/media/i2c/max9286.c|  2 +-
>  drivers/media/usb/cx231xx/cx231xx-i2c.c|  5 +
>  drivers/of/unittest.c  |  2 +-
>  include/linux/i2c-mux.h|  3 +--
>  23 files changed, 23 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 8f84e9824..2fbeda902 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -1092,7 +1092,7 @@ static int sii902x_init(struct sii902x *sii902x)
>   }
>  
>   sii902x->i2cmux->priv = sii902x;
> - ret = i2c_mux_add_adapter(sii902x->i2cmux, 0, 0, 0);
> + ret = i2c_mux_add_adapter(sii902x->i2cmux, 0, 0);
>   if (ret)
>   goto err_unreg_audio;
>  
> diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
> index 57ff09f18..fda72e8be 100644
> --- a/drivers/i2c/i2c-mux.c
> +++ b/drivers/i2c/i2c-mux.c
> @@ -127,19 +127,6 @@ static u32 i2c_mux_functionality(struct i2c_adapter 
> *adap)
>   return parent->algo->functionality(parent);
>  }
>  
> -/* Return all parent classes, merged */
> -static unsigned int i2c_mux_parent_classes(struct i2c_adapter *parent)
> -{
> - unsigned int class = 0;
> -
> - do {
> - class |= parent->class;
> - parent = i2c_parent_is_i2c_adapter(parent);
> - } while (parent);
> -
> - return class;
> -}
> -
>  static void i2c_mux_lock_bus(struct i2c_adapter *adapter, unsigned int flags)
>  {
>   struct i2c_mux_priv *priv = adapter->algo_data;
> @@ -281,8 +268,7 @@ static const struct i2c_lock_operations 
> i2c_parent_lock_ops = {
>  };
>  
>  int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
> - u32 force_nr, u32 chan_id,
> - unsigned int class)
> + u32 force_nr, u32 chan_id)
>  {
>   struct i2c_adapter *parent = muxc->parent;
>   struct i2c_mux_priv *priv;
> @@ -340,14 +326,6 @@ int i2c_mux_add_adapter(struct i2c_mux_core *muxc,
>   else
>   priv->adap.lock_ops = _parent_lock_ops;
>  
> - /* Sanity check on class */
> - if (i2c_mux_parent_classes(parent) & class & ~I2C_CLASS_DEPRECATED)
> - dev_err(>dev,
> - "Segment %d behind mux can't share classes with 
> ancestors\n",
> - chan_id);
> - else
> - priv->adap.class = class;
> -
>   /*
>* Try to populate the mux adapter's of_node, expands to
>* nothing if !CONFIG_OF.
> diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c 
> b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> index 24168e9f7..7aa6e795d 100644
> --- a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> +++ b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> @@ -167,7 +167,7 @@ static int i2c_arbitrator_probe(struct platform_device 
> *pdev)
>   }
>  
>   /* Actually add the mux adapter */
> - ret = i2c_mux_add_adapter(muxc, 0, 0, 0);
> + ret = i2c_mux_add_ad

Re: [PATCH v9 0/6] iio: new DMABUF based API

[Jonathan Cameron]

On Sun, 10 Mar 2024 13:48:29 +0100
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Here's the final-er version of the IIO DMABUF patchset.
> 
> This v9 fixes the few issues reported by the kernel bot.
> 
> This was based on next-20240308.
> 
> Changelog:
> 
> - [3/6]:
> - Select DMA_SHARED_BUFFER in Kconfig
> - Remove useless forward declaration of 'iio_dma_fence'
> - Import DMA-BUF namespace
> - Add missing __user tag to iio_buffer_detach_dmabuf() argument

Merge window is coming to an end, and whilst we obviously have
plenty of time left in this cycle, I would like to get this queued
up fairly early so any issues can shake out and the various series
that will build on this can progress.

Hopefully Paul has addressed all remaining comments.
So I'm looking for RB or Ack for DMABUF and dmaengine parts from
respective reviewers/maintainers.

Thanks

Jonathan

> 
> Cheers,
> -Paul
> 
> Paul Cercueil (6):
>   dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
>   dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
>   iio: core: Add new DMABUF interface infrastructure
>   iio: buffer-dma: Enable support for DMABUFs
>   iio: buffer-dmaengine: Support new DMABUF based userspace API
>   Documentation: iio: Document high-speed DMABUF based API
> 
>  Documentation/iio/iio_dmabuf_api.rst  |  54 ++
>  Documentation/iio/index.rst   |   1 +
>  drivers/dma/dma-axi-dmac.c|  40 ++
>  drivers/iio/Kconfig   |   1 +
>  drivers/iio/buffer/industrialio-buffer-dma.c  | 181 ++-
>  .../buffer/industrialio-buffer-dmaengine.c|  59 ++-
>  drivers/iio/industrialio-buffer.c | 462 ++
>  include/linux/dmaengine.h |  27 +
>  include/linux/iio/buffer-dma.h|  31 ++
>  include/linux/iio/buffer_impl.h   |  30 ++
>  include/uapi/linux/iio/buffer.h   |  22 +
>  11 files changed, 891 insertions(+), 17 deletions(-)
>  create mode 100644 Documentation/iio/iio_dmabuf_api.rst
> 

Re: [PATCH v8 0/6] iio: new DMABUF based API

[Jonathan Cameron]

On Fri,  8 Mar 2024 18:00:40 +0100
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Here's the final(tm) version of the IIO DMABUF patchset.
> 
> This v8 fixes the remaining few issues that Christian reported.
> 
> I also updated the documentation patch as there has been changes to
> index.rst.
> 
> This was based on next-20240308.
> 
> Changelog:
> 
> - [3/6]:
> - Fix swapped fence direction
> - Simplify fence wait mechanism
> - Remove "Buffer closed with active transfers" print, as it was dead
>   code
> - Un-export iio_buffer_dmabuf_{get,put}. They are not used anywhere
>   else so they can even be static.
> - Prevent attaching already-attached DMABUFs
> - [6/6]:
> Renamed dmabuf_api.rst -> iio_dmabuf_api.rst, and updated index.rst
> whose format changed in iio/togreg.
> 
> Cheers,
> -Paul
Given nature of the build bug issues reported, I'm guessing you never
built this as a module :(  Not sure how one instance of a missing 
user marking got through but also easy to fix.

Anyhow, no need to wait before sending a v9 with those sorted.

0-day does it's job again - even better is that it's whilst it's
still your problem and not mine :)

Jonathan

> 
> Paul Cercueil (6):
>   dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
>   dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
>   iio: core: Add new DMABUF interface infrastructure
>   iio: buffer-dma: Enable support for DMABUFs
>   iio: buffer-dmaengine: Support new DMABUF based userspace API
>   Documentation: iio: Document high-speed DMABUF based API
> 
>  Documentation/iio/iio_dmabuf_api.rst  |  54 ++
>  Documentation/iio/index.rst   |   1 +
>  drivers/dma/dma-axi-dmac.c|  40 ++
>  drivers/iio/buffer/industrialio-buffer-dma.c  | 181 ++-
>  .../buffer/industrialio-buffer-dmaengine.c|  59 ++-
>  drivers/iio/industrialio-buffer.c | 462 ++
>  include/linux/dmaengine.h |  27 +
>  include/linux/iio/buffer-dma.h|  31 ++
>  include/linux/iio/buffer_impl.h   |  30 ++
>  include/uapi/linux/iio/buffer.h   |  22 +
>  10 files changed, 890 insertions(+), 17 deletions(-)
>  create mode 100644 Documentation/iio/iio_dmabuf_api.rst
> 

Re: [PATCH v7 0/6] iio: new DMABUF based API

[Jonathan Cameron]

On Mon, 04 Mar 2024 08:59:47 +0100
Nuno Sá  wrote:

> On Sun, 2024-03-03 at 17:42 +0000, Jonathan Cameron wrote:
> > On Fri, 23 Feb 2024 13:13:58 +0100
> > Nuno Sa  wrote:
> >   
> > > Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be
> > > honest, we're hoping to get this merged this for the 6.9 merge window.
> > > Main reason is because the USB part is already in (so it would be nice
> > > to get the whole thing in). Moreover, the changes asked in v6 were simple
> > > (even though I'm not quite sure in one of them) and Paul has no access to
> > > it's laptop so he can't send v7 himself. So he kind of said/asked for me 
> > > to
> > > do it.  
> > 
> > So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe 
> > we
> > can sneak this in. However, I need an Ack from Vinod for the dma engine
> > changes first.
> > 
> > Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!)
> > 
> > Seems that the other side got resolved in the USB gadget, but last we heard
> > form
> > Daniel and Christian looks to have been back on v5. I'd like them to confirm
> > they are fine with the changes made as a result. 
> >   
> 
> I can ask Christian or Daniel for some acks but my feeling (I still need, at
> some point, to get really familiar with all of this) is that this should be
> pretty similar to the USB series (from a DMABUF point of view) as they are 
> both
> importers.
> 
> > I've been happy with the IIO parts for a few versions now but my ability to
> > review
> > the DMABUF and DMA engine bits is limited.
> > 
> > A realistic path to get this in is rc8 is happening, is all Acks in place by
> > Wednesday,
> > I get apply it and hits Linux-next Thursday, Pull request to Greg on 
> > Saturday
> > and Greg
> > is feeling particularly generous to take one on the day he normally closes 
> > his
> > trees.
> >   
> 
> Well, it looks like we still have a shot. I'll try to see if Vinod is fine 
> with
> the DMAENGINE stuff.
> 

Sadly, looks like rc7 was at the end of a quiet week, so almost certain to not
be an rc8 in the end. Let's aim to get this in at the start of the next cycle
so we can build on it from there.


Jonathan

> - Nuno Sá
> 
> 

Re: [PATCH v7 0/6] iio: new DMABUF based API

[Jonathan Cameron]

On Fri, 23 Feb 2024 13:13:58 +0100
Nuno Sa  wrote:

> Hi Jonathan, likely you're wondering why I'm sending v7. Well, to be
> honest, we're hoping to get this merged this for the 6.9 merge window.
> Main reason is because the USB part is already in (so it would be nice
> to get the whole thing in). Moreover, the changes asked in v6 were simple
> (even though I'm not quite sure in one of them) and Paul has no access to
> it's laptop so he can't send v7 himself. So he kind of said/asked for me to 
> do it.

So, we are cutting this very fine. If Linus hints strongly at an rc8 maybe we
can sneak this in. However, I need an Ack from Vinod for the dma engine changes 
first.

Also I'd love a final 'looks ok' comment from DMABUF folk (Ack even better!)

Seems that the other side got resolved in the USB gadget, but last we heard form
Daniel and Christian looks to have been back on v5. I'd like them to confirm
they are fine with the changes made as a result. 

I've been happy with the IIO parts for a few versions now but my ability to 
review
the DMABUF and DMA engine bits is limited.

A realistic path to get this in is rc8 is happening, is all Acks in place by 
Wednesday,
I get apply it and hits Linux-next Thursday, Pull request to Greg on Saturday 
and Greg
is feeling particularly generous to take one on the day he normally closes his 
trees.

Whilst I'll cross my fingers, looks like 6.10 material to me :(

I'd missed the progress on the USB side so wasn't paying enough attention. 
Sorry!

Jonathan

> 
> v6:
>  * 
> https://lore.kernel.org/linux-iio/20240129170201.133785-1-p...@crapouillou.net/
> 
> v7:
>  - Patch 1
>   * Renamed *device_prep_slave_dma_vec() -> device_prep_peripheral_dma_vec();
>   * Added a new flag parameter to the function as agreed between Paul
> and Vinod. I renamed the first parameter to prep_flags as it's supposed to
> be used (I think) with enum dma_ctrl_flags. I'm not really sure how that 
> API
> can grow but I was thinking in just having a bool cyclic parameter (as the
> first intention of the flags is to support cyclic transfers) but ended up
> "respecting" the previously agreed approach.
> - Patch 2
>   * Adapted patch for the changes made in patch 1.
> - Patch 5
>   * Adapted patch for the changes made in patch 1.
> 
> Patchset based on next-20240223.
> 
> ---
> Paul Cercueil (6):
>   dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
>   dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec
>   iio: core: Add new DMABUF interface infrastructure
>   iio: buffer-dma: Enable support for DMABUFs
>   iio: buffer-dmaengine: Support new DMABUF based userspace API
>   Documentation: iio: Document high-speed DMABUF based API
> 
>  Documentation/iio/dmabuf_api.rst   |  54 +++
>  Documentation/iio/index.rst|   2 +
>  drivers/dma/dma-axi-dmac.c |  40 ++
>  drivers/iio/buffer/industrialio-buffer-dma.c   | 181 +++-
>  drivers/iio/buffer/industrialio-buffer-dmaengine.c |  59 ++-
>  drivers/iio/industrialio-buffer.c  | 462 
> +
>  include/linux/dmaengine.h  |  27 ++
>  include/linux/iio/buffer-dma.h |  31 ++
>  include/linux/iio/buffer_impl.h|  33 ++
>  include/uapi/linux/iio/buffer.h|  22 +
>  10 files changed, 894 insertions(+), 17 deletions(-)
> ---
> base-commit: 33e1d31873f87d119e5120b88cd350efa68ef276
> change-id: 20240223-iio-dmabuf-5ee0530195ca
> --
> 
> Thanks!
> - Nuno Sá
> 

Re: [PATCH v5 5/8] iio: core: Add new DMABUF interface infrastructure

[Jonathan Cameron]

> > > + iio_buffer_dmabuf_put(attach);
> > > +
> > > +out_dmabuf_put:
> > > + dma_buf_put(dmabuf);  
> > As below. Feels like a __free(dma_buf_put) bit of magic would be a
> > nice to have.  
> 
> I'm working on the patches right now, just one quick question.
> 
> Having a __free(dma_buf_put) requires that dma_buf_put is first
> "registered" as a freeing function using DEFINE_FREE() in  buf.h>, which has not been done yet.  
> 
> That would mean carrying a dma-buf specific patch in your tree, are you
> OK with that?
Needs an ACK from appropriate maintainer, but otherwise I'm fine doing
so.  Alternative is to circle back to this later after this code is upstream.

> 
> Cheers,
> -Paul

> 

Re: [PATCH v2 00/33] spi: get rid of some legacy macros

[Jonathan Cameron]

On Mon, 22 Jan 2024 19:23:43 +
Jonathan Cameron  wrote:

> On Mon, 22 Jan 2024 18:18:22 +
> Mark Brown  wrote:
> 
> > On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
> >   
> > > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > > didn't appear in a public tree though yet. I still included it here to
> > > make the kernel build bots happy.
> > 
> > It's also going to be needed for buildability of the end of the series.  
> 
> Ah.  I thought intent was to split this across all the different trees
> then do the final patch only after they were all gone?
> 
> I'm fine with it going all in one go if people prefer that.
> 
> My tree will be out in a few mins. Was just waiting to rebase on rc1
> which I've just done.
> 
> Jonathan
> 

Dropped from my tree.

Acked-by: Jonathan Cameron 

Re: [PATCH v2 00/33] spi: get rid of some legacy macros

[Jonathan Cameron]

On Mon, 22 Jan 2024 18:18:22 +
Mark Brown  wrote:

> On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote:
> 
> > Note that Jonathan Cameron has already applied patch 3 to his tree, it
> > didn't appear in a public tree though yet. I still included it here to
> > make the kernel build bots happy.  
> 
> It's also going to be needed for buildability of the end of the series.

Ah.  I thought intent was to split this across all the different trees
then do the final patch only after they were all gone?

I'm fine with it going all in one go if people prefer that.

My tree will be out in a few mins. Was just waiting to rebase on rc1
which I've just done.

Jonathan

Re: [PATCH v5 0/8] iio: new DMABUF based API, v5

[Jonathan Cameron]

On Thu, 21 Dec 2023 18:56:52 +0100
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Le jeudi 21 décembre 2023 à 16:30 +, Jonathan Cameron a écrit :
> > On Tue, 19 Dec 2023 18:50:01 +0100
> > Paul Cercueil  wrote:
> >   
> > > [V4 was: "iio: Add buffer write() support"][1]
> > > 
> > > Hi Jonathan,
> > >   
> > Hi Paul,
> >   
> > > This is a respin of the V3 of my patchset that introduced a new
> > > interface based on DMABUF objects [2].  
> > 
> > Great to see this moving forwards.
> >   
> > > 
> > > The V4 was a split of the patchset, to attempt to upstream buffer
> > > write() support first. But since there is no current user upstream,
> > > it
> > > was not merged. This V5 is about doing the opposite, and contains
> > > the
> > > new DMABUF interface, without adding the buffer write() support. It
> > > can
> > > already be used with the upstream adi-axi-adc driver.  
> > 
> > Seems like a sensible path in the short term.
> >   
> > > 
> > > In user-space, Libiio uses it to transfer back and forth blocks of
> > > samples between the hardware and the applications, without having
> > > to
> > > copy the data.
> > > 
> > > On a ZCU102 with a FMComms3 daughter board, running Libiio from the
> > > pcercuei/dev-new-dmabuf-api branch [3], compiled with
> > > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
> > >   sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
> > >   Throughput: 116 MiB/s
> > > 
> > > Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON):
> > >   sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
> > >   Throughput: 475 MiB/s
> > > 
> > > This benchmark only measures the speed at which the data can be
> > > fetched
> > > to iio_rwdev's internal buffers, and does not actually try to read
> > > the
> > > data (e.g. to pipe it to stdout). It shows that fetching the data
> > > is
> > > more than 4x faster using the new interface.
> > > 
> > > When actually reading the data, the performance difference isn't
> > > that
> > > impressive (maybe because in case of DMABUF the data is not in
> > > cache):  
> > 
> > This needs a bit more investigation ideally. Perhaps perf counters
> > can be
> > used to establish that cache misses are the main different between
> > dropping it on the floor and actually reading the data.  
> 
> Yes, we'll work on it. The other big difference is that fileio uses
> dma_alloc_coherent() while the DMABUFs use non-coherent mappings. I
> guess coherent memory is faster for the typical access pattern (which
> is "read/write everything sequentially once").

Long time since I last worked much with a platform that wasn't always
IO coherent, so I've forgotten how all this works (all ends up as no-ops
on platforms I tend to use these days!)  Good luck, I'll be interested
to see what this turns out to be.

> 
> > > 
> > > WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
> > >   sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero
> > > status=progress
> > >   2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s
> > > 
> > > WITH_LOCAL_DMABUF_API=ON:
> > >   sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero
> > > status=progress
> > >   2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s
> > > 
> > > One interesting thing to note is that fileio is (currently)
> > > actually
> > > faster than the DMABUF interface if you increase a lot the buffer
> > > size.
> > > My explanation is that the cache invalidation routine takes more
> > > and
> > > more time the bigger the DMABUF gets. This is because the DMABUF is
> > > backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by
> > > up
> > > to 16 thousands pages, that have to be invalidated one by one. This
> > > can
> > > be addressed by using huge pages, but the udmabuf driver does not
> > > (yet)
> > > support creating DMABUFs backed by huge pages.  
> > 
> > I'd imagine folios of reasonable size will help sort of a huge page
> > as then hopefully it will use the flush by va range instructions if
> > available.
> >   
> > > 
> > > Anyway, the real benefits happen when the DMABUFs are either shared
> > > between IIO devices, or between the IIO subsystem and another
> > > filesystem. I

Re: [PATCH v5 7/8] iio: buffer-dmaengine: Support new DMABUF based userspace API

[Jonathan Cameron]

On Fri, 22 Dec 2023 09:58:29 +0100
Nuno Sá  wrote:

> On Thu, 2023-12-21 at 18:30 +0100, Paul Cercueil wrote:
> > Hi Jonathan,
> > 
> > Le jeudi 21 décembre 2023 à 16:12 +0000, Jonathan Cameron a écrit :  
> > > On Tue, 19 Dec 2023 18:50:08 +0100
> > > Paul Cercueil  wrote:
> > >   
> > > > Use the functions provided by the buffer-dma core to implement the
> > > > DMABUF userspace API in the buffer-dmaengine IIO buffer
> > > > implementation.
> > > > 
> > > > Since we want to be able to transfer an arbitrary number of bytes
> > > > and
> > > > not necesarily the full DMABUF, the associated scatterlist is
> > > > converted
> > > > to an array of DMA addresses + lengths, which is then passed to
> > > > dmaengine_prep_slave_dma_array().
> > > > 
> > > > Signed-off-by: Paul Cercueil   
> > > One question inline. Otherwise looks fine to me.
> > > 
> > > J  
> > > > 
> > > > ---
> > > > v3: Use the new dmaengine_prep_slave_dma_array(), and adapt the
> > > > code to
> > > >     work with the new functions introduced in industrialio-buffer-
> > > > dma.c.
> > > > 
> > > > v5: - Use the new dmaengine_prep_slave_dma_vec().
> > > >     - Restrict to input buffers, since output buffers are not yet
> > > >   supported by IIO buffers.
> > > > ---
> > > >  .../buffer/industrialio-buffer-dmaengine.c    | 52
> > > > ---
> > > >  1 file changed, 46 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > > b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > > index 5f85ba38e6f6..825d76a24a67 100644
> > > > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > > > @@ -64,15 +64,51 @@ static int
> > > > iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue
> > > > *queue,
> > > > struct dmaengine_buffer *dmaengine_buffer =
> > > > iio_buffer_to_dmaengine_buffer(>buffer);
> > > > struct dma_async_tx_descriptor *desc;
> > > > +   unsigned int i, nents;
> > > > +   struct scatterlist *sgl;
> > > > +   struct dma_vec *vecs;
> > > > +   size_t max_size;
> > > > dma_cookie_t cookie;
> > > > +   size_t len_total;
> > > >  
> > > > -   block->bytes_used = min(block->size, dmaengine_buffer-  
> > > > > max_size);  
> > > > -   block->bytes_used = round_down(block->bytes_used,
> > > > -   dmaengine_buffer->align);
> > > > +   if (queue->buffer.direction != IIO_BUFFER_DIRECTION_IN) {
> > > > +   /* We do not yet support output buffers. */
> > > > +   return -EINVAL;
> > > > +   }
> > > >  
> > > > -   desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> > > > -   block->phys_addr, block->bytes_used,
> > > > DMA_DEV_TO_MEM,
> > > > -   DMA_PREP_INTERRUPT);
> > > > +   if (block->sg_table) {
> > > > +   sgl = block->sg_table->sgl;
> > > > +   nents = sg_nents_for_len(sgl, block->bytes_used);  
> > > 
> > > Are we guaranteed the length in the sglist is enough?  If not this
> > > can return an error code.  
> > 
> > The length of the sglist will always be enough, the
> > iio_buffer_enqueue_dmabuf() function already checks that block-  
> > > bytes_used is equal or smaller than the size of the DMABUF.  
> > 
> > It is quite a few functions above in the call stack though, so I can
> > handle the errors of sg_nents_for_len() here if you think makes sense.  
> 
> Maybe putting something like the above in a comment?
Either comment, or an explicit check so we don't need the comment is
fine as far as I'm concerned.

Jonathan

> 
> - Nuno Sá
> 
> 

Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs

[Jonathan Cameron]

> > > +struct iio_dma_buffer_block *
> > > +iio_dma_buffer_attach_dmabuf(struct iio_buffer *buffer,
> > > +    struct dma_buf_attachment *attach)
> > > +{
> > > +   struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
> > > +   struct iio_dma_buffer_block *block;
> > > +   int err;
> > > +
> > > +   mutex_lock(>lock);  
> > 
> > guard(mutex)(>lock);  
> 
> I'm also a big fan of this new stuff but shouldn't we have a prep patch 
> making the
> transition to that? Otherwise we'll end up with a mix of styles. I'm happy to 
> clean
> up stuff with follow up patches (even some coding style could be improved 
> IIRC) but
> typically that's not how we handle things like this I believe...

Ideally yes, I think a prep patch would make sense - but I'm not that fussed
about it and follow up patches would be fine here. 

There are cases for using this that are much easier to justify than
others, so I don't really mind if simple

mutex_lock();
do_something
mutex_unlock();

cases are left for ever not using guard(), though I also don't mind if people 
want to use
scoped_guard() or guard for these just to be consistent.  Either way is pretty
easy to read.  We'll probably also continue to gain new uses of this logic such
as the conditional guard stuff that is queued up for the next merge window and
whilst that is going on we are going to have a bit of mixed style.

Jonathan


> 
> - Nuno Sá
> >   
> 

Re: [PATCH v5 0/8] iio: new DMABUF based API, v5

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:01 +0100
Paul Cercueil  wrote:

> [V4 was: "iio: Add buffer write() support"][1]
> 
> Hi Jonathan,
> 
Hi Paul,

> This is a respin of the V3 of my patchset that introduced a new
> interface based on DMABUF objects [2].

Great to see this moving forwards.

> 
> The V4 was a split of the patchset, to attempt to upstream buffer
> write() support first. But since there is no current user upstream, it
> was not merged. This V5 is about doing the opposite, and contains the
> new DMABUF interface, without adding the buffer write() support. It can
> already be used with the upstream adi-axi-adc driver.

Seems like a sensible path in the short term.

> 
> In user-space, Libiio uses it to transfer back and forth blocks of
> samples between the hardware and the applications, without having to
> copy the data.
> 
> On a ZCU102 with a FMComms3 daughter board, running Libiio from the
> pcercuei/dev-new-dmabuf-api branch [3], compiled with
> WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
>   sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
>   Throughput: 116 MiB/s
> 
> Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON):
>   sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
>   Throughput: 475 MiB/s
> 
> This benchmark only measures the speed at which the data can be fetched
> to iio_rwdev's internal buffers, and does not actually try to read the
> data (e.g. to pipe it to stdout). It shows that fetching the data is
> more than 4x faster using the new interface.
> 
> When actually reading the data, the performance difference isn't that
> impressive (maybe because in case of DMABUF the data is not in cache):

This needs a bit more investigation ideally. Perhaps perf counters can be
used to establish that cache misses are the main different between
dropping it on the floor and actually reading the data.

> 
> WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
>   sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress
>   2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s
> 
> WITH_LOCAL_DMABUF_API=ON:
>   sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress
>   2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s
> 
> One interesting thing to note is that fileio is (currently) actually
> faster than the DMABUF interface if you increase a lot the buffer size.
> My explanation is that the cache invalidation routine takes more and
> more time the bigger the DMABUF gets. This is because the DMABUF is
> backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by up
> to 16 thousands pages, that have to be invalidated one by one. This can
> be addressed by using huge pages, but the udmabuf driver does not (yet)
> support creating DMABUFs backed by huge pages.

I'd imagine folios of reasonable size will help sort of a huge page
as then hopefully it will use the flush by va range instructions if
available.

> 
> Anyway, the real benefits happen when the DMABUFs are either shared
> between IIO devices, or between the IIO subsystem and another
> filesystem. In that case, the DMABUFs are simply passed around drivers,
> without the data being copied at any moment.
> 
> We use that feature to transfer samples from our transceivers to USB,
> using a DMABUF interface to FunctionFS [4].
> 
> This drastically increases the throughput, to about 274 MiB/s over a
> USB3 link, vs. 127 MiB/s using IIO's fileio interface + write() to the
> FunctionFS endpoints, for a lower CPU usage (0.85 vs. 0.65 load avg.).

This is a nice example.  Where are you with getting the patch merged?

Overall, this code looks fine to me, though there are some parts that
need review by other maintainers (e.g. Vinod for the dmaengine callback)
and I'd like a 'looks fine' at least form those who know a lot more
about dmabuf than I do.

To actually make this useful sounds like either udmabuf needs some perf
improvements, or there has to be an upstream case of sharing it without
something else (e.g your functionfs patches).  So what do we need to
get in before the positive benefit becomes worth carrying this extra
complexity? (which isn't too bad so I'm fine with a small benefit and
promises of riches :)

Jonathan

> 
> Based on linux-next/next-20231219.
> 
> Cheers,
> -Paul
> 
> [1] https://lore.kernel.org/all/20230807112113.47157-1-p...@crapouillou.net/
> [2] https://lore.kernel.org/all/20230403154800.215924-1-p...@crapouillou.net/
> [3] 
> https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api
> [4] https://lore.kernel.org/all/20230322092118.9213-1-p...@crapouillou.net/
> 
> ---
> Changelog:
> - [3/8]: Replace V3's dmaengine_prep_slave_dma_array() with a new
>   dmaengine_prep_slave_dma_vec(), which uses a new 'dma_vec' struct.
>   Note that at some point we will need to support cyclic transfers
>   using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
>   parameter to the function?
> 
> - [4/8]: Implement .device_prep_slave_dma_vec() 

Re: [PATCH v5 8/8] Documentation: iio: Document high-speed DMABUF based API

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:09 +0100
Paul Cercueil  wrote:

> Document the new DMABUF based API.
> 
> Signed-off-by: Paul Cercueil 
One minor comment inline.

> 
> ---
> v2: - Explicitly state that the new interface is optional and is
>   not implemented by all drivers.
> - The IOCTLs can now only be called on the buffer FD returned by
>   IIO_BUFFER_GET_FD_IOCTL.
> - Move the page up a bit in the index since it is core stuff and not
>   driver-specific.
> 
> v3: Update the documentation to reflect the new API.
> 
> v5: Use description lists for the documentation of the three new IOCTLs
> instead of abusing subsections.
> ---
>  Documentation/iio/dmabuf_api.rst | 54 
>  Documentation/iio/index.rst  |  2 ++
>  2 files changed, 56 insertions(+)
>  create mode 100644 Documentation/iio/dmabuf_api.rst
> 
> diff --git a/Documentation/iio/dmabuf_api.rst 
> b/Documentation/iio/dmabuf_api.rst
> new file mode 100644
> index ..1cd6cd51a582
> --- /dev/null
> +++ b/Documentation/iio/dmabuf_api.rst
> @@ -0,0 +1,54 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +High-speed DMABUF interface for IIO
> +===
> +
> +1. Overview
> +===
> +
> +The Industrial I/O subsystem supports access to buffers through a
> +file-based interface, with read() and write() access calls through the
> +IIO device's dev node.
> +
> +It additionally supports a DMABUF based interface, where the userspace
> +can attach DMABUF objects (externally created) to a IIO buffer, and
> +subsequently use them for data transfers.
> +
> +A userspace application can then use this interface to share DMABUF
> +objects between several interfaces, allowing it to transfer data in a
> +zero-copy fashion, for instance between IIO and the USB stack.
> +
> +The userspace application can also memory-map the DMABUF objects, and
> +access the sample data directly. The advantage of doing this vs. the
> +read() interface is that it avoids an extra copy of the data between the
> +kernel and userspace. This is particularly useful for high-speed devices
> +which produce several megabytes or even gigabytes of data per second.
> +It does however increase the userspace-kernelspace synchronization
> +overhead, as the DMA_BUF_SYNC_START and DMA_BUF_SYNC_END IOCTLs have to
> +be used for data integrity.
> +
> +2. User API
> +===
> +
> +As part of this interface, three new IOCTLs have been added. These three
> +IOCTLs have to be performed on the IIO buffer's file descriptor,
> +obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.

I would call out that they do not work on the main file descriptor (which
is arguably also a IIO buffer file descriptor).

> +
> +  ``IIO_BUFFER_DMABUF_ATTACH_IOCTL(int)``
> +Attach the DMABUF object, identified by its file descriptor, to the
> +IIO buffer. Returns zero on success, and a negative errno value on
> +error.
> +
> +  ``IIO_BUFFER_DMABUF_DETACH_IOCTL(int)``
> +Detach the given DMABUF object, identified by its file descriptor,
> +from the IIO buffer. Returns zero on success, and a negative errno
> +value on error.
> +
> +Note that closing the IIO buffer's file descriptor will
> +automatically detach all previously attached DMABUF objects.
> +
> +  ``IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *iio_dmabuf)``
> +Enqueue a previously attached DMABUF object to the buffer queue.
> +Enqueued DMABUFs will be read from (if output buffer) or written to
> +(if input buffer) as long as the buffer is enabled.

Re: [PATCH v5 7/8] iio: buffer-dmaengine: Support new DMABUF based userspace API

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:08 +0100
Paul Cercueil  wrote:

> Use the functions provided by the buffer-dma core to implement the
> DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
> 
> Since we want to be able to transfer an arbitrary number of bytes and
> not necesarily the full DMABUF, the associated scatterlist is converted
> to an array of DMA addresses + lengths, which is then passed to
> dmaengine_prep_slave_dma_array().
> 
> Signed-off-by: Paul Cercueil 
One question inline. Otherwise looks fine to me.

J
> 
> ---
> v3: Use the new dmaengine_prep_slave_dma_array(), and adapt the code to
> work with the new functions introduced in industrialio-buffer-dma.c.
> 
> v5: - Use the new dmaengine_prep_slave_dma_vec().
> - Restrict to input buffers, since output buffers are not yet
>   supported by IIO buffers.
> ---
>  .../buffer/industrialio-buffer-dmaengine.c| 52 ---
>  1 file changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c 
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 5f85ba38e6f6..825d76a24a67 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -64,15 +64,51 @@ static int iio_dmaengine_buffer_submit_block(struct 
> iio_dma_buffer_queue *queue,
>   struct dmaengine_buffer *dmaengine_buffer =
>   iio_buffer_to_dmaengine_buffer(>buffer);
>   struct dma_async_tx_descriptor *desc;
> + unsigned int i, nents;
> + struct scatterlist *sgl;
> + struct dma_vec *vecs;
> + size_t max_size;
>   dma_cookie_t cookie;
> + size_t len_total;
>  
> - block->bytes_used = min(block->size, dmaengine_buffer->max_size);
> - block->bytes_used = round_down(block->bytes_used,
> - dmaengine_buffer->align);
> + if (queue->buffer.direction != IIO_BUFFER_DIRECTION_IN) {
> + /* We do not yet support output buffers. */
> + return -EINVAL;
> + }
>  
> - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> - block->phys_addr, block->bytes_used, DMA_DEV_TO_MEM,
> - DMA_PREP_INTERRUPT);
> + if (block->sg_table) {
> + sgl = block->sg_table->sgl;
> + nents = sg_nents_for_len(sgl, block->bytes_used);

Are we guaranteed the length in the sglist is enough?  If not this
can return an error code.


> +
> + vecs = kmalloc_array(nents, sizeof(*vecs), GFP_KERNEL);
> + if (!vecs)
> + return -ENOMEM;
> +
> + len_total = block->bytes_used;
> +
> + for (i = 0; i < nents; i++) {
> + vecs[i].addr = sg_dma_address(sgl);
> + vecs[i].len = min(sg_dma_len(sgl), len_total);
> + len_total -= vecs[i].len;
> +
> + sgl = sg_next(sgl);
> + }
> +
> + desc = dmaengine_prep_slave_dma_vec(dmaengine_buffer->chan,
> + vecs, nents, DMA_DEV_TO_MEM,
> + DMA_PREP_INTERRUPT);
> + kfree(vecs);
> + } else {
> + max_size = min(block->size, dmaengine_buffer->max_size);
> + max_size = round_down(max_size, dmaengine_buffer->align);
> + block->bytes_used = max_size;
> +
> + desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> +block->phys_addr,
> +block->bytes_used,
> +DMA_DEV_TO_MEM,
> +DMA_PREP_INTERRUPT);
> + }
>   if (!desc)
>   return -ENOMEM;
>  

Re: [PATCH v5 6/8] iio: buffer-dma: Enable support for DMABUFs

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:07 +0100
Paul Cercueil  wrote:

> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
> 
> Signed-off-by: Paul Cercueil 
> 
Hi Paul,

A few comments in here. Mostly places where the cleanup.h guard() stuff
can simplify error paths.

Overall this looks reasonable to me.

Jonathan

> ---
> v3: Update code to provide the functions that will be used as callbacks
> for the new IOCTLs.
> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 157 +--
>  include/linux/iio/buffer-dma.h   |  26 +++
>  2 files changed, 170 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index 5610ba67925e..adb64f975064 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -94,14 +95,24 @@ static void iio_buffer_block_release(struct kref *kref)
>  {
>   struct iio_dma_buffer_block *block = container_of(kref,
>   struct iio_dma_buffer_block, kref);
> + struct iio_dma_buffer_queue *queue = block->queue;
>  
> - WARN_ON(block->state != IIO_BLOCK_STATE_DEAD);
> + WARN_ON(block->fileio && block->state != IIO_BLOCK_STATE_DEAD);
>  
> - dma_free_coherent(block->queue->dev, PAGE_ALIGN(block->size),
> - block->vaddr, block->phys_addr);
> + mutex_lock(>lock);
>  
> - iio_buffer_put(>queue->buffer);
> + if (block->fileio) {
> + dma_free_coherent(queue->dev, PAGE_ALIGN(block->size),
> +   block->vaddr, block->phys_addr);
> + queue->num_fileio_blocks--;
> + }
> +
> + queue->num_blocks--;
>   kfree(block);
> +
> + mutex_unlock(>lock);
> +
> + iio_buffer_put(>buffer);
>  }
>  
>  static void iio_buffer_block_get(struct iio_dma_buffer_block *block)
> @@ -163,7 +174,7 @@ static struct iio_dma_buffer_queue 
> *iio_buffer_to_queue(struct iio_buffer *buf)
>  }
>  
>  static struct iio_dma_buffer_block *iio_dma_buffer_alloc_block(
> - struct iio_dma_buffer_queue *queue, size_t size)
> + struct iio_dma_buffer_queue *queue, size_t size, bool fileio)
>  {
>   struct iio_dma_buffer_block *block;
>  
> @@ -171,13 +182,16 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_alloc_block(
>   if (!block)
>   return NULL;
>  
> - block->vaddr = dma_alloc_coherent(queue->dev, PAGE_ALIGN(size),
> - >phys_addr, GFP_KERNEL);
> - if (!block->vaddr) {
> - kfree(block);
> - return NULL;
> + if (fileio) {
> + block->vaddr = dma_alloc_coherent(queue->dev, PAGE_ALIGN(size),
> +   >phys_addr, 
> GFP_KERNEL);
> + if (!block->vaddr) {
> + kfree(block);
> + return NULL;
> + }
>   }
>  
> + block->fileio = fileio;
>   block->size = size;
>   block->state = IIO_BLOCK_STATE_DONE;
>   block->queue = queue;
> @@ -186,6 +200,9 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_alloc_block(
>  
>   iio_buffer_get(>buffer);
>  
> + queue->num_blocks++;
> + queue->num_fileio_blocks += fileio;
Adding a boolean is non intuitive.

if (fileio)
queue->num_fileio_blocks++;

probably easier to read and compiler should be able to figure out how to
optimise the condition away.

> +
>   return block;
>  }
>  
> @@ -211,6 +228,9 @@ void iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   _iio_dma_buffer_block_done(block);
>   spin_unlock_irqrestore(>list_lock, flags);
>  
> + if (!block->fileio)
> + iio_buffer_signal_dmabuf_done(block->attach, 0);
> +
>   iio_buffer_block_put_atomic(block);
>   wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
>  }
> @@ -237,10 +257,14 @@ void iio_dma_buffer_block_list_abort(struct 
> iio_dma_buffer_queue *queue,
>   list_del(>head);
>   block->bytes_used = 0;
>   _iio_dma_buffer_block_done(block);
> +
> + if (!block->fileio)
> + iio_buffer_signal_dmabuf_done(block->attach, -EINTR);
>   iio_buffer_block_put_atomic(block);
>   }
>   spin_unlock_irqrestore(>list_lock, flags);
>  
> + queue->fileio.enabled = false;

While this obviously doesn't need to be conditional if it can already be false
it might be easier to follow the code flow it if didn't check if we were doing
fileio or not before disabling it.

>   wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_list_abort);
> @@ -261,6 +285,12 @@ 

Re: [PATCH v5 5/8] iio: core: Add new DMABUF interface infrastructure

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:06 +0100
Paul Cercueil  wrote:

> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
> 
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transfer.
> 
> A userspace application can then use this interface to share DMABUF
> objects between several interfaces, allowing it to transfer data in a
> zero-copy fashion, for instance between IIO and the USB stack.
> 
> The userspace application can also memory-map the DMABUF objects, and
> access the sample data directly. The advantage of doing this vs. the
> read() interface is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.
> 
> As part of the interface, 3 new IOCTLs have been added:
> 
> IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
>  Attach the DMABUF object identified by the given file descriptor to the
>  buffer.
> 
> IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
>  Detach the DMABUF object identified by the given file descriptor from
>  the buffer. Note that closing the IIO buffer's file descriptor will
>  automatically detach all previously attached DMABUF objects.
> 
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
>  Request a data transfer to/from the given DMABUF object. Its file
>  descriptor, as well as the transfer size and flags are provided in the
>  "iio_dmabuf" structure.
> 
> These three IOCTLs have to be performed on the IIO buffer's file
> descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
> 

Fair enough - so they don't apply to the 'legacy' buffer which simplifies
things but in one place you assume that logic is used (given error return
values).

> Signed-off-by: Paul Cercueil 
> 
This is big and complex and I'm out of time for now, so I've made some
comments but should revisit it.
I'm also looking for review from those more familiar with dmabuf side
of things than I am!

Jonathan


>  
> +static int iio_dma_resv_lock(struct dma_buf *dmabuf, bool nonblock)
> +{
> + int ret;
> +
> + ret = dma_resv_lock_interruptible(dmabuf->resv, NULL);
> + if (ret) {
> + if (ret != -EDEADLK)
> + goto out;
> + if (nonblock) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + ret = dma_resv_lock_slow_interruptible(dmabuf->resv, NULL);
> + }
> +
> +out:
> + return ret;

I'm not a fan gotos that do nothing.  Just return in appropriate places above.

> +}
>
> +static int iio_buffer_detach_dmabuf(struct iio_dev_buffer_pair *ib, int 
> *user_req)
> +{
> + struct dma_buf_attachment *attach;
> + struct iio_dmabuf_priv *priv;
> + struct dma_buf *dmabuf;
> + int dmabuf_fd, ret = 0;
> +
> + if (copy_from_user(_fd, user_req, sizeof(dmabuf_fd)))
> + return -EFAULT;
> +
> + dmabuf = dma_buf_get(dmabuf_fd);
> + if (IS_ERR(dmabuf))
> + return PTR_ERR(dmabuf);
> +
> + attach = iio_buffer_find_attachment(ib->indio_dev, dmabuf);
> + if (IS_ERR(attach)) {
> + ret = PTR_ERR(attach);
> + goto out_dmabuf_put;
> + }
> +
> + priv = attach->importer_priv;
> + list_del_init(>entry);
> +
> + /*
> +  * Unref twice to release the reference obtained with
> +  * iio_buffer_find_attachment() above, and the one obtained in
> +  * iio_buffer_attach_dmabuf().
> +  */
> + iio_buffer_dmabuf_put(attach);
> + iio_buffer_dmabuf_put(attach);
> +
> +out_dmabuf_put:
> + dma_buf_put(dmabuf);
As below. Feels like a __free(dma_buf_put) bit of magic would be a nice to have.

> +
> + return ret;
> +}
> +
> +static const char *
> +iio_buffer_dma_fence_get_driver_name(struct dma_fence *fence)
> +{
> + return "iio";
> +}
> +
> +static void iio_buffer_dma_fence_release(struct dma_fence *fence)
> +{
> + struct iio_dma_fence *iio_fence =
> + container_of(fence, struct iio_dma_fence, base);
> +
> + kfree(iio_fence);
> +}
> +
> +static const struct dma_fence_ops iio_buffer_dma_fence_ops = {
> + .get_driver_name= iio_buffer_dma_fence_get_driver_name,
> + .get_timeline_name  = iio_buffer_dma_fence_get_driver_name,
> + .release= iio_buffer_dma_fence_release,
> +};
> +
> +static int iio_buffer_enqueue_dmabuf(struct iio_dev_buffer_pair *ib,
> +  struct iio_dmabuf __user *iio_dmabuf_req,
> +  bool nonblock)
> +{
> + struct iio_dev *indio_dev = ib->indio_dev;
> + struct iio_buffer *buffer = ib->buffer;
> + struct iio_dmabuf iio_dmabuf;
> + struct dma_buf_attachment *attach;
> + struct iio_dmabuf_priv *priv;
> + enum dma_data_direction dir;
> + struct iio_dma_fence *fence;
> + struct dma_buf *dmabuf;

Re: [PATCH v5 3/8] dmaengine: Add API function dmaengine_prep_slave_dma_vec()

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:04 +0100
Paul Cercueil  wrote:

> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
> 
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
> 
> Note that dmaengine_prep_interleaved_dma() is not helpful either in that
> case, as it assumes that the address of each segment will be higher than
> the one of the previous segment, which we just cannot guarantee in case
> of a scatter-gather transfer.
> 
> Signed-off-by: Paul Cercueil 

This and the next patch look fine to me as clearly simplify things for
our usecases, but they are really something for the dmaengine maintainers
to comment on.

Jonathan

Re: [PATCH v5 2/8] iio: buffer-dma: split iio_dma_buffer_fileio_free() function

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:03 +0100
Paul Cercueil  wrote:

> From: Alexandru Ardelean 
> 
> This change splits the logic into a separate function, which will be
> re-used later.
> 
> Signed-off-by: Alexandru Ardelean 
> Cc: Alexandru Ardelean 
> Signed-off-by: Paul Cercueil 
Harmless refactor so I'm fine taking this now to reduce noise on any
v6

Applied

Jonathan

Re: [PATCH v5 1/8] iio: buffer-dma: Get rid of outgoing queue

[Jonathan Cameron]

On Tue, 19 Dec 2023 18:50:02 +0100
Paul Cercueil  wrote:

> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
> 
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much easier to
> just check each block's state manually, and keep a counter for the next
> block to dequeue.
> 
> Since the new DMABUF based API wouldn't use the outgoing queue anyway,
> getting rid of it now makes the upcoming changes simpler.
> 
> With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
> be removed.
> 
> Signed-off-by: Paul Cercueil 
> 

I've applied this in interests in reducing the outstanding set of patches
and because it stands fine as on its own.

Applied to the togreg branch of iio.git and pushed out as testing.
Note this is now almost certainly 6.9 material given timing.

Jonathan

Re: [PATCH 10/17] dt-bindings: iio: samsung,exynos-adc: add specific compatibles for existing SoC

[Jonathan Cameron]

On Wed,  8 Nov 2023 11:43:36 +0100
Krzysztof Kozlowski  wrote:

> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski 
Acked-by: Jonathan Cameron 
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.
> ---
>  .../bindings/iio/adc/samsung,exynos-adc.yaml  | 29 +++
>  1 file changed, 17 insertions(+), 12 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml 
> b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
> index 582d0a03b814..4e40f6bed5db 100644
> --- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
> @@ -11,18 +11,23 @@ maintainers:
>  
>  properties:
>compatible:
> -enum:
> -  - samsung,exynos-adc-v1 # Exynos5250
> -  - samsung,exynos-adc-v2
> -  - samsung,exynos3250-adc
> -  - samsung,exynos4212-adc# Exynos4212 and Exynos4412
> -  - samsung,exynos7-adc
> -  - samsung,s3c2410-adc
> -  - samsung,s3c2416-adc
> -  - samsung,s3c2440-adc
> -  - samsung,s3c2443-adc
> -  - samsung,s3c6410-adc
> -  - samsung,s5pv210-adc
> +oneOf:
> +  - enum:
> +  - samsung,exynos-adc-v1 # Exynos5250
> +  - samsung,exynos-adc-v2
> +  - samsung,exynos3250-adc
> +  - samsung,exynos4212-adc# Exynos4212 and Exynos4412
> +  - samsung,exynos7-adc
> +  - samsung,s3c2410-adc
> +  - samsung,s3c2416-adc
> +  - samsung,s3c2440-adc
> +  - samsung,s3c2443-adc
> +  - samsung,s3c6410-adc
> +  - samsung,s5pv210-adc
> +  - items:
> +  - enum:
> +  - samsung,exynos5433-adc
> +  - const: samsung,exynos7-adc
>  
>reg:
>  maxItems: 1

Re: [PATCH] dt-bindings: cleanup DTS example whitespaces

[Jonathan Cameron]

On Sun,  2 Jul 2023 20:23:08 +0200
Krzysztof Kozlowski  wrote:

> The DTS code coding style expects spaces around '=' sign.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
For the IIO one.
Acked-by: Jonathan Cameron 

Thanks for tidying these up.

Jonathan

> ---
> 
> Rob,
> 
> Maybe this could go via your tree? Rebased on your for-next:
> v6.4-rc2-45-gf0ac35049606
> ---
>  .../bindings/arm/arm,coresight-cti.yaml| 18 +-
>  .../bindings/arm/keystone/ti,sci.yaml  |  8 
>  .../devicetree/bindings/display/msm/gmu.yaml   |  2 +-
>  .../display/panel/samsung,s6e8aa0.yaml |  2 +-
>  .../display/rockchip/rockchip-vop.yaml |  4 ++--
>  .../bindings/iio/adc/ti,adc108s102.yaml|  2 +-
>  .../bindings/media/renesas,rzg2l-cru.yaml  |  4 ++--
>  .../devicetree/bindings/media/renesas,vin.yaml |  4 ++--
>  .../devicetree/bindings/mtd/mtd-physmap.yaml   |  2 +-
>  .../bindings/net/mediatek-dwmac.yaml   |  2 +-
>  .../bindings/perf/amlogic,g12-ddr-pmu.yaml |  4 ++--
>  .../bindings/phy/mediatek,dsi-phy.yaml |  2 +-
>  .../remoteproc/amlogic,meson-mx-ao-arc.yaml|  2 +-
>  .../devicetree/bindings/usb/mediatek,mtu3.yaml |  2 +-
>  .../devicetree/bindings/usb/ti,am62-usb.yaml   |  2 +-
>  15 files changed, 30 insertions(+), 30 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml 
> b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
> index 0c5b875cb654..d6c84b6e7fe6 100644
> --- a/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
> +++ b/Documentation/devicetree/bindings/arm/arm,coresight-cti.yaml
> @@ -287,7 +287,7 @@ examples:
>  arm,trig-in-sigs = <0 1>;
>  arm,trig-in-types =PE_PMUIRQ>;  
> -arm,trig-out-sigs=<0 1 2 >;
> +arm,trig-out-sigs = <0 1 2 >;
>  arm,trig-out-types = PE_DBGRESTART
>PE_CTIIRQ>;  
> @@ -309,24 +309,24 @@ examples:
>  
>trig-conns@0 {
>  reg = <0>;
> -arm,trig-in-sigs=<0>;
> -arm,trig-in-types=;
> -arm,trig-out-sigs=<0>;
> -arm,trig-out-types=;
> +arm,trig-in-sigs = <0>;
> +arm,trig-in-types = ;
> +arm,trig-out-sigs = <0>;
> +arm,trig-out-types = ;
>  arm,trig-conn-name = "sys_profiler";
>};
>  
>trig-conns@1 {
>  reg = <1>;
> -arm,trig-out-sigs=<2 3>;
> -arm,trig-out-types=;
> +arm,trig-out-sigs = <2 3>;
> +arm,trig-out-types = ;
>  arm,trig-conn-name = "watchdog";
>};
>  
>trig-conns@2 {
>  reg = <2>;
> -arm,trig-in-sigs=<1 6>;
> -arm,trig-in-types=;
> +arm,trig-in-sigs = <1 6>;
> +arm,trig-in-types = ;
>  arm,trig-conn-name = "g_counter";
>};
>  };
> diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml 
> b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> index 91b96065f7df..86b59de7707e 100644
> --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> @@ -96,8 +96,8 @@ examples:
>compatible = "ti,k2g-sci";
>ti,system-reboot-controller;
>mbox-names = "rx", "tx";
> -  mboxes= < 5 2>,
> -  < 0 0>;
> +  mboxes = < 5 2>,
> +   < 0 0>;
>reg-names = "debug_messages";
>reg = <0x02921800 0x800>;
>  };
> @@ -107,8 +107,8 @@ examples:
>compatible = "ti,k2g-sci";
>ti,host-id = <12>;
>mbox-names = "rx", "tx";
> -  mboxes= <_proxy_main 11>,
> -  <_proxy_main 13>;
> +  mboxes = <_proxy_main 11>,
> +   <_proxy_main 13>;
>reg-names = "debug_messages";
>reg = <0x44083000 0x1000>;
>  
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml 
> b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> index 029d72822d8b..65b02c7a1211 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> @@ -225,7 +225,7 @@ examples:
>  #include 
>  
>  gmu: gmu@506a000 {
> -compatible="qcom,adreno-gmu-630.2", "qcom,adreno-

Re: [PATCH v3 03/11] iio: buffer-dma: Get rid of outgoing queue

[Jonathan Cameron]

On Tue, 18 Apr 2023 10:08:21 +0200
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Le dimanche 16 avril 2023 à 15:24 +0100, Jonathan Cameron a écrit :
> > On Mon,  3 Apr 2023 17:47:52 +0200
> > Paul Cercueil  wrote:
> >   
> > > The buffer-dma code was using two queues, incoming and outgoing, to
> > > manage the state of the blocks in use.
> > > 
> > > While this totally works, it adds some complexity to the code,
> > > especially since the code only manages 2 blocks. It is much easier
> > > to
> > > just check each block's state manually, and keep a counter for the
> > > next
> > > block to dequeue.
> > > 
> > > Since the new DMABUF based API wouldn't use the outgoing queue
> > > anyway,
> > > getting rid of it now makes the upcoming changes simpler.
> > > 
> > > With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and
> > > can
> > > be removed.
> > > 
> > > Signed-off-by: Paul Cercueil 
> > > 
> > > ---
> > > v2: - Only remove the outgoing queue, and keep the incoming queue,
> > > as we
> > >   want the buffer to start streaming data as soon as it is
> > > enabled.
> > >     - Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally
> > > the
> > >   same as IIO_BLOCK_STATE_DONE.  
> > 
> > I'm not that familiar with this code, but with my understanding this
> > makes
> > sense.   I think it is independent of the earlier patches and is a
> > useful
> > change in it's own right.  As such, does it make sense to pick this
> > up
> > ahead of the rest of the series? I'm assuming that discussion on the
> > rest will take a while.  No great rush as too late for the coming
> > merge
> > window anyway.  
> 
> Actually, you can pick patches 3 to 6 (when all have been acked). They
> add write support for buffer-dma implementations; which is a dependency
> for the rest of the patchset, but they can live on their own.

Remind me of that in the cover letter for v4.

Thanks,

Jonathan

> 
> Cheers,
> -Paul

Re: [PATCH v3 10/11] iio: buffer-dmaengine: Support new DMABUF based userspace API

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:49:54 +0200
Paul Cercueil  wrote:

> Use the functions provided by the buffer-dma core to implement the
> DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
> 
> Since we want to be able to transfer an arbitrary number of bytes and
> not necesarily the full DMABUF, the associated scatterlist is converted
> to an array of DMA addresses + lengths, which is then passed to
> dmaengine_prep_slave_dma_array().
> 
> Signed-off-by: Paul Cercueil 
A few things inline.

Thanks,

Jonathan

> 
> ---
> v3: Use the new dmaengine_prep_slave_dma_array(), and adapt the code to
> work with the new functions introduced in industrialio-buffer-dma.c.
> ---
>  .../buffer/industrialio-buffer-dmaengine.c| 69 ---
>  include/linux/iio/buffer-dma.h|  2 +
>  2 files changed, 60 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c 
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 866c8b84bb24..faed9c2b089c 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -65,25 +65,68 @@ static int iio_dmaengine_buffer_submit_block(struct 
> iio_dma_buffer_queue *queue,
>   iio_buffer_to_dmaengine_buffer(>buffer);
>   struct dma_async_tx_descriptor *desc;
>   enum dma_transfer_direction dma_dir;
> + unsigned int i, nents, *lenghts;
> + struct scatterlist *sgl;
> + unsigned long flags;
> + dma_addr_t *addrs;
>   size_t max_size;
>   dma_cookie_t cookie;
> + size_t len_total;
>  
> - max_size = min(block->size, dmaengine_buffer->max_size);
> - max_size = round_down(max_size, dmaengine_buffer->align);
> + if (!block->bytes_used)
> + return -EINVAL;
>  
> - if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> - block->bytes_used = max_size;
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
>   dma_dir = DMA_DEV_TO_MEM;
> - } else {
> + else
>   dma_dir = DMA_MEM_TO_DEV;
> - }
>  
> - if (!block->bytes_used || block->bytes_used > max_size)
> - return -EINVAL;

Ah this is dropping the code I moaned about earlier.  I'll probably
forget though so maybe add a note to that patch saying it goes
away later anyway so I don't keep moaning about it in future versions.

> + if (block->sg_table) {
> + sgl = block->sg_table->sgl;
> + nents = sg_nents_for_len(sgl, block->bytes_used);
> +
> + addrs = kmalloc_array(nents, sizeof(*addrs), GFP_KERNEL);
> + if (!addrs)
> + return -ENOMEM;
> +
> + lenghts = kmalloc_array(nents, sizeof(*lenghts), GFP_KERNEL);

lengths?

> + if (!lenghts) {
> + kfree(addrs);
> + return -ENOMEM;
> + }
> +
> + len_total = block->bytes_used;
>  
> - desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> - block->phys_addr, block->bytes_used, dma_dir,
> - DMA_PREP_INTERRUPT);
> + for (i = 0; i < nents; i++) {
> + addrs[i] = sg_dma_address(sgl);
> + lenghts[i] = min(sg_dma_len(sgl), len_total);
> + len_total -= lenghts[i];
> +
> + sgl = sg_next(sgl);
> + }
> +
> + flags = block->cyclic ? DMA_PREP_REPEAT : DMA_PREP_INTERRUPT;
> +
> + desc = dmaengine_prep_slave_dma_array(dmaengine_buffer->chan,
> +   addrs, lenghts, nents,
> +   dma_dir, flags);
> + kfree(addrs);
> + kfree(lenghts);
> + } else {
> + max_size = min(block->size, dmaengine_buffer->max_size);
> + max_size = round_down(max_size, dmaengine_buffer->align);
> +
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> + block->bytes_used = max_size;
> +
> + if (block->bytes_used > max_size)
> + return -EINVAL;
> +
> + desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> +block->phys_addr,
> +block->bytes_used, dma_dir,
> +DMA_PREP_INTERRUPT);
> + }


> diff --git a/include/linux/iio/buffer-dma.h b/include/linux/iio/buffer-dma.h
> index e5e5817e99db..48f7ffaf0867 100644
> --- a/include/linux/iio/buffer-dma.h
> +++ b/include/linux/iio/buffer-dma.h
> @@ -43,6 +43,7 @@ enum iio_block_state {
>   * @queue: Parent DMA buffer queue
>   * @kref: kref used to manage the lifetime of block
>   * @state: Current state of the block
> + * @cyclic: True if this is a cyclic buffer
>   * @fileio: True if this buffer is used for fileio 

Re: [PATCH v3 09/11] iio: buffer-dma: Enable support for DMABUFs

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:47:58 +0200
Paul Cercueil  wrote:

> Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
> and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
> DMA buffer implementations.
> 
> Signed-off-by: Paul Cercueil 
Hi Paul,

A few superficially comments.

Jonathan

> 
> ---
> v3: Update code to provide the functions that will be used as callbacks
> for the new IOCTLs.
> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 157 +--
>  include/linux/iio/buffer-dma.h   |  24 +++
>  2 files changed, 168 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index e14814e0d4c8..422bd784fd1e 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
...

> @@ -412,8 +448,12 @@ static void iio_dma_buffer_submit_block(struct 
> iio_dma_buffer_queue *queue,
>  
>   block->state = IIO_BLOCK_STATE_ACTIVE;
>   iio_buffer_block_get(block);
> +

Trivial, but I'd rather not see unrelated white space changes in a patch
doing anything else.

>   ret = queue->ops->submit(queue, block);
>   if (ret) {
> + if (!block->fileio)
> + iio_buffer_signal_dmabuf_done(block->attach, ret);
> +
>   /*
>* This is a bit of a problem and there is not much we can do
>* other then wait for the buffer to be disabled and re-enabled
> @@ -645,6 +685,97 @@ size_t iio_dma_buffer_data_available(struct iio_buffer 
> *buf)
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_data_available);

...

> +int iio_dma_buffer_enqueue_dmabuf(struct iio_buffer *buffer,
> +   struct iio_dma_buffer_block *block,
> +   struct sg_table *sgt,
> +   size_t size, bool cyclic)
> +{
> + struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
> + int ret = 0;

No need to init.

> +
> + mutex_lock(>lock);
> + ret = iio_dma_can_enqueue_block(block);
> + if (ret < 0)
> + goto out_mutex_unlock;
> +
> + block->bytes_used = size;
> + block->cyclic = cyclic;
> + block->sg_table = sgt;
> +
> + iio_dma_buffer_enqueue(queue, block);
> +
> +out_mutex_unlock:
> + mutex_unlock(>lock);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iio_dma_buffer_enqueue_dmabuf);

Obviously an unrelated activity but good to namespace these
in a future patch set.

> +
>  /**
>   * iio_dma_buffer_set_bytes_per_datum() - DMA buffer set_bytes_per_datum 
> callback
>   * @buffer: Buffer to set the bytes-per-datum for
> diff --git a/include/linux/iio/buffer-dma.h b/include/linux/iio/buffer-dma.h
> index 490b93f76fa8..e5e5817e99db 100644
> --- a/include/linux/iio/buffer-dma.h
> +++ b/include/linux/iio/buffer-dma.h

>  /**
>   * enum iio_block_state - State of a struct iio_dma_buffer_block
> @@ -41,6 +43,7 @@ enum iio_block_state {
>   * @queue: Parent DMA buffer queue
>   * @kref: kref used to manage the lifetime of block
>   * @state: Current state of the block
> + * @fileio: True if this buffer is used for fileio mode

Docs need update for the other two new elements.

>   */
>  struct iio_dma_buffer_block {
>   /* May only be accessed by the owner of the block */
> @@ -63,6 +66,11 @@ struct iio_dma_buffer_block {
>* queue->list_lock if the block is not owned by the core.
>*/
>   enum iio_block_state state;
> +
> + bool fileio;
> +
> + struct dma_buf_attachment *attach;
> + struct sg_table *sg_table;
>  };

Re: [PATCH v3 07/11] iio: core: Add new DMABUF interface infrastructure

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:47:56 +0200
Paul Cercueil  wrote:

> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
> 
> With this new interface, DMABUF objects (externally created) can be
> attached to a IIO buffer, and subsequently used for data transfer.
> 
> A userspace application can then use this interface to share DMABUF
> objects between several interfaces, allowing it to transfer data in a
> zero-copy fashion, for instance between IIO and the USB stack.
> 
> The userspace application can also memory-map the DMABUF objects, and
> access the sample data directly. The advantage of doing this vs. the
> read() interface is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.

I like numbers to support a patch.  Any nice ones to throw in here
as examples of expected rates?

> 
> As part of the interface, 3 new IOCTLs have been added:
> 
> IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd):
>  Attach the DMABUF object identified by the given file descriptor to the
>  buffer.
> 
> IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd):
>  Detach the DMABUF object identified by the given file descriptor from
>  the buffer. Note that closing the IIO buffer's file descriptor will
>  automatically detach all previously attached DMABUF objects.
> 
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
>  Request a data transfer to/from the given DMABUF object. Its file
>  descriptor, as well as the transfer size and flags are provided in the
>  "iio_dmabuf" structure.
> 
> These three IOCTLs have to be performed on the IIO buffer's file
> descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.
> 
> Signed-off-by: Paul Cercueil 
> 

Trivial comments from me.  I don't (yet) understand dmabuf well enough
to know if that part is right or not.  Not sure I will ever find the time
so relying on those who are more familiar with it to tell me if that code
is correct.

Thanks,

Jonathan



>  static int iio_buffer_chrdev_release(struct inode *inode, struct file *filep)
>  {
>   struct iio_dev_buffer_pair *ib = filep->private_data;
>   struct iio_dev *indio_dev = ib->indio_dev;
>   struct iio_buffer *buffer = ib->buffer;
> + struct iio_dmabuf_priv *priv, *tmp;
>  
>   wake_up(>pollq);
>  
> + /* Close all attached DMABUFs */
> + list_for_each_entry_safe(priv, tmp, >dmabufs, entry) {
> + list_del_init(>entry);
> + iio_buffer_dmabuf_put(priv->attach);
> + }
> +
> + /* TODO: Is it safe? Can "ib" be freed here? */

No idea :)  However that need resolving before we apply this.

> + if (!list_empty(>dmabufs))
> + dev_warn(_dev->dev, "Buffer FD closed with active 
> transfers\n");
> +
>   kfree(ib);
>   clear_bit(IIO_BUSY_BIT_POS, >flags);
>   iio_device_put(indio_dev);
> @@ -1515,11 +1591,337 @@ static int iio_buffer_chrdev_release(struct inode 
> *inode, struct file *filep)
>   return 0;
>  }
>  




> +static int iio_buffer_enqueue_dmabuf(struct iio_dev_buffer_pair *ib,
> +  struct iio_dmabuf __user *iio_dmabuf_req,
> +  bool nonblock)
> +{

...

> +
> + ret = buffer->access->enqueue_dmabuf(buffer, priv->block, sgt,
> +  iio_dmabuf.bytes_used, cyclic);
> + if (ret)

Hmm. Is there an easy way to perhaps avoid a function with multiple
error handling paths like we have here.  Perhaps drag the
extra stuff from the the dmabuf_done() function into this if (ret)
then goto err_fence_put;?  I'm not sure if that would make this even
harder to read however.

> + iio_buffer_signal_dmabuf_done(attach, ret);
> +
> + dma_buf_put(dmabuf);
> +
> + return ret;
> +
> +err_resv_unlock:
> + dma_resv_unlock(dmabuf->resv);
> +err_fence_put:
> + dma_fence_put(>base);
> +err_unmap_attachment:
> + dma_buf_unmap_attachment(attach, sgt, dir);
> +err_attachment_put:
> + iio_buffer_dmabuf_put(attach);
> +err_dmabuf_put:
> + dma_buf_put(dmabuf);
> +
> + return ret;
> +}
> +
> +void iio_buffer_signal_dmabuf_done(struct dma_buf_attachment *attach, int 
> ret)
> +{
> + struct iio_dmabuf_priv *priv = attach->importer_priv;
> + struct iio_dma_fence *fence = priv->fence;
> + enum dma_data_direction dir = fence->dir;
> + struct sg_table *sgt = fence->sgt;
> +
> + dma_fence_get(>base);
> + fence->base.error = ret;
> + dma_fence_signal(>base);
> + dma_fence_put(>base);
> +
> + dma_buf_unmap_attachment(attach, sgt, dir);
> + iio_buffer_dmabuf_put(attach);
> +}
> +EXPORT_SYMBOL_GPL(iio_buffer_signal_dmabuf_done);

...

> diff --git a/include/linux/iio/buffer_impl.h b/include/linux/iio/buffer_impl.h
> index 89c3fd7c29ca..a8a490091277 100644
> --- a/include/linux/iio/buffer_impl.h
> +++ 

Re: [PATCH v3 06/11] iio: buffer-dmaengine: Enable write support

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:47:55 +0200
Paul Cercueil  wrote:

> Use the iio_dma_buffer_write() and iio_dma_buffer_space_available()
> functions provided by the buffer-dma core, to enable write support in
> the buffer-dmaengine code.
> 
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Alexandru Ardelean 
> ---
>  drivers/iio/buffer/industrialio-buffer-dmaengine.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c 
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 592d2aa9044c..866c8b84bb24 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -123,12 +123,14 @@ static void iio_dmaengine_buffer_release(struct 
> iio_buffer *buf)
>  
>  static const struct iio_buffer_access_funcs iio_dmaengine_buffer_ops = {
>   .read = iio_dma_buffer_read,
> + .write = iio_dma_buffer_write,
>   .set_bytes_per_datum = iio_dma_buffer_set_bytes_per_datum,
>   .set_length = iio_dma_buffer_set_length,
>   .request_update = iio_dma_buffer_request_update,
>   .enable = iio_dma_buffer_enable,
>   .disable = iio_dma_buffer_disable,
>   .data_available = iio_dma_buffer_data_available,
> + .space_available = iio_dma_buffer_space_available,
Follow through from earlier patch.  I would prefer it to be obvious
hers that the two callbacks above are identical.  Easiest way to
expose that detail is to set the callbacks to the same function, but then
it perhaps needs a rename so it isn't specific to one of the other.

Jonathan

>   .release = iio_dmaengine_buffer_release,
>  
>   .modes = INDIO_BUFFER_HARDWARE,

Re: [PATCH v3 05/11] iio: buffer-dmaengine: Support specifying buffer direction

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:47:54 +0200
Paul Cercueil  wrote:

> Update the devm_iio_dmaengine_buffer_setup() function to support
> specifying the buffer direction.
> 
> Update the iio_dmaengine_buffer_submit() function to handle input
> buffers as well as output buffers.
> 
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Alexandru Ardelean 

Just one trivial question inline.

Jonathan

> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c 
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 5f85ba38e6f6..592d2aa9044c 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -64,14 +64,25 @@ static int iio_dmaengine_buffer_submit_block(struct 
> iio_dma_buffer_queue *queue,
>   struct dmaengine_buffer *dmaengine_buffer =
>   iio_buffer_to_dmaengine_buffer(>buffer);
>   struct dma_async_tx_descriptor *desc;
> + enum dma_transfer_direction dma_dir;
> + size_t max_size;
>   dma_cookie_t cookie;
>  
> - block->bytes_used = min(block->size, dmaengine_buffer->max_size);
> - block->bytes_used = round_down(block->bytes_used,
> - dmaengine_buffer->align);
> + max_size = min(block->size, dmaengine_buffer->max_size);
> + max_size = round_down(max_size, dmaengine_buffer->align);
> +
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> + block->bytes_used = max_size;
> + dma_dir = DMA_DEV_TO_MEM;
> + } else {
> + dma_dir = DMA_MEM_TO_DEV;
> + }
> +
> + if (!block->bytes_used || block->bytes_used > max_size)
> + return -EINVAL;

Two paths to here.  Either DIRECTION_IN in which we just set things
up so conditions being checked are always fine (unless max_size == 0?
Can that happen?), or !DIRECTION_IN.
So why not move this into the else {} branch above?

>  
>   desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,
> - block->phys_addr, block->bytes_used, DMA_DEV_TO_MEM,
> + block->phys_addr, block->bytes_used, dma_dir,
>   DMA_PREP_INTERRUPT);
>   if (!desc)
>   return -ENOMEM;

Re: [PATCH v3 04/11] iio: buffer-dma: Enable buffer write support

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:47:53 +0200
Paul Cercueil  wrote:

> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
> 
> Therefore, the iio_buffer_dma_read() and the new iio_buffer_dma_write()
> now both call a function iio_buffer_dma_io(), which will perform this
> task.
> 
> The .space_available() callback can return the exact same value as the
> .data_available() callback for input buffers, since in both cases we
> count the exact same thing (the number of bytes in each available
> block).

As they are doing the same thing, I'd like that to be visible down
where the callback is set.  As such, do we need a wrapper to
provide the space available version?  Perhaps just give the
data_available version a more generic name to make it seem
appropriate for both usecases?

Otherwise LGTM.

Jonathan


> 
> Note that we preemptively reset block->bytes_used to the buffer's size
> in iio_dma_buffer_request_update(), as in the future the
> iio_dma_buffer_enqueue() function won't reset it.
> 
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Alexandru Ardelean 
> 
> ---
> v2: - Fix block->state not being reset in
>   iio_dma_buffer_request_update() for output buffers.
> - Only update block->bytes_used once and add a comment about why we
>   update it.
> - Add a comment about why we're setting a different state for output
>   buffers in iio_dma_buffer_request_update()
> - Remove useless cast to bool (!!) in iio_dma_buffer_io()
> 
> v3: - Reorganize arguments to iio_dma_buffer_io()
> - Change 'is_write' argument to 'is_from_user'
> - Change (__force char *) to (__force __user char *), in
>   iio_dma_buffer_write(), since we only want to drop the "const".
> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 89 
>  include/linux/iio/buffer-dma.h   |  7 ++
>  2 files changed, 80 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index 1fc91467d1aa..86eced458236 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -195,6 +195,18 @@ static void _iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   block->state = IIO_BLOCK_STATE_DONE;
>  }
>  
> +static void iio_dma_buffer_queue_wake(struct iio_dma_buffer_queue *queue)
> +{
> + __poll_t flags;
> +
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> + flags = EPOLLIN | EPOLLRDNORM;
> + else
> + flags = EPOLLOUT | EPOLLWRNORM;
> +
> + wake_up_interruptible_poll(>buffer.pollq, flags);
> +}
> +
>  /**
>   * iio_dma_buffer_block_done() - Indicate that a block has been completed
>   * @block: The completed block
> @@ -212,7 +224,7 @@ void iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   spin_unlock_irqrestore(>list_lock, flags);
>  
>   iio_buffer_block_put_atomic(block);
> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> + iio_dma_buffer_queue_wake(queue);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_done);
>  
> @@ -241,7 +253,7 @@ void iio_dma_buffer_block_list_abort(struct 
> iio_dma_buffer_queue *queue,
>   }
>   spin_unlock_irqrestore(>list_lock, flags);
>  
> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> + iio_dma_buffer_queue_wake(queue);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_list_abort);
>  
> @@ -335,8 +347,24 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> *buffer)
>   queue->fileio.blocks[i] = block;
>   }
>  
> - block->state = IIO_BLOCK_STATE_QUEUED;
> - list_add_tail(>head, >incoming);
> + /*
> +  * block->bytes_used may have been modified previously, e.g. by
> +  * iio_dma_buffer_block_list_abort(). Reset it here to the
> +  * block's so that iio_dma_buffer_io() will work.
> +  */
> + block->bytes_used = block->size;
> +
> + /*
> +  * If it's an input buffer, mark the block as queued, and
> +  * iio_dma_buffer_enable() will submit it. Otherwise mark it as
> +  * done, which means it's ready to be dequeued.
> +  */
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> + block->state = IIO_BLOCK_STATE_QUEUED;
> + list_add_tail(>head, >incoming);
> + } else {
> + block->state = IIO_BLOCK_STATE_DONE;
> + }
>   }
>  
>  out_unlock:
> @@ -465,20 +493,12 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_dequeue(
>   return block;
>  }
>  
> -/**
> - * iio_dma_buffer_read() - DMA 

Re: [PATCH v3 03/11] iio: buffer-dma: Get rid of outgoing queue

[Jonathan Cameron]

On Mon,  3 Apr 2023 17:47:52 +0200
Paul Cercueil  wrote:

> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
> 
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much easier to
> just check each block's state manually, and keep a counter for the next
> block to dequeue.
> 
> Since the new DMABUF based API wouldn't use the outgoing queue anyway,
> getting rid of it now makes the upcoming changes simpler.
> 
> With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
> be removed.
> 
> Signed-off-by: Paul Cercueil 
> 
> ---
> v2: - Only remove the outgoing queue, and keep the incoming queue, as we
>   want the buffer to start streaming data as soon as it is enabled.
> - Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the
>   same as IIO_BLOCK_STATE_DONE.

I'm not that familiar with this code, but with my understanding this makes
sense.   I think it is independent of the earlier patches and is a useful
change in it's own right.  As such, does it make sense to pick this up
ahead of the rest of the series? I'm assuming that discussion on the
rest will take a while.  No great rush as too late for the coming merge
window anyway.

Thanks,

Jonathan

Re: [PATCH v4 0/8] Support ROHM BU27034 ALS sensor

[Jonathan Cameron]

On Fri, 17 Mar 2023 16:40:16 +0200
Matti Vaittinen  wrote:

> Support ROHM BU27034 ALS sensor

Hi Matti,

For ease of when this is ready to apply, better to just keep
key mailing lists and individuals cc'd on all patches.

Mind you cc list is random enough I'm guessing it wasn't
deliberate (like the maintainers patch 8 only went to lkml
where no one will notice it)

I can scrape these all of lore, but it's a step that not
all reviewers are going to bother with.

Jonathan



> 
> This series adds support for ROHM BU27034 Ambient Light Sensor.
> 
> The BU27034 has configurable gain and measurement (integration) time
> settings. Both of these have inversely proportional relation to the
> sensor's intensity channel scale.
> 
> Many users only set the scale, which means that many drivers attempt to
> 'guess' the best gain+time combination to meet the scale. Usually this
> is the biggest integration time which allows setting the requested
> scale. Typically, increasing the integration time has better accuracy
> than increasing the gain, which often amplifies the noise as well as the
> real signal.
> 
> However, there may be cases where more responsive sensors are needed.
> So, in some cases the longest integration times may not be what the user
> prefers. The driver has no way of knowing this.
> 
> Hence, the approach taken by this series is to allow user to set both
> the scale and the integration time with following logic:
> 
> 1. When scale is set, the existing integration time is tried to be
>maintained as a first priority.
>1a) If the requested scale can't be met by current time, then also
>other time + gain combinations are searched. If scale can be met
>by some other integration time, then the new time may be applied.
>If the time setting is common for all channels, then also other
>channels must be able to maintain their scale with this new time
>(by changing their gain). The new times are scanned in the order
>of preference (typically the longest times first).
>1b) If the requested scale can be met using current time, then only
>the gain for the channel is changed.
> 
> 2. When the integration time change - scale is tried to be maintained.
>When integration time change is requested also gain for all impacted
>channels is adjusted so that the scale is not changed, or is chaned
>as little as possible. This is different from the RFCv1 where the
>request was rejected if suitable gain couldn't be found for some
>channel(s).
> 
> This logic is simple. When total gain (either caused by time or hw-gain)
> is doubled, the scale gets halved. Also, the supported times are given a
> 'multiplier' value which tells how much they increase the total gain.
> 
> However, when I wrote this logic in bu27034 driver, I made quite a few
> errors on the way - and driver got pretty big. As I am writing drivers
> for two other sensors (RGB C/IR + flicker BU27010 and RGB C/IR BU27008)
> with similar gain-time-scale logic I thought that adding common helpers
> for these computations might be wise. I hope this way all the bugs will
> be concentrated in one place and not in every individual driver ;)
> 
> Hence, this series also intriduces IIO gain-time-scale helpers
> (abbreviated as gts-helpers) + a couple of KUnit tests for the most
> hairy parts.
> 
> Speaking of which - testing the devm interfaces requires a 'dummy
> device'. There were neat helpers in DRM tests for creating and freeing
> such a device. This series moves those helpers to more generic location.
> What is worth noting is that there is something similar ongoing in the
> CCF territory:
> https://lore.kernel.org/all/20230302013822.1808711-1-sb...@kernel.org/
> These efforts should be somehow coordinated in order to avoid any ajor
> conflicts.
> 
> Finally, these added helpers do provide some value also for drivers
> which only:
>  a) allow gain change
>   or
>  b) allow changing both the time and gain while trying to maintain the
> scale.
> 
> For a) we provide the gain - selector (register value) table format +
> selector to gain look-ups, gain <-> scale conversions and the available
> scales helpers.
> 
> For latter case we also provide the time-tables, and actually all the
> APIs should be usable by setting the time multiplier to 1. (not testeted
> thoroughly though).
> 
> Revision history:
> v3 => v4: (Stil ostly fixes to review comments from Andy and Jonathan)
> - more accurate change-log in individual patches
> - dt-binding and maintainer patches unchanged.
> - dropped unused helpers and converted ones currently used only internally
>   to static.
> - extracted "dummy device" creation helpers from DRM tests.
> - added tests for devm APIs
> - dropped scale for PROCESSED channel in BU27034 and converted mLux
>   values to luxes
> - dropped channel 2 GAIN setting which can't be done due to HW
>   limitations.
> 
> v2 => v3: (Mostly fixes to review comments from Andy and 

Re: [PATCH v2 04/13] iio: imu: Replace all spi->chip_select and spi->cs_gpiod references with function call

[Jonathan Cameron]

On Fri, 20 Jan 2023 00:23:33 +0530
Amit Kumar Mahapatra  wrote:

> Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
> members of struct spi_device to be an array. But changing the type of these
> members to array would break the spi driver functionality. To make the
> transition smoother introduced four new APIs to get/set the
> spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and
> spi->cs_gpiod references with get or set API calls.
> While adding multi-cs support in further patches the chip_select & cs_gpiod
> members of the spi_device structure would be converted to arrays & the
> "idx" parameter of the APIs would be used as array index i.e.,
> spi->chip_select[idx] & spi->cs_gpiod[idx] respectively.
> 
> Signed-off-by: Amit Kumar Mahapatra 

Acked-by: Jonathan Cameron 

> ---
>  drivers/iio/imu/adis16400.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/imu/adis16400.c b/drivers/iio/imu/adis16400.c
> index c02fc35dceb4..3eda32e12a53 100644
> --- a/drivers/iio/imu/adis16400.c
> +++ b/drivers/iio/imu/adis16400.c
> @@ -466,7 +466,7 @@ static int adis16400_initial_setup(struct iio_dev 
> *indio_dev)
>  
>   dev_info(_dev->dev, "%s: prod_id 0x%04x at CS%d (irq 
> %d)\n",
>   indio_dev->name, prod_id,
> - st->adis.spi->chip_select, st->adis.spi->irq);
> + spi_get_chipselect(st->adis.spi, 0), st->adis.spi->irq);
>   }
>   /* use high spi speed if possible */
>   if (st->variant->flags & ADIS16400_HAS_SLOW_MODE) {

Re: [PATCH] dt-bindings: Remove "status" from schema examples, again

[Jonathan Cameron]

On Fri, 14 Oct 2022 15:51:04 -0500
Rob Herring  wrote:

> There's no reason to have "status" properties in examples. "okay" is the
> default, and "disabled" turns off some schema checks ('required'
> specifically).
> 
> A meta-schema check for this is pending, so hopefully the last time to
> fix these.
> 
> Fix the indentation in intel,phy-thunderbay-emmc while we're here.
> 
> Signed-off-by: Rob Herring 
Acked-by: Jonathan Cameron  #for-iio

> ---
>  .../arm/tegra/nvidia,tegra-ccplex-cluster.yaml|  1 -
>  .../display/tegra/nvidia,tegra124-dpaux.yaml  |  1 -
>  .../display/tegra/nvidia,tegra186-display.yaml|  2 --
>  .../bindings/iio/addac/adi,ad74413r.yaml  |  1 -
>  .../devicetree/bindings/net/cdns,macb.yaml|  1 -
>  .../devicetree/bindings/net/nxp,dwmac-imx.yaml|  1 -
>  .../bindings/phy/intel,phy-thunderbay-emmc.yaml   | 15 +++
>  7 files changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
>  
> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
> index 711bb4d08c60..869c266e7ebc 100644
> --- 
> a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
> +++ 
> b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml
> @@ -47,5 +47,4 @@ examples:
>compatible = "nvidia,tegra234-ccplex-cluster";
>reg = <0x0e00 0x5>;
>nvidia,bpmp = <>;
> -  status = "okay";
>  };
> diff --git 
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml 
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
> index 9ab123cd2325..5cdbc527a560 100644
> --- 
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
> +++ 
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-dpaux.yaml
> @@ -128,7 +128,6 @@ examples:
>  resets = <_car 181>;
>  reset-names = "dpaux";
>  power-domains = <_sor>;
> -status = "disabled";
>  
>  state_dpaux_aux: pinmux-aux {
>  groups = "dpaux-io";
> diff --git 
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
>  
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
> index 8c0231345529..ce5c673f940c 100644
> --- 
> a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
> +++ 
> b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-display.yaml
> @@ -138,7 +138,6 @@ examples:
>   < TEGRA186_CLK_NVDISPLAY_DSC>,
>   < TEGRA186_CLK_NVDISPLAYHUB>;
>  clock-names = "disp", "dsc", "hub";
> -status = "disabled";
>  
>  power-domains = < TEGRA186_POWER_DOMAIN_DISP>;
>  
> @@ -227,7 +226,6 @@ examples:
>  clocks = < TEGRA194_CLK_NVDISPLAY_DISP>,
>   < TEGRA194_CLK_NVDISPLAYHUB>;
>  clock-names = "disp", "hub";
> -status = "disabled";
>  
>  power-domains = < TEGRA194_POWER_DOMAIN_DISP>;
>  
> diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml 
> b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml
> index 03bb90a7f4f8..d2a9f92c0a6d 100644
> --- a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml
> +++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml
> @@ -114,7 +114,6 @@ examples:
>#size-cells = <0>;
>  
>cs-gpios = < 17 GPIO_ACTIVE_LOW>;
> -  status = "okay";
>  
>ad74413r@0 {
>  compatible = "adi,ad74413r";
> diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml 
> b/Documentation/devicetree/bindings/net/cdns,macb.yaml
> index 318f4efe7f6f..bef5e0f895be 100644
> --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml
> +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml
> @@ -203,7 +203,6 @@ examples:
>  power-domains = <_firmware PD_ETH_1>;
>  resets = <_reset ZYNQMP_RESET_GEM1>;
>  reset-names = "gem1_rst";
> -status = "okay";
>  phy-mode = "sgmii";
>  phys = < 1 PHY_TYPE_SGMII 1 1>;
>  fixed-link {
> diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml 
> b/Documentation

Re: [PATCH v7 06/13] dt-bindings: mfd: Add MediaTek MT6370

[Jonathan Cameron]

On Tue, 9 Aug 2022 14:14:14 +0100
Lee Jones  wrote:

> On Fri, 05 Aug 2022, ChiaEn Wu wrote:
> 
> > From: ChiYuan Huang 
> > 
> > Add MediaTek MT6370 binding documentation.
> > 
> > Reviewed-by: Krzysztof Kozlowski 
> > Signed-off-by: ChiYuan Huang 
> > Signed-off-by: ChiaEn Wu 
> > ---
> >  .../devicetree/bindings/mfd/mediatek,mt6370.yaml   | 280 
> > +
> >  include/dt-bindings/iio/adc/mediatek,mt6370_adc.h  |  18 ++
> >  2 files changed, 298 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> >  create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h  
> 
> Applied, thanks.
> 
Hi Lee,

The iio: adc: patch is dependent on this (due to the binding header) -
so either you should pick that up as well, or it'll get delayed until what
you've picked up is available upstream - or I guess some hackery to allow them
to go via different trees and flip to the header only once all the prior steps
are in place.

Note I'd messed up sending an Ack on the ADC patch which I've now fixed.

Thanks,

Jonathan

Re: [PATCH v7 09/13] iio: adc: mt6370: Add MediaTek MT6370 support

[Jonathan Cameron]

On Fri, 5 Aug 2022 12:54:04 +0200
Andy Shevchenko  wrote:

> On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu  wrote:
> >
> > From: ChiaEn Wu 
> >
> > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> > driver, display bias voltage supply, one general purpose LDO, and the
> > USB Type-C & PD controller complies with the latest USB Type-C and PD
> > standards.
> >
> > Add a support for the MT6370 ADC driver for system monitoring, including
> > charger current, voltage, and temperature.  
> 
> On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu  wrote:
> >
> > From: ChiYuan Huang 
> >
> > The MediaTek MT6370 is a highly-integrated smart power management IC,
> > which includes a single cell Li-Ion/Li-Polymer switching battery
> > charger, a USB Type-C & Power Delivery (PD) controller, dual
> > Flash LED current sources, a RGB LED driver, a backlight WLED driver,
> > a display bias driver and a general LDO for portable devices.
> >
> > Add a support for the Type-C & Power Delivery controller in
> > MediaTek MT6370 IC.  
> 
> Reviewed-by: Andy Shevchenko 
Oops. I just noticed I replied only to Andy due to a misclick.

Acked-by: Jonathan Cameron 

I took a quick glance through, and with Andy's comments now all answered
to his satisfaction I'm fine with this going through the MFD tree
(or another path if one makes more sense).

Thanks to Andy for his reviewing effort on this one!

Note that because of the bindings header I think this has a build dependency on 
the
MFD binding patch.

Jonathan


> 
> > Reviewed-by: AngeloGioacchino Del Regno 
> > 
> > Signed-off-by: ChiaEn Wu 
> > ---
> >
> > v7
> > - Add AICR(100mA ~ 350mA), ICHG(100mA ~ 800mA) macros
> > - Remove 400mA AICR and 900mA ICHG macros
> > - Revise using 'if-else' to 'switch-case' in mt6370_adc_read_scale()
> >   where the adc channel is ibus or ibat
> > ---
> >  drivers/iio/adc/Kconfig  |  12 ++
> >  drivers/iio/adc/Makefile |   1 +
> >  drivers/iio/adc/mt6370-adc.c | 305 
> > +++
> >  3 files changed, 318 insertions(+)
> >  create mode 100644 drivers/iio/adc/mt6370-adc.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7fe5930..995cbb5 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -736,6 +736,18 @@ config MEDIATEK_MT6360_ADC
> >   is used in smartphones and tablets and supports a 11 channel
> >   general purpose ADC.
> >
> > +config MEDIATEK_MT6370_ADC
> > +   tristate "MediaTek MT6370 ADC driver"
> > +   depends on MFD_MT6370
> > +   help
> > + Say yes here to enable MediaTek MT6370 ADC support.
> > +
> > + This ADC driver provides 9 channels for system monitoring (charger
> > + current, voltage, and temperature).
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called "mt6370-adc".
> > +
> >  config MEDIATEK_MT6577_AUXADC
> > tristate "MediaTek AUXADC driver"
> > depends on ARCH_MEDIATEK || COMPILE_TEST
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 1772a54..c6bc35f 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -68,6 +68,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
> >  obj-$(CONFIG_MCP3422) += mcp3422.o
> >  obj-$(CONFIG_MCP3911) += mcp3911.o
> >  obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
> > +obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
> >  obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> >  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> >  obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> > diff --git a/drivers/iio/adc/mt6370-adc.c b/drivers/iio/adc/mt6370-adc.c
> > new file mode 100644
> > index 000..2a46471
> > --- /dev/null
> > +++ b/drivers/iio/adc/mt6370-adc.c
> > @@ -0,0 +1,305 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2022 Richtek Technology Corp.
> > + *
> > + * Author: ChiaEn Wu 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#define MT6370_REG_CHG_CTRL3 

Re: [PATCH v2 1/1] spi/panel: dt-bindings: drop CPHA and CPOL from common properties

[Jonathan Cameron]

On Fri, 22 Jul 2022 21:15:39 +0200
Krzysztof Kozlowski  wrote:

> The spi-cpha and spi-cpol properties are device specific and should be
> accepted only if device really needs them.  Drop them from common
> spi-peripheral-props.yaml schema, mention in few panel drivers which use
> them and include instead in the SPI controller bindings.  The controller
> bindings will provide CPHA/CPOL type validation and one place for
> description.  Each device schema must list the properties if they are
> applicable.
> 
> Suggested-by: Jonathan Cameron 
> Suggested-by: Rob Herring 
> Signed-off-by: Krzysztof Kozlowski 

This seems like a good solution to me.

Reviewed-by: Jonathan Cameron 

> ---
>  .../bindings/display/panel/lgphilips,lb035q02.yaml|  3 +++
>  .../bindings/display/panel/samsung,ld9040.yaml|  3 +++
>  .../bindings/display/panel/sitronix,st7789v.yaml  |  3 +++
>  .../devicetree/bindings/display/panel/tpo,td.yaml |  3 +++
>  .../devicetree/bindings/spi/spi-controller.yaml   | 11 +++
>  .../devicetree/bindings/spi/spi-peripheral-props.yaml | 10 --
>  6 files changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml 
> b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
> index 5e4e0e552c2f..628c4b898111 100644
> --- a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml
> @@ -21,6 +21,9 @@ properties:
>enable-gpios: true
>port: true
>  
> +  spi-cpha: true
> +  spi-cpol: true
> +
>  required:
>- compatible
>- enable-gpios
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml 
> b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
> index d525165d6d63..c0fabeb38628 100644
> --- a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml
> @@ -42,6 +42,9 @@ properties:
>panel-height-mm:
>  description: physical panel height [mm]
>  
> +  spi-cpha: true
> +  spi-cpol: true
> +
>  required:
>- compatible
>- reg
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml 
> b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
> index 9e1d707c2ace..d984b59daa4a 100644
> --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml
> @@ -23,6 +23,9 @@ properties:
>backlight: true
>port: true
>  
> +  spi-cpha: true
> +  spi-cpol: true
> +
>  required:
>- compatible
>- reg
> diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml 
> b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
> index f902a9d74141..e8c8ee8d7c88 100644
> --- a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml
> @@ -28,6 +28,9 @@ properties:
>backlight: true
>port: true
>  
> +  spi-cpha: true
> +  spi-cpol: true
> +
>  required:
>- compatible
>- port
> diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml 
> b/Documentation/devicetree/bindings/spi/spi-controller.yaml
> index 678cee68b52a..655713fba7e2 100644
> --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml
> +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml
> @@ -95,6 +95,17 @@ patternProperties:
>  type: object
>  $ref: spi-peripheral-props.yaml
>  
> +properties:
> +  spi-cpha:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> +  The device requires shifted clock phase (CPHA) mode.
> +
> +  spi-cpol:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description:
> +  The device requires inverse clock polarity (CPOL) mode.
> +
>  required:
>- compatible
>- reg
> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml 
> b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> index 5e32928c4fc3..2349f83c07f3 100644
> --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml
> @@ -34,16 +34,6 @@ properties:
>  description:
>The device requires 3-wire mode.
>  
> -  spi-cpha:
> -$ref: /schemas/types.yaml#/definitions/flag
> -description:
> -  The device requires shifted clock phase (CPHA) mode.
> -
> -  spi-cpol:
> -$ref: /schemas/types.yaml#/definitions/flag
> -description:
> -  The device requires inverse clock polarity (CPOL) mode.
> -
>spi-cs-high:
>  $ref: /schemas/types.yaml#/definitions/flag
>  description:

Re: [PATCH v2 07/15] Documentation: ABI: testing: mt6370: Add ADC sysfs guideline

[Jonathan Cameron]

On Mon, 20 Jun 2022 14:00:43 +0800
ChiaEn Wu  wrote:

> Hi Jonathan,
> 
> Thanks for your helpful comments, and I have some questions want to
> ask you below.
> 
> Jonathan Cameron  於 2022年6月18日 週六 晚上11:39寫道：
> >
> > On Mon, 13 Jun 2022 19:11:38 +0800
> > ChiaEn Wu  wrote:
> >  
> > > From: ChiaEn Wu 
> > >
> > > Add ABI documentation for mt6370 non-standard ADC sysfs interfaces.
> > >
> > > Signed-off-by: ChiaEn Wu 
> > > ---
> > >  .../ABI/testing/sysfs-bus-iio-adc-mt6370  | 36 +++
> > >  1 file changed, 36 insertions(+)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 
> > > b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370
> > > new file mode 100644
> > > index ..039b3381176a
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370
> > > @@ -0,0 +1,36 @@
> > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw  
> >
> > Unfortunately the kernel documentation build scripts do no support 
> > duplicating
> > standard ABI for particular devices so as to provide more information.
> > Hence you can't have anything in this file.
> >  
> 
> I want to confirm with you again,
> because my ABI file duplicates with standard sysfs-bus-iio (voltage,
> current, and temperature channels),
> Should I just remove this ABI file and modify the code of mt6370-adc
> to meet your expectations??

yes.

> 
> >  
> > > +KernelVersion:   5.18
> > > +Contact: chiaen...@richtek.com
> > > +Description:
> > > + Indicated MT6370 VBUS ADC with lower accuracy(+-75mA)  
> > Curious though, voltage with a mA accuracy range?  
> 
> Yes, this description is based on the data sheet.

Weird :) 

> 
> > This scale should be presented directly to userspace anyway so no need
> > for this doc.
> >  
> > > + higher measure range(1~22V)
> > > + Calculating with scale returns voltage in uV  
> >
> > No. All channels return in mV. That's the ABI requirement as
> > in sysfs-bus-iio and we cannot vary if for particular drivers.  If we did
> > no generic tooling would work.  
> 
> Ok, I got it!
> 
> >  
> > > +
> > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw
> > > +KernelVersion:   5.18
> > > +Contact: chiaen...@richtek.com
> > > +Description:
> > > + Indicated MT6370 VBUS ADC with higher accuracy(+-30mA)
> > > + lower measure range(1~9.76V)
> > > + Calculating with scale offset returns voltage in uV
> > > +
> > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage4_raw
> > > +KernelVersion:   5.18
> > > +Contact: chiaen...@richtek.com
> > > +Description:
> > > + Indicated MT6370 TS_BAT ADC
> > > + Calculating with scale returns voltage in uV
> > > +
> > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage7_raw
> > > +KernelVersion:   5.18
> > > +Contact: chiaen...@richtek.com
> > > +Description:
> > > + Indicated MT6370 CHG_VDDP ADC
> > > + Calculating with scale returns voltage in mV
> > > +
> > > +What:/sys/bus/iio/devices/iio:deviceX/in_temp8_raw
> > > +KernelVersion:   5.18
> > > +Contact: chiaen...@richtek.com
> > > +Description:
> > > + Indicated MT6370 IC junction temperature
> > > + Calculating with scale and offset returns temperature in 
> > > degree  
> 
> Shall I modify the scale of temperature to milli degrees in
> mt6370-adc.c and remove this item??

yes.

Thanks,

Jonathan

> 
> >  
> 
> Best regards,
> ChiaEn Wu

Re: [PATCH v2 11/15] iio: adc: mt6370: Add Mediatek MT6370 support

[Jonathan Cameron]

On Mon, 13 Jun 2022 19:11:42 +0800
ChiaEn Wu  wrote:

> From: ChiaEn Wu 
> 
> Add Mediatek MT6370 ADC support.
> 
> Signed-off-by: ChiaEn Wu 

Hi ChiaEn Wu,

A few comments inline, but mostly looks good to me
with the exception of the scales which look far too large.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/Kconfig  |   9 ++
>  drivers/iio/adc/Makefile |   1 +
>  drivers/iio/adc/mt6370-adc.c | 262 +++
>  3 files changed, 272 insertions(+)
>  create mode 100644 drivers/iio/adc/mt6370-adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 71ab0a06aa82..09576fb478ad 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -737,6 +737,15 @@ config MEDIATEK_MT6360_ADC
> is used in smartphones and tablets and supports a 11 channel
> general purpose ADC.
>  
> +config MEDIATEK_MT6370_ADC
> + tristate "Mediatek MT6370 ADC driver"
> + depends on MFD_MT6370
> + help
> +   Say Y here to enable MT6370 ADC support.
> +
> +   Integrated for System Monitoring includes is used in smartphones
> +   and tablets and supports a 9 channel general purpose ADC.
> +
>  config MEDIATEK_MT6577_AUXADC
>   tristate "MediaTek AUXADC driver"
>   depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 39d806f6d457..0ce285c7e2d0 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -68,6 +68,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>  obj-$(CONFIG_MCP3422) += mcp3422.o
>  obj-$(CONFIG_MCP3911) += mcp3911.o
>  obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
> +obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o
>  obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
>  obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>  obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> diff --git a/drivers/iio/adc/mt6370-adc.c b/drivers/iio/adc/mt6370-adc.c
> new file mode 100644
> index ..c30e1290973a
> --- /dev/null
> +++ b/drivers/iio/adc/mt6370-adc.c
> @@ -0,0 +1,262 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

#include 
rather than relying on indirect include for
struct of_device_id

We've just removed such an include path from IIO and had
to fix up a lot of drivers that falsely assumed that would
available.

> +#include 
> +#include 
> +#include 
> +
> +#define MT6370_REG_CHG_CTRL3 0x113 /* AICR */
> +#define MT6370_REG_CHG_CTRL7 0x117 /* ICHG */
> +#define MT6370_REG_CHG_ADC   0x121
> +#define MT6370_REG_ADC_DATA_H0x14C
> +
> +#define MT6370_ADC_START_MASKBIT(0)
> +#define MT6370_ADC_IN_SEL_MASK   GENMASK(7, 4)
> +#define MT6370_AICR_ICHG_MASKGENMASK(7, 2)
> +
> +#define MT6370_AICR_400MA0x6
> +#define MT6370_ICHG_500MA0x4
> +#define MT6370_ICHG_900MA0x8
> +
> +#define ADC_CONV_TIME_US 35000
> +#define ADC_CONV_POLLING_TIME1000
> +
> +struct mt6370_adc_data {
> + struct device *dev;
> + struct regmap *regmap;
> + struct mutex adc_lock;
Please document scope of the lock.  I think it's to synchronize
access to the device state concerned with channel reads, but there
should be a comment here to say something about that.
> +};
> +
> +static int mt6370_adc_read_channel(struct mt6370_adc_data *priv, int chan,
> +unsigned long addr, int *val)
> +{
> + __be16 be_val;
> + unsigned int reg_val;
> + int ret;
> +
> + mutex_lock(>adc_lock);
> +
> + reg_val = MT6370_ADC_START_MASK |
> +   FIELD_PREP(MT6370_ADC_IN_SEL_MASK, addr);
> + ret = regmap_write(priv->regmap, MT6370_REG_CHG_ADC, reg_val);
> + if (ret)
> + goto adc_unlock;
> +
> + msleep(ADC_CONV_TIME_US / 1000);
> +
> + ret = regmap_read_poll_timeout(priv->regmap,
> +MT6370_REG_CHG_ADC, reg_val,
> +!(reg_val & MT6370_ADC_START_MASK),
> +ADC_CONV_POLLING_TIME,
> +ADC_CONV_TIME_US * 3);
> + if (ret) {
> + if (ret == -ETIMEDOUT)
> + dev_err(priv->dev, "Failed to wait adc conversion\n");
Why are any other error here not worth reporting?  I'd print a message for
all return values.

> + goto adc_unlock;
> + }
> +
> + ret = regmap_raw_read(priv->regmap, MT6370_REG_ADC_DATA_H,
> +   _val, sizeof(be_val));
> + if (ret)
> + goto adc_unlock;
> +
> + *val = be16_to_cpu(be_val);
> + ret = IIO_VAL_INT;
> +
> +adc_unlock:
> + mutex_unlock(>adc_lock);
> +
> + return ret;
> +}
> +
> +static int mt6370_adc_read_scale(struct mt6370_adc_data *priv,
> +  int chan, int *val1, int *val2)
> +{
> +   

Re: [PATCH v2 08/15] mfd: mt6370: Add Mediatek MT6370 support

[Jonathan Cameron]

On Mon, 13 Jun 2022 19:11:39 +0800
ChiaEn Wu  wrote:

> From: ChiYuan Huang 
> 
> Add Mediatek MT6370 MFD support.
> 
> Signed-off-by: ChiYuan Huang 
Hi.

A few trivial things that probably overlap with other reviewer
comments.


> +static int mt6370_check_vendor_info(struct mt6370_info *info)
> +{
> + unsigned int devinfo;
> + int ret;
> +
> + ret = regmap_read(info->regmap, MT6370_REG_DEV_INFO, );
> + if (ret)
> + return ret;
> +
> + switch (FIELD_GET(MT6370_VENID_MASK, devinfo)) {
> + case 0x8: /* RT5081 */
> + case 0xA: /* RT5081A */
> + case 0xE: /* MT6370 */
> + case 0xF: /* MT6371 */
> + case 0x9: /* MT6372P */
> + case 0xB: /* MT6372CP */
> + break;
> + default:
> + dev_err(info->dev, "Not invalid value 0x%02x\n", devinfo);

Double negative... You mean "Invalid value" 
though you probably want to say something more specific such as
"Unknown Vendor ID 0x%02x\n")

> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static int mt6370_regmap_read(void *context, const void *reg_buf,
> +   size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct mt6370_info *info = context;
> + u8 bank_idx = *(u8 *)reg_buf, bank_addr = *(u8 *)(reg_buf + 1);
> + int ret;
> +
> + ret = i2c_smbus_read_i2c_block_data(info->i2c[bank_idx], bank_addr,
> + val_size, val_buf);
> + if (ret != val_size)
> + return ret;
If it's positive , that is probably not what regmap expects.
See handling in here
https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap-i2c.c#L222

> +
> + return 0;
> +}


> +
> +static int mt6370_probe(struct i2c_client *i2c)
> +{
> + struct mt6370_info *info;
> + struct i2c_client *usbc_i2c;
> + int ret;
> +
> + info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + info->dev = >dev;
> +
> + usbc_i2c = devm_i2c_new_dummy_device(>dev, i2c->adapter,
> +  MT6370_USBC_I2CADDR);
> + if (IS_ERR(usbc_i2c)) {
> + ret = PTR_ERR(usbc_i2c);
> + dev_err(>dev, "Failed to register usbc i2c client %d\n", 
> ret);
Might as well use
return dev_err_probe(>dev, PTR_ERR(usb_i2c),
 "Failed to register USBC I2C client\n");

Whilst the defer handling isn't relevant, it is safe to use throughout probe
and tidier in this case at least.

> + return ret;
> + }
> +
> + /* Assign I2C client for PMU and TypeC */
> + info->i2c[MT6370_PMU_I2C] = i2c;
> + info->i2c[MT6370_USBC_I2C] = usbc_i2c;
> +
> + info->regmap = devm_regmap_init(>dev, _regmap_bus, info,
> + _regmap_config);
> + if (IS_ERR(info->regmap)) {
> + ret = PTR_ERR(info->regmap);
> + dev_err(>dev, "Failed to register regmap (%d)\n", ret);

as above dev_err_probe() will tidy this and following cases up for you.

> + return ret;
> + }
> +
> + ret = mt6370_check_vendor_info(info);
> + if (ret) {
> + dev_err(>dev, "Failed to check vendor info (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = devm_regmap_add_irq_chip(>dev, info->regmap, i2c->irq,
> +IRQF_ONESHOT, -1, _irq_chip,
> +>irq_data);
> + if (ret) {
> + dev_err(>dev, "Failed to add irq chip (%d)\n", ret);
> + return ret;
> + }
> +
> + return devm_mfd_add_devices(>dev, PLATFORM_DEVID_AUTO,
> + mt6370_devices, ARRAY_SIZE(mt6370_devices),
> + NULL, 0,
> + regmap_irq_get_domain(info->irq_data));
> +}

Re: [PATCH v2 07/15] Documentation: ABI: testing: mt6370: Add ADC sysfs guideline

[Jonathan Cameron]

On Mon, 13 Jun 2022 19:11:38 +0800
ChiaEn Wu  wrote:

> From: ChiaEn Wu 
> 
> Add ABI documentation for mt6370 non-standard ADC sysfs interfaces.
> 
> Signed-off-by: ChiaEn Wu 
> ---
>  .../ABI/testing/sysfs-bus-iio-adc-mt6370  | 36 +++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370 
> b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370
> new file mode 100644
> index ..039b3381176a
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6370
> @@ -0,0 +1,36 @@
> +What:/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw

Unfortunately the kernel documentation build scripts do no support duplicating
standard ABI for particular devices so as to provide more information.
Hence you can't have anything in this file.


> +KernelVersion:   5.18
> +Contact: chiaen...@richtek.com
> +Description:
> + Indicated MT6370 VBUS ADC with lower accuracy(+-75mA)
Curious though, voltage with a mA accuracy range?
This scale should be presented directly to userspace anyway so no need
for this doc.

> + higher measure range(1~22V)
> + Calculating with scale returns voltage in uV

No. All channels return in mV. That's the ABI requirement as
in sysfs-bus-iio and we cannot vary if for particular drivers.  If we did
no generic tooling would work.

> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw
> +KernelVersion:   5.18
> +Contact: chiaen...@richtek.com
> +Description:
> + Indicated MT6370 VBUS ADC with higher accuracy(+-30mA)
> + lower measure range(1~9.76V)
> + Calculating with scale offset returns voltage in uV
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_voltage4_raw
> +KernelVersion:   5.18
> +Contact: chiaen...@richtek.com
> +Description:
> + Indicated MT6370 TS_BAT ADC
> + Calculating with scale returns voltage in uV
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_voltage7_raw
> +KernelVersion:   5.18
> +Contact: chiaen...@richtek.com
> +Description:
> + Indicated MT6370 CHG_VDDP ADC
> + Calculating with scale returns voltage in mV
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_temp8_raw
> +KernelVersion:   5.18
> +Contact: chiaen...@richtek.com
> +Description:
> + Indicated MT6370 IC junction temperature
> + Calculating with scale and offset returns temperature in degree

Re: [RESEND 10/14] iio: adc: mt6370: Add Mediatek MT6370 support

[Jonathan Cameron]

> >  
> > > +
> > > +#define MT6370_AICR_400MA0x6
> > > +#define MT6370_ICHG_500MA0x4
> > > +#define MT6370_ICHG_900MA0x8
> > > +
> > > +#define ADC_CONV_TIME_US 35000
> > > +#define ADC_CONV_POLLING_TIME1000
> > > +
> > > +struct mt6370_adc_data {
> > > + struct device *dev;
> > > + struct regmap *regmap;
> > > + struct mutex lock;  
> >
> > All locks need documentation.  What is the scope of the lock?
> > Looks like it protects device state when doing setup, wait for read, read
> > cycles.  
> 
> This mutex lock is for preventing the different adc channel from being
> read at the same time.
> So, if I just change its name to adc_chan_lock or adc_lock and add the
> comment for this mutex lock, does this change meet your requirement

Yes

> 
> >  
> > > +};
> > > +
> > > +static int mt6370_adc_read_scale(struct mt6370_adc_data *priv,
> > > +  int chan, int *val1, int *val2)
> > > +{
> > > + unsigned int reg_val;
> > > + int ret;
> > > +
> > > + switch (chan) {
> > > + case MT6370_CHAN_VBAT:
> > > + case MT6370_CHAN_VSYS:
> > > + case MT6370_CHAN_CHG_VDDP:
> > > + *val1 = 5000;  
> >
> > This seems very large.  Voltages are in millivolts
> > as per Documentation/ABI/testing/sysfs-bus-iio
> > and this means each step is 5 volts.
> >
> > So value in mv is currently 5 * _raw
> >  
> 
> OK, I got it. Also, I will add the ABI file in the next version. Thanks!
Only add ABI documentation for anything non-standard.

The documentation scripts really don't like repeats!

> 
> > > +static const char * const mt6370_channel_labels[MT6370_CHAN_MAX] = {  
> >
> > Perhaps define an enum with which to index this and the chan spec
> > and hence ensure they end up matching.
> >  [vbusdiv5] = "vbusdiv5", etc
> >  
> 
> Do you mean that I can refine this const char array to the following array??
> 
> static const char * const mt6370_channel_labels[MT6370_CHAN_MAX] = {
> [MT6370_CHAN_VBUSDIV5] =  "vbusdiv5",
> [MT6370_CHAN_VBUSDIV2] =  "vbusdiv2",
> ...
> ...
> [MT6370_CHAN_TEMP_JC] =  "temp_jc",
> };

Yes

thanks,

Jonathan

Re: [PATCH] dt-bindings: Drop redundant 'maxItems/minItems' in if/then schemas

[Jonathan Cameron]

On Tue,  3 May 2022 11:27:38 -0500
Rob Herring  wrote:

> Another round of removing redundant minItems/maxItems when 'items' list is
> specified. This time it is in if/then schemas as the meta-schema was
> failing to check this case.
> 
> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.

Acked-by: Jonathan Cameron  #for IIO
> 
> Cc: Abel Vesa 
> Cc: Stephen Boyd 
> Cc: Krzysztof Kozlowski 
> Cc: Laurent Pinchart 
> Cc: Kieran Bingham 
> Cc: Jonathan Cameron 
> Cc: Lars-Peter Clausen 
> Cc: Ulf Hansson 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Miquel Raynal 
> Cc: Richard Weinberger 
> Cc: Vignesh Raghavendra 
> Cc: Wolfgang Grandegger 
> Cc: Marc Kleine-Budde 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: Paolo Abeni 
> Cc: Kishon Vijay Abraham I 
> Cc: Vinod Koul 
> Cc: Alessandro Zummo 
> Cc: Alexandre Belloni 
> Cc: Chen-Yu Tsai 
> Cc: Greg Kroah-Hartman 
> Cc: Mark Brown 
> Cc: "Rafael J. Wysocki" 
> Cc: Daniel Lezcano 
> Cc: Zhang Rui 
> Cc: "Niklas Söderlund" 
> Cc: Anson Huang 
> Cc: Fabrice Gasnier 
> Cc: Han Xu 
> Cc: Dario Binacchi 
> Cc: Florian Fainelli 
> Cc: Maxime Ripard 
> Cc: Peter Ujfalusi 
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../bindings/clock/imx8m-clock.yaml   |  4 
>  .../bindings/display/bridge/renesas,lvds.yaml |  4 
>  .../bindings/display/renesas,du.yaml  | 23 ---
>  .../bindings/iio/adc/st,stm32-adc.yaml|  2 --
>  .../bindings/mmc/nvidia,tegra20-sdhci.yaml|  7 +-
>  .../devicetree/bindings/mtd/gpmi-nand.yaml|  2 --
>  .../bindings/net/can/bosch,c_can.yaml |  3 ---
>  .../bindings/phy/brcm,sata-phy.yaml   | 10 
>  .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 10 
>  .../bindings/serial/samsung_uart.yaml |  4 
>  .../sound/allwinner,sun4i-a10-i2s.yaml|  1 -
>  .../bindings/sound/ti,j721e-cpb-audio.yaml|  2 --
>  .../bindings/thermal/rcar-gen3-thermal.yaml   |  1 -
>  13 files changed, 5 insertions(+), 68 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml 
> b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> index 625f573a7b90..458c7645ee68 100644
> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> @@ -55,8 +55,6 @@ allOf:
>  then:
>properties:
>  clocks:
> -  minItems: 7
> -  maxItems: 7
>items:
>  - description: 32k osc
>  - description: 25m osc
> @@ -66,8 +64,6 @@ allOf:
>  - description: ext3 clock input
>  - description: ext4 clock input
>  clock-names:
> -  minItems: 7
> -  maxItems: 7
>items:
>  - const: ckil
>  - const: osc_25m
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml 
> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> index a51baf8a4c76..bb9dbfb9beaf 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> @@ -95,7 +95,6 @@ then:
>properties:
>  clocks:
>minItems: 1
> -  maxItems: 4
>items:
>  - description: Functional clock
>  - description: EXTAL input clock
> @@ -104,7 +103,6 @@ then:
>  
>  clock-names:
>minItems: 1
> -  maxItems: 4
>items:
>  - const: fck
>  # The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks.
> @@ -128,12 +126,10 @@ then:
>  else:
>properties:
>  clocks:
> -  maxItems: 1
>items:
>  - description: Functional clock
>  
>  clock-names:
> -  maxItems: 1
>items:
>  - const: fck
>  
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml 
> b/Documentation/

Re: [PATCH v2 07/12] iio: buffer-dma: Use DMABUFs instead of custom solution

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:28 +
Paul Cercueil  wrote:

> Enhance the current fileio code by using DMABUF objects instead of
> custom buffers.
> 
> This adds more code than it removes, but:
> - a lot of the complexity can be dropped, e.g. custom kref and
>   iio_buffer_block_put_atomic() are not needed anymore;
> - it will be much easier to introduce an API to export these DMABUF
>   objects to userspace in a following patch.
> 
> Signed-off-by: Paul Cercueil 
Hi Paul,

I'm a bit rusty on dma mappings, but you seem to have
a mixture of streaming and coherent mappings going on in here.

Is it the case that the current code is using the coherent mappings
and a potential 'other user' of the dma buffer might need
streaming mappings?

Jonathan

> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 192 ---
>  include/linux/iio/buffer-dma.h   |   8 +-
>  2 files changed, 122 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index 15ea7bc3ac08..54e6000cd2ee 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -90,103 +91,145 @@
>   * callback is called from within the custom callback.
>   */
>  
> -static void iio_buffer_block_release(struct kref *kref)
> -{
> - struct iio_dma_buffer_block *block = container_of(kref,
> - struct iio_dma_buffer_block, kref);
> -
> - WARN_ON(block->state != IIO_BLOCK_STATE_DEAD);
> -
> - dma_free_coherent(block->queue->dev, PAGE_ALIGN(block->size),
> - block->vaddr, block->phys_addr);
> -
> - iio_buffer_put(>queue->buffer);
> - kfree(block);
> -}
> -
> -static void iio_buffer_block_get(struct iio_dma_buffer_block *block)
> -{
> - kref_get(>kref);
> -}
> -
> -static void iio_buffer_block_put(struct iio_dma_buffer_block *block)
> -{
> - kref_put(>kref, iio_buffer_block_release);
> -}
> -
> -/*
> - * dma_free_coherent can sleep, hence we need to take some special care to be
> - * able to drop a reference from an atomic context.
> - */
> -static LIST_HEAD(iio_dma_buffer_dead_blocks);
> -static DEFINE_SPINLOCK(iio_dma_buffer_dead_blocks_lock);
> -
> -static void iio_dma_buffer_cleanup_worker(struct work_struct *work)
> -{
> - struct iio_dma_buffer_block *block, *_block;
> - LIST_HEAD(block_list);
> -
> - spin_lock_irq(_dma_buffer_dead_blocks_lock);
> - list_splice_tail_init(_dma_buffer_dead_blocks, _list);
> - spin_unlock_irq(_dma_buffer_dead_blocks_lock);
> -
> - list_for_each_entry_safe(block, _block, _list, head)
> - iio_buffer_block_release(>kref);
> -}
> -static DECLARE_WORK(iio_dma_buffer_cleanup_work, 
> iio_dma_buffer_cleanup_worker);
> -
> -static void iio_buffer_block_release_atomic(struct kref *kref)
> -{
> +struct iio_buffer_dma_buf_attachment {
> + struct scatterlist sgl;
> + struct sg_table sg_table;
>   struct iio_dma_buffer_block *block;
> - unsigned long flags;
> -
> - block = container_of(kref, struct iio_dma_buffer_block, kref);
> -
> - spin_lock_irqsave(_dma_buffer_dead_blocks_lock, flags);
> - list_add_tail(>head, _dma_buffer_dead_blocks);
> - spin_unlock_irqrestore(_dma_buffer_dead_blocks_lock, flags);
> -
> - schedule_work(_dma_buffer_cleanup_work);
> -}
> -
> -/*
> - * Version of iio_buffer_block_put() that can be called from atomic context
> - */
> -static void iio_buffer_block_put_atomic(struct iio_dma_buffer_block *block)
> -{
> - kref_put(>kref, iio_buffer_block_release_atomic);
> -}
> +};
>  
>  static struct iio_dma_buffer_queue *iio_buffer_to_queue(struct iio_buffer 
> *buf)
>  {
>   return container_of(buf, struct iio_dma_buffer_queue, buffer);
>  }
>  
> +static struct iio_buffer_dma_buf_attachment *
> +to_iio_buffer_dma_buf_attachment(struct sg_table *table)
> +{
> + return container_of(table, struct iio_buffer_dma_buf_attachment, 
> sg_table);
> +}
> +
> +static void iio_buffer_block_get(struct iio_dma_buffer_block *block)
> +{
> + get_dma_buf(block->dmabuf);
> +}
> +
> +static void iio_buffer_block_put(struct iio_dma_buffer_block *block)
> +{
> + dma_buf_put(block->dmabuf);
> +}
> +
> +static int iio_buffer_dma_buf_attach(struct dma_buf *dbuf,
> +  struct dma_buf_attachment *at)
> +{
> + at->priv = dbuf->priv;
> +
> + return 0;
> +}
> +
> +static struct sg_table *iio_buffer_dma_buf_map(struct dma_buf_attachment *at,
> +enum dma_data_direction dma_dir)
> +{
> + struct iio_dma_buffer_block *block = at->priv;
> + struct iio_buffer_dma_buf_attachment *dba;
> + int ret;
> +
> + dba = kzalloc(sizeof(*dba), GFP_KERNEL);
> + if (!dba)
> + return ERR_PTR(-ENOMEM);
> +
> + sg_init_one(>sgl, 

Re: [PATCH v2 05/12] iio: core: Add new DMABUF interface infrastructure

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:26 +
Paul Cercueil  wrote:

> Add the necessary infrastructure to the IIO core to support a new
> optional DMABUF based interface.
> 
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed

useful

> devices which produce several megabytes or even gigabytes of data per
> second.
> 
> The data in this new DMABUF interface is managed at the granularity of
> DMABUF objects. Reducing the granularity from byte level to block level
> is done to reduce the userspace-kernelspace synchronization overhead
> since performing syscalls for each byte at a few Mbps is just not
> feasible.
> 
> This of course leads to a slightly increased latency. For this reason an
> application can choose the size of the DMABUFs as well as how many it
> allocates. E.g. two DMABUFs would be a traditional double buffering
> scheme. But using a higher number might be necessary to avoid
> underflow/overflow situations in the presence of scheduling latencies.
> 
> As part of the interface, 2 new IOCTLs have been added:
> 
> IIO_BUFFER_DMABUF_ALLOC_IOCTL(struct iio_dmabuf_alloc_req *):
>  Each call will allocate a new DMABUF object. The return value (if not
>  a negative errno value as error) will be the file descriptor of the new
>  DMABUF.
> 
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
>  Place the DMABUF object into the queue pending for hardware process.
> 
> These two IOCTLs have to be performed on the IIO buffer's file
> descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl.

Just to check, do they work on the old deprecated chardev route? Normally
we can directly access the first buffer without the ioctl.

> 
> To access the data stored in a block by userspace the block must be
> mapped to the process's memory. This is done by calling mmap() on the
> DMABUF's file descriptor.
> 
> Before accessing the data through the map, you must use the
> DMA_BUF_IOCTL_SYNC(struct dma_buf_sync *) ioctl, with the
> DMA_BUF_SYNC_START flag, to make sure that the data is available.
> This call may block until the hardware is done with this block. Once
> you are done reading or writing the data, you must use this ioctl again
> with the DMA_BUF_SYNC_END flag, before enqueueing the DMABUF to the
> kernel's queue.
> 
> If you need to know when the hardware is done with a DMABUF, you can
> poll its file descriptor for the EPOLLOUT event.
> 
> Finally, to destroy a DMABUF object, simply call close() on its file
> descriptor.
> 
> A typical workflow for the new interface is:
> 
>   for block in blocks:
> DMABUF_ALLOC block
> mmap block
> 
>   enable buffer
> 
>   while !done
> for block in blocks:
>   DMABUF_ENQUEUE block
> 
>   DMABUF_SYNC_START block
>   process data
>   DMABUF_SYNC_END block
> 
>   disable buffer
> 
>   for block in blocks:
> close block

Given my very limited knowledge of dma-buf, I'll leave commenting
on the flow to others who know if this looks 'standards' or not ;)

Code looks sane to me..

> 
> v2: Only allow the new IOCTLs on the buffer FD created with
> IIO_BUFFER_GET_FD_IOCTL().
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/iio/industrialio-buffer.c | 55 +++
>  include/linux/iio/buffer_impl.h   |  8 +
>  include/uapi/linux/iio/buffer.h   | 29 
>  3 files changed, 92 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-buffer.c 
> b/drivers/iio/industrialio-buffer.c
> index 94eb9f6cf128..72f333a519bc 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1520,11 +1521,65 @@ static int iio_buffer_chrdev_release(struct inode 
> *inode, struct file *filep)
>   return 0;
>  }
>  
> +static int iio_buffer_enqueue_dmabuf(struct iio_buffer *buffer,
> +  struct iio_dmabuf __user *user_buf)
> +{
> + struct iio_dmabuf dmabuf;
> +
> + if (!buffer->access->enqueue_dmabuf)
> + return -EPERM;
> +
> + if (copy_from_user(, user_buf, sizeof(dmabuf)))
> + return -EFAULT;
> +
> + if (dmabuf.flags & ~IIO_BUFFER_DMABUF_SUPPORTED_FLAGS)
> + return -EINVAL;
> +
> + return buffer->access->enqueue_dmabuf(buffer, );
> +}
> +
> +static int iio_buffer_alloc_dmabuf(struct iio_buffer *buffer,
> +struct iio_dmabuf_alloc_req __user *user_req)
> +{
> + struct iio_dmabuf_alloc_req req;
> +
> + if (!buffer->access->alloc_dmabuf)
> + return -EPERM;
> +
> + if (copy_from_user(, user_req, sizeof(req)))
> + return -EFAULT;
> +
> + if (req.resv)
> + return -EINVAL;
> +
> + return buffer->access->alloc_dmabuf(buffer, );
> +}
> +
> +static long 

Re: [PATCH v2 04/12] iio: buffer-dmaengine: Enable write support

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:25 +
Paul Cercueil  wrote:

> Use the iio_dma_buffer_write() and iio_dma_buffer_space_available()
> functions provided by the buffer-dma core, to enable write support in
> the buffer-dmaengine code.
> 
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Alexandru Ardelean 
This (and previous) look fine to me. Just that question of a user for
the new functionality...

Jonathan

> ---
>  drivers/iio/buffer/industrialio-buffer-dmaengine.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c 
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index ac26b04aa4a9..5cde8fd81c7f 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -123,12 +123,14 @@ static void iio_dmaengine_buffer_release(struct 
> iio_buffer *buf)
>  
>  static const struct iio_buffer_access_funcs iio_dmaengine_buffer_ops = {
>   .read = iio_dma_buffer_read,
> + .write = iio_dma_buffer_write,
>   .set_bytes_per_datum = iio_dma_buffer_set_bytes_per_datum,
>   .set_length = iio_dma_buffer_set_length,
>   .request_update = iio_dma_buffer_request_update,
>   .enable = iio_dma_buffer_enable,
>   .disable = iio_dma_buffer_disable,
>   .data_available = iio_dma_buffer_data_available,
> + .space_available = iio_dma_buffer_space_available,
>   .release = iio_dmaengine_buffer_release,
>  
>   .modes = INDIO_BUFFER_HARDWARE,

Re: [PATCH v2 02/12] iio: buffer-dma: Enable buffer write support

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:23 +
Paul Cercueil  wrote:

> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
> 
> Therefore, the iio_buffer_dma_read() and the new iio_buffer_dma_write()
> now both call a function iio_buffer_dma_io(), which will perform this
> task.
> 
> The .space_available() callback can return the exact same value as the
> .data_available() callback for input buffers, since in both cases we
> count the exact same thing (the number of bytes in each available
> block).
> 
> Note that we preemptively reset block->bytes_used to the buffer's size
> in iio_dma_buffer_request_update(), as in the future the
> iio_dma_buffer_enqueue() function won't reset it.
> 
> v2: - Fix block->state not being reset in
>   iio_dma_buffer_request_update() for output buffers.
> - Only update block->bytes_used once and add a comment about why we
>   update it.
> - Add a comment about why we're setting a different state for output
>   buffers in iio_dma_buffer_request_update()
> - Remove useless cast to bool (!!) in iio_dma_buffer_io()
> 
> Signed-off-by: Paul Cercueil 
> Reviewed-by: Alexandru Ardelean 
One comment inline.

I'd be tempted to queue this up with that fixed, but do we have
any users?  Even though it's trivial I'm not that keen on code
upstream well in advance of it being used.

Thanks,

Jonathan

> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 88 
>  include/linux/iio/buffer-dma.h   |  7 ++
>  2 files changed, 79 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index 1fc91467d1aa..a9f1b673374f 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -195,6 +195,18 @@ static void _iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   block->state = IIO_BLOCK_STATE_DONE;
>  }
>  
> +static void iio_dma_buffer_queue_wake(struct iio_dma_buffer_queue *queue)
> +{
> + __poll_t flags;
> +
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> + flags = EPOLLIN | EPOLLRDNORM;
> + else
> + flags = EPOLLOUT | EPOLLWRNORM;
> +
> + wake_up_interruptible_poll(>buffer.pollq, flags);
> +}
> +
>  /**
>   * iio_dma_buffer_block_done() - Indicate that a block has been completed
>   * @block: The completed block
> @@ -212,7 +224,7 @@ void iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   spin_unlock_irqrestore(>list_lock, flags);
>  
>   iio_buffer_block_put_atomic(block);
> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> + iio_dma_buffer_queue_wake(queue);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_done);
>  
> @@ -241,7 +253,7 @@ void iio_dma_buffer_block_list_abort(struct 
> iio_dma_buffer_queue *queue,
>   }
>   spin_unlock_irqrestore(>list_lock, flags);
>  
> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> + iio_dma_buffer_queue_wake(queue);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_list_abort);
>  
> @@ -335,8 +347,24 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> *buffer)
>   queue->fileio.blocks[i] = block;
>   }
>  
> - block->state = IIO_BLOCK_STATE_QUEUED;
> - list_add_tail(>head, >incoming);
> + /*
> +  * block->bytes_used may have been modified previously, e.g. by
> +  * iio_dma_buffer_block_list_abort(). Reset it here to the
> +  * block's so that iio_dma_buffer_io() will work.
> +  */
> + block->bytes_used = block->size;
> +
> + /*
> +  * If it's an input buffer, mark the block as queued, and
> +  * iio_dma_buffer_enable() will submit it. Otherwise mark it as
> +  * done, which means it's ready to be dequeued.
> +  */
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> + block->state = IIO_BLOCK_STATE_QUEUED;
> + list_add_tail(>head, >incoming);
> + } else {
> + block->state = IIO_BLOCK_STATE_DONE;
> + }
>   }
>  
>  out_unlock:
> @@ -465,20 +493,12 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_dequeue(
>   return block;
>  }
>  
> -/**
> - * iio_dma_buffer_read() - DMA buffer read callback
> - * @buffer: Buffer to read form
> - * @n: Number of bytes to read
> - * @user_buffer: Userspace buffer to copy the data to
> - *
> - * Should be used as the read callback for iio_buffer_access_ops
> - * struct for DMA buffers.
> - */
> -int iio_dma_buffer_read(struct iio_buffer *buffer, size_t n,
> - char __user 

Re: [PATCH v2 01/12] iio: buffer-dma: Get rid of outgoing queue

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:22 +
Paul Cercueil  wrote:

> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
> 
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much easier to
> just check each block's state manually, and keep a counter for the next
> block to dequeue.
> 
> Since the new DMABUF based API wouldn't use the outgoing queue anyway,
> getting rid of it now makes the upcoming changes simpler.
> 
> With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
> be removed.
> 
> v2: - Only remove the outgoing queue, and keep the incoming queue, as we
>   want the buffer to start streaming data as soon as it is enabled.
> - Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the
>   same as IIO_BLOCK_STATE_DONE.
> 
> Signed-off-by: Paul Cercueil 

Hi Paul,

In the interests of moving things forward / simplifying what people need
to look at: This change looks good to me on it's own.

Lars had some comments on v1.  Lars, could you take look at this and
verify if this versions addresses the points you raised (I think it does
but they were your comments so better you judge)

Thanks,

Jonathan

> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 44 ++--
>  include/linux/iio/buffer-dma.h   |  7 ++--
>  2 files changed, 26 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index d348af8b9705..1fc91467d1aa 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -179,7 +179,7 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_alloc_block(
>   }
>  
>   block->size = size;
> - block->state = IIO_BLOCK_STATE_DEQUEUED;
> + block->state = IIO_BLOCK_STATE_DONE;
>   block->queue = queue;
>   INIT_LIST_HEAD(>head);
>   kref_init(>kref);
> @@ -191,16 +191,8 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_alloc_block(
>  
>  static void _iio_dma_buffer_block_done(struct iio_dma_buffer_block *block)
>  {
> - struct iio_dma_buffer_queue *queue = block->queue;
> -
> - /*
> -  * The buffer has already been freed by the application, just drop the
> -  * reference.
> -  */
> - if (block->state != IIO_BLOCK_STATE_DEAD) {
> + if (block->state != IIO_BLOCK_STATE_DEAD)
>   block->state = IIO_BLOCK_STATE_DONE;
> - list_add_tail(>head, >outgoing);
> - }
>  }
>  
>  /**
> @@ -261,7 +253,6 @@ static bool iio_dma_block_reusable(struct 
> iio_dma_buffer_block *block)
>* not support abort and has not given back the block yet.
>*/
>   switch (block->state) {
> - case IIO_BLOCK_STATE_DEQUEUED:
>   case IIO_BLOCK_STATE_QUEUED:
>   case IIO_BLOCK_STATE_DONE:
>   return true;
> @@ -317,7 +308,6 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> *buffer)
>* dead. This means we can reset the lists without having to fear
>* corrution.
>*/
> - INIT_LIST_HEAD(>outgoing);
>   spin_unlock_irq(>list_lock);
>  
>   INIT_LIST_HEAD(>incoming);
> @@ -456,14 +446,20 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_dequeue(
>   struct iio_dma_buffer_queue *queue)
>  {
>   struct iio_dma_buffer_block *block;
> + unsigned int idx;
>  
>   spin_lock_irq(>list_lock);
> - block = list_first_entry_or_null(>outgoing, struct
> - iio_dma_buffer_block, head);
> - if (block != NULL) {
> - list_del(>head);
> - block->state = IIO_BLOCK_STATE_DEQUEUED;
> +
> + idx = queue->fileio.next_dequeue;
> + block = queue->fileio.blocks[idx];
> +
> + if (block->state == IIO_BLOCK_STATE_DONE) {
> + idx = (idx + 1) % ARRAY_SIZE(queue->fileio.blocks);
> + queue->fileio.next_dequeue = idx;
> + } else {
> + block = NULL;
>   }
> +
>   spin_unlock_irq(>list_lock);
>  
>   return block;
> @@ -539,6 +535,7 @@ size_t iio_dma_buffer_data_available(struct iio_buffer 
> *buf)
>   struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buf);
>   struct iio_dma_buffer_block *block;
>   size_t data_available = 0;
> + unsigned int i;
>  
>   /*
>* For counting the available bytes we'll use the size of the block not
> @@ -552,8 +549,15 @@ size_t iio_dma_buffer_data_available(struct iio_buffer 
> *buf)
>   data_available += queue->fileio.active_block->size;
>  
>   spin_lock_irq(>list_lock);
> - list_for_each_entry(block, >outgoing, head)
> - data_available += block->size;
> +
> + for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
> + block = queue->fileio.blocks[i];
> +
> + if (block != queue->fileio.active_block
> + && 

Re: [PATCH v8 02/16] clk: Provide new devm_clk helpers for prepared and enabled clocks

[Jonathan Cameron]

On Mon, 14 Mar 2022 15:16:29 +0100
Uwe Kleine-König  wrote:

> When a driver keeps a clock prepared (or enabled) during the whole
> lifetime of the driver, these helpers allow to simplify the drivers.
> 
> Reviewed-by: Jonathan Cameron 
> Reviewed-by: Alexandru Ardelean 
> Signed-off-by: Uwe Kleine-König 

One trivial thing below.

> ---
>  drivers/clk/clk-devres.c | 31 ++
>  include/linux/clk.h  | 90 +++-
>  2 files changed, 120 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> index fb7761888b30..4707fe718f0b 100644
> --- a/drivers/clk/clk-devres.c
> +++ b/drivers/clk/clk-devres.c
> @@ -67,12 +67,43 @@ struct clk *devm_clk_get(struct device *dev, const char 
> *id)
>  }
>  EXPORT_SYMBOL(devm_clk_get);
>  
> +struct clk *devm_clk_get_prepared(struct device *dev, const char *id)
> +{
> + return __devm_clk_get(dev, id, clk_get, clk_prepare, clk_unprepare);

Nitpick but this spacing before } in functions is rather unusual and not
in keeping with the existing code in this file.

> +
> +}
> +EXPORT_SYMBOL(devm_clk_get_prepared);
> +
> +struct clk *devm_clk_get_enabled(struct device *dev, const char *id)
> +{
> + return __devm_clk_get(dev, id, clk_get,
> +   clk_prepare_enable, clk_disable_unprepare);
> +
> +}
> +EXPORT_SYMBOL(devm_clk_get_enabled);
> +
>  struct clk *devm_clk_get_optional(struct device *dev, const char *id)
>  {
>   return __devm_clk_get(dev, id, clk_get_optional, NULL, NULL);
>  }
>  EXPORT_SYMBOL(devm_clk_get_optional);
>  
> +struct clk *devm_clk_get_optional_prepared(struct device *dev, const char 
> *id)
> +{
> + return __devm_clk_get(dev, id, clk_get_optional,
> +   clk_prepare, clk_unprepare);
> +
> +}
> +EXPORT_SYMBOL(devm_clk_get_optional_prepared);
> +
> +struct clk *devm_clk_get_optional_enabled(struct device *dev, const char *id)
> +{
> + return __devm_clk_get(dev, id, clk_get_optional,
> +   clk_prepare_enable, clk_disable_unprepare);
> +
> +}
> +EXPORT_SYMBOL(devm_clk_get_optional_enabled);
> +
>  struct clk_bulk_devres {
>   struct clk_bulk_data *clks;
>   int num_clks;
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 266e8de3cb51..b011dbba7109 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -449,7 +449,7 @@ int __must_check devm_clk_bulk_get_all(struct device *dev,
>   * the clock producer.  (IOW, @id may be identical strings, but
>   * clk_get may return different clock producers depending on @dev.)
>   *
> - * Drivers must assume that the clock source is not enabled.
> + * Drivers must assume that the clock source is neither prepared nor enabled.
>   *
>   * devm_clk_get should not be called from within interrupt context.
>   *
> @@ -458,6 +458,47 @@ int __must_check devm_clk_bulk_get_all(struct device 
> *dev,
>   */
>  struct clk *devm_clk_get(struct device *dev, const char *id);
>  
> +/**
> + * devm_clk_get_prepared - devm_clk_get() + clk_prepare()
> + * @dev: device for clock "consumer"
> + * @id: clock consumer ID
> + *
> + * Returns a struct clk corresponding to the clock producer, or
> + * valid IS_ERR() condition containing errno.  The implementation
> + * uses @dev and @id to determine the clock consumer, and thereby
> + * the clock producer.  (IOW, @id may be identical strings, but
> + * clk_get may return different clock producers depending on @dev.)
> + *
> + * The returned clk (if valid) is prepared. Drivers must however assume that 
> the
> + * clock is not enabled.
> + *
> + * devm_clk_get_prepared should not be called from within interrupt context.
> + *
> + * The clock will automatically be unprepared and freed when the
> + * device is unbound from the bus.
> + */
> +struct clk *devm_clk_get_prepared(struct device *dev, const char *id);
> +
> +/**
> + * devm_clk_get_enabled - devm_clk_get() + clk_prepare_enable()
> + * @dev: device for clock "consumer"
> + * @id: clock consumer ID
> + *
> + * Returns a struct clk corresponding to the clock producer, or valid 
> IS_ERR()
> + * condition containing errno.  The implementation uses @dev and @id to
> + * determine the clock consumer, and thereby the clock producer.  (IOW, @id 
> may
> + * be identical strings, but clk_get may return different clock producers
> + * depending on @dev.)
> + *
> + * The returned clk (if valid) is prepared and enabled.
> + *
> + * devm_clk_get_prepared should not be called from within interrupt context.
> + *
> + * The clock will automatically be disabled, unprepared and 

Re: [PATCH v2 01/12] iio: buffer-dma: Get rid of outgoing queue

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:22 +
Paul Cercueil  wrote:

> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
> 
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much easier to
> just check each block's state manually, and keep a counter for the next
> block to dequeue.
> 
> Since the new DMABUF based API wouldn't use the outgoing queue anyway,
> getting rid of it now makes the upcoming changes simpler.
> 
> With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
> be removed.
> 
> v2: - Only remove the outgoing queue, and keep the incoming queue, as we
>   want the buffer to start streaming data as soon as it is enabled.
> - Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the
>   same as IIO_BLOCK_STATE_DONE.
> 
> Signed-off-by: Paul Cercueil 
> ---

Trivial process thing but change log should be here, not above as we don't
want it to end up in the main git log.


>  drivers/iio/buffer/industrialio-buffer-dma.c | 44 ++--
>  include/linux/iio/buffer-dma.h   |  7 ++--
>  2 files changed, 26 insertions(+), 25 deletions(-)
> 

Re: [PATCH v2 00/12] iio: buffer-dma: write() and new DMABUF based API

[Jonathan Cameron]

On Mon,  7 Feb 2022 12:59:21 +
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> This is the V2 of my patchset that introduces a new userspace interface
> based on DMABUF objects to complement the fileio API, and adds write()
> support to the existing fileio API.

Hi Paul,

It's been a little while. Perhaps you could summarize the various view
points around the appropriateness of using DMABUF for this?
I appreciate it is a tricky topic to distil into a brief summary but
I know I would find it useful even if no one else does!

Thanks,

Jonathan

> 
> Changes since v1:
> 
> - the patches that were merged in v1 have been (obviously) dropped from
>   this patchset;
> - the patch that was setting the write-combine cache setting has been
>   dropped as well, as it was simply not useful.
> - [01/12]: 
> * Only remove the outgoing queue, and keep the incoming queue, as we
>   want the buffer to start streaming data as soon as it is enabled.
> * Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the
>   same as IIO_BLOCK_STATE_DONE.
> - [02/12]:
> * Fix block->state not being reset in
>   iio_dma_buffer_request_update() for output buffers.
> * Only update block->bytes_used once and add a comment about why we
>   update it.
> * Add a comment about why we're setting a different state for output
>   buffers in iio_dma_buffer_request_update()
> * Remove useless cast to bool (!!) in iio_dma_buffer_io()
> - [05/12]:
> Only allow the new IOCTLs on the buffer FD created with
> IIO_BUFFER_GET_FD_IOCTL().
> - [12/12]:
> * Explicitly state that the new interface is optional and is
>   not implemented by all drivers.
> * The IOCTLs can now only be called on the buffer FD returned by
>   IIO_BUFFER_GET_FD_IOCTL.
> * Move the page up a bit in the index since it is core stuff and not
>   driver-specific.
> 
> The patches not listed here have not been modified since v1.
> 
> Cheers,
> -Paul
> 
> Alexandru Ardelean (1):
>   iio: buffer-dma: split iio_dma_buffer_fileio_free() function
> 
> Paul Cercueil (11):
>   iio: buffer-dma: Get rid of outgoing queue
>   iio: buffer-dma: Enable buffer write support
>   iio: buffer-dmaengine: Support specifying buffer direction
>   iio: buffer-dmaengine: Enable write support
>   iio: core: Add new DMABUF interface infrastructure
>   iio: buffer-dma: Use DMABUFs instead of custom solution
>   iio: buffer-dma: Implement new DMABUF based userspace API
>   iio: buffer-dmaengine: Support new DMABUF based userspace API
>   iio: core: Add support for cyclic buffers
>   iio: buffer-dmaengine: Add support for cyclic buffers
>   Documentation: iio: Document high-speed DMABUF based API
> 
>  Documentation/driver-api/dma-buf.rst  |   2 +
>  Documentation/iio/dmabuf_api.rst  |  94 +++
>  Documentation/iio/index.rst   |   2 +
>  drivers/iio/adc/adi-axi-adc.c |   3 +-
>  drivers/iio/buffer/industrialio-buffer-dma.c  | 610 ++
>  .../buffer/industrialio-buffer-dmaengine.c|  42 +-
>  drivers/iio/industrialio-buffer.c |  60 ++
>  include/linux/iio/buffer-dma.h|  38 +-
>  include/linux/iio/buffer-dmaengine.h  |   5 +-
>  include/linux/iio/buffer_impl.h   |   8 +
>  include/uapi/linux/iio/buffer.h   |  30 +
>  11 files changed, 749 insertions(+), 145 deletions(-)
>  create mode 100644 Documentation/iio/dmabuf_api.rst
> 

Re: [PATCH 11/15] iio: buffer-dma: Boost performance using write-combine cache setting

[Jonathan Cameron]

On Thu, 25 Nov 2021 17:29:58 +
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Le dim., nov. 21 2021 at 17:43:20 +, Paul Cercueil 
>  a écrit :
> > Hi Jonathan,
> > 
> > Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron 
> >  a écrit :  
> >> On Mon, 15 Nov 2021 14:19:21 +
> >> Paul Cercueil  wrote:
> >>   
> >>>  We can be certain that the input buffers will only be accessed by
> >>>  userspace for reading, and output buffers will mostly be accessed 
> >>> by
> >>>  userspace for writing.  
> >> 
> >> Mostly?  Perhaps a little more info on why that's not 'only'.  
> > 
> > Just like with a framebuffer, it really depends on what the 
> > application does. Most of the cases it will just read sequentially an 
> > input buffer, or write sequentially an output buffer. But then you 
> > get the exotic application that will try to do something like alpha 
> > blending, which means read+write. Hence "mostly".
> >   
> >>> 
> >>>  Therefore, it makes more sense to use only fully cached input 
> >>> buffers,
> >>>  and to use the write-combine cache coherency setting for output 
> >>> buffers.
> >>> 
> >>>  This boosts performance, as the data written to the output buffers 
> >>> does
> >>>  not have to be sync'd for coherency. It will halve performance if 
> >>> the
> >>>  userspace application tries to read from the output buffer, but 
> >>> this
> >>>  should never happen.
> >>> 
> >>>  Since we don't need to sync the cache when disabling CPU access 
> >>> either
> >>>  for input buffers or output buffers, the .end_cpu_access() 
> >>> callback can
> >>>  be dropped completely.  
> >> 
> >> We have an odd mix of coherent and non coherent DMA in here as you 
> >> noted,
> >> but are you sure this is safe on all platforms?  
> > 
> > The mix isn't safe, but using only coherent or only non-coherent 
> > should be safe, yes.
> >   
> >>   
> >>> 
> >>>  Signed-off-by: Paul Cercueil   
> >> 
> >> Any numbers to support this patch?  The mapping types are performance
> >> optimisations so nice to know how much of a difference they make.  
> > 
> > Output buffers are definitely faster in write-combine mode. On a 
> > ZedBoard with a AD9361 transceiver set to 66 MSPS, and buffer/size 
> > set to 8192, I would get about 185 MiB/s before, 197 MiB/s after.
> > 
> > Input buffers... early results are mixed. On ARM32 it does look like 
> > it is slightly faster to read from *uncached* memory than reading 
> > from cached memory. The cache sync does take a long time.
> > 
> > Other architectures might have a different result, for instance on 
> > MIPS invalidating the cache is a very fast operation, so using cached 
> > buffers would be a huge win in performance.
> > 
> > Setups where the DMA operations are coherent also wouldn't require 
> > any cache sync and this patch would give a huge win in performance.
> > 
> > I'll run some more tests next week to have some fresh numbers.  
> 
> I think I mixed things up before, because I get different results now.
> 
> Here are some fresh benchmarks, triple-checked, using libiio's 
> iio_readdev and iio_writedev tools, with 64K samples buffers at 61.44 
> MSPS (max. theorical throughput: 234 MiB/s):
>   iio_readdev -b 65536 cf-ad9361-lpc voltage0 voltage1 | pv > /dev/null
>   pv /dev/zero | iio_writedev -b 65536 cf-ad9361-dds-core-lpc voltage0 
> voltage1

There is a bit of a terminology confusion going on here.  I think
for the mappings you mean cacheable vs non-cacheable but maybe
I'm misunderstanding.  That doesn't necessarily correspond to
coherency.  Non cached memory is always coherent because all caches
miss.

Non-cacheable can be related to coherency of course. Also beware that given
hardware might not implement non-cacheable if it knows all possible
accesses are IO-coherent.  Affect is the same and if implemented
correctly it will not hurt performance significantly.

firmware should be letting the OS know if the device does coherent
DMA or not... dma-coherent in dt.  It might be optional for a given
piece of DMA engine but I've not seen that..

I'm not sure I see how you can do a mixture of cacheable for reads
and write combine (which means uncacheable) for writes...

> 
> Coherent mapping:
> - fileio:
> read: 125 MiB/s
> write:141 MiB/s
> - dmabuf:
> r

Re: [PATCH 04/15] iio: buffer-dma: Enable buffer write support

[Jonathan Cameron]

On Sun, 21 Nov 2021 17:19:32 +
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Le dim., nov. 21 2021 at 14:20:49 +, Jonathan Cameron 
>  a écrit :
> > On Mon, 15 Nov 2021 14:19:14 +
> > Paul Cercueil  wrote:
> >   
> >>  Adding write support to the buffer-dma code is easy - the write()
> >>  function basically needs to do the exact same thing as the read()
> >>  function: dequeue a block, read or write the data, enqueue the block
> >>  when entirely processed.
> >> 
> >>  Therefore, the iio_buffer_dma_read() and the new 
> >> iio_buffer_dma_write()
> >>  now both call a function iio_buffer_dma_io(), which will perform 
> >> this
> >>  task.
> >> 
> >>  The .space_available() callback can return the exact same value as 
> >> the
> >>  .data_available() callback for input buffers, since in both cases we
> >>  count the exact same thing (the number of bytes in each available
> >>  block).
> >> 
> >>  Signed-off-by: Paul Cercueil   
> > Hi Paul,
> > 
> > There are a few changes in here, such as the bytes_used value being 
> > set that
> > I'm not following the reasoning behind. More info on those?
> > Also good to provide something about those in this patch description.
> > 
> > Thanks,
> > 
> > Jonathan
> > 
> >   
> >>  ---
> >>   drivers/iio/buffer/industrialio-buffer-dma.c | 75 
> >> +++-
> >>   include/linux/iio/buffer-dma.h   |  7 ++
> >>   2 files changed, 66 insertions(+), 16 deletions(-)
> >> 
> >>  diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> >> b/drivers/iio/buffer/industrialio-buffer-dma.c
> >>  index abac88f20104..d6b2e0cf 100644
> >>  --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> >>  +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> >>  @@ -179,7 +179,8 @@ static struct iio_dma_buffer_block 
> >> *iio_dma_buffer_alloc_block(
> >>}
> >> 
> >>block->size = size;
> >>  - block->state = IIO_BLOCK_STATE_DEQUEUED;
> >>  + block->bytes_used = size;
> >>  + block->state = IIO_BLOCK_STATE_DONE;  
> > 
> > I don't know why these are here - some more info?  
> 
> When using an input buffer the block->bytes_used is unconditionally 
> reset in iio_dmaengine_buffer_submit_block(), so this was fine until 
> now.
> 
> When using an output buffer the block->bytes_used can actually (with 
> the new API) be specified by the user, so we don't want 
> iio_dmaengine_buffer_submit_block() to unconditionally override it. 
> Which means that in the case where we have an output buffer in fileio 
> mode, we do need block->bytes_used to be initialized to the buffer's 
> size since it won't be set anywhere else.

Makes sense.  Thanks for the explanation.

> 
> About the change in block->state: in patch [01/15] we removed the 
> incoming/outgoing queues, and while the "enqueued" state is still 
> useful to know which buffers have to be submitted when the buffer is 
> enabled, the "dequeued" state is not useful anymore since there is no 
> more distinction vs. the "done" state.
> 
> I believe this change should be moved to patch [01/15] then, and I 
> should go further and remove the IIO_BLOCK_STATE_DEQUEUED completely.

Complete removal would indeed be a more 'obvious' change, so I'd support
that assuming now disadvantages we havent' thought of yet.
> 
> >>block->queue = queue;
> >>INIT_LIST_HEAD(>head);
> >>kref_init(>kref);
> >>  @@ -195,6 +196,18 @@ static void _iio_dma_buffer_block_done(struct 
> >> iio_dma_buffer_block *block)
> >>block->state = IIO_BLOCK_STATE_DONE;
> >>   }
> >> 
> >>  +static void iio_dma_buffer_queue_wake(struct iio_dma_buffer_queue 
> >> *queue)
> >>  +{
> >>  + __poll_t flags;
> >>  +
> >>  + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> >>  + flags = EPOLLIN | EPOLLRDNORM;
> >>  + else
> >>  + flags = EPOLLOUT | EPOLLWRNORM;
> >>  +
> >>  + wake_up_interruptible_poll(>buffer.pollq, flags);
> >>  +}
> >>  +
> >>   /**
> >>* iio_dma_buffer_block_done() - Indicate that a block has been 
> >> completed
> >>* @block: The completed block
> >>  @@ -212,7 +225,7 @@ void iio_dma_buffer_block_done(struct 
> >> iio_dma_buf

Re: [PATCH 03/15] iio: buffer-dma: Use round_down() instead of rounddown()

[Jonathan Cameron]

On Mon, 22 Nov 2021 10:00:19 +
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Le dim., nov. 21 2021 at 14:08:23 +, Jonathan Cameron 
>  a écrit :
> > On Mon, 15 Nov 2021 14:19:13 +
> > Paul Cercueil  wrote:
> >   
> >>  We know that the buffer's alignment will always be a power of two;
> >>  therefore, we can use the faster round_down() macro.
> >> 
> >>  Signed-off-by: Paul Cercueil   
> > *groan*.  I don't want to know where the naming of these two came 
> > from but that
> > is spectacular...
> > 
> > Anyhow, happy to pick up 1-3 now if you like as all are good cleanup 
> > of
> > existing code.  
> 
> I think you can pick 2-3 now; I will do some changes to patch [01/15] 
> in the V2.

Applied, 2+3 to the togreg branch of iio.git and pushed out as testing for all
the normal reasons.

Thanks,

Jonathan

> 
> Cheers,
> -Paul
> 
> 

Re: [PATCH 11/15] iio: buffer-dma: Boost performance using write-combine cache setting

[Jonathan Cameron]

On Sun, 21 Nov 2021 17:43:20 +
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> Le dim., nov. 21 2021 at 15:00:37 +, Jonathan Cameron 
>  a écrit :
> > On Mon, 15 Nov 2021 14:19:21 +
> > Paul Cercueil  wrote:
> >   
> >>  We can be certain that the input buffers will only be accessed by
> >>  userspace for reading, and output buffers will mostly be accessed by
> >>  userspace for writing.  
> > 
> > Mostly?  Perhaps a little more info on why that's not 'only'.  
> 
> Just like with a framebuffer, it really depends on what the application 
> does. Most of the cases it will just read sequentially an input buffer, 
> or write sequentially an output buffer. But then you get the exotic 
> application that will try to do something like alpha blending, which 
> means read+write. Hence "mostly".

Ok. That makes sense though I hope no one actually does it, we can't
prevent them doing so.


> 
> >> 
> >>  Therefore, it makes more sense to use only fully cached input 
> >> buffers,
> >>  and to use the write-combine cache coherency setting for output 
> >> buffers.
> >> 
> >>  This boosts performance, as the data written to the output buffers 
> >> does
> >>  not have to be sync'd for coherency. It will halve performance if 
> >> the
> >>  userspace application tries to read from the output buffer, but this
> >>  should never happen.
> >> 
> >>  Since we don't need to sync the cache when disabling CPU access 
> >> either
> >>  for input buffers or output buffers, the .end_cpu_access() callback 
> >> can
> >>  be dropped completely.  
> > 
> > We have an odd mix of coherent and non coherent DMA in here as you 
> > noted,
> > but are you sure this is safe on all platforms?  
> 
> The mix isn't safe, but using only coherent or only non-coherent should 
> be safe, yes.

yup

> 
> >   
> >> 
> >>  Signed-off-by: Paul Cercueil   
> > 
> > Any numbers to support this patch?  The mapping types are performance
> > optimisations so nice to know how much of a difference they make.  
> 
> Output buffers are definitely faster in write-combine mode. On a 
> ZedBoard with a AD9361 transceiver set to 66 MSPS, and buffer/size set 
> to 8192, I would get about 185 MiB/s before, 197 MiB/s after.
> 
> Input buffers... early results are mixed. On ARM32 it does look like it 
> is slightly faster to read from *uncached* memory than reading from 
> cached memory. The cache sync does take a long time.
> 
> Other architectures might have a different result, for instance on MIPS 
> invalidating the cache is a very fast operation, so using cached 
> buffers would be a huge win in performance.
> 
> Setups where the DMA operations are coherent also wouldn't require any 
> cache sync and this patch would give a huge win in performance.
> 
> I'll run some more tests next week to have some fresh numbers.

Great.

Thanks,

Jonathan

> 
> Cheers,
> -Paul
> 
> >>  ---
> >>   drivers/iio/buffer/industrialio-buffer-dma.c | 82 
> >> +---
> >>   1 file changed, 54 insertions(+), 28 deletions(-)
> >> 
> >>  diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> >> b/drivers/iio/buffer/industrialio-buffer-dma.c
> >>  index 92356ee02f30..fb39054d8c15 100644
> >>  --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> >>  +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> >>  @@ -229,8 +229,33 @@ static int iio_buffer_dma_buf_mmap(struct 
> >> dma_buf *dbuf,
> >>if (vma->vm_ops->open)
> >>vma->vm_ops->open(vma);
> >> 
> >>  - return dma_mmap_pages(dev, vma, vma->vm_end - vma->vm_start,
> >>  -   virt_to_page(block->vaddr));
> >>  + if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> >>  + /*
> >>  +  * With an input buffer, userspace will only read the data and
> >>  +  * never write. We can mmap the buffer fully cached.
> >>  +  */
> >>  + return dma_mmap_pages(dev, vma, vma->vm_end - vma->vm_start,
> >>  +   virt_to_page(block->vaddr));
> >>  + } else {
> >>  + /*
> >>  +  * With an output buffer, userspace will only write the data
> >>  +  * and should rarely (if never) read from it. It is better to
> >>  +  * use write-combine in this case.
> >>  +  */
> >> 

Re: [PATCH 15/15] Documentation: iio: Document high-speed DMABUF based API

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:22:43 +
Paul Cercueil  wrote:

> Document the new DMABUF based API.
> 
> Signed-off-by: Paul Cercueil 

Hi Paul,

A few trivial things inline but looks good to me if we do end up using DMABUF
anyway.

Jonathan

> ---
>  Documentation/driver-api/dma-buf.rst |  2 +
>  Documentation/iio/dmabuf_api.rst | 94 
>  Documentation/iio/index.rst  |  2 +
>  3 files changed, 98 insertions(+)
>  create mode 100644 Documentation/iio/dmabuf_api.rst
> 
> diff --git a/Documentation/driver-api/dma-buf.rst 
> b/Documentation/driver-api/dma-buf.rst
> index 2cd7db82d9fe..d3c9b58d2706 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -1,3 +1,5 @@
> +.. _dma-buf:
> +

Why this change?

>  Buffer Sharing and Synchronization
>  ==
>  
> diff --git a/Documentation/iio/dmabuf_api.rst 
> b/Documentation/iio/dmabuf_api.rst
> new file mode 100644
> index ..b4e120a4ef0c
> --- /dev/null
> +++ b/Documentation/iio/dmabuf_api.rst
> @@ -0,0 +1,94 @@
> +===
> +High-speed DMABUF interface for IIO
> +===
> +
> +1. Overview
> +===
> +
> +The Industrial I/O subsystem supports access to buffers through a file-based
> +interface, with read() and write() access calls through the IIO device's dev
> +node.
> +
> +It additionally supports a DMABUF based interface, where the userspace
> +application can allocate and append DMABUF objects to the buffer's queue.

I would note somewhere that this interface is optional for a given IIO driver.
I don't want people to start assuming their i2c ADC will support this and
wondering why it doesn't work :)

> +
> +The advantage of this DMABUF based interface vs. the fileio
> +interface, is that it avoids an extra copy of the data between the
> +kernel and userspace. This is particularly userful for high-speed
> +devices which produce several megabytes or even gigabytes of data per
> +second.
> +
> +The data in this DMABUF interface is managed at the granularity of
> +DMABUF objects. Reducing the granularity from byte level to block level
> +is done to reduce the userspace-kernelspace synchronization overhead
> +since performing syscalls for each byte at a few Mbps is just not
> +feasible.
> +
> +This of course leads to a slightly increased latency. For this reason an
> +application can choose the size of the DMABUFs as well as how many it
> +allocates. E.g. two DMABUFs would be a traditional double buffering
> +scheme. But using a higher number might be necessary to avoid
> +underflow/overflow situations in the presence of scheduling latencies.
> +
> +2. User API
> +===
> +
> +``IIO_BUFFER_DMABUF_ALLOC_IOCTL(struct iio_dmabuf_alloc_req *)``
> +
> +
> +Each call will allocate a new DMABUF object. The return value (if not
> +a negative errno value as error) will be the file descriptor of the new
> +DMABUF.
> +
> +``IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *)``
> +
> +
> +Place the DMABUF object into the queue pending for hardware process.
> +
> +These two IOCTLs have to be performed on the IIO buffer's file
> +descriptor (either opened from the corresponding /dev/iio:deviceX, or
> +obtained using the `IIO_BUFFER_GET_FD_IOCTL` ioctl).
> +
> +3. Usage
> +
> +
> +To access the data stored in a block by userspace the block must be
> +mapped to the process's memory. This is done by calling mmap() on the
> +DMABUF's file descriptor.
> +
> +Before accessing the data through the map, you must use the
> +DMA_BUF_IOCTL_SYNC(struct dma_buf_sync *) ioctl, with the
> +DMA_BUF_SYNC_START flag, to make sure that the data is available.
> +This call may block until the hardware is done with this block. Once
> +you are done reading or writing the data, you must use this ioctl again
> +with the DMA_BUF_SYNC_END flag, before enqueueing the DMABUF to the
> +kernel's queue.
> +
> +If you need to know when the hardware is done with a DMABUF, you can
> +poll its file descriptor for the EPOLLOUT event.
> +
> +Finally, to destroy a DMABUF object, simply call close() on its file
> +descriptor.
> +
> +For more information about manipulating DMABUF objects, see: :ref:`dma-buf`.
> +
> +A typical workflow for the new interface is:
> +
> +for block in blocks:
> +  DMABUF_ALLOC block
> +  mmap block
> +
> +enable buffer
> +
> +while !done
> +  for block in blocks:
> +DMABUF_ENQUEUE block
> +
> +DMABUF_SYNC_START block
> +process data
> +DMABUF_SYNC_END block
> +
> +disable buffer
> +
> +for block in blocks:
> +  close block
> diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
> index 58b7a4ebac51..9ce799fbf262 100644
> --- a/Documentation/iio/index.rst
> +++ b/Documentation/iio/index.rst
> 

Re: [PATCH 11/15] iio: buffer-dma: Boost performance using write-combine cache setting

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:19:21 +
Paul Cercueil  wrote:

> We can be certain that the input buffers will only be accessed by
> userspace for reading, and output buffers will mostly be accessed by
> userspace for writing.

Mostly?  Perhaps a little more info on why that's not 'only'.

> 
> Therefore, it makes more sense to use only fully cached input buffers,
> and to use the write-combine cache coherency setting for output buffers.
> 
> This boosts performance, as the data written to the output buffers does
> not have to be sync'd for coherency. It will halve performance if the
> userspace application tries to read from the output buffer, but this
> should never happen.
> 
> Since we don't need to sync the cache when disabling CPU access either
> for input buffers or output buffers, the .end_cpu_access() callback can
> be dropped completely.

We have an odd mix of coherent and non coherent DMA in here as you noted,
but are you sure this is safe on all platforms?

> 
> Signed-off-by: Paul Cercueil 

Any numbers to support this patch?  The mapping types are performance
optimisations so nice to know how much of a difference they make.


> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 82 +---
>  1 file changed, 54 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index 92356ee02f30..fb39054d8c15 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -229,8 +229,33 @@ static int iio_buffer_dma_buf_mmap(struct dma_buf *dbuf,
>   if (vma->vm_ops->open)
>   vma->vm_ops->open(vma);
>  
> - return dma_mmap_pages(dev, vma, vma->vm_end - vma->vm_start,
> -   virt_to_page(block->vaddr));
> + if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> + /*
> +  * With an input buffer, userspace will only read the data and
> +  * never write. We can mmap the buffer fully cached.
> +  */
> + return dma_mmap_pages(dev, vma, vma->vm_end - vma->vm_start,
> +   virt_to_page(block->vaddr));
> + } else {
> + /*
> +  * With an output buffer, userspace will only write the data
> +  * and should rarely (if never) read from it. It is better to
> +  * use write-combine in this case.
> +  */
> + return dma_mmap_wc(dev, vma, block->vaddr, block->phys_addr,
> +vma->vm_end - vma->vm_start);
> + }
> +}
> +
> +static void iio_dma_buffer_free_dmamem(struct iio_dma_buffer_block *block)
> +{
> + struct device *dev = block->queue->dev;
> + size_t size = PAGE_ALIGN(block->size);
> +
> + if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> + dma_free_coherent(dev, size, block->vaddr, block->phys_addr);
> + else
> + dma_free_wc(dev, size, block->vaddr, block->phys_addr);
>  }
>  
>  static void iio_buffer_dma_buf_release(struct dma_buf *dbuf)
> @@ -243,9 +268,7 @@ static void iio_buffer_dma_buf_release(struct dma_buf 
> *dbuf)
>  
>   mutex_lock(>lock);
>  
> - dma_free_coherent(queue->dev, PAGE_ALIGN(block->size),
> -   block->vaddr, block->phys_addr);
> -
> + iio_dma_buffer_free_dmamem(block);
>   kfree(block);
>  
>   queue->num_blocks--;
> @@ -268,19 +291,6 @@ static int iio_buffer_dma_buf_begin_cpu_access(struct 
> dma_buf *dbuf,
>   return 0;
>  }
>  
> -static int iio_buffer_dma_buf_end_cpu_access(struct dma_buf *dbuf,
> -  enum dma_data_direction dma_dir)
> -{
> - struct iio_dma_buffer_block *block = dbuf->priv;
> - struct device *dev = block->queue->dev;
> -
> - /* We only need to sync the cache for output buffers */
> - if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_OUT)
> - dma_sync_single_for_device(dev, block->phys_addr, block->size, 
> dma_dir);
> -
> - return 0;
> -}
> -
>  static const struct dma_buf_ops iio_dma_buffer_dmabuf_ops = {
>   .attach = iio_buffer_dma_buf_attach,
>   .map_dma_buf= iio_buffer_dma_buf_map,
> @@ -288,9 +298,28 @@ static const struct dma_buf_ops 
> iio_dma_buffer_dmabuf_ops = {
>   .mmap   = iio_buffer_dma_buf_mmap,
>   .release= iio_buffer_dma_buf_release,
>   .begin_cpu_access   = iio_buffer_dma_buf_begin_cpu_access,
> - .end_cpu_access = iio_buffer_dma_buf_end_cpu_access,
>  };
>  
> +static int iio_dma_buffer_alloc_dmamem(struct iio_dma_buffer_block *block)
> +{
> + struct device *dev = block->queue->dev;
> + size_t size = PAGE_ALIGN(block->size);
> +
> + if (block->queue->buffer.direction == IIO_BUFFER_DIRECTION_IN) {
> + block->vaddr = dma_alloc_coherent(dev, size,
> +   

Re: [PATCH 07/15] iio: core: Add new DMABUF interface infrastructure

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:19:17 +
Paul Cercueil  wrote:

> Add the necessary infrastructure to the IIO core to support a new DMABUF
> based interface.
> 
> The advantage of this new DMABUF based interface vs. the read()
> interface, is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.
> 
> The data in this new DMABUF interface is managed at the granularity of
> DMABUF objects. Reducing the granularity from byte level to block level
> is done to reduce the userspace-kernelspace synchronization overhead
> since performing syscalls for each byte at a few Mbps is just not
> feasible.
> 
> This of course leads to a slightly increased latency. For this reason an
> application can choose the size of the DMABUFs as well as how many it
> allocates. E.g. two DMABUFs would be a traditional double buffering
> scheme. But using a higher number might be necessary to avoid
> underflow/overflow situations in the presence of scheduling latencies.
> 
> As part of the interface, 2 new IOCTLs have been added:
> 
> IIO_BUFFER_DMABUF_ALLOC_IOCTL(struct iio_dmabuf_alloc_req *):
>  Each call will allocate a new DMABUF object. The return value (if not
>  a negative errno value as error) will be the file descriptor of the new
>  DMABUF.
> 
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *):
>  Place the DMABUF object into the queue pending for hardware process.
> 
> These two IOCTLs have to be performed on the IIO buffer's file
> descriptor (either opened from the corresponding /dev/iio:deviceX, or
> obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl).

Unrelated to this patch except tangentially.  Maybe we should enable
new buffer features only on the IIO_BUFFER_GET_FD_IOCTL() route as
we probably want to deprecate the old interfaces due to the it only
supporting a single buffer / datastream per device.

Possibly something for another day...

Nothing to add on actual code...

Jonathan

> 
> To access the data stored in a block by userspace the block must be
> mapped to the process's memory. This is done by calling mmap() on the
> DMABUF's file descriptor.
> 
> Before accessing the data through the map, you must use the
> DMA_BUF_IOCTL_SYNC(struct dma_buf_sync *) ioctl, with the
> DMA_BUF_SYNC_START flag, to make sure that the data is available.
> This call may block until the hardware is done with this block. Once
> you are done reading or writing the data, you must use this ioctl again
> with the DMA_BUF_SYNC_END flag, before enqueueing the DMABUF to the
> kernel's queue.
> 
> If you need to know when the hardware is done with a DMABUF, you can
> poll its file descriptor for the EPOLLOUT event.
> 
> Finally, to destroy a DMABUF object, simply call close() on its file
> descriptor.
> 
> A typical workflow for the new interface is:
> 
>   for block in blocks:
> DMABUF_ALLOC block
> mmap block
> 
>   enable buffer
> 
>   while !done
> for block in blocks:
>   DMABUF_ENQUEUE block
> 
>   DMABUF_SYNC_START block
>   process data
>   DMABUF_SYNC_END block
> 
>   disable buffer
> 
>   for block in blocks:
> close block
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/iio/industrialio-buffer.c | 44 +++
>  include/linux/iio/buffer_impl.h   |  8 ++
>  include/uapi/linux/iio/buffer.h   | 29 
>  3 files changed, 81 insertions(+)
> 
> diff --git a/drivers/iio/industrialio-buffer.c 
> b/drivers/iio/industrialio-buffer.c
> index e180728914c0..30910e6c2346 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -1585,12 +1586,55 @@ static long iio_device_buffer_getfd(struct iio_dev 
> *indio_dev, unsigned long arg
>   return ret;
>  }
>  
> +static int iio_buffer_enqueue_dmabuf(struct iio_buffer *buffer,
> +  struct iio_dmabuf __user *user_buf)
> +{
> + struct iio_dmabuf dmabuf;
> +
> + if (!buffer->access->enqueue_dmabuf)
> + return -EPERM;
> +
> + if (copy_from_user(, user_buf, sizeof(dmabuf)))
> + return -EFAULT;
> +
> + if (dmabuf.flags & ~IIO_BUFFER_DMABUF_SUPPORTED_FLAGS)
> + return -EINVAL;
> +
> + return buffer->access->enqueue_dmabuf(buffer, );
> +}
> +
> +static int iio_buffer_alloc_dmabuf(struct iio_buffer *buffer,
> +struct iio_dmabuf_alloc_req __user *user_req)
> +{
> + struct iio_dmabuf_alloc_req req;
> +
> + if (!buffer->access->alloc_dmabuf)
> + return -EPERM;
> +
> + if (copy_from_user(, user_req, sizeof(req)))
> + return -EFAULT;
> +
> + if (req.resv)
> + return -EINVAL;
> +
> + return buffer->access->alloc_dmabuf(buffer, );
> +}
> +
>  static long 

Re: [PATCH 04/15] iio: buffer-dma: Enable buffer write support

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:19:14 +
Paul Cercueil  wrote:

> Adding write support to the buffer-dma code is easy - the write()
> function basically needs to do the exact same thing as the read()
> function: dequeue a block, read or write the data, enqueue the block
> when entirely processed.
> 
> Therefore, the iio_buffer_dma_read() and the new iio_buffer_dma_write()
> now both call a function iio_buffer_dma_io(), which will perform this
> task.
> 
> The .space_available() callback can return the exact same value as the
> .data_available() callback for input buffers, since in both cases we
> count the exact same thing (the number of bytes in each available
> block).
> 
> Signed-off-by: Paul Cercueil 
Hi Paul,

There are a few changes in here, such as the bytes_used value being set that
I'm not following the reasoning behind. More info on those?
Also good to provide something about those in this patch description.

Thanks,

Jonathan


> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 75 +++-
>  include/linux/iio/buffer-dma.h   |  7 ++
>  2 files changed, 66 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index abac88f20104..d6b2e0cf 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -179,7 +179,8 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_alloc_block(
>   }
>  
>   block->size = size;
> - block->state = IIO_BLOCK_STATE_DEQUEUED;
> + block->bytes_used = size;
> + block->state = IIO_BLOCK_STATE_DONE;

I don't know why these are here - some more info?

>   block->queue = queue;
>   INIT_LIST_HEAD(>head);
>   kref_init(>kref);
> @@ -195,6 +196,18 @@ static void _iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   block->state = IIO_BLOCK_STATE_DONE;
>  }
>  
> +static void iio_dma_buffer_queue_wake(struct iio_dma_buffer_queue *queue)
> +{
> + __poll_t flags;
> +
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> + flags = EPOLLIN | EPOLLRDNORM;
> + else
> + flags = EPOLLOUT | EPOLLWRNORM;
> +
> + wake_up_interruptible_poll(>buffer.pollq, flags);
> +}
> +
>  /**
>   * iio_dma_buffer_block_done() - Indicate that a block has been completed
>   * @block: The completed block
> @@ -212,7 +225,7 @@ void iio_dma_buffer_block_done(struct 
> iio_dma_buffer_block *block)
>   spin_unlock_irqrestore(>list_lock, flags);
>  
>   iio_buffer_block_put_atomic(block);
> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> + iio_dma_buffer_queue_wake(queue);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_done);
>  
> @@ -241,7 +254,7 @@ void iio_dma_buffer_block_list_abort(struct 
> iio_dma_buffer_queue *queue,
>   }
>   spin_unlock_irqrestore(>list_lock, flags);
>  
> - wake_up_interruptible_poll(>buffer.pollq, EPOLLIN | EPOLLRDNORM);
> + iio_dma_buffer_queue_wake(queue);
>  }
>  EXPORT_SYMBOL_GPL(iio_dma_buffer_block_list_abort);
>  
> @@ -334,7 +347,8 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> *buffer)
>   queue->fileio.blocks[i] = block;
>   }
>  
> - block->state = IIO_BLOCK_STATE_QUEUED;
> + if (queue->buffer.direction == IIO_BUFFER_DIRECTION_IN)
> + block->state = IIO_BLOCK_STATE_QUEUED;

Possibly worth a comment on the state being set here.  I figured it out, but 
might
save some brain cells in future if it's stated in the code.

>   }
>  
>  out_unlock:
> @@ -467,20 +481,12 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_dequeue(
>   return block;
>  }
>  
> -/**
> - * iio_dma_buffer_read() - DMA buffer read callback
> - * @buffer: Buffer to read form
> - * @n: Number of bytes to read
> - * @user_buffer: Userspace buffer to copy the data to
> - *
> - * Should be used as the read callback for iio_buffer_access_ops
> - * struct for DMA buffers.
> - */
> -int iio_dma_buffer_read(struct iio_buffer *buffer, size_t n,
> - char __user *user_buffer)
> +static int iio_dma_buffer_io(struct iio_buffer *buffer,
> +  size_t n, char __user *user_buffer, bool is_write)
>  {
>   struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
>   struct iio_dma_buffer_block *block;
> + void *addr;
>   int ret;
>  
>   if (n < buffer->bytes_per_datum)
> @@ -503,8 +509,13 @@ int iio_dma_buffer_read(struct iio_buffer *buffer, 
> size_t n,
>   n = rounddown(n, buffer->bytes_per_datum);
>   if (n > block->bytes_used - queue->fileio.pos)
>   n = block->bytes_used - queue->fileio.pos;
> + addr = block->vaddr + queue->fileio.pos;
>  
> - if (copy_to_user(user_buffer, block->vaddr + queue->fileio.pos, n)) {
> + if (is_write)
> + ret = !!copy_from_user(addr, user_buffer, n);
> +  

Re: [PATCH 03/15] iio: buffer-dma: Use round_down() instead of rounddown()

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:19:13 +
Paul Cercueil  wrote:

> We know that the buffer's alignment will always be a power of two;
> therefore, we can use the faster round_down() macro.
> 
> Signed-off-by: Paul Cercueil 
*groan*.  I don't want to know where the naming of these two came from but that
is spectacular... 

Anyhow, happy to pick up 1-3 now if you like as all are good cleanup of
existing code.

Jonathan

> ---
>  drivers/iio/buffer/industrialio-buffer-dmaengine.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c 
> b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 1ac94c4e9792..f8ce26a24c57 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -67,7 +67,7 @@ static int iio_dmaengine_buffer_submit_block(struct 
> iio_dma_buffer_queue *queue,
>   dma_cookie_t cookie;
>  
>   block->bytes_used = min(block->size, dmaengine_buffer->max_size);
> - block->bytes_used = rounddown(block->bytes_used,
> + block->bytes_used = round_down(block->bytes_used,
>   dmaengine_buffer->align);
>  
>   desc = dmaengine_prep_slave_single(dmaengine_buffer->chan,

Re: [PATCH 01/15] iio: buffer-dma: Get rid of incoming/outgoing queues

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:19:11 +
Paul Cercueil  wrote:

> The buffer-dma code was using two queues, incoming and outgoing, to
> manage the state of the blocks in use.
> 
> While this totally works, it adds some complexity to the code,
> especially since the code only manages 2 blocks. It is much easier to
> just check each block's state manually, and keep a counter for the next
> block to dequeue.
> 
> Since the new DMABUF based API wouldn't use these incoming and outgoing
> queues anyway, getting rid of them now makes the upcoming changes
> simpler.
> 
> Signed-off-by: Paul Cercueil 
This looks to be a nice little cleanup on it's own.

Let me know if you'd like me to pick this up before the main discussion
comes to any conclusion.

Jonathan

> ---
>  drivers/iio/buffer/industrialio-buffer-dma.c | 68 ++--
>  include/linux/iio/buffer-dma.h   |  7 +-
>  2 files changed, 37 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> b/drivers/iio/buffer/industrialio-buffer-dma.c
> index d348af8b9705..abac88f20104 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> @@ -191,16 +191,8 @@ static struct iio_dma_buffer_block 
> *iio_dma_buffer_alloc_block(
>  
>  static void _iio_dma_buffer_block_done(struct iio_dma_buffer_block *block)
>  {
> - struct iio_dma_buffer_queue *queue = block->queue;
> -
> - /*
> -  * The buffer has already been freed by the application, just drop the
> -  * reference.
> -  */
> - if (block->state != IIO_BLOCK_STATE_DEAD) {
> + if (block->state != IIO_BLOCK_STATE_DEAD)
>   block->state = IIO_BLOCK_STATE_DONE;
> - list_add_tail(>head, >outgoing);
> - }
>  }
>  
>  /**
> @@ -317,11 +309,8 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> *buffer)
>* dead. This means we can reset the lists without having to fear
>* corrution.
>*/
> - INIT_LIST_HEAD(>outgoing);
>   spin_unlock_irq(>list_lock);
>  
> - INIT_LIST_HEAD(>incoming);
> -
>   for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
>   if (queue->fileio.blocks[i]) {
>   block = queue->fileio.blocks[i];
> @@ -346,7 +335,6 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> *buffer)
>   }
>  
>   block->state = IIO_BLOCK_STATE_QUEUED;
> - list_add_tail(>head, >incoming);
>   }
>  
>  out_unlock:
> @@ -401,13 +389,18 @@ int iio_dma_buffer_enable(struct iio_buffer *buffer,
>   struct iio_dev *indio_dev)
>  {
>   struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buffer);
> - struct iio_dma_buffer_block *block, *_block;
> + struct iio_dma_buffer_block *block;
> + unsigned int i;
>  
>   mutex_lock(>lock);
>   queue->active = true;
> - list_for_each_entry_safe(block, _block, >incoming, head) {
> - list_del(>head);
> - iio_dma_buffer_submit_block(queue, block);
> + queue->fileio.next_dequeue = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
> + block = queue->fileio.blocks[i];
> +
> + if (block->state == IIO_BLOCK_STATE_QUEUED)
> + iio_dma_buffer_submit_block(queue, block);
>   }
>   mutex_unlock(>lock);
>  
> @@ -442,28 +435,33 @@ EXPORT_SYMBOL_GPL(iio_dma_buffer_disable);
>  static void iio_dma_buffer_enqueue(struct iio_dma_buffer_queue *queue,
>   struct iio_dma_buffer_block *block)
>  {
> - if (block->state == IIO_BLOCK_STATE_DEAD) {
> + if (block->state == IIO_BLOCK_STATE_DEAD)
>   iio_buffer_block_put(block);
> - } else if (queue->active) {
> + else if (queue->active)
>   iio_dma_buffer_submit_block(queue, block);
> - } else {
> + else
>   block->state = IIO_BLOCK_STATE_QUEUED;
> - list_add_tail(>head, >incoming);
> - }
>  }
>  
>  static struct iio_dma_buffer_block *iio_dma_buffer_dequeue(
>   struct iio_dma_buffer_queue *queue)
>  {
>   struct iio_dma_buffer_block *block;
> + unsigned int idx;
>  
>   spin_lock_irq(>list_lock);
> - block = list_first_entry_or_null(>outgoing, struct
> - iio_dma_buffer_block, head);
> - if (block != NULL) {
> - list_del(>head);
> +
> + idx = queue->fileio.next_dequeue;
> + block = queue->fileio.blocks[idx];
> +
> + if (block->state == IIO_BLOCK_STATE_DONE) {
>   block->state = IIO_BLOCK_STATE_DEQUEUED;
> + idx = (idx + 1) % ARRAY_SIZE(queue->fileio.blocks);
> + queue->fileio.next_dequeue = idx;
> + } else {
> + block = NULL;
>   }
> +
>   spin_unlock_irq(>list_lock);
>  
>   return block;
> @@ -539,6 +537,7 @@ size_t iio_dma_buffer_data_available(struct iio_buffer 
> *buf)
>   struct iio_dma_buffer_queue *queue = iio_buffer_to_queue(buf);
>   

Re: [PATCH 00/15] iio: buffer-dma: write() and new DMABUF based API

[Jonathan Cameron]

On Mon, 15 Nov 2021 14:19:10 +
Paul Cercueil  wrote:

> Hi Jonathan,
> 
> This patchset introduces a new userspace interface based on DMABUF
> objects, to complement the existing fileio based API.
> 
> The advantage of this DMABUF based interface vs. the fileio
> interface, is that it avoids an extra copy of the data between the
> kernel and userspace. This is particularly userful for high-speed
> devices which produce several megabytes or even gigabytes of data per
> second.

I'm going to defer to others for the discussion of whether dmabuf is
the right way to do this. I look forwards to some conclusions.
Much like yourselves, I want to see 'a' way of doing this but I'm
not knowledgeable enough about the quirks and corner cases of the
different options to offer a strong opinion.

Either way, it's great to get that discussion going and it would never
have happened without having actual code so thanks for doing this!

> 
> The first few patches [01/15] to [03/15] are not really related, but
> allow to reduce the size of the patches that introduce the new API.
> 
> Patch [04/15] to [06/15] enables write() support to the buffer-dma
> implementation of the buffer API, to continue the work done by
> Mihail Chindris.
> 
> Patches [07/15] to [12/15] introduce the new DMABUF based API.
> 
> Patches [13/15] and [14/15] add support for cyclic buffers, only through
> the new API. A cyclic buffer will be repeated on the output until the
> buffer is disabled.
> 
> Patch [15/15] adds documentation about the new API.
> 
> For now, the API allows you to alloc DMABUF objects and mmap() them to
> read or write the samples. It does not yet allow to import DMABUFs
> parented to other subsystems, but that should eventually be possible
> once it's wired.
> 
> This patchset is inspired by the "mmap interface" that was previously
> submitted by Alexandru Ardelean and Lars-Peter Clausen, so it would be
> great if I could get a review from you guys. Alexandru's commit was
> signed with his @analog.com address but he doesn't work at ADI anymore,
> so I believe I'll need him to sign with a new email.

Given it reflects a sign off given back then I think it's fine to
leave them as analog.com but maybe he can give an Acked-by: on a different
email address to reflect that he is happy for these to go forwards.

It's far from unusual to have out of date email addresses in sign offs
given often code is coming out of trees many years after someone
originally wrote it for a vendor tree or similar.  Whilst not a lawyer
I don't think that's a problem.

Jonathan

> 
> Cheers,
> -Paul
> 
> Alexandru Ardelean (1):
>   iio: buffer-dma: split iio_dma_buffer_fileio_free() function
> 
> Paul Cercueil (14):
>   iio: buffer-dma: Get rid of incoming/outgoing queues
>   iio: buffer-dma: Remove unused iio_buffer_block struct
>   iio: buffer-dma: Use round_down() instead of rounddown()
>   iio: buffer-dma: Enable buffer write support
>   iio: buffer-dmaengine: Support specifying buffer direction
>   iio: buffer-dmaengine: Enable write support
>   iio: core: Add new DMABUF interface infrastructure
>   iio: buffer-dma: Use DMABUFs instead of custom solution
>   iio: buffer-dma: Implement new DMABUF based userspace API
>   iio: buffer-dma: Boost performance using write-combine cache setting
>   iio: buffer-dmaengine: Support new DMABUF based userspace API
>   iio: core: Add support for cyclic buffers
>   iio: buffer-dmaengine: Add support for cyclic buffers
>   Documentation: iio: Document high-speed DMABUF based API
> 
>  Documentation/driver-api/dma-buf.rst  |   2 +
>  Documentation/iio/dmabuf_api.rst  |  94 +++
>  Documentation/iio/index.rst   |   2 +
>  drivers/iio/adc/adi-axi-adc.c |   3 +-
>  drivers/iio/buffer/industrialio-buffer-dma.c  | 670 ++
>  .../buffer/industrialio-buffer-dmaengine.c|  42 +-
>  drivers/iio/industrialio-buffer.c |  49 ++
>  include/linux/iio/buffer-dma.h|  43 +-
>  include/linux/iio/buffer-dmaengine.h  |   5 +-
>  include/linux/iio/buffer_impl.h   |   8 +
>  include/uapi/linux/iio/buffer.h   |  30 +
>  11 files changed, 783 insertions(+), 165 deletions(-)
>  create mode 100644 Documentation/iio/dmabuf_api.rst
> 

Re: [PATCH 08/15] iio: buffer-dma: split iio_dma_buffer_fileio_free() function

[Jonathan Cameron]

On Tue, 16 Nov 2021 12:59:30 +0200
Alexandru Ardelean  wrote:

> On Mon, Nov 15, 2021 at 4:20 PM Paul Cercueil  wrote:
> >
> > From: Alexandru Ardelean 
> >
> > A part of the logic in the iio_dma_buffer_exit() is required for the change
> > to add mmap support to IIO buffers.
> > This change splits the logic into a separate function, which will be
> > re-used later.
> >  
> 
> Not sure how the protocol is here, since my old @analog.com email
> isn't working anymore.
> 
> But:
> 
> Signed-off-by: Alexandru Ardelean 

If you want to both document your email address change and make various scripts
find you more easily, send a patch for .mailmap

In meantime we can probably leave your original sign off in place but add
a Cc: with an up to date email address. That will reflect that the sign off
for this was (I assume) given back when you were at Analog.

> 
> Thanks :)
> Alex
> 
> > Signed-off-by: Alexandru Ardelean 
> > Signed-off-by: Paul Cercueil 
> > ---
> >  drivers/iio/buffer/industrialio-buffer-dma.c | 39 +++-
> >  1 file changed, 22 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c 
> > b/drivers/iio/buffer/industrialio-buffer-dma.c
> > index d6b2e0cf..eb8cfd3af030 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-dma.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-dma.c
> > @@ -358,6 +358,27 @@ int iio_dma_buffer_request_update(struct iio_buffer 
> > *buffer)
> >  }
> >  EXPORT_SYMBOL_GPL(iio_dma_buffer_request_update);
> >
> > +static void iio_dma_buffer_fileio_free(struct iio_dma_buffer_queue *queue)
> > +{
> > +   unsigned int i;
> > +
> > +   spin_lock_irq(>list_lock);
> > +   for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
> > +   if (!queue->fileio.blocks[i])
> > +   continue;
> > +   queue->fileio.blocks[i]->state = IIO_BLOCK_STATE_DEAD;
> > +   }
> > +   spin_unlock_irq(>list_lock);
> > +
> > +   for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
> > +   if (!queue->fileio.blocks[i])
> > +   continue;
> > +   iio_buffer_block_put(queue->fileio.blocks[i]);
> > +   queue->fileio.blocks[i] = NULL;
> > +   }
> > +   queue->fileio.active_block = NULL;
> > +}
> > +
> >  static void iio_dma_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > struct iio_dma_buffer_block *block)
> >  {
> > @@ -681,25 +702,9 @@ EXPORT_SYMBOL_GPL(iio_dma_buffer_init);
> >   */
> >  void iio_dma_buffer_exit(struct iio_dma_buffer_queue *queue)
> >  {
> > -   unsigned int i;
> > -
> > mutex_lock(>lock);
> >
> > -   spin_lock_irq(>list_lock);
> > -   for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
> > -   if (!queue->fileio.blocks[i])
> > -   continue;
> > -   queue->fileio.blocks[i]->state = IIO_BLOCK_STATE_DEAD;
> > -   }
> > -   spin_unlock_irq(>list_lock);
> > -
> > -   for (i = 0; i < ARRAY_SIZE(queue->fileio.blocks); i++) {
> > -   if (!queue->fileio.blocks[i])
> > -   continue;
> > -   iio_buffer_block_put(queue->fileio.blocks[i]);
> > -   queue->fileio.blocks[i] = NULL;
> > -   }
> > -   queue->fileio.active_block = NULL;
> > +   iio_dma_buffer_fileio_free(queue);
> > queue->ops = NULL;
> >
> > mutex_unlock(>lock);
> > --
> > 2.33.0
> >  

Re: [PATCH] dt-bindings: Drop redundant minItems/maxItems

[Jonathan Cameron]

On Tue, 15 Jun 2021 13:15:43 -0600
Rob Herring  wrote:

> If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
> same size as the list is redundant and can be dropped. Note that is DT
> schema specific behavior and not standard json-schema behavior. The tooling
> will fixup the final schema adding any unspecified minItems/maxItems.
> 
> This condition is partially checked with the meta-schema already, but
> only if both 'minItems' and 'maxItems' are equal to the 'items' length.
> An improved meta-schema is pending.
> 

...

>  .../devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml   | 1 -

For this one, the fact it overrides maxItems elsewhere makes this a little
bit odd.  I guess we can get used to it being implicit.

>  .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 2 --

Acked-by: Jonathan Cameron 

Re: [PATCH 00/25] Rid W=1 warnings from HID

[Jonathan Cameron]

On Wed, 24 Mar 2021 17:33:39 +
Lee Jones  wrote:

> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.

Lee, it's a bit novel to cc linux-iio on the cover letter but
none of the actual patches..  Or least none of them reached
me or lore.kernel.org

I'm sure they are great :)

Jonathan

> 
> Lee Jones (25):
>   HID: intel-ish-hid: Remove unused variable 'err'
>   HID: ishtp-hid-client: Move variable to where it's actually used
>   HID: intel-ish-hid: pci-ish: Remove unused variable 'ret'
>   HID: intel-ish: Supply some missing param descriptions
>   HID: intel-ish: Fix a naming disparity and a formatting error
>   HID: usbhid: Repair a formatting issue in a struct description
>   HID: intel-ish-hid: Fix a little doc-rot
>   HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses
>   HID: hid-alps: Correct struct misnaming
>   HID: intel-ish-hid: Fix potential copy/paste error
>   HID: hid-core: Fix incorrect function name in header
>   HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in
> header
>   HID: ishtp-hid-client: Fix incorrect function name report_bad_packet()
>   HID: hid-kye: Fix incorrect function name for kye_tablet_enable()
>   HID: hid-picolcd_core: Remove unused variable 'ret'
>   HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote
> abuses
>   HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs
>   HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses
>   HID: hid-uclogic-params: Ensure function names are present and correct
> in kernel-doc headers
>   HID: hid-sensor-custom: Remove unused variable 'ret'
>   HID: wacom_sys: Demote kernel-doc abuse
>   HID: hid-sensor-hub: Remove unused struct member 'quirks'
>   HID: hid-sensor-hub: Move 'hsdev' description to correct struct
> definition
>   HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues
>   HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning
> 
>  drivers/hid/hid-alps.c   |  2 +-
>  drivers/hid/hid-core.c   |  2 +-
>  drivers/hid/hid-kye.c|  2 +-
>  drivers/hid/hid-logitech-hidpp.c |  7 +--
>  drivers/hid/hid-picolcd_core.c   |  5 +--
>  drivers/hid/hid-sensor-custom.c  |  5 +--
>  drivers/hid/hid-sensor-hub.c |  4 +-
>  drivers/hid/hid-thrustmaster.c   | 24 +--
>  drivers/hid/hid-uclogic-params.c |  8 ++--
>  drivers/hid/hid-uclogic-rdesc.c  |  2 +-
>  drivers/hid/intel-ish-hid/ipc/ipc.c  |  2 +-
>  drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  3 +-
>  drivers/hid/intel-ish-hid/ishtp-fw-loader.c  | 45 ++--
>  drivers/hid/intel-ish-hid/ishtp-hid-client.c | 11 +++--
>  drivers/hid/intel-ish-hid/ishtp-hid.c|  2 +-
>  drivers/hid/intel-ish-hid/ishtp-hid.h|  9 +---
>  drivers/hid/intel-ish-hid/ishtp/bus.c|  9 +++-
>  drivers/hid/intel-ish-hid/ishtp/client.c |  5 +--
>  drivers/hid/intel-ish-hid/ishtp/hbm.c|  4 +-
>  drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  4 +-
>  drivers/hid/usbhid/hid-pidff.c   |  4 +-
>  drivers/hid/usbhid/usbkbd.c  |  2 +-
>  drivers/hid/wacom_sys.c  |  2 +-
>  include/linux/intel-ish-client-if.h  |  8 +++-
>  24 files changed, 90 insertions(+), 81 deletions(-)
> 
> Cc: Alexandre Torgue 
> Cc: Anssi Hannula 
> Cc: Benjamin Tissoires 
> Cc: "Bruno Prémont" 
> Cc: "Christian König" 
> Cc: Daniel Drubin 
> Cc: Dario Pagani 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Henrik Rydberg 
> Cc: Jiri Kosina 
> Cc: Jonathan Cameron 
> Cc: Kai-Heng Feng 
> Cc: Kim Kuparinen 
> Cc: "Krzysztof Wilczyński" 
> Cc: Lee Jones 
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-...@vger.kernel.org
> Cc: Lopez Casado 
> Cc: "L. Vinyard, Jr" 
> Cc: Masaki Ota 
> Cc: Maxime Coquelin 
> Cc: message to 
> Cc: Michael Haboustak 
> Cc: Rushikesh S Kadam 
> Cc: Srinivas Pandruvada 
> Cc: Sumit Semwal 
> Cc: "Uwe Kleine-König" 
> Cc: Vojtech Pavlik 
> Cc: Zhang Lixu 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: Add missing array size constraints

[Jonathan Cameron]

On Mon, 4 Jan 2021 16:02:53 -0700
Rob Herring  wrote:

> DT properties which can have multiple entries need to specify what the
> entries are and define how many entries there can be. In the case of
> only a single entry, just 'maxItems: 1' is sufficient.
> 
> Add the missing entry constraints. These were found with a modified
> meta-schema. Unfortunately, there are a few cases where the size
> constraints are not defined such as common bindings, so the meta-schema
> can't be part of the normal checks.
> 
> Cc: Jens Axboe 
> Cc: Stephen Boyd 
> Cc: Thierry Reding 
> Cc: MyungJoo Ham 
> Cc: Chanwoo Choi 
> Cc: Linus Walleij 
> Cc: Bartosz Golaszewski 
> Cc: Jonathan Cameron 
> Cc: Dmitry Torokhov 
> Cc: Thomas Gleixner 
> Cc: Marc Zyngier 
> Cc: Mauro Carvalho Chehab 
> Cc: Chen-Yu Tsai 
> Cc: Ulf Hansson 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: Sebastian Reichel 
> Cc: Ohad Ben-Cohen 
> Cc: Bjorn Andersson 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Rob Herring 

Acked-by: Jonathan Cameron  #for-iio

> ---
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-remotep...@vger.kernel.org
> Cc: linux-ri...@lists.infradead.org
> Cc: linux-ser...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> ---
>  .../socionext,uniphier-system-cache.yaml  |  4 ++--
>  .../bindings/ata/sata_highbank.yaml   |  1 +
>  .../bindings/clock/canaan,k210-clk.yaml   |  1 +
>  .../bindings/display/brcm,bcm2711-hdmi.yaml   |  1 +
>  .../bindings/display/brcm,bcm2835-hdmi.yaml   |  1 +
>  .../display/panel/jdi,lt070me05000.yaml   |  1 +
>  .../display/panel/mantix,mlaf057we51-x.yaml   |  3 ++-
>  .../display/panel/novatek,nt36672a.yaml   |  1 +
>  .../devicetree/bindings/dsp/fsl,dsp.yaml  |  2 +-
>  .../devicetree/bindings/eeprom/at25.yaml  |  3 +--
>  .../bindings/extcon/extcon-ptn5150.yaml   |  2 ++
>  .../bindings/gpio/gpio-pca95xx.yaml   |  1 +
>  .../bindings/iio/adc/adi,ad7768-1.yaml|  2 ++
>  .../bindings/iio/adc/aspeed,ast2400-adc.yaml  |  1 +
>  .../bindings/iio/adc/lltc,ltc2496.yaml|  2 +-
>  .../bindings/iio/adc/qcom,spmi-vadc.yaml  |  1 +
>  .../bindings/iio/adc/st,stm32-adc.yaml|  2 ++
>  .../iio/magnetometer/asahi-kasei,ak8975.yaml  |  1 +
>  .../iio/potentiometer/adi,ad5272.yaml |  1 +
>  .../input/touchscreen/elan,elants_i2c.yaml|  1 +
>  .../interrupt-controller/fsl,intmux.yaml  |  2 +-
>  .../interrupt-controller/st,stm32-exti.yaml   |  2 ++
>  .../allwinner,sun4i-a10-video-engine.yaml |  1 +
>  .../devicetree/bindings/media/i2c/imx219.yaml |  1 +
>  .../memory-controllers/exynos-srom.yaml   |  2 ++
>  .../bindings/misc/fsl,dpaa2-console.yaml  |  1 +
>  .../bindings/mmc/mmc-controller.yaml  |  2 ++
>  .../bindings/net/ti,k3-am654-cpsw-nuss.yaml   |  1 +
>  .../bindings/net/ti,k3-am654-cpts.yaml|  1 +
>  .../phy/allwinner,sun4i-a10-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun50i-a64-usb-phy.yaml |  2 ++
>  .../phy/allwinner,sun50i-h6-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun5i-a13-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun6i-a31-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun8i-a23-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun8i-a83t-usb-phy.yaml |  2 ++
>  .../phy/allwinner,sun8i-h3-usb-phy.yaml   |  2 ++
>  .../phy/allwinner,sun8i-r40-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun8i-v3s-usb-phy.yaml  |  2 ++
>  .../phy/allwinner,sun9i-a80-usb-phy.yaml  | 19 ---
>  .../phy/socionext,uniphier-ahci-phy.yaml  |  2 +-
>  .../phy/socionext,uniphier-pcie-phy.yaml  |  2 +-
>  .../phy/socionext,uniphier-usb3hs-phy.yaml|  2 +-
>  .../phy/socionext,uniphier-usb3ss-phy.yaml|  2 +-
>  .../bindings/phy/ti,phy-gmii-sel.yaml |  2 +-
>  .../pinctrl/aspeed,ast2400-pinctrl.yaml   |  3 +--
>  .../pinctrl/aspeed,ast2500-pinctrl.yaml   |  4 ++--
>  .../bindings/power/supply/bq25980.yaml|  1 +
>  .../bindings/remoteproc/ingenic,vpu.yaml  |  2 +-
>  .../remoteproc/ti,omap-remoteproc.yaml|  3 +++
>  .../bindings/riscv/sifive-l2-cache.yaml   |  1 +
>  .../bindings/serial/renesas,hscif.yaml|  2 ++
>  .../bindings/serial/renesas,scif.yaml |  2 ++
>  .../bindings/se

Re: [PATCH] dt-bindings: Drop unnecessary *-supply schemas properties

[Jonathan Cameron]

On Mon, 21 Dec 2020 16:46:59 -0700
Rob Herring  wrote:

> *-supply properties are always a single phandle, so binding schemas
> don't need a type $ref nor 'maxItems'.
> 
> A meta-schema check for this is pending once these existing cases are
> fixed.
> 
> Cc: Jonathan Cameron 
> Cc: Dmitry Torokhov 
> Cc: Laurent Pinchart 
> Cc: Mauro Carvalho Chehab 
> Cc: Sakari Ailus 
> Cc: Lee Jones 
> Cc: Mark Brown 
> Cc: Maxime Ripard 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by: Jonathan Cameron  #for-iio

> ---
>  Documentation/devicetree/bindings/display/bridge/anx6345.yaml | 2 --
>  .../devicetree/bindings/display/bridge/ite,it6505.yaml| 2 --
>  .../devicetree/bindings/display/bridge/lvds-codec.yaml| 3 +--
>  Documentation/devicetree/bindings/display/bridge/ps8640.yaml  | 2 --
>  .../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 -
>  .../bindings/display/bridge/thine,thc63lvd1024.yaml   | 1 -
>  .../devicetree/bindings/display/bridge/toshiba,tc358775.yaml  | 2 --
>  Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml   | 4 +---
>  .../devicetree/bindings/iio/humidity/ti,hdc2010.yaml  | 3 +--
>  .../devicetree/bindings/input/fsl,mpr121-touchkey.yaml| 3 +--
>  .../devicetree/bindings/input/touchscreen/edt-ft5x06.yaml | 3 +--
>  .../devicetree/bindings/media/i2c/maxim,max9286.yaml  | 1 -
>  Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 3 ---
>  Documentation/devicetree/bindings/media/i2c/sony,imx214.yaml  | 3 ---
>  Documentation/devicetree/bindings/media/i2c/sony,imx274.yaml  | 3 ---
>  Documentation/devicetree/bindings/mfd/st,stmfx.yaml   | 3 +--
>  .../devicetree/bindings/regulator/anatop-regulator.yaml   | 1 -
>  17 files changed, 6 insertions(+), 34 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml 
> b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
> index 8c0e4f285fbc..fccd63521a8c 100644
> --- a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml
> @@ -26,11 +26,9 @@ properties:
>  description: GPIO connected to active low reset
>  
>dvdd12-supply:
> -maxItems: 1
>  description: Regulator for 1.2V digital core power.
>  
>dvdd25-supply:
> -maxItems: 1
>  description: Regulator for 2.5V digital core power.
>  
>ports:
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> index efbb3d0117dc..02cfc0a3b550 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -35,11 +35,9 @@ properties:
>  maxItems: 1
>  
>ovdd-supply:
> -maxItems: 1
>  description: I/O voltage
>  
>pwr18-supply:
> -maxItems: 1
>  description: core voltage
>  
>interrupts:
> diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml 
> b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> index e5e3c72630cf..66a14d60ce1d 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
> @@ -79,8 +79,7 @@ properties:
>The GPIO used to control the power down line of this device.
>  maxItems: 1
>  
> -  power-supply:
> -maxItems: 1
> +  power-supply: true
>  
>  required:
>- compatible
> diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
> index 7e27cfcf770d..763c7909473e 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml
> @@ -35,11 +35,9 @@ properties:
>  description: GPIO connected to active low reset.
>  
>vdd12-supply:
> -maxItems: 1
>  description: Regulator for 1.2V digital core power.
>  
>vdd33-supply:
> -maxItems: 1
>  description: Regulator for 3.3V digital core power.
>  
>ports:
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml 
> b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
> index 3ddb35fcf0a2..64e8a1c24b40 100644
> --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml

Re: [PATCH] dt-bindings: More whitespace clean-ups in schema files

[Jonathan Cameron]

On Fri, 23 Oct 2020 14:22:58 -0500
Rob Herring  wrote:

> Clean-up incorrect indentation, extra spaces, and missing EOF newline in
> schema files. Most of the clean-ups are for list indentation which
> should always be 2 spaces more than the preceding keyword.
> 
> Found with yamllint (now integrated into the checks).
> 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring 

Acked-by:  Jonathan Cameron  #for-iio

> ---
>  .../display/bridge/toshiba,tc358775.yaml  |  18 ++--
>  .../display/panel/ilitek,ili9881c.yaml|   5 +-
>  .../devicetree/bindings/eeprom/at25.yaml  |   6 +-
>  .../bindings/gpio/kontron,sl28cpld-gpio.yaml  |   4 +-
>  .../devicetree/bindings/i2c/ingenic,i2c.yaml  |   8 +-
>  .../bindings/iio/adc/adi,ad7291.yaml  |   3 +-
>  .../bindings/iio/adc/adi,ad7768-1.yaml|   3 +-
>  .../bindings/iio/adc/cosmic,10001-adc.yaml|   4 +-
>  .../bindings/iio/adc/holt,hi8435.yaml |   2 +-
>  .../interrupt-controller/ti,pruss-intc.yaml   |  12 +--
>  .../devicetree/bindings/mfd/ene-kb3930.yaml   |   2 +-
>  .../devicetree/bindings/mmc/arasan,sdhci.yaml |   8 +-
>  .../devicetree/bindings/mmc/sdhci-am654.yaml  |  15 ++-
>  .../pci/socionext,uniphier-pcie-ep.yaml   |  18 ++--
>  .../phy/socionext,uniphier-ahci-phy.yaml  |   6 +-
>  .../devicetree/bindings/phy/ti,omap-usb2.yaml |  20 ++--
>  .../pinctrl/actions,s500-pinctrl.yaml | 102 +-
>  .../bindings/pinctrl/pinctrl-mt8192.yaml  |   2 +-
>  .../pinctrl/qcom,msm8226-pinctrl.yaml |   6 +-
>  .../pinctrl/toshiba,visconti-pinctrl.yaml |  24 ++---
>  .../bindings/power/reset/reboot-mode.yaml |   6 +-
>  .../power/supply/ingenic,battery.yaml |   8 +-
>  .../power/supply/summit,smb347-charger.yaml   |  16 +--
>  .../bindings/riscv/sifive-l2-cache.yaml   |   4 +-
>  .../devicetree/bindings/rng/imx-rng.yaml  |   6 +-
>  .../bindings/serial/fsl-imx-uart.yaml |  34 +++---
>  .../bindings/sound/mchp,spdifrx.yaml  |   4 +-
>  .../bindings/sound/mchp,spdiftx.yaml  |   4 +-
>  .../bindings/sound/qcom,lpass-cpu.yaml|  40 +++
>  .../devicetree/bindings/timer/arm,sp804.yaml  |  12 +--
>  .../devicetree/bindings/usb/cdns,usb3.yaml|   4 +-
>  .../devicetree/bindings/usb/ti,hd3ss3220.yaml |   2 +-
>  .../devicetree/bindings/w1/fsl-imx-owire.yaml |   8 +-
>  33 files changed, 210 insertions(+), 206 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml 
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> index 31f085d8ab13..526bbd63924b 100644
> --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
>  title: Toshiba TC358775 DSI to LVDS bridge bindings
>  
>  maintainers:
> - - Vinay Simha BN 
> +  - Vinay Simha BN 
>  
>  description: |
>   This binding supports DSI to LVDS bridge TC358775
> @@ -29,7 +29,7 @@ properties:
>  
>vdd-supply:
>  maxItems: 1
> -description:  1.2V LVDS Power Supply
> +description: 1.2V LVDS Power Supply
>  
>vddio-supply:
>  maxItems: 1
> @@ -77,13 +77,13 @@ properties:
>- port@1
>  
>  required:
> - - compatible
> - - reg
> - - vdd-supply
> - - vddio-supply
> - - stby-gpios
> - - reset-gpios
> - - ports
> +  - compatible
> +  - reg
> +  - vdd-supply
> +  - vddio-supply
> +  - stby-gpios
> +  - reset-gpios
> +  - ports
>  
>  examples:
>   - |
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml 
> b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> index c60b3bd74337..b2fcec4f22fd 100644
> --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> @@ -13,9 +13,8 @@ properties:
>compatible:
>  items:
>- enum:
> -- bananapi,lhr050h41
> -- feixin,k101-im2byl02
> -
> +  - bananapi,lhr050h41
> +  - feixin,k101-im2byl02
>- const: ilitek,ili9881c
>  
>backlight: true
> diff --git a/Documentation/devicetree/bindings/eepr

Re: [PATCH 2/4] dt-bindings: Use 'additionalProperties' instead of 'unevaluatedProperties'

[Jonathan Cameron]

On Mon, 5 Oct 2020 13:38:28 -0500
Rob Herring  wrote:

> In cases where we don't reference another schema, 'additionalProperties'
> can be used instead. This is preferred for now as 'unevaluatedProperties'
> support isn't implemented yet.
> 
> In a few cases, this means adding some missing property definitions of
> which most are for SPI bus properties. 'unevaluatedProperties' is not going
> to work for the SPI bus properties anyways as they are evaluated from the
> parent node, not the SPI child node.
> 
> Signed-off-by: Rob Herring 

Acked-by: Jonathan Cameron 

> ---
>  .../devicetree/bindings/clock/baikal,bt1-ccu-div.yaml  |  6 +-
>  .../devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml  |  2 +-
>  .../devicetree/bindings/clock/imx8m-clock.yaml |  2 +-
>  .../devicetree/bindings/hwmon/baikal,bt1-pvt.yaml  |  4 ++--
>  .../devicetree/bindings/iio/accel/adi,adis16240.yaml   |  4 +++-
>  .../devicetree/bindings/iio/accel/adi,adxl345.yaml |  4 +++-
>  .../devicetree/bindings/iio/accel/adi,adxl372.yaml |  4 +++-
>  .../devicetree/bindings/iio/adc/adi,ad7124.yaml|  4 +++-
>  .../devicetree/bindings/iio/adc/adi,ad7192.yaml|  4 +++-
>  .../devicetree/bindings/iio/adc/adi,ad7292.yaml|  4 +++-
>  .../devicetree/bindings/iio/adc/adi,ad7606.yaml|  6 +-
>  .../devicetree/bindings/iio/adc/adi,ad7923.yaml|  4 +++-
>  .../devicetree/bindings/iio/adc/maxim,max1241.yaml |  4 +++-
>  .../devicetree/bindings/iio/dac/adi,ad5770r.yaml   | 10 +-
>  .../devicetree/bindings/iio/frequency/adf4371.yaml |  4 +++-
>  .../devicetree/bindings/iio/imu/adi,adis16460.yaml |  4 +++-
>  .../devicetree/bindings/iio/imu/adi,adis16475.yaml |  2 +-
>  .../devicetree/bindings/iio/imu/bosch,bmi160.yaml  |  4 +++-
>  .../devicetree/bindings/iio/imu/nxp,fxos8700.yaml  |  4 +++-
>  .../bindings/interrupt-controller/mti,gic.yaml |  2 +-
>  .../devicetree/bindings/mfd/cirrus,lochnagar.yaml  | 10 +-
>  .../bindings/mfd/ti,j721e-system-controller.yaml   |  5 -
>  .../devicetree/bindings/misc/olpc,xo1.75-ec.yaml   |  4 +++-
>  .../opp/allwinner,sun50i-h6-operating-points.yaml  |  4 +++-
>  .../bindings/regulator/qcom-labibb-regulator.yaml  |  2 +-
>  .../devicetree/bindings/timer/snps,dw-apb-timer.yaml   |  2 +-
>  26 files changed, 82 insertions(+), 27 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml 
> b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
> index 2821425ee445..bd4cefbb1244 100644
> --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
> +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-div.yaml
> @@ -134,7 +134,11 @@ properties:
>"#reset-cells":
>  const: 1
>  
> -unevaluatedProperties: false
> +  clocks: true
> +
> +  clock-names: true
> +
> +additionalProperties: false
>  
>  required:
>- compatible
> diff --git a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml 
> b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> index 97131bfa6f87..624984d51c10 100644
> --- a/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> +++ b/Documentation/devicetree/bindings/clock/baikal,bt1-ccu-pll.yaml
> @@ -101,7 +101,7 @@ properties:
>clock-names:
>  const: ref_clk
>  
> -unevaluatedProperties: false
> +additionalProperties: false
>  
>  required:
>- compatible
> diff --git a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml 
> b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> index 31e7cc9693c3..625f573a7b90 100644
> --- a/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> +++ b/Documentation/devicetree/bindings/clock/imx8m-clock.yaml
> @@ -96,7 +96,7 @@ allOf:
>  - const: clk_ext3
>  - const: clk_ext4
>  
> -unevaluatedProperties: false
> +additionalProperties: false
>  
>  examples:
># Clock Control Module node:
> diff --git a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml 
> b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
> index 84ae4cdd08ed..00a6511354e6 100644
> --- a/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/baikal,bt1-pvt.yaml
> @@ -79,7 +79,7 @@ properties:
>minimum: 0
>maximum: 7130
>  
> -unevaluatedProperties: false
> +additionalProperties: false
>  
>  required:
>- compatible
> @@ -99,7 +99,7 @@ examples:
>  
>interrupts = ;
>  
> -  baikal,pvt-temp-trim-millicelsius = <1000>;
> +  baikal,pvt-temp-offset-millicelsius = <1000>

Re: [PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas

[Jonathan Cameron]

On Mon, 5 Oct 2020 13:38:30 -0500
Rob Herring  wrote:

> In order to add meta-schema checks for additional/unevaluatedProperties
> being present, all schema need to make this explicit. As common/shared
> schema are included by other schemas, they should always allow for
> additionalProperties.
> 
> Signed-off-by: Rob Herring 

>  Documentation/devicetree/bindings/iio/common.yaml| 2 ++
For IIO

Acked-by: Jonathan Cameron 
>  ...


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: Another round of adding missing 'additionalProperties'

[Jonathan Cameron]

On Fri, 2 Oct 2020 18:41:43 -0500
Rob Herring  wrote:

> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
> 
> Cc: Thierry Reding 
> Cc: Linus Walleij 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Cc: Bjorn Andersson 
> Cc: Baolin Wang 
> Cc: Guenter Roeck 
> Cc: Jonathan Cameron 
> Cc: Mauro Carvalho Chehab 
> Cc: Laurent Pinchart 
> Cc: Lee Jones 
> Cc: Ulf Hansson 
> Cc: "David S. Miller" 
> Cc: Bjorn Helgaas 
> Cc: Vinod Koul 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Greg Kroah-Hartman 
> Cc: Daniel Lezcano 
> Cc: linux-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-hw...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: openipmi-develo...@lists.sourceforge.net
> Cc: linux-l...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-m...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-remotep...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---

Hi Rob,

Acked-by: Jonathan Cameron  # for iio


However, one of these made me wonder if the binding was simply wrong...
(definitely highlights why we should have additionalProperties: false
where ever possible).

...


> diff --git 
> a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml 
> b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> index abd8d25e1136..4c1c083d0e92 100644
> --- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> +++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> @@ -47,11 +47,17 @@ properties:
>vddio-supply:
>  description: Regulator that provides power to the bus
>  
> +  spi-max-frequency: true
> +  spi-cpha: true
> +  spi-cpol: true

It isn't completely unheard of for a device to operate in multiple SPI modes, 
but
it does seem to be fairly unusual.  I took a look at the datasheet and at least
from the provided timing diagrams, these are both required in SPI mode.

http://invensense.tdk.com/wp-content/uploads/2020/09/DS-000292-ICM-42605-v1.5.pdf

That doesn't make the binding wrong as such, but we could be tighter in 
checking this!

I'll add this to my list to take a closer look at sometime soonish.

Thanks.

Jonathan

> +
>  required:
>- compatible
>- reg
>- interrupts
>  
> +additionalProperties: false
> +
>  examples:
>- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] MAINTAINERS: add Dan Murphy as TP LP8xxx drivers maintainer

[Jonathan Cameron]

On Wed, 23 Sep 2020 11:53:33 -0500
Dan Murphy  wrote:

> Hello
> 
> On 9/22/20 10:28 AM, Krzysztof Kozlowski wrote:
> > Milo Kim's email in TI bounces with permanent error (550: Invalid
> > recipient).  Last email from him on LKML was in 2017.  Move Milo Kim to
> > credits and add Dan Murphy from TI to look after:
> >   - TI LP855x backlight driver,
> >   - TI LP8727 charger driver,
> >   - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers.
> >
> > Cc: Dan Murphy 
> > Signed-off-by: Krzysztof Kozlowski   
> 
> Acked-by: Dan Murphy 
> 
Not sure who will pick this one up, but
Acked-by: Jonathan Cameron 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dt-bindings: Whitespace clean-ups in schema files

[Jonathan Cameron]

On Wed, 12 Aug 2020 23:34:53 +0200
Sam Ravnborg  wrote:

> Hi Rob.
> 
> On Wed, Aug 12, 2020 at 02:36:18PM -0600, Rob Herring wrote:
> > Clean-up incorrect indentation, extra spaces, long lines, and missing
> > EOF newline in schema files. Most of the clean-ups are for list
> > indentation which should always be 2 spaces more than the preceding
> > keyword.
> > 
> > Found with yamllint (which I plan to integrate into the checks).  
> 
> I have browsed through the patch - and there was only a few things
> that jumped at me.
> 
> With these points considered:
> Acked-by: Sam Ravnborg 

Replying here as the patch doesn't seem to have made it to linux-iio
at least. I'm not sure why...

Anyhow, found it in an lkml archive so for the iio changes
Acked-by: Jonathan Cameron 

> 
> I expect only some (few) of my points to actually results in any updates.
> 
> I look forward to have the lint functionality as part of the built-in
> tools so we catch these things early.
> 
>   Sam
> 
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
> > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index f63895c8ce2d..88814a2a14a5 100644
> > --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > @@ -273,8 +273,8 @@ properties:
> >- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK 
> > Board
> >- kontron,imx6ull-n6411-som # Kontron N6411 SOM
> >- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation 
> > Board
> > -  - toradex,colibri-imx6ull-eval# Colibri iMX6ULL 
> > Module on Colibri Evaluation Board
> > -  - toradex,colibri-imx6ull-wifi-eval   # Colibri iMX6ULL 
> > Wi-Fi / Bluetooth Module on Colibri Evaluation Board
> > +  - toradex,colibri-imx6ull-eval  # Colibri iMX6ULL Module 
> > on Colibri Eval Board
> > +  - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi 
> > / BT Module on Colibri Eval Board
> >- const: fsl,imx6ull  
> 
> This change looks bad as it drops the alignment with the comments below.
> See following patch chunck:
> 
> >
> >- description: Kontron N6411 S Board
> > @@ -312,9 +312,12 @@ properties:
> >- toradex,colibri-imx7d   # Colibri iMX7 
> > Dual Module
> >- toradex,colibri-imx7d-aster # Colibri iMX7 
> > Dual Module on Aster Carrier Board
> >- toradex,colibri-imx7d-emmc  # Colibri iMX7 
> > Dual 1GB (eMMC) Module
> > -  - toradex,colibri-imx7d-emmc-aster# Colibri iMX7 
> > Dual 1GB (eMMC) Module on Aster Carrier Board
> > -  - toradex,colibri-imx7d-emmc-eval-v3  # Colibri iMX7 
> > Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
> > -  - toradex,colibri-imx7d-eval-v3   # Colibri iMX7 
> > Dual Module on Colibri Evaluation Board V3
> > +  - toradex,colibri-imx7d-emmc-aster# Colibri iMX7 
> > Dual 1GB (eMMC) Module on
> > +#  Aster Carrier 
> > Board  
> 
> 
> 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml 
> > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> > index 177d48c5bd97..e89c1ea62ffa 100644
> > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml
> > @@ -25,8 +25,7 @@ properties:
> >compatible:
> >  items:
> >- enum:
> > -- dlink,dir-685-panel
> > -
> > +  - dlink,dir-685-panel
> >- const: ilitek,ili9322
> >
> >reset-gpios: true
> > diff --git 
> > a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml 
> > b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> > index a39332276bab..76a9068a85dd 100644
> > --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
> > @@ -13,8 +13,7 @@ properties:
> >compatible:
> >  items:
> >- enum:
> > -- bananapi,lhr050h41
> > -
> > +  - bananapi,lhr050h41
> >- const: ilitek,ili9881c
> >  
> 
> The extra lines is a simple way to indicate that here shall be added
> more in the future. So I like the empty

Re: [PATCH 2/2] dt-bindings: Remove cases of 'allOf' containing a '$ref'

[Jonathan Cameron]

On Wed, 15 Apr 2020 19:55:49 -0500
Rob Herring  wrote:

> json-schema versions draft7 and earlier have a weird behavior in that
> any keywords combined with a '$ref' are ignored (silently). The correct
> form was to put a '$ref' under an 'allOf'. This behavior is now changed
> in the 2019-09 json-schema spec and '$ref' can be mixed with other
> keywords. The json-schema library doesn't yet support this, but the
> tooling now does a fixup for this and either way works.
> 
> This has been a constant source of review comments, so let's change this
> treewide so everyone copies the simpler syntax.
> 
> Signed-off-by: Rob Herring 

A few unrelated white space changes in enums in the IIO chunks.

Don't suppose they matter but maybe need the description to mention there
may be some minor formatting changes as well in some cases.

Acked-by: Jonathan Cameron  #for-iio

> ---
>  .../devicetree/bindings/arm/cpus.yaml |  81 +++---
>  .../devicetree/bindings/arm/l2c2x0.yaml   |  87 +++---
>  .../devicetree/bindings/arm/psci.yaml |  15 +-
>  .../bindings/arm/samsung/exynos-chipid.yaml   |   5 +-
>  .../bus/allwinner,sun50i-a64-de2.yaml |   5 +-
>  .../bindings/clock/fixed-factor-clock.yaml|   5 +-
>  .../bindings/connector/usb-connector.yaml |  28 +-
>  .../bindings/crypto/st,stm32-hash.yaml|   9 +-
>  .../allwinner,sun4i-a10-display-engine.yaml   |   7 +-
>  .../display/allwinner,sun4i-a10-tcon.yaml |   5 +-
>  .../bindings/display/panel/panel-common.yaml  |   5 +-
>  .../devicetree/bindings/dma/dma-common.yaml   |   3 +-
>  .../devicetree/bindings/dma/ti/k3-udma.yaml   |  18 +-
>  .../devicetree/bindings/eeprom/at24.yaml  |  11 +-
>  .../devicetree/bindings/example-schema.yaml   |  17 +-
>  .../bindings/hwmon/adi,ltc2947.yaml   |  32 +--
>  .../devicetree/bindings/hwmon/ti,tmp513.yaml  |  21 +-
>  .../devicetree/bindings/i2c/st,stm32-i2c.yaml |   9 +-
>  .../bindings/iio/adc/adi,ad7124.yaml  |   5 +-
>  .../bindings/iio/adc/lltc,ltc2496.yaml|   3 +-
>  .../bindings/iio/adc/microchip,mcp3911.yaml   |   7 +-
>  .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml  |  31 +-
>  .../bindings/iio/light/tsl2772.yaml   |  13 +-
>  .../bindings/iio/temperature/adi,ltc2983.yaml |  56 ++--

...

> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml 
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
> index 97087a45ce54..deb34deff0e8 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
> @@ -83,9 +83,8 @@ patternProperties:
>1: REFIN2(+)/REFIN2(−).
>3: AVDD
>If this field is left empty, internal reference is selected.
> -allOf:
> -  - $ref: /schemas/types.yaml#/definitions/uint32
> -  - enum: [0, 1, 3]
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [0, 1, 3]
> 
>diff-channels:
>  description: see Documentation/devicetree/bindings/iio/adc/adc.txt
> diff --git a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml 
> b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
> index 97f521d654ea..6a991e9f78e2 100644
> --- a/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml
> @@ -18,8 +18,7 @@ properties:
> 
>vref-supply:
>  description: phandle to an external regulator providing the reference 
> voltage
> -allOf:
> -  - $ref: /schemas/types.yaml#/definitions/phandle
> +$ref: /schemas/types.yaml#/definitions/phandle
> 
>reg:
>  description: spi chipselect number according to the usual spi bindings
> diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml 
> b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
> index 8ffeceb6abae..95ab285f4eba 100644
> --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3911.yaml
> @@ -38,10 +38,9 @@ properties:
> 
>microchip,device-addr:
>  description: Device address when multiple MCP3911 chips are present on 
> the same SPI bus.
> -allOf:
> -  - $ref: /schemas/types.yaml#/definitions/uint32
> -  - enum: [0, 1, 2, 3]
> -  - default: 0
> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [0, 1, 2, 3]
> +default: 0
> 
>vref-supply:
>  description: |
> diff --git 
> a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml 
> b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
> index b1627441a0b2..d69ca492d020 100644
> --- a/D

Re: [PATCH 1/2] dt-bindings: Clean-up schema indentation formatting

[Jonathan Cameron]

On Wed, 15 Apr 2020 19:55:48 -0500
Rob Herring  wrote:

> Fix various inconsistencies in schema indentation. Most of these are
> list indentation which should be 2 spaces more than the start of the
> enclosing keyword. This doesn't matter functionally, but affects running
> scripts which do transforms on the schema files.
> 
> Signed-off-by: Rob Herring 
> ---

...

>  .../bindings/iio/adc/adi,ad7124.yaml  |  4 +-
>  .../bindings/iio/adc/lltc,ltc2496.yaml|  6 +-

Acked-by: Jonathan Cameron  #for-iio

>  .../input/allwinner,sun4i-a10-lradc-keys.yaml |  4 +-
>  .../bindings/input/touchscreen/goodix.yaml|  2 +-
>  .../bindings/interconnect/qcom,msm8916.yaml   |  4 +-
>  .../bindings/interconnect/qcom,msm8974.yaml   |  4 +-
>  .../bindings/interconnect/qcom,qcs404.yaml|  4 +-
>  .../allwinner,sun7i-a20-sc-nmi.yaml   | 12 ++--
>  .../intel,ixp4xx-interrupt.yaml   |  8 +--
>  .../interrupt-controller/st,stm32-exti.yaml   | 12 ++--
>  .../bindings/iommu/samsung,sysmmu.yaml| 10 +--
>  .../bindings/mailbox/st,stm32-ipcc.yaml   |  2 +-
>  .../media/allwinner,sun4i-a10-csi.yaml| 28 
>  .../bindings/media/amlogic,gx-vdec.yaml   | 14 ++--
>  .../bindings/media/renesas,ceu.yaml   | 28 
>  .../bindings/media/renesas,vin.yaml   |  8 +--
>  .../devicetree/bindings/media/ti,vpe.yaml |  2 +-
>  .../memory-controllers/fsl/imx8m-ddrc.yaml|  6 +-
>  .../bindings/mfd/st,stm32-lptimer.yaml|  4 +-
>  .../bindings/mfd/st,stm32-timers.yaml |  4 +-
>  .../devicetree/bindings/mfd/syscon.yaml   | 12 ++--
>  .../devicetree/bindings/mmc/cdns,sdhci.yaml   |  2 +-
>  .../bindings/mmc/rockchip-dw-mshc.yaml| 16 ++---
>  .../bindings/mmc/socionext,uniphier-sd.yaml   | 14 ++--
>  .../devicetree/bindings/mtd/denali,nand.yaml  |  4 +-
>  .../net/allwinner,sun8i-a83t-emac.yaml|  4 +-
>  .../bindings/net/can/bosch,m_can.yaml | 52 +++
>  .../bindings/net/renesas,ether.yaml   |  4 +-
>  .../bindings/net/ti,cpsw-switch.yaml  | 12 ++--
>  .../bindings/net/ti,davinci-mdio.yaml | 27 
>  .../bindings/phy/intel,lgm-emmc-phy.yaml  |  2 +-
>  .../devicetree/bindings/pwm/pwm-samsung.yaml  | 16 ++---
>  .../bindings/remoteproc/st,stm32-rproc.yaml   |  2 +-
>  .../reset/brcm,bcm7216-pcie-sata-rescal.yaml  |  4 +-
>  .../devicetree/bindings/rtc/st,stm32-rtc.yaml | 38 +--
>  .../bindings/serial/amlogic,meson-uart.yaml   | 16 ++---
>  .../devicetree/bindings/serial/rs485.yaml | 17 ++---
>  .../bindings/soc/amlogic/amlogic,canvas.yaml  | 10 +--
>  .../bindings/sound/renesas,fsi.yaml   | 16 ++---
>  .../bindings/spi/qcom,spi-qcom-qspi.yaml  | 10 +--
>  .../devicetree/bindings/spi/renesas,hspi.yaml |  4 +-
>  .../devicetree/bindings/spi/spi-pl022.yaml|  2 +-
>  .../bindings/spi/st,stm32-qspi.yaml   |  4 +-
>  .../allwinner,sun4i-a10-system-control.yaml   | 64 +--
>  .../bindings/thermal/amlogic,thermal.yaml | 10 +--
>  .../bindings/timer/arm,arch_timer.yaml|  4 +-
>  .../bindings/timer/arm,arch_timer_mmio.yaml   |  4 +-
>  .../devicetree/bindings/usb/dwc2.yaml |  8 +--
>  77 files changed, 450 insertions(+), 450 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/altera.yaml 
> b/Documentation/devicetree/bindings/arm/altera.yaml
> index 49e0362ddc11..b388c5aa7984 100644
> --- a/Documentation/devicetree/bindings/arm/altera.yaml
> +++ b/Documentation/devicetree/bindings/arm/altera.yaml
> @@ -13,8 +13,8 @@ properties:
>compatible:
>  items:
>- enum:
> -- altr,socfpga-cyclone5
> -- altr,socfpga-arria5
> -- altr,socfpga-arria10
> +  - altr,socfpga-cyclone5
> +  - altr,socfpga-arria5
> +  - altr,socfpga-arria10
>- const: altr,socfpga
>  ...
> diff --git 
> a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
>  
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
> index 66213bd95e6e..6cc74523ebfd 100644
> --- 
> a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
> +++ 
> b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
> @@ -25,7 +25,7 @@ select:
> 
>  properties:
>compatible:
> -   items:
> +items:
>- const: amlogic,meson-gx-ao-secure
>- const: syscon
> 
> diff --git a/Documentation/devicetree/bindings/arm/bitmain.yaml 
> b/Documentation/devicetree/bindings/arm/bitmain.yaml
> index 0efdb4ac028e..5cd5b36cff2d 100644
> --- a/Documentation/devicetree/bindings/arm/bitmain.yaml
> +++ b/Docu

Re: [PATCH v2] of_device: removed #include that caused a recursion in included headers

[Jonathan Cameron]

On Thu, 16 Apr 2020 12:49:03 +0300
Hadar Gat  wrote:

> Both of_platform.h and of_device.h were included each other.
> In of_device.h, removed unneeded #include to of_platform.h
> and added include to of_platform.h in the files that needs it.
> 
> Signed-off-by: Hadar Gat 

Hmm.  I guess the chances of this causing merge problems are fairly low so
perhaps not worth doing additions of headers via individual subsystems and
actually dropping the header include after another cycle.

So on that basis

Acked-by: Jonathan Cameron  #for-iio

> ---
> v2: add include to of_platform.h in more files. (reported due other builds)
> 
>  arch/sparc/mm/io-unit.c   | 1 +
>  arch/sparc/mm/iommu.c | 1 +
>  drivers/base/platform.c   | 1 +
>  drivers/bus/imx-weim.c| 1 +
>  drivers/bus/vexpress-config.c | 1 +
>  drivers/clk/mediatek/clk-mt7622-aud.c | 1 +
>  drivers/dma/at_hdmac.c| 1 +
>  drivers/dma/stm32-dmamux.c| 1 +
>  drivers/dma/ti/dma-crossbar.c | 1 +
>  drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 +
>  drivers/gpu/drm/msm/hdmi/hdmi.c   | 1 +
>  drivers/gpu/drm/msm/msm_drv.c | 1 +
>  drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c   | 1 +
>  drivers/gpu/drm/sun4i/sun4i_tcon.c| 1 +
>  drivers/iio/adc/stm32-adc-core.c  | 1 +
>  drivers/iio/adc/stm32-dfsdm-adc.c | 1 +
>  drivers/iio/adc/stm32-dfsdm-core.c| 1 +
>  drivers/iommu/tegra-smmu.c| 1 +
>  drivers/memory/atmel-ebi.c| 1 +
>  drivers/mfd/palmas.c  | 1 +
>  drivers/mfd/ssbi.c| 1 +
>  drivers/mtd/nand/raw/omap2.c  | 1 +
>  drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 1 +
>  drivers/net/ethernet/ti/cpsw.c| 1 +
>  drivers/phy/tegra/xusb.c  | 1 +
>  drivers/pinctrl/freescale/pinctrl-imx1-core.c | 1 +
>  drivers/pinctrl/nomadik/pinctrl-nomadik.c | 1 +
>  drivers/soc/samsung/exynos-pmu.c  | 1 +
>  drivers/soc/sunxi/sunxi_sram.c| 1 +
>  include/linux/of_device.h | 2 --
>  lib/genalloc.c| 1 +
>  31 files changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/sparc/mm/io-unit.c b/arch/sparc/mm/io-unit.c
> index 289276b..5638399 100644
> --- a/arch/sparc/mm/io-unit.c
> +++ b/arch/sparc/mm/io-unit.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c
> index b00dde1..9cbb2e7 100644
> --- a/arch/sparc/mm/iommu.c
> +++ b/arch/sparc/mm/iommu.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 520..f549274b 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
> index 28bb65a..8c786da 100644
> --- a/drivers/bus/imx-weim.c
> +++ b/drivers/bus/imx-weim.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/bus/vexpress-config.c b/drivers/bus/vexpress-config.c
> index ff70575..12b8b0b 100644
> --- a/drivers/bus/vexpress-config.c
> +++ b/drivers/bus/vexpress-config.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  
> diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c 
> b/drivers/clk/mediatek/clk-mt7622-aud.c
> index 2bd4295..8cbb68f 100644
> --- a/drivers/clk/mediatek/clk-mt7622-aud.c
> +++ b/drivers/clk/mediatek/clk-mt7622-aud.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "clk-mtk.h"
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 73a2078..388f8e10 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "at_hdmac_regs.h"
> diff --git a/drivers/dma/stm32-dmamux.c b/drivers/dma/stm32-dmamux.c
> index 12f7637..b704896 100644
> --- a/drivers/dma/stm32-dma

Re: [PATCH trivial 4/6] iio: Fix misspellings of "Analog Devices"

[Jonathan Cameron]

On Thu, 16 Apr 2020 12:30:56 +0200
Geert Uytterhoeven  wrote:

> According to https://www.analog.com/, the company name is spelled
> "Analog Devices".
> 
> Signed-off-by: Geert Uytterhoeven 

Applied to the togreg branch of iio.git and pushed out as testing as there
are other things in that tree that need a build test.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/ad7791.c   | 2 +-
>  drivers/iio/trigger/iio-trig-hrtimer.c | 2 +-
>  drivers/staging/iio/Documentation/overview.txt | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7791.c b/drivers/iio/adc/ad7791.c
> index abb2393926317087..70bfc41052db2740 100644
> --- a/drivers/iio/adc/ad7791.c
> +++ b/drivers/iio/adc/ad7791.c
> @@ -444,5 +444,5 @@ static struct spi_driver ad7791_driver = {
>  module_spi_driver(ad7791_driver);
>  
>  MODULE_AUTHOR("Lars-Peter Clausen ");
> -MODULE_DESCRIPTION("Analog Device AD7787/AD7788/AD7789/AD7790/AD7791 ADC 
> driver");
> +MODULE_DESCRIPTION("Analog Devices AD7787/AD7788/AD7789/AD7790/AD7791 ADC 
> driver");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c 
> b/drivers/iio/trigger/iio-trig-hrtimer.c
> index a5e670726717f0d8..f59bf8d585866ea2 100644
> --- a/drivers/iio/trigger/iio-trig-hrtimer.c
> +++ b/drivers/iio/trigger/iio-trig-hrtimer.c
> @@ -4,7 +4,7 @@
>   *
>   * Copyright (C) Intuitive Aerial AB
>   * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
> - * Copyright (C) 2012, Analog Device Inc.
> + * Copyright (C) 2012, Analog Devices Inc.
>   *   Author: Lars-Peter Clausen 
>   * Copyright (C) 2015, Intel Corporation
>   */
> diff --git a/drivers/staging/iio/Documentation/overview.txt 
> b/drivers/staging/iio/Documentation/overview.txt
> index 43f92b06bc3e5574..ebdc64f451d7c798 100644
> --- a/drivers/staging/iio/Documentation/overview.txt
> +++ b/drivers/staging/iio/Documentation/overview.txt
> @@ -34,7 +34,7 @@ turned on or off (if possible) via sysfs interfaces.
>  fifo / ring buffers on the sensor chip.  These greatly reduce the load
>  on the host CPU by buffering relatively large numbers of data samples
>  based on an internal sampling clock. Examples include VTI SCA3000
> -series and Analog Device ADXL345 accelerometers.  Each buffer supports
> +series and Analog Devices ADXL345 accelerometers.  Each buffer supports
>  polling to establish when data is available.
>  
>  * Trigger and software buffer support. In many data analysis

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'

[Jonathan Cameron]

On Wed, 25 Mar 2020 16:05:41 -0600
Rob Herring  wrote:

> Setting 'additionalProperties: false' is frequently omitted, but is
> important in order to check that there aren't extra undocumented
> properties in a binding.
> 
> Ideally, we'd just add this automatically and make this the default, but
> there's some cases where it doesn't work. For example, if a common
> schema is referenced, then properties in the common schema aren't part
> of what's considered for 'additionalProperties'. Also, sometimes there
> are bus specific properties such as 'spi-max-frequency' that go into
> bus child nodes, but aren't defined in the child node's schema.
> 
> So let's stick with the json-schema defined default and add
> 'additionalProperties: false' where needed. This will be a continual
> review comment and game of wack-a-mole.
> 
> Signed-off-by: Rob Herring 

Acked-by: Jonathan Cameron 
for IIO ones.

Thanks.

> ---
>  .../devicetree/bindings/arm/altera/socfpga-clk-manager.yaml| 2 ++
>  .../bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml   | 2 ++
>  Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml   | 2 ++
>  Documentation/devicetree/bindings/arm/renesas,prr.yaml | 2 ++
>  .../devicetree/bindings/arm/samsung/exynos-chipid.yaml | 2 ++
>  Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 ++
>  .../bindings/arm/samsung/samsung-secure-firmware.yaml  | 2 ++
>  .../devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++
>  Documentation/devicetree/bindings/clock/fsl,plldig.yaml| 2 ++
>  Documentation/devicetree/bindings/clock/imx8mn-clock.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/imx8mp-clock.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/milbeaut-clock.yaml| 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml   | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml   | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml   | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,gcc.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++
>  .../devicetree/bindings/clock/qcom,msm8998-gpucc.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml   | 2 ++
>  .../devicetree/bindings/clock/qcom,sc7180-dispcc.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++
>  .../devicetree/bindings/clock/qcom,sc7180-videocc.yaml | 2 ++
>  .../devicetree/bindings/clock/qcom,sdm845-dispcc.yaml  | 2 ++
>  Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++
>  .../devicetree/bindings/clock/qcom,sdm845-videocc.yaml | 2 ++
>  .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 2 ++
>  .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml| 2 ++
>  Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++
>  Documentation/devicetree/bindings/eeprom/at24.yaml | 2 ++
>  .../firmware/intel,ixp4xx-network-processing-engine.yaml   | 3 +++
>  .../devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml  | 2 ++
>  .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml  | 2 ++
>  Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++
>  Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml| 2 ++
>  Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml| 2 ++
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++
>  Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 ++
>  Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml   | 2 ++
>  Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml   | 2 ++
>  Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++
>  Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++
>  Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml  | 2 ++
>  Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml  | 2 ++
>  Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml  | 2 ++
>  Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml| 2 ++
>  .../devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 2 ++
>  .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml| 2 ++
>  .../devicetree/bindings/iio/chemical/plantower,pms7003.yaml| 2 ++
>  .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml  |

Re: [PATCH 3/4] dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false'

[Jonathan Cameron]

On Wed, 25 Mar 2020 16:05:40 -0600
Rob Herring  wrote:

> Numerous schemas are missing 'additionalProperties: false' statements which
> ensures a binding doesn't have any extra undocumented properties or child
> nodes. Fixing this reveals various missing properties, so let's fix all
> those occurrences.
> 
> Cc: Stephen Boyd 
> Cc: Linus Walleij 
> Cc: Bartosz Golaszewski 
> Cc: Masahiro Yamada 
> Cc: Jonathan Cameron 
> Cc: Hartmut Knaack 
> Cc: Lars-Peter Clausen 
> Cc: Peter Meerwald-Stadler 
> Cc: Neil Armstrong 
> Cc: Mauro Carvalho Chehab 
> Cc: Kevin Hilman 
> Cc: Lee Jones 
> Cc: "David S. Miller" 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Cc: Guillaume La Roque 
> Cc: Zhang Rui 
> Cc: Daniel Lezcano 
> Cc: Thomas Gleixner 
> Cc: linux-...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: net...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Signed-off-by: Rob Herring 
Acked-by: Jonathan Cameron  #for-iio

> ---
>  .../devicetree/bindings/clock/fsl,plldig.yaml |  3 +++
>  .../gpio/socionext,uniphier-gpio.yaml |  2 ++
>  .../bindings/gpu/arm,mali-bifrost.yaml|  6 ++---
>  .../bindings/gpu/arm,mali-midgard.yaml|  3 +++
>  .../bindings/iio/adc/adi,ad7192.yaml  |  1 -
>  .../bindings/iio/pressure/bmp085.yaml |  3 +++
>  .../media/amlogic,meson-gx-ao-cec.yaml|  9 +---
>  .../bindings/mfd/rohm,bd71828-pmic.yaml   |  3 +++
>  .../bindings/net/ti,cpsw-switch.yaml  | 23 ---
>  .../regulator/max77650-regulator.yaml |  2 +-
>  .../bindings/thermal/amlogic,thermal.yaml |  2 ++
>  .../bindings/timer/arm,arch_timer_mmio.yaml   |  2 ++
>  12 files changed, 43 insertions(+), 16 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml 
> b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
> index c8350030b374..d1c040228cf7 100644
> --- a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
> +++ b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml
> @@ -21,6 +21,9 @@ properties:
>reg:
>  maxItems: 1
>  
> +  clocks:
> +maxItems: 1
> +
>'#clock-cells':
>  const: 0
>  
> diff --git 
> a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml 
> b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
> index 580a39e09d39..c58ff9a94f45 100644
> --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml
> @@ -41,6 +41,8 @@ properties:
>  minimum: 0
>  maximum: 512
>  
> +  gpio-ranges: true
> +
>gpio-ranges-group-names:
>  $ref: /schemas/types.yaml#/definitions/string-array
>  
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml 
> b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> index e8b99adcb1bd..05fd9a404ff7 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
> @@ -43,6 +43,9 @@ properties:
>  
>operating-points-v2: true
>  
> +  resets:
> +maxItems: 2
> +
>  required:
>- compatible
>- reg
> @@ -57,9 +60,6 @@ allOf:
>contains:
>  const: amlogic,meson-g12a-mali
>  then:
> -  properties:
> -resets:
> -  minItems: 2
>required:
>  - resets
>  
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml 
> b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
> index 8d966f3ff3db..6819cde050df 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
> @@ -75,6 +75,9 @@ properties:
>  
>mali-supply: true
>  
> +  power-domains:
> +maxItems: 1
> +
>resets:
>  minItems: 1
>  maxItems: 2
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml 
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
> index 84d25bd39488..d0913034b1d8 100644
> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml
> @@ -106,7 +106,6 @@ examples:
>  spi-cpha;
>  clocks = <_mclk>;
>  clock-names = "mclk";
> -#interrupt-cells = <2>;
>  interrupts = <25 0x2>;
>  interrupt-pare

Re: [PATCH 1/4] dt-bindings: iio/accel: Drop duplicate adi, adxl345/6 from trivial-devices.yaml

[Jonathan Cameron]

On Thu, 26 Mar 2020 07:57:31 +
"Ardelean, Alexandru"  wrote:

> On Wed, 2020-03-25 at 16:05 -0600, Rob Herring wrote:
> > [External]
> > 
> > The 'adi,adxl345' definition is a duplicate as there's a full binding in:
> > Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> > 
> > The trivial-devices binding doesn't capture that 'adi,adxl346' has a
> > fallback compatible 'adi,adxl345', so let's add it to adi,adxl345.yaml.
> >   
> 
> Acked-by: Alexandru Ardelean 

Acked-by: Jonathan Cameron 

> 
> > Cc: Michael Hennerich 
> > Cc: Jonathan Cameron 
> > Cc: Hartmut Knaack 
> > Cc: Lars-Peter Clausen 
> > Cc: Peter Meerwald-Stadler 
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Rob Herring 
> > ---
> >  .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 10 +++---
> >  Documentation/devicetree/bindings/trivial-devices.yaml |  4 
> >  2 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> > b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> > index c602b6fe1c0c..d124eba1ce54 100644
> > --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> > +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
> > @@ -17,9 +17,13 @@ description: |
> >  
> >  properties:
> >compatible:
> > -enum:
> > -  - adi,adxl345
> > -  - adi,adxl375
> > +oneOf:
> > +  - items:
> > +  - const: adi,adxl346
> > +  - const: adi,adxl345
> > +  - enum:
> > +  - adi,adxl345
> > +  - adi,adxl375
> >  
> >reg:
> >  maxItems: 1
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml
> > b/Documentation/devicetree/bindings/trivial-devices.yaml
> > index 978de7d37c66..51d1f6e43c02 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> > @@ -42,10 +42,6 @@ properties:
> >- adi,adt7476
> >  # +/-1C TDM Extended Temp Range I.C
> >- adi,adt7490
> > -# Three-Axis Digital Accelerometer
> > -  - adi,adxl345
> > -# Three-Axis Digital Accelerometer (backward-compatibility 
> > value
> > "adi,adxl345" must be listed too)
> > -  - adi,adxl346
> >  # AMS iAQ-Core VOC Sensor
> >- ams,iaq-core
> >  # i2c serial eeprom  (24cxx)  
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg

[Jonathan Cameron]

On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann  wrote:

> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
> 
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
> 
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
> 
> Signed-off-by: Arnd Bergmann 
> ---

For IIO part.

Acked-by: Jonathan Cameron 

Thanks,
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..22844b94b0e9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1630,7 +1630,7 @@ static const struct file_operations iio_buffer_fileops 
> = {
>   .owner = THIS_MODULE,
>   .llseek = noop_llseek,
>   .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
>  };
>  

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v5 2/6] i2c: add helpers to ease DMA handling

[Jonathan Cameron]

On Thu, 21 Sep 2017 16:15:28 +0200
Wolfram Sang  wrote:

> > > > +/**
> > > > + * i2c_release_dma_safe_msg_buf - release DMA safe buffer and sync 
> > > > with i2c_msg
> > > > + * @msg: the message to be synced with
> > > > + * @buf: the buffer obtained from i2c_get_dma_safe_msg_buf(). May be 
> > > > NULL.
> > > > + */
> > > > +void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf)
> > > > +{
> > > > +   if (!buf || buf == msg->buf)
> > > > +   return;
> > > > +
> > > > +   if (msg->flags & I2C_M_RD)
> > > > +   memcpy(msg->buf, buf, msg->len);
> > > > +
> > > > +   kfree(buf);  
> > 
> > Only free when you actually allocated it.  Seems to me like you need
> > to check if (!(msg->flags & I2C_M_DMA_SAFE)) before kfree.
> > 
> > Otherwise the logic to do this will be needed in every driver
> > which will get irritating fast.  
> 
> Well, I return early if (buf == msg->buf) which is only true for
> I2C_M_DMA_SAFE. If not, I allocated the buffer. Am I missing something?
> It would be very strange to call this function if the caller allocated
> the buffer manually.
> 
> Thanks for the review!

Doh missed that check and my comment was bonkers even if it hadn't been there.
I come back to the claim of insufficient caffeine.

You are quite correct.  Please ignore previous comment - the code is
fine as is. 

Jonathan
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v5 6/6] i2c: dev: mark RDWR buffers as DMA_SAFE

[Jonathan Cameron]

On Wed, 20 Sep 2017 20:59:56 +0200
Wolfram Sang <wsa+rene...@sang-engineering.com> wrote:

> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>

Makes sense as do the other drivers.

Feel free to add

Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>

to all of them (though they hardly took a lot of reviewing given how simple
the patches were :)

> ---
>  drivers/i2c/i2c-dev.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
> index 6f638bbc922db4..bbc7aadb4c899d 100644
> --- a/drivers/i2c/i2c-dev.c
> +++ b/drivers/i2c/i2c-dev.c
> @@ -280,6 +280,8 @@ static noinline int i2cdev_ioctl_rdwr(struct i2c_client 
> *client,
>   res = PTR_ERR(rdwr_pa[i].buf);
>   break;
>   }
> + /* memdup_user allocates with GFP_KERNEL, so DMA is ok */
> + rdwr_pa[i].flags |= I2C_M_DMA_SAFE;
>  
>   /*
>* If the message length is received from the slave (similar

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v5 2/6] i2c: add helpers to ease DMA handling

[Jonathan Cameron]

On Wed, 20 Sep 2017 20:59:52 +0200
Wolfram Sang <wsa+rene...@sang-engineering.com> wrote:

> One helper checks if DMA is suitable and optionally creates a bounce
> buffer, if not. The other function returns the bounce buffer and makes
> sure the data is properly copied back to the message.
> 
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>

One minor suggestion for wording. Otherwise looks good to me.

Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>

> ---
>  drivers/i2c/i2c-core-base.c | 45 
> +
>  include/linux/i2c.h |  3 +++
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 56e46581b84bdb..925a22794d3ced 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -2241,6 +2241,51 @@ void i2c_put_adapter(struct i2c_adapter *adap)
>  }
>  EXPORT_SYMBOL(i2c_put_adapter);
>  
> +/**
> + * i2c_get_dma_safe_msg_buf() - get a DMA safe buffer for the given i2c_msg
> + * @msg: the message to be checked
> + * @threshold: the amount of byte from which using DMA makes sense

the minimum number of bytes for which using DMA makes sense.

> + *
> + * Return: NULL if a DMA safe buffer was not obtained. Use msg->buf with PIO.
> + *
> + *  Or a valid pointer to be used with DMA. Note that it can either be
> + *  msg->buf or a bounce buffer. After use, release it by calling
> + *  i2c_release_dma_safe_msg_buf().
> + *
> + * This function must only be called from process context!
> + */
> +u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold)
> +{
> + if (msg->len < threshold)
> + return NULL;
> +
> + if (msg->flags & I2C_M_DMA_SAFE)
> + return msg->buf;
> +
> + if (msg->flags & I2C_M_RD)
> + return kzalloc(msg->len, GFP_KERNEL);
> + else
> + return kmemdup(msg->buf, msg->len, GFP_KERNEL);
> +}
> +EXPORT_SYMBOL_GPL(i2c_get_dma_safe_msg_buf);
> +
> +/**
> + * i2c_release_dma_safe_msg_buf - release DMA safe buffer and sync with 
> i2c_msg
> + * @msg: the message to be synced with
> + * @buf: the buffer obtained from i2c_get_dma_safe_msg_buf(). May be NULL.
> + */
> +void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf)
> +{
> + if (!buf || buf == msg->buf)
> + return;
> +
> + if (msg->flags & I2C_M_RD)
> + memcpy(msg->buf, buf, msg->len);
> +
> + kfree(buf);
> +}
> +EXPORT_SYMBOL_GPL(i2c_release_dma_safe_msg_buf);
> +
>  MODULE_AUTHOR("Simon G. Vogl <si...@tk.uni-linz.ac.at>");
>  MODULE_DESCRIPTION("I2C-Bus main module");
>  MODULE_LICENSE("GPL");
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index d501d3956f13f0..1e99342f180f45 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -767,6 +767,9 @@ static inline u8 i2c_8bit_addr_from_msg(const struct 
> i2c_msg *msg)
>   return (msg->addr << 1) | (msg->flags & I2C_M_RD ? 1 : 0);
>  }
>  
> +u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold);
> +void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf);
> +
>  int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short 
> addr);
>  /**
>   * module_i2c_driver() - Helper macro for registering a modular I2C driver

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v5 3/6] i2c: add docs to clarify DMA handling

[Jonathan Cameron]

On Wed, 20 Sep 2017 16:56:48 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> Em Wed, 20 Sep 2017 20:59:53 +0200
> Wolfram Sang <wsa+rene...@sang-engineering.com> escreveu:
> 
> > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>  
> 
> Documentation looks OK on my eyes. So:
> 
> Reviewed-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Really minor suggestion inline. I don't really care either way as
what you had is perfectly comprehensible. 

Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>

> 
> > ---
> >  Documentation/i2c/DMA-considerations | 58 
> > 
> >  1 file changed, 58 insertions(+)
> >  create mode 100644 Documentation/i2c/DMA-considerations
> > 
> > diff --git a/Documentation/i2c/DMA-considerations 
> > b/Documentation/i2c/DMA-considerations
> > new file mode 100644
> > index 00..5a63355c6a9b6f
> > --- /dev/null
> > +++ b/Documentation/i2c/DMA-considerations
> > @@ -0,0 +1,58 @@
> > +=
> > +Linux I2C and DMA
> > +=
> > +
> > +Given that I2C is a low-speed bus where largely small messages are 
> > transferred,

Slightly nicer as:

Given that i2c is a low-speed bus, over which the majority of messages 
transferred are small,

> > +it is not considered a prime user of DMA access. At this time of writing, 
> > only
> > +10% of I2C bus master drivers have DMA support implemented. And the vast
> > +majority of transactions are so small that setting up DMA for it will 
> > likely
> > +add more overhead than a plain PIO transfer.
> > +
> > +Therefore, it is *not* mandatory that the buffer of an I2C message is DMA 
> > safe.
> > +It does not seem reasonable to apply additional burdens when the feature 
> > is so
> > +rarely used. However, it is recommended to use a DMA-safe buffer if your
> > +message size is likely applicable for DMA. Most drivers have this threshold
> > +around 8 bytes (as of today, this is mostly an educated guess, however). 
> > For
> > +any message of 16 byte or larger, it is probably a really good idea. Please
> > +note that other subsystems you use might add requirements. E.g., if your
> > +I2C bus master driver is using USB as a bridge, then you need to have DMA
> > +safe buffers always, because USB requires it.
> > +
> > +For clients, if you use a DMA safe buffer in i2c_msg, set the 
> > I2C_M_DMA_SAFE
> > +flag with it. Then, the I2C core and drivers know they can safely operate 
> > DMA
> > +on it. Note that using this flag is optional. I2C host drivers which are 
> > not
> > +updated to use this flag will work like before. And like before, they risk
> > +using an unsafe DMA buffer. To improve this situation, using 
> > I2C_M_DMA_SAFE in
> > +more and more clients and host drivers is the planned way forward. Note 
> > also
> > +that setting this flag makes only sense in kernel space. User space data is
> > +copied into kernel space anyhow. The I2C core makes sure the destination
> > +buffers in kernel space are always DMA capable.
> > +
> > +FIXME: Need to implement i2c_master_{send|receive}_dma and proper buffers 
> > for i2c_smbus_xfer_emulated.
> > +
> > +Drivers wishing to implement safe DMA can use helper functions from the I2C
> > +core. One gives you a DMA-safe buffer for a given i2c_msg as long as a 
> > certain
> > +threshold is met::
> > +
> > +   dma_buf = i2c_get_dma_safe_msg_buf(msg, threshold_in_byte);
> > +
> > +If a buffer is returned, it is either msg->buf for the I2C_M_DMA_SAFE case 
> > or a
> > +bounce buffer. But you don't need to care about that detail, just use the
> > +returned buffer. If NULL is returned, the threshold was not met or a bounce
> > +buffer could not be allocated. Fall back to PIO in that case.
> > +
> > +In any case, a buffer obtained from above needs to be released. It ensures 
> > data
> > +is copied back to the message and a potentially used bounce buffer is 
> > freed::
> > +
> > +   i2c_release_dma_safe_msg_buf(msg, dma_buf);
> > +
> > +The bounce buffer handling from the core is generic and simple. It will 
> > always
> > +allocate a new bounce buffer. If you want a more sophisticated handling 
> > (e.g.
> > +reusing pre-allocated buffers), you are free to implement your own.
> > +
> > +Please also check the in-kernel documentation for details. The 
> > i2c-sh_mobile
> > +driver can be used as a reference example how to use the a

Re: [RFC PATCH v5 2/6] i2c: add helpers to ease DMA handling

[Jonathan Cameron]

On Thu, 21 Sep 2017 14:59:22 +0100
Jonathan Cameron <jonathan.came...@huawei.com> wrote:

> On Wed, 20 Sep 2017 20:59:52 +0200
> Wolfram Sang <wsa+rene...@sang-engineering.com> wrote:
> 
> > One helper checks if DMA is suitable and optionally creates a bounce
> > buffer, if not. The other function returns the bounce buffer and makes
> > sure the data is properly copied back to the message.
> > 
> > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>  
> 
> One minor suggestion for wording. Otherwise looks good to me.
> 
> Reviewed-by: Jonathan Cameron <jonathan.came...@huawei.com>
>

Need more coffee. See below.
 
> > ---
> >  drivers/i2c/i2c-core-base.c | 45 
> > +
> >  include/linux/i2c.h |  3 +++
> >  2 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> > index 56e46581b84bdb..925a22794d3ced 100644
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -2241,6 +2241,51 @@ void i2c_put_adapter(struct i2c_adapter *adap)
> >  }
> >  EXPORT_SYMBOL(i2c_put_adapter);
> >  
> > +/**
> > + * i2c_get_dma_safe_msg_buf() - get a DMA safe buffer for the given i2c_msg
> > + * @msg: the message to be checked
> > + * @threshold: the amount of byte from which using DMA makes sense  
> 
> the minimum number of bytes for which using DMA makes sense.
> 
> > + *
> > + * Return: NULL if a DMA safe buffer was not obtained. Use msg->buf with 
> > PIO.
> > + *
> > + *Or a valid pointer to be used with DMA. Note that it can either be
> > + *msg->buf or a bounce buffer. After use, release it by calling
> > + *i2c_release_dma_safe_msg_buf().
> > + *
> > + * This function must only be called from process context!
> > + */
> > +u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold)
> > +{
> > +   if (msg->len < threshold)
> > +   return NULL;
> > +
> > +   if (msg->flags & I2C_M_DMA_SAFE)
> > +   return msg->buf;
> > +
> > +   if (msg->flags & I2C_M_RD)
> > +   return kzalloc(msg->len, GFP_KERNEL);
> > +   else
> > +   return kmemdup(msg->buf, msg->len, GFP_KERNEL);
> > +}
> > +EXPORT_SYMBOL_GPL(i2c_get_dma_safe_msg_buf);
> > +
> > +/**
> > + * i2c_release_dma_safe_msg_buf - release DMA safe buffer and sync with 
> > i2c_msg
> > + * @msg: the message to be synced with
> > + * @buf: the buffer obtained from i2c_get_dma_safe_msg_buf(). May be NULL.
> > + */
> > +void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf)
> > +{
> > +   if (!buf || buf == msg->buf)
> > +   return;
> > +
> > +   if (msg->flags & I2C_M_RD)
> > +   memcpy(msg->buf, buf, msg->len);
> > +
> > +   kfree(buf);

Only free when you actually allocated it.  Seems to me like you need
to check if (!(msg->flags & I2C_M_DMA_SAFE)) before kfree.

Otherwise the logic to do this will be needed in every driver
which will get irritating fast.


> > +}
> > +EXPORT_SYMBOL_GPL(i2c_release_dma_safe_msg_buf);
> > +
> >  MODULE_AUTHOR("Simon G. Vogl <si...@tk.uni-linz.ac.at>");
> >  MODULE_DESCRIPTION("I2C-Bus main module");
> >  MODULE_LICENSE("GPL");
> > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > index d501d3956f13f0..1e99342f180f45 100644
> > --- a/include/linux/i2c.h
> > +++ b/include/linux/i2c.h
> > @@ -767,6 +767,9 @@ static inline u8 i2c_8bit_addr_from_msg(const struct 
> > i2c_msg *msg)
> > return (msg->addr << 1) | (msg->flags & I2C_M_RD ? 1 : 0);
> >  }
> >  
> > +u8 *i2c_get_dma_safe_msg_buf(struct i2c_msg *msg, unsigned int threshold);
> > +void i2c_release_dma_safe_msg_buf(struct i2c_msg *msg, u8 *buf);
> > +
> >  int i2c_handle_smbus_host_notify(struct i2c_adapter *adap, unsigned short 
> > addr);
> >  /**
> >   * module_i2c_driver() - Helper macro for registering a modular I2C driver 
> >  
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it

[Jonathan Cameron]

On Thu, 17 Aug 2017 16:14:43 +0200
Wolfram Sang  wrote:

> So, after revisiting old mail threads, taking part in a similar discussion on
> the USB list, and implementing a not-convincing solution before, here is what 
> I
> cooked up to document and ease DMA handling for I2C within Linux. Please have 
> a
> look at the documentation introduced in patch 3 for details.
> 
> While the previous versions tried to magically apply bounce buffers when
> needed, it became clear that detecting DMA safe buffers is too fragile. This
> approach is now opt-in, a DMA_SAFE flag needs to be set on an i2c_msg. The
> outcome so far is very convincing IMO. The core additions are simple and easy
> to understand (makes me even think of inlining them again?). The driver 
> changes
> for the Renesas IP cores became easier to understand, too. While only a tad 
> for
> the i2c-sh_mobile driver, the situation became a LOT better for the i2c-rcar
> driver. No more DMA disabling for the whole transfer in case of unsafe 
> buffers,
> we are back to per-msg handling. And the code fix is now an easy to understand
> one line change. Yay!
> 
> Of course, we must now whitelist DMA safe buffers. An example for I2C_RDWR 
> case
> is in this series. It makes the i2ctransfer utility have DMA_SAFE buffers,
> which is nice for testing as i2cdump will (currently) not use DMA_SAFE 
> buffers.
> My plan is to add two new calls: i2c_master_{send|receive}_dma_safe which can
> be used if DMA_SAFE buffers are provided. So, drivers can simply switch to
> them. Also, the buffers used within i2c_smbus_xfer_emulated() need to be
> converted to be DMA_SAFE which will cover a huge bunch of use cases. The rest
> is then updating drivers which can be done when needed.
> 
> As these conversions are not done yet, this patch series has RFC status. But I
> already would like to get opinions on this approach, so I'll cc mailing lists
> of the heavier I2C users. Please let me know what you think.
> 
> All patches have been tested with a Renesas Salvator-X board (r8a7796/M3-W).
> 
> The branch can be found here:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
> renesas/topic/i2c-core-dma-rfc-v4
> 
> And big kudos to Renesas Electronics for funding this work, thank you very 
> much!

All looks good to me.  I should really set up some testing for this to see if it
gains us much on the various platforms I use, but that will 'a while' so don't 
wait
on me!  This is particularly true as none of them have dma support in the master
drivers yet.

Thanks for you work on this and cool than Renesas are funding it!

Jonathan

> 
> Regards,
> 
>Wolfram
> 
> Changes since v3:
>   * completely redesigned
> 
> Wolfram Sang (6):
>   i2c: add a message flag for DMA safe buffers
>   i2c: add helpers to ease DMA handling
>   i2c: add docs to clarify DMA handling
>   i2c: sh_mobile: use helper to decide if DMA is useful
>   i2c: rcar: skip DMA if buffer is not safe
>   i2c: dev: mark RDWR buffers as DMA_SAFE
> 
>  Documentation/i2c/DMA-considerations | 50 
> 
>  drivers/i2c/busses/i2c-rcar.c|  2 +-
>  drivers/i2c/busses/i2c-sh_mobile.c   |  8 --
>  drivers/i2c/i2c-core-base.c  | 45 
>  drivers/i2c/i2c-dev.c|  2 ++
>  include/linux/i2c.h  |  3 +++
>  include/uapi/linux/i2c.h |  3 +++
>  7 files changed, 110 insertions(+), 3 deletions(-)
>  create mode 100644 Documentation/i2c/DMA-considerations
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/8] ida: Simplified functions for id allocation.

[Jonathan Cameron]

From: Rusty Russell <ru...@rustcorp.com.au>

The current hyper-optimized functions are overkill if you simply want
to allocate an id for a device.  Create versions which use an internal
lock.

Thanks to Tejun for feedback.

Signed-off-by: Rusty Russell 
Acked-by: Tejun Heo 
Acked-by: Jonathan Cameron 
---
 include/linux/idr.h |4 +++
 lib/idr.c   |   67 +++
 2 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index 13a801f..255491c 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -146,6 +146,10 @@ void ida_remove(struct ida *ida, int id);
 void ida_destroy(struct ida *ida);
 void ida_init(struct ida *ida);

+int ida_simple_get(struct ida *ida, unsigned int start, unsigned int end,
+  gfp_t gfp_mask);
+void ida_simple_remove(struct ida *ida, unsigned int id);
+
 void __init idr_init_cache(void);

 #endif /* __IDR_H__ */
diff --git a/lib/idr.c b/lib/idr.c
index e15502e..db040ce 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -34,8 +34,10 @@
 #include 
 #include 
 #include 
+#include 

 static struct kmem_cache *idr_layer_cache;
+static DEFINE_SPINLOCK(simple_ida_lock);

 static struct idr_layer *get_from_free_list(struct idr *idp)
 {
@@ -926,6 +928,71 @@ void ida_destroy(struct ida *ida)
 EXPORT_SYMBOL(ida_destroy);

 /**
+ * ida_simple_get - get a new id.
+ * @ida: the (initialized) ida.
+ * @start: the minimum id (inclusive, < 0x800)
+ * @end: the maximum id (exclusive, < 0x800 or 0)
+ * @gfp_mask: memory allocation flags
+ *
+ * Allocates an id in the range start <= id < end, or returns -ENOSPC.
+ * On memory allocation failure, returns -ENOMEM.
+ *
+ * Use ida_simple_remove() to get rid of an id.
+ */
+int ida_simple_get(struct ida *ida, unsigned int start, unsigned int end,
+  gfp_t gfp_mask)
+{
+   int ret, id;
+   unsigned int max;
+
+   BUG_ON((int)start < 0);
+   BUG_ON((int)end < 0);
+
+   if (end == 0)
+   max = 0x8000;
+   else {
+   BUG_ON(end < start);
+   max = end - 1;
+   }
+
+again:
+   if (!ida_pre_get(ida, gfp_mask))
+   return -ENOMEM;
+
+   spin_lock(_ida_lock);
+   ret = ida_get_new_above(ida, start, );
+   if (!ret) {
+   if (id > max) {
+   ida_remove(ida, id);
+   ret = -ENOSPC;
+   } else {
+   ret = id;
+   }
+   }
+   spin_unlock(_ida_lock);
+
+   if (unlikely(ret == -EAGAIN))
+   goto again;
+
+   return ret;
+}
+EXPORT_SYMBOL(ida_simple_get);
+
+/**
+ * ida_simple_remove - remove an allocated id.
+ * @ida: the (initialized) ida.
+ * @id: the id returned by ida_simple_get.
+ */
+void ida_simple_remove(struct ida *ida, unsigned int id)
+{
+   BUG_ON((int)id < 0);
+   spin_lock(_ida_lock);
+   ida_remove(ida, id);
+   spin_unlock(_ida_lock);
+}
+EXPORT_SYMBOL(ida_simple_remove);
+
+/**
  * ida_init - initialize ida handle
  * @ida:   ida handle
  *
-- 
1.7.3.4

[PATCH 0/8] RFC: Introduce ida_simple interfaces and use them.

[Jonathan Cameron]

Hi All,

Firstly sorry for the huge cc list, but this series does get about.

This series came out of two separate lkml threads:

https://lkml.org/lkml/2011/7/13/64
http://thread.gmane.org/gmane.linux.kernel/1148513/focus=74236

Basically Rusty and I both got annoyed with yet more instances
of the same cut and past ida allocation code for the very simple
case of wanting a unique id for some device. Tejun helpfully
joined the two threads up.

Anyhow, Rusty proposed more or less the first patch here (with a name
change requested by Tejun applied.)

The others patches are some of the more obvious looking cases for
applying this code.  My original reason was for IIO but those patches will
have to wait a little while for some prior changes to merge.
For reference, it saves about 40 lines there so I'm happy ;)

There are a number of other cases in tree that can be cleaned up
in a second series once these are sorted.

There are a couple of cases in here where I've carefully mangled
the error codes to keep consistent with the existing code.  Please
can people who know those subsystems well decide on whether the
mangling is necessary.

All comments welcome. I expect I've broken at least one driver
doing this so please take a close look.

Rusty, Tejun. I kept your sign of an ack for the first patch. Could
you quickly verify that's fine?

Thanks,

Jonathan

Jonathan Cameron (7):
  hwmon: convert idr to ida and use ida_simple interface.
  hwmon: ibmaem: convert idr to ida and use ida_simple_get
  [SCSI] use ida_simple_get and ida_simple remove in place of
boilerplate code.
  drm/vmwgfx: use ida_simple_get for id allocation.
  [SCSI] osduld: use ida_simple_get to handle id.
  w1: ds2760 and ds2780, use ida for id and ida_simple_get to get it.
  rtc: class idr converted to ida and ida_simple_get used.

Rusty Russell (1):
  ida: Simplified functions for id allocation.

 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |   34 +++--
 drivers/hwmon/hwmon.c |   32 +++-
 drivers/hwmon/ibmaem.c|   47 +++--
 drivers/rtc/class.c   |   32 +++-
 drivers/scsi/osd/osd_uld.c|   22 +++-
 drivers/scsi/sd.c |   32 
 drivers/w1/slaves/w1_ds2760.c |   48 ++---
 drivers/w1/slaves/w1_ds2780.c |   48 ++---
 include/linux/idr.h   |4 ++
 lib/idr.c |   67 +
 10 files changed, 134 insertions(+), 232 deletions(-)

-- 
1.7.3.4

[PATCH 5/8] drm/vmwgfx: use ida_simple_get for id allocation.

[Jonathan Cameron]

Some messing with error codes to return 0 on out id's and match
current situation.  Is this necessary? Looks a touch 'interesting'.

Signed-off-by: Jonathan Cameron 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |   34 ++---
 1 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index ac6e0d1..d51577b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -37,7 +37,6 @@
 #include 

 struct vmwgfx_gmrid_man {
-   spinlock_t lock;
struct ida gmr_ida;
uint32_t max_gmr_ids;
 };
@@ -49,34 +48,20 @@ static int vmw_gmrid_man_get_node(struct 
ttm_mem_type_manager *man,
 {
struct vmwgfx_gmrid_man *gman =
(struct vmwgfx_gmrid_man *)man->priv;
-   int ret;
int id;

mem->mm_node = NULL;

-   do {
-   if (unlikely(ida_pre_get(>gmr_ida, GFP_KERNEL) == 0))
-   return -ENOMEM;
-
-   spin_lock(>lock);
-   ret = ida_get_new(>gmr_ida, );
-
-   if (unlikely(ret == 0 && id >= gman->max_gmr_ids)) {
-   ida_remove(>gmr_ida, id);
-   spin_unlock(>lock);
+   id = ida_simple_get(>gmr_ida, 0, gman->max_gmr_ids, GFP_KERNEL);
+   if (id < 0) {
+   if (id == -ENOSPC)
return 0;
-   }
-
-   spin_unlock(>lock);
-
-   } while (ret == -EAGAIN);
-
-   if (likely(ret == 0)) {
-   mem->mm_node = gman;
-   mem->start = id;
+   return id;
}
+   mem->mm_node = gman;
+   mem->start = id;

-   return ret;
+   return 0;
 }

 static void vmw_gmrid_man_put_node(struct ttm_mem_type_manager *man,
@@ -86,9 +71,7 @@ static void vmw_gmrid_man_put_node(struct 
ttm_mem_type_manager *man,
(struct vmwgfx_gmrid_man *)man->priv;

if (mem->mm_node) {
-   spin_lock(>lock);
-   ida_remove(>gmr_ida, mem->start);
-   spin_unlock(>lock);
+   ida_simple_remove(>gmr_ida, mem->start);
mem->mm_node = NULL;
}
 }
@@ -102,7 +85,6 @@ static int vmw_gmrid_man_init(struct ttm_mem_type_manager 
*man,
if (unlikely(gman == NULL))
return -ENOMEM;

-   spin_lock_init(>lock);
ida_init(>gmr_ida);
gman->max_gmr_ids = p_size;
man->priv = (void *) gman;
-- 
1.7.3.4

[PATCH 5/8] drm/vmwgfx: use ida_simple_get for id allocation.

[Jonathan Cameron]

Some messing with error codes to return 0 on out id's and match
current situation.  Is this necessary? Looks a touch 'interesting'.

Signed-off-by: Jonathan Cameron ji...@cam.ac.uk
---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |   34 ++---
 1 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index ac6e0d1..d51577b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -37,7 +37,6 @@
 #include linux/kernel.h
 
 struct vmwgfx_gmrid_man {
-   spinlock_t lock;
struct ida gmr_ida;
uint32_t max_gmr_ids;
 };
@@ -49,34 +48,20 @@ static int vmw_gmrid_man_get_node(struct 
ttm_mem_type_manager *man,
 {
struct vmwgfx_gmrid_man *gman =
(struct vmwgfx_gmrid_man *)man-priv;
-   int ret;
int id;
 
mem-mm_node = NULL;
 
-   do {
-   if (unlikely(ida_pre_get(gman-gmr_ida, GFP_KERNEL) == 0))
-   return -ENOMEM;
-
-   spin_lock(gman-lock);
-   ret = ida_get_new(gman-gmr_ida, id);
-
-   if (unlikely(ret == 0  id = gman-max_gmr_ids)) {
-   ida_remove(gman-gmr_ida, id);
-   spin_unlock(gman-lock);
+   id = ida_simple_get(gman-gmr_ida, 0, gman-max_gmr_ids, GFP_KERNEL);
+   if (id  0) {
+   if (id == -ENOSPC)
return 0;
-   }
-
-   spin_unlock(gman-lock);
-
-   } while (ret == -EAGAIN);
-
-   if (likely(ret == 0)) {
-   mem-mm_node = gman;
-   mem-start = id;
+   return id;
}
+   mem-mm_node = gman;
+   mem-start = id;
 
-   return ret;
+   return 0;
 }
 
 static void vmw_gmrid_man_put_node(struct ttm_mem_type_manager *man,
@@ -86,9 +71,7 @@ static void vmw_gmrid_man_put_node(struct 
ttm_mem_type_manager *man,
(struct vmwgfx_gmrid_man *)man-priv;
 
if (mem-mm_node) {
-   spin_lock(gman-lock);
-   ida_remove(gman-gmr_ida, mem-start);
-   spin_unlock(gman-lock);
+   ida_simple_remove(gman-gmr_ida, mem-start);
mem-mm_node = NULL;
}
 }
@@ -102,7 +85,6 @@ static int vmw_gmrid_man_init(struct ttm_mem_type_manager 
*man,
if (unlikely(gman == NULL))
return -ENOMEM;
 
-   spin_lock_init(gman-lock);
ida_init(gman-gmr_ida);
gman-max_gmr_ids = p_size;
man-priv = (void *) gman;
-- 
1.7.3.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel