aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-11-24drm/mcde: Fix RGB/BGR bugLinus Walleij2-14/+13
I was confused when the graphics came out with blue penguins on the DPI panel. It turns out that the so-called "packed RGB666" mode on the DSI formatter is incorrect: this mode is the actual RGB888 mode, and the mode called RGB888 is BGR888. The claims that the MCDE had inverse RGB/BGR buffer formats was wrong, so correct this and the buggy register and everything is much more consistent, and graphics look good on all targets, both DPI and DSI. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Cc: phone-devel@vger.kernel.org Cc: Stephan Gerhold <stephan@gerhold.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201117175413.869871-1-linus.walleij@linaro.org
2020-11-23drm/i915/gt: Free stale request on destroying the virtual engineChris Wilson1-7/+53
Since preempt-to-busy, we may unsubmit a request while it is still on the HW and completes asynchronously. That means it may be retired and in the process destroy the virtual engine (as the user has closed their context), but that engine may still be holding onto the unsubmitted compelted request. Therefore we need to potentially cleanup the old request on destroying the virtual engine. We also have to keep the virtual_engine alive until after the sibling's execlists_dequeue() have finished peeking into the virtual engines, for which we serialise with RCU. v2: Be paranoid and flush the tasklet as well. v3: And flush the tasklet before the engines, as the tasklet may re-attach an rb_node after our removal from the siblings. Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201123113717.20500-4-chris@chris-wilson.co.uk
2020-11-23drm/i915/gt: Don't cancel the interrupt shadow too earlyChris Wilson1-1/+1
We currently want to keep the interrupt enabled until the interrupt after which we have no more work to do. This heuristic was broken by us kicking the irq-work on adding a completed request without attaching a signaler -- hence it appearing to the irq-worker that an interrupt had fired when we were idle. Fixes: 2854d866327a ("drm/i915/gt: Replace intel_engine_transfer_stale_breadcrumbs") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201123113717.20500-3-chris@chris-wilson.co.uk
2020-11-23drm/i915/gt: Track signaled breadcrumbs outside of the breadcrumb spinlockChris Wilson3-14/+28
Make b->signaled_requests a lockless-list so that we can manipulate it outside of the b->irq_lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201123113717.20500-2-chris@chris-wilson.co.uk
2020-11-23drm/i915/gt: Defer enabling the breadcrumb interrupt to after submissionChris Wilson1-39/+70
Move the register slow register write and readback from out of the critical path for execlists submission and delay it until the following worker, shaving off around 200us. Note that the same signal_irq_work() is allowed to run concurrently on each CPU (but it will only be queued once, once running though it can be requeued and reexecuted) so we have to remember to lock the global interactions as we cannot rely on the signal_irq_work() itself providing the serialisation (in constrast to a tasklet). By pushing the arm/disarm into the central signaling worker we can close the race for disarming the interrupt (and dropping its associated GT wakeref) on parking the engine. If we loose the race, that GT wakeref may be held indefinitely, preventing the machine from sleeping while the GPU is ostensibly idle. v2: Move the self-arming parking of the signal_irq_work to a flush of the irq-work from intel_breadcrumbs_park(). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2271 Fixes: e23005604b2f ("drm/i915/gt: Hold context/request reference while breadcrumbs are active") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201123113717.20500-1-chris@chris-wilson.co.uk
2020-11-23drm/vc4: kms: Don't disable the muxing of an active CRTCMaxime Ripard2-36/+48
The current HVS muxing code will consider the CRTCs in a given state to setup their muxing in the HVS, and disable the other CRTCs muxes. However, it's valid to only update a single CRTC with a state, and in this situation we would mux out a CRTC that was enabled but left untouched by the new state. Fix this by setting a flag on the CRTC state when the muxing has been changed, and only change the muxing configuration when that flag is there. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201120144245.398711-3-maxime@cerno.tech
2020-11-23drm/vc4: kms: Store the unassigned channel list in the stateMaxime Ripard2-25/+102
If a CRTC is enabled but not active, and that we're then doing a page flip on another CRTC, drm_atomic_get_crtc_state will bring the first CRTC state into the global state, and will make us wait for its vblank as well, even though that might never occur. Instead of creating the list of the free channels each time atomic_check is called, and calling drm_atomic_get_crtc_state to retrieve the allocated channels, let's create a private state object in the main atomic state, and use it to store the available channels. Since vc4 has a semaphore (with a value of 1, so a lock) in its commit implementation to serialize all the commits, even the nonblocking ones, we are free from the use-after-free race if two subsequent commits are not ran in their submission order. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201120144245.398711-2-maxime@cerno.tech
2020-11-23drm/i915/gvt: treat intel_gvt_mpt as const in gvt codeJulian Stecklina4-4/+4
The current interface of intel_gvt_register_hypervisor() expects a non-const pointer to struct intel_gvt_mpt, even though the mediator never modifies (or should modifiy) the content of this struct. Change the function signature and relevant struct members to const to properly express the API's intent and allow instances of intel_gvt_mpt to be allocated as const. While I was here, I also made KVM's instance of this struct const to reduce the number of writable function pointers in the kernel. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201111172811.558443-1-julian.stecklina@cyberus-technology.de
2020-11-23drm/exynos: depend on COMMON_CLK to fix compile testsKrzysztof Kozlowski1-1/+2
The Exynos DRM uses Common Clock Framework thus it cannot be built on platforms without it (e.g. compile test on MIPS with RALINK and SOC_RT305X): /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function `mixer_bind': exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent' Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2020-11-22drm/via: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/c21a588bf9e222826f6b138db91de26a2b21df33.1605896060.git.gustavoars@kernel.org
2020-11-22drm: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/111e9d3d55c686892357aa5269022024b4d48330.1605896059.git.gustavoars@kernel.org
2020-11-22drm/mediatek/mtk_disp_ovl: Fix formatting and provide missing member descriptionLee Jones1-2/+3
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or member 'ddp_comp' not described in 'mtk_disp_ovl' drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or member 'crtc' not described in 'mtk_disp_ovl' drivers/gpu/drm/mediatek/mtk_disp_ovl.c:75: warning: Function parameter or member 'data' not described in 'mtk_disp_ovl' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-11-22drm/mediatek/mtk_disp_color: Fix formatting and provide missing member descriptionLee Jones1-2/+3
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or member 'ddp_comp' not described in 'mtk_disp_color' drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or member 'crtc' not described in 'mtk_disp_color' drivers/gpu/drm/mediatek/mtk_disp_color.c:40: warning: Function parameter or member 'data' not described in 'mtk_disp_color' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-11-22drm/mediatek/mtk_drm_drv: Staticise local function invoked by referenceLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_drm_drv.c:316:24: warning: no previous prototype for ‘mtk_drm_gem_prime_import’ [-Wmissing-prototypes] Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: "Christian König" <christian.koenig@amd.com> Cc: YT SHEN <yt.shen@mediatek.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-11-22drm/mediatek/mtk_disp_rdma: Fix formatting and supply missing struct member descriptionLee Jones1-2/+3
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or member 'ddp_comp' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or member 'crtc' not described in 'mtk_disp_rdma' drivers/gpu/drm/mediatek/mtk_disp_rdma.c:66: warning: Function parameter or member 'data' not described in 'mtk_disp_rdma' Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-11-22drm/mediatek: Drop local dma_parmsRobin Murphy2-26/+3
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices"), struct platform_device already provides a dma_parms structure, so we can save allocating another one. Also the DMA segment size is simply a size, not a bitmask. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2020-11-21drm/i915/gt: Plug IPS into intel_rps_setChris Wilson2-13/+26
The old IPS interface did not match the RPS interface that we tried to plug it into (bool vs int return). Once repaired, our minimal selftesting is finally happy! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201121190352.15996-1-chris@chris-wilson.co.uk
2020-11-21drm/msm/shrinker: Only iterate dontneed objsRob Clark5-15/+40
In situations where the GPU is mostly idle, all or nearly all buffer objects will be in the inactive list. But if the system is under memory pressure (from something other than GPU), we could still get a lot of shrinker calls. Which results in traversing a list of thousands of objs and in the end finding nothing to shrink. Which isn't so efficient. Instead split the inactive_list into two lists, one inactive objs which are shrinkable, and a second one for those that are not. This way we can avoid traversing objs which we know are not shrinker candidates. v2: Fix inverted logic think-o Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-11-21drm/msm/shrinker: We can vmap shrink active_list tooRob Clark1-12/+35
Just because a obj is active, if the vmap_count is zero, we can still tear down the vmap. Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-11-21drm/msm: Protect obj->active_count under obj lockRob Clark3-11/+15
Previously we only held obj lock in the _active_get() path, and relied on atomic_dec_return() to not be racy in the _active_put() path where obj lock was not held. But this is a false sense of security. Unlike obj lifetime refcnt, where you do not expect to *increase* the refcnt after the last put (which would mean that something has gone horribly wrong with the object liveness reference counting), the active_count can increase again from zero. Racing _active_put()s and _active_get()s could leave the obj on the wrong mm list. But in the retire path, immediately after the _active_put(), the _unpin_iova() would acquire obj lock. So just move the locking earlier and rely on that to protect obj->active_count. Fixes: c5c1643cef7a ("drm/msm: Drop struct_mutex from the retire path") Signed-off-by: Rob Clark <robdclark@chromium.org>
2020-11-21drm/mediatek: dsi: Modify horizontal front/back porch byte formulaCK Hu1-37/+20
In the patch to be fixed, horizontal_backporch_byte become too large for some panel, so roll back that patch. For small hfp or hbp panel, using vm->hfront_porch + vm->hback_porch to calculate horizontal_backporch_byte would make it negtive, so use horizontal_backporch_byte itself to make it positive. Fixes: 35bf948f1edb ("drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbp") Signed-off-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Tested-by: Bilal Wasim <bilal.wasim@imgtec.com>
2020-11-20drm/i915/selftests: Small tweak to put the termination conditions togetherChris Wilson1-7/+6
If we run out of ring space, or exceed the desired runtime, we wish to stop the subtest. Put these checks together, so that we always keep the requests flushed on completion. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201120140314.24749-3-chris@chris-wilson.co.uk
2020-11-20drm/i915/selftests: Improve granularity for mocs reset checksChris Wilson1-19/+21
Allow us to validate mocs configurations after reset if we have either engine or global reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201120140314.24749-2-chris@chris-wilson.co.uk
2020-11-20drm/i915/gem: Remove incorrect early dbg printChris Wilson1-3/+0
We print out the "logical" context support before we discover whether or not the engines have logical contexts. No one, except Tvrtko, seems to have noticed the error, so the debug message must not be useful to anyone. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201120140314.24749-1-chris@chris-wilson.co.uk
2020-11-20drm/meson: dw-hdmi: Enable the iahb clock early enoughMarc Zyngier1-2/+6
Instead of moving meson_dw_hdmi_init() around which breaks existing platform, let's enable the clock meson_dw_hdmi_init() depends on. This means we don't have to worry about this clock being enabled or not, depending on the boot-loader features. Fixes: b33340e33acd ("drm/meson: dw-hdmi: Ensure that clocks are enabled before touching the TOP registers") Reported-by: "kernelci.org bot" <bot@kernelci.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> [narmstrong: changed reported by to kernelci.org bot] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201120094205.525228-3-maz@kernel.org
2020-11-20drm/meson: dw-hdmi: Disable clocks on driver teardownMarc Zyngier1-14/+29
The HDMI driver request clocks early, but never disable them, leaving the clocks on even when the driver is removed. Fix it by slightly refactoring the clock code, and register a devm action that will eventually disable/unprepare the enabled clocks. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201120094205.525228-2-maz@kernel.org
2020-11-20drm/panel: s6e63m0: Fix init sequenceLinus Walleij1-8/+10
The init sequence consist of a number of unknown settings for the display controller. This patch achieves two things: - Fix an error that must have happened when the driver was converted from the backlight subsystem: the 0xb8 configuration command was lost and added as a tail to the previous command. - Update some minor settings in some bytes here and there according to changes in the Samsung GT-I9070 and Samsung GT-S7710 code dumps. Since two other devices use these settings they probably reflect trimmings later found to be better for the display rather than customizations for these devices. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Guido Günther <agx@sigxcpu.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117175621.870085-3-linus.walleij@linaro.org
2020-11-20drm/panel: s6e63m0: Implement 28 backlight levelsLinus Walleij1-52/+256
A later version of the s6e63m0 driver in the Samsung GT-I9070 vendor tree provides 28 different backlight levels making use of elaborate control of the ACL and ELVSS regulator. Implement this more fine-grained backlight control. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Guido Günther <agx@sigxcpu.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117175621.870085-2-linus.walleij@linaro.org
2020-11-20drm/panel: s6e63m0: Fix and extend MCS tableLinus Walleij1-8/+9
Fix up the format of the manufacturer command set table to be TAB-indented and lowercase. Add the MCS_TEMP_SWIRE command that we will make use of. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Guido Günther <agx@sigxcpu.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117175621.870085-1-linus.walleij@linaro.org
2020-11-20drm: Pass the full state to connectors atomic functionsMaxime Ripard6-11/+25
The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Now that the CRTCs have been converted, let's move forward with the connectors to provide a consistent interface. The conversion was done using the coccinelle script below, and built tested on all the drivers. @@ identifier connector, connector_state; @@ struct drm_connector_helper_funcs { ... struct drm_encoder* (*atomic_best_encoder)(struct drm_connector *connector, - struct drm_connector_state *connector_state); + struct drm_atomic_state *state); ... } @@ identifier connector, connector_state; @@ struct drm_connector_helper_funcs { ... void (*atomic_commit)(struct drm_connector *connector, - struct drm_connector_state *connector_state); + struct drm_atomic_state *state); ... } @@ struct drm_connector_helper_funcs *FUNCS; identifier state; identifier connector, connector_state; identifier f; @@ f(..., struct drm_atomic_state *state, ...) { <+... - FUNCS->atomic_commit(connector, connector_state); + FUNCS->atomic_commit(connector, state); ...+> } @@ struct drm_connector_helper_funcs *FUNCS; identifier state; identifier connector, connector_state; identifier var, f; @@ f(struct drm_atomic_state *state, ...) { <+... - var = FUNCS->atomic_best_encoder(connector, connector_state); + var = FUNCS->atomic_best_encoder(connector, state); ...+> } @ connector_atomic_func @ identifier helpers; identifier func; @@ ( static struct drm_connector_helper_funcs helpers = { ..., .atomic_best_encoder = func, ..., }; | static struct drm_connector_helper_funcs helpers = { ..., .atomic_commit = func, ..., }; ) @@ identifier connector_atomic_func.func; identifier connector; symbol state; @@ func(struct drm_connector *connector, - struct drm_connector_state *state + struct drm_connector_state *connector_state ) { ... - state + connector_state ... } @ ignores_state @ identifier connector_atomic_func.func; identifier connector, connector_state; @@ func(struct drm_connector *connector, struct drm_connector_state *connector_state) { ... when != connector_state } @ adds_state depends on connector_atomic_func && !ignores_state @ identifier connector_atomic_func.func; identifier connector, connector_state; @@ func(struct drm_connector *connector, struct drm_connector_state *connector_state) { + struct drm_connector_state *connector_state = drm_atomic_get_new_connector_state(state, connector); ... } @ depends on connector_atomic_func @ identifier connector_atomic_func.func; identifier connector_state; identifier connector; @@ func(struct drm_connector *connector, - struct drm_connector_state *connector_state + struct drm_atomic_state *state ) { ... } @ include depends on adds_state @ @@ #include <drm/drm_atomic.h> @ no_include depends on !include && adds_state @ @@ + #include <drm/drm_atomic.h> #include <drm/...> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201118094758.506730-1-maxime@cerno.tech
2020-11-20drm/virtio: rename sync_seq and last_seqGurchetan Singh3-8/+9
To be clearer about our intentions to associate sequence numbers and fence IDs, let's rename these variables. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-11-20drm/virtio: use fence_id when processing fencesGurchetan Singh2-4/+4
Currently, the fence ID, which can be used to identify a virtgpu fence, is the same as the fence sequence number. Let's use the fence_id name to clearly signal this. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-4-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-11-20drm/virtio: fix a file name comment referenceAnthoine Bourgeois1-1/+1
Easier to find where declarations are implemented. Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-11-20drm/virtio: suffix create blob call with _ioctl like any ioctlAnthoine Bourgeois1-3/+4
For coherency, all ioctls are suffixed Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201119010809.528-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-11-20drm/i915/dg1: Enable portsAditya Swarup1-4/+4
For DG1 we have a little of mix up wrt to DDI/port names and indexes. Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2 (besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the most unambiguous one. This means that for any register on Display Engine we should use the index of A, B, D and E. However in some places this is not true: - VBT: uses C and D and have to be mapped to D/E - IO/Combo: uses C and D, but we already differentiate those when we created the phy vs port distinction. This additional mapping for VBT and phy are already covered in previous patches, so now we can initialize all the DDIs as A, B, D and E. v2: Squash previous patch enabling just ports A and B since most of the pumbling code is already merged now Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117084836.2318234-1-lucas.demarchi@intel.com
2020-11-19drm/i915: Do not call hsw_set_frame_start_delay for dsiManasi Navare1-5/+3
This should fix the boot oops for dsi v2: * Fix indent (Manasi) v3: * Remove redundant condition (Matt Roper) Fixes: 4e3cdb4535e7 ("drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner") Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119232615.23231-1-manasi.d.navare@intel.com
2020-11-20Merge tag 'drm-intel-fixes-2020-11-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixesDave Airlie11-34/+43
- Fix tgl power gating issue (Rodrigo) - Memory leak fixes (Tvrtko, Chris) - Selftest fixes (Zhang) - Display bpc fix (Ville) - Fix TGL MOCS for PTE tracking (Chris) GVT Fixes: It temporarily disables VFIO edid feature on BXT/APL until its virtual display is really fixed to make it work properly. And fixes for DPCD 1.2 and error return in taking module reference. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119203417.GA1795798@intel.com
2020-11-20Merge tag 'drm-misc-fixes-2020-11-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixesDave Airlie3-7/+8
two patches to fix dw-hdmi bind and detection code, and one fix for sun4i shared with arm-soc Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201119083939.ddj3saipyg5iwvb4@gilmour
2020-11-19drm/i915: Show timeline dependencies for debugTvrtko Ursulin3-1/+37
Include the signalers each request in the timeline is waiting on, as a means to try and identify the cause of a stall. This can be quite verbose, even as for now we only show each request in the timeline and its immediate antecedents. This generates output like: Timeline 886: { count 1, ready: 0, inflight: 0, seqno: { current: 664, last: 666 }, engine: rcs0 } U 886:29a- prio=0 @ 134ms: gem_exec_parall<4621> U bc1:27a- prio=0 @ 134ms: gem_exec_parall[4917] Timeline 825: { count 1, ready: 0, inflight: 0, seqno: { current: 802, last: 804 }, engine: vcs0 } U 825:324 prio=0 @ 107ms: gem_exec_parall<4518> U b75:140- prio=0 @ 110ms: gem_exec_parall<5486> Timeline b46: { count 1, ready: 0, inflight: 0, seqno: { current: 782, last: 784 }, engine: vcs0 } U b46:310- prio=0 @ 70ms: gem_exec_parall<5428> U c11:170- prio=0 @ 70ms: gem_exec_parall[5501] Timeline 96b: { count 1, ready: 0, inflight: 0, seqno: { current: 632, last: 634 }, engine: vcs0 } U 96b:27a- prio=0 @ 67ms: gem_exec_parall<4878> U b75:19e- prio=0 @ 67ms: gem_exec_parall<5486> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201119165616.10834-6-chris@chris-wilson.co.uk
2020-11-19drm/i915: Lift waiter/signaler iteratorsChris Wilson2-10/+10
Lift the list iteration defines for traversing the signaler/waiter lists into i915_scheduler.h for reuse. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119165616.10834-5-chris@chris-wilson.co.uk
2020-11-19drm/i915/gt: Show all active timelines for debuggingChris Wilson3-7/+98
Include the active timelines for debugfs/i915_engine_info, so that we can see which have unready requests inflight which are not shown otherwise. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119165616.10834-4-chris@chris-wilson.co.uk
2020-11-19drm/i915/gt: Update request status flags for debug pretty-printerChris Wilson5-24/+88
We plan to expand upon the number of available statuses for when we pretty-print the requests along the timelines, and so need a new set of flags. We have settled upon: Unready [U] - initial status after being submitted, the request is not ready for execution as it is waiting for external fences Ready [R] - all fences the request was waiting on have been signaled, and the request is now ready for execution and will be in a backend queue - a ready request may still need to wait on semaphores [internal fences] Ready/virtual [V] - same as ready, but queued over multiple backends Executing [E] - the request has been transferred from the backend queue and submitted for execution on HW - a completed request may still be regarded as executing, its status may not be updated until it is retired and removed from the lists Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119165616.10834-3-chris@chris-wilson.co.uk
2020-11-19drm/i915: Lift i915_request_show()Chris Wilson5-45/+50
Extract i915_request_show for reuse in other request chain pretty printers. For a bonus point, quietly change the seqno format from %llx to %lld to match everywhere else. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119165616.10834-2-chris@chris-wilson.co.uk
2020-11-19drm/i915/gt: Include semaphore status in print_request()Chris Wilson1-0/+1
When pretty-printing the requests for debug, also show the status of any semaphore waits as part of its runnable status. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119165616.10834-1-chris@chris-wilson.co.uk
2020-11-19drm/i915/gt: Fixup tgl mocs for PTE trackingChris Wilson1-2/+3
Forcing mocs:1 [used for our winsys follows-pte mode] to be cached caused display glitches. Though it is documented as deprecated (and so likely behaves as uncached) use the follow-pte bit and force it out of L3 cache. Testcase: igt/kms_frontbuffer_tracking Testcase: igt/kms_big_fb Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201015122138.30161-4-chris@chris-wilson.co.uk (cherry picked from commit a04ac827366594c7244f60e9be79fcb404af69f0) Fixes: 849c0fe9e831 ("drm/i915/gt: Initialize reserved and unspecified MOCS indices") Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo: Updated Fixes tag]
2020-11-20Merge tag 'amd-drm-fixes-5.10-2020-11-18' of git://people.freedesktop.org/~agd5f/linux into drm-fixesDave Airlie3-7/+8
amd-drm-fixes-5.10-2020-11-18: amdgpu: - Pageflip fix for navi1x with 5 or 6 displays - Remove experimental flag for Arcturus - Fix regression in atomic commit tail rework Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201118213646.4015-1-alexander.deucher@amd.com
2020-11-19drm/i915/display: Whitespace cleanupsChris Wilson1-12/+11
drivers/gpu/drm/i915/display/intel_display.c:3634 intel_find_initial_plane_obj() warn: inconsistent indenting drivers/gpu/drm/i915/display/intel_display.c:15367 kill_bigjoiner_slave() warn: inconsistent indenting Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119090717.30687-1-chris@chris-wilson.co.uk
2020-11-20drm/vram-helper: Fix use of top-down placementThomas Zimmermann1-1/+1
Commit 7053e0eab473 ("drm/vram-helper: stop using TTM placement flags") cleared the BO placement flags if top-down placement had been selected. Hence, BOs that were supposed to go into VRAM are now placed in a default location in system memory. Trying to scanout the incorrectly pinned BO results in displayed garbage and an error message. [ 146.108127] ------------[ cut here ]------------ [ 146.1V08180] WARNING: CPU: 0 PID: 152 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x59/0x60 [drm_vram_helper] ... [ 146.108591] ast_cursor_page_flip+0x3e/0x150 [ast] [ 146.108622] ast_cursor_plane_helper_atomic_update+0x8a/0xc0 [ast] [ 146.108654] drm_atomic_helper_commit_planes+0x197/0x4c0 [ 146.108699] drm_atomic_helper_commit_tail_rpm+0x59/0xa0 [ 146.108718] commit_tail+0x103/0x1c0 ... [ 146.109302] ---[ end trace d901a1ba1d949036 ]--- Fix the bug by keeping the placement flags. The top-down placement flag is stored in a separate variable. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Fixes: 7053e0eab473 ("drm/vram-helper: stop using TTM placement flags") Reported-by: Pu Wen <puwen@hygon.cn> [for 5.10-rc1] Tested-by: Pu Wen <puwen@hygon.cn> Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200921142536.4392-1-tzimmermann@suse.de (cherry picked from commit b8f8dbf6495850b0babc551377bde754b7bc0eea) [pulled into fixes from drm-next] Signed-off-by: Dave Airlie <airlied@redhat.com>
2020-11-19drm/vc4: hdmi: Disable Wifi FrequenciesMaxime Ripard2-0/+29
There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi chip and some resolutions, most notably 1440p at 60Hz. In such a case, we can either reject entirely the mode, or lower slightly the pixel frequency to remove the overlap. Let's go for the latter. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201029134018.1948636-2-maxime@cerno.tech
2020-11-19drm/vc4: kms: Document the muxing corner casesMaxime Ripard1-0/+22
We've had a number of muxing corner-cases with specific ways to reproduce them, so let's document them to make sure they aren't lost and introduce regressions later on. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201105135656.383350-6-maxime@cerno.tech