- 11 Oct, 2021 1 commit
-
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.16-2021-10-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.16-2021-10-08: amdgpu: - gart BO pin count fix - RAS fixes - Misc display fixes - Misc code cleanups - Validate IP discovery table - IOMMU handling fixes for hotplug - Cyan Skillfish display support - DP 2.0 fixes - Covert vega and navi to IP discovery based asic enumeration - JPEG fixes - More FP cleanup for display - DCC fixes for DCN3.x - Initial USB4 DP tunnelling support - Aldebaran MCE support amdkfd: - Misc bug fixes - Misc code cleanups - RAS fixes x86/MCE: - Export symbol for use by GPU driver Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211008200345.4689-1-alexander.deucher@amd.com
-
- 08 Oct, 2021 9 commits
-
-
kernel test robot authored
Generated by: scripts/checkincludes.pl Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Lv Ruyi authored
Remove all but the first include of reg_helper.h and core_types.h from dcn201_clk_mgr.c. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Lv Ruyi <lv.ruyi@zte.com.cn> Signed-off-by:
-
Guchun Chen authored
adev_to_drm is used everywhere, so improve recent changes when accessing drm_device pointer from amdgpu_device. Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Sierra authored
This fix the deadlock with the BO reservations during SVM_BO evictions while allocations in VRAM are concurrently performed. More specific, while the ttm waits for the fence to be signaled (ttm_bo_wait), it already has the BO reserved. In parallel, the restore worker might be running, prefetching memory to VRAM. This also requires to reserve the BO, but blocks the mmap semaphore first. The deadlock happens when the SVM_BO eviction worker kicks in and waits for the mmap semaphore held in restore worker. Preventing signal the fence back, causing the deadlock until the ttm times out. We don't need to hold the BO reservation anymore during validation and mapping. Now the physical addresses are taken from hmm_range_fault. We also take migrate_mutex to prevent range migration while validate_and_map update GPU page table. Signed-off-by:
Alex Sierra <alex.sierra@amd.com> Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Philip Yang <philip.yang@amd.com> Signed-off-by:
-
Wayne Lin authored
[Why & How] Got Werror when building with Clang-13: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:195:2: error: variable 'ts' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized] default: ^~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:200:9: note: uninitialized use occurs here return ts; ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:180:2: note: variable 'ts' is declared here enum dpia_set_config_ts ts; ^ 1 error generated. Fix it. Reported-by:Mike Lothian <mike@fireburn.co.uk> Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> Acked-by:
-
Alex Deucher authored
Missing 4.1.2. Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by:
-
Colin Ian King authored
The variable result is being initialized with a value that is never read, it is being updated immediately afterwards in both branches of an if statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Alex Deucher authored
Was missed when converting the driver over to IP based initialization. Tested-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
R-Car DU improvements & enhancements to misc drivers Most notably, - Non-contiguous buffer import support for rcar-du - r8a779a0 support preparation for rcar-du - COMPILE_TEST fixes for omapdrm and sti Signed-off-by:
-
- 07 Oct, 2021 18 commits
-
-
Nirmoy Das authored
Unify BO evicting functionality for possible memory types in amdgpu_ttm.c. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
-
Kieran Bingham authored
Extend the rcar_du_device_info structure and rcar_du_output enum to support DSI outputs and utilise these additions to provide support for the R8A779A0 V3U platform. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
-
Kieran Bingham authored
Not all platforms require both per-crtc IRQ and per-crtc clock management. In preparation for suppporting such platforms, split the feature macro to be able to specify both features independently. The other features are incremented accordingly, to keep the two crtc features adjacent. Reviewed-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by:
-
Kieran Bingham authored
The DIDSR fields named LDCS were incorrectly defined as LCDS. Both the Gen2 and Gen3 documentation refer to the fields as the "LVDS Dot Clock Select". Correct the definitions. Reviewed-by:
-
Kieran Bingham authored
The R-Car DU as found on the D3, E3, and V3U do not have support for an external synchronisation method. In these cases, the dsysr cached register should not be initialised in DSYSR_TVM_TVSYNC, but instead should be left clear to configure as DSYSR_TVM_MASTER by default. Reviewed-by:
-
Kieran Bingham authored
Sort the DU outputs alphabetically, with the exception of the final entry which is there as a sentinal. Reviewed-by:
-
Kieran Bingham authored
Extend the Renesas DU display bindings to support the r8a779a0 V3U. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Reviewed-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Laurent Pinchart authored
The correct format specifier for size_t is %zu. Using %d (or %u) generates a warning on 64-bit platforms. Fix it. Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com>
-
Laurent Pinchart authored
The driver accesses the drm_bridge.of_node field, which is present only if CONFIG_OF is enabled. As all platforms using omapdrm are OF-based, we can simply depend on CONFIG_OF. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Laurent Pinchart authored
On 64-bit platforms, the compiler complains that casting a void pointer to an unsigned int loses data. Cast the pointer to a uintptr_t to fix this. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
-
Laurent Pinchart authored
The correct format specifier for size_t is %zu. Using %d (or %u) generates a warning on 64-bit platforms. Fix it. Signed-off-by:
-
Laurent Pinchart authored
strncpy() is widely regarded as unsafe due to the fact that it may leave the destination string without a nul-termination when the source string size is too large. When compiling the kernel with W=1, the gcc warns about this: drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’: drivers/gpu/drm/drm_property.c:130:2: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] 130 | strncpy(property->name, name, DRM_PROP_NAME_LEN); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are three occurrences of strncpy() in drm_property.c. None of them are actually unsafe, as the very next line forces nul-termination of the destination buffer. The warning is thus a false positive, but adds noise to the kernel log. It can easily be silenced by using strscpy_pad() instead. Do so. One of the three occurrences, in drm_property_add_enum(), fills a char array that is later copied to userspace with copy_to_user() in drm_mode_getproperty_ioctl(). To avoid leaking kernel data, strscpy_pad() is required. Similarly, a second occurrence, in drm_mode_getproperty_ioctl(), copies the string to an ioctl data buffer that isn't previously zero'ed, to strscpy_pad() is also required. The last occurrence, in drm_property_create(), would be safe to replace with strscpy(), as the destination buffer is copied to userspace with strscpy_pad(). However, given that this isn't in a hot path, let's avoid future data leaks in case someone copies the whole char array blindly. Signed-off-by: -
Laurent Pinchart authored
On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA from memory and composition of planes. The DU hardware then only handles the video timings and the interface with the encoders. This differs from Gen2, where the DU included a composer with DMA engines. When sourcing from the VSP, the DU hardware performs no memory access, and thus has no requirements on imported dma-buf memory types. The GEM CMA helpers however still create a DMA mapping to the DU device, which isn't used. The mapping to the VSP is done when processing the atomic commits, in the plane .prepare_fb() handler. When the system uses an IOMMU, the VSP device is attached to it, which enables the VSP to use non physically contiguous memory. The DU, as it performs no memory access, isn't connected to the IOMMU. The GEM CMA drm_gem_cma_prime_import_sg_table() helper will in that case fail to map non-contiguous imported dma-bufs, as the DMA mapping to the DU device will have multiple entries in its sgtable. The prevents using non physically contiguous memory for display. The DRM PRIME and GEM CMA helpers are designed to create the sgtable when the dma-buf is imported. By default, the device referenced by the drm_device is used to create the dma-buf attachment. Drivers can use a different device by using the drm_gem_prime_import_dev() function. While the DU has access to the VSP device, this won't help here, as different CRTCs use different VSP instances, connected to different IOMMU channels. The driver doesn't know at import time which CRTC a GEM object will be used, and thus can't select the right VSP device to pass to drm_gem_prime_import_dev(). To support non-contiguous memory, implement a custom .gem_prime_import_sg_table() operation that accepts all imported dma-buf regardless of the number of scatterlist entries. The sgtable will be mapped to the VSP at .prepare_fb() time, which will reject the framebuffer if the VSP isn't connected to an IOMMU. Signed-off-by:
-
Laurent Pinchart authored
The DU DMA address space is limited to 32 bits, so the DMA coherent mask should be set accordingly. The DMA mapping implementation will transparently map high memory buffers to 32-bit addresses through an IOMMU when present (or through bounce buffers otherwise, which isn't a supported use case as performances would be terrible). However, when sourcing frames from a VSP, the situation is more complicated. The DU delegates all memory accesses to the VSP and doesn't perform any DMA access by itself. Due to how the GEM CMA helpers are structured buffers are still mapped to the DU device. They are later mapped to the VSP as well to perform DMA access, through the IOMMU connected to the VSP. Setting the DMA coherent mask to 32 bits for the DU when using a VSP can cause issues when importing a dma_buf. If the buffer is located above the 32-bit address space, the DMA mapping implementation will try to map it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer will be allocated, which in the best case will waste memory and in the worst case will just fail. To work around this issue, set the DMA coherent mask to the full 40-bit address space for the DU. All dma-buf instances will be imported without any restriction, and will be mapped to the VSP when preparing the associated framebuffer. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com>
-
Laurent Pinchart authored
Improve the debugging and error messages printing when initializing encoders by replacing the output number by the output name, printing the bridge OF node name, and the error code of failed operations. While at it, move the related rcar_du_output enumeration from rcar_du_crtc.h to rcar_du_drv.h as it's not specific to the CRTC. Signed-off-by: -
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:
-
- 06 Oct, 2021 12 commits
-
-
Solomon Chiu authored
[Why] For those video format with 60 fps, the user space player could ask for 120Hz for playback. [How] Add 120 in the table of common rates. Signed-off-by:
Solomon Chiu <solomon.chiu@amd.com> Signed-off-by:
-
Mukul Joshi authored
On Aldebaran, GPU driver will handle bad page retirement for GPU memory even though UMC is host managed. As a result, register a bad page retirement handler on the mce notifier chain to retire bad pages on Aldebaran. Signed-off-by:
Mukul Joshi <mukul.joshi@amd.com> Reviewed-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
-
Mukul Joshi authored
Export smca_get_bank_type for use in the AMD GPU driver to determine MCA bank while handling correctable and uncorrectable errors in GPU UMC. Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Nirmoy Das authored
Check first if debugfs is initialized before creating amdgpu debugfs files. References: https://gitlab.freedesktop.org/drm/amd/-/issues/1686Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Jude Shih authored
[Why] YELLOW_CARP_B0 address was not correct [How] Set YELLOW_CARP_B0 to 0x1A. Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by:
Jude Shih <shenshih@amd.com> Signed-off-by:
-
Jude Shih authored
[Why] Condition variable sometimes terminated unexpectedly [How] Use wait_for_completion_timeout to avoid unexpected termination of CV Reviewed-by:
-
Jude Shih authored
[why] 1. HPD callback function has deadlock problem 2. HPD status is not assigned 3. There is crash due to null pointer 4. link_enc is NULL in DPIA case [How] 1. Fix deadlock problem by moving it out of the drm_modeset_lock 2. Assign HPD status from the notify of outbox from dmub FW 3. Fix the crash by checking if pin or enc exists 4. Use link_enc_cfg_get_link_enc_used_by_link to dynamically assign Reviewed-by:
-
Meenakshikumar Somasundaram authored
[Why & How] 1. Remove unnecessary dummy interrupt source for USB4 HPD & HPD RX 2. Adjust parameter for DPCD writing of link training process of DPIA link 3. Adjust specific AUX defer delay for DPIA link Reviewed-by:
Jimmy Kizito <Jimmy.Kizito@amd.com> Acked-by:
Meenakshikumar Somasundaram <meenakshikumar.somasundaram@amd.com> Signed-off-by:
-
Jimmy Kizito authored
[Why & How] Additional debug flags that can be useful for testing USB4 DP link training. Add flags: - 0x2 : Forces USB4 DP link to non-LTTPR mode - 0x4 : Extends status read intervals to about 60s. Reviewed-by:
Jun Lei <Jun.Lei@amd.com> Acked-by:
-
Jimmy Kizito authored
[Why] DIB_BE_CNTL<i>.DIG_HPD_SELECT selects the HPD block being used by the display endpoint assigned to DIG<i>. In the case of USB4 display endpoints, no physical HPD block is assigned. [How] Setting DIB_BE_CNTL<i>.DIG_HPD_SELECT to 5 indicates that no HPD is assigned to a display endpoint. Firmware decrements the HPD_SELECT value by 1 before writing it to the register. Reviewed-by:
-
Jude Shih authored
[Why] To process SET_CONFIG transactions with DMUB using inbox1 and outbox1 mail boxes. [How] 1) DMUB posts SET_CONFIG reply as an Outbox1 message of type DMUB_OUT_CMD__SET_CONFIG_REPLY. 2) The dmub async to sync mechanism for AUX is modified to accommodate SET_CONFIG commands for both command issue and reply code paths. Reviewed-by:
-
Meenakshikumar Somasundaram authored
[Why & How] To add support for dpia debug options. Reviewed-by:
-
