> -----Original Message----- > From: Lucas Stach [mailto:l.stach@xxxxxxxxxxxxxx] > 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- > kernel@xxxxxxxxxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx > 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.stach@xxxxxxxxxxxxxx] > > > 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- > > > kernel@xxxxxxxxxxxxxxxxxxx; linux-media@xxxxxxxxxxxxxxx > > > 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? Thanks, Inki Dae > > In all this I can't see any need for a new syncpoint primitive slapped > on top of dma-buf. > > 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
