- 26 May, 2021 2 commits
-
-
Thomas Zimmermann authored
Drivers may want to set their own callbacks for a VM area. Only set TTM's callbacks if the vm_ops field is clear. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210525151055.8174-2-tzimmermann@suse.de
-
Andrey Grodzovsky authored
Problem: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:332:1: warning: unused label 'exit' [-Wunused-label] exit: ^~~~~ Fix: Put #ifdef CONFIG_64BIT around exit Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
-
- 25 May, 2021 6 commits
-
-
Andrey Grodzovsky authored
Problem: When device goes into runtime suspend due to prolonged inactivity (e.g. BACO sleep) and then hot unplugged, PCI core will try to wake up the device as part of unplug process. Since the device is gone all HW programming during rpm resume fails leading to a bad SW state later during pci remove handling. Fix: Use a flag we use for PCIe error recovery to avoid accessing registres. This allows to successfully complete rpm resume sequence and finish pci remove. v2: Renamed HW access block flag Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1081 Link: https://patchwork.freedesktop.org/patch/msgid/20210521204122.762288-2-andrey.grodzovsky@amd.com
-
Andrey Grodzovsky authored
Make it's name not feature but function descriptive. Signed-off-by:
-
Paul Cercueil authored
Alloc GEM buffers backed by noncoherent memory on SoCs where it is actually faster than write-combine. This dramatically speeds up software rendering on these SoCs, even for tasks where write-combine memory should in theory be faster (e.g. simple blits). v3: The option is now selected per-SoC instead of being a module parameter. v5: - Fix drm_atomic_get_new_plane_state() used to retrieve the old state - Use custom drm_gem_fb_create() - Only check damage clips and sync DMA buffers if non-coherent buffers are used Signed-off-by:Paul Cercueil <paul@crapouillou.net> Acked-by:
-
Paul Cercueil authored
This function can be used by drivers that use damage clips and have CMA GEM objects backed by non-coherent memory. Calling this function in a plane's .atomic_update ensures that all the data in the backing memory have been written to RAM. v3: - Only sync data if using GEM objects backed by non-coherent memory. - Use a drm_device pointer instead of device pointer in prototype v5: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Move to drm_fb_cma_helper.c to avoid circular dependency Signed-off-by: -
Paul Cercueil authored
Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on some Ingenic SoCs, where even simple blits (e.g. memcpy) are about three times faster using this method. Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which can be set by the drivers when they create the dumb buffer. Since this really only applies to software rendering, disable this flag as soon as the CMA objects are exported via PRIME. v3: New patch. Now uses a simple 'map_noncoherent' flag to control how the objects are mapped, and use the new dma_mmap_pages function. v4: Make sure map_noncoherent is always disabled when creating GEM objects meant to be used with dma-buf. Signed-off-by: -
Zou Wei authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/1621840854-105978-1-git-send-email-zou_wei@huawei.com
-
- 24 May, 2021 15 commits
-
-
Douglas Anderson authored
The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe(): > Drivers in ->remove() callback should undo the runtime PM changes done > in ->probe(). Usually this means calling pm_runtime_disable(), > pm_runtime_dont_use_autosuspend() etc. We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove(). Fixes: 3235b0f2 ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210517130450.v7.1.I9e947183e95c9bd067c9c1d51208ac6a96385139@changeid
-
Maxime Ripard authored
It looks like some displays (like the LG 27UL850-W) don't enable the scrambling when the HDMI driver enables it. However, if we set later the scrambler enable bit, the display will work as expected. Let's create delayed work queue to periodically look at the display scrambling status, and if it's not set yet try to enable it again. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-12-maxime@cerno.tech
-
Maxime Ripard authored
The HDMI controller on the BCM2711 includes a scrambler in order to reach the HDMI 2.0 modes that require it. Let's add the support for it. Acked-by:
-
Maxime Ripard authored
In order to reach the frequencies needed to output at 594MHz, the firmware needs to be configured with the appropriate parameters in the config.txt file (enable_hdmi_4kp60 and force_turbo). Let's detect it at bind time, warn the user if we can't, and filter out the relevant modes. Acked-by:
-
Maxime Ripard authored
The BVB clock rate computation doesn't take into account a mode clock of 594MHz that we're going to need to support 4k60. Acked-by:
-
Maxime Ripard authored
We'll need to have the HVS binding before the HDMI controllers so that we can check whether the firmware allows to run in 4kp60. Reorder a bit the component list, and document the current constraints we're aware of. Acked-by:
-
Maxime Ripard authored
Since we fixed the hooks to disable the encoder at boot, we now have an unbalanced clk_disable call at boot since we never enabled them in the first place. Let's mimic the state of the hardware and enable the clocks at boot if the controller is enabled to get the use-count right. Cc: <stable@vger.kernel.org> # v5.10+ Fixes: 09c43813 ("drm/vc4: hdmi: Implement finer-grained hooks") Signed-off-by:
-
Maxime Ripard authored
At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a state yet and thus will not be able to figure out which connector is attached to our CRTC. However, we have a muxing bit in the CRTC register we can use to get the encoder currently connected to the pixelvalve. We can thus read that register, lookup the associated register through the vc4_pv_data structure, and then pass it to vc4_crtc_disable so that we can perform the proper operations. Fixes: 875a4d53 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by:
-
Maxime Ripard authored
The vc4_get_crtc_encoder function currently only works when the connector->state->crtc pointer is set, which is only true when the connector is currently enabled. However, we use it as part of the disable path as well, and our lookup will fail in that case, resulting in it returning a null pointer we can't act on. We can access the connector that used to be connected to that crtc though using the old connector state in the disable path. Since we want to support both the enable and disable path, we can support it by passing the state accessor variant as a function pointer, together with the atomic state. Fixes: 792c3132 ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by:
-
Maxime Ripard authored
The vc4_crtc_config_pv will need to access the drm_atomic_state structure and its only parent function, vc4_crtc_atomic_enable already has access to it. Let's pass it as a parameter. Fixes: 792c3132 ("drm/vc4: encoder: Add finer-grained encoder callbacks") Signed-off-by:
-
Maxime Ripard authored
The vc4_set_crtc_possible_masks is meant to run over all the encoders and then set their possible_crtcs mask to their associated pixelvalve. However, since the commit 39fcb280 ("drm/vc4: txp: Turn the TXP into a CRTC of its own"), the TXP has been turned to a CRTC and encoder of its own, and while it does indeed register an encoder, it no longer has an associated pixelvalve. The code will thus run over the TXP encoder and set a bogus possible_crtcs mask, overriding the one set in the TXP bind function. In order to fix this, let's skip any virtual encoder. Cc: <stable@vger.kernel.org> # v5.9+ Fixes: 39fcb280 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by:
-
Maxime Ripard authored
The current code does a binary OR on the possible_crtcs variable of the TXP encoder, while we want to set it to that value instead. Cc: <stable@vger.kernel.org> # v5.9+ Fixes: 39fcb280 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by:
-
Mateusz Kwiatkowski authored
The VEC's DAC on BCM2711 is slightly different compared to the one on BCM283x and needs different configuration. In particular, bit 3 (mask 0x8) switches the BCM2711 DAC input to "self-test input data", which makes the output unusable. Separating two compatible variants in devicetrees and the DRM driver was therefore necessary. The configurations used for both variants have been borrowed from Raspberry Pi (model 3B for BCM283x, 4B for BCM2711) firmware defaults. Signed-off-by:
Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Signed-off-by:
-
Mateusz Kwiatkowski authored
The BCM2711 VEC uses a slightly different, incompatible, setup than the one used for the earlier SoC. Add a new compatible for it. Signed-off-by:
-
Mateusz Kwiatkowski authored
On the BCM2711 (Raspberry Pi 4), the VEC is actually connected to output 2 of pixelvalve3. NOTE: This contradicts the Broadcom docs, but has been empirically tested and confirmed by Raspberry Pi firmware devs. Signed-off-by:
-
- 22 May, 2021 1 commit
-
-
Thomas Zimmermann authored
Backmerging from drm/drm-next to the patches for AMD devices for v5.14. Signed-off-by:
-
- 21 May, 2021 5 commits
-
-
Zhen Lei authored
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210511091344.4508-1-thunder.leizhen@huawei.com
-
Linus Walleij authored
The dev_info():s in the DSI driver are very talkative, depromote these to dev_dbg(). Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210313230913.4108256-1-linus.walleij@linaro.org
-
Corentin Labbe authored
Converts display/faraday,tve200.txt to yaml. Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.14-2021-05-21' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.14-2021-05-21: amdgpu: - RAS fixes - SR-IOV fixes - More BO management cleanups - Aldebaran fixes - Display fixes - Support for new GPU, Beige Goby - Backlight fixes amdkfd: - RAS fixes - DMA mapping fixes - HMM SVM fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210521045743.4047-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.14-2021-05-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.14-2021-05-19: amdgpu: - Aldebaran updates - More LTTPR display work - Vangogh updates - SDMA 5.x GCR fixes - RAS fixes - PCIe ASPM support - Modifier fixes - Enable TMZ on Renoir - Buffer object code cleanup - Display overlay fixes - Initial support for multiple eDP panels - Initial SR-IOV support for Aldebaran - DP link training refactor - Misc code cleanups and bug fixes - SMU regression fixes for variable sized arrays - MAINTAINERS fixes for amdgpu amdkfd: - Initial SR-IOV support for Aldebaran - Topology fixes - Initial HMM SVM support - Misc code cleanups and bug fixes radeon: - Misc code cleanups and bug fixes - SMU regression fixes for variable sized arrays - Flickering fix for Oland with multiple 4K displays UAPI: - amdgpu: Drop AMDGPU_GEM_CREATE_SHADOW flag. This was always a kernel internal flag and userspace use of it has always been blocked. It's no longer needed so remove it. - amdkgd: HMM SVM support Overview: https://patchwork.freedesktop.org/series/85562/ Porposed userspace: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/tree/fxkamd/hmm-wipSigned-off-by:
-
- 20 May, 2021 11 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2021-05-19-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Core Changes: - drm: Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP spec (Jose). Driver Changes: - Display plane clock rates fixes and improvements (Ville). - Uninint DMC FW loader state during shutdown (Imre). - Convert snprintf to sysfs_emit (Xuezhi). - Fix invalid access to ACPI _DSM objects (Takashi). - A big refactor around how i915 addresses the graphics and display IP versions. (Matt, Lucas). - Backlight fix (Lyude). - Display watermark and DBUF fixes (Ville). - HDCP fix (Anshuman). - Improve cases where display is not available (Jose). - Defeature PSR2 for RKL and ALD-S (Jose). - VLV DSI panel power fixes and improvements (Hans). - display-12 workaround (Jose). - Fix modesetting (Imre). - Drop redundant address-of op before lttpr_common_caps array (Imre). - Fix compiler checks (Jose, Jason). - GLK display fixes (Ville). - Fix error code returns (Dan). - eDP novel: back again to slow and wide link training everywhere (Kai-Heng). - Abstract DMC FW path (Rodrigo). - Preparation and changes for upcoming XeLPD display IP (Jose, Matt, Ville, Juha-Pekka, Animesh). - Fix comment typo in DSI code (zuoqilin). - Simplify CCS and UV plane alignment handling (Imre). - PSR Fixes on TGL (Gwan-gyeong, Jose). - Add intel_dp_hdcp.h and rename init (Jani). - Move crtc and dpll declarations around (Jani). - Fix pre-skl DP AUX precharge length (Ville). - Remove stray newlines from random files (Ville). - crtc->index and intel_crtc+drm_crtc pointer clean-up (Ville). - Add frontbuffer tracking tracepoints (Ville). - ADL-S PCI ID updates (Anand). - Use unique backlight device names (Jani). - A few clean-ups on i915/audio (Jani). - Use intel_framebuffer instead of drm one on intel_fb functions (Imre). - Add the missing MC CCS/XYUV8888 format support on display >= 12 (Imre). - Nuke display error state (Ville). - ADL-P initial enablement patches starting to land (Clint, Imre, Jose, Umesh, Vandita, Mika). - Display clean-up around VBT and the strap bits (Lucas). - Try YCbCr420 color when RGB fails (Werner). - More PSR fixes and improvements (Jose). - Other generic display code clean-up (Jose, Ville). - Use correct downstream caps for check Src-Ctl mode for PCON (Ankit). - Disable HiZ Raw Stall Optimization on broken gen7 (Simon). Signed-off-by:
-
Daniel Vetter authored
Motivated because I got confused and Christian confirmed why this works. I think this is non-obvious enough that it merits a slightly longer comment. Acked-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210519082409.672016-1-daniel.vetter@ffwll.ch
-
Zou Wei authored
Add the missing unlock and free before return from function drm_legacy_addbufs_pci() in the error handling case. Fixes: 70556e24 ("drm: remove usage of drm_pci_alloc/free") Reported-by:
-
Kai-Heng Feng authored
Commit 3d42f1dd ("vgaarb: Keep adding VGA device in queue") assumes the first device is an integrated GPU. However, on AMD platforms an integrated GPU can have higher PCI device number than a discrete GPU. Integrated GPU on ACPI platform generally has _DOD and _DOS method, so use that as predicate to find integrated GPU. If the new strategy doesn't work, fallback to use the first device as boot VGA. Reviewed-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Pi-Hsun Shih authored
Originally when using pm_runtime_put, there's a chance that the runtime suspend hook will be run after the following anx7625_bridge_mode_set call, resulting in the display_timing_valid field to be cleared, and the following power on fail. Change all pm_runtime_put to pm_runtime_put_sync, so all power off operations are guaranteed to be done after the call returns. Fixes: 60487584 ("drm/bridge: anx7625: refactor power control to use runtime PM framework") Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Tested-by:
Tzung-Bi Shih <tzungbi@google.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Andrey Grodzovsky authored
Access to those must be prevented post pci_remove v6: Drop BOs list, unampping VRAM BAR is enough. v8: Add condition of xgmi.connected_to_cpu to MTTR handling and remove MTTR handling from the old place. Signed-off-by:
-
Andrey Grodzovsky authored
In case device remove is just simualted by sysfs then verify device doesn't keep doing DMA to the released memory after pci_remove is done. Signed-off-by:
-
Andrey Grodzovsky authored
It's already being released by DRM core through devm Signed-off-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512142648.666476-15-andrey.grodzovsky@amd.com
-
Andrey Grodzovsky authored
Wait for all dependencies of a job to complete before killing it to avoid data corruptions. Signed-off-by:
-
Andrey Grodzovsky authored
Problem: If scheduler is already stopped by the time sched_entity is released and entity's job_queue not empty I encountred a hang in drm_sched_entity_flush. This is because drm_sched_entity_is_idle never becomes false. Fix: In drm_sched_fini detach all sched_entities from the scheduler's run queues. This will satisfy drm_sched_entity_is_idle. Also wakeup all those processes stuck in sched_entity flushing as the scheduler main thread which wakes them up is stopped by now. v2: Reverse order of drm_sched_rq_remove_entity and marking s_entity as stopped to prevent reinserion back to rq due to race. v3: Drop drm_sched_rq_remove_entity, only modify entity->stopped and check for it in drm_sched_entity_is_idle Signed-off-by:
-
Andrey Grodzovsky authored
If removing while commands in flight you cannot wait to flush the HW fences on a ring since the device is gone. Signed-off-by:
-
