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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
