On Fri, Feb 18, 2022 at 3:46 PM Christian König
wrote:
>
> Am 18.02.22 um 04:08 schrieb Qiang Yu:
> > On Thu, Feb 17, 2022 at 8:22 PM Christian König
> > wrote:
> >> Am 17.02.22 um 11:58 schrieb Qiang Yu:
> >>> On Thu, Feb 17, 2022 at 6:39 PM Christian König
> >>> wrote:
>
> Am 17.02.2
Am 18.02.22 um 09:58 schrieb Qiang Yu:
On Fri, Feb 18, 2022 at 3:46 PM Christian König
wrote:
Am 18.02.22 um 04:08 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 8:22 PM Christian König
wrote:
Am 17.02.22 um 11:58 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 6:39 PM Christian König
wrote:
Am 17.0
From: Ville Syrjälä
I might be taking this a bit too far, but the lack of
consistency in our methods to copy drm_display_mode
structs around is bugging me.
The main worry is the embedded list head, which if
clobbered could lead to list corruption. I'd also
prefer to make sure even the valid list
From: Ville Syrjälä
These on stack copies of the modes appear to be pointless.
Just look at the originals directly.
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org
Cc: Nikola Cornij
Cc: Aurabindo Pillai
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Initialize on-stack modes with drm_mode_init() to guarantee
no stack garbage in the list head, or that we aren't copying
over another mode's list head.
Based on the following cocci script, with manual fixups:
@decl@
identifier M;
expression E;
@@
- struct drm_display_mode M =
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
From: Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destinat
On Fri, Feb 18, 2022 at 5:27 PM Christian König
wrote:
>
> Am 18.02.22 um 09:58 schrieb Qiang Yu:
> > On Fri, Feb 18, 2022 at 3:46 PM Christian König
> > wrote:
> >> Am 18.02.22 um 04:08 schrieb Qiang Yu:
> >>> On Thu, Feb 17, 2022 at 8:22 PM Christian König
> >>> wrote:
> Am 17.02.22 um 11
Am 18.02.22 um 11:16 schrieb Qiang Yu:
[SNIP]
If amdgpu_vm_ready() use evicting flag, it's still not equivalent to check
vm idle: true -> vm idle, false -> vm may be idle or busy.
Yeah, but why should that be relevant?
The amdgpu_vm_ready() return if we can do page table updates or not. If
the
On Friday, February 18th, 2022 at 11:38, Hans de Goede
wrote:
> What I'm reading in the above is that it is being considered to allow
> changing the panel-orientation value after the connector has been made
> available to userspace; and let userspace know about this through a uevent.
>
> I belie
On Friday, February 18th, 2022 at 12:54, Hans de Goede
wrote:
> On 2/18/22 12:39, Simon Ser wrote:
> > On Friday, February 18th, 2022 at 11:38, Hans de Goede
> > wrote:
> >
> >> What I'm reading in the above is that it is being considered to allow
> >> changing the panel-orientation value afte
structure changed in smc_fw_version >= 0x3A4900,
"uint16_t VcnActivityPercentage" replaced with
"uint16_t VcnUsagePercentage0" and "uint16_t VcnUsagePercentage1"
Signed-off-by: Danijel Slivka
---
.../pmfw_if/smu11_driver_if_sienna_cichlid.h | 58 ++
.../amd/pm/swsmu/smu11/sienna_cichlid_pp
Hi Dan,
Thank you for catching this. I will look into it and post a patch.
Regards,
David
-Original Message-
From: Dan Carpenter
Sent: Friday, February 18, 2022 2:30 AM
To: Yat Sin, David
Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: [bug report] drm/amdkf
[AMD Official Use Only]
We could probably convert this to an IP version check or a family check in the
future, or add all of the unsupported chips to the disabled case and make this
case the default.
Acked-by: Alex Deucher
Alex
From: Liang, Prike
Sent: Thurs
[Public]
May want to update the sysfs interface as well.
Reviewed-by: Alex Deucher
From: Chen, Guchun
Sent: Thursday, February 17, 2022 11:56 PM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Zhang, Hawking ;
Koenig, Christian ; Pan, Xinhui
Cc: Che
[Public]
I think we should check adev->enable_virtual_display instead of sr-iov? You
can enable virtual display on bare metal as well.
Alex
From: Chen, Guchun
Sent: Friday, February 18, 2022 12:11 AM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Zha
[Public]
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Prike Liang
Sent: Friday, February 18, 2022 2:04 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liang, Prike
; Lazar, Lijo ; Huang, Ray
; Quan, Evan
Subject: [PATCH v2] drm/amd/pm:
[Public]
Excellent point, exactly, we should check adev->enable_virtual_display. Let me
send out a v2 soon.
Regards,
Guchun
From: Deucher, Alexander
Sent: Friday, February 18, 2022 10:39 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Zhang,
Hawking ; Shi, Leslie ; Cui, Flora
; Koenig,
This reverts commit 2f73d74ac4cd880beaa1c19fa9ef0296c3eb3b60.
No need to support modifier in virtual kms, otherwise, in SRIOV
mode, when lanuching X server, set crtc will fail due to mismatch
between primary plane modifier and framebuffer modifier.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm
vkms leverages common amdgpu framebuffer creation, and
also as it does not support FB modifier, there is no need
to check tiling flags when initing framebuffer when virtual
display is enabled.
This can fix below calltrace:
amdgpu :00:08.0: GFX9+ requires FB check based on format modifier
WARN
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* add debug option to bypass ssinfo from bios.
* Refactor fixed VS logic for non-transparent mode
* add cable ID support for usb c connector
* clear remote dc_sink when stop mst
* Ignore Transitional Invalid Link Ra
From: Chris Park
[Why]
Integrate OVT timing from DM to DC logic to update info frame
and mode management to report the resolution to the OS.
[How]
Reflect RID and Frame Rate to AVI InfoFrame Version 5.
Define new Timing Standard for OVT timing.
Reviewed-by: Charlene Liu
Acked-by: Solomon Chiu
From: Paul Hsieh
[Why]
When system resume from sleep, the cursor lock will be reset
to default(lock status). And the cursor programming sequence
doesn't consider about odm pipe split cause cursor can't be
enabled.
[How]
If odm pipe split has been used, lock/un-lock on each pipes.
Reviewed-by: D
From: "Ma, Duncan"
[Why]
Detbuffer size is dynamically set for dcn31x. At certain moment,
compbuf+(def size * num pipes) > config return buffer size causing
flickering. This is easily reproducible when MPO is
enabled with two displays.
[How]
At prepare BW, use the min comp buffer size. When it i
From: Po Ting Chen
[Why]
To move the PSR DPCD caps detection into detect_edp_sink_caps()
Reviewed-by: Anthony Koo
Acked-by: Solomon Chiu
Signed-off-by: Po Ting Chen
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 6 +-
.../drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 58 ++---
From: Ilya
[Why]
Hotplugging the VGA side of some DP/VGA adapters caused the display to
light up with the wrong (non-native) resolution.
This is caused by the adapter misbehaving by reporting the wrong number
of downstream ports when the VGA side is unplugged (reports 1 instead of
0), but only i
From: Fangzhi Zuo
[Why]
When hotplug or unplug happens, each stream disabled one by one, and then
enable any alived streams. Link phy and payload table is cleared when 1st
stream is disabled. That causes the error message pops up when disable 2nd
stream. There is no active stream after link_rate
From: Wayne Lin
[Why]
Currently, we don't have code path to release remote dc_sink when unplug
MST hub from the system. After few times hotplug, we hit the limition of
maximum number of remote dc_sink and can't light up new connected monitor
anymore.
[How]
Releasing all remote dc_sink at dm_help
From: Wenjing Liu
[how]
Call to DMUB to retrieve usb c cable ID data from PD firmware.
If cable id is retrieved from DMUB, skip reading cable ID from RX.
Reviewed-by: George Shen
Acked-by: Solomon Chiu
Signed-off-by: Wenjing Liu
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 +-
...
From: "Shen, George"
[Why]
All fixed VS/PE link training sequence should be refactored
into a separate function outside of the standard link training
sequence. This includes the sequence for non-transparent
mode.
[How]
Isolate link training sequence for fixed VS/PE non-transparent
mode into a se
From: Anthony Koo
Acked-by: Solomon Chiu
Signed-off-by: Anthony Koo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
ind
From: Charlene Liu
[Why&How]
add debug option to bypass ssinfo from bios.
Reviewed-by: Chris Park
Acked-by: Solomon Chiu
Signed-off-by: Charlene Liu
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c | 2 ++
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 2 ++
d
From: Aric Cyr
This version brings along following fixes:
- add debug option to bypass ssinfo from bios.
- Refactor fixed VS logic for non-transparent mode
- add cable ID support for usb c connector
- clear remote dc_sink when stop mst
- Ignore Transitional Invalid Link Rate Error Message
- Fix w
[Public]
Series is:
Reviewed-by: Alex Deucher
From: Chen, Guchun
Sent: Friday, February 18, 2022 9:51 AM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Zhang, Hawking ;
Shi, Leslie ; Cui, Flora ; Koenig,
Christian ; Pan, Xinhui
Cc: Chen, Guchun
Sub
Hi,
Sorry for jumping in in the middle of the thread I did
not notice this thread before.
On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
>> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon Ser
Hi,
On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede
> wrote:
>
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> available to userspace; and let usersp
On Fri, Feb 18, 2022 at 03:57:27PM +0800, David Gow wrote:
> There are a number of Kconfig options which break compilation under UML with
> allyesconfig. As kunit_tool's --alltests option is based on allyesconfig and
> UML, we need to update the list of broken options to make --alltests build
> ag
On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
> I'm thinking of a more theoretical approach: Instead of auditing all users,
> I'd ask, what are the invariants that a vm_normal_page should have. Then
> check, whether our DEVICE_COHERENT pages satisfy them. But maybe the concept
>
Felix Kuehling writes:
> Am 2022-02-16 um 07:26 schrieb Jason Gunthorpe:
>> The other place that needs careful audit is all the callers using
>> vm_normal_page() - they must all be able to accept a ZONE_DEVICE page
>> if we don't set pte_devmap.
>
> How much code are we talking about here? A quic
From: Changcheng Deng
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use "flexible array members" for these cases. The older
style of one-element or zero-length arrays should no longer
Also seen on i386.
On 2/16/22 14:08, Luben Tuikov wrote:
> Fix this ARM warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:664:35: warning: format '%ld'
> expects argument of type 'long int', but argument 4 has type 'size_t' {aka
> 'unsigned int'} [-Wformat=]
>
> Cc: Alex Deucher
> Cc:
On Fri, 2022-02-18 at 15:57 +0800, David Gow wrote:
>
> Note that, while this does build again, it still segfaults on startup,
> so more work remains to be done.
That's probably just a lot more stuff getting included somehow?
> They are:
> - CONFIG_VFIO_PCI: Needs ioport_map/ioport_unmap.
> - CO
On Fri, Feb 18, 2022 at 7:13 AM Simon Ser wrote:
>
> On Friday, February 18th, 2022 at 12:54, Hans de Goede
> wrote:
>
> > On 2/18/22 12:39, Simon Ser wrote:
> > > On Friday, February 18th, 2022 at 11:38, Hans de Goede
> > > wrote:
> > >
> > >> What I'm reading in the above is that it is being
On 2022-02-18 07:12, Simon Ser wrote:
> On Friday, February 18th, 2022 at 12:54, Hans de Goede
> wrote:
>
>> On 2/18/22 12:39, Simon Ser wrote:
>>> On Friday, February 18th, 2022 at 11:38, Hans de Goede
>>> wrote:
>>>
What I'm reading in the above is that it is being considered to allow
>
It looks like this structure isn't being used at all. So I'm OK with
this change, in case we ever use it in the future.
Regards,
Felix
Am 2022-02-18 um 02:47 schrieb Christian König:
Felix need to comment as well, but I don't think that this will work
that easily.
By changing the entry fr
On 2022-02-18 05:03, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> These on stack copies of the modes appear to be pointless.
> Just look at the originals directly.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Rodrigo Siqueira
> Cc: Alex Deucher
> Cc: amd-gfx@lists.freedesktop.org
> Cc: Nik
Well in that case somebody could argue that we should probably remove
the structure altogether.
Regards,
Christian.
Am 18.02.22 um 17:15 schrieb Felix Kuehling:
It looks like this structure isn't being used at all. So I'm OK with
this change, in case we ever use it in the future.
Regards,
On 2022-02-18 05:03, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Initialize on-stack modes with drm_mode_init() to guarantee
> no stack garbage in the list head, or that we aren't copying
> over another mode's list head.
>
> Based on the following cocci script, with manual fixups:
> @decl@
On 2022-02-18 05:03, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves the list he
Am 2022-02-18 um 02:57 schrieb David Gow:
From: Randy Dunlap
cpuinfo_x86 and its associated macros are not available under ARCH=um,
even though CONFIG_X86_64 is defined.
This patch (and discussion) were originally posted here:
https://lkml.org/lkml/2022/1/24/1547
This produces the following
On Fri, Feb 18, 2022 at 11:39 AM Felix Kuehling wrote:
>
>
> Am 2022-02-18 um 02:57 schrieb David Gow:
> > From: Randy Dunlap
> >
> > cpuinfo_x86 and its associated macros are not available under ARCH=um,
> > even though CONFIG_X86_64 is defined.
> >
> > This patch (and discussion) were originall
This parameter controls xGMI p2p communication, which is enabled by
default. However, it can be disabled by setting it to 0. In case xGMI
p2p is disabled in a dGPU, PCIe p2p interface will be used instead.
This parameter is ignored in GPUs that do not support xGMI
p2p configuration.
Signed-off-by:
Update DCN 3.1 for 3.1.5. This is a minor update
to DCN 3.1 display support in amdgpu.
The first two patches are register headers so I did not
send them out due to size.
Qingqing Zhuo (11):
drm/amd/include: add DCN 3.1.5 registers
drm/amd/display: Add DCN315 family information
drm/amd/disp
From: Qingqing Zhuo
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/include/dal_asic_id.h | 6 ++
drivers/gpu/drm/amd/display/include/dal_types.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/d
From: Qingqing Zhuo
Clk and SMU interfaces for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/dc/clk_mgr/Makefile | 9 +
.../gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c | 23 +-
.../dc/clk_mgr/dcn315/dcn315_clk_mgr.
From: Qingqing Zhuo
Add vbios table support for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/bios/command_table_helper2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/bios
From: Qingqing Zhuo
Add GPIO interfaces for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/gpio/Makefile | 8 +
.../dc/gpio/dcn315/hw_factory_dcn315.c| 260
.../dc/gpio/dcn315/hw_factory_
From: Qingqing Zhuo
Add irq interfaces for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/irq/Makefile | 8 +
.../dc/irq/dcn315/irq_service_dcn315.c| 438 ++
.../dc/irq/dcn315/irq_ser
From: Qingqing Zhuo
Add support for the DMUB firmware for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dmub/dmub_srv.h | 1 +
drivers/gpu/drm/amd/display/dmub/src/Makefile | 4 +-
.../drm/amd/display/dmub/src
From: Qingqing Zhuo
Add display resource management for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/dc/dcn315/Makefile| 56 +
.../amd/display/dc/dcn315/dcn315_resource.c | 2302 +
.../amd/dis
From: Qingqing Zhuo
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
b/drivers/gpu/drm/amd/display/dc/Makefile
index 30d028
From: Yifan Zhang
this patch adds dm ip block for dcn 3.1.5.
Signed-off-by: Yifan Zhang
Reviewed-by: Alex Deucher
Reviewed-by: Huang Rui
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdg
From: Qingqing Zhuo
Add display manager support for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 1 +
2 files chan
From: Qingqing Zhuo
DC core changes for DCN 3.1.5.
Signed-off-by: Qingqing Zhuo
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 13 ++---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 8
2 files changed, 18
From: Tom Rix
Clang static analysis reports this problem
kfd_chardev.c:2327:2: warning: 1st function call argument
is an uninitialized value
kvfree(bo_privs);
^~~~
If the copy_from_users(bo_buckets, ...) fails, there is a jump to
the generic error handler at exit:. The freeing
Hi Dave, Daniel,
More new stuff for 5.18.
The following changes since commit b9c7babe2c2e37a50aa42401b38d597ea78f506e:
Backmerge tag 'v5.17-rc4' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next
(2022-02-14 10:52:27 +1000)
are available in the Git repository at:
Am 2022-02-18 um 12:39 schrieb t...@redhat.com:
From: Tom Rix
Clang static analysis reports this problem
kfd_chardev.c:2327:2: warning: 1st function call argument
is an uninitialized value
kvfree(bo_privs);
^~~~
If the copy_from_users(bo_buckets, ...) fails, there is a jum
Am 2022-02-18 um 11:53 schrieb Alex Sierra:
This parameter controls xGMI p2p communication, which is enabled by
default. However, it can be disabled by setting it to 0. In case xGMI
p2p is disabled in a dGPU, PCIe p2p interface will be used instead.
This parameter is ignored in GPUs that do not s
Am 2022-02-17 um 19:19 schrieb Jason Gunthorpe:
On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
I'm thinking of a more theoretical approach: Instead of auditing all users,
I'd ask, what are the invariants that a vm_normal_page should have. Then
check, whether our DEVICE_COHERENT
From: "Souptick Joarder (HPE)"
Kernel test robot reported warning ->
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:2129:2: warning: Undefined
or garbage value returned to caller [clang-analyzer-core.
uninitialized.UndefReturn]
Initialize r inside amdgpu_fill_buffer().
Reported-by: kernel test robot
On Fri, Feb 18, 2022 at 02:20:45PM -0500, Felix Kuehling wrote:
> Am 2022-02-17 um 19:19 schrieb Jason Gunthorpe:
> > On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
> >
> > > I'm thinking of a more theoretical approach: Instead of auditing all
> > > users,
> > > I'd ask, what are
Am 2022-02-18 um 14:26 schrieb Jason Gunthorpe:
On Fri, Feb 18, 2022 at 02:20:45PM -0500, Felix Kuehling wrote:
Am 2022-02-17 um 19:19 schrieb Jason Gunthorpe:
On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
I'm thinking of a more theoretical approach: Instead of auditing all
The driver has a fallback, to make the message informational
rather than a warning.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1906
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
Am 2022-02-18 um 15:42 schrieb Alex Deucher:
The driver has a fallback, to make the message informational
rather than a warning.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1906
Signed-off-by: Alex Deucher
Reviewed-by: Felix Kuehling
Thanks!
---
drivers/gpu/drm/amd/amdkfd/kf
When this was first implemented, overflows weren't expected in regular
operations, and tests weren't in place to cause said overflow. Now there
are cases where overflows occur with real workloads, but we know that
the kernel can handle this robustly, so move the message to a debug
message.
Signed-
Am 2022-02-18 um 17:01 schrieb Kent Russell:
When this was first implemented, overflows weren't expected in regular
operations, and tests weren't in place to cause said overflow. Now there
are cases where overflows occur with real workloads, but we know that
the kernel can handle this robustly, s
So we can tell when this function fails.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 100 +++---
2 files changed, 64 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amd
To avoid multiple runs in parallel to avoid mixing results.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 23 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 1 +
3 files changed, 17 ins
So we can tell which output goes to which device when multiple GPUs
are present. Also while we are here, convert DRM_ERROR to dev_info.
The error cases are not critical.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 12 +++-
1 file changed, 7 insertions
Now that we expose the benchmarks via debugfs, there is no
longer a need for the module parameter.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 8
3 f
This was always duplicate functionality with the benchmark tests.
Drop it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 7 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 -
drivers/gpu/drm/amd/amdgpu/amdgp
So you can tell which benchmark was run.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
index 7709f48e25a1..62
They provide a nice smoke test of transfer performance
using SDMA. Allow the user to run these at runtime
rather than only at init time.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 23 +
1 file changed, 23 insertions(+)
diff --git a/drivers
Clang static analysis reports this problem
kfd_chardev.c:2327:2: warning: 1st function call argument
is an uninitialized value
kvfree(bo_privs);
^~~~
Make sure bo_buckets and bo_privs are initialized so freeing them in the
error handling code path will never result in undefined b
So you can tell which benchmark was run.
v2: print the test description as well
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c | 26 ++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c
b/
[AMD Official Use Only]
Reviewed-by: Rajneesh Bhardwaj
Regards,
Rajneesh
From: Kuehling, Felix
Sent: Friday, February 18, 2022 5:32:18 PM
To: amd-gfx@lists.freedesktop.org
Cc: Bhardwaj, Rajneesh ; Tom Rix
Subject: [PATCH 1/1] drm/amdkfd: Fix criu_restore_bo er
Fix for possible integer overflow when doing addition.
Reported-by: Dan Carpenter
Signed-off-by: David Yat Sin
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b
Am 2022-02-18 um 18:08 schrieb David Yat Sin:
Fix for possible integer overflow when doing addition.
Reported-by: Dan Carpenter
Signed-off-by: David Yat Sin
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1
kfd_chardev() doesn't provide much useful information in dev_... messages
on multi-GPU systems because there is only one KFD device, which doesn't
correspond to any particular GPU. Use the actual GPU device to indicate
the GPU that caused a message.
Signed-off-by: Felix Kuehling
---
drivers/gpu/
Am 2022-02-18 um 21:34 schrieb Tom Rix:
On 2/18/22 10:35 AM, Felix Kuehling wrote:
Am 2022-02-18 um 12:39 schrieb t...@redhat.com:
From: Tom Rix
Clang static analysis reports this problem
kfd_chardev.c:2327:2: warning: 1st function call argument
is an uninitialized value
kvfree(bo_pr
Dear Alex,
Thank you for the patch.
Am 18.02.22 um 21:42 schrieb Alex Deucher:
The driver has a fallback, to make the message informational
s/to/so/?
rather than a warning.
Maybe extend it a little?
Component Resource Association Table (CRAT) are only applicable on some
AMD APUs. The m
Signed-off-by: Paul Menzel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 63a089992645..430e56583751 100644
--- a/drivers/gpu/drm/amd/amdgpu/am
92 matches
Mail list logo
