Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-09-14 Thread Daniel Stone
Hi, On Tue, 2013-08-06 at 12:31 +0100, Tom Cooksey wrote: > > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey > > >> wrote: > > that was part of the reason to punt this problem to userspace ;-) > > > > In practice, the kernel drivers doesn't usually know too much about > > the dimensions/format/

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

2013-08-09 Thread Rob Clark
On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote: > >> > 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 ou

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

2013-08-07 Thread Rob Clark
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote: > >> >> > 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

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-07 Thread Alex Deucher
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote: > >> >> > 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

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

2013-08-07 Thread Rob Clark
On Wed, Aug 7, 2013 at 12:23 AM, John Stultz wrote: > On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote: >> well, let's divide things up into two categories: >> >> 1) the arrangement and format of pixels.. ie. what userspace would >> need to know if it mmap's a buffer. This includes pixel format,

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

2013-08-06 Thread John Stultz
On Tue, Aug 6, 2013 at 5:15 AM, Rob Clark wrote: > On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote: >> >>> > So in some respects, there is a constraint on how buffers which will >>> > be drawn to using the GPU are allocated. I don't really like the idea >>> > of teaching the display controller

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

2013-08-06 Thread Rob Clark
On Tue, Aug 6, 2013 at 1:38 PM, Tom Cooksey wrote: > >> >> ... 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 devi

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-06 Thread Daniel Vetter
On Tue, Aug 6, 2013 at 2:18 PM, Lucas Stach wrote: > I strongly disagree with exposing low-level hardware details like tiling > to userspace. If we have to do the negotiation of those things in > userspace we will end up with having to pipe those information through > things like the wayland proto

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-06 Thread Rob Clark
On Tue, Aug 6, 2013 at 10:36 AM, Lucas Stach wrote: > Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark: >> On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote: >> > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey: >> >> Hi Rob, >> >> >> >> +lkml >> >> >> >> > >> On Fri, Jul 2

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

2013-08-06 Thread Rob Clark
On Tue, Aug 6, 2013 at 10:03 AM, Tom Cooksey wrote: > 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 >> >> > difficu

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-06 Thread Lucas Stach
Am Dienstag, den 06.08.2013, 10:14 -0400 schrieb Rob Clark: > On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote: > > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey: > >> Hi Rob, > >> > >> +lkml > >> > >> > >> On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey > >> > >> wrote: > >> > >> >

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-06 Thread Rob Clark
On Tue, Aug 6, 2013 at 8:18 AM, Lucas Stach wrote: > Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey: >> 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 >> > >> >> >

Re: [Linaro-mm-sig] [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111

2013-08-06 Thread Lucas Stach
Am Dienstag, den 06.08.2013, 12:31 +0100 schrieb Tom Cooksey: > 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

2013-08-06 Thread Rob Clark
On Tue, Aug 6, 2013 at 7:31 AM, Tom Cooksey wrote: > >> > So in some respects, there is a constraint on how buffers which will >> > be drawn to using the GPU are allocated. I don't really like the idea >> > of teaching the display controller DRM driver about the GPU buffer >> > constraints, even i

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

2013-08-05 Thread Rob Clark
On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey wrote: > 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 >> >> >