- 07 Oct, 2021 1 commit
-
-
Laurent Pinchart authored
On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU, even when LVDS outputs are not used. For this reason, the rcar-lvds driver probes successfully on those platforms even if no further bridge or panel is connected to the LVDS output, in order to provide the rcar_lvds_clk_enable() and rcar_lvds_clk_disable() functions to the DU driver. If an LVDS output isn't connected, trying to create a DRM connector for the output will fail. Fix this by skipping connector creation in that case, and also skip creation of the DRM encoder as there's no point in an encoder without a connector. Fixes: e9e05694 ("drm: rcar-du: lvds: Convert to DRM panel bridge helper") Reported-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Tested-by:
-
- 28 Sep, 2021 1 commit
-
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.16-2021-09-27' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.16-2021-09-27: amdgpu: - RAS improvements - BACO fixes - Yellow Carp updates - Misc code cleanups - Initial DP 2.0 support - VCN priority handling - Cyan Skillfish updates - Rework IB handling for multimedia engine tests - Backlight fixes - DCN 3.1 power saving improvements - Runtime PM fixes - Modifier support for DCC image stores for gfx 10.3 - Hotplug fixes - Clean up stack related warnings in display code - DP alt mode fixes - Display rework for better handling FP code - Debugfs fixes amdkfd: - SVM fixes - DMA map fixes radeon: - AGP fix From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210927212653.4575-1-alexander.deucher@amd.comSigned-off-by:
Dave Airlie <airlied@redhat.com>
-
- 24 Sep, 2021 1 commit
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.15: UAPI Changes: Cross-subsystem Changes: Core Changes: Driver Changes: - Conversions to dev_err_probe() helper - rockchip: Various build improvements, Use DRM_BRIDGE_ATTACH_NO_CONNECTOR for LVDS and RGB - panel: New panel-edp driver Signed-off-by:
-
- 23 Sep, 2021 37 commits
-
-
Alex Deucher authored
It's not used outside of soc15.c Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Lijo Lazar authored
Update the current state as boot state during dpm initialization. During the subsequent initialization, set_power_state gets called to transition to the final power state. set_power_state refers to values from the current state and without current state populated, it could result in NULL pointer dereference. For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f370 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)"). Bug:https://gitlab.freedesktop.org/drm/amd/-/issues/1698Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Acked-by:
-
Candice Li authored
All code paths under the EAGAIN path in RAS late init are unused. Signed-off-by:
Candice Li <candice.li@amd.com> Reviewed-by:
John Clements <john.clements@amd.com> Signed-off-by:
-
John Clements authored
Explicity post warning if cmd is issued against unsupported IP Update to latest RAS TA interface Reviewed-by:
-
Philip Yang authored
Device manager releases device-specific resources when a driver disconnects from a device, devm_memunmap_pages and devm_release_mem_region calls in svm_migrate_fini are redundant. It causes below warning trace after patch "drm/amdgpu: Split amdgpu_device_fini into early and late", so remove function svm_migrate_fini. BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718 WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795 devm_release_action+0x51/0x60 Call Trace: ? memunmap_pages+0x360/0x360 svm_migrate_fini+0x2d/0x60 [amdgpu] kgd2kfd_device_exit+0x23/0xa0 [amdgpu] amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu] amdgpu_device_fini_sw+0x45/0x290 [amdgpu] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] drm_dev_release+0x20/0x40 [drm] release_nodes+0x196/0x1e0 device_release_driver_internal+0x104/0x1d0 driver_detach+0x47/0x90 bus_remove_driver+0x7a/0xd0 pci_unregister_driver+0x3d/0x90 amdgpu_exit+0x11/0x20 [amdgpu] Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
-
Philip Yang authored
If svm migration init failed to create pgmap for device memory, set pgmap type to 0 to disable device SVM support capability. Signed-off-by:
-
John Clements authored
Update RAS infrastructure to support RAS query for MCA subblocks Reviewed-by:
-
Guchun Chen authored
adev->rmmio is set to be NULL in amdgpu_device_unmap_mmio to prevent access after pci_remove, however, in SRIOV case, amdgpu_virt_release_full_gpu will still use adev->rmmio for access after amdgpu_device_unmap_mmio. The patch is to move such SRIOV calling earlier to fini_early stage. Fixes: 07775fc1 ("drm/amdgpu: Unmap all MMIO mappings") Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
Leslie Shi <Yuliang.Shi@amd.com> Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Signed-off-by:
-
Hayden Goodfellow authored
[Why] Currently, the 32bit kernel build fails due to an incorrect string format specifier. ARRAY_SIZE() returns size_t type as it uses sizeof(). However, we specify it in a string as %ld. This causes a compiler error and causes the 32bit build to fail. [How] Change the %ld to %zu as size_t (which sizeof() returns) is an unsigned integer data type. We use 'z' to ensure it also works with 64bit build. Reviewed-by:
Harry Wentland <Harry.Wentland@amd.com> Acked-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
Hayden Goodfellow <Hayden.Goodfellow@amd.com> Signed-off-by:
-
Aric Cyr authored
This new DC version brings improvements in the following areas: - New firmware version - Fix HPD problems on DCN2 - Fix generic encoder problems and null deferences - Adjust DCN301 watermark - Rework dynamic bpp for DCN3x - Improve link training fallback logic Acked-by:
Aric Cyr <aric.cyr@amd.com> Signed-off-by:
-
Anthony Koo authored
Acked-by:
Anthony Koo <Anthony.Koo@amd.com> Signed-off-by:
-
Jimmy Kizito authored
[Why] Links which are dynamically assigned link encoders have their link encoder set to NULL. [How] Check that a pointer to a link_encoder object is non-NULL before using it. Reviewed-by:
Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Acked-by:
Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by:
-
Meenakshikumar Somasundaram authored
[Why] Need a bit for x86 driver to enable a FW boot option for an upcoming feature. [How] Added a bit in dmub_fw_boot_options for an upcoming feature. Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Liu, Zhan authored
[Why] DIG mapping change is causing a blocker [How] Revert the change for now. We will re-implement it later. Reviewed-by:
Zhan Liu <Zhan.Liu@amd.com> Signed-off-by:
-
Liu, Zhan authored
[Why] Starting from B0, along with RDPCSTX, RDPCSPIPE registers are also used. [How] Make sure RDPCSPIPE registers are programmed correctly. Reviewed-by:
Charlene Liu <charlene.liu@amd.com> Acked-by:
-
Michael Strauss authored
[WHY] Currently causes visible flicker in some scenarios on OLED eDPs Reviewed-by:
Haonan Wang <haonan.wang2@amd.com> Acked-by:
Michael Strauss <michael.strauss@amd.com> Signed-off-by:
-
Guo, Bing authored
Why: Screen sometimes would have artifacts or blink once at the time when bpp is dynamically changed. How: 1. Changed to update PPS infopacket in frame mode instead of immediate mode since other updates for bpp change are double-buffered. 2. Changed double-buffering enablement programming for DCN30 as advised by ASIC team Reviewed-by:
Wenjing Liu <wenjing.liu@amd.com> Acked-by:
Bing Guo <Bing.Guo@amd.com> Signed-off-by:
-
Nikola Cornij authored
[why] If DCN30 watermark calc is used for DCN301, the calculated values are wrong due to the data structure mismatch between DCN30 and DCN301. However, using the original DCN301 watermark values causes underflow. [how] - Add DCN21-style watermark calculations - Adjust DCN301 watermark values to remove the underflow Reviewed-by:
Nikola Cornij <nikola.cornij@amd.com> Signed-off-by:
-
Lai, Derek authored
[Why] The change of setting a timer callback on boot for 10 seconds is still working, just lost power down on boot and power down for DCN3. [How] Added power down on boot and power down for DCN3. Reviewed-by:
Derek Lai <Derek.Lai@amd.com> Signed-off-by:
-
Jimmy Kizito authored
[Why] Incorrect encoder assignments were being used while applying a new state to hardware. (1) When committing a new state to hardware requires resetting the back-end, the encoder assignments of the current or old state should be used when disabling the back-end; and the encoder assignments for the next or new state should be used when re-enabling the back-end. (2) Link training on hot plug could take over an encoder already in use by another stream without first disabling it. [How] (1) Introduce a resource context 'link_enc_cfg_context' which includes: - a mode to indicate when transitioning from current to next state. - transient encoder assignments to use during this state transition. Update the encoder configuration interface to respond to queries about encoder assignment based on the mode of operation. (2) Check if an encoder is already in use before attempting to perform link training on hot plug. Reviewed-by:
-
Jimmy Kizito authored
[Why] Trying to enable multiple displays simultaneously exposed shortcomings with the algorithm for dynamic link encoder assignment. The main problems were: - Assuming stream order remained constant across states would sometimes lead to invalid DIG encoder assignment. - Incorrect logic for deciding whether or not a DIG could support a stream would also sometimes lead to invalid DIG encoder assignment. - Changes in encoder assignment were wholesale while updating of the pipe backend is incremental. This would lead to the hardware state not matching the software state even with valid encoder assignments. [How] The following changes fix the identified problems. - Use stream pointer rather than stream index to track streams across states. - Fix DIG compatibility check by examining the link signal type rather than the stream signal type. - Modify assignment algorithm to make incremental updates so software and hardware states remain coherent. Additionally: - Add assertions and an encoder assignment validation function link_enc_cfg_validate() to detect potential problems with encoder assignment closer to their root cause. - Reduce the frequency with which the assignment algorithm is executed. It should not be necessary for fast state validation. Reviewed-by:
-
Jimmy Kizito authored
[Why] Link training should fail if stream bandwidth exceeds link bandwidth. [How] Correct fallback logic and use named variables to make intention clear. Reviewed-by:
-
Liu, Zhan authored
[Why] DCN3 B0 has a mux, which redirects PHYC and PHYD to PHYF and PHYG. [How] Fix DIG mapping. Reviewed-by:
-
Aric Cyr authored
Acked-by:
-
Anthony Koo authored
Acked-by:
-
Qingqing Zhuo authored
[Why] HPD disable and enable sequences are not mutually exclusive on Linux. For HPDs that spans under 1s (i.e. HPD low = 1s), part of the disable sequence (specifically, a request to SMU to lower refclk) could come right before the call to PHY enablement, causing DMUB to access an irresponsive PHY and thus a hard hang on the system. [How] Disable 48mhz refclk off when there is any HPD status in connected state for dcn20. Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
-
Harry Wentland authored
[Why & How] With Werror enabled in the kernel we were failing the clang build since dml21_ModeSupportAndSystemConfigurationFull's stack frame is 1064 when building with clang, and exceeding the default 1024 stack frame limit. The culprit seems to be the Pipe struct, so pull the relevant block out into its own sub-function. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Signed-off-by:
-
Harry Wentland authored
[Why & How] dcn_bw_calc_rq_dlg_ttu uses a stack frame great than 1024. To solve this we could allocate the rq_param, dlg_sys_param, and input structs dynamically. Since this function is inside a kernel_fpu_begin()/end() call we want to avoid memory allocation. Instead it's much safer to pre-allocate these on the pipe_ctx. Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
-
Harry Wentland authored
Passing structs adds a lot of overhead. We don't ever want to pass anything bigger than primitives by value. This patch fixes these Coverity IDs: Addresses-Coverity-ID: 1424031: ("Big parameter passed by value") Addresses-Coverity-ID: 1424055: ("Big parameter passed by value") Addresses-Coverity-ID: 1424072: ("Big parameter passed by value") Addresses-Coverity-ID: 1423779: ("Big parameter passed by value") Signed-off-by: -
Harry Wentland authored
Passing structs adds a lot of overhead. We don't ever want to pass anything bigger than primitives by value. This patch fixes these Coverity IDs: Addresses-Coverity-ID: 1423868: ("Big parameter passed by value") Addresses-Coverity-ID: 1423870: ("Big parameter passed by value") Signed-off-by: -
Harry Wentland authored
[Why] This neither needs to be on the stack nor passed by value to each function call. In fact, when building with clang it seems to break the Linux's default 1024 byte stack frame limit. [How] We can simply pass this as a const pointer. This patch fixes these Coverity IDs Addresses-Coverity-ID: 1424031: ("Big parameter passed by value") Addresses-Coverity-ID: 1423970: ("Big parameter passed by value") Addresses-Coverity-ID: 1423941: ("Big parameter passed by value") Addresses-Coverity-ID: 1451742: ("Big parameter passed by value") Addresses-Coverity-ID: 1451887: ("Big parameter passed by value") Addresses-Coverity-ID: 1454146: ("Big parameter passed by value") Addresses-Coverity-ID: 1454152: ("Big parameter passed by value") Addresses-Coverity-ID: 1454413: ("Big parameter passed by value") Addresses-Coverity-ID: 1466144: ("Big parameter passed by value") Addresses-Coverity-ID: 1487237: ("Big parameter passed by value") Signed-off-by: -
Philip Yang authored
For xnack off, restore work dma unmap previous system memory page, and dma map the updated system memory page to update GPU mapping, this is not dma mapping leaking, remove the WARN_ONCE for dma mapping leaking. prange->dma_addr store the VRAM page pfn after the range migrated to VRAM, should not dma unmap VRAM page when updating GPU mapping or remove prange. Add helper svm_is_valid_dma_mapping_addr to check VRAM page and error cases. Mask out SVM_RANGE_VRAM_DOMAIN flag in dma_addr before calling amdgpu vm update to avoid BUG_ON(*addr & 0xFFFF00000000003FULL), and set it again immediately after. This flag is used to know the type of page later to dma unmapping system memory page. Fixes: 1d5dbfe6 ("drm/amdkfd: classify and map mixed svm range pages in GPU") Signed-off-by:
-
Philip Yang authored
SVM range may includes multiple VMAs with different vm_flags, if prange page index is the last page of the VMA offset + npages, update GPU mapping to create GPU page table with same VMA access permission. Signed-off-by:
-
Alex Deucher authored
Fix the path to cover both the older powerplay infrastructure and the newer SwSMU infrastructure. Reviewed-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Arnd Bergmann authored
Using an empty macro expansion as a conditional expression produces a W=1 warning: drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c: In function 'dce_aux_transfer_with_retries': drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:775:156: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 775 | "dce_aux_transfer_with_retries: AUX_RET_SUCCESS: AUX_TRANSACTION_REPLY_I2C_OVER_AUX_DEFER"); | ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_aux.c:783:155: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 783 | "dce_aux_transfer_with_retries: AUX_RET_SUCCESS: AUX_TRANSACTION_REPLY_I2C_OVER_AUX_NACK"); | ^ Expand it to "do { } while (0)" instead to make the expression more robust and avoid the warning. Fixes: 56aca230 ("drm/amd/display: Add AUX I2C tracing.") Signed-off-by: -
Andrey Grodzovsky authored
Problem: When device goes into suspend and unplugged during it then all HW programming during resume fails leading to a bad SW during pci remove handling which follows. Because device is first resumed and only later removed we cannot rely on drm_dev_enter/exit here. Fix: Use a flag we use for PCIe error recovery to avoid accessing registres. This allows to successfully complete pm resume sequence and finish pci remove. Signed-off-by:
-
Andrey Grodzovsky authored
Add more guards to MMIO access post device unbind/unplug Bug: https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1Signed-off-by:
James Zhu <James.Zhu@amd.com> Signed-off-by:
-
