Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-05-02 Thread Daniel Stone
Hi, On 2 May 2017 at 09:10, Daniel Vetter wrote: > On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote: >> Do you know which hw would that be? I don't know. Maybe we should just >> don't care for now and see how drivers will solve this to then extract >> helpers like we did for atomic

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-05-02 Thread Daniel Vetter
On Fri, Apr 21, 2017 at 03:41:10PM -0300, Gustavo Padovan wrote: > 2017-04-11 Daniel Vetter : > > > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > > > Gustavo Padovan writes: > > > > > > > From: Gustavo Padovan > > Some async cursor updates are not 100% async, as in the hw might

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-21 Thread Gustavo Padovan
2017-04-11 Daniel Vetter : > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > > Gustavo Padovan writes: > > > > > From: Gustavo Padovan > > > > > > In some cases, like cursor updates, it is interesting to update the > > > plane in an asynchronous fashion to avoid big delays. > > >

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-12 Thread Gustavo Padovan
2017-04-11 Daniel Vetter : > On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > > Gustavo Padovan writes: > > > > > From: Gustavo Padovan > > > > > > In some cases, like cursor updates, it is interesting to update the > > > plane in an asynchronous fashion to avoid big delays. > > >

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-11 Thread Daniel Vetter
On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > Gustavo Padovan writes: > > > From: Gustavo Padovan > > > > In some cases, like cursor updates, it is interesting to update the > > plane in an asynchronous fashion to avoid big delays. > > > > The current queued update could be stil

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-10 Thread Eric Anholt
Gustavo Padovan writes: > From: Gustavo Padovan > > In some cases, like cursor updates, it is interesting to update the > plane in an asynchronous fashion to avoid big delays. > > The current queued update could be still waiting for a fence to signal and > thus block and subsequent update until

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-10 Thread Gustavo Padovan
Hi Emil, Thank you for your review! 2017-04-10 Emil Velikov : > Hi Gustavo, > > Mostly some documentation suggestions below. Hope that I've not lost > the plot and they seem ok :-) > > On 10 April 2017 at 01:24, Gustavo Padovan wrote: > > > +static bool drm_atomic_async_check(struct drm_atom

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-10 Thread Emil Velikov
Hi Gustavo, Mostly some documentation suggestions below. Hope that I've not lost the plot and they seem ok :-) On 10 April 2017 at 01:24, Gustavo Padovan wrote: > +static bool drm_atomic_async_check(struct drm_atomic_state *state) > +{ /* FIXME: we support single plane updates for now */ > +

[RFC 1/7] drm/atomic: initial support for asynchronous plane update

2017-04-09 Thread Gustavo Padovan
From: Gustavo Padovan In some cases, like cursor updates, it is interesting to update the plane in an asynchronous fashion to avoid big delays. The current queued update could be still waiting for a fence to signal and thus block and subsequent update until its scan out. In cases like this if we