- 10 Feb, 2022 6 commits
-
-
Thomas Zimmermann authored
Clip the damage area horizontally if only a single scanline has been changed. This is helpful to reduce the memcpy overhead for small writes. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209161617.3553-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Write helpers used to mark the complete screen as dirty. This is wasteful for writes that only change a small portion of the screen. Fix the problem by computing the damaged area from the written memory range and perform damage handling accordingly. Signed-off-by:
-
Thomas Zimmermann authored
Add drm_fb_helper_memory_range_to_clip(), a helper function that accepts an linear range of video memory and converts it into a rectangle. The computed rectangle describes the damaged area in terms of scanlines and pixels per scanline. While at it, make the code more readable by using struct drm_rect and related helpers. The code was previously part of the deferred I/O helpers, but is also useful for damage handling of regular write operations. Update the deferred I/O code to use the new function. v2: * rename helper (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Don't clip the damage rectangle against the viewport. This only works if the viewport is located at the beginning of the video memory and the video memory doesn't extend the screen (i.e., if there's no overallocation). Fbdev emulation transfers data from write operations into a possible shadow buffer, then into a GEM buffer object, and finally via graphics driver onto the screen. If callers write outside the currently visible area, clipping the damage rectangle against the viewport will loose these updates in the shadow buffer and the fbdev's buffer object will contain stale data. Panning the viewport to the stale area of the buffer will display obsolete data. Instead, mark all written areas as damaged, so that the damage handler updates the buffer object from the shadow buffer for all such areas. The graphics driver's later has the option of clipping the damaged area against the viewport when updating the screen from the buffer object. Signed-off-by:
-
Thomas Zimmermann authored
Computing the clip rectangle is prone to off-by-one errors when writes happen near the end of a memory page. Point the end of the memory area to the first trailing byte, so that (end - start) returns the area's length. Signed-off-by:
-
Andrey Grodzovsky authored
Seems I forgot to add this to the relevant commit when submitting. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 09 Feb, 2022 11 commits
-
-
Andrey Grodzovsky authored
Since we have a single instance of reset semaphore which we lock only once even for XGMI hive we don't need the nested locking hint anymore. Signed-off-by:
-
Andrey Grodzovsky authored
This functions needs to be split into 2 parts where one is called only once for locking single instance of reset_domain's sem and reset flag and the other part which handles MP1 states should still be called for each device in XGMI hive. Signed-off-by:
-
Andrey Grodzovsky authored
We should have a single instance per entrire reset domain. Signed-off-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
-
Andrey Grodzovsky authored
We want single instance of reset sem across all reset clients because in case of XGMI we should stop access cross device MMIO because any of them could be in a reset in the moment. Signed-off-by:
-
Andrey Grodzovsky authored
The reset domain contains register access semaphor now and so needs to be present as long as each device in a hive needs it and so it cannot be binded to XGMI hive life cycle. Adress this by making reset domain refcounted and pointed by each member of the hive and the hive itself. v4: Fix crash on boot witrh XGMI hive by adding type to reset_domain. XGMI will only create a new reset_domain if prevoius was of single device type meaning it's first boot. Otherwsie it will take a refocunt to exsiting reset_domain from the amdgou device. Add a wrapper around reset_domain->refcount get/put and a wrapper around send to reset wq (Lijo) Signed-off-by:
-
Andrey Grodzovsky authored
Since now all GPU resets are serialzied there is no need for this. This patch also reverts 'drm/amdgpu: race issue when jobs on 2 ring timeout' Signed-off-by:
-
Andrey Grodzovsky authored
Since we serialize all resets no need to protect from concurrent resets. Signed-off-by:
-
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 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 5 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:
-
