On Thu, Jan 21, 2021 at 5:36 PM Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > Only planes' prepare_fb and cleanup_fb, and encoders' atomic_check and > atomic_mode_set hooks remain with an object state and not the global > drm_atomic_state. > > prepare_fb and cleanup_fb operate by design on a given state and > depending on the calling site can operate on either the old or new > state, so it doesn't really make much sense to convert them. > > The encoders' atomic_check and atomic_mode_set operate on the CRTC and > connector state connected to them since encoders don't have a state of > their own. Without those state pointers, we would need to get the CRTC > through the drm_connector_state crtc pointer. > > However, in order to get the drm_connector_state pointer, we would need > to get the connector itself and while usually we have a single connector > connected to the encoder, we can't really get it from the encoder at > the moment since it could be behind any number of bridges. > > While this could be addressed by (for example) listing all the > connectors and finding the one that has the encoder as its source, it > feels like an unnecessary rework for something that is slowly getting > replaced by bridges. > > Since all the users that matter have been converted, let's remove the > TODO item. > > Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx> Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > --- > > Changes from v1: > - New patch > --- > Documentation/gpu/todo.rst | 46 -------------------------------------- > 1 file changed, 46 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 009d8e6c7e3c..609794108f5a 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -440,52 +440,6 @@ Contact: Emil Velikov, respective driver maintainers > > Level: Intermediate > > -Plumb drm_atomic_state all over > -------------------------------- > - > -Currently various atomic functions take just a single or a handful of > -object states (eg. plane state). While that single object state can > -suffice for some simple cases, we often have to dig out additional > -object states for dealing with various dependencies between the individual > -objects or the hardware they represent. The process of digging out the > -additional states is rather non-intuitive and error prone. > - > -To fix that most functions should rather take the overall > -drm_atomic_state as one of their parameters. The other parameters > -would generally be the object(s) we mainly want to interact with. > - > -For example, instead of > - > -.. code-block:: c > - > - int (*atomic_check)(struct drm_plane *plane, struct drm_plane_state *state); > - > -we would have something like > - > -.. code-block:: c > - > - int (*atomic_check)(struct drm_plane *plane, struct drm_atomic_state *state); > - > -The implementation can then trivially gain access to any required object > -state(s) via drm_atomic_get_plane_state(), drm_atomic_get_new_plane_state(), > -drm_atomic_get_old_plane_state(), and their equivalents for > -other object types. > - > -Additionally many drivers currently access the object->state pointer > -directly in their commit functions. That is not going to work if we > -eg. want to allow deeper commit pipelines as those pointers could > -then point to the states corresponding to a future commit instead of > -the current commit we're trying to process. Also non-blocking commits > -execute locklessly so there are serious concerns with dereferencing > -the object->state pointers without holding the locks that protect them. > -Use of drm_atomic_get_new_plane_state(), drm_atomic_get_old_plane_state(), > -etc. avoids these problems as well since they relate to a specific > -commit via the passed in drm_atomic_state. > - > -Contact: Ville Syrjälä, Daniel Vetter > - > -Level: Intermediate > - > Use struct dma_buf_map throughout codebase > ------------------------------------------ > > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
