summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2021-12-08drm/amd/display: Allow DSC on supported MST branch devicesNicholas Kazlauskas1-4/+16
commit 94ebc035456a4ccacfbbef60c444079a256623ad upstream. [Why] When trying to lightup two 4k60 non-DSC displays behind a branch device that supports DSC we can't lightup both at once due to bandwidth limitations - each requires 48 VCPI slots but we only have 63. [How] The workaround already exists in the code but is guarded by a CONFIG that cannot be set by the user and shouldn't need to be. Check for specific branch device IDs to device whether to enable the workaround for multiple display scenarios. Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-08drm/amd/amdgpu: fix potential memleakBernard Zhao1-0/+1
[ Upstream commit 27dfaedc0d321b4ea4e10c53e4679d6911ab17aa ] In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put. Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Bernard Zhao <bernard@vivo.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-08drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered againshaoyunl1-0/+5
[ Upstream commit 2cf49e00d40d5132e3d067b5aa6d84791929ab15 ] In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch already been called, the start_cpsch will not be called since there is no resume in this case. When reset been triggered again, driver should avoid to do uninitialization again. Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-08drm/amd/pm: Remove artificial freq level on Navi1xLijo Lazar1-5/+8
[ Upstream commit be83a5676767c99c2417083c29d42aa1e109a69d ] Print Navi1x fine grained clocks in a consistent manner with other SOCs. Don't show aritificial DPM level when the current clock equals min or max. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-08drm/sun4i: fix unmet dependency on RESET_CONTROLLER for PHY_SUN6I_MIPI_DPHYJulian Braha1-0/+1
[ Upstream commit bb162bb2b4394108c8f055d1b115735331205e28 ] When PHY_SUN6I_MIPI_DPHY is selected, and RESET_CONTROLLER is not selected, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for PHY_SUN6I_MIPI_DPHY Depends on [n]: (ARCH_SUNXI [=n] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] && COMMON_CLK [=y] && RESET_CONTROLLER [=n] Selected by [y]: - DRM_SUN6I_DSI [=y] && HAS_IOMEM [=y] && DRM_SUN4I [=y] This is because DRM_SUN6I_DSI selects PHY_SUN6I_MIPI_DPHY without selecting or depending on RESET_CONTROLLER, despite PHY_SUN6I_MIPI_DPHY depending on RESET_CONTROLLER. These unmet dependency bugs were detected by Kismet, a static analysis tool for Kconfig. Please advise if this is not the appropriate solution. v2: Fixed indentation to match the rest of the file. Signed-off-by: Julian Braha <julianbraha@gmail.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211109032351.43322-1-julianbraha@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/amdgpu/gfx9: switch to golden tsc registers for renoir+Alex Deucher1-11/+35
commit 53af98c091bc42fd9ec64cfabc40da4e5f3aae93 upstream. Renoir and newer gfx9 APUs have new TSC register that is not part of the gfxoff tile, so it can be read without needing to disable gfx off. Acked-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-01drm/amdgpu/gfx10: add wraparound gpu counter check for APUs as wellAlex Deucher1-2/+13
commit 244ee398855df2adc7d3ac5702b58424a5f684cc upstream. Apply the same check we do for dGPUs for APUs as well. Acked-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-01drm/amd/display: Set plane update flags for all planes in resetNicholas Kazlauskas1-2/+2
[ Upstream commit 21431f70f6014f81b0d118ff4fcee12b00b9dd70 ] [Why] We're only setting the flags on stream[0]'s planes so this logic fails if we have more than one stream in the state. This can cause a page flip timeout with multiple displays in the configuration. [How] Index into the stream_status array using the stream index - it's a 1:1 mapping. Fixes: cdaae8371aa9 ("drm/amd/display: Handle GPU reset for DC block") Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/amd/display: Fix DPIA outbox timeout after GPU resetNicholas Kazlauskas1-0/+2
[ Upstream commit 6eff272dbee7ad444c491c9a96d49e78e91e2161 ] [Why] The HW interrupt gets disabled after GPU reset so we don't receive notifications for HPD or AUX from DMUB - leading to timeout and black screen with (or without) DPIA links connected. [How] Re-enable the interrupt after GPU reset like we do for the other DC interrupts. Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX") Reviewed-by: Jude Shih <Jude.Shih@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/hyperv: Fix device removal on Gen1 VMsMohammed Gamal1-1/+18
[ Upstream commit e048834c209a02e3776bcc47d43c6d863e3a67ca ] The Hyper-V DRM driver tries to free MMIO region on removing the device regardless of VM type, while Gen1 VMs don't use MMIO and hence causing the kernel to crash on a NULL pointer dereference. Fix this by making deallocating MMIO only on Gen2 machines and implement removal for Gen1 Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Signed-off-by: Mohammed Gamal <mgamal@redhat.com> Reviewed-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211119112900.300537-1-mgamal@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/aspeed: Fix vga_pw sysfs outputJoel Stanley1-1/+1
[ Upstream commit b4a6aaeaf4aa79f23775f6688a7e8db3ee1c1303 ] Before the drm driver had support for this file there was a driver that exposed the contents of the vga password register to userspace. It would present the entire register instead of interpreting it. The drm implementation chose to mask of the lower bit, without explaining why. This breaks the existing userspace, which is looking for 0xa8 in the lower byte. Change our implementation to expose the entire register. Fixes: 696029eb36c0 ("drm/aspeed: Add sysfs for output settings") Reported-by: Oskar Senft <osk@google.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Tested-by: Oskar Senft <osk@google.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211117010145.297253-1-joel@jms.id.au Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/vc4: fix error code in vc4_create_object()Dan Carpenter1-1/+1
[ Upstream commit 96c5f82ef0a145d3e56e5b26f2bf6dcd2ffeae1c ] The ->gem_create_object() functions are supposed to return NULL if there is an error. None of the callers expect error pointers so returing one will lead to an Oops. See drm_gem_vram_create(), for example. Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211118111416.GC1147@kili Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/nouveau/acr: fix a couple NULL vs IS_ERR() checksDan Carpenter2-4/+8
[ Upstream commit b371fd131fcec59f6165c80778bdc2cd1abd616b ] The nvkm_acr_lsfw_add() function never returns NULL. It returns error pointers on error. Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118111314.GB1147@kili Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-01drm/amd/display: Fix OLED brightness control on eDPRoman Li1-0/+3
commit dab60582685aabdae2d4ff7ce716456bd0dc7a0f upstream. [Why] After commit ("drm/amdgpu/display: add support for multiple backlights") number of eDPs is defined while registering backlight device. However the panel's extended caps get updated once before register call. That leads to regression with extended caps like oled brightness control. [How] Update connector ext caps after register_backlight_device Fixes: 7fd13baeb7a3a4 ("drm/amdgpu/display: add support for multiple backlights") Link: https://www.reddit.com/r/AMDLaptops/comments/qst0fm/after_updating_to_linux_515_my_brightness/ Signed-off-by: Roman Li <Roman.Li@amd.com> Tested-by: Samuel Čavoj <samuel@cavoj.net> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jasdeep Dhillon <Jasdeep.Dhillon@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-01drm/nouveau: recognise GA106Ben Skeggs1-0/+22
commit 46741e4f593ff1bd0e4a140ab7e566701946484b upstream. I've got HW now, appears to work as expected so far. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: <stable@vger.kernel.org> # 5.14+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211118030413.2610-1-skeggsb@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-01drm/amdgpu/pm: fix powerplay OD interfaceAlex Deucher6-79/+67
commit d5c7255dc7ff6e1239d794b9c53029d83ced04ca upstream. The overclocking interface currently appends data to a string. Revert back to using sprintf(). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1774 Fixes: 6db0c87a0a8ee1 ("amdgpu/pm: Replace hwmgr smu usage of sprintf with sysfs_emit") Acked-by: Evan Quan <evan.quan@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-01drm/amdgpu: IH process reset count when restartPhilip Yang1-1/+2
commit 4d62555f624582e60be416fbc4772cd3fcd12b1a upstream. Otherwise when IH process restart, count is zero, the loop will not exit to wake_up_all after processing AMDGPU_IH_MAX_NUM_IVS interrupts. Cc: stable@vger.kernel.org Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/amd/pm: avoid duplicate powergate/ungate settingEvan Quan4-1/+23
commit 6ee27ee27ba8b2e725886951ba2d2d87f113bece upstream. Just bail out if the target IP block is already in the desired powergate/ungate state. This can avoid some duplicate settings which sometimes may cause unexpected issues. Link: https://lore.kernel.org/all/YV81vidWQLWvATMM@zn.tnic/ Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214921 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215025 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1789 Fixes: bf756fb833cb ("drm/amdgpu: add missing cleanups for Polaris12 UVD/VCE on suspend") Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Borislav Petkov <bp@suse.de> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/amdgpu: fix set scaling mode Full/Full aspect/Center not works on vga ↵hongao1-0/+1
and dvi connectors commit bf552083916a7f8800477b5986940d1c9a31b953 upstream. amdgpu_connector_vga_get_modes missed function amdgpu_get_native_mode which assign amdgpu_encoder->native_mode with *preferred_mode result in amdgpu_encoder->native_mode.clock always be 0. That will cause amdgpu_connector_set_property returned early on: if ((rmx_type != DRM_MODE_SCALE_NONE) && (amdgpu_encoder->native_mode.clock == 0)) when we try to set scaling mode Full/Full aspect/Center. Add the missing function to amdgpu_connector_vga_get_mode can fix this. It also works on dvi connectors because amdgpu_connector_dvi_helper_funcs.get_mode use the same method. Signed-off-by: hongao <hongao@uniontech.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platformsVille Syrjälä1-22/+63
commit 1977e8eb40ed53f0cac7db1a78295726f4ac0b24 upstream. Looks like we never updated intel_bios_is_port_dp_dual_mode() when the VBT port mapping became erratic on modern platforms. This is causing us to look up the wrong child device and thus throwing the heuristic off (ie. we might end looking at a child device for a genuine DP++ port when we were supposed to look at one for a native HDMI port). Fix it up by not using the outdated port_mapping[] in intel_bios_is_port_dp_dual_mode() and rely on intel_bios_encoder_data_lookup() instead. Cc: stable@vger.kernel.org Tested-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025142147.23897-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 32c2bc89c7420fad2959ee23ef5b6be8b05d2bde) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/dp: Ensure max link params are always validImre Deak1-8/+10
commit cc99bc62ff6902688ee7bd3a7b25eefc620fbb6a upstream. Atm until the DPCD for a connector is read the max link rate and lane count params are invalid. If the connector is modeset, in intel_dp_compute_config(), intel_dp_common_len_rate_limit(max_link_rate) will return 0, leading to a intel_dp->common_rates[-1] access. Fix the above by making sure the max link params are always valid. The above access leads to an undefined behaviour by definition, though not causing a user visible problem to my best knowledge, see the previous patch why. Nevertheless it is an undefined behaviour and it triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-4-imre.deak@intel.com (cherry picked from commit 9ad87de4735620ffc555592e8c5f580478fa3ed0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/dp: Ensure sink rate values are always validImre Deak1-0/+11
commit 6c34bd4532a3f39952952ddc102737595729afc4 upstream. Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com (cherry picked from commit 3f61ef9777c0ab0f03f4af0ed6fd3e5250537a8d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/nouveau: clean up all clients on device removalJeremy Cline1-0/+30
commit f55aaf63bde0d0336c3823bb3713bd4a464abbcf upstream. The postclose handler can run after the device has been removed (or the driver has been unbound) since userspace clients are free to hold the file open as long as they want. Because the device removal callback frees the entire nouveau_drm structure, any reference to it in the postclose handler will result in a use-after-free. To reproduce this, one must simply open the device file, unbind the driver (or physically remove the device), and then close the device file. This was found and can be reproduced easily with the IGT core_hotunplug tests. To avoid this, all clients are cleaned up in the device finalization rather than deferring it to the postclose handler, and the postclose handler is protected by a critical section which ensures the drm_dev_unplug() and the postclose handler won't race. This is not an ideal fix, since as I understand the proposed plan for the kernel<->userspace interface for hotplug support, destroying the client before the file is closed will cause problems. However, I believe to properly fix this issue, the lifetime of the nouveau_drm structure needs to be extended to match the drm_device, and this proved to be a rather invasive change. Thus, I've broken this out so the fix can be easily backported. This fixes with the two previous commits CVE-2020-27820 (Karol). Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-4-jcline@redhat.com Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/nouveau: use drm_dev_unplug() during device removalJeremy Cline1-1/+1
commit aff2299e0d81b26304ccc6a1ec0170e437f38efc upstream. Nouveau does not currently support hot-unplugging, but it still makes sense to switch from drm_dev_unregister() to drm_dev_unplug(). drm_dev_unplug() calls drm_dev_unregister() after marking the device as unplugged, but only after any device critical sections are finished. Since nouveau isn't using drm_dev_enter() and drm_dev_exit(), there are no critical sections so this is nearly functionally equivalent. However, the DRM layer does check to see if the device is unplugged, and if it is returns appropriate error codes. In the future nouveau can add critical sections in order to truly support hot-unplugging. Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-2-jcline@redhat.com Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/nouveau: Add a dedicated mutex for the clients listJeremy Cline2-4/+11
commit abae9164a421bc4a41a3769f01ebcd1f9d955e0e upstream. Rather than protecting the nouveau_drm clients list with the lock within the "client" nouveau_cli, add a dedicated lock to serialize access to the list. This is both clearer and necessary to avoid lockdep being upset with us when we need to iterate through all the clients in the list and potentially lock their mutex, which is the same class as the lock protecting the entire list. Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Tested-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201125202648.5220-3-jcline@redhat.com Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/prime: Fix use after free in mmap with drm_gem_ttm_mmapAnand K Mistry1-2/+4
commit 8244a3bc27b3efd057da154b8d7e414670d5044f upstream. drm_gem_ttm_mmap() drops a reference to the gem object on success. If the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that drop will free the gem object, and the subsequent drm_gem_object_get() will be a UAF. Fix by grabbing a reference before calling the mmap helper. This issue was forseen when the reference dropping was adding in commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"): "For that to work properly the drm_gem_object_get() call in drm_gem_ttm_mmap() must be moved so it happens before calling obj->funcs->mmap(), otherwise the gem refcount would go down to zero." Signed-off-by: Anand K Mistry <amistry@google.com> Fixes: 9786b65bc61a ("drm/ttm: fix mmap refcounting") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> 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 Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210930085932.1.I8043d61cc238e0168e2f4ca5f4783223434aa587@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/udl: fix control-message timeoutJohan Hovold1-1/+1
commit 5591c8f79db1729d9c5ac7f5b4d3a5c26e262d93 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)") Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211025115353.5089-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/guc: Unwind context requests in reverse orderMatthew Brost1-4/+4
commit c39f51cc980dd918c5b3da61d54c4725785e766e upstream. When unwinding requests on a reset context, if other requests in the context are in the priority list the requests could be resubmitted out of seqno order. Traverse the list of active requests in reverse and append to the head of the priority list to fix this. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-4-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/guc: Don't drop ce->guc_active.lock when unwinding contextMatthew Brost1-4/+0
commit 88209a8ecb8b8752322908a3c3362a001bdc3a39 upstream. Don't drop ce->guc_active.lock when unwinding a context after reset. At one point we had to drop this because of a lock inversion but that is no longer the case. It is much safer to hold the lock so let's do that. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-5-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/guc: Workaround reset G2H is received after schedule done G2HMatthew Brost1-6/+35
commit 1ca36cff0166b0483fe3b99e711e9c800ebbfaa4 upstream. If the context is reset as a result of the request cancellation the context reset G2H is received after schedule disable done G2H which is the wrong order. The schedule disable done G2H release the waiting request cancellation code which resubmits the context. This races with the context reset G2H which also wants to resubmit the context but in this case it really should be a NOP as request cancellation code owns the resubmit. Use some clever tricks of checking the context state to seal this race until the GuC firmware is fixed. v2: (Checkpatch) - Fix typos v3: (Daniele) - State that is a bug in the GuC firmware Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-7-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, ↵Matthew Brost1-3/+19
not registered commit 9888beaaf118b6878347e1fe2b369fc66d756d18 upstream. When unblocking a context, do not enable scheduling if the context is banned, guc_id invalid, or not registered. v2: (Daniele) - Add helper for unblock Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-10-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/i915/guc: Fix outstanding G2H accountingMatthew Brost1-42/+37
commit 669b949c1a44d0cb2bcd18ff6ab4fd0c21e7cf6f upstream. A small race that could result in incorrect accounting of the number of outstanding G2H. Basically prior to this patch we did not increment the number of outstanding G2H if we encoutered a GT reset while sending a H2G. This was incorrect as the context state had already been updated to anticipate a G2H response thus the counter should be incremented. As part of this change we remove a legacy (now unused) path that was the last caller requiring a G2H response that was not guaranteed to loop. This allows us to simplify the accounting as we don't need to handle the case where the send fails due to the channel being busy. Also always use helper when decrementing this value. v2 (Daniele): update GEM_BUG_ON check, pull in dead code removal from later patch, remove loop param from context_deregister. Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-3-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/amd/display: Limit max DSC target bpp for specific monitorsRoman Li1-0/+35
commit 55eea8ef98641f6e1e1c202bd3a49a57c1dd4059 upstream. [Why] Some monitors exhibit corruption at 16bpp DSC. [How] - Add helpers for patching edid caps. - Use it for limiting DSC target bitrate to 15bpp for known monitors Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Roman Li <Roman.Li@amd.com> Cc: stable@vger.kernel.org Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/amd/display: Update swizzle mode enumsAlvin Lee2-3/+5
commit 58065a1e524de30df9a2d8214661d5d7eed0a2d9 upstream. [Why] Swizzle mode enum for DC_SW_VAR_R_X was existing, but not mapped correctly. [How] Update mapping and conversion for DC_SW_VAR_R_X. Reviewed-by: XiangBing Foo <XiangBing.Foo@amd.com> Reviewed-by: Martin Leung <Martin.Leung@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Cc: stable@vger.kernel.org Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/cma-helper: Release non-coherent memory with dma_free_noncoherent()Thomas Zimmermann1-2/+7
commit 995f54ea962e03ec08b8bc6a4fe11a32b420edd3 upstream. The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this with a call to dma_free_noncoherent(). Writecombining storage is still released with dma_free_wc(). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: cf8ccbc72d61 ("drm: Add support for GEM buffers backed by non-coherent memory") Acked-by: Paul Cercueil <paul@crapouillou.net> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/20210708175146.10618-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"Vandita Kulkarni1-8/+2
commit f15863b27752682bb700c21de5f83f613a0fb77e upstream. This reverts commit 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"). The Bspec was updated recently with the pll ungate sequence similar to that of icl dsi enable sequence. Hence reverting. Bspec: 49187 Fixes: 991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping") Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com (cherry picked from commit 4579509ef181480f4e4510d436c691519167c5c2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-25drm/nouveau: hdmigv100.c: fix corrupted HDMI Vendor InfoFrameHans Verkuil1-1/+0
[ Upstream commit 3cc1ae1fa70ab369e4645e38ce335a19438093ad ] gv100_hdmi_ctrl() writes vendor_infoframe.subpack0_high to 0x6f0110, and then overwrites it with 0. Just drop the overwrite with 0, that's clearly a mistake. Because of this issue the HDMI VIC is 0 instead of 1 in the HDMI Vendor InfoFrame when transmitting 4kp30. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 290ffeafcc1a ("drm/nouveau/disp/gv100: initial support") Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/3d3bd0f7-c150-2479-9350-35d394ee772d@xs4all.nl Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-21Revert "drm: fb_helper: fix CONFIG_FB dependency"Greg Kroah-Hartman1-1/+1
This reverts commit c95380ba527ae0aee29b2a133c5d0c481d472759 which is commit 606b102876e3741851dfb09d53f3ee57f650a52c upstream. It causes some build problems as reported by Jiri. Link: https://lore.kernel.org/r/9fdb2bf1-de52-1b9d-4783-c61ce39e8f51@kernel.org Reported-by: Jiri Slaby <jirislaby@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-21Revert "drm: fb_helper: improve CONFIG_FB dependency"Greg Kroah-Hartman1-2/+3
This reverts commit 94e18f5a5dd1b5e3b89c665fc5ff780858b1c9f6 which is commit 9d6366e743f37d36ef69347924ead7bcc596076e upstream. It causes some build problems as reported by Jiri. Link: https://lore.kernel.org/r/9fdb2bf1-de52-1b9d-4783-c61ce39e8f51@kernel.org Reported-by: Jiri Slaby <jirislaby@kernel.org> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Kees Cook <keescook@chromium.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18drm/amd/display: Look at firmware version to determine using dmub on dcn21Mario Limonciello1-1/+8
commit 91adec9e07097e538691daed5d934e7886dd1dc3 upstream. commit 652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21 asics") switched over to using dmub on Renoir to fix Gitlab 1735, but this implied a new dependency on newer firmware which might not be met on older kernel versions. Since sw_init runs before hw_init, there is an opportunity to determine whether or not the firmware version is new to adjust the behavior. Cc: Roman.Li@amd.com BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1772 BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1735 Fixes: 652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21 asics") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18drm/sun4i: Fix macros in sun8i_csc.hJernej Skrabec1-2/+2
commit c302c98da646409d657a473da202f10f417f3ff1 upstream. Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual recommendation of having arguments enclosed in parenthesis. While that didn't change anything for quite sometime, it actually become important after CSC code rework with commit ea067aee45a8 ("drm/sun4i: de2/de3: Remove redundant CSC matrices"). Without this fix, colours are completely off for supported YVU formats on SoCs with DE2 (A64, H3, R40, etc.). Fix the issue by enclosing macro arguments in parenthesis. Cc: stable@vger.kernel.org # 5.12+ Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library") Reported-by: Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210831184819.93670-1-jernej.skrabec@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18drm/i915/guc: Fix blocked context accountingMatthew Brost1-1/+1
commit fc30a6764a54dea42291aeb7009bef7aa2fc1cd4 upstream. Prior to this patch the blocked context counter was cleared on init_sched_state (used during registering a context & resets) which is incorrect. This state needs to be persistent or the counter can read the incorrect value resulting in scheduling never getting enabled again. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-2-matthew.brost@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-11-18drm/amdgpu: fix uvd crash on Polaris12 during driver unloadingEvan Quan1-11/+13
[ Upstream commit 4fc30ea780e0a5c1c019bc2e44f8523e1eed9051 ] There was a change(below) target for such issue: d82e2c249c8f ("drm/amdgpu: Fix crash on device remove/driver unload") But the fix for VI ASICs was missing there. This is a supplement for that. Fixes: d82e2c249c8f ("drm/amdgpu: Fix crash on device remove/driver unload") Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18drm/i915/fb: Fix rounding error in subsampled plane size calculationImre Deak1-2/+3
[ Upstream commit 90ab96f3872eae816f4e07deaa77322a91237960 ] For NV12 FBs with odd main surface tile-row height the CCS surface height was incorrectly calculated 1 less than the actual value. Fix this by rounding up the result of divison. For consistency do the same for the CCS surface width calculation. Fixes: b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-2-imre.deak@intel.com (cherry picked from commit 2ee5ef9c934ad26376c9282171e731e6c0339815) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18drm/amdgpu/powerplay: fix sysfs_emit/sysfs_emit_at handlingAlex Deucher7-12/+51
[ Upstream commit e9c76719c1e99caf95e70de74170291b9457bbc1 ] sysfs_emit and sysfs_emit_at requrie a page boundary aligned buf address. Make them happy! v2: fix sysfs_emit -> sysfs_emit_at missed conversions Cc: Lang Yu <lang.yu@amd.com> Cc: Darren Powell <darren.powell@amd.com> Fixes: 6db0c87a0a8e ("amdgpu/pm: Replace hwmgr smu usage of sprintf with sysfs_emit") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1774 Reviewed-by: Lang Yu <lang.yu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18Revert "drm/imx: Annotate dma-fence critical section in commit path"Fabio Estevam1-2/+0
[ Upstream commit 14d9a37c952588930d7226953359fea3ab956d39 ] This reverts commit f4b34faa08428d813fc3629f882c503487f94a12. Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit path") the following possible circular dependency is detected: [ 5.001811] ====================================================== [ 5.001817] WARNING: possible circular locking dependency detected [ 5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: G W [ 5.001833] ------------------------------------------------------ [ 5.001838] kworker/u8:0/7 is trying to acquire lock: [ 5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x40/0x294 [ 5.001903] [ 5.001903] but task is already holding lock: [ 5.001909] c176df78 (dma_fence_map){++++}-{0:0}, at: imx_drm_atomic_commit_tail+0x10/0x160 [ 5.001957] [ 5.001957] which lock already depends on the new lock. ... Revert it for now. Tested on a imx6q-sabresd. Fixes: f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit path") Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211104001112.4035691-1-festevam@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18drm: fb_helper: improve CONFIG_FB dependencyArnd Bergmann1-3/+2
[ Upstream commit 9d6366e743f37d36ef69347924ead7bcc596076e ] My previous patch correctly addressed the possible link failure, but as Jani points out, the dependency is now stricter than it needs to be. Change it again, to allow DRM_FBDEV_EMULATION to be used when DRM_KMS_HELPER and FB are both loadable modules and DRM is linked into the kernel. As a side-effect, the option is now only visible when at least one DRM driver makes use of DRM_KMS_HELPER. This is better, because the option has no effect otherwise. Fixes: 606b102876e3 ("drm: fb_helper: fix CONFIG_FB dependency") Suggested-by: Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211029120307.1407047-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18drm/ttm: remove ttm_bo_vm_insert_huge()Jason Gunthorpe7-173/+6
[ Upstream commit 0d979509539ed1df883a30d442177ca7be609565 ] The huge page functionality in TTM does not work safely because PUD and PMD entries do not have a special bit. get_user_pages_fast() considers any page that passed pmd_huge() as usable: if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) || pmd_devmap(pmd))) { And vmf_insert_pfn_pmd_prot() unconditionally sets entry = pmd_mkhuge(pfn_t_pmd(pfn, prot)); eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE. As such gup_huge_pmd() will try to deref a struct page: head = try_grab_compound_head(pmd_page(orig), refs, flags); and thus crash. Thomas further notices that the drivers are not expecting the struct page to be used by anything - in particular the refcount incr above will cause them to malfunction. Thus everything about this is not able to fully work correctly considering GUP_fast. Delete it entirely. It can return someday along with a proper PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast. Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Thomas Hellström <thomas.helllstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> [danvet: Update subject per Thomas' &Christian's review] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/0-v2-a44694790652+4ac-ttm_pmd_jgg@nvidia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18drm/nouveau/svm: Fix refcount leak bug and missing check against null bugChenyuan Mi1-0/+4
[ Upstream commit 6bb8c2d51811eb5e6504f49efe3b089d026009d2 ] The reference counting issue happens in one exception handling path of nouveau_svmm_bind(). When cli->svm.svmm is null, the function forgets to decrease the refcount of mm increased by get_task_mm(), causing a refcount leak. Fix this issue by using mmput() to decrease the refcount in the exception handling path. Also, the function forgets to do check against null when get mm by get_task_mm(). Fix this issue by adding null check after get mm by get_task_mm(). Signed-off-by: Chenyuan Mi <cymi20@fudan.edu.cn> Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Fixes: 822cab6150d3 ("drm/nouveau/svm: check for SVM initialized before migrating") Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907122633.16665-1-cymi20@fudan.edu.cn Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmtsGuido Günther1-0/+35
[ Upstream commit 2f1495fac8d38bfade18bd7e31fa787cd7815626 ] Components further up in the chain might ask us for supported formats. Without this MEDIA_BUS_FMT_FIXED is assumed which then breaks display output with mxsfb since it can't determine a proper bus format. We handle the bus formats that correspond to the DSI formats the bridge can potentially output (see chapter 13.6 of the i.MX 8MQ reference manual) - which matches what xsfb can input. Fixes: b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if present") Signed-off-by: Guido Günther <agx@sigxcpu.org> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1712f2b952694fd4484dfd8576fbc5b4d7adf042.1633959458.git.agx@sigxcpu.org Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-13 14:04:03 +0300