Hi Luben,
I'd have to ping you because we've got a P1 ticket currently on this issue.
Would you please give a vague time when would you confirm whether this patch is
safe? Thank you a lot for helping double check this.
Regards & Thanks,
Yubiao
-Original Message-
From: Tuikov, Luben
Will attached patch help?
Regards,
Guchun
> -Original Message-
> From: Zhenneng Li
> Sent: Monday, March 13, 2023 10:57 AM
> To: Chen, Guchun
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; Zhenneng Li
>
Am 2023-03-13 um 14:35 schrieb David Belanger:
Handle case when module is unloaded (kfd_exit) before a process space
(mm_struct) is released.
v2: Fixed potential race conditions by removing all kfd_process from
the process table first, then working on releasing the resources.
v3: Fixed loop e
Handle case when module is unloaded (kfd_exit) before a process space
(mm_struct) is released.
v2: Fixed potential race conditions by removing all kfd_process from
the process table first, then working on releasing the resources.
v3: Fixed loop element access / synchronization. Fixed extra empty
This is a reminder that the nomination period for the X.Org Board of
Director elections finishes in a week, on March 19th.
If you would like to nominate yourself please send email to the election
committee electi...@x.org, giving your
name
current professional affiliation
a statement
This is a reminder that the deadline for new memberships and renewals
finishes in a couple of weeks. Original email follows.
Thanks for your attention.
On Wed, 2023-02-15 at 16:58 +0100, Ricardo Garcia wrote:
> The 2023 X.Org Foundation elections are rapidly approaching. We will be
> forwarding t
Applied. Thanks!
Alex
On Sun, Mar 12, 2023 at 12:51 PM Guilherme G. Piccoli
wrote:
>
> The VCN firmware loading path enables the indirect SRAM mode if it's
> advertised as supported. We might have some cases of FW issues that
> prevents this mode to working properly though, ending-up in a faile
Am 13.03.23 um 14:21 schrieb Felix Kuehling:
Am 2023-03-13 um 03:36 schrieb Christian König:
Am 10.03.23 um 23:16 schrieb Felix Kuehling:
This will make it possible for amdgpu GEM ioctls to flush TLBs on
compute
VMs.
This removes VMID-based TLB flushing and always uses PASID-based
flushin
[Public]
Hi all,
This week this patchset was tested on the following systems:
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Lenovo Thinkpad T13s Gen4 with AMD Ryzen 5 6600U
Reference AMD RX6800
These systems were tested on the following display types:
eDP, (1080p 60hz [5650U]) (1920x12
Am 2023-03-13 um 03:36 schrieb Christian König:
Am 10.03.23 um 23:16 schrieb Felix Kuehling:
This will make it possible for amdgpu GEM ioctls to flush TLBs on
compute
VMs.
This removes VMID-based TLB flushing and always uses PASID-based
flushing. This still works because it scans the VMID-PA
This is a note to let you know that I've just added the patch titled
drm/connector: print max_requested_bpc in state debugfs
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/connector: print max_requested_bpc in state debugfs
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/connector: print max_requested_bpc in state debugfs
to the 6.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On 12.03.2023 13:01, Huang Rui wrote:
> Xen PVH is the paravirtualized mode and takes advantage of hardware
> virtualization support when possible. It will using the hardware IOMMU
> support instead of xen-swiotlb, so disable swiotlb if current domain is
> Xen PVH.
But the kernel has no way (yet)
This is a note to let you know that I've just added the patch titled
drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
to the 6.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/connector: print max_requested_bpc in state debugfs
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/connector: print max_requested_bpc in state debugfs
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On 3/12/23 20:47, Benjamin Cheng wrote:
When FB_DAMAGE_CLIPS are provided in a non-MPO scenario, the loop does
not use the counter i. This causes the fill_dc_dity_rect() to always
fill dirty_rects[0], causing graphical artifacts when a damage clip
aware DRM client sends more than 1 damage clip.
[Why]
For GC IP v11.0.4/11, PSP TMR need to be reserved
for ASIC mode2 reset. But for S4, when psp suspend,
it will destroy the TMR that fails the ASIC reset.
[ 96.006101] amdgpu :62:00.0: amdgpu: MODE2 reset
[ 100.409717] amdgpu :62:00.0: amdgpu: SMU: I'm not done with your
previous co
Rename register_backlight_device() to setup_backlight_device()
and move all backlight setup related calls from
amdgpu_dm_register_backlight_device() and from
amdgpu_dm_initialize_drm_device() there.
This leaves amdgpu_dm_register_backlight_device() dealing purely
with registering the actual backli
6.1.14 worked OK for 11 days, then I got the idea of updating this stable
series. In the morning screen was black and system completely dead, had
to press reset switch. 6.1.16 and 6.1.18 both have this issue.
If I just press ctrl-alt-L on Wayland Gnome to "power-save" the display
and wait a coup
When FB_DAMAGE_CLIPS are provided in a non-MPO scenario, the loop does
not use the counter i. This causes the fill_dc_dity_rect() to always
fill dirty_rects[0], causing graphical artifacts when a damage clip
aware DRM client sends more than 1 damage clip.
Instead, use the flip_addrs->dirty_rect_co
On Sun, Mar 12, 2023 at 21:26:56 +0200, Sami Farin wrote:
6.1.14 worked OK for 11 days, then I got the idea of updating this stable
Well now 6.1.14 crashed also, but not when suspending display.
I used Wayland normally for one hour.
Would you say GPU is getting old and cranky and I should buy a
Hi All,
Here is version 3 of my patch series to pass the proper parent device
to backlight_device_register().
Changes in v3:
- Make amdgpu_dm_register_backlight_device() check bl_idx != 1 before
registering the backlight since amdgpu_dm_connector_late_register()
now calls it for _all_ connect
This bug is first reported here:
https://lore.kernel.org/lkml/1a620e7c-5b71-3d16-001a-0d79b292a...@amd.com/
I modify the patch accroding mail list's discusstion, and I do reboot
test for tens of thousands of times about 10 machines on arm64, there's
no bug reported.
在 2023/3/10 16:18, Che
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[6.996395][ 7] [ T295] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init of IP block failed -22
[7.006919][ 7] [ T295] amdgpu :04:00.0: amdgpu_device
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[6.996395][ 7] [ T295] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init of IP block failed -22
[7.006919][ 7] [ T295] amdgpu :04:00.0: amdgpu_device
Make amdgpu_dm_register_backlight_device() take an amdgpu_dm_connector
pointer to the connector for which it should register the backlight
as its only argument.
This is a preparation patch for moving the actual backlight class device
registering to drm_connector_funcs.late_register.
Signed-off-by
The parent for the backlight device should be the drm-connector object,
not the PCI device.
Userspace relies on this to be able to detect which backlight class device
to use on hybrid gfx devices where there may be multiple native (raw)
backlight devices registered.
Specifically gnome-settings-da
Refactor register_backlight_device():
1) Turn the connector-type + signal check into an early exit
condition to avoid the indentation level of the rest of the code
2) Add an array bounds check for the arrays indexed by dm->num_of_edps
3) register_backlight_device() always increases dm->num_of_ed
Hi,
On 3/8/23 22:58, Hans de Goede wrote:
> The parent for the backlight device should be the drm-connector object,
> not the PCI device.
>
> Userspace relies on this to be able to detect which backlight class device
> to use on hybrid gfx devices where there may be multiple native (raw)
> backli
Currently functions like update_connector_ext_caps() and
amdgpu_dm_connector_destroy() are iterating over dm->backlight_link[i]
to find the index of the (optional) backlight_dev associated with
the connector.
Instead make register_backlight_device() store the dm->backlight_dev[]
index used for the
backlight_device_register() returns an ERR_PTR on error, but other code
such as amdgpu_dm_connector_destroy() assumes dm->backlight_dev[i] is NULL
if no backlight is registered.
Clear dm->backlight_dev[i] on registration failure, to avoid other code
trying to deref an ERR_PTR pointer.
Signed-off-
Am 10.03.23 um 23:16 schrieb Felix Kuehling:
Use dummy command submissions with a 0-sized IB on a compute VM to flush
TLBs and signal the fence in SW. This allows applications with user mode
queues to sync with asynchronous VM updates through the CS API.
Ok that is really hacky. Going to sync u
Am 10.03.23 um 23:16 schrieb Felix Kuehling:
This will make it possible for amdgpu GEM ioctls to flush TLBs on compute
VMs.
This removes VMID-based TLB flushing and always uses PASID-based
flushing. This still works because it scans the VMID-PASID mapping
registers to find the right VMID. It's o
[AMD Official Use Only - General]
The series is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: Zhang, Hawking
> Sent: Monday, March 13, 2023 9:44 AM
> To: amd-gfx@lists.freedesktop.org; Zhou1, Tao ; Yang,
> Stanley ; Li, Candice ; Chai,
> Thomas
> Cc: Zhang, Hawking
> Subject: [P
37 matches
Mail list logo
