2013/6/19 Lucas Stach <l.st...@pengutronix.de>
> Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae:
> >
> > > -----Original Message-----
> > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > Sent: Wednesday, June 19, 2013 7:22 PM
> > > To: Inki Dae
> > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> > > ker...@lists.infradead.org; linux-me...@vger.kernel.org
> > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
> synchronization
> > > framework
> > >
> > > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
> > > >
> > > > > -----Original Message-----
> > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de]
> > > > > Sent: Tuesday, June 18, 2013 6:47 PM
> > > > > To: Inki Dae
> > > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park';
> 'DRI
> > > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> > > > > ker...@lists.infradead.org; linux-me...@vger.kernel.org
> > > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
> > > synchronization
> > > > > framework
> > > > >
> > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
> > > > > [...]
> > > > > >
> > > > > > > a display device driver. It shouldn't be used within a single
> > > driver
> > > > > > > as a means of passing buffers between userspace and kernel
> space.
> > > > > >
> > > > > > What I try to do is not really such ugly thing. What I try to do
> is
> > > to
> > > > > > notify that, when CPU tries to access a buffer , to kernel side
> > > through
> > > > > > dmabuf interface. So it's not really to send the buffer to
> kernel.
> > > > > >
> > > > > > Thanks,
> > > > > > Inki Dae
> > > > > >
> > > > > The most basic question about why you are trying to implement this
> > > sort
> > > > > of thing in the dma_buf framework still stands.
> > > > >
> > > > > Once you imported a dma_buf into your DRM driver it's a GEM object
> and
> > > > > you can and should use the native DRM ioctls to prepare/end a CPU
> > > access
> > > > > to this BO. Then internally to your driver you can use the dma_buf
> > > > > reservation/fence stuff to provide the necessary cross-device sync.
> > > > >
> > > >
> > > > I don't really want that is used only for DRM drivers. We really need
> > > > it for all other DMA devices; i.e., v4l2 based drivers. That is what
> I
> > > > try to do. And my approach uses reservation to use dma-buf resources
> > > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM
> > > > driver for why we need dma fence stuff, and how we can use it if
> > > > needed.
> > > >
> > >
> > > Still I don't see the point why you need syncpoints above dma-buf. In
> > > both the DRM and the V4L2 world we have defined points in the API where
> > > a buffer is allowed to change domain from device to CPU and vice versa.
> > >
> > > In DRM if you want to access a buffer with the CPU you do a
> cpu_prepare.
> > > The buffer changes back to GPU domain once you do the execbuf
> > > validation, queue a pageflip to the buffer or similar things.
> > >
> > > In V4L2 the syncpoints for cache operations are the queue/dequeue API
> > > entry points. Those are also the exact points to synchronize with other
> > > hardware thus using dma-buf reserve/fence.
> >
> >
> > If so, what if we want to access a buffer with the CPU _in V4L2_? We
> > should open a drm device node, and then do a cpu_prepare?
> >
> Not at all. As I said the syncpoints are the queue/dequeue operations.
> When dequeueing a buffer you are explicitly dragging the buffer domain
> back from device into userspace and thus CPU domain.
>
> If you are operating on an mmap of a V4L2 processed buffer it's either
> before or after it got processed by the hardware and therefore all DMA
> operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls.
> That is where cache operations and synchronization should happen. The
> V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it
> back into CPU domain while there is still DMA ongoing. Equally the queue
> ioctrl should make sure caches are properly written back to memory. The
> results of reading/writing to the mmap of a V4L2 buffer while it is
> enqueued to the hardware is simply undefined and there is nothing
> suggesting that this is a valid usecase.
Thanks to comments. However, that's not definitely my point, and you
just say the conventional way. My point is to more enhance the conventional
way.
The conventional way is (sorry but I'm not really a good painter) :
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- syncpoint start streaming <- dma access
DMA accesses a queued buffer with start streaming if source and
destination queues are ready.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- syncpoint
Internally, dqbuf waits for until DMA opertion is completed. And if
completed then user process can access a dequeued buffer.
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU -> DMA,
ioctl(qbuf command) ioctl(streamon)
| |
| |
qbuf <- dma_buf_sync_get start streaming <- syncpoint
dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object. And
the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
accesses the sync buffer.
And DMA -> CPU,
ioctl(dqbuf command)
|
|
dqbuf <- nothing to do
Actual syncpoint is when DMA operation is completed (in interrupt handler):
the syncpoint is performed by calling dma_buf_sync_unlock().
Hence, my approach is to move the syncpoints into just before dma access
as long as possible. Of course, user process need to call dma-buf
interfaces or simliar things for buffer synchronization with DMA side.
However, as of now, there is no good idea: I had implemented the user
interfaces in dma-buf framework but that was just to show you so ugly. The
eventual purpose of my approach is to integrate sync interfaces with dmabuf
sync, and this approach can be used commonly for v4l2, drm drivers, user
processes, and so on: as I already mentioned in document file, this
approach is for DMA devices using system memory as DMA buffer, especially
most ARM SoCs.
Thanks,
Inki Dae
> Regards,
> Lucas
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
