[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 Intel-gfx
mailing list