[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

[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

On Tue, Aug 13, 2013 at 10:35 AM, Tom Cooksey wrote: >> > > > 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

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

On Tue, Aug 13, 2013 at 10:35 AM, Tom Cooksey wrote: >> > > > 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

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

2013/8/8 Daniel Vetter > Just comment a bit on Rob's review with my own opinion. > > On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote: > > On Thu, Jul 25, 2013 at 1:17 PM, wrote: > > > From: Tom Cooksey > > > > > > This is a mode-setting driver for the pl111 CLCD display controller >

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

On Fri, Aug 9, 2013 at 1:31 PM, Tom Cooksey wrote: >> > > 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

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

On Fri, Aug 9, 2013 at 1:31 PM, Tom Cooksey wrote: >> > > 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

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

2013/8/8 Daniel Vetter > Just comment a bit on Rob's review with my own opinion. > > On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote: > > On Thu, Jul 25, 2013 at 1:17 PM, wrote: > > > From: Tom Cooksey > > > > > > This is a mode-setting driver for the pl111 CLCD display controller >

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

On Fri, Aug 09, 2013 at 12:34:55PM -0400, Rob Clark wrote: > On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote: > >> > fwiw, this is at least different from how other drivers do triple > >> > (or > double) buffering. In other drivers (intel, omap, and > >> > msm/freedreno, that I know of, maybe

[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 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 1/1] drm/pl111: Initial drm/kms driver for pl111

On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote: > 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

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 1/1] drm/pl111: Initial drm/kms driver for pl111

On Fri, Aug 09, 2013 at 12:34:55PM -0400, Rob Clark wrote: > On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote: > >> > fwiw, this is at least different from how other drivers do triple > >> > (or > double) buffering. In other drivers (intel, omap, and > >> > msm/freedreno, that I know of, maybe

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

On Fri, Aug 9, 2013 at 12:15 PM, Tom Cooksey wrote: > 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

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 1/1] drm/pl111: Initial drm/kms driver for pl111

Just comment a bit on Rob's review with my own opinion. On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote: > On Thu, Jul 25, 2013 at 1:17 PM, wrote: > > From: Tom Cooksey > > > > This is a mode-setting driver for the pl111 CLCD display controller > > found on various ARM reference platf

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

On Thu, Jul 25, 2013 at 1:17 PM, wrote: > From: Tom Cooksey > > This is a mode-setting driver for the pl111 CLCD display controller > found on various ARM reference platforms such as the Versatile > Express. The driver supports setting of a single mode (640x480) and > has only been tested on Ver

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

Just comment a bit on Rob's review with my own opinion. On Wed, Aug 07, 2013 at 12:17:21PM -0400, Rob Clark wrote: > On Thu, Jul 25, 2013 at 1:17 PM, wrote: > > From: Tom Cooksey > > > > This is a mode-setting driver for the pl111 CLCD display controller > > found on various ARM reference platf

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

From: Tom Cooksey This is a mode-setting driver for the pl111 CLCD display controller found on various ARM reference platforms such as the Versatile Express. The driver supports setting of a single mode (640x480) and has only been tested on Versatile Express with a Cortex-A9 core tile. Known iss