> On 22 June 2020 at 18:34 Thomas Ruf <freelan...@rufusul.de> wrote:
>
>
>
> > 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.
To make it short - i have two questions:
- what are the chances to revive DMA_SG?
- what are the chances to get my driver for memcpy like transfers from user
space using DMA_SG upstream? ("dma-sg-proxy")
Best regards,
Thomas
