> On 22 June 2020 at 17:54 Vinod Koul <vk...@kernel.org> wrote:
>
>
> On 22-06-20, 14:01, Thomas Ruf wrote:
> > > On 22 June 2020 at 06:47 Vinod Koul <vk...@kernel.org> wrote:
> > >
> > > On 21-06-20, 22:36, Federico Vaga wrote:
> > > > On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote:
> > > > > On 19-06-20, 16:31, Dave Jiang wrote:
> > > > > >
> > > > > >
> > > > > > On 6/19/2020 3:47 PM, Federico Vaga wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > is there the possibility of using a DMA engine channel from
> > > > > > > userspace?
> > > > > > >
> > > > > > > Something like:
> > > > > > > - configure DMA using ioctl() (or whatever configuration
> > > > > > > mechanism)
> > > > > > > - read() or write() to trigger the transfer
> > > > > > >
> > > > > >
> > > > > > I may have supposedly promised Vinod to look into possibly providing
> > > > > > something like this in the future. But I have not gotten around to
> > > > > > do that
> > > > > > yet. Currently, no such support.
> > > > >
> > > > > And I do still have serious reservations about this topic :) Opening
> > > > > up
> > > > > userspace access to DMA does not sound very great from security point
> > > > > of
> > > > > view.
> > > >
> > > > I was thinking about a dedicated module, and not something that the DMA
> > > > engine
> > > > offers directly. You load the module only if you need it (like the test
> > > > module)
> > >
> > > But loading that module would expose dma to userspace.
> > > >
> > > > > Federico, what use case do you have in mind?
> > > >
> > > > Userspace drivers
> > >
> > > more the reason not do do so, why cant a kernel driver be added for your
> > > usage?
> >
> > by chance i have written a driver allowing dma from user space using a
> > memcpy like interface ;-)
> > now i am trying to get this code upstream but was hit by the fact that
> > DMA_SG is gone since Aug 2017 :-(
> >
> > just let me introduce myself and the project:
> > - coding in C since '91
> > - coding in C++ since '98
> > - a lot of stuff not relevant for this ;-)
> > - working as a freelancer since Nov '19
> > - implemented a "dma-sg-proxy" driver for my client in Mar/Apr '20 to copy
> > camera frames from uncached memory to cached memory using a second dma on a
> > Zynq platform
> > - last week we figured out that we can not upgrade from "Xilinx 2019.2"
> > (kernel 4.19.x) to "2020.1" (kernel 5.4.x) because the DMA_SG interface is
> > gone
> > - subscribed to dmaengine on friday, saw the start of this discussion on
> > saturday
> > - talked to my client today if it is ok to try to revive DMA_SG and get our
> > driver upstream to avoid such problems in future
>
> DMA_SG was removed as it had no users, if we have a user (in-kernel) we
> can certainly revert that removal patch.
yeah, already understood that.
> >
> > here the struct for the ioctl:
> >
> > typedef struct {
> > unsigned int struct_size;
> > const void *src_user_ptr;
> > void *dst_user_ptr;
> > unsigned long length;
> > unsigned int timeout_in_ms;
> > } dma_sg_proxy_arg_t;
>
> Again, am not convinced opening DMA to userspace like this is a great
> idea. Why not have Xilinx camera driver invoke the dmaengine and do
> DMA_SG ?
In our case we have several camera pipelines, in some cases uncached memory is
okay (e. g. image goes directly to display framebuffer), in some cases not
because we need to process the images on cpu or gpu and we for that need to
copy to oridinary user memoy first. This seems easier to do by decoupling the
driver code.
And one more thing: in case we engage the dma memcpy we want to copy to target
memory which is prepared for IPC because we want to share these images with
another process. The v4l2 interface did not look to be made for such cases but
is possible by this "memcpy" approach.
Best regards,
Thomas
