[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-08 Thread Tomi Valkeinen
On 03/09/14 17:25, Daniel Vetter wrote: > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: >> Currently modesetting is not done synchronously, but it queues work that >> is done later. In theory this is fine, but the driver doesn't handle it >> at properly. This means that if an appl

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-08 Thread Daniel Vetter
On Mon, Sep 08, 2014 at 09:39:40AM -0400, Rob Clark wrote: > On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter wrote: > > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote: > >> On 03/09/14 17:25, Daniel Vetter wrote: > >> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote:

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-08 Thread Daniel Vetter
On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote: > On 03/09/14 17:25, Daniel Vetter wrote: > > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: > >> Currently modesetting is not done synchronously, but it queues work that > >> is done later. In theory this is fine, but

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-08 Thread Rob Clark
On Mon, Sep 8, 2014 at 9:50 AM, Daniel Vetter wrote: > On Mon, Sep 08, 2014 at 09:39:40AM -0400, Rob Clark wrote: >> On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter wrote: >> > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote: >> >> On 03/09/14 17:25, Daniel Vetter wrote: >> >> > On W

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-08 Thread Rob Clark
On Mon, Sep 8, 2014 at 9:24 AM, Daniel Vetter wrote: > On Mon, Sep 08, 2014 at 03:53:18PM +0300, Tomi Valkeinen wrote: >> On 03/09/14 17:25, Daniel Vetter wrote: >> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: >> >> Currently modesetting is not done synchronously, but it queue

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-03 Thread Daniel Vetter
On Wed, Sep 3, 2014 at 6:00 PM, Rob Clark wrote: > so, I am not quite sure that would work.. (and maybe this is an extra > thing to think about for atomic). > > The problem is that hw has no hw cursor. So cursor is implemented > using plane. But thanks to retarded userspace that rapidly > enabl

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-03 Thread Daniel Vetter
On Wed, Sep 03, 2014 at 11:05:08AM -0400, Rob Clark wrote: > On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter wrote: > > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: > >> Currently modesetting is not done synchronously, but it queues work that > >> is done later. In theory this is

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-03 Thread Daniel Vetter
On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: > Currently modesetting is not done synchronously, but it queues work that > is done later. In theory this is fine, but the driver doesn't handle it > at properly. This means that if an application first does a full > modeset, then imm

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-03 Thread Tomi Valkeinen
Currently modesetting is not done synchronously, but it queues work that is done later. In theory this is fine, but the driver doesn't handle it at properly. This means that if an application first does a full modeset, then immediately afterwards starts page flipping, the page flipping will not wor

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-03 Thread Rob Clark
On Wed, Sep 3, 2014 at 11:21 AM, Daniel Vetter wrote: > On Wed, Sep 03, 2014 at 11:05:08AM -0400, Rob Clark wrote: >> On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter wrote: >> > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: >> >> Currently modesetting is not done synchronously, b

[PATCH 4/9] drm/omap: make modesetting synchronous

2014-09-03 Thread Rob Clark
On Wed, Sep 3, 2014 at 10:25 AM, Daniel Vetter wrote: > On Wed, Sep 03, 2014 at 02:55:05PM +0300, Tomi Valkeinen wrote: >> Currently modesetting is not done synchronously, but it queues work that >> is done later. In theory this is fine, but the driver doesn't handle it >> at properly. This means