[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 d

[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 ar

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 ar

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 d

[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 > > > do

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 > > > do

[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 ch

[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 w

[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 migh

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 ch

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 w

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 > July/042462.html> can't hurt > > > > although you migh

[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 poi

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 poi

[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 reallocat

[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

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 > >&

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 reallocat

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 >

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 > >> 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, +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.

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 > 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, > > * 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

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

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

From: Tom Cooksey Please find below the current state of our pl111 DRM/KMS driver. This is lightly tested on a Versatile Express using X running the xf86-video-armsoc DDX driver[i] with the patches applied to drm-next as of ~last week. To actually see anything on the DVI output, you must also

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

RE: abuse of dumb ioctls in exynos

age- > 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 > > s

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 i

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 i

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 driver

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 driver

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

sey=arm.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.freed

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

cooksey=arm@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...

[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.linaro

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

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'

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...@

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

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'

[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

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.

[RFC] New dma_buf -> EGLImage EGL extension

to the Khronos registry, which includes 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

[RFC] New dma_buf -> EGLImage EGL extension

to the Khronos registry, which includes 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

[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 by

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 > > A dma-fence can be attached to a buffer which is being filled or > consumed by

[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 is

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 is

[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

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

kds_* functions get renamed to dma_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 A

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

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

kds_* functions get renamed to dma_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 n

[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

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 > Sub

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 vi

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 vi

[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; > rs

[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; > rs

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...@g

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...@g

[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 synchroni

RE: [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 synchroni