Commit Graph

3 Commits

Author SHA1 Message Date
Rob Clark
49ec5b2e5a drm/msm/mdp5: handle SMP block allocations "atomically"
Previously, SMP block allocation was not checked in the plane's
atomic_check() fxn, so we could fail allocation SMP block allocation at
atomic_update() time.  Re-work the block allocation to request blocks
during atomic_check(), but not update the hw until committing the atomic
update.

Since SMP blocks allocated at atomic_check() time, we need to manage the
SMP state as part of mdp5_state (global atomic state).  This actually
ends up significantly simplifying the SMP management, as the SMP module
does not need to manage the intermediate state between assigning new
blocks before setting flush bits and releasing old blocks after vblank.
(The SMP registers and SMP allocation is not double-buffered, so newly
allocated blocks need to be updated in kms->prepare_commit() released
blocks in kms->complete_commit().)

Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-27 11:32:34 -05:00
Rob Clark
4a0f012da3 drm/msm/mdp5: dynamically assign hw pipes to planes
(re)assign the hw pipes to planes based on required caps, and to handle
situations where we could not modify an in-use plane (ie. SMP block
reallocation).

This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as not all planes may be available for use on every frame.

The mapping of hwpipe to plane is stored in mdp5_state, so that state
updates are atomically committed in the same way that plane/etc state
updates are managed.  This is needed because the mdp5_plane_state keeps
a pointer to the hwpipe, and we don't want global state to become out
of sync with the plane state if an atomic update fails, we hit deadlock/
backoff scenario, etc.  The use of state_lock keeps multiple parallel
updates which both re-assign hwpipes properly serialized.

Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-27 11:32:33 -05:00
Rob Clark
c056b55dc6 drm/msm/mdp5: introduce mdp5_hw_pipe
Split out the hardware pipe specifics from mdp5_plane.  To start, the hw
pipes are statically assigned to planes, but next step is to assign the
hw pipes during plane->atomic_check() based on requested caps (scaling,
YUV, etc).  And then hw pipe re-assignment if required if required SMP
blocks changes.

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
2016-11-27 11:32:20 -05:00