aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-22drivers/accel: define kconfig and register a new majorGravatar Oded Gabbay 7-0/+155
Add a new Kconfig for the accel subsystem. The Kconfig currently contains only the basic CONFIG_DRM_ACCEL option that will be used to decide whether to compile the accel registration code. Therefore, the kconfig option is defined as bool. The accel code will be compiled as part of drm.ko and will be called directly from the DRM core code. The reason we compile it as part of drm.ko and not as a separate module is because of cyclic dependency between drm.ko and the separate module (if it would have existed). This is due to the fact that DRM core code calls accel functions and vice-versa. The accelerator devices will be exposed to the user space with a new, dedicated major number - 261. The accel init function registers the new major number as a char device and create corresponding sysfs and debugfs root entries, similar to what is done in DRM init function. I added a new header called drm_accel.h to include/drm/, that will hold the prototypes of the drm_accel.c functions. In case CONFIG_DRM_ACCEL is set to 'N', that header will contain empty inline implementations of those functions, to allow DRM core code to compile successfully without dependency on CONFIG_DRM_ACCEL. I Updated the MAINTAINERS file accordingly with the newly added folder and I have taken the liberty to appropriate the dri-devel mailing list and the dri-devel IRC channel for the accel subsystem. Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Tested-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by: Melissa Wen <mwen@igalia.com>
2022-11-22Merge tag 'amd-drm-next-6.2-2022-11-18' of ↵Gravatar Dave Airlie 176-1643/+2686
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.2-2022-11-18: amdgpu: - SR-IOV fixes - Clean up DC checks - DCN 3.2.x fixes - DCN 3.1.x fixes - Don't enable degamma on asics which don't support it - IP discovery fixes - BACO fixes - Fix vbios allocation handling when vkms is enabled - Drop buggy tdr advanced mode GPU reset handling - Fix the build when DCN is not set in kconfig - MST DSC fixes - Userptr fixes - FRU and RAS EEPROM fixes - VCN 4.x RAS support - Aldrebaran CU occupancy reporting fix - PSP ring cleanup amdkfd: - Memory limit fix - Enable cooperative launch on gfx 10.3 amd-drm-next-6.2-2022-11-11: amdgpu: - SMU 13.x updates - GPUVM TLB race fix - DCN 3.1.4 updates - DCN 3.2.x updates - PSR fixes - Kerneldoc fix - Vega10 fan fix - GPUVM locking fixes in error pathes - BACO fix for Beige Goby - EEPROM I2C address cleanup - GFXOFF fix - Fix DC memory leak in error pathes - Flexible array updates - Mtype fix for GPUVM PTEs - Move Kconfig into amdgpu directory - SR-IOV updates - Fix possible memory leak in CS IOCTL error path amdkfd: - Fix possible memory overrun - CRIU fixes radeon: - ACPI ref count fix - HDA audio notifier support - Move Kconfig into radeon directory UAPI: - Add new GEM_CREATE flags to help to transition more KFD functionality to the DRM UAPI. These are used internally in the driver to align location based memory coherency requirements from memory allocated in the KFD with how we manage GPUVM PTEs. They are currently blocked in the GEM_CREATE IOCTL as we don't have a user right now. They are just used internally in the kernel driver for now for existing KFD memory allocations. So a change to the UAPI header, but no functional change in the UAPI. From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221118170807.6505-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-11-22Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into ↵Gravatar Dave Airlie 10-37/+138
drm-next please pull the following etnaviv changes for the next merge window. Mostly some small workarounds to get new hardware support going. But also more fixes to the softpin MMU handling and a nice addition from Christian to make the kernel logs on hang detection more useful. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/adcb1b3dec89a18d6c3c4ee6e179b9b2c9f25046.camel@pengutronix.de
2022-11-22Merge tag 'drm-misc-next-2022-11-17' of ↵Gravatar Dave Airlie 108-191/+1331
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-17drm/amdgpu: make psp_ring_init commonGravatar Alex Deucher 9-191/+26
All of the IP specific versions are the same now, so we can just use a common function. Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu/psp12: move ih_reroute into ring_createGravatar Alex Deucher 1-2/+2
This matches what we do for psp 3.1 and makes ring_init common for all PSP versions. Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amd/display: fix kernel-doc issues in dc.hGravatar Randy Dunlap 1-6/+6
Fix these kernel-doc complaints: drivers/gpu/drm/amd/display/dc/dc.h:505: warning: cannot understand function prototype: 'struct dc_clocks ' dc.h:472: warning: Enum value 'MPC_SPLIT_AVOID' not described in enum 'pipe_split_policy' dc.h:472: warning: Enum value 'MPC_SPLIT_AVOID_MULT_DISP' not described in enum 'pipe_split_policy' dc.h:532: warning: Incorrect use of kernel-doc format: * @fw_based_mclk_switching Fixes: ea76895ffab1 ("drm/amd/display: Document pipe split policy") Fixes: 1682bd1a6b5f ("drm/amd/display: Expand kernel doc for DC") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdkfd: enable cooperative launch for gfx10.3Gravatar Jonathan Kim 1-1/+4
FW fix available to enable cooperative launch for GFX10.3. Signed-off-by: Jonathan Kim <jonathan.kim@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: Enable Aldebaran devices to report CU OccupancyGravatar Ramesh Errabolu 1-0/+1
Allow user to know number of compute units (CU) that are in use at any given moment. Enable access to the method kgd_gfx_v9_get_cu_occupancy that computes CU occupancy. Signed-off-by: Ramesh Errabolu <Ramesh.Errabolu@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: add JPEG 4.0 RAS poison consumption handlingGravatar Tao Zhou 1-0/+18
Register related irq handler. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: add VCN 4.0 RAS poison consumption handlingGravatar Tao Zhou 1-0/+10
Register irq handler. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: add irq source id definition for VCN/JPEG 4.0Gravatar Tao Zhou 1-0/+3
Add interrupt source id macros. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: add RAS error query for JPEG 4.0Gravatar Tao Zhou 2-0/+70
Initialize JPEG RAS structure and add error query interface. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: add RAS query support for VCN 4.0Gravatar Tao Zhou 2-0/+66
Initialize VCN RAS structure and add RAS status query function. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: define common jpeg_set_ras_funcsGravatar Tao Zhou 3-12/+19
Make the code reusable. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: define common vcn_set_ras_funcsGravatar Tao Zhou 3-12/+19
So the code can be reused. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: enable RAS for VCN/JPEG v4.0Gravatar Tao Zhou 1-1/+2
Set support flag for VCN/JPEG 4.0. Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: Enable mode-1 reset for RAS recovery in fatal error modeGravatar YiPeng Chai 2-1/+10
The patch is enabling mode-1 reset for RAS recovery in fatal error mode. Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: Add support for RAS table at 0x40000Gravatar Luben Tuikov 1-1/+6
Add support for RAS table at I2C EEPROM address of 0x40000, since on some ASICs it is not at 0, but at 0x40000. Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Kent Russell <kent.russell@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Tested-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: Interpret IPMI data for product information (v2)Gravatar Luben Tuikov 1-98/+85
Don't assume FRU MCU memory locations for the FRU data fields, or their sizes, instead read and interpret the IPMI data, as stipulated in the IPMI spec version 1.0 rev 1.2. Extract the Product Name, Product Part/Model Number, and the Product Serial Number by interpreting the IPMI data. Check the checksums of the stored IPMI data to make sure we don't read and give corrupted data back the the user. Eliminate small I2C reads, and instead read the whole Product Info Area in one go, and then extract the information we're seeking from it. Eliminates a whole function, making this file smaller. v2: Clarify changes in the commit message. Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Kent Russell <kent.russell@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Tested-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: Bug-fix: Reading I2C FRU data on newer ASICsGravatar Luben Tuikov 1-11/+25
Set the new correct default FRU MCU I2C address for newer ASICs, so that we can correctly read the Product Name, Product Part/Model Number and Serial Number. On newer ASICs, the FRU MCU was moved to I2C address 0x58. Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Kent Russell <kent.russell@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Tested-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: Allow non-standard EEPROM I2C addressGravatar Luben Tuikov 1-1/+1
Allow non-standard EEPROM I2C address of 0x58, where the Device Type Identifier is 1011b, where we form 1011000b = 0x58 I2C address, as on some ASICs the FRU data lives there. Cc: Alex Deucher <Alexander.Deucher@amd.com> Cc: Kent Russell <kent.russell@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Tested-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/tests: helpers: Add SPDX headerGravatar Maxime Ripard 2-0/+4
The SPDX header is missing, let's add it and fix the corresponding checkpatch warning. Suggested-by: Maíra Canal <mairacanal@riseup.net> Fixes: 44a3928324e9 ("drm/tests: Add Kunit Helpers") Reviewed-by: Maíra Canal <mairacanal@riseup.net> Link: https://lore.kernel.org/r/20221116151833.1679379-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-17drm/tests: client: Remove extra blank linesGravatar Maxime Ripard 1-2/+0
Some extra blank lines slipped through, remove them. Fixes: 8fc0380f6ba7 ("drm/client: Add some tests for drm_connector_pick_cmdline_mode()") Reviewed-by: Maíra Canal <mairacanal@riseup.net> Link: https://lore.kernel.org/r/20221116151833.1679379-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-17drm/amdgpu: cleanup amdgpu_hmm_range_get_pagesGravatar Christian König 4-21/+11
Remove unused parameters and cleanup dead code. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: rename the files for HMM handlingGravatar Christian König 9-31/+33
Clean that up a bit, no functional change. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: fix userptr HMM range handling v2Gravatar Christian König 7-51/+46
The basic problem here is that it's not allowed to page fault while holding the reservation lock. So it can happen that multiple processes try to validate an userptr at the same time. Work around that by putting the HMM range object into the mutex protected bo list for now. v2: make sure range is set to NULL in case of an error Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> CC: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu: always register an MMU notifier for userptrGravatar Christian König 1-5/+3
Since switching to HMM we always need that because we no longer grab references to the pages. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> CC: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu/dm/dp_mst: Don't grab mst_mgr->lock when computing DSC stateGravatar Lyude Paul 1-4/+0
Now that we've fixed the issue with using the incorrect topology manager, we're actually grabbing the topology manager's lock - and consequently deadlocking. Luckily for us though, there's actually nothing in AMD's DSC state computation code that really should need this lock. The one exception is the mutex_lock() in dm_dp_mst_is_port_support_mode(), however we grab no locks beneath &mgr->lock there so that should be fine to leave be. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu/dm/mst: Use the correct topology mgr pointer in amdgpu_dm_connectorGravatar Lyude Paul 1-19/+18
This bug hurt me. Basically, it appears that we've been grabbing the entirely wrong mutex in the MST DSC computation code for amdgpu! While we've been grabbing: amdgpu_dm_connector->mst_mgr That's zero-initialized memory, because the only connectors we'll ever actually be doing DSC computations for are MST ports. Which have mst_mgr zero-initialized, and instead have the correct topology mgr pointer located at: amdgpu_dm_connector->mst_port->mgr; I'm a bit impressed that until now, this code has managed not to crash anyone's systems! It does seem to cause a warning in LOCKDEP though: [ 66.637670] DEBUG_LOCKS_WARN_ON(lock->magic != lock) This was causing the problems that appeared to have been introduced by: commit 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into the atomic state") This wasn't actually where they came from though. Presumably, before the only thing we were doing with the topology mgr pointer was attempting to grab mst_mgr->lock. Since the above commit however, we grab much more information from mst_mgr including the atomic MST state and respective modesetting locks. This patch also implies that up until now, it's quite likely we could be susceptible to race conditions when going through the MST topology state for DSC computations since we technically will not have grabbed any lock when going through it. So, let's fix this by adjusting all the respective code paths to look at the right pointer and skip things that aren't actual MST connectors from a topology. Gitlab issue: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/display/dp_mst: Fix drm_dp_mst_add_affected_dsc_crtcs() return codeGravatar Lyude Paul 1-1/+1
Looks like that we're accidentally dropping a pretty important return code here. For some reason, we just return -EINVAL if we fail to get the MST topology state. This is wrong: error codes are important and should never be squashed without being handled, which here seems to have the potential to cause a deadlock. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs") Cc: <stable@vger.kernel.org> # v5.6+ Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amdgpu/mst: Stop ignoring error codes and deadlockingGravatar Lyude Paul 3-118/+147
It appears that amdgpu makes the mistake of completely ignoring the return values from the DP MST helpers, and instead just returns a simple true/false. In this case, it seems to have come back to bite us because as a result of simply returning false from compute_mst_dsc_configs_for_state(), amdgpu had no way of telling when a deadlock happened from these helpers. This could definitely result in some kernel splats. V2: * Address Wayne's comments (fix another bunch of spots where we weren't passing down return codes) Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 8c20a1ed9b4f ("drm/amd/display: MST DSC compute fair share") Cc: Harry Wentland <harry.wentland@amd.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amd/display: Align dcn314_smu logging with other DCNsGravatar Roman Li 1-2/+9
[Why] Assert on non-OK response from SMU is unnecessary. It was replaced with respective log message on other asics in the past with commit: "drm/amd/display: Removing assert statements for Linux" [How] Remove assert and add dbg logging as on other DCNs. Signed-off-by: Roman Li <roman.li@amd.com> Reviewed-by: Saaem Rizvi <SyedSaaem.Rizvi@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-17drm/amd/display: fix the build when DRM_AMD_DC_DCN is not setGravatar Alex Deucher 1-1/+1
Move the new callback outside of the guard. Fixes: dc55b106ad47 ("drm/amd/display: Disable phantom OTG after enable for plane disable") CC: Alvin Lee <Alvin.Lee2@amd.com> CC: Alan Liu <HaoPing.Liu@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-11-16drm/etnaviv: switch to PFN mappingsGravatar Lucas Stach 1-5/+6
There is no reason to use page based mappings, as the established mappings are special driver mappings anyways and should not be handled like normal pages. Be consistent with what other drivers do and use raw PFN based mappings. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2022-11-16drm/etnaviv: add HWDB entry for GC7000 r6203Gravatar Marco Felsch 1-0/+31
The GPU is found on the NXP i.MX8MN SoC. The feature bits are taken from the NXP downstream kernel driver 6.4.3.p2. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
2022-11-16drm/tests: helpers: Add module infosGravatar Maxime Ripard 1-0/+3
The MODULE_LICENSE macro is missing from the kunit helpers file, thus leading to a build error. Let's introduce it along with MODULE_AUTHOR. Fixes: 44a3928324e9 ("drm/tests: Add Kunit Helpers") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Link: https://lore.kernel.org/r/20221116091712.1309651-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-16drm/tests: Include helpers headerGravatar Maxime Ripard 1-0/+2
The kunit helpers code weren't including its header, leading to a warning that no previous prototype had been defined for public functions. Include the matching header to fix the warning. Fixes: 44a3928324e9 ("drm/tests: Add Kunit Helpers") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Link: https://lore.kernel.org/r/20221116091712.1309651-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-16drm/edid/firmware: stop using a throwaway platform deviceGravatar Jani Nikula 1-12/+1
We've used a temporary platform device for firmware EDID loading since it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as firmware to override broken monitor"), but there's no explanation why. Using a temporary device does not play well with CONFIG_FW_CACHE=y, which caches firmware images (e.g. on suspend) so that drivers can request firmware when the system is not ready for it, and return the images from the cache (e.g. during resume). This works automatically for regular devices, but obviously not for a temporarily created device. Stop using the throwaway platform device, and use the drm device instead. Note that this may still be problematic for cases where the display was plugged in during suspend, and the firmware wasn't loaded and therefore not cached before suspend. References: https://lore.kernel.org/r/20220727074152.43059-1-matthieu.charette@gmail.com Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061 Reported-by: Matthieu CHARETTE <matthieu.charette@gmail.com> Tested-by: Matthieu CHARETTE <matthieu.charette@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221114111709.434979-1-jani.nikula@intel.com
2022-11-16fbdev: Add support for the nomodeset kernel parameterGravatar Thomas Zimmermann 47-2/+246
Support the kernel's nomodeset parameter for all PCI-based fbdev drivers that use aperture helpers to remove other, hardware-agnostic graphics drivers. The parameter is a simple way of using the firmware-provided scanout buffer if the hardware's native driver is broken. The same effect could be achieved with per-driver options, but the importance of the graphics output for many users makes a single, unified approach worthwhile. With nomodeset specified, the fbdev driver module will not load. This unifies behavior with similar DRM drivers. In DRM helpers, modules first check the nomodeset parameter before registering the PCI driver. As fbdev has no such module helpers, we have to modify each driver individually. The name 'nomodeset' is slightly misleading, but has been chosen for historical reasons. Several drivers implemented it before it became a general option for DRM. So keeping the existing name was preferred over introducing a new one. v2: * print a warning if a driver does not init (Helge) * wrap video_firmware_drivers_only() in helper Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221111133024.9897-3-tzimmermann@suse.de
2022-11-16drm: Move nomodeset kernel parameter to drivers/videoGravatar Thomas Zimmermann 9-19/+39
Move the nomodeset kernel parameter to drivers/video to make it available to non-DRM drivers. Adapt the interface, but keep the DRM interface drm_firmware_drivers_only() to avoid churn within DRM. The function should later be inlined into callers. The parameter disables any DRM graphics driver that would replace a driver for firmware-provided scanout buffers. It is an option to easily fallback to basic graphics output if the hardware's native driver is broken. Moving it to a more prominent location wil make it available to fbdev as well. v2: * clarify the meaning of the nomodeset parameter (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221111133024.9897-2-tzimmermann@suse.de
2022-11-16drm/fb-helper: Remove damage workerGravatar Thomas Zimmermann 2-11/+0
The fbdev damage worker is unused, so remove it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-7-tzimmermann@suse.de
2022-11-16drm/fb-helper: Schedule deferred-I/O worker after writing to framebufferGravatar Thomas Zimmermann 3-1/+25
Schedule the deferred-I/O worker instead of the damage worker after writing to the fbdev framebuffer. The deferred-I/O worker then performs the dirty-fb update. The fbdev emulation will initialize deferred I/O for all drivers that require damage updates. It is therefore a valid assumption that the deferred-I/O worker is present. It would be possible to perform the damage handling directly from within the write operation. But doing this could increase the overhead of the write or interfere with a concurrently scheduled deferred-I/O worker. Instead, scheduling the deferred-I/O worker with its regular delay of 50 ms removes load off the write operation and allows the deferred-I/O worker to handle multiple write operations that arrived during the delay time window. v3: * remove unused variable (lkp) v2: * keep drm_fb_helper_damage() (Daniel) * use fb_deferred_io_schedule_flush() (Daniel) * clarify comments (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-6-tzimmermann@suse.de
2022-11-16drm/fb-helper: Perform damage handling in deferred-I/O helperGravatar Thomas Zimmermann 1-3/+9
Call fb_dirty directly from drm_fb_helper_deferred_io() to avoid the latency of running the damage worker. The deferred-I/O helper drm_fb_helper_deferred_io() runs in a worker thread at regular intervals as part of writing to mmaped framebuffer memory. It used to schedule the fbdev damage worker to flush the framebuffer. Changing this to flushing the framebuffer directly avoids the latency introduced by the damage worker. v2: * remove fb_dirty from defio in separate patch (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-5-tzimmermann@suse.de
2022-11-16drm/fb-helper: Remove test for fb_dirty callback from deferred-I/O helperGravatar Thomas Zimmermann 1-9/+7
The helper for processing deferred I/O on pages has no dependency on the fb_dirty damge-handling callback; so remove the test. In practice, deferred I/O is only used with damage handling and the damage worker already guarantees the presence of the fb_dirty callback. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-4-tzimmermann@suse.de
2022-11-16drm/fb-helper: Move dirty-fb update into helper functionGravatar Thomas Zimmermann 1-2/+8
Move the dirty-fb update from the damage-worker callback into the new helper drm_fb_helper_fb_dirty(), so that it can run outside the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-3-tzimmermann@suse.de
2022-11-16drm/fb-helper: Set damage-clip area in helperGravatar Thomas Zimmermann 1-2/+8
Set the damage area in the new helper drm_fb_helper_add_damage_clip(). It can now be updated without scheduling the damage worker. This change will help to remove the damage worker entirely. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221115115819.23088-2-tzimmermann@suse.de
2022-11-16drm/fourcc: Fix vsub/hsub for Q410 and Q401Gravatar Brian Starkey 1-4/+4
These formats are not subsampled, but that means hsub and vsub should be 1, not 0. Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats") Reported-by: George Kennedy <george.kennedy@oracle.com> Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com> Signed-off-by: Brian Starkey <brian.starkey@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220913144306.17279-1-brian.starkey@arm.com
2022-11-16drm/arm/malidp: remove calls to drm_mode_config_cleanup()Gravatar Danilo Krummrich 1-14/+6
drm_mode_config_init() simply calls drmm_mode_config_init(), hence cleanup is automatically handled through registering drm_mode_config_cleanup() with drmm_add_action_or_reset(). While at it, get rid of the deprecated drm_mode_config_init() and replace it with drmm_mode_config_init() directly. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026155934.125294-6-dakr@redhat.com
2022-11-16drm/arm/malidp: plane: use drm managed resourcesGravatar Danilo Krummrich 1-21/+7
Use drm managed resource allocation (drmm_universal_plane_alloc()) in order to get rid of the explicit destroy hook in struct drm_plane_funcs. Signed-off-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026155934.125294-5-dakr@redhat.com