On 2022-10-21 05:12, Yang Yingliang wrote:
>
> On 2022/10/21 16:36, Greg KH wrote:
>> On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
>>> On 2022/10/21 13:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> On 2022-10-20 22:20, Yang
On 2022-10-21 05:56, Yang Yingliang wrote:
>
> On 2022/10/21 17:08, Luben Tuikov wrote:
>> On 2022-10-21 04:59, Yang Yingliang wrote:
>>> On 2022/10/21 16:36, Greg KH wrote:
On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
> On 2022/10/21 13:37, Greg KH wrote:
>> On
On 2022-10-21 09:05, Liang, Prike wrote:
[Public]
-Original Message-
From: Kuehling, Felix
Sent: Friday, October 21, 2022 1:11 PM
To: Liang, Prike ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zhang, Yifan ;
Huang, Ray ; Liu, Aaron
Subject: Re: [PATCH 1/2] drm/amdkfd:
It looks like this patch never landed.
Alex
On Tue, Oct 11, 2022 at 9:48 PM Zhang, Yifan wrote:
>
> [Public]
>
>
>
> This patch is
>
>
>
> Reviewed-by: Yifan Zhang
>
>
>
> From: Zhang, Jesse(Jie)
> Sent: Tuesday, October 11, 2022 1:23 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher,
Unfortunately, printk() doesn't currently support the printing of %f
entries. So, print statements that contain "%f" should be removed.
However, since DC is used on other OSes that can still benefit from the
additional debugging information, we should instead remove the
problematic print
On 2022-10-20 18:10, Rafael Mendonca wrote:
> This is an extension of commit fd3bc691fc7b ("drm/amd/display: Remove
> duplicate code across dcn30 and dcn31"), which removed duplicate code for
> the function CalculateBytePerPixelAnd256BBlockSizes() across dcn30 and
> dcn31. At the time the
On Fri, Oct 21, 2022 at 10:47 AM Prike Liang wrote:
>
> In the S2idle suspend/resume phase the gfxoff is keeping functional so
> some IP blocks will be likely to reinitialize at gfxoff entry and that
> will result in failing to program GC registers.Therefore, let disallow
> gfxoff until AMDGPU
In the S2idle suspend/resume phase the gfxoff is keeping functional so
some IP blocks will be likely to reinitialize at gfxoff entry and that
will result in failing to program GC registers.Therefore, let disallow
gfxoff until AMDGPU IPs reinitialized completely.
Signed-off-by: Prike Liang
---
On Fri, Oct 21, 2022 at 10:10 AM Liang, Prike wrote:
>
> [Public]
>
> -Original Message-
> From: Alex Deucher
> Sent: Friday, October 21, 2022 9:39 PM
> To: Liang, Prike
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Huang, Ray
> Subject: Re: [PATCH] drm/amdgpu: disallow
[Public]
-Original Message-
From: Alex Deucher
Sent: Friday, October 21, 2022 9:39 PM
To: Liang, Prike
Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; Huang, Ray
Subject: Re: [PATCH] drm/amdgpu: disallow gfxoff until GC IP blocks complete
s2idle resume
On Thu, Oct 20, 2022
On Thu, Oct 20, 2022 at 10:30 PM Prike Liang wrote:
>
> In the S2idle suspend/resume phase the gfxoff is keeping functional so
> some IP blocks will be likely to reinitialize at gfxoff entry and that
> will result in failing to program GC registers.Therefore, let disallow
> gfxoff until AMDGPU
On 2022/10/21 16:41, Luben Tuikov wrote:
On 2022-10-21 04:24, Luben Tuikov wrote:
On 2022-10-21 04:18, Greg KH wrote:
On Fri, Oct 21, 2022 at 03:55:18AM -0400, Luben Tuikov wrote:
On 2022-10-21 01:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On
On 2022/10/21 16:36, Greg KH wrote:
On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
On 2022/10/21 13:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
The previous discussion link:
On 2022/10/21 16:36, Greg KH wrote:
On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
On 2022/10/21 13:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
The previous discussion link:
On 2022/10/21 13:34, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
kset_register() is currently used in some places without calling
kset_put() in error path, because the callers think it should be
kset internal thing to do, but the driver core can not know what
caller doing
Hi,
On 2022/10/21 13:29, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
The previous discussion link:
https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
The very first discussion on this was here:
On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
>
> On 2022/10/21 13:37, Greg KH wrote:
> > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> > > On 2022-10-20 22:20, Yang Yingliang wrote:
> > > > The previous discussion link:
> > > >
On Fri, Oct 21, 2022 at 04:05:18PM +0800, Yang Yingliang wrote:
>
> On 2022/10/21 13:34, Luben Tuikov wrote:
> > On 2022-10-20 22:20, Yang Yingliang wrote:
> > > kset_register() is currently used in some places without calling
> > > kset_put() in error path, because the callers think it should be
On Fri, Oct 21, 2022 at 03:55:18AM -0400, Luben Tuikov wrote:
> On 2022-10-21 01:37, Greg KH wrote:
> > On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> >> On 2022-10-20 22:20, Yang Yingliang wrote:
> >>> The previous discussion link:
> >>>
On 2022/10/21 17:08, Luben Tuikov wrote:
On 2022-10-21 04:59, Yang Yingliang wrote:
On 2022/10/21 16:36, Greg KH wrote:
On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
On 2022/10/21 13:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On
On 2022/10/21 13:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
The previous discussion link:
https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
The very first discussion on this was
[Public]
-Original Message-
From: Kuehling, Felix
Sent: Friday, October 21, 2022 1:11 PM
To: Liang, Prike ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zhang, Yifan
; Huang, Ray ; Liu, Aaron
Subject: Re: [PATCH 1/2] drm/amdkfd: introduce dummy cache info for property
asic
On Fri, Oct 21, 2022 at 1:33 PM Christian König
wrote:
>
> Hi,
>
> yes Bas already reported this issue, but I couldn't reproduce it. Need
> to come up with a patch to narrow this down further.
>
> Can I send you something to test?
I would appreciate to test any patches and ideas.
--
Best
On Thu, 20 Oct 2022, Ville Syrjälä wrote:
> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
>> > hi Greg, Dan, Jason, DRM-folk,
>> >
>> > heres follow-up to V6:
>> > rebased on driver-core/driver-core-next for -v6 applied
On 2022-10-21 04:59, Yang Yingliang wrote:
>
> On 2022/10/21 16:36, Greg KH wrote:
>> On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
>>> On 2022/10/21 13:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> On 2022-10-20 22:20, Yang
On 2022-10-21 04:36, Greg KH wrote:
> On Fri, Oct 21, 2022 at 04:24:23PM +0800, Yang Yingliang wrote:
>>
>> On 2022/10/21 13:37, Greg KH wrote:
>>> On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
> The previous discussion link:
On 2022-10-21 04:24, Luben Tuikov wrote:
> On 2022-10-21 04:18, Greg KH wrote:
>> On Fri, Oct 21, 2022 at 03:55:18AM -0400, Luben Tuikov wrote:
>>> On 2022-10-21 01:37, Greg KH wrote:
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> On 2022-10-20 22:20, Yang Yingliang
Hi,
yes Bas already reported this issue, but I couldn't reproduce it. Need
to come up with a patch to narrow this down further.
Can I send you something to test?
Thanks for the help,
Christian.
Am 21.10.22 um 10:08 schrieb Mikhail Gavrilov:
Hi!
I found that some games (Cyberpunk 2077,
On 2022-10-21 04:18, Greg KH wrote:
> On Fri, Oct 21, 2022 at 03:55:18AM -0400, Luben Tuikov wrote:
>> On 2022-10-21 01:37, Greg KH wrote:
>>> On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
On 2022-10-20 22:20, Yang Yingliang wrote:
> The previous discussion link:
>
[AMD Official Use Only - General]
Series is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Zhou1, Tao
Sent: Friday, October 21, 2022 15:36
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ;
Yang, Stanley ; Chai, Thomas ; Li,
Candice
Cc: Zhou1, Tao
Subject:
On 2022-10-21 04:05, Yang Yingliang wrote:
>
> On 2022/10/21 13:34, Luben Tuikov wrote:
>> On 2022-10-20 22:20, Yang Yingliang wrote:
>>> kset_register() is currently used in some places without calling
>>> kset_put() in error path, because the callers think it should be
>>> kset internal thing
Hi!
I found that some games (Cyberpunk 2077, Forza Horizon 4/5) hang at
start after commit dd80d9c8eecac8c516da5b240d01a35660ba6cb6.
dd80d9c8eecac8c516da5b240d01a35660ba6cb6 is the first bad commit
commit dd80d9c8eecac8c516da5b240d01a35660ba6cb6
Author: Christian König
Date: Thu Jul 14
On 2022-10-21 01:37, Greg KH wrote:
> On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
>> On 2022-10-20 22:20, Yang Yingliang wrote:
>>> The previous discussion link:
>>>
On 2022-10-20 16:59, Christian König wrote:
> Am 20.10.22 um 16:49 schrieb Michel Dänzer:
>> On 2022-10-18 11:08, jiadong@amd.com wrote:
>>> From: "Jiadong.Zhu"
>>>
>>> The software ring is created to support priority context while there is only
>>> one hardware queue for gfx.
>>>
>>> Every
Make the code more simple.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c| 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.h| 4 +---
4 files changed,
For MCA poison, if unmap queue fails, only gpu reset should be
triggered without page retirement handling, MCA notifier will do it.
v2: handle MCA poison consumption in umc_poison_handler directly.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 31
Make the code more readable.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 36 +++--
1 file changed, 3 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index
Define page retirement functions for MCA platform.
v2: remove page retirement handling from MCA poison handler,
let MCA notifier do page retirement.
v3: remove specific poison handler for MCA to simplify code.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 53
On 10/19/22 21:48, Alex Deucher wrote:
Commit 8795e182b02d ("PCI/portdrv: Don't disable AER reporting in
get_port_device_capability()")
uncovered a bug in amdgpu that required a reordering of the driver
init sequence to avoid accessing a special register on the GPU
before it was properly set up
Inject fault while loading module (e.g. pktcdvd.ko), kset_register() may
fail in __class_register(), if it fails, but the refcount of kobject is
not decreased to 0, the name allocated in kobject_set_name() is leaked.
To fix this by calling kfree_const().
unreferenced object 0x888102fa8190
Move remaining FPU code to dml folder
in preparation for enabling aarch64 support.
Signed-off-by: Ao Zhong
---
.../drm/amd/display/dc/dcn10/dcn10_resource.c | 44 +--
.../drm/amd/display/dc/dcn32/dcn32_resource.c | 5 ++-
.../drm/amd/display/dc/dml/dcn10/dcn10_fpu.c | 40
Inject fault while loading module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().
unreferenced object
Subject: [PATCH] drm/amd/display: move remaining FPU code to dml folder
Move remaining FPU code to dml folder
in preparation for enabling aarch64 support.
Signed-off-by: Ao Zhong
---
.../drm/amd/display/dc/dcn10/dcn10_resource.c | 44 +--
From: Liu Shixin
When insmod ubifs.ko, a kmemleak reported as below:
unreferenced object 0x88817fb1a780 (size 8):
comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s)
hex dump (first 8 bytes):
75 62 69 66 73 00 ff ff ubifs...
backtrace:
[]
kset_register() is currently used in some places without calling
kset_put() in error path, because the callers think it should be
kset internal thing to do, but the driver core can not know what
caller doing with that memory at times. The memory could be freed
both in kset_put() and error path of
Inject fault while loading module, kset_register() may fail, if
it fails, but the refcount of kobject is not decreased to 0, the
name allocated in kobject_set_name() is leaked. To fix this by
calling kset_put(), so that name can be freed in callback function
kobject_cleanup() and 'subdir' is freed
After moving all FPU code to the DML folder, we can enable DCN support
for the ARM64 platform. Remove the -mgeneral-regs-only CFLAG form the
code in the DML folder that needs to use hardware FPU, and add a control
mechanism for ARM Neon.
Signed-off-by: Ao Zhong
---
Hello. Thanks for the reply, Rodrigo
Will redo the patch and resubmit.
Cheers
Inject fault while loading module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().
unreferenced object
If kset_register() fails, the refcount of kobject is not 0,
the name allocated in kobject_set_name(, ...) is
leaked. Fix this by calling kset_put(), so that it will be
freed in callback function kobject_cleanup().
Cc: sta...@vger.kernel.org
Fixes: a6c40b178092 ("drm/amdgpu: Show IP discovery in
On Fri, Oct 21, 2022 at 01:29:31AM -0400, Luben Tuikov wrote:
> On 2022-10-20 22:20, Yang Yingliang wrote:
> > The previous discussion link:
> > https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
>
> The very first discussion on this was here:
>
>
Inject fault while loading module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().
unreferenced object
kset_put() can be called from drivers, add null pointer
check to make it more robust.
Signed-off-by: Yang Yingliang
---
include/linux/kobject.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index
The previous discussion link:
https://lore.kernel.org/lkml/0db486eb-6927-927e-3629-958f8f211...@huawei.com/T/
kset_register() is currently used in some places without calling
kset_put() in error path, because the callers think it should be
kset internal thing to do, but the driver core can not
This is an extension of commit fd3bc691fc7b ("drm/amd/display: Remove
duplicate code across dcn30 and dcn31"), which removed duplicate code for
the function CalculateBytePerPixelAnd256BBlockSizes() across dcn30 and
dcn31. At the time the aforementioned commit was introduced, support for
DCN 3.1.4
Inject fault while loading module (e.g. qemu_fw_cfg.ko), kset_register()
may fail in kset_create_and_add(), if it fails, but the refcount of kobject
is not decreased to 0, the name allocated in kset_create() is leaked. To fix
this by calling kset_put(), so that name can be freed in callback
This file was split in commit 5d945cbcd4b16a29d6470a80dfb19738f9a4319f
("drm/amd/display: Create a file dedicated to planes") and the logic in
dm_plane_format_mod_supported() function got changed by a switch logic.
That change broke drm_plane modifiers setting on series 5000 APUs
(tested on OXP
Inject fault while loading module (e.g. edac_core.ko), kset_register()
may fail in bus_register(), if it fails, but the refcount of kobject is
not decreased to 0, the name allocated in kobject_set_name() is leaked.
To fix this by calling kset_put(), so that name can be freed in callback
function
[AMD Official Use Only - General]
> -Original Message-
> From: Zhang, Hawking
> Sent: Friday, October 21, 2022 12:15 PM
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org; Yang,
> Stanley ; Chai, Thomas ; Li,
> Candice
> Subject: RE: [PATCH 1/4] drm/amdgpu: add RAS page retirement
59 matches
Mail list logo
