Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to c
It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(), amdgpu
Some deadlock related fixes for amdgpu and DRM, spurred by:
https://gitlab.freedesktop.org/drm/amd/-/issues/2171
Unfortunately these don't fully fix the problem yet, but I'm getting
there!
Lyude Paul (2):
drm/amdgpu/mst: Stop ignoring error codes and deadlocking
drm/display/dp_mst: Fix drm_dp
Hi Dave, Daniel,
New stuff for 6.2.
The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:
Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-next-6.2-2022-11-04
for you to fe
On 2022-11-04 15:41, coverity-bot wrote:
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221104 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email becaus
Hello!
This is an experimental semi-automated report about issues detected by
Coverity from a scan of next-20221104 as part of the linux-next scan project:
https://scan.coverity.com/projects/linux-next-weekly-scan
You're getting this email because you were associated with the identified
lin
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 0cdb3579f1ee4c1e55acf8dfb0697b660067b1f8 Add linux-next specific
files for 20221104
Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
On Fri, Nov 4, 2022 at 6:05 AM Hanjun Guo wrote:
>
> VBIOSImageOffset in struct UEFI_ACPI_VFCT is ULONG (unsigned long),
> but it will be assigned to "unsigned offset", so use unsigned long
> instead of unsigned for the offset, to avoid possible overflow.
ULONG in atombios is 32 bits so an int sh
Hi Matthew, Rafael,
On 10/27/22 14:09, Rafael J. Wysocki wrote:
> On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 10/27/22 11:52, Matthew Garrett wrote:
>>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote:
>>>
The *only* behavior which actually is new i
Am 04.11.22 um 16:40 schrieb Felix Kuehling:
When importing dmabufs from other amdgpu devices, inherit the coherence
flags from the exported BO. This ensures correct MTYPEs in the GPU PTEs
for multi-GPU mappings of shared BOs.
Fixes: 763fbebb20e1 ("drm/amdgpu: Set MTYPE in PTE based on BO flags"
When importing dmabufs from other amdgpu devices, inherit the coherence
flags from the exported BO. This ensures correct MTYPEs in the GPU PTEs
for multi-GPU mappings of shared BOs.
Fixes: 763fbebb20e1 ("drm/amdgpu: Set MTYPE in PTE based on BO flags")
Tested-by: Gang Ba
Signed-off-by: Felix Kueh
On Fri, Nov 4, 2022 at 12:17 AM Harsh Jain wrote:
>
> change guarantees that gfxoff is allowed before moving further in
> s2idle sequence to add more reliablity about gfxoff in amdgpu IP's
> suspend flow
>
> Signed-off-by: Harsh Jain
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/d
On Fri, Nov 4, 2022 at 5:30 AM Asher Song wrote:
>
> This reverts commit 97370f1826eb7ee6880e09ee1eaafe28232cabc6.
>
> The origin patch "drm/amdgpu: getting fan speed pwm for vega10 properly"
> works fine. Test failure is caused by test case self.
Instead of reverting the revert, can you just re
In dcn*_clock_source_create when dcn*_clk_src_construct fails allocated
clk_src needs release. A local attack could use this to cause memory
exhaustion.
Signed-off-by: LongJun Tang
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 1 +
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_res
Am 04.11.22 um 12:19 schrieb Emily Deng:
Starting from SIENNA CICHLID asic supports two gfx pipes, enabling
two graphics queues for performance concern.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42
Starting from SIENNA CICHLID asic supports two gfx pipes, enabling
two graphics queues for performance concern.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42 -
2 files changed, 22 insertions(+)
Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region
firstly to make sure TMR can be allocated at 2MB
Signed-off-by: Tong Liu01
---
.../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 106 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 52 +
d
On 11/3/22 16:14, Thomas Zimmermann wrote:
> Clarify documentation in the use of struct drm_driver.last_close and
> struct drm_mode_config_funcs.output_poll_changed. Those callbacks should
> not be said for fbdev implementations on top of struct drm_client_funcs.
>
> Signed-off-by: Thomas Zimmerma
On 11/3/22 16:14, Thomas Zimmermann wrote:
> Uncouple the parameter drm_leak_fbdev_smem from the implementation by
> setting a flag in struct drm_fb_helper. This will help to move the
> generic fbdev emulation into its own source file, while keeping the
> parameter in drm_fb_helper.c. No functional
VBIOSImageOffset in struct UEFI_ACPI_VFCT is ULONG (unsigned long),
but it will be assigned to "unsigned offset", so use unsigned long
instead of unsigned for the offset, to avoid possible overflow.
Signed-off-by: Hanjun Guo
---
drivers/gpu/drm/radeon/radeon_bios.c | 2 +-
1 file changed, 1 inse
When the radeon driver reads the bios information from ACPI
table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table()
to release the ACPI memory after the init, so add acpi_put_table()
properly to fix the memory leak.
Fixes: 268ba0a99f89 ("drm/radeon: implement ACPI VFCT vbios fetch (v3
Please find my reply inline below
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Harsh Jain
>> Sent: Friday, November 4, 2022 12:17 PM
>> To: Deucher, Alexander
>> Cc: Jain, Harsh ; amd-gfx@lists.freedesktop.org
>> Subject: [PATCH] drm/amdgpu: wait till Gfxoff allow signal compl
Hi Esther,
ok, that works as well.
I would just move the handling of version of the firmware table into
separate functions. That should make it easier to understand what's
going on here.
Thanks,
Christian.
Am 04.11.22 um 10:34 schrieb Liu01, Tong (Esther):
[AMD Official Use Only - General]
[AMD Official Use Only - General]
>-Original Message-
>From: Christian König
>Sent: Friday, November 4, 2022 5:26 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org;
>Michel Dänzer
>Subject: Re: [PATCH] drm/amd/amdgpu: Enable gfx pipe1 and fix related
>issues
>
>Am 04.11.22 um 01:32 sch
[AMD Official Use Only - General]
Hi Christian,
Based on VBIOS's comment " driver can allocate their own reservation region as
long as it does not overlap firwmare's reservation region". Our understanding
is that they are not mutual exclusive. So we create extra parameters to record
drv reserv
This reverts commit 97370f1826eb7ee6880e09ee1eaafe28232cabc6.
The origin patch "drm/amdgpu: getting fan speed pwm for vega10 properly" works
fine. Test failure is caused by test case self.
Signed-off-by: Asher Song
---
.../amd/pm/powerplay/hwmgr/vega10_thermal.c | 25 +--
1 f
Am 03.11.22 um 15:59 schrieb Philip Yang:
Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest
application.
If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as
caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the
kernel WARNING.
Add unlock
Am 04.11.22 um 01:32 schrieb Emily Deng:
Starting from SIENNA CICHLID asic supports two gfx pipes, enabling
two graphics queues for performance concern.
With the printk still in the patch I assume that this is just a
debugging patch?
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amd
Am 04.11.22 um 09:52 schrieb Tong Liu01:
Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region
firstly to make sure TMR can be allocated at 2MB
If I understand it correctly the two methods are mutual exclusive. So I
think you can just extend the existing function in
Move TMR region from top of FB to 2MB for FFBM, so we need to reserve TMR region
firstly to make sure TMR can be allocated at 2MB
Signed-off-by: Tong Liu01
---
.../gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 84 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 52
Working fine after 26hrs+ of testing, plus another 24hrs of the previous
version of this patch.
Sorry if there are multiple replies, I had to figure out how to properly
reply to a mailing list, such that the reply is picked up by patchwork (1st
time doing this).
Tested-by: Stefan Springer
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Harsh Jain
> Sent: Friday, November 4, 2022 12:17 PM
> To: Deucher, Alexander
> Cc: Jain, Harsh ; amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: wait till Gfxoff allow signal completes d
Am 03.11.22 um 22:18 schrieb Philip Yang:
On 2022-11-02 10:58, Christian König wrote:
It can happen that we query the sequence value before the callback
had a chance to run.
Work around that by grabbing the fence lock and releasing it again.
Should be replaced by hw handling soon.
kfd_flush_
33 matches
Mail list logo
