summary refs log tree commit diff
path: root/drivers/gpu/drm/nouveau
AgeCommit message (Collapse)Author
2023-09-15Merge branch 6.1/features/amd-drm-extraCristian Ciocaltea
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
2023-09-08Merge tag 'v6.1.52' into 6.1/features/merge-fixesCristian Ciocaltea
Fix conflicts: drivers/gpu/drm/amd/amdgpu/amdgpu.h drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.h drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c drivers/gpu/drm/amd/display/dc/core/dc.c drivers/gpu/drm/amd/display/dc/core/dc_link.c drivers/gpu/drm/amd/display/dc/core/dc_resource.c drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.h drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.c drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c drivers/gpu/drm/amd/display/dc/inc/core_types.h drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c drivers/thunderbolt/quirks.c Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
2023-08-23drm/nouveau/disp: fix use-after-free in error handling of ↵Karol Herbst
nouveau_connector_create commit 1b254b791d7b7dea6e8adc887fbbd51746d8bb27 upstream. We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit. Link: https://lore.kernel.org/lkml/20230806213107.GFZNARG6moWpFuSJ9W@fat_crate.local/ Fixes: 95983aea8003 ("drm/nouveau/disp: add connector class") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230814144933.3956959-1-kherbst@redhat.com Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-16drm/nouveau/disp: Revert a NULL check inside nouveau_connector_get_modesKarol Herbst
commit d5712cd22b9cf109fded1b7f178f4c1888c8b84b upstream. The original commit adding that check tried to protect the kenrel against a potential invalid NULL pointer access. However we call nouveau_connector_detect_depth once without a native_mode set on purpose for non LVDS connectors and this broke DP support in a few cases. Cc: Olaf Skibbe <news@kravcenko.com> Cc: Lyude Paul <lyude@redhat.com> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/238 Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/245 Fixes: 20a2ce87fbaf8 ("drm/nouveau/dp: check for NULL nv_connector->native_mode") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230805101813.2603989-1-kherbst@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-16drm/nouveau/nvkm/dp: Add workaround to fix DP 1.3+ DPCD issuesLyude Paul
commit e4060dad253352382b20420d8ef98daab24dbc17 upstream. Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of nouveau in order to read the DPCD of a DP connector, which makes sure we do the right thing and also check for extended DPCD caps. However, it turns out we're not currently doing this on the nvkm side since we don't have access to the drm_dp_aux structure there - which means that the DRM side of the driver and the NVKM side can end up with different DPCD capabilities for the same connector. Ideally in order to fix this, we just want to use the drm_dp_read_dpcd_caps() helper in nouveau. That's not currently possible though, and is going to depend on having a bunch of the DP code moved out of nvkm and into the DRM side of things as part of the GSP enablement work. Until then however, let's workaround this problem by porting a copy of drm_dp_read_dpcd_caps() into NVKM - which should fix this issue. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211 Link: https://patchwork.freedesktop.org/patch/msgid/20230728225858.350581-1-lyude@redhat.com (cherry picked from commit cc4adf3a7323212f303bc9ff0f96346c44fcba06 in drm-misc-next) Cc: <stable@vger.kernel.org> # 6.3+ Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-16drm/nouveau/gr: enable memory loads on helper invocation on all channelsKarol Herbst
commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream. We have a lurking bug where Fragment Shader Helper Invocations can't load from memory. But this is actually required in OpenGL and is causing random hangs or failures in random shaders. It is unknown how widespread this issue is, but shaders hitting this can end up with infinite loops. We enable those only on all Kepler and newer GPUs where we use our own Firmware. Nvidia's firmware provides a way to set a kernelspace controlled list of mmio registers in the gr space from push buffers via MME macros. v2: drop code for gm200 and newer. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: nouveau@lists.freedesktop.org Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kherbst@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-09Merge tag 'v6.1.43' into 6.1/features/merge-fixesCristian Ciocaltea
Fix conflicts: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c drivers/gpu/drm/amd/display/dc/core/dc.c drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c drivers/gpu/drm/amd/display/dc/dc.h drivers/gpu/drm/amd/display/dc/dcn315/dcn315_resource.c drivers/gpu/drm/amd/display/dc/dml/dcn314/dcn314_fpu.c drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.c drivers/gpu/drm/amd/display/dmub/src/dmub_dcn314.h drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c drivers/gpu/drm/drm_fb_helper.c Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
2023-08-08drm: introduce drm_mode_config.atomic_async_page_flip_not_supportedSimon Ser
This new field indicates whether the driver has the necessary logic to support async page-flips via the atomic uAPI. This is leveraged by the next commit to allow user-space to use this functionality. All atomic drivers setting drm_mode_config.async_page_flip are updated to also set drm_mode_config.atomic_async_page_flip_not_supported. We will gradually check and update these drivers to properly handle drm_crtc_state.async_flip in their atomic logic. The goal of this negative flag is the same as fb_modifiers_not_supported: we want to eventually get rid of all drivers missing atomic support for async flips. New drivers should not set this flag, instead they should support atomic async flips (if they support async flips at all). IOW, we don't want more drivers with async flip support for legacy but not atomic. v2: only set the flag on atomic drivers (remove it on amdgpu DCE and on radeon) Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joshua Ashton <joshua@froggi.es> Cc: Melissa Wen <mwen@igalia.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: André Almeida <andrealmeid@igalia.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20220830172851.269402-4-contact@emersion.fr
2023-07-27drm/dp_mst: Clear MSG_RDY flag before sending new messageWayne Lin
commit 72f1de49ffb90b29748284f27f1d6b829ab1de95 upstream. [Why] The sequence for collecting down_reply from source perspective should be: Request_n->repeat (get partial reply of Request_n->clear message ready flag to ack DPRX that the message is received) till all partial replies for Request_n are received->new Request_n+1. Now there is chance that drm_dp_mst_hpd_irq() will fire new down request in the tx queue when the down reply is incomplete. Source is restricted to generate interveleaved message transactions so we should avoid it. Also, while assembling partial reply packets, reading out DPCD DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be wrapped up as a complete operation for reading out a reply packet. Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might be risky. e.g. If the reply of the new request has overwritten the DPRX DOWN_REP Sideband MSG buffer before source writing one to clear DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply for the new request. Should handle the up request in the same way. [How] Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might trigger drm_dp_mst_kick_tx() only when there is no on going message transaction. Changes since v1: * Reworked on review comments received -> Adjust the fix to let driver explicitly kick off new down request when mst irq event is handled and acked -> Adjust the commit message Changes since v2: * Adjust the commit message * Adjust the naming of the divided 2 functions and add a new input parameter "ack". * Adjust code flow as per review comments. Changes since v3: * Update the function description of drm_dp_mst_hpd_irq_handle_event Changes since v4: * Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align the size of esi[] Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-22Merge tag 'v6.1.39' into 6.1/features/merge-fixesCristian Ciocaltea
Fix conflicts: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c drivers/gpu/drm/amd/display/dc/core/dc_link.c drivers/gpu/drm/amd/display/dc/dc_types.h drivers/gpu/drm/i915/display/intel_tc.c drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
2023-06-21drm/nouveau: add nv_encoder pointer check for NULLNatalia Petrova
[ Upstream commit 55b94bb8c42464bad3d2217f6874aa1a85664eac ] Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 3195c5f9784a ("drm/nouveau: set encoder for lvds") Signed-off-by: Natalia Petrova <n.petrova@fintech.ru> Reviewed-by: Lyude Paul <lyude@redhat.com> [Fixed patch title] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512103320.82234-1-n.petrova@fintech.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/nouveau/dp: check for NULL nv_connector->native_modeNatalia Petrova
[ Upstream commit 20a2ce87fbaf81e4c3dcb631d738e423959eb320 ] Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one") Signed-off-by: Natalia Petrova <n.petrova@fintech.ru> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512111526.82408-1-n.petrova@fintech.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/nouveau: don't detect DSM for non-NVIDIA deviceRatchanan Srirattanamet
[ Upstream commit 11d24327c2d7ad7f24fcc44fb00e1fa91ebf6525 ] The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the presence of power resource support, and the rest of the code will keep using Optimus DSM, breaking power management for that machine. Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run this detection on a non-NVIDIA device anyway. Thus, check at the beginning of the detection code if this is an NVIDIA card, and just return if it isn't. This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and landed earlier, fixes runtime power management of the NVIDIA card in Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code will "timeout", sometimes hanging userspace. As a bonus, we'll also stop preventing _PR3 usage from the bridge for unrelated devices, which is always nice, I guess. Fixes: ccfc2d5cdb02 ("drm/nouveau: Use generic helper to check _PR3 presence") Signed-off-by: Ratchanan Srirattanamet <peathot@hotmail.com> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79 Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/DM6PR19MB2780805D4BE1E3F9B3AC96D0BC409@DM6PR19MB2780.namprd19.prod.outlook.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21nouveau: fix client work fence deletion raceDave Airlie
commit c8a5d5ea3ba6a18958f8d76430e4cd68eea33943 upstream. This seems to have existed for ever but is now more apparant after commit 9bff18d13473 ("drm/ttm: use per BO cleanup workers") My analysis: two threads are running, one in the irq signalling the fence, in dma_fence_signal_timestamp_locked, it has done the DMA_FENCE_FLAG_SIGNALLED_BIT setting, but hasn't yet reached the callbacks. The second thread in nouveau_cli_work_ready, where it sees the fence is signalled, so then puts the fence, cleanups the object and frees the work item, which contains the callback. Thread one goes again and tries to call the callback and causes the use-after-free. Proposed fix: lock the fence signalled check in nouveau_cli_work_ready, so either the callbacks are done or the memory is freed. Reviewed-by: Karol Herbst <kherbst@redhat.com> Fixes: 11e451e74050 ("drm/nouveau: remove fence wait code from deferred client work handler") Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/dri-devel/20230615024008.1600281-1-airlied@gmail.com/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-05Merge tag 'v6.1.29' into amd-staging-drm-nextCristian Ciocaltea
Fix conflicts: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c drivers/gpu/drm/amd/amdgpu/soc21.c drivers/gpu/drm/amd/amdkfd/kfd_chardev.c drivers/gpu/drm/amd/amdkfd/kfd_crat.c drivers/gpu/drm/amd/amdkfd/kfd_device.c drivers/gpu/drm/amd/amdkfd/kfd_migrate.c drivers/gpu/drm/amd/amdkfd/kfd_topology.c drivers/gpu/drm/amd/amdkfd/kfd_topology.h drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_smu.c drivers/gpu/drm/amd/display/dc/core/dc_link.c drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c drivers/gpu/drm/amd/display/dc/dc_link.h drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.c drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dio_stream_encoder.c drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.c drivers/gpu/drm/amd/display/dc/dcn314/dcn314_hwseq.h drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hwseq.c drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c drivers/gpu/drm/amd/display/dc/dml/dcn20/dcn20_fpu.c drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.h drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h drivers/gpu/drm/amd/display/modules/power/power_helpers.c drivers/gpu/drm/amd/display/modules/power/power_helpers.h drivers/gpu/drm/amd/pm/amdgpu_pm.c drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c drivers/gpu/drm/drm_edid.c drivers/gpu/drm/i915/display/intel_fbdev.c drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c drivers/gpu/drm/msm/msm_drv.c drivers/gpu/drm/nouveau/dispnv50/disp.c drivers/gpu/drm/ttm/ttm_pool.c drivers/gpu/drm/vmwgfx/vmwgfx_kms.c drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c drivers/thunderbolt/quirks.c Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
2023-04-13drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()Imre Deak
commit e761cc20946a0094df71cb31a565a6a0d03bd8be upstream. Atm, drm_dp_remove_payload() uses the same payload state to both get the vc_start_slot required for the payload removal DPCD message and to deduct time_slots from vc_start_slot of all payloads after the one being removed. The above isn't always correct, as vc_start_slot must be the up-to-date version contained in the new payload state, but time_slots must be the one used when the payload was previously added, contained in the old payload state. The new payload's time_slots can change vs. the old one if the current atomic commit changes the corresponding mode. This patch let's drivers pass the old and new payload states to drm_dp_remove_payload(), but keeps these the same for now in all drivers not to change the behavior. A follow-up i915 patch will pass in that driver the correct old and new states to the function. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: stable@vger.kernel.org # 6.1 Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Wayne Lin <wayne.lin@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.deak@intel.com Hand modified for missing 8c7d980da9ba3eb67a1b40fd4b33bcf49397084b Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-13drm/nouveau/disp: Support more modes by checking with lower bpcKarol Herbst
commit 7f67aa097e875c87fba024e850cf405342300059 upstream. This allows us to advertise more modes especially on HDR displays. Fixes using 4K@60 modes on my TV and main display both using a HDMI to DP adapter. Also fixes similar issues for users running into this. Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230330223938.4025569-1-kherbst@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-17drm/nouveau/kms/nv50: fix nv50_wndw_new_ prototypeJiri Slaby (SUSE)
[ Upstream commit 3638a820c5c3b52f327cebb174fd4274bee08aa7 ] gcc-13 warns about mismatching types for enums. That revealed switched arguments of nv50_wndw_new_(): drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for 'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)' drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of 'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)' It can be barely visible, but the declaration says about the parameters in the middle: enum nv50_disp_interlock_type, u32 interlock_data, u32 heads, While the definition states differently: u32 heads, enum nv50_disp_interlock_type interlock_type, u32 interlock_data, Unify/fix the declaration to match the definition. Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel interlocks") Cc: Martin Liska <mliska@suse.cz> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221031114229.10289-1-jirislaby@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-23drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()Imre Deak
Atm, drm_dp_remove_payload() uses the same payload state to both get the vc_start_slot required for the payload removal DPCD message and to deduct time_slots from vc_start_slot of all payloads after the one being removed. The above isn't always correct, as vc_start_slot must be the up-to-date version contained in the new payload state, but time_slots must be the one used when the payload was previously added, contained in the old payload state. The new payload's time_slots can change vs. the old one if the current atomic commit changes the corresponding mode. This patch let's drivers pass the old and new payload states to drm_dp_remove_payload(), but keeps these the same for now in all drivers not to change the behavior. A follow-up i915 patch will pass in that driver the correct old and new states to the function. Cc: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: stable@vger.kernel.org # 6.1 Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Lyude Paul <lyude@redhat.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Acked-by: Wayne Lin <wayne.lin@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206114856.2665066-2-imre.deak@intel.com Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-02-22drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETEDBen Skeggs
[ Upstream commit d22915d22ded21fd5b24b60d174775789f173997 ] Starting from Turing, the driver is no longer responsible for initiating DEVINIT when required as the GPU started loading a FW image from ROM and executing DEVINIT itself after power-on. However - we apparently still need to wait for it to complete. This should correct some issues with runpm on some systems, where we get control of the HW before it's been fully reinitialised after resume from suspend. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130223715.1831509-1-bskeggs@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-11-22Merge tag 'drm-misc-next-2022-11-17' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 6.2: UAPI Changes: Cross-subsystem Changes: - fbdev: Add support for the nomodeset kernel parameter Core Changes: - client: Add kunit tests for drm_connector_pick_cmdline_mode() - dma-buf: Move dma_buf_mmap_internal() to new locking specification - edid: Dump EDID on drm_edid_get_panel_id() failure, Stop using a temporary device to load the EDID through the firmware mechanism - fb-helper: Remove damage worker - gem-vram: Fix deadlock in drm_gem_vram_vmap() - modes: Named mode parsing improvements - tests: Add Kunit helpers to create a DRM device Driver Changes: - hisilicon: convert to drm_mode_init() - malidp: Use drm-managed resources - msm: convert to drm_mode_init() and drm_mode_copy() - mtk: convert to drm_mode_init() - nouveau: Support backlight control for nva3 - rockchip: convert to drm_mode_copy() - sti: convert to drm_mode_copy() - v3d: Switch to drm-managed resources - vc4: Fix potential NULL pointer dereference - panels: - New panel: NewVision NV3051D Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221117083628.mzij5nrbdzokek7c@houat
2022-11-16Merge tag 'drm-misc-next-2022-11-10-1' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 6.2: UAPI Changes: Cross-subsystem Changes: Core Changes: - atomic-helper: Add begin_fb_access and end_fb_access hooks - fb-helper: Rework to move fb emulation into helpers - scheduler: rework entity flush, kill and fini - ttm: Optimize pool allocations Driver Changes: - amdgpu: scheduler rework - hdlcd: Switch to DRM-managed resources - ingenic: Fix registration error path - lcdif: FIFO threshold tuning - meson: Fix return type of cvbs' mode_valid - ofdrm: multiple fixes (kconfig, types, endianness) - sun4i: A100 and D1 support - panel: - New Panel: Jadard JD9365DA-H3 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221110083612.g63eaocoaa554soh@houat
2022-11-14drm/nouveau/disp: fix incorrect/broken hdmi methodsBen Skeggs
These are fixes from Lyude, and were meant to have been included in the last round of drm-next patches. - Fix some nasty memory issues that broke Lyude's display: - 0 initialize both nvif args and parsed HDMI infoframe buffers - Fixed missing memset(…, 0, …) for nvif args before sending VSI infoframe - Fixed incorrect data pointer and size in nvkm_uoutp_mthd_infoframe() (was previously pointing at the start of the nvif_outp_infoframe_args struct instead of at the start of the infoframe data - Get rid of duplicated scdc assignments, since we only use it to write the scdc registers Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-11-11drm/nouveau: Add support to control backlight using bl_power for nva3.Antonio Gomes
Summary: * Add support to turn on/off backlight when changing values in bl_power file. This is achieved by using function backlight_get_brightness() in nva3_set_intensity to get current brightness. Test plan: * Turn off: echo 1 > /sys/class/backlight/nv_backlight/bl_power * Turn on: echo 0 > /sys/class/backlight/nv_backlight/bl_power Signed-off-by: Antonio Gomes <antoniospg100@gmail.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221104220424.41164-1-antoniospg100@gmail.com
2022-11-09drm/nouveau/gr/ga102: initial supportBen Skeggs
v2: - whitespace Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Gourav Samaiya <gsamaiya@nvidia.com>
2022-11-09drm/nouveau/ltc/ga102: initial supportBen Skeggs
v2. fixup for ga103 early merge Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/acr/ga102: initial supportBen Skeggs
v2. fixup for ga103 early merge Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Gourav Samaiya <gsamaiya@nvidia.com>
2022-11-09drm/nouveau/fb/ga102: load and boot VPR scrubber FWBen Skeggs
v2. fixup for ga103 early merge Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Gourav Samaiya <gsamaiya@nvidia.com>
2022-11-09drm/nouveau/gr/tu102: remove gv100_grctx_unkn88cBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/tu102: add gv100_gr_init_4188a4Ben Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/tu102-: fix support for sw_bundle64_initBen Skeggs
We weren't sending the high bits, though they're zero currently anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/tu102-: use sw_veid_bundle_init from firmwareBen Skeggs
NVIDIA provided this on Turing, but we kept using the hardcoded version from Volta (where they didn't). Switch to the firmware version prior to Ampere. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gv100-: drop a write from init_shader_exceptions()Ben Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gv100-: move init_419bd8() after sw_ctx loadBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gv100-: add NV_PGRAPH_PRI_PD_AB_DIST_CONFIG_1 to patch listBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gv100-: fix number of tile map registersBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gv100-: port smid mapping code from nvgpuBen Skeggs
Essentially ripped verbatim from NVGPU, comments and all, and adapted to nvkm's structs and style. - maybe fixes an nvgpu bug though, a small tweak was needed to match RM v2: - remove unnecessary WARN_ON Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gp100-: modify init_fecs_exceptionsBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gk20a,gm20b,gp10b: split out netlist parsing from fw loadingBen Skeggs
We'll want to reuse the former for loading from proper netlist images. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gp100-: fix number of zcull tile regsBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf117-: make ppc_nr[gpc] accurateBen Skeggs
We're going to be pulling in a chunk of code from NVGPU to fixup our SMID mappings on Volta and above, which depends on ppc_nr[gpc] reflecting the actual number of PPCs present, not the maximum number. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: switch to newer style interrupt handlerBen Skeggs
Ampere. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: move some init to init_exception2()Ben Skeggs
Ampere. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: move some init to init_rop_exceptions()Ben Skeggs
Ampere. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: move reset during golden ctx init to fecs_reset()Ben Skeggs
Ampere. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: wfi after register-bashing golden initBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: gpfifo_ctl zero before initBen Skeggs
Match RM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: wait for FE_PWR_MODE_AUTOBen Skeggs
This doesn't fix any known issue, but RM started doing it at some point, so presumably it's needed for something. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: call FECS HALT_PIPE method before RC resetBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/gr/gf100-: call FECS WFI_GOLDEN_SAVE methodBen Skeggs
This won't work on Ampere, and, it's questionable whether we should have been using our FW's method of storing the golden context image with NV's firmware to begin with. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-09-25 20:20:14 +0000