UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c

179 lines
4.7 KiB
C
Raw Normal View History

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-01 21:56:51 +08:00
/*
* Copyright (C) 2016 Red Hat
* Author: Rob Clark <robdclark@gmail.com>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
* the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "mdp5_kms.h"
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
int mdp5_pipe_assign(struct drm_atomic_state *s, struct drm_plane *plane,
uint32_t caps, uint32_t blkcfg,
drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:30 +08:00
struct mdp5_hw_pipe **hwpipe,
struct mdp5_hw_pipe **r_hwpipe)
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-01 23:56:54 +08:00
{
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
drm/msm/mdp5: Use the new private_obj state This replaces the usage of the subclassed atomic state (mdp5_state) with a private_obj state embedded within drm_atomic_state. The latter method is the preferred approach, since it's simpler to implement and less prone to errors. The new API replaces the older and equivalent mdp5_state usage in the following pattern: - References to "mdp5_kms->state" (i.e, the old/existing state) is replaced with mdp5_get_existing_global_state(). In the atomic_check path, this should be called with the glob_state_lock drm_modeset_lock alredy taken. - References to "mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Changes in v3: - Acquire glob_state_lock in mdp5_smp.c - Added to the msm atomic helper patch set Changes in v4: - None Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-02-21 22:37:23 +08:00
struct mdp5_global_state *new_global_state, *old_global_state;
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-01 23:56:54 +08:00
struct mdp5_hw_pipe_state *old_state, *new_state;
drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:30 +08:00
int i, j;
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-01 23:56:54 +08:00
drm/msm/mdp5: Use the new private_obj state This replaces the usage of the subclassed atomic state (mdp5_state) with a private_obj state embedded within drm_atomic_state. The latter method is the preferred approach, since it's simpler to implement and less prone to errors. The new API replaces the older and equivalent mdp5_state usage in the following pattern: - References to "mdp5_kms->state" (i.e, the old/existing state) is replaced with mdp5_get_existing_global_state(). In the atomic_check path, this should be called with the glob_state_lock drm_modeset_lock alredy taken. - References to "mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Changes in v3: - Acquire glob_state_lock in mdp5_smp.c - Added to the msm atomic helper patch set Changes in v4: - None Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-02-21 22:37:23 +08:00
new_global_state = mdp5_get_global_state(s);
if (IS_ERR(new_global_state))
return PTR_ERR(new_global_state);
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-01 23:56:54 +08:00
drm/msm/mdp5: Use the new private_obj state This replaces the usage of the subclassed atomic state (mdp5_state) with a private_obj state embedded within drm_atomic_state. The latter method is the preferred approach, since it's simpler to implement and less prone to errors. The new API replaces the older and equivalent mdp5_state usage in the following pattern: - References to "mdp5_kms->state" (i.e, the old/existing state) is replaced with mdp5_get_existing_global_state(). In the atomic_check path, this should be called with the glob_state_lock drm_modeset_lock alredy taken. - References to "mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Changes in v3: - Acquire glob_state_lock in mdp5_smp.c - Added to the msm atomic helper patch set Changes in v4: - None Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-02-21 22:37:23 +08:00
/* grab old_state after mdp5_get_global_state(), since now we hold lock: */
old_global_state = mdp5_get_existing_global_state(mdp5_kms);
old_state = &old_global_state->hwpipe;
new_state = &new_global_state->hwpipe;
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-01 23:56:54 +08:00
for (i = 0; i < mdp5_kms->num_hwpipes; i++) {
struct mdp5_hw_pipe *cur = mdp5_kms->hwpipes[i];
/* skip if already in-use.. check both new and old state,
* since we cannot immediately re-use a pipe that is
* released in the current update in some cases:
* (1) mdp5 can have SMP (non-double-buffered)
* (2) hw pipe previously assigned to different CRTC
* (vblanks might not be aligned)
*/
if (new_state->hwpipe_to_plane[cur->idx] ||
old_state->hwpipe_to_plane[cur->idx])
continue;
/* skip if doesn't support some required caps: */
if (caps & ~cur->caps)
continue;
drm/msm/mdp5: Misc cursor plane bits These are various changes added in preparation for cursor planes: - Add a pipe_cursor block for 8x96 in mdp5_cfg. - Add a new pipe CAP called MDP_PIPE_CAP_CURSOR. Use this to ensure we assign a cursor SSPP for a drm_plane with type DRM_PLANE_TYPE_CURSOR. - Update mdp5_ctl_blend_mask/ext_blend_mask funcs to incorporate cursor SSPPs. - In mdp5_ctl_blend, iterate through MAX_STAGES instead of stage_cnt, we need to do this because we can now have empty stages in between. - In mdp5_crtc_atomic_check, make sure that the cursor plane has the highest zorder, and stage the cursor plane to the maximum stage # present on the HW. - Create drm_crtc_funcs that doesn't try to implement cursors using the older LM cursor HW. - Pass drm_plane_type in mdp5_plane_init instead of a bool telling whether plane is primary or not. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-01-16 14:27:04 +08:00
/*
* don't assign a cursor pipe to a plane that isn't going to
* be used as a cursor
*/
if (cur->caps & MDP_PIPE_CAP_CURSOR &&
plane->type != DRM_PLANE_TYPE_CURSOR)
continue;
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-01 23:56:54 +08:00
/* possible candidate, take the one with the
* fewest unneeded caps bits set:
*/
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
if (!(*hwpipe) || (hweight_long(cur->caps & ~caps) <
drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:30 +08:00
hweight_long((*hwpipe)->caps & ~caps))) {
bool r_found = false;
if (r_hwpipe) {
for (j = i + 1; j < mdp5_kms->num_hwpipes;
j++) {
struct mdp5_hw_pipe *r_cur =
mdp5_kms->hwpipes[j];
/* reject different types of hwpipes */
if (r_cur->caps != cur->caps)
continue;
/* respect priority, eg. VIG0 > VIG1 */
if (cur->pipe > r_cur->pipe)
continue;
*r_hwpipe = r_cur;
r_found = true;
break;
}
}
if (!r_hwpipe || r_found)
*hwpipe = cur;
}
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-01 23:56:54 +08:00
}
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
if (!(*hwpipe))
return -ENOMEM;
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-01 23:56:54 +08:00
drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:30 +08:00
if (r_hwpipe && !(*r_hwpipe))
return -ENOMEM;
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-02 04:35:32 +08:00
if (mdp5_kms->smp) {
int ret;
drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:30 +08:00
/* We don't support SMP and 2 hwpipes/plane together */
WARN_ON(r_hwpipe);
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
DBG("%s: alloc SMP blocks", (*hwpipe)->name);
drm/msm/mdp5: Use the new private_obj state This replaces the usage of the subclassed atomic state (mdp5_state) with a private_obj state embedded within drm_atomic_state. The latter method is the preferred approach, since it's simpler to implement and less prone to errors. The new API replaces the older and equivalent mdp5_state usage in the following pattern: - References to "mdp5_kms->state" (i.e, the old/existing state) is replaced with mdp5_get_existing_global_state(). In the atomic_check path, this should be called with the glob_state_lock drm_modeset_lock alredy taken. - References to "mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Changes in v3: - Acquire glob_state_lock in mdp5_smp.c - Added to the msm atomic helper patch set Changes in v4: - None Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-02-21 22:37:23 +08:00
ret = mdp5_smp_assign(mdp5_kms->smp, &new_global_state->smp,
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
(*hwpipe)->pipe, blkcfg);
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-02 04:35:32 +08:00
if (ret)
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
return -ENOMEM;
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-02 04:35:32 +08:00
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
(*hwpipe)->blkcfg = blkcfg;
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-02 04:35:32 +08:00
}
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-01 23:56:54 +08:00
DBG("%s: assign to plane %s for caps %x",
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
(*hwpipe)->name, plane->name, caps);
new_state->hwpipe_to_plane[(*hwpipe)->idx] = plane;
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-01 23:56:54 +08:00
drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planes We currently call mdp5_pipe_assign() twice to assign the left and right hwpipes for our drm_plane. When merging 2 hwpipes, there are a few constraints that we need to keep in mind: - Only the same types of SSPPs are preferred. I.e, a RGB pipe should be paired with another RGB pipe, VIG with VIG etc. - The hwpipe staged on the left should have a higher priority than the hwpipe staged on the right. The priorities are as follows: VIG0 > VIG1 > VIG2 > VIG3 RGB0 > RGB1 > RGB2 > RGB3 DMA0 > DMA1 We can't apply these constraints easily if mdp5_pipe_assign() is called twice. Update mdp5_pipe_assign() to find both hwpipes in one go, and add the extra constraints needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:30 +08:00
if (r_hwpipe) {
DBG("%s: assign to right of plane %s for caps %x",
(*r_hwpipe)->name, plane->name, caps);
new_state->hwpipe_to_plane[(*r_hwpipe)->idx] = plane;
}
drm/msm/mdp5: Prepare mdp5_pipe_assign for some rework mdp5_pipe_assign currently returns the hwpipe pointer for the drm_plane. Return it indirectly by setting a pointer passed as an argument. This is needed because we want the func to find out the right hwpipe too. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-27 18:57:29 +08:00
return 0;
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-01 23:56:54 +08:00
}
void mdp5_pipe_release(struct drm_atomic_state *s, struct mdp5_hw_pipe *hwpipe)
{
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-02 04:35:32 +08:00
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
drm/msm/mdp5: Use the new private_obj state This replaces the usage of the subclassed atomic state (mdp5_state) with a private_obj state embedded within drm_atomic_state. The latter method is the preferred approach, since it's simpler to implement and less prone to errors. The new API replaces the older and equivalent mdp5_state usage in the following pattern: - References to "mdp5_kms->state" (i.e, the old/existing state) is replaced with mdp5_get_existing_global_state(). In the atomic_check path, this should be called with the glob_state_lock drm_modeset_lock alredy taken. - References to "mdp5_get_state()" are replaced with mdp5_get_global_state(). This acquires glob_state_lock and uses drm_atomic_get_private_obj_state() to create a new duplicated state. Changes in v3: - Acquire glob_state_lock in mdp5_smp.c - Added to the msm atomic helper patch set Changes in v4: - None Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org>
2018-02-21 22:37:23 +08:00
struct mdp5_global_state *state = mdp5_get_global_state(s);
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-01 23:56:54 +08:00
struct mdp5_hw_pipe_state *new_state = &state->hwpipe;
if (!hwpipe)
return;
if (WARN_ON(!new_state->hwpipe_to_plane[hwpipe->idx]))
return;
DBG("%s: release from plane %s", hwpipe->name,
new_state->hwpipe_to_plane[hwpipe->idx]->name);
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-02 04:35:32 +08:00
if (mdp5_kms->smp) {
DBG("%s: free SMP blocks", hwpipe->name);
mdp5_smp_release(mdp5_kms->smp, &state->smp, hwpipe->pipe);
}
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-01 23:56:54 +08:00
new_state->hwpipe_to_plane[hwpipe->idx] = NULL;
}
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-01 21:56:51 +08:00
void mdp5_pipe_destroy(struct mdp5_hw_pipe *hwpipe)
{
kfree(hwpipe);
}
struct mdp5_hw_pipe *mdp5_pipe_init(enum mdp5_pipe pipe,
uint32_t reg_offset, uint32_t caps)
{
struct mdp5_hw_pipe *hwpipe;
hwpipe = kzalloc(sizeof(*hwpipe), GFP_KERNEL);
if (!hwpipe)
return ERR_PTR(-ENOMEM);
hwpipe->name = pipe2name(pipe);
hwpipe->pipe = pipe;
hwpipe->reg_offset = reg_offset;
hwpipe->caps = caps;
hwpipe->flush_mask = mdp_ctl_flush_mask_pipe(pipe);
return hwpipe;
}