In the process of getting kms fence fd (and related gpu egl fence fd extension) working with real hardware (using android drm-hwc) I found a lot of issues w/ plane support. Perhaps that is to be expected the first time getting a userspace that actually makes heavy use of overlay planes working. So some of the approaches here may be useful to other drivers when they cross that bridge. The mdp5 hw, in particular variants that have "SMP" (Shared Memory Pool, ie. shared FIFO blocks that are allocated to the various hw pipes) have a lot of constraints that a generic userspace is not aware of. Such as not being able to arbitrarily change scanout width or pixel format on an active pipe. In addition, not all pipes can support all features (YUV, rotation, and in some cases, scaling). Additionally, during the initial conversion to atomic, we did not handle SMP block allocation in plane->atomic_check(), leading to cases where an update could fail in plane->atomic_update() due to failure to allocate SMP blocks. To solve this: (1) dynamically assign hw pipes to planes at ->atomic_check() based on the required plane capabilities (2) handle SMP block allocation in ->atomic_check(). When SMP block allocation needs to change, re-assign a new hw pipe To do this, we need to track the SMP block allocation, and hw pipe assignment in a global atomic state object. This way, we ensure that multiple updates from different threads which touch shared state (the hw pipe assignemnt or SMP block allocation) are properly serialized (via state_lock), and atomic test-only updates, or commits that fail in atomic_check() (or deadlock/backoff scenarios) are properly un- wound by simply throwing away the new state objects. The global state is handled in the same way as plane/crtc/etc state. On mdp5_get_state(), the state_lock is acquired as part of the atomic acquire_ctx, and the current state is copied. At that point changes to the copied state are permitted. New plane state can reference new hw pipes, since the assignment of hw pipes is tracked in the global state. At any point the new state can be thrown away (along with the various new plane state objects that reference it as part of the new drm_atomic_state). And if the new state is committed, the new global state is swapped with old state, in the same way per-plane/ crtc/connector state is handled, preserving consistency between global and per-plane state. Rob Clark (5): drm/msm/mdp5: introduce mdp5_hw_pipe drm/msm: subclass drm_atomic_state drm/msm/mdp5: add skeletal mdp5_state drm/msm/mdp5: dynamically assign hw pipes to planes drm/msm/mdp5: handle SMP block allocations "atomically" drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 180 +++++++++++++++----- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 33 +++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c | 132 +++++++++++++++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.h | 54 ++++++ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 202 +++++++++------------- drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 270 ++++++++++-------------------- drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h | 66 ++++++-- drivers/gpu/drm/msm/msm_atomic.c | 31 ++++ drivers/gpu/drm/msm/msm_drv.c | 3 + drivers/gpu/drm/msm/msm_drv.h | 3 + drivers/gpu/drm/msm/msm_kms.h | 14 ++ 13 files changed, 629 insertions(+), 362 deletions(-) create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.h -- 2.7.4 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel