[v11,3/7] iio: core: Add new DMABUF interface infrastructure
Commit Message
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.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Co-developed-by: Nuno Sa <nuno.sa@analog.com>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
---
v2: Only allow the new IOCTLs on the buffer FD created with
IIO_BUFFER_GET_FD_IOCTL().
v3: - Get rid of the old IOCTLs. The IIO subsystem does not create or
manage DMABUFs anymore, and only attaches/detaches externally
created DMABUFs.
- Add IIO_BUFFER_DMABUF_CYCLIC to the supported flags.
v5: - Use dev_err() instead of pr_err()
- Inline to_iio_dma_fence()
- Add comment to explain why we unref twice when detaching dmabuf
- Remove TODO comment. It is actually safe to free the file's
private data even when transfers are still pending because it
won't be accessed.
- Fix documentation of new fields in struct iio_buffer_access_funcs
- iio_dma_resv_lock() does not need to be exported, make it static
v6: - Remove dead code in iio_dma_resv_lock()
- Fix non-block actually blocking
- Cache dma_buf_attachment instead of mapping/unmapping it for every
transfer
- Return -EINVAL instead of IIO_IOCTL_UNHANDLED for unknown ioctl
- Make .block_enqueue() callback take a dma_fence pointer, which
will be passed to iio_buffer_signal_dmabuf_done() instead of the
dma_buf_attachment; and remove the backpointer from the priv
structure to the dma_fence.
- Use dma_fence_begin/end_signalling in the dma_fence critical
sections
- Unref dma_fence and dma_buf_attachment in worker, because they
might try to lock the dma_resv, which would deadlock.
- Add buffer ops to lock/unlock the queue. This is motivated by the
fact that once the dma_fence has been installed, we cannot lock
anything anymore - so the queue must be locked before the
dma_fence is installed.
- Use 'long retl' variable to handle the return value of
dma_resv_wait_timeout()
- Protect dmabufs list access with a mutex
- Rework iio_buffer_find_attachment() to use the internal dmabufs
list, instead of messing with dmabufs private data.
- Add an atomically-increasing sequence number for fences
v8 - 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
v9: - 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
v11:
- Document .lock_queue / .unlock_queue buffer callbacks
- Add small comment to explain what the spinlock protects
- Use guard(mutex)
---
drivers/iio/Kconfig | 1 +
drivers/iio/industrialio-buffer.c | 457 ++++++++++++++++++++++++++++++
include/linux/iio/buffer_impl.h | 33 +++
include/uapi/linux/iio/buffer.h | 22 ++
4 files changed, 513 insertions(+)
Comments
Hi Paul,
kernel test robot noticed the following build errors:
[auto build test ERROR on jic23-iio/togreg]
[also build test ERROR on vkoul-dmaengine/next linus/master v6.10-rc4 next-20240618]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Paul-Cercueil/dmaengine-Add-API-function-dmaengine_prep_peripheral_dma_vec/20240618-180602
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link: https://lore.kernel.org/r/20240618100302.72886-4-paul%40crapouillou.net
patch subject: [PATCH v11 3/7] iio: core: Add new DMABUF interface infrastructure
config: x86_64-randconfig-161-20240619 (https://download.01.org/0day-ci/archive/20240619/202406191014.9JAzwRV6-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240619/202406191014.9JAzwRV6-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406191014.9JAzwRV6-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label
1715 | goto err_dmabuf_unmap_attachment;
| ^
drivers/iio/industrialio-buffer.c:1720:2: note: jump bypasses initialization of variable with __attribute__((cleanup))
1720 | guard(mutex)(&buffer->dmabufs_mutex);
| ^
include/linux/cleanup.h:164:15: note: expanded from macro 'guard'
164 | CLASS(_name, __UNIQUE_ID(guard))
| ^
include/linux/compiler.h:189:29: note: expanded from macro '__UNIQUE_ID'
189 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
| ^
include/linux/compiler_types.h:84:22: note: expanded from macro '__PASTE'
84 | #define __PASTE(a,b) ___PASTE(a,b)
| ^
include/linux/compiler_types.h:83:23: note: expanded from macro '___PASTE'
83 | #define ___PASTE(a,b) a##b
| ^
<scratch space>:126:1: note: expanded from here
126 | __UNIQUE_ID_guard696
| ^
drivers/iio/industrialio-buffer.c:1704:3: error: cannot jump from this goto statement to its label
1704 | goto err_resv_unlock;
| ^
drivers/iio/industrialio-buffer.c:1720:2: note: jump bypasses initialization of variable with __attribute__((cleanup))
1720 | guard(mutex)(&buffer->dmabufs_mutex);
| ^
include/linux/cleanup.h:164:15: note: expanded from macro 'guard'
164 | CLASS(_name, __UNIQUE_ID(guard))
| ^
include/linux/compiler.h:189:29: note: expanded from macro '__UNIQUE_ID'
189 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
| ^
include/linux/compiler_types.h:84:22: note: expanded from macro '__PASTE'
84 | #define __PASTE(a,b) ___PASTE(a,b)
| ^
include/linux/compiler_types.h:83:23: note: expanded from macro '___PASTE'
83 | #define ___PASTE(a,b) a##b
| ^
<scratch space>:126:1: note: expanded from here
126 | __UNIQUE_ID_guard696
| ^
drivers/iio/industrialio-buffer.c:1695:3: error: cannot jump from this goto statement to its label
1695 | goto err_dmabuf_detach;
| ^
drivers/iio/industrialio-buffer.c:1720:2: note: jump bypasses initialization of variable with __attribute__((cleanup))
1720 | guard(mutex)(&buffer->dmabufs_mutex);
| ^
include/linux/cleanup.h:164:15: note: expanded from macro 'guard'
164 | CLASS(_name, __UNIQUE_ID(guard))
| ^
include/linux/compiler.h:189:29: note: expanded from macro '__UNIQUE_ID'
189 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
| ^
include/linux/compiler_types.h:84:22: note: expanded from macro '__PASTE'
84 | #define __PASTE(a,b) ___PASTE(a,b)
| ^
include/linux/compiler_types.h:83:23: note: expanded from macro '___PASTE'
83 | #define ___PASTE(a,b) a##b
| ^
<scratch space>:126:1: note: expanded from here
126 | __UNIQUE_ID_guard696
| ^
drivers/iio/industrialio-buffer.c:1690:3: error: cannot jump from this goto statement to its label
1690 | goto err_dmabuf_put;
| ^
drivers/iio/industrialio-buffer.c:1720:2: note: jump bypasses initialization of variable with __attribute__((cleanup))
1720 | guard(mutex)(&buffer->dmabufs_mutex);
| ^
include/linux/cleanup.h:164:15: note: expanded from macro 'guard'
164 | CLASS(_name, __UNIQUE_ID(guard))
| ^
include/linux/compiler.h:189:29: note: expanded from macro '__UNIQUE_ID'
189 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
| ^
include/linux/compiler_types.h:84:22: note: expanded from macro '__PASTE'
84 | #define __PASTE(a,b) ___PASTE(a,b)
| ^
include/linux/compiler_types.h:83:23: note: expanded from macro '___PASTE'
83 | #define ___PASTE(a,b) a##b
| ^
<scratch space>:126:1: note: expanded from here
126 | __UNIQUE_ID_guard696
| ^
drivers/iio/industrialio-buffer.c:1684:3: error: cannot jump from this goto statement to its label
1684 | goto err_free_priv;
| ^
drivers/iio/industrialio-buffer.c:1720:2: note: jump bypasses initialization of variable with __attribute__((cleanup))
1720 | guard(mutex)(&buffer->dmabufs_mutex);
| ^
include/linux/cleanup.h:164:15: note: expanded from macro 'guard'
164 | CLASS(_name, __UNIQUE_ID(guard))
| ^
include/linux/compiler.h:189:29: note: expanded from macro '__UNIQUE_ID'
189 | #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
| ^
include/linux/compiler_types.h:84:22: note: expanded from macro '__PASTE'
84 | #define __PASTE(a,b) ___PASTE(a,b)
| ^
include/linux/compiler_types.h:83:23: note: expanded from macro '___PASTE'
83 | #define ___PASTE(a,b) a##b
vim +1715 drivers/iio/industrialio-buffer.c
1655
1656 static int iio_buffer_attach_dmabuf(struct iio_dev_buffer_pair *ib,
1657 int __user *user_fd, bool nonblock)
1658 {
1659 struct iio_dev *indio_dev = ib->indio_dev;
1660 struct iio_buffer *buffer = ib->buffer;
1661 struct dma_buf_attachment *attach;
1662 struct iio_dmabuf_priv *priv, *each;
1663 struct dma_buf *dmabuf;
1664 int err, fd;
1665
1666 if (!buffer->access->attach_dmabuf
1667 || !buffer->access->detach_dmabuf
1668 || !buffer->access->enqueue_dmabuf)
1669 return -EPERM;
1670
1671 if (copy_from_user(&fd, user_fd, sizeof(fd)))
1672 return -EFAULT;
1673
1674 priv = kzalloc(sizeof(*priv), GFP_KERNEL);
1675 if (!priv)
1676 return -ENOMEM;
1677
1678 spin_lock_init(&priv->lock);
1679 priv->context = dma_fence_context_alloc(1);
1680
1681 dmabuf = dma_buf_get(fd);
1682 if (IS_ERR(dmabuf)) {
1683 err = PTR_ERR(dmabuf);
1684 goto err_free_priv;
1685 }
1686
1687 attach = dma_buf_attach(dmabuf, indio_dev->dev.parent);
1688 if (IS_ERR(attach)) {
1689 err = PTR_ERR(attach);
1690 goto err_dmabuf_put;
1691 }
1692
1693 err = iio_dma_resv_lock(dmabuf, nonblock);
1694 if (err)
1695 goto err_dmabuf_detach;
1696
1697 priv->dir = buffer->direction == IIO_BUFFER_DIRECTION_IN
1698 ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
1699
1700 priv->sgt = dma_buf_map_attachment(attach, priv->dir);
1701 if (IS_ERR(priv->sgt)) {
1702 err = PTR_ERR(priv->sgt);
1703 dev_err(&indio_dev->dev, "Unable to map attachment: %d\n", err);
1704 goto err_resv_unlock;
1705 }
1706
1707 kref_init(&priv->ref);
1708 priv->buffer = buffer;
1709 priv->attach = attach;
1710 attach->importer_priv = priv;
1711
1712 priv->block = buffer->access->attach_dmabuf(buffer, attach);
1713 if (IS_ERR(priv->block)) {
1714 err = PTR_ERR(priv->block);
> 1715 goto err_dmabuf_unmap_attachment;
1716 }
1717
1718 dma_resv_unlock(dmabuf->resv);
1719
1720 guard(mutex)(&buffer->dmabufs_mutex);
1721
1722 /*
1723 * Check whether we already have an attachment for this driver/DMABUF
1724 * combo. If we do, refuse to attach.
1725 */
1726 list_for_each_entry(each, &buffer->dmabufs, entry) {
1727 if (each->attach->dev == indio_dev->dev.parent
1728 && each->attach->dmabuf == dmabuf) {
1729 /*
1730 * We unlocked the reservation object, so going through
1731 * the cleanup code would mean re-locking it first.
1732 * At this stage it is simpler to free the attachment
1733 * using iio_buffer_dma_put().
1734 */
1735 iio_buffer_dmabuf_put(attach);
1736 return -EBUSY;
1737 }
1738 }
1739
1740 /* Otherwise, add the new attachment to our dmabufs list. */
1741 list_add(&priv->entry, &buffer->dmabufs);
1742
1743 return 0;
1744
1745 err_dmabuf_unmap_attachment:
1746 dma_buf_unmap_attachment(attach, priv->sgt, priv->dir);
1747 err_resv_unlock:
1748 dma_resv_unlock(dmabuf->resv);
1749 err_dmabuf_detach:
1750 dma_buf_detach(dmabuf, attach);
1751 err_dmabuf_put:
1752 dma_buf_put(dmabuf);
1753 err_free_priv:
1754 kfree(priv);
1755
1756 return err;
1757 }
1758
On Wed, 2024-06-19 at 11:15 +0800, kernel test robot wrote:
> Hi Paul,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on jic23-iio/togreg]
> [also build test ERROR on vkoul-dmaengine/next linus/master v6.10-rc4 next-
> 20240618]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Paul-Cercueil/dmaengine-Add-API-function-dmaengine_prep_peripheral_dma_vec/20240618-180602
> base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
> patch link:
> https://lore.kernel.org/r/20240618100302.72886-4-paul%40crapouillou.net
> patch subject: [PATCH v11 3/7] iio: core: Add new DMABUF interface infrastructure
> config: x86_64-randconfig-161-20240619
> (https://download.01.org/0day-ci/archive/20240619/202406191014.9JAzwRV6-lkp@intel.c
> om/config)
> compiler: clang version 18.1.5
> (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20240619/202406191014.9JAzwRV6-lkp@intel.c
> om/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes:
> > https://lore.kernel.org/oe-kbuild-all/202406191014.9JAzwRV6-lkp@intel.com/
>
> All errors (new ones prefixed by >>):
>
> > > drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto
> > > statement to its label
> 1715 | goto err_dmabuf_unmap_attachment;
> | ^
> drivers/iio/industrialio-buffer.c:1720:2: note: jump bypasses initialization of
I guess the compiler produces code that will run the cleanup function on an
uninitialized variable. I would then go back to plain mutex() instead of moving
guard() to a place where it does not make sense only to shut up the warnings.
- Nuno Sá
…
> All errors (new ones prefixed by >>):
>
> >> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label
> 1715 | goto err_dmabuf_unmap_attachment;
…
Would you dare to transform the remaining goto chain into further applications
of scope-based resource management?
Regards,
Markus
Hi Markus,
Le mercredi 19 juin 2024 à 12:03 +0200, Markus Elfring a écrit :
> …
> > All errors (new ones prefixed by >>):
> >
> > > > drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump
> > > > from this goto statement to its label
> > 1715 | goto err_dmabuf_unmap_attachment;
> …
>
> Would you dare to transform the remaining goto chain into further
> applications
> of scope-based resource management?
We discussed this after v6 or v7, DRM/DMABUF maintainers were not keen
on doing that *just yet*.
Cheers,
-Paul
>> Would you dare to transform the remaining goto chain into further applications
>> of scope-based resource management?
>
> We discussed this after v6 or v7, DRM/DMABUF maintainers were not keen
> on doing that *just yet*.
* Would you like to add any links for corresponding development discussions?
* Will the desire grow for further collateral evolution according to
affected software components?
Regards,
Markus
Le mercredi 19 juin 2024 à 13:13 +0200, Markus Elfring a écrit :
> > > Would you dare to transform the remaining goto chain into further
> > > applications
> > > of scope-based resource management?
> >
> > We discussed this after v6 or v7, DRM/DMABUF maintainers were not
> > keen
> > on doing that *just yet*.
>
> * Would you like to add any links for corresponding development
> discussions?
https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com/T/#eefd360069c4261aec9621fafde30924706571c94
(and responses below)
It's more nuanced than I remembered. Christian was OK to add cleanup.h
support to the DMABUF code as long as the examples were updated as
well, but those aren't good candidates as they don't free up the
resources in all code paths.
>
> * Will the desire grow for further collateral evolution according to
> affected software components?
Not sure what you mean by that.
Cheers,
-Paul
…
> +++ b/drivers/iio/industrialio-buffer.c
…
> +static void iio_buffer_dmabuf_release(struct kref *ref)
> +{
…
> + dma_resv_lock(dmabuf->resv, NULL);
> + dma_buf_unmap_attachment(attach, priv->sgt, priv->dir);
> + dma_resv_unlock(dmabuf->resv);
…
Under which circumstances will another lock guard become applicable?
https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L179
Regards,
Markus
…
> https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com/T/#eefd360069c4261aec9621fafde30924706571c94
>
> (and responses below)
>
> It's more nuanced than I remembered.
…
>> * Will the desire grow for further collateral evolution according to
>> affected software components?
>
> Not sure what you mean by that.
Advanced programming interfaces were added a while ago.
Example:
https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L8
Corresponding attempts for increasing API usage need to adapt to remaining change reluctance,
don't they?
Regards,
Markus
Le mercredi 19 juin 2024 à 13:43 +0200, Markus Elfring a écrit :
> …
> > +++ b/drivers/iio/industrialio-buffer.c
> …
> > +static void iio_buffer_dmabuf_release(struct kref *ref)
> > +{
> …
> > + dma_resv_lock(dmabuf->resv, NULL);
> > + dma_buf_unmap_attachment(attach, priv->sgt, priv->dir);
> > + dma_resv_unlock(dmabuf->resv);
> …
>
> Under which circumstances will another lock guard become applicable?
> https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L179
As soon as "struct dma_resv" gets a DEFINE_GUARD().
-Paul
Le mercredi 19 juin 2024 à 13:56 +0200, Markus Elfring a écrit :
> …
> > https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com/T/#eefd360069c4261aec9621fafde30924706571c94
> >
> > (and responses below)
> >
> > It's more nuanced than I remembered.
> …
>
>
> > > * Will the desire grow for further collateral evolution according
> > > to
> > > affected software components?
> >
> > Not sure what you mean by that.
>
> Advanced programming interfaces were added a while ago.
>
> Example:
> https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L8
>
> Corresponding attempts for increasing API usage need to adapt to
> remaining change reluctance,
> don't they?
Sure, I guess.
But that does not change the fact that I cannot use cleanup.h magic in
this patchset, yet, as the required changes would have to be done in a
separate one.
Cheers,
-Paul
On Wed, 2024-06-19 at 14:21 +0200, Paul Cercueil wrote:
> Le mercredi 19 juin 2024 à 13:56 +0200, Markus Elfring a écrit :
> > …
> > > https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.camel@gmail.com/T/#eefd360069c4261aec9621fafde30924706571c94
> > >
> > > (and responses below)
> > >
> > > It's more nuanced than I remembered.
> > …
> >
> >
> > > > * Will the desire grow for further collateral evolution according
> > > > to
> > > > affected software components?
> > >
> > > Not sure what you mean by that.
> >
> > Advanced programming interfaces were added a while ago.
> >
> > Example:
> > https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L8
> >
> > Corresponding attempts for increasing API usage need to adapt to
> > remaining change reluctance,
> > don't they?
>
> Sure, I guess.
>
> But that does not change the fact that I cannot use cleanup.h magic in
> this patchset, yet, as the required changes would have to be done in a
> separate one.
>
>
Not to speak on the added churn in doing that now. This is already v11 and
complicated enough for us to add another dependency.
Moreover, yes, cleanup stuff is very nice but if some interface/API does not support
it, it's not up to the developer using that interface/API on some other patch series
to add support for it.
- Nuno Sá
>> …
>>> +++ b/drivers/iio/industrialio-buffer.c
>> …
>>> +static void iio_buffer_dmabuf_release(struct kref *ref)
>>> +{
>> …
>>> + dma_resv_lock(dmabuf->resv, NULL);
>>> + dma_buf_unmap_attachment(attach, priv->sgt, priv->dir);
>>> + dma_resv_unlock(dmabuf->resv);
>> …
>>
>> Under which circumstances will another lock guard become applicable?
>> https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/cleanup.h#L179
>
> As soon as "struct dma_resv" gets a DEFINE_GUARD().
Would any contributor like to add a macro call accordingly?
Regards,
Markus
…
> All errors (new ones prefixed by >>):
>
>>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label
> 1715 | goto err_dmabuf_unmap_attachment;
…
Which software design options would you like to try out next
so that such a questionable compilation error message will be avoided finally?
Regards,
Markus
On 20-06-24, 12:45, Markus Elfring wrote:
> …
> > All errors (new ones prefixed by >>):
> >
> >>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label
> > 1715 | goto err_dmabuf_unmap_attachment;
> …
>
> Which software design options would you like to try out next
> so that such a questionable compilation error message will be avoided finally?
The one where all emails from Markus go to dev/null
On Thu, 20 Jun 2024, Vinod Koul wrote:
> On 20-06-24, 12:45, Markus Elfring wrote:
> > …
> > > All errors (new ones prefixed by >>):
> > >
> > >>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label
> > > 1715 | goto err_dmabuf_unmap_attachment;
> > …
> >
> > Which software design options would you like to try out next
> > so that such a questionable compilation error message will be avoided finally?
>
> The one where all emails from Markus go to dev/null
Play nice please.
Documentation/process/code-of-conduct.rst
On 20-06-24, 18:05, Lee Jones wrote:
> On Thu, 20 Jun 2024, Vinod Koul wrote:
>
> > On 20-06-24, 12:45, Markus Elfring wrote:
> > > …
> > > > All errors (new ones prefixed by >>):
> > > >
> > > >>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from this goto statement to its label
> > > > 1715 | goto err_dmabuf_unmap_attachment;
> > > …
> > >
> > > Which software design options would you like to try out next
> > > so that such a questionable compilation error message will be avoided finally?
> >
> > The one where all emails from Markus go to dev/null
>
> Play nice please.
Would love to... but Markus has been repeat offender
Sadly, I am yet to see a constructive approach or even better a helpful
patch which improve something, rather than vague suggestions on the list
On Fri, 2024-06-21 at 12:39 +0530, Vinod Koul wrote:
> On 20-06-24, 18:05, Lee Jones wrote:
> > On Thu, 20 Jun 2024, Vinod Koul wrote:
> >
> > > On 20-06-24, 12:45, Markus Elfring wrote:
> > > > …
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > > > > drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from
> > > > > > > this goto statement to its label
> > > > > 1715 | goto err_dmabuf_unmap_attachment;
> > > > …
> > > >
> > > > Which software design options would you like to try out next
> > > > so that such a questionable compilation error message will be avoided
> > > > finally?
> > >
> > > The one where all emails from Markus go to dev/null
> >
> > Play nice please.
>
> Would love to... but Markus has been repeat offender
>
> Sadly, I am yet to see a constructive approach or even better a helpful
> patch which improve something, rather than vague suggestions on the list
>
Yeah, just look at how many automatic replies he get's from Greg pretty much
saying to ignore his comments.
- Nuno Sá
> Sadly, I am yet to see a constructive approach or even better a helpful
> patch which improve something, rather than vague suggestions on the list
Can you get any more constructive impressions from another data representation?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Elfring
Are you aware how many change suggestions (also from my selection) are still
in various waiting queues?
Regards,
Markus
> Yeah, just look at how many automatic replies he get's from Greg pretty much
> saying to ignore his comments.
Does your feedback just indicate recurring communication difficulties?
Regards,
Markus
On Fri, 21 Jun 2024, Nuno Sá wrote:
> On Fri, 2024-06-21 at 12:39 +0530, Vinod Koul wrote:
> > On 20-06-24, 18:05, Lee Jones wrote:
> > > On Thu, 20 Jun 2024, Vinod Koul wrote:
> > >
> > > > On 20-06-24, 12:45, Markus Elfring wrote:
> > > > > …
> > > > > > All errors (new ones prefixed by >>):
> > > > > >
> > > > > > > > drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from
> > > > > > > > this goto statement to its label
> > > > > > 1715 | goto err_dmabuf_unmap_attachment;
> > > > > …
> > > > >
> > > > > Which software design options would you like to try out next
> > > > > so that such a questionable compilation error message will be avoided
> > > > > finally?
> > > >
> > > > The one where all emails from Markus go to dev/null
> > >
> > > Play nice please.
> >
> > Would love to... but Markus has been repeat offender
> >
> > Sadly, I am yet to see a constructive approach or even better a helpful
> > patch which improve something, rather than vague suggestions on the list
Right, there are communication issues.
Doesn't mean we have to lower our own standards.
> Yeah, just look at how many automatic replies he get's from Greg pretty much
> saying to ignore his comments.
Yes, Greg is also grumpy about it, but at least he remains polite.
On Fri, 21 Jun 2024, Markus Elfring wrote:
> > Sadly, I am yet to see a constructive approach or even better a helpful
> > patch which improve something, rather than vague suggestions on the list
>
> Can you get any more constructive impressions from another data representation?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Elfring
>
> Are you aware how many change suggestions (also from my selection) are still
> in various waiting queues?
No one is doubting your overall contributions Markus.
The issue is one of communication and the way reviews are conducted.
Reviewing other people's work is challenging and requires a certain
skill-set, of which _excellent_ communication skills are non-negotiable.
Why not concentrate on more complex submissions for a while and grow
your repertoire of common review points, rather than repeating the same
few over and over? Reading other, more experienced maintainer's reviews
would also be a good use of your time.
> The issue is one of communication and the way reviews are conducted.
>
> Reviewing other people's work is challenging and requires a certain
> skill-set, of which _excellent_ communication skills are non-negotiable.
Patch feedback and change tolerance can vary also according to involved communities.
> Why not concentrate on more complex submissions for a while and grow
> your repertoire of common review points,
Further collateral evolution can be considered there depending on
corresponding development resources.
> rather than repeating the same few over and over?
Some factors are probably known also according to corresponding statistics.
Several contributors are stumbling on recurring improvement possibilities
in published information.
> Reading other, more experienced maintainer's reviews would also be a good use
> of your time.
I am trying to influence adjustments in desirable directions for a while.
Regards,
Markus
On Fri, 21 Jun 2024, Markus Elfring wrote:
> > The issue is one of communication and the way reviews are conducted.
> >
> > Reviewing other people's work is challenging and requires a certain
> > skill-set, of which _excellent_ communication skills are non-negotiable.
>
> Patch feedback and change tolerance can vary also according to involved communities.
Agreed.
For this community, I suggest you build your skills for a while longer.
> > Why not concentrate on more complex submissions for a while and grow
> > your repertoire of common review points,
>
> Further collateral evolution can be considered there depending on
> corresponding development resources.
>
> > rather than repeating the same few over and over?
>
> Some factors are probably known also according to corresponding statistics.
> Several contributors are stumbling on recurring improvement possibilities
> in published information.
Right, this will always be true, however the few you've picked up on
are not important enough to keep reiterating. By doing so, you're
receiving undesirable attention.
> > Reading other, more experienced maintainer's reviews would also be a good use
> > of your time.
>
> I am trying to influence adjustments in desirable directions for a while.
Never stop trying to improve.
These are only my opinions of course. Take the advice or leave it.
There's no need to reply to this.
@@ -14,6 +14,7 @@ if IIO
config IIO_BUFFER
bool "Enable buffer support within IIO"
+ select DMA_SHARED_BUFFER
help
Provide core support for various buffer based data
acquisition methods.
@@ -9,15 +9,20 @@
* - Better memory allocation techniques?
* - Alternative access techniques?
*/
+#include <linux/atomic.h>
#include <linux/anon_inodes.h>
#include <linux/cleanup.h>
#include <linux/kernel.h>
#include <linux/export.h>
#include <linux/device.h>
+#include <linux/dma-buf.h>
+#include <linux/dma-fence.h>
+#include <linux/dma-resv.h>
#include <linux/file.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/slab.h>
+#include <linux/mm.h>
#include <linux/poll.h>
#include <linux/sched/signal.h>
@@ -29,6 +34,34 @@
#include <linux/iio/buffer.h>
#include <linux/iio/buffer_impl.h>
+#define DMABUF_ENQUEUE_TIMEOUT_MS 5000
+
+MODULE_IMPORT_NS(DMA_BUF);
+
+struct iio_dmabuf_priv {
+ struct list_head entry;
+ struct kref ref;
+
+ struct iio_buffer *buffer;
+ struct iio_dma_buffer_block *block;
+
+ u64 context;
+
+ /* Spinlock used for locking the dma_fence */
+ spinlock_t lock;
+
+ struct dma_buf_attachment *attach;
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+ atomic_t seqno;
+};
+
+struct iio_dma_fence {
+ struct dma_fence base;
+ struct iio_dmabuf_priv *priv;
+ struct work_struct work;
+};
+
static const char * const iio_endian_prefix[] = {
[IIO_BE] = "be",
[IIO_LE] = "le",
@@ -333,6 +366,8 @@ void iio_buffer_init(struct iio_buffer *buffer)
{
INIT_LIST_HEAD(&buffer->demux_list);
INIT_LIST_HEAD(&buffer->buffer_list);
+ INIT_LIST_HEAD(&buffer->dmabufs);
+ mutex_init(&buffer->dmabufs_mutex);
init_waitqueue_head(&buffer->pollq);
kref_init(&buffer->ref);
if (!buffer->watermark)
@@ -1526,14 +1561,55 @@ static void iio_buffer_unregister_legacy_sysfs_groups(struct iio_dev *indio_dev)
kfree(iio_dev_opaque->legacy_scan_el_group.attrs);
}
+static void iio_buffer_dmabuf_release(struct kref *ref)
+{
+ struct iio_dmabuf_priv *priv = container_of(ref, struct iio_dmabuf_priv, ref);
+ struct dma_buf_attachment *attach = priv->attach;
+ struct iio_buffer *buffer = priv->buffer;
+ struct dma_buf *dmabuf = attach->dmabuf;
+
+ dma_resv_lock(dmabuf->resv, NULL);
+ dma_buf_unmap_attachment(attach, priv->sgt, priv->dir);
+ dma_resv_unlock(dmabuf->resv);
+
+ buffer->access->detach_dmabuf(buffer, priv->block);
+
+ dma_buf_detach(attach->dmabuf, attach);
+ dma_buf_put(dmabuf);
+ kfree(priv);
+}
+
+static void iio_buffer_dmabuf_get(struct dma_buf_attachment *attach)
+{
+ struct iio_dmabuf_priv *priv = attach->importer_priv;
+
+ kref_get(&priv->ref);
+}
+
+static void iio_buffer_dmabuf_put(struct dma_buf_attachment *attach)
+{
+ struct iio_dmabuf_priv *priv = attach->importer_priv;
+
+ kref_put(&priv->ref, iio_buffer_dmabuf_release);
+}
+
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(&buffer->pollq);
+ guard(mutex)(&buffer->dmabufs_mutex);
+
+ /* Close all attached DMABUFs */
+ list_for_each_entry_safe(priv, tmp, &buffer->dmabufs, entry) {
+ list_del_init(&priv->entry);
+ iio_buffer_dmabuf_put(priv->attach);
+ }
+
kfree(ib);
clear_bit(IIO_BUSY_BIT_POS, &buffer->flags);
iio_device_put(indio_dev);
@@ -1541,11 +1617,391 @@ static int iio_buffer_chrdev_release(struct inode *inode, struct file *filep)
return 0;
}
+static int iio_dma_resv_lock(struct dma_buf *dmabuf, bool nonblock)
+{
+ if (!nonblock)
+ return dma_resv_lock_interruptible(dmabuf->resv, NULL);
+
+ if (!dma_resv_trylock(dmabuf->resv))
+ return -EBUSY;
+
+ return 0;
+}
+
+static struct dma_buf_attachment *
+iio_buffer_find_attachment(struct iio_dev_buffer_pair *ib,
+ struct dma_buf *dmabuf, bool nonblock)
+{
+ struct device *dev = ib->indio_dev->dev.parent;
+ struct iio_buffer *buffer = ib->buffer;
+ struct dma_buf_attachment *attach = NULL;
+ struct iio_dmabuf_priv *priv;
+
+ guard(mutex)(&buffer->dmabufs_mutex);
+
+ list_for_each_entry(priv, &buffer->dmabufs, entry) {
+ if (priv->attach->dev == dev
+ && priv->attach->dmabuf == dmabuf) {
+ attach = priv->attach;
+ break;
+ }
+ }
+
+ if (attach)
+ iio_buffer_dmabuf_get(attach);
+
+ return attach ?: ERR_PTR(-EPERM);
+}
+
+static int iio_buffer_attach_dmabuf(struct iio_dev_buffer_pair *ib,
+ int __user *user_fd, bool nonblock)
+{
+ struct iio_dev *indio_dev = ib->indio_dev;
+ struct iio_buffer *buffer = ib->buffer;
+ struct dma_buf_attachment *attach;
+ struct iio_dmabuf_priv *priv, *each;
+ struct dma_buf *dmabuf;
+ int err, fd;
+
+ if (!buffer->access->attach_dmabuf
+ || !buffer->access->detach_dmabuf
+ || !buffer->access->enqueue_dmabuf)
+ return -EPERM;
+
+ if (copy_from_user(&fd, user_fd, sizeof(fd)))
+ return -EFAULT;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ spin_lock_init(&priv->lock);
+ priv->context = dma_fence_context_alloc(1);
+
+ dmabuf = dma_buf_get(fd);
+ if (IS_ERR(dmabuf)) {
+ err = PTR_ERR(dmabuf);
+ goto err_free_priv;
+ }
+
+ attach = dma_buf_attach(dmabuf, indio_dev->dev.parent);
+ if (IS_ERR(attach)) {
+ err = PTR_ERR(attach);
+ goto err_dmabuf_put;
+ }
+
+ err = iio_dma_resv_lock(dmabuf, nonblock);
+ if (err)
+ goto err_dmabuf_detach;
+
+ priv->dir = buffer->direction == IIO_BUFFER_DIRECTION_IN
+ ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+
+ priv->sgt = dma_buf_map_attachment(attach, priv->dir);
+ if (IS_ERR(priv->sgt)) {
+ err = PTR_ERR(priv->sgt);
+ dev_err(&indio_dev->dev, "Unable to map attachment: %d\n", err);
+ goto err_resv_unlock;
+ }
+
+ kref_init(&priv->ref);
+ priv->buffer = buffer;
+ priv->attach = attach;
+ attach->importer_priv = priv;
+
+ priv->block = buffer->access->attach_dmabuf(buffer, attach);
+ if (IS_ERR(priv->block)) {
+ err = PTR_ERR(priv->block);
+ goto err_dmabuf_unmap_attachment;
+ }
+
+ dma_resv_unlock(dmabuf->resv);
+
+ guard(mutex)(&buffer->dmabufs_mutex);
+
+ /*
+ * Check whether we already have an attachment for this driver/DMABUF
+ * combo. If we do, refuse to attach.
+ */
+ list_for_each_entry(each, &buffer->dmabufs, entry) {
+ if (each->attach->dev == indio_dev->dev.parent
+ && each->attach->dmabuf == dmabuf) {
+ /*
+ * We unlocked the reservation object, so going through
+ * the cleanup code would mean re-locking it first.
+ * At this stage it is simpler to free the attachment
+ * using iio_buffer_dma_put().
+ */
+ iio_buffer_dmabuf_put(attach);
+ return -EBUSY;
+ }
+ }
+
+ /* Otherwise, add the new attachment to our dmabufs list. */
+ list_add(&priv->entry, &buffer->dmabufs);
+
+ return 0;
+
+err_dmabuf_unmap_attachment:
+ dma_buf_unmap_attachment(attach, priv->sgt, priv->dir);
+err_resv_unlock:
+ dma_resv_unlock(dmabuf->resv);
+err_dmabuf_detach:
+ dma_buf_detach(dmabuf, attach);
+err_dmabuf_put:
+ dma_buf_put(dmabuf);
+err_free_priv:
+ kfree(priv);
+
+ return err;
+}
+
+static int iio_buffer_detach_dmabuf(struct iio_dev_buffer_pair *ib,
+ int __user *user_req, bool nonblock)
+{
+ struct iio_buffer *buffer = ib->buffer;
+ struct iio_dev *indio_dev = ib->indio_dev;
+ struct iio_dmabuf_priv *priv;
+ struct dma_buf *dmabuf;
+ int dmabuf_fd, ret = -EPERM;
+
+ if (copy_from_user(&dmabuf_fd, user_req, sizeof(dmabuf_fd)))
+ return -EFAULT;
+
+ dmabuf = dma_buf_get(dmabuf_fd);
+ if (IS_ERR(dmabuf))
+ return PTR_ERR(dmabuf);
+
+ guard(mutex)(&buffer->dmabufs_mutex);
+
+ list_for_each_entry(priv, &buffer->dmabufs, entry) {
+ if (priv->attach->dev == indio_dev->dev.parent
+ && priv->attach->dmabuf == dmabuf) {
+ list_del(&priv->entry);
+
+ /* Unref the reference from iio_buffer_attach_dmabuf() */
+ iio_buffer_dmabuf_put(priv->attach);
+ ret = 0;
+ break;
+ }
+ }
+
+ dma_buf_put(dmabuf);
+
+ 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_buffer *buffer = ib->buffer;
+ struct iio_dmabuf iio_dmabuf;
+ struct dma_buf_attachment *attach;
+ struct iio_dmabuf_priv *priv;
+ struct iio_dma_fence *fence;
+ struct dma_buf *dmabuf;
+ unsigned long timeout;
+ bool cookie, cyclic, dma_to_ram;
+ long retl;
+ u32 seqno;
+ int ret;
+
+ if (copy_from_user(&iio_dmabuf, iio_dmabuf_req, sizeof(iio_dmabuf)))
+ return -EFAULT;
+
+ if (iio_dmabuf.flags & ~IIO_BUFFER_DMABUF_SUPPORTED_FLAGS)
+ return -EINVAL;
+
+ cyclic = iio_dmabuf.flags & IIO_BUFFER_DMABUF_CYCLIC;
+
+ /* Cyclic flag is only supported on output buffers */
+ if (cyclic && buffer->direction != IIO_BUFFER_DIRECTION_OUT)
+ return -EINVAL;
+
+ dmabuf = dma_buf_get(iio_dmabuf.fd);
+ if (IS_ERR(dmabuf))
+ return PTR_ERR(dmabuf);
+
+ if (!iio_dmabuf.bytes_used || iio_dmabuf.bytes_used > dmabuf->size) {
+ ret = -EINVAL;
+ goto err_dmabuf_put;
+ }
+
+ attach = iio_buffer_find_attachment(ib, dmabuf, nonblock);
+ if (IS_ERR(attach)) {
+ ret = PTR_ERR(attach);
+ goto err_dmabuf_put;
+ }
+
+ priv = attach->importer_priv;
+
+ fence = kmalloc(sizeof(*fence), GFP_KERNEL);
+ if (!fence) {
+ ret = -ENOMEM;
+ goto err_attachment_put;
+ }
+
+ fence->priv = priv;
+
+ seqno = atomic_add_return(1, &priv->seqno);
+
+ /*
+ * The transfers are guaranteed to be processed in the order they are
+ * enqueued, so we can use a simple incrementing sequence number for
+ * the dma_fence.
+ */
+ dma_fence_init(&fence->base, &iio_buffer_dma_fence_ops,
+ &priv->lock, priv->context, seqno);
+
+ ret = iio_dma_resv_lock(dmabuf, nonblock);
+ if (ret)
+ goto err_fence_put;
+
+ timeout = nonblock ? 0 : msecs_to_jiffies(DMABUF_ENQUEUE_TIMEOUT_MS);
+ dma_to_ram = buffer->direction == IIO_BUFFER_DIRECTION_IN;
+
+ /* Make sure we don't have writers */
+ retl = dma_resv_wait_timeout(dmabuf->resv,
+ dma_resv_usage_rw(dma_to_ram),
+ true, timeout);
+ if (retl == 0)
+ retl = -EBUSY;
+ if (retl < 0) {
+ ret = (int)retl;
+ goto err_resv_unlock;
+ }
+
+ if (buffer->access->lock_queue)
+ buffer->access->lock_queue(buffer);
+
+ ret = dma_resv_reserve_fences(dmabuf->resv, 1);
+ if (ret)
+ goto err_queue_unlock;
+
+ dma_resv_add_fence(dmabuf->resv, &fence->base,
+ dma_to_ram ? DMA_RESV_USAGE_WRITE : DMA_RESV_USAGE_READ);
+ dma_resv_unlock(dmabuf->resv);
+
+ cookie = dma_fence_begin_signalling();
+
+ ret = buffer->access->enqueue_dmabuf(buffer, priv->block, &fence->base,
+ priv->sgt, iio_dmabuf.bytes_used,
+ cyclic);
+ if (ret) {
+ /*
+ * DMABUF enqueue failed, but we already added the fence.
+ * Signal the error through the fence completion mechanism.
+ */
+ iio_buffer_signal_dmabuf_done(&fence->base, ret);
+ }
+
+ if (buffer->access->unlock_queue)
+ buffer->access->unlock_queue(buffer);
+
+ dma_fence_end_signalling(cookie);
+ dma_buf_put(dmabuf);
+
+ return ret;
+
+err_queue_unlock:
+ if (buffer->access->unlock_queue)
+ buffer->access->unlock_queue(buffer);
+err_resv_unlock:
+ dma_resv_unlock(dmabuf->resv);
+err_fence_put:
+ dma_fence_put(&fence->base);
+err_attachment_put:
+ iio_buffer_dmabuf_put(attach);
+err_dmabuf_put:
+ dma_buf_put(dmabuf);
+
+ return ret;
+}
+
+static void iio_buffer_cleanup(struct work_struct *work)
+{
+ struct iio_dma_fence *fence =
+ container_of(work, struct iio_dma_fence, work);
+ struct iio_dmabuf_priv *priv = fence->priv;
+ struct dma_buf_attachment *attach = priv->attach;
+
+ dma_fence_put(&fence->base);
+ iio_buffer_dmabuf_put(attach);
+}
+
+void iio_buffer_signal_dmabuf_done(struct dma_fence *fence, int ret)
+{
+ struct iio_dma_fence *iio_fence =
+ container_of(fence, struct iio_dma_fence, base);
+ bool cookie = dma_fence_begin_signalling();
+
+ /*
+ * Get a reference to the fence, so that it's not freed as soon as
+ * it's signaled.
+ */
+ dma_fence_get(fence);
+
+ fence->error = ret;
+ dma_fence_signal(fence);
+ dma_fence_end_signalling(cookie);
+
+ /*
+ * The fence will be unref'd in iio_buffer_cleanup.
+ * It can't be done here, as the unref functions might try to lock the
+ * resv object, which can deadlock.
+ */
+ INIT_WORK(&iio_fence->work, iio_buffer_cleanup);
+ schedule_work(&iio_fence->work);
+}
+EXPORT_SYMBOL_GPL(iio_buffer_signal_dmabuf_done);
+
+static long iio_buffer_chrdev_ioctl(struct file *filp,
+ unsigned int cmd, unsigned long arg)
+{
+ struct iio_dev_buffer_pair *ib = filp->private_data;
+ void __user *_arg = (void __user *)arg;
+ bool nonblock = filp->f_flags & O_NONBLOCK;
+
+ switch (cmd) {
+ case IIO_BUFFER_DMABUF_ATTACH_IOCTL:
+ return iio_buffer_attach_dmabuf(ib, _arg, nonblock);
+ case IIO_BUFFER_DMABUF_DETACH_IOCTL:
+ return iio_buffer_detach_dmabuf(ib, _arg, nonblock);
+ case IIO_BUFFER_DMABUF_ENQUEUE_IOCTL:
+ return iio_buffer_enqueue_dmabuf(ib, _arg, nonblock);
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct file_operations iio_buffer_chrdev_fileops = {
.owner = THIS_MODULE,
.llseek = noop_llseek,
.read = iio_buffer_read,
.write = iio_buffer_write,
+ .unlocked_ioctl = iio_buffer_chrdev_ioctl,
+ .compat_ioctl = compat_ptr_ioctl,
.poll = iio_buffer_poll,
.release = iio_buffer_chrdev_release,
};
@@ -1994,6 +2450,7 @@ static void iio_buffer_release(struct kref *ref)
{
struct iio_buffer *buffer = container_of(ref, struct iio_buffer, ref);
+ mutex_destroy(&buffer->dmabufs_mutex);
buffer->access->release(buffer);
}
@@ -9,8 +9,12 @@
#include <uapi/linux/iio/buffer.h>
#include <linux/iio/buffer.h>
+struct dma_buf_attachment;
+struct dma_fence;
struct iio_dev;
+struct iio_dma_buffer_block;
struct iio_buffer;
+struct sg_table;
/**
* INDIO_BUFFER_FLAG_FIXED_WATERMARK - Watermark level of the buffer can not be
@@ -39,6 +43,16 @@ struct iio_buffer;
* device stops sampling. Calles are balanced with @enable.
* @release: called when the last reference to the buffer is dropped,
* should free all resources allocated by the buffer.
+ * @attach_dmabuf: called from userspace via ioctl to attach one external
+ * DMABUF.
+ * @detach_dmabuf: called from userspace via ioctl to detach one previously
+ * attached DMABUF.
+ * @enqueue_dmabuf: called from userspace via ioctl to queue this DMABUF
+ * object to this buffer. Requires a valid DMABUF fd, that
+ * was previouly attached to this buffer.
+ * @lock_queue: called when the core needs to lock the buffer queue;
+ * it is used when enqueueing DMABUF objects.
+ * @unlock_queue: used to unlock a previously locked buffer queue
* @modes: Supported operating modes by this buffer type
* @flags: A bitmask combination of INDIO_BUFFER_FLAG_*
*
@@ -68,6 +82,17 @@ struct iio_buffer_access_funcs {
void (*release)(struct iio_buffer *buffer);
+ struct iio_dma_buffer_block * (*attach_dmabuf)(struct iio_buffer *buffer,
+ struct dma_buf_attachment *attach);
+ void (*detach_dmabuf)(struct iio_buffer *buffer,
+ struct iio_dma_buffer_block *block);
+ int (*enqueue_dmabuf)(struct iio_buffer *buffer,
+ struct iio_dma_buffer_block *block,
+ struct dma_fence *fence, struct sg_table *sgt,
+ size_t size, bool cyclic);
+ void (*lock_queue)(struct iio_buffer *buffer);
+ void (*unlock_queue)(struct iio_buffer *buffer);
+
unsigned int modes;
unsigned int flags;
};
@@ -136,6 +161,12 @@ struct iio_buffer {
/* @ref: Reference count of the buffer. */
struct kref ref;
+
+ /* @dmabufs: List of DMABUF attachments */
+ struct list_head dmabufs; /* P: dmabufs_mutex */
+
+ /* @dmabufs_mutex: Protects dmabufs */
+ struct mutex dmabufs_mutex;
};
/**
@@ -159,6 +190,8 @@ void iio_buffer_init(struct iio_buffer *buffer);
struct iio_buffer *iio_buffer_get(struct iio_buffer *buffer);
void iio_buffer_put(struct iio_buffer *buffer);
+void iio_buffer_signal_dmabuf_done(struct dma_fence *fence, int ret);
+
#else /* CONFIG_IIO_BUFFER */
static inline void iio_buffer_get(struct iio_buffer *buffer) {}
@@ -5,6 +5,28 @@
#ifndef _UAPI_IIO_BUFFER_H_
#define _UAPI_IIO_BUFFER_H_
+#include <linux/types.h>
+
+/* Flags for iio_dmabuf.flags */
+#define IIO_BUFFER_DMABUF_CYCLIC (1 << 0)
+#define IIO_BUFFER_DMABUF_SUPPORTED_FLAGS 0x00000001
+
+/**
+ * struct iio_dmabuf - Descriptor for a single IIO DMABUF object
+ * @fd: file descriptor of the DMABUF object
+ * @flags: one or more IIO_BUFFER_DMABUF_* flags
+ * @bytes_used: number of bytes used in this DMABUF for the data transfer.
+ * Should generally be set to the DMABUF's size.
+ */
+struct iio_dmabuf {
+ __u32 fd;
+ __u32 flags;
+ __u64 bytes_used;
+};
+
#define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
+#define IIO_BUFFER_DMABUF_ATTACH_IOCTL _IOW('i', 0x92, int)
+#define IIO_BUFFER_DMABUF_DETACH_IOCTL _IOW('i', 0x93, int)
+#define IIO_BUFFER_DMABUF_ENQUEUE_IOCTL _IOW('i', 0x94, struct iio_dmabuf)
#endif /* _UAPI_IIO_BUFFER_H_ */