summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2021-10-04Revert "drm/gma500: cleanup: drm_modeset_lock_all() --> ↵Sean Paul
DRM_MODESET_LOCK_ALL_BEGIN()" This reverts commit 4f9e860e6ad65ff4ea8ce165a1407d96ff1b2211. This patchset breaks on intel platforms and was previously NACK'd by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fernando Ramos <greenfoo@u92.eu> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-3-sean@poorly.run
2021-10-04Revert "drm/amd: cleanup: drm_modeset_lock_all() --> ↵Sean Paul
DRM_MODESET_LOCK_ALL_BEGIN()" This reverts commit 299f040e855b69c29522cde446777902381a07f5. This patchset breaks on intel platforms and was previously NACK'd by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fernando Ramos <greenfoo@u92.eu> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-2-sean@poorly.run
2021-10-04Revert "drm: cleanup: remove drm_modeset_(un)lock_all()"Sean Paul
This reverts commit 8d813d1a535c8c7503a5f4061654a73026be8c5e. This patchset breaks on intel platforms and was previously NACK'd by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fernando Ramos <greenfoo@u92.eu> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211002154542.15800-1-sean@poorly.run
2021-10-04drm/gud: Add GUD_PIXEL_FORMAT_RGB888Noralf Trønnes
Add support for the RGB888 pixel format. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-7-noralf@tronnes.org
2021-10-04drm/gud: Add GUD_PIXEL_FORMAT_RGB332Noralf Trønnes
Add support for the RGB332 pixel format. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-6-noralf@tronnes.org
2021-10-04drm/gud: Add GUD_PIXEL_FORMAT_R8Noralf Trønnes
Add support for 8-bit greyscale format. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-5-noralf@tronnes.org
2021-10-04drm/i915: Allow per-lane drive settings with LTTPRsVille Syrjälä
LTTPRs should support per-lane drive settings I think, and even if they don't they should implement their own fallback logic to determine suitable common drive settings to use for all the lanes. v2: Actually check the correct thing Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-11-ville.syrjala@linux.intel.com
2021-10-04drm/i915: Prepare link training for per-lane drive settingsVille Syrjälä
Adjust the link training code to accommodate per-lane drive settings, if supported by the platform. Actually enabling this will involve some changes to each platform's .set_signal_level() implementation, so for the moment all supported platforms will keep using the current codepath that just uses the same drive settings for all the lanes. v2: Fix min() vs. max() fumble v3: Compact the debug print to a single line Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-10-ville.syrjala@linux.intel.com
2021-10-04drm/i915: Pass the lane to intel_ddi_level()Ville Syrjälä
In order to have per-lane drive settings we need intel_ddi_level() to accept the lane as a parameter. That is, the eventual goal is to call intel_ddi_level() once for each lane. For now we just pass in a hardcoded 0 and use the same settings for every lane. Ie. no change in behaviour yet. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-9-ville.syrjala@linux.intel.com
2021-10-04drm/format-helper: Add drm_fb_xrgb8888_to_rgb888()Noralf Trønnes
Add XRGB8888 emulation support for devices that can only do RGB888. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-4-noralf@tronnes.org
2021-10-04drm/format-helper: Add drm_fb_xrgb8888_to_rgb332()Noralf Trønnes
Add XRGB8888 emulation support for devices that can only do RGB332. v2: - Support Big Endian (Daniel) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-3-noralf@tronnes.org
2021-10-04drm/fourcc: Add R8 to drm_format_infoNoralf Trønnes
Add an entry in drm_format_info for the existing format DRM_FORMAT_R8. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210929191201.34456-2-noralf@tronnes.org
2021-10-04drm/i915: Nuke intel_ddi_hdmi_num_entries()Ville Syrjälä
Since intel_ddi_level() now looks at the buf_trans table there's no point in having intel_ddi_hdmi_num_entries() around. Just roll the necessary bits of locic into intel_ddi_hdmi_level()/intel_ddi_level(). Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-8-ville.syrjala@linux.intel.com
2021-10-04drm/i915: Hoover the level>=n_entries WARN into intel_ddi_level()Ville Syrjälä
All callers of intel_ddi_level() duplicate the check+WARN to make sure the returned level is actually present in the appropriate buf_trans table. Let's push that stuff into intel_ddi_level() so the callers don't have to worry about it. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-7-ville.syrjala@linux.intel.com
2021-10-04treewide: Replace the use of mem_encrypt_active() with cc_platform_has()Tom Lendacky
Replace uses of mem_encrypt_active() with calls to cc_platform_has() with the CC_ATTR_MEM_ENCRYPT attribute. Remove the implementation of mem_encrypt_active() across all arches. For s390, since the default implementation of the cc_platform_has() matches the s390 implementation of mem_encrypt_active(), cc_platform_has() does not need to be implemented in s390 (the config option ARCH_HAS_CC_PLATFORM is not set). Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210928191009.32551-9-bp@alien8.de
2021-10-04drm/i915: De-wrapper bxt_ddi_phy_set_signal_levels()Ville Syrjälä
Convert bxt_ddi_phy_set_signal_levels() to act as the full .set_signal_levels() hook instead of going through a pointless wrapper. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-6-ville.syrjala@linux.intel.com
2021-10-04drm/i915: Nuke useless .set_signal_levels() wrappersVille Syrjälä
Now that .set_signal_levels() is used for HDMI as well, we can remove the extra level of indirection and just plug the correct stuff straight into .set_signal_levels(). Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-5-ville.syrjala@linux.intel.com
2021-10-04drm/i915: Generalize .set_signal_levels()Ville Syrjälä
Currently .set_signal_levels() is only used by encoders in DP mode. For most modern platforms there is no essential difference between DP and HDMI, and both codepaths just end up calling the same function under the hood. Let's get remove the need for that extra indirection by moving .set_signal_levels() into the encoder from intel_dp. Since we already plumb the crtc_state/etc. into .set_signal_levels() the code will do the right thing for both DP and HDMI. HSW/BDW/SKL are the only platforms that need a bit of care on account of having to preload the hardware buf_trans register with the full set of values. So we must still remember to call hsw_prepare_{dp,hdmi}_ddi_buffers() to do said preloading, and .set_signal_levels() will just end up selecting the correct entry for DP, and also setting up the iboost magic for both DP and HDMI. Note that previously on HSW/BDW/SKL we did write to DDI_BUF_CTL to select the correct entry until link training started, now that we call .set_signal_levels() already from hsw_ddi_pre_enable_dp() that is no longer the case. But it's all safe now that the intel_ddi_init_dp_buf_reg() call was hoisted up and it no longer sets up the DDI_BUF_CTL_ENABLE bit (that is still deferred until link training). v2: Rebase due to has_{iboost,buf_trans_select}() Add some notes about the DDI_BUF_CTL situation on HSW/BDW/SKL (Imre) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-4-ville.syrjala@linux.intel.com
2021-10-04drm/i915: Introduce has_buf_trans_select()Ville Syrjälä
Add a small helper to determine if DDI_BUF_CTL uses the DDI_BUF_TRANS_SELECT field, and whether we have the accompanying DDI_BUF_TRANS table in the hardware. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-04drm/i915: Introduce has_iboost()Ville Syrjälä
Suck the "do we have iboost?" platform checks into a small helper. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001130107.1746-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-04drm/i915: Fix DP clock recovery "voltage_tries" handlingVille Syrjälä
The DP spec says: "If the receiver keeps the same value in the ADJUST_REQUEST_LANEx_y register(s) while the LANEx_CR_DONE bits remain unset, the transmitter must loop four times with the same voltage swing. On the fifth time, the transmitter must down-shift to the lower bit rate and must repeat the CR-lock training sequence as described below." Lets fix the code to follow that instead of terminating after five times of transmitting the same signal levels. The text in spec feels a little bit ambiguous still, but this is my best guess at its meaning. As a bonus this also gets rid of the train_set[0] stuff which would not work for per-lane drive settings anyway. Cc: Imre Deak <imre.deak@intel.com> CC: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001160826.17080-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2021-10-04drm/v3d: add multiple syncobjs supportMelissa Wen
Using the generic extension from the previous patch, a specific multisync extension enables more than one in/out binary syncobj per job submission. Arrays of syncobjs are set in struct drm_v3d_multisync, that also cares of determining the stage for sync (wait deps) according to the job queue. v2: - subclass the generic extension struct (Daniel) - simplify adding dependency conditions to make understandable (Iago) v3: - fix conditions to consider single or multiples in/out_syncs (Iago) - remove irrelevant comment (Iago) Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ffd8b2e3dd2e0c686db441a0c0a4a0181ff85328.1633016479.git.mwen@igalia.com
2021-10-04drm/v3d: add generic ioctl extensionMelissa Wen
Add support to attach generic extensions on job submission. This patch is third prep work to enable multiple syncobjs on job submission. With this work, when the job submission interface needs to be extended to accommodate a new feature, we will use a generic extension struct where an id determines the data type to be pointed. The first application is to enable multiples in/out syncobj (next patch), but the base is already done for future features. Therefore, to attach a new feature, a specific extension struct should subclass drm_v3d_extension and update the list of extensions in a job submission. v2: - remove redundant elements to subclass struct (Daniel) v3: - add comment for v3d_get_extensions Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/ed53b1cd7e3125b76f18fe3fb995a04393639bc6.1633016479.git.mwen@igalia.com
2021-10-04drm/v3d: alloc and init job in one shotMelissa Wen
Move job memory allocation to v3d_job_init function. This aim to facilitate error handling in job initialization, since cleanup steps are similar for all (struct v3d_job)-based types of job involved in a command submission. To generalize v3d_job_init(), this change takes into account that all job structs have the first element a struct v3d_job (bin, render, tfu, csd) or it is a v3d_job itself (clean_job) for pointer casting. v3: - explicitly init job as NULL (Iago) - fix pm failure handling on v3_job_init (Iago) Suggested-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/4d12e07bd334d2cddb51cabd359e99edde595619.1633016479.git.mwen@igalia.com
2021-10-04drm/v3d: decouple adding job dependencies steps from job initMelissa Wen
Prep work to enable a job to wait for more than one syncobj before start. Also get rid of old checkpatch warnings in the v3d_gem file. No functional changes. Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/825f5fdd540b0aa2eb57bd5ff93c0777808b108c.1633016479.git.mwen@igalia.com
2021-10-04drm/i915/reg: add AUD_TCA_DP_2DOT0_CTRL registersJani Nikula
For controlling the audio SDP split. Bspec: 63837 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211001100316.26441-1-jani.nikula@intel.com
2021-10-04drm/i915: fix regression with uncore refactoring.Dave Airlie
This was causing infinite recursion on snb/ivb. Fixes: 5716c8c6f4b6 ("drm/i915/uncore: split the fw get function into separate vfunc") Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004003133.2279446-1-airlied@gmail.com
2021-10-02drm/i915: fix blank screen booting crashesHugh Dickins
5.15-rc1 crashes with blank screen when booting up on two ThinkPads using i915. Bisections converge convincingly, but arrive at different and suprising "culprits", none of them the actual culprit. netconsole (with init_netconsole() hacked to call i915_init() when logging has started, instead of by module_init()) tells the story: kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! with RSI: ffffffff814d408b pointing to sw_fence_dummy_notify(). I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that function needs to be 4-byte aligned. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Hugh Dickins <hughd@google.com> Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-10-01drm/msm/submit: fix overflow check on 64-bit architecturesArnd Bergmann
The overflow check does causes a warning from clang-14 when 'sz' is a type that is smaller than size_t: drivers/gpu/drm/msm/msm_gem_submit.c:217:10: error: result of comparison of constant 18446744073709551615 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (sz == SIZE_MAX) { Change the type accordingly. Fixes: 20224d715a88 ("drm/msm/submit: Move copy_from_user ahead of locking bos") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210927113632.3849987-1-arnd@kernel.org Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm: One sched entity per process per priorityRob Clark
Some userspace apps make assumptions that rendering against multiple contexts within the same process (from the same thread, with appropriate MakeCurrent() calls) provides sufficient synchronization without any external synchronization (ie. glFenceSync()/glWaitSync()). Since a submitqueue maps to a gl/vk context, having multiple sched entities of the same priority only works with implicit sync enabled. To fix this, limit things to a single sched entity per priority level per process. An alternative would be sharing submitqueues between contexts in userspace, but tracking of per-context faults (ie. GL_EXT_robustness) is already done at the submitqueue level, so this is not an option. Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm: A bit more docs + cleanupRob Clark
msm_file_private is more gpu related, and in the next commit it will need access to other GPU specific #defines. While we're at it, add some comments. Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm/a6xx: Track current ctx by seqnoRob Clark
In theory a context can be destroyed and a new one allocated at the same address, making the pointer comparision to detect when we don't need to update the current pagetables invalid. Instead assign a sequence number to each context on creation, and use this for the check. Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables") Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm/a6xx: Serialize GMU communicationRob Clark
I've seen some crashes in our crash reporting that *look* like multiple threads stomping on each other while communicating with GMU. So wrap all those paths in a lock. Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/msm: Fix crash on dev file closeRob Clark
If the device file was opened prior to fw being available (such as from initrd before rootfs is mounted, when the initrd does not contain GPU fw), that would cause a later crash when the dev file is closed due to unitialized submitqueues list: CPU: 4 PID: 263 Comm: plymouthd Tainted: G W 5.15.0-rc2-next-20210924 #2 Hardware name: LENOVO 81JL/LNVNB161216, BIOS 9UCN33WW(V2.06) 06/ 4/2019 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_submitqueue_close+0x30/0x190 [msm] lr : msm_postclose+0x54/0xf0 [msm] sp : ffff80001074bb80 x29: ffff80001074bb80 x28: ffff03ad80c4db80 x27: ffff03ad80dc5ab0 x26: 0000000000000000 x25: ffff03ad80dc5af8 x24: ffff03ad81e90800 x23: 0000000000000000 x22: ffff03ad81e90800 x21: ffff03ad8b35e788 x20: ffff03ad81e90878 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda15f14f7940 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffda15cd18ff88 x8 : ffff03ad80c4db80 x7 : 0000000000000228 x6 : 0000000000000000 x5 : 1793a4e807e636bd x4 : ffff03ad80c4db80 x3 : ffff03ad81e90878 x2 : 0000000000000000 x1 : ffff03ad80c4db80 x0 : 0000000000000000 Call trace: msm_submitqueue_close+0x30/0x190 [msm] msm_postclose+0x54/0xf0 [msm] drm_file_free.part.0+0x1cc/0x2e0 [drm] drm_close_helper.isra.0+0x74/0x84 [drm] drm_release+0x78/0x120 [drm] __fput+0x78/0x23c ____fput+0x1c/0x30 task_work_run+0xcc/0x22c do_exit+0x304/0x9f4 do_group_exit+0x44/0xb0 __wake_up_parent+0x0/0x3c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x4c/0xf4 do_el0_svc+0x30/0x9c el0_svc+0x20/0x60 el0t_64_sync_handler+0xe8/0xf0 el0t_64_sync+0x1a0/0x1a4 Code: aa0003f5 a90153f3 f8408eb3 aa1303e0 (f85e8674) ---[ end trace 39b2fa37509a2be2 ]--- Fixing recursive fault but reboot is needed! Fixes: 86c2a0f000c1 drm/msm: ("Small submitqueue creation cleanup") Reported-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-01drm/i915/guc: Move and improve error message for missed CTB replyMichal Wajdeczko
If we timeout waiting for a CT reply we print very simple error message. Improve that and by moving error reporting to the caller we can use CT_ERROR instead of DRM_ERROR and report just fence as error code will be reported later anyway. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210926184545.1407-5-michal.wajdeczko@intel.com
2021-10-01drm/i915/guc: Print error name on CTB send failureMichal Wajdeczko
Instead of plain error value (%d) print more user friendly error name (%pe). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210926184545.1407-4-michal.wajdeczko@intel.com
2021-10-01drm/i915/guc: Print error name on CTB (de)registration failureMichal Wajdeczko
Instead of plain error value (%d) print more user friendly error name (%pe). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210926184545.1407-3-michal.wajdeczko@intel.com
2021-10-01drm/i915/guc: Verify result from CTB (de)register actionMichal Wajdeczko
In commit b839a869dfc9 ("drm/i915/guc: Add support for data reporting in GuC responses") we missed the hypothetical case that GuC might return positive non-zero value as success data. While that would be lucky treated as error case, and at the end will result in reporting valid -EIO, in the meantime this value will be passed to ERR_PTR that could be misleading. v2: rebased Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210926184545.1407-2-michal.wajdeczko@intel.com
2021-10-01drm/i915: Use fixed offset for PTEs locationMichal Wajdeczko
We assumed that for all modern GENs the PTEs and register space are split in the GTTMMADR BAR, but while it is true, we should rather use fixed offset as it is defined in the specification. Bspec: 4409, 4457, 4604, 11181, 9027, 13246, 13321, 44980 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: CQ Tang <cq.tang@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210926201005.1450-1-michal.wajdeczko@intel.com
2021-10-01drm/bridge: ti-sn65dsi86: Implement bridge->mode_valid()Rob Clark
For the brave new world of bridges not creating their own connectors, we need to implement the max clock limitation via bridge->mode_valid() instead of connector->mode_valid(). v2: Drop unneeded connector->mode_valid() Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210920225801.227211-3-robdclark@gmail.com
2021-10-01drm/i915: Stop force enabling pipe bottom color gammma/cscVille Syrjälä
While sanitizing the hardware state we're currently forcing the pipe bottom color legacy csc/gamma bits on. That is not a good idea as BIOSen are likely to leave gabage in the LUTs and so doing this causes ugly visual glitches if and when the planes covering the background get disabled. This was exactly the case on this Dell Precision 5560 tgl laptop. On icl+ we don't normally even use these legacy bits anymore and instead use their GAMMA_MODE counterparts. On earlier platforms the bits are used, but we still shouldn't force them on without knowing what's in the LUT. So two options, get rid of the whole thing, or do what intel_color_commit() does to make sure the bottom color state matches whatever out hardware readout produced. I chose the latter since it'll match what happens on older platforms when the primary plane gets turned off. In fact let's just call intel_color_commit(). It'll also do some CSC programming but since we don't have readout for that it'll actually just set to all zeros. So in the unlikely case of CSC actually being enabld by the BIOS we'll end up with all black until the first atomic commit happens. Still not totally sure what we should do about color management features here in general. Probably the safest thing would be to force everything off exactly at the same time when we disable the primary plane as there is no guarantees that whatever the LUTs/CSCs contain make any sense whatsoever without the specific pixel data in the BIOS fb. And if we preserve the primary plane then we should disable the color management features exactly when the primary plane fb contents first changes since the new content assumes more or less no transformations. But of course synchronizing front buffer rendering with anything else is a bit hard... Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3534 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210928185105.3030-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2021-10-01drm: cleanup: remove drm_modeset_(un)lock_all()Fernando Ramos
Functions drm_modeset_lock_all() and drm_modeset_unlock_all() are no longer used anywhere and can be removed. Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-17-greenfoo@u92.eu
2021-10-01drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-16-greenfoo@u92.eu
2021-10-01drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-15-greenfoo@u92.eu
2021-10-01drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() ↵Fernando Ramos
part 2 As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() While the previous commit was a simple "search and replace", this time I had to do a bit of refactoring as only one call to DRM_MODESET_LOCK_ALL_BEGIN() is allowed inside one same function. Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-14-greenfoo@u92.eu
2021-10-01drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-13-greenfoo@u92.eu
2021-10-01drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-12-greenfoo@u92.eu
2021-10-01drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-11-greenfoo@u92.eu
2021-10-01drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-10-greenfoo@u92.eu
2021-10-01drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN()Fernando Ramos
As requested in Documentation/gpu/todo.rst, replace driver calls to drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and DRM_MODESET_LOCK_ALL_END() Signed-off-by: Fernando Ramos <greenfoo@u92.eu> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210924064324.229457-9-greenfoo@u92.eu
generated by cgit (git 2.34.1) at 2025-09-13 06:38:12 +0000