RE: [PATCH] RFC: dma-buf: userspace mmap support

From: Rob Clark r...@ti.com Enable optional userspace access to dma-buf buffers via mmap() on the dma-buf file descriptor. Userspace access to the buffer should be bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to give the exporting driver a chance to deal with cache

RE: [PATCH] RFC: dma-buf: userspace mmap support

-Original Message- From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] Sent: 17 March 2012 20:17 To: Tom Cooksey Cc: 'Rob Clark'; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; linux-me...@vger.kernel.org; rschu...@google.com; Rob Clark; sumit.sem...@linaro.org

RE: [PATCH] RFC: dma-buf: userspace mmap support

-Original Message- From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] Sent: 19 March 2012 16:57 To: Tom Cooksey Cc: 'Rob Clark'; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; linux-me...@vger.kernel.org; rschu...@google.com; Rob Clark; sumit.sem...@linaro.org

New xf86-video-armsoc DDX driver

Hi All, For the last few months we (ARM MPD... The Mali guys) have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller via

RE: [Linaro-mm-sig] New xf86-video-armsoc DDX driver

-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: 21 May 2012 10:04 To: Dave Airlie Cc: Tom Cooksey; linaro-mm-...@lists.linaro.org; xorg- de...@lists.x.org; dri-devel@lists.freedesktop.org Subject: Re: [Linaro-mm-sig] New

[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

I guess what I'm saying is please don't review the actual code just yet, only the concepts the code describes, where kds_resource == dma_duf. Cheers, Tom Author: Tom Cooksey tom.cook...@arm.com Date: Fri May 25 10:45:27 2012 +0100 Add new system to allow synchronizing access

RE: [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

There are multiple ways synchronization can be achieved, fences/sync objects is one common approach, however we're presenting a different approach. Personally, I quite like fence sync objects, however we believe it requires a lot of userspace interfaces to be changed to pass around

RE: [Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

 The bigger issue is the previous point about how to deal with cases where the CPU doesn't really need to get involved as an intermediary. CPU fallback access to the buffer is the only legit case where we need a standardized API to userspace (since CPU access isn't already

RE: [RFC] dma-fence: dma-buf synchronization (v2)

Hi Rob, Yes, sorry we've been a bit slack progressing KDS publicly. Your approach looks interesting and seems like it could enable both implicit and explicit synchronization. A good compromise. From: Rob Clark r...@ti.com A dma-fence can be attached to a buffer which is being filled or

RE: [Linaro-mm-sig] [RFC] New dma_buf - EGLImage EGL extension

Hi Maarten, Thanks for taking a look at this! Responses in-line... Cheers, Tom -Original Message- From: Maarten Lankhorst [mailto:m.b.lankho...@gmail.com] Sent: 02 October 2012 13:10 To: Tom Cooksey Cc: mesa-...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri- de

RE: [Linaro-mm-sig] [RFC] New dma_buf - EGLImage EGL extension

Hi Rob, -Original Message- From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob Clark Sent: 03 October 2012 13:39 To: Maarten Lankhorst Cc: Tom Cooksey; mesa-...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; Jesse

RE: [Mesa-dev] [RFC] New dma_buf - EGLImage EGL extension - Final spec published!

@lists.freedesktop.org [mailto:mesa-dev- bounces+tom.cooksey=arm@lists.freedesktop.org] On Behalf Of Tom Cooksey Sent: 04 October 2012 13:10 To: mesa-...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; linux-me...@vger.kernel.org Subject: [Mesa-dev

Status of exporting an fbdev framebuffer with dma_buf?

Hi All, Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev framebuffer through dma_buf. Looking through the mailing list archives, it doesn't appear to have progressed beyond an RFC? What would be needed to get this merged? It would be useful for our Mali T6xx

RE: abuse of dumb ioctls in exynos

It appears exynos is passing the generic flags from the dumb ioctls straight into the the GEM creation code. The dumb flags are NOT driver specific, and are NOT to be used in this fashion. Please remove this use of the flags from your driver. I was going to add one new flag to the

RE: abuse of dumb ioctls in exynos

- From: Dave Airlie [mailto:airl...@gmail.com] Sent: 23 April 2013 21:29 To: Tom Cooksey Cc: dri-devel; Inki Dae Subject: Re: abuse of dumb ioctls in exynos Having a flag to indicate a dumb buffer allocation is to be used as a scan-out buffer would be useful for xf86-video-armsoc

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also allocate buffers for the GPU. Still not sure how to resolve this as we don't use DRM for our GPU driver. any thoughts/plans about a DRM GPU driver? Ideally long term (esp. once the dma-fence stuff is in

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, +linux-media, +linaro-mm-sig for discussion of video/camera buffer constraints... On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com wrote: * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also allocate buffers for the GPU. Still not sure how

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, +lkml On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com wrote: * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also allocate buffers for the GPU. Still not sure how to resolve this as we don't use DRM for our GPU driver. any

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, We may also then have additional constraints when sharing buffers between the display HW and video decode or even camera ISP HW. Programmatically describing buffer allocation constraints is very difficult and I'm not sure you can actually do it - there's some pretty complex

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

... This is the purpose of the attach step, so you know all the devices involved in sharing up front before allocating the backing pages. (Or in the worst case, if you have a late attacher you at least know when no device is doing dma access to a buffer and can reallocate and move the

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Didn't you say that programmatically describing device placement constraints was an unbounded problem? I guess we would have to accept that it's not possible to describe all possible constraints and instead find a way to describe the common ones? well, the point I'm trying to

RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

Hi Daniel, Rob. Thank you both for your reviews - greatly appreciated! Known issues: * It still includes code to use KDS, which is not going upstream. review's on http://lists.freedesktop.org/archives/dri-devel/2013- July/042462.html can't hurt although you might consider

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Turning to DRM/KMS, it seems the supported formats of a plane can be queried using drm_mode_get_plane. However, there doesn't seem to be a way to query the supported formats of a crtc? If display HW only supports scanning out from a single buffer (like pl111 does), I think it won't have

RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

So in the above, after X receives the second DRI2SwapBuffers, it doesn't need to get scheduled again for the next frame to be both rendered by the GPU and issued to the display for scanout. well, this is really only an issue if you are so loaded that you don't get a chance to

RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

So in the above, after X receives the second DRI2SwapBuffers, it doesn't need to get scheduled again for the next frame to be both rendered by the GPU and issued to the display for scanout. well, this is really only an issue if you are so loaded that you don't get a chance to

RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Turning to DRM/KMS, it seems the supported formats of a plane can be queried using drm_mode_get_plane. However, there doesn't seem to be a way to query the supported formats of a crtc? If display HW only supports scanning out from a single buffer (like pl111 does), I think it

RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

So in the above, after X receives the second DRI2SwapBuffers, it doesn't need to get scheduled again for the next frame to be both rendered by the GPU and issued to the display for scanout. well, this is really only an issue if you are so loaded that you don't

[PATCH] RFC: dma-buf: userspace mmap support

> From: Rob Clark > > Enable optional userspace access to dma-buf buffers via mmap() on the > dma-buf file descriptor. Userspace access to the buffer should be > bracketed with DMA_BUF_IOCTL_{PREPARE,FINISH}_ACCESS ioctl calls to > give the exporting driver a chance to deal with cache

[PATCH] RFC: dma-buf: userspace mmap support

> -Original Message- > From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk] > Sent: 17 March 2012 20:17 > To: Tom Cooksey > Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri- > devel at lists.freedesktop.org; linux-media at vger.kernel.org; > rschultz at

[PATCH] RFC: dma-buf: userspace mmap support

> -Original Message- > From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk] > Sent: 19 March 2012 16:57 > To: Tom Cooksey > Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri- > devel at lists.freedesktop.org; linux-media at vger.kernel.org; > rschultz at

New "xf86-video-armsoc" DDX driver

Hi All, For the last few months we (ARM MPD... "The Mali guys") have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller

[Linaro-mm-sig] New "xf86-video-armsoc" DDX driver

> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: 21 May 2012 10:04 > To: Dave Airlie > Cc: Tom Cooksey; linaro-mm-sig at lists.linaro.org; xorg- > devel at lists.x.org; dri-devel at lists.freedesk

[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

buf_* functions, etc. So I guess what I'm saying is please don't review the actual code just yet, only the concepts the code describes, where kds_resource == dma_duf. Cheers, Tom Author: Tom Cooksey Date: Fri May 25 10:45:27 2012 +0100 Add new system to allow synchronizing access t

[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

> > There are multiple ways synchronization can be achieved, > > fences/sync objects is one common approach, however we're > > presenting a different approach. Personally, I quite like > > fence sync objects, however we believe it requires a lot of > > userspace interfaces to be changed to pass

[Linaro-mm-sig] [RFC] New dma_buf -> EGLImage EGL extension

Hi Maarten, Thanks for taking a look at this! Responses in-line... Cheers, Tom > -Original Message- > From: Maarten Lankhorst [mailto:m.b.lankhorst at gmail.com] > Sent: 02 October 2012 13:10 > To: Tom Cooksey > Cc: mesa-dev at lists.freedesktop.org; linaro-mm-sig at l

[RFC] New dma_buf -> EGLImage EGL extension - New draft!

8< Name EXT_image_dma_buf_import Name Strings EGL_EXT_image_dma_buf_import Contributors Jesse Barker Rob Clark Tom Cooksey Contacts Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org) Tom Cooksey (tom 'dot' cooksey 'at'

[Linaro-mm-sig] [RFC] New dma_buf -> EGLImage EGL extension

Hi Rob, > -Original Message- > From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob > Clark > Sent: 03 October 2012 13:39 > To: Maarten Lankhorst > Cc: Tom Cooksey; mesa-dev at lists.freedesktop.org; linaro-mm-sig at > lists.lin

Status of exporting an fbdev framebuffer with dma_buf?

Hi All, Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev framebuffer through dma_buf. Looking through the mailing list archives, it doesn't appear to have progressed beyond an RFC? What would be needed to get this merged? It would be useful for our Mali T6xx

abuse of dumb ioctls in exynos

> It appears exynos is passing the generic flags from the dumb ioctls > straight into the the GEM creation code. > > The dumb flags are NOT driver specific, and are NOT to be used in this > fashion. Please remove this use of the flags from your driver. > > I was going to add one new flag to the

abuse of dumb ioctls in exynos

age- > From: Dave Airlie [mailto:airlied at gmail.com] > Sent: 23 April 2013 21:29 > To: Tom Cooksey > Cc: dri-devel; Inki Dae > Subject: Re: abuse of dumb ioctls in exynos > > > > > Having a flag to indicate a dumb buffer allocation is to be used as a > > s

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, +linux-media, +linaro-mm-sig for discussion of video/camera buffer constraints... > On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey > wrote: > >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also > >> >allocate buffers for the GPU.

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, +lkml > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey > >> wrote: > >> >> > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to > >> >> >also allocate buffers for the GPU. Still not sure how to > >&

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, > >> > We may also then have additional constraints when sharing buffers > >> > between the display HW and video decode or even camera ISP HW. > >> > Programmatically describing buffer allocation constraints is very > >> > difficult and I'm not sure you can actually do it - there's some >

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

> >> ... This is the purpose of the attach step, > >> so you know all the devices involved in sharing up front before > >> allocating the backing pages. (Or in the worst case, if you have a > >> "late attacher" you at least know when no device is doing dma access > >> to a buffer and can

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

> >> > Didn't you say that programmatically describing device placement > >> > constraints was an unbounded problem? I guess we would have to > >> > accept that it's not possible to describe all possible constraints > >> > and instead find a way to describe the common ones? > >> > >> well, the

[RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

Hi Daniel, Rob. Thank you both for your reviews - greatly appreciated! > > > Known issues: > > > * It still includes code to use KDS, which is not going upstream. > > > > review's on > July/042462.html> can't hurt > > > > although you

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

> > Turning to DRM/KMS, it seems the supported formats of a plane can be > > queried using drm_mode_get_plane. However, there doesn't seem to be a > > way to query the supported formats of a crtc? If display HW only > > supports scanning out from a single buffer (like pl111 does), I think > > it

[RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

> > > So in the above, after X receives the second DRI2SwapBuffers, it > > > doesn't need to get scheduled again for the next frame to be both > > > rendered by the GPU and issued to the display for scanout. > > > > well, this is really only an issue if you are so loaded that you > > don't get a

[RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

> > > > So in the above, after X receives the second DRI2SwapBuffers, it > > > > doesn't need to get scheduled again for the next frame to be both > > > > rendered by the GPU and issued to the display for scanout. > > > > > > well, this is really only an issue if you are so loaded that you > > >

[RFC 1/1] drm/pl111: Initial drm/kms driver for pl111

> >> > > > So in the above, after X receives the second DRI2SwapBuffers, > >> > > > it doesn't need to get scheduled again for the next frame to > >> > > > be both rendered by the GPU and issued to the display for > >> > > > scanout. > >> > > > >> > > well, this is really only an issue if you

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

> >> > Turning to DRM/KMS, it seems the supported formats of a plane > >> > can be queried using drm_mode_get_plane. However, there doesn't > >> > seem to be a way to query the supported formats of a crtc? If > >> > display HW only supports scanning out from a single buffer > >> > (like pl111

[Mesa-dev] [RFC] New dma_buf -> EGLImage EGL extension - Final spec published!

rm.com at lists.freedesktop.org > [mailto:mesa-dev- > bounces+tom.cooksey=arm.com at lists.freedesktop.org] On Behalf Of Tom Cooksey > Sent: 04 October 2012 13:10 > To: mesa-dev at lists.freedesktop.org; linaro-mm-sig at lists.linaro.org; dri- > devel at lists.freedes

[RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

Hi Rob, > > * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also > >allocate buffers for the GPU. Still not sure how to resolve this > >as we don't use DRM for our GPU driver. > > any thoughts/plans about a DRM GPU driver? Ideally long term (esp. > once the dma-fence stuff

[RFC] New dma_buf -> EGLImage EGL extension

assigning values for the new symbols. Cheers, Tom -8<- Name EXT_image_dma_buf_import Name Strings EGL_EXT_image_dma_buf_import Contributors Jesse Barker Rob Clark Tom Cooksey Contacts Jesse Barker (jesse 'dot' barker 'at' linaro 'dot' org)

[RFC] dma-fence: dma-buf synchronization (v2)

Hi Rob, Yes, sorry we've been a bit slack progressing KDS publicly. Your approach looks interesting and seems like it could enable both implicit and explicit synchronization. A good compromise. > From: Rob Clark > > A dma-fence can be attached to a buffer which is being filled or > consumed

[Linaro-mm-sig] [RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

> >>>?The bigger issue is the previous point about how to deal > >>> with cases where the CPU doesn't really need to get involved as an > >>> intermediary. > >>> > >>> CPU fallback access to the buffer is the only legit case where we > >>> need a standardized API to userspace (since CPU access