On Mon, Mar 28, 2022 at 11:30 PM Paul Cercueil <paul@xxxxxxxxxxxxxxx> wrote:
> Le lun., mars 28 2022 at 18:54:25 +0100, Jonathan Cameron
> <jic23@xxxxxxxxxx> a écrit :
> > On Mon, 7 Feb 2022 12:59:28 +0000
> > Paul Cercueil <paul@xxxxxxxxxxxxxxx> 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.
> > I'm a bit rusty on dma mappings, but you seem to have
> > a mixture of streaming and coherent mappings going on in here.
>
> That's OK, so am I. What do you call "streaming mappings"?
dma_*_coherent() are for coherent mappings (usually you do it once and
cache coherency is guaranteed by accessing this memory by device or
CPU).
dma_map_*() are for streaming, which means that you often want to map
arbitrary pages during the transfer (usually used for the cases when
you want to keep previous data and do something with a new coming, or
when a new coming data is supplied by different virtual address, and
hence has to be mapped for DMA).
> > 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?
>
> Something like that. There are two different things; on both cases,
> userspace needs to create a DMABUF with IIO_BUFFER_DMABUF_ALLOC_IOCTL,
> and the backing memory is allocated with dma_alloc_coherent().
>
> - For the userspace interface, you then have a "cpu access" IOCTL
> (DMA_BUF_IOCTL_SYNC), that allows userspace to inform when it will
> start/finish to process the buffer in user-space (which will
> sync/invalidate the data cache if needed). A buffer can then be
> enqueued for DMA processing (TX or RX) with the new
> IIO_BUFFER_DMABUF_ENQUEUE_IOCTL.
>
> - When the DMABUF created via the IIO core is sent to another driver
> through the driver's custom DMABUF import function, this driver will
> call dma_buf_attach(), which will call iio_buffer_dma_buf_map(). Since
> it has to return a "struct sg_table *", this function then simply
> creates a sgtable with one entry that points to the backing memory.
...
> >> + ret = dma_map_sgtable(at->dev, &dba->sg_table, dma_dir, 0);
> >> + if (ret) {
> >> + kfree(dba);
> >> + return ERR_PTR(ret);
> >> + }
Missed DMA mapping error check.
> >> +
> >> + return &dba->sg_table;
> >> +}
...
> >> - /* Must not be accessed outside the core. */
> >> - struct kref kref;
> >> + struct dma_buf *dmabuf;
Is it okay to access outside the core? If no, why did you remove
(actually not modify) the comment?
--
With Best Regards,
Andy Shevchenko
