[Intel-gfx] [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state.

Daniel Vetter daniel at ffwll.ch
Mon Jan 23 08:50:52 UTC 2017


On Tue, Jan 17, 2017 at 02:45:32AM +0200, Laurent Pinchart wrote:
> Hi Maarten,
> 
> Thank you for the patches.
> 
> On Monday 16 Jan 2017 10:37:37 Maarten Lankhorst wrote:
> > Fourth iteration. Instead of trying to convert all drivers straight away,
> > implement all macros that are required to get state working.
> > 
> > Old situation:
> > Use obj->state, which can refer to old or new state.
> > Use drm_atomic_get_(existing_)obj_state, which can refer to new or old
> > state. Use for_each_obj_in_state, which refers to new or old state.
> > 
> > New situation:
> > 
> > During atomic check:
> > - Use drm_atomic_get_obj_state to add a object to the atomic state,
> >   or get the new state.
> > - Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state,
> >   without adding the object. This will return NULL if the object is
> >   not part of the state. For planes and connectors the relevant crtc_state
> >   is added, so this will work to get the crtc_state from obj_state->crtc
> >   too, this means not having to write some error handling.
> > 
> > During atomic commit:
> > - Do not use drm_atomic_get_obj_state, obj->state or
> > drm_atomic_get_(existing_)obj_state any more, replace with
> > drm_atomic_get_old/new_obj_state calls as required.
> 
> That will make driver code quite complicated :-/ I wonder if that's really a 
> good solution. Maybe we should maintain obj->state only for the duration of 
> the commit as a way to simplify drivers, and set it to NULL at all other times 
> to avoid misusing it ? I know this contradicts the comment I've made in my 
> review of patch 1/7, you can now choose which one to ignore :-)

We still need a state pointer to track the current logical state all the
time (ignoring nonblocking commits or other async magic). We might do that
in obj->_state or something to discourage use, but it needs to be there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list