summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
AgeCommit message (Collapse)Author
2018-03-19drm/msm: rename mdp->dispRob Clark
Since new display controller is called "dpu" instead of "mdp". Lets make the name of the toplevel directory for the display controllers a bit more generic. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org>
2018-01-23drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangleVille Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-10-ville.syrjala@linux.intel.com Reviewed-by: Archit Taneja <architt@codeaurora.org> Reviewed-by: Thierry Reding <treding@nvidia.com>
2017-12-13drm/msm: avoid false-positive -Wmaybe-uninitialized warningArnd Bergmann
gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning: drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_mode_set.isra.8': drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:1053:3: error: 'crtc_x_r' may be used uninitialized in this function [-Werror=maybe-uninitialized] It's relatively clear from reading the source that this cannot happen, and older compilers get it right. This rearranges the code remove the two affected variables, which reliably avoids the problem. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-11-21Merge airlied/drm-next into drm-misc-nextDaniel Vetter
Bake in the conflict between the drm_print.h extraction and the addition of DRM_DEBUG_LEASES since we lost it a few too many times. Also fix a new use of drm_plane_helper_check_state in msm to follow Ville's conversion in commit a01cb8ba3f6282934cff65e89ab36b18b14cbe27 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 1 22:16:19 2017 +0200 drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-11-20drm: Move drm_plane_helper_check_state() into drm_atomic_helper.cVille Syrjälä
drm_plane_helper_check_update() isn't a transitional helper, so let's rename it to drm_atomic_helper_check_plane_state() and move it into drm_atomic_helper.c. v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc Cc: Daniel Vetter <daniel@ffwll.ch> Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171101201619.6175-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-11-20drm: Check crtc_state->enable rather than crtc->enabled in ↵Ville Syrjälä
drm_plane_helper_check_state() drm_plane_helper_check_state() is supposed to do things the atomic way, so it should not be inspecting crtc->enabled. Rather we should be looking at crtc_state->enable. We have a slight complication due to drm_plane_helper_check_update() reusing drm_plane_helper_check_state() for non-atomic drivers. Thus we'll have to pass the crtc_state in manally and construct a fake crtc_state in drm_plane_helper_check_update(). v2: Fix the WARNs about plane_state->crtc matching crtc_state->crtc Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171101201558.6059-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-10-28drm/msm/mdp5: Don't use async plane update path if plane visibility changesArchit Taneja
When a plane moves out of bounds (i.e, outside the crtc clip region), the plane state's "visible" parameter changes to false. When this happens, we (a) release the hwpipe resources away from it, and (b) unstage the corresponding hwpipe(s) from the Layer Mixers in the CRTC. (a) requires use to acquire the global atomic state and assign a new hwpipe. (b) requires us to re-configure the Layer Mixer, which is done in the CRTC. We don't want to do these things in the async plane update path, so return an error if the new state's "visible" isn't the same as the current state's "visible". Cc: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-28drm/msm/mdp5: Update mdp5_pipe_assign to spit out both planesArchit Taneja
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-28drm/msm/mdp5: Prepare mdp5_pipe_assign for some reworkArchit Taneja
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-28drm/msm: remove mdp5_cursor_plane_funcsGustavo Padovan
After converting legacy cursor updates to atomic async commits mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now. Cc: Rob Clark <robdclark@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Tested-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-10-28drm/msm: update cursors asynchronously through atomicGustavo Padovan
Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what mdp5_update_cursor_plane_legacy() did but through atomic. v5: call drm_atomic_helper_async_check() from the check hook v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja) v3: move size checks back to drivers (Ville Syrjälä) v2: move fb setting to core and use new state (Eric Anholt) Cc: Rob Clark <robdclark@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> Tested-by: Archit Taneja <architt@codeaurora.org> (v4) [added comment about not hitting async update path if hwpipes are re-assigned or global state is touched] Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-08-15Backmerge tag 'v4.13-rc5' into drm-nextDave Airlie
Linux 4.13-rc5 There's a really nasty nouveau collision, hopefully someone can take a look once I pushed this out.
2017-08-08drm: Nuke drm_atomic_helper_plane_set_propertyDaniel Vetter
It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_plane_set_property. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Eric Engestrom <eric@engestrom.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rob Clark <robdclark@gmail.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170725080122.20548-6-daniel.vetter@ffwll.ch Reviewed-by: Archit Taneja <architt@codeaurora.org> Acked-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Philippe Cornu <philippe.cornu@st.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Vincent Abriou <vincent.abriou@st.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2017-08-01drm/msm/mdp5: Fix compilation warningsViresh Kumar
Following compilation warnings were observed for these files: CC [M] drivers/gpu/drm/msm/mdp/mdp5/mdp5_mdss.o drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c: In function 'blend_setup': drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: missing braces around initializer [-Wmissing-braces] enum mdp5_pipe stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:223:7: warning: (near initialization for 'stage[0]') [-Wmissing-braces] drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: missing braces around initializer [-Wmissing-braces] enum mdp5_pipe r_stage[STAGE_MAX + 1][MAX_PIPE_STAGE] = { SSPP_NONE }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c:224:7: warning: (near initialization for 'r_stage[0]') [-Wmissing-braces] drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function 'mdp5_plane_mode_set': drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: missing braces around initializer [-Wmissing-braces] struct phase_step step = { 0 }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:892:9: warning: (near initialization for 'step.x') [-Wmissing-braces] drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: missing braces around initializer [-Wmissing-braces] struct pixel_ext pe = { 0 }; ^ drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:893:9: warning: (near initialization for 'pe.left') [-Wmissing-braces] This happens because in the first case we were initializing a two dimensional array with {0} and in the second case we were initializing a struct containing two arrays with {0}. Fix them by adding another pair of {}. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-08-01drm: Plumb modifiers through plane initBen Widawsky
This is the plumbing for supporting fb modifiers on planes. Modifiers have already been introduced to some extent, but this series will extend this to allow querying modifiers per plane. Based on this, the client to enable optimal modifications for framebuffers. This patch simply allows the DRM drivers to initialize their list of supported modifiers upon initializing the plane. v2: A minor addition from Daniel v3: * Updated commit message * s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu) * Remove some excess newlines (Liviu) * Update comment for > 64 modifiers (Liviu) v4: Minor comment adjustments (Liviu) v5: Some new platforms added due to rebase v6: Add some missed plane inits (or maybe they're new - who knows at this point) (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Daniel Stone <daniels@collabora.com> (v2) Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-06-16drm/msm: pass address-space to _get_iova() and friendsRob Clark
No functional change, that will come later. But this will make it easier to deal with dynamically created address spaces (ie. per- process pagetables for gpu). Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-06-16drm/msm/mdp4+5: move aspace/id to base classRob Clark
Before we can shift to passing the address-space object to _get_iova(), we need to fix a few places (dsi+fbdev) that were hard-coding the adress space id. That gets somewhat easier if we just move these to the kms base class. Prep work for next patch. Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-06-16drm/msm/mdp5: kill pipe_lockRob Clark
It serves no purpose, things should be sufficiently synchronized already by atomic framework. And it is somewhat awkward to be holding a spinlock when msm_gem_iova() is going to start needing to grab a mutex. Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-06-16BackMerge tag 'v4.12-rc5' into drm-nextDave Airlie
Linux 4.12-rc5 for nouveau fixes
2017-05-27drm/msm/mdp5: release hwpipe(s) for unused planesRob Clark
Otherwise, if userspace doesn't re-use a given plane, it's hwpipe(s) could stay permanently assigned. Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-05-27drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()Rob Clark
Somehow the helper was never retrofitted for mdp5. Which meant when plane_state->fence was added, it could get copied into new state in mdp5_plane_duplicate_state(). If an update to disable the plane (for example on rmfb) managed to sneak in after an nonblock update had swapped state, but before it was committed, we'd get a splat: WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 drm_atomic_helper_wait_for_fences+0xe0/0xf8 Modules linked in: CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: G W 4.11.0-rc8+ #1187 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Workqueue: events drm_mode_rmfb_work_fn task: ffffffc036560d00 task.stack: ffffffc036550000 PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8 LR is at complete_commit.isra.1+0x44/0x1c0 pc : [<ffffff80084f6040>] lr : [<ffffff800854176c>] pstate: 20000145 sp : ffffffc036553b60 x29: ffffffc036553b60 x28: ffffffc0264e6a00 x27: ffffffc035659000 x26: 0000000000000000 x25: ffffffc0240e8000 x24: 0000000000000038 x23: 0000000000000000 x22: ffffff800858f200 x21: ffffffc0240e8000 x20: ffffffc02f56a800 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: ffffffc00a192700 x13: 0000000000000004 x12: 0000000000000000 x11: ffffff80089a1690 x10: 00000000000008f0 x9 : ffffffc036553b20 x8 : ffffffc036561650 x7 : ffffffc03fe6cb40 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000002 x3 : ffffffc035659000 x2 : ffffffc0240e8c80 x1 : 0000000000000000 x0 : ffffffc02adbe588 ---[ end trace 13aeec77c3fb55e2 ]--- Call trace: Exception stack(0xffffffc036553990 to 0xffffffc036553ac0) 3980: 0000000000000000 0000008000000000 39a0: ffffffc036553b60 ffffff80084f6040 0000000000004ff0 0000000000000038 39c0: ffffffc0365539d0 ffffff800857e098 ffffffc036553a00 ffffff800857e1b0 39e0: ffffffc036553a10 ffffff800857c554 ffffffc0365e8400 ffffffc0365e8400 3a00: ffffffc036553a20 ffffff8008103358 000000000001aad7 ffffff800851b72c 3a20: ffffffc036553a50 ffffff80080e9228 ffffffc02adbe588 0000000000000000 3a40: ffffffc0240e8c80 ffffffc035659000 0000000000000002 0000000000000001 3a60: 0000000000000000 ffffffc03fe6cb40 ffffffc036561650 ffffffc036553b20 3a80: 00000000000008f0 ffffff80089a1690 0000000000000000 0000000000000004 3aa0: ffffffc00a192700 0000000000000000 0000000000000000 0000000000000000 [<ffffff80084f6040>] drm_atomic_helper_wait_for_fences+0xe0/0xf8 [<ffffff800854176c>] complete_commit.isra.1+0x44/0x1c0 [<ffffff8008541c64>] msm_atomic_commit+0x32c/0x350 [<ffffff8008516230>] drm_atomic_commit+0x50/0x60 [<ffffff8008517548>] drm_atomic_remove_fb+0x158/0x250 [<ffffff80085186d0>] drm_framebuffer_remove+0x50/0x158 [<ffffff8008518818>] drm_mode_rmfb_work_fn+0x40/0x58 [<ffffff80080d5668>] process_one_work+0x1d0/0x378 [<ffffff80080d5a54>] worker_thread+0x244/0x488 [<ffffff80080db7fc>] kthread+0xfc/0x128 [<ffffff8008082ec0>] ret_from_fork+0x10/0x50 Fixes: 9626014 ("drm/fence: add in-fences support") Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-05-22drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPIRobert Foss
Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Changes since v3: - Switched away from past tense in comments - Add define name change to previously mis-spelled DRM_REFLECT_X comment - Improved the comment for the DRM_MODE_REFLECT_<axis> comment Changes since v2: - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_ - Fix compilation errors - Changed comment formatting - Deduplicated comment lines - Clarified DRM_MODE_PROP_REFLECT_ comment Changes since v1: - Moved defines from drm.h to drm_mode.h - Changed define prefix from DRM_ to DRM_MODE_PROP_ - Updated uses of the defines to the new prefix - Removed include from drm_rect.c - Stopped using the BIT() macro Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
2017-04-08drm/msm/mdp5: Configure 'right' hwpipeArchit Taneja
Now that we have a right hwpipe in mdp5_plane_state, configure it mdp5_plane_mode_set(). The only parameters that vary between the left and right hwpipes are the src_w, src_img_w, src_x and crtc_x as we just even chop the fb into left and right halves. Add a mdp5_plane_right_pipe() which will be used by the crtc code to set up LM stages. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Assign a 'right hwpipe' to plane stateArchit Taneja
If the drm_plane has a source width that's greater than the max width supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe' to it in mdp5_plane_atomic_check(). TODO: There are a few scenarios where the hwpipe assignments aren't recommended by HW. For example, an assignment which results in a drm_plane to of two different types of hwpipes (say RGB0 on left and DMA1 on right) is not recommended. Also, hwpipes have a priority mapping, where the higher priority pipe needs to be staged on left LM, and the lower priority needs to be staged on the right LM. For example, the priority order for VIG pipes in decreasing order of priority is VIG0, VIG1, VIG2, and VIG3. So, VIG0 on left and VIG1 on right is a correct configuration, but VIG1 on left and VIG0 on right isn't. These scenarios are ignored for now for the sake of simplicity. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Create mdp5_hwpipe_mode_setArchit Taneja
Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter func takes in only the hwpipe and the parameters that need to be programmed into the hwpipe registers. All the code that calculates these parameters is left as is in mdp5_plane_mode_set. In the future, when we let drm_plane be comprised of 2 hwpipes, this func allow us to configure each pipe without adding redundant code. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctlArchit Taneja
These are a part of CRTC state, it doesn't feel nice to leave them hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead wherever it is needed. We still have some params in mdp5_ctl like start_mask etc which are derivative of atomic state, and should be rolled back if a commit fails, but it doesn't seem to cause much trouble. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Bring back pipe_lock to mdp5_plane structArchit Taneja
We'd previously moved the pipe_lock spinlock to the hwpipe struct. Bring it back to mdp5_plane. We will need this because an mdp5_plane in the future could comprise of 2 hw pipes. It makes more sense to have a single lock to protect the registers for the hw pipes used by a plane, rather than trying to take individual locks per hwpipe when committing a configuration. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-03-29drm: Add acquire ctx parameter to ->update_planeDaniel Vetter
Just rolling it out, no code change here. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Rob Clark <robdclark@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-3-daniel.vetter@ffwll.ch
2017-02-06drm/msm/mdp5: Add support for legacy cursor updatesArchit Taneja
This code has been more or less picked up from the vc4 and intel implementations of update_plane() funcs for cursor planes. The update_plane() func is usually the drm_atomic_helper_update_plane func that will issue an atomic commit with the plane updates. Such commits are not intended to be done faster than the vsync rate. The legacy cursor userspace API, on the other hand, expects the kernel to handle cursor updates immediately. Create a fast path in update_plane, which updates the cursor registers and flushes the configuration. The fast path is taken when there is only a change in the cursor's position in the crtc, or a change in the cursor's crop co-ordinates. For anything else, we go via the slow path. We take the slow path even when the fb changes, and when there is currently no fb tied to the plane. This should hopefully ensure that we always take a slow path for every new fb. This in turn should ensure that the fb is pinned/prepared. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-02-06drm/msm/mdp5: Refactor mdp5_plane_atomic_checkArchit Taneja
In mdp5_plane_atomic_check, we get crtc_state from drm_plane_state. Later, for cursor planes, we'll populate the update_plane() func that takes a fast asynchronous path to implement cursor movements. There, we would need to call a similar atomic_check func to validate the plane state, but crtc_state would need to be derived differently. Refactor mdp5_plane_atomic_check to mdp5_plane_atomic_check_with_state such that the latter takes crtc_state as an argument. This is similar to what the intel driver has done for async cursor updates. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-02-06drm/msm/mdp5: Misc cursor plane bitsArchit Taneja
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-02-06drm/msm/mdp5: Use plane helpers to configure src/dst rectanglesArchit Taneja
The MDP5 plane's atomic_check ops doesn't perform clipping tests. This didn't hurt us much in the past, but clipping becomes important with cursor planes. Use drm_plane_helper_check_state, the way rockchip/intel/mtk drivers already do. Use these drivers as reference. Clipping requires knowledge of the crtc width and height. This requires us to call drm_atomic_helper_check_modeset before drm_atomic_helper_check_planes in the driver's atomic_check op, because check_modetest will populate the mode for the crtc, needed to populate the clip rectangle. We update the plane_enabled(state) local helper to use state->visible, since state->visible and 'state->fb && state->crtc' represent the same thing. One issue with the existing code is that we don't have a way to disable the plane when it's completely clipped out. Until there isn't an update on the crtc (which would de-stage the plane), we would still see the plane in its last 'visible' configuration. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-02-06drm/msm/mdp5: Prepare CRTC/LM for empty stagesArchit Taneja
Use SSPP_NONE in mdp5_plane_pipe() if there is now hwpipe allocated for the drm_plane. Returning '0' means we are returning VIG0 pipe. Also, use the mdp5_pipe enum to pass around the stage array. Initialize the stage to SSPP_NONE by default. We do the above because 1) Cursor plane has to be staged at the topmost blender of the LM, which can result in empty stages in between 2) In the future, when we support multiple LMs per CRTC. We could have stages which don't have any pipe assigned to them. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-01-27Merge branch 'master' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Backmerge Linus master to get the connector locking revert. * 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux: (645 commits) sysctl: fix proc_doulongvec_ms_jiffies_minmax() Revert "drm/probe-helpers: Drop locking from poll_enable" MAINTAINERS: add Dan Streetman to zbud maintainers MAINTAINERS: add Dan Streetman to zswap maintainers mm: do not export ioremap_page_range symbol for external module mn10300: fix build error of missing fpu_save() romfs: use different way to generate fsid for BLOCK or MTD frv: add missing atomic64 operations mm, page_alloc: fix premature OOM when racing with cpuset mems update mm, page_alloc: move cpuset seqcount checking to slowpath mm, page_alloc: fix fast-path race with cpuset update or removal mm, page_alloc: fix check for NULL preferred_zone kernel/panic.c: add missing \n fbdev: color map copying bounds checking frv: add atomic64_add_unless() mm/mempolicy.c: do not put mempolicy before using its nodemask radix-tree: fix private list warnings Documentation/filesystems/proc.txt: add VmPin mm, memcg: do not retry precharge charges proc: add a schedule point in proc_pid_readdir() ...
2017-01-13drm/msm/mdp5: rip out plane->pending trackingRob Clark
It would race between userspace thread and commit worker. Ie. vblank irq would trigger event and userspace could begin the next atomic update, before the commit worker had a chance to clear the pending flag. If we do end up needing something to prevent userspace from trying another pageflip before getting vblank event, it should probably be implemented as a pending_planes bitmask, similar to pending_crtcs. See start_atomic() and end_atomic(). Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-12-15drm: Replace drm_format_num_planes() with fb->format->num_planesVille Syrjälä
Replace drm_format_num_planes(fb->pixel_format) with just fb->format->num_planes. Avoids the expensive format info lookup. @@ struct drm_framebuffer *a; struct drm_framebuffer b; @@ ( - drm_format_num_planes(a->pixel_format) + a->format->num_planes | - drm_format_num_planes(b.pixel_format) + b.format->num_planes ) @@ struct drm_plane_state *a; struct drm_plane_state b; @@ ( - drm_format_num_planes(a->fb->pixel_format) + a->fb->format->num_planes | - drm_format_num_planes(b.fb->pixel_format) + b.fb->format->num_planes ) @@ struct drm_framebuffer *a; identifier T; @@ T = a->pixel_format <+... - drm_format_num_planes(T) + a->format->num_planes ...+> @@ struct drm_framebuffer b; identifier T; @@ T = b.pixel_format <+... - drm_format_num_planes(T) + b.format->num_planes ...+> v2: Rerun spatch due to code changes Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481751022-18015-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-27drm/msm/mdp5: move LM bounds check into plane->atomic_check()Rob Clark
The mode_config->max_{width,height} is for the maximum size of a fb, not the max scanout limits (of the layer-mixer). It is legal, and in fact common, to create a larger fb, only only scan-out a smaller part of it. For example multi-monitor configurations for x11, or android wallpaper layer (which is created larger than the screen resolution for fast scrolling by just changing the src x/y coordinates). Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-27drm/msm/mdp5: handle SMP block allocations "atomically"Rob Clark
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-27drm/msm/mdp5: dynamically assign hw pipes to planesRob Clark
(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-27drm/msm/mdp5: introduce mdp5_hw_pipeRob Clark
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-27drm/msm/mdp5: rip out mode_changedRob Clark
It wasn't really doing the right thing if, for example, position or height changed. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-27drm/msm/mdp5: don't be so castyRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-27drm/msm/mdp5: drop mdp5_plane::nameRob Clark
Just use plane->name now that it is a thing. In a following patch, once we dynamically assign hw pipes to planes, it won't make sense to name planes the way we do, so this also partly reduces churn in following patch. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-27drm/msm/mdp5: nuke mdp5_plane_complete_flip()Rob Clark
We can do this all from mdp5_plane_complete_commit(), so simplify things a bit and drop mdp5_plane_complete_flip(). Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-26drm/msm/mdp5: clip img size to src sizeRob Clark
If fb dimensions are larger than what can be scanned out, but the src dimensions are not, the hw can still handle this. So clip. Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-26drm/msm/mdp5: no scaling support on RGBn pipes for 8x16Rob Clark
Looks like cut/paste error from the other device cfgs (which do support scaling on RGBn pipes). Signed-off-by: Rob Clark <robdclark@gmail.com>
2016-11-08drm/msm/mdp5: add atomic_print_state supportRob Clark
We subclass drm_plane_state, so add mdp5_plane_atomic_print_state() to dump out our own driver specific plane state. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1478358492-30738-7-git-send-email-robdclark@gmail.com
2016-10-22drm/msm/mdp5: Advertize 180 degree rotationVille Syrjälä
Since the hardware can apparently do both X and Y reflection, we can advertize also 180 degree rotation as thats just X+Y reflection. v2: Drop the BIT() Cc: Rob Clark <robdclark@gmail.com> Cc: Jilai Wang <jilaiw@codeaurora.org> Cc: Archit Taneja <architt@codeaurora.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-3-git-send-email-ville.syrjala@linux.intel.com
2016-10-22drm/msm/mdp5: Use per-plane rotation propertyVille Syrjälä
The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Rob Clark <robdclark@gmail.com> Cc: Jilai Wang <jilaiw@codeaurora.org> Cc: Archit Taneja <architt@codeaurora.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-2-git-send-email-ville.syrjala@linux.intel.com
2016-09-15drm/msm/mdp5: Set rotation property initial value to DRM_ROTATE_0 insted of 0Ville Syrjälä
0 isn't a valid rotation property value, so let's set the initial value of the property to DRM_ROTATE_0 instead. In the same vein, we must always have at leat one angle as part of set of supported rotation bits, so let's include DRM_ROTATE_0 in there. Cc: Rob Clark <robdclark@gmail.com> Cc: Jilai Wang <jilaiw@codeaurora.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
generated by cgit (git 2.34.1) at 2025-10-01 20:57:03 +0000