- 07 Oct, 2021 17 commits
-
-
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:
-
- 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 21 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:
-
