- 09 Feb, 2022 5 commits
-
-
Andrey Grodzovsky authored
Since we serialize all resets no need to protect from concurrent resets. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://www.spinics.net/lists/amd-gfx/msg74115.html
-
Andrey Grodzovsky authored
No need to to trigger another work queue inside the work queue. v3: Problem: Extra reset caused by host side FLR notification following guest side triggered reset. Fix: Preven qeuing flr_work from mailbox irq if guest already executing a reset. Suggested-by:
Liu Shaoyun <Shaoyun.Liu@amd.com> Signed-off-by:
-
Andrey Grodzovsky authored
Use reset domain wq also for non TDR gpu recovery trigers such as sysfs and RAS. We must serialize all possible GPU recoveries to gurantee no concurrency there. For TDR call the original recovery function directly since it's already executed from within the wq. For others just use a wrapper to qeueue work and wait on it to finish. v2: Rename to amdgpu_recover_work_struct Signed-off-by:
-
Andrey Grodzovsky authored
Before we initialize schedulers we must know which reset domain are we in - for single device there iis a single domain per device and so single wq per device. For XGMI the reset domain spans the entire XGMI hive and so the reset wq is per hive. Signed-off-by:
-
Andrey Grodzovsky authored
Defined a reset_domain struct such that all the entities that go through reset together will be serialized one against another. Do it for both single device and XGMI hive cases. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by:
Christian König <ckoenig.leichtzumerken@gmail.com> Reviewed-by:
-
- 08 Feb, 2022 18 commits
-
-
Lyude Paul authored
Currently we can get a warning on systems with eDP backlights like so: nv_backlight: invalid backlight type WARNING: CPU: 4 PID: 454 at drivers/video/backlight/backlight.c:420 backlight_device_register+0x226/0x250 This happens as a result of us not filling out props.type for the eDP backlight, even though we do it for all other backlight types. Since nothing in our driver uses anything but BACKLIGHT_RAW, let's take the props\.type assignments out of the codepaths for individual backlight types and just set it unconditionally to prevent this from happening again. Signed-off-by:Lyude Paul <lyude@redhat.com> Fixes: 6eca310e ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau") Cc: <stable@vger.kernel.org> # v5.15+ Reviewed-by:
Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204193319.451119-1-lyude@redhat.com
-
Lyude Paul authored
It seems that some laptops will report having both an eDP and LVDS connector, even though only the LVDS connector is actually hooked up. This can lead to issues with backlight registration if the eDP connector ends up getting registered before the LVDS connector, as the backlight device will then be registered to the eDP connector instead of the LVDS connector. So, fix this by only registering the backlight on connectors that are reported as being connected. Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worse scenario, could lead to heap overflows. Link: https://github.com/KSPP/linux/issues/160Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
-
Thomas Zimmermann authored
Add helpers for initializing SIL164-based connectors. These used to be handled by the VGA connector code. But SIL164 provides output via DVI-I, so set the encoder and connector types accordingly. If a SIL164 chip has been detected, ast will now create a DVI-I connector instead of a VGA connector. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220207141544.30015-10-tzimmermann@suse.de
-
Thomas Zimmermann authored
Add helpers for DP501-based connectors. DP501 provides output via DisplayPort. This used to be handled by the VGA connector code. If a DP501 chip has been detected, ast will now create a DisplayPort connector instead of a VGA connector. Remove the DP501 code from ast_vga_connector_helper_get_modes(). Also remove the call to drm_connector_update_edid_property(), which is performed by drm_get_edid(). Signed-off-by:
-
Thomas Zimmermann authored
Read the encoder's possible-CRTC mask from the involved CRTC instead of hard-coding it. Signed-off-by:
-
Thomas Zimmermann authored
Move encoder and connector initialization into a single helper and put all related mode-setting structures into a single place. Done in preparation of moving transmitter code into separate helpers. No functional changes. v2: * move encoder CRTC bitmask fix into separate patch (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Prepare for introducing other connectors besides VGA. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Remove reading the link-rate. The value is maintained by the connector code but never used. Signed-off-by:
-
Thomas Zimmermann authored
The ITE66121 is an HDMI transmitter chip. There's no code for detecting or programming the chip within ast. Remove the enum constant. Signed-off-by:
-
Thomas Zimmermann authored
The tests in ast_mode_valid() verify the correct resolution for the supplied mode. This is a limitation of the CRTC, so move the function to the CRTC helpers. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Update the connector code to fail if the connector could not be initialized. The current code just ignored the error and failed later when the connector was supposed to be used. Signed-off-by:
-
Christian König authored
Instead of manually extracting the fence. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204100429.2049-7-christian.koenig@amd.com
-
Christian König authored
It's a reoccurring pattern that we need to extract the fence from a dma_fence_chain object. Add a helper for this. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220204100429.2049-6-christian.koenig@amd.com
-
Christian König authored
Drivers should not add containers as shared fences to the dma_resv object, instead each fence should be added individually. Signed-off-by:
-
Christian König authored
Chaining of dma_fence_chain objects is only allowed through the prev fence and not through the contained fence. Warn about that when we create a dma_fence_chain. v2: fix comment style Signed-off-by:
-
Christian König authored
It's not allowed to nest another dma_fence container into a dma_fence_array or otherwise we can run into recursion. Warn about that when we create a dma_fence_array. v2: fix comment style and typo in the warning pointed out by Thomas Signed-off-by:
-
Christian König authored
Consolidate the wrapper functions to check for dma_fence subclasses in the dma_fence header. This makes it easier to document and also check the different requirements for fence containers in the subclasses. Signed-off-by:
-
- 07 Feb, 2022 7 commits
-
-
Lucas De Marchi authored
Remove the local yesno() implementation and adopt the str_yes_no() from linux/string_helpers.h. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220126093951.1470898-11-lucas.demarchi@intel.com
-
Lucas De Marchi authored
linux/string_helpers.h provides a helper to return "yes"/"no" strings. Replace the open coded versions with str_yes_no(). The places were identified with the following semantic patch: @@ expression b; @@ - b ? "yes" : "no" + str_yes_no(b) Then the includes were added, so we include-what-we-use, and parenthesis adjusted in drivers/gpu/drm/v3d/v3d_debugfs.c. After the conversion we still see the same binary sizes: text data bss dec hex filename 51149 3295 212 54656 d580 virtio/virtio-gpu.ko.old 51149 3295 212 54656 d580 virtio/virtio-gpu.ko 1441491 60340 800 1502631 16eda7 radeon/radeon.ko.old 1441491 60340 800 1502631 16eda7 radeon/radeon.ko 6125369 328538 34000 6487907 62ff63 amd/amdgpu/amdgpu.ko.old 6125369 328538 34000 6487907 62ff63 amd/amdgpu/amdgpu.ko 411986 10490 6176 428652 68a6c drm.ko.old 411986 10490 6176 428652 68a6c drm.ko 98129 1636 264 100029 186bd dp/drm_dp_helper.ko.old 98129 1636 264 100029 186bd dp/drm_dp_helper.ko 1973432 109640 2352 2085424 1fd230 nouveau/nouveau.ko.old 1973432 109640 2352 2085424 1fd230 nouveau/nouveau.ko Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220126093951.1470898-10-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Sort includes alphabetically so it's easier to add/remove includes and know when that is needed. Signed-off-by:
-
Lucas De Marchi authored
Remove the local yesno() implementation and adopt the str_yes_no() from linux/string_helpers.h. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220126093951.1470898-8-lucas.demarchi@intel.com
-
Lucas De Marchi authored
There are a few implementations of string helpers in the tree like yesno() that just returns "yes" or "no" depending on a boolean argument. Those are helpful to output strings to the user or log. In order to consolidate them, prefix all of them str_ prefix to make it clear what they are about and avoid symbol clashes. Taking the commoon `val ? "yes" : "no"` implementation, quite a few users of open coded yesno() could later be converted to the new function: $ git grep '?\s*"yes"\s*' | wc -l 286 $ git grep '?\s*"no"\s*' | wc -l 20 The inlined function should keep the const strings local to each compilation unit, the same way it's now, thus not changing the current behavior. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
-
Maarten Lankhorst authored
First backmerge into drm-misc-next. Required for more helpers backmerged, and to pull in 5.17 (rc2). Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Hans de Goede authored
Fix the following warning from "make htmldocs": drivers/gpu/drm/drm_privacy_screen.c:392: warning: Function parameter or member 'data' not described in 'drm_privacy_screen_register' Fixes: 30598d92 ("drm/privacy_screen: Add drvdata in drm_privacy_screen") Cc: Rajat Jain <rajatja@google.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20220207113307.346281-1-hdegoede@redhat.com
-
- 06 Feb, 2022 2 commits
-
-
Tomohito Esaki authored
Remove allow_fb_modifiers setting in this driver. The allow_fb_modifiers flag was removed. Signed-off-by:
Tomohito Esaki <etom@igel.co.jp> Fixes: 3d082157 ("drm: remove allow_fb_modifiers") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220204023635.15496-1-etom@igel.co.jp
-
Simon Ser authored
Follow-up for the DRM_IOCTL_MODE_GETFB2 docs. v2: (Daniel Stone) - Replace fourcc.org with drm_fourcc.h because this is the authoritative source and the website may have mismatches. - Drop assumption that offsets will generally be 0. - Mention that unused entries must be zero'ed out. v3: (Pekka) - Mention that a handle can be re-used - Add unit for pitches/offsets Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203133753.261507-1-contact@emersion.fr
-
- 04 Feb, 2022 1 commit
-
-
Thomas Zimmermann authored
As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select the option to fix the build failure. The error message is shown below. arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function `panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to `drm_panel_dp_aux_backlight' make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1 The issue has been reported before, when DisplayPort helpers were hidden behind the option CONFIG_DRM_KMS_HELPER. [2] v2: * fix and expand commit description (Arnd) Signed-off-by:Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by:
Linux Kernel Functional Testing <lkft@linaro.org> Reviewed-by:
-
- 03 Feb, 2022 3 commits
-
-
Lucas De Marchi authored
Only x86 and in some cases PPC have support added in drm_cache.c for the clflush class of functions. However warning once is sufficient to taint the log instead of spamming it with "Architecture has no drm_cache.c support" every few millisecond. Switch to WARN_ONCE() so we still get the log message, but only once, together with the warning. E.g: ------------[ cut here ]------------ Architecture has no drm_cache.c support WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 drm_clflush_sg+0x40/0x50 [drm] ... v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err() Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220131165926.3230642-2-lucas.demarchi@intel.com
-
Maxime Ripard authored
Commit 4adc33f3 ("drm/edid: Split deep color modes between RGB and YUV444") introduced two new variables in struct drm_display_info and their documentation, but the documentation part had a typo resulting in a doc build warning. Fixes: 4adc33f3 ("drm/edid: Split deep color modes between RGB and YUV444") Reported-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
-
Alexander Stein authored
Use the dev_err_probe() helper, instead of open-coding the same operation. This also adds a nice hint in /sys/kernel/debug/devices_deferred. Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
- 02 Feb, 2022 4 commits
-
-
Christian König authored
Decomposing fence containers don't seem to make any sense here. So just remove the function entirely and call dma_fence_wait() directly. Signed-off-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124130328.2376-12-christian.koenig@amd.com
-
Maxime Ripard authored
Following the previous patch, let's introduce a generic panel-lvds binding that documents the panels that don't have any particular constraint documented. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Maxime Ripard authored
The lvds.yaml file so far was both defining the generic LVDS properties (such as data-mapping) that could be used for any LVDS sink, but also the panel-lvds binding. That last binding was to describe LVDS panels simple enough, and had a number of other bindings using it as a base to specialise it further. However, this situation makes it fairly hard to extend and reuse both the generic parts, and the panel-lvds itself. Let's remove the panel-lvds parts and leave only the generic LVDS properties. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Maxime Ripard authored
When we have the entire DRM state, retrieving the connector state only requires the drm_connector pointer. Fortunately for us, we have allocated it as a part of the vc4_hdmi structure, so we can retrieve get a pointer by simply accessing our field in that structure. Signed-off-by:
-
