[AMD Official Use Only - General]
Issue: during evict or validate happened on amdgpu_bo, the 'from' and
'to' is always same in ftrace event of amdgpu_bo_move
where calling the 'trace_amdgpu_bo_move', the comment says move_notify
is called before move happens, but actually it is called after
add power save mode workload for smu 13.0.10, so that in compute mode,
pmfw will add 35mv voltage margin since some applications requres higher
voltages.
Signed-off-by: Kenneth Feng
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 23 +++
1 file changed, 13 insertions(+), 10
Am 13.12.23 um 00:31 schrieb Woody Suwalski:
Fix to avoid multiple debug error lines printed on every suspend by
Radeon driver's debugfs.
radeon_debugfs_init() calls debugfs_create_file() for every ring.
This results in printing multiple error lines to the screen and dmesg
similar to this:
From: Aric Cyr
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
- change static screen wait frame_count for ips
- Fix hang/underflow when transitioning to ODM4:1
- Only clear symclk otg flag for HDMI
- Fix lightup regression with DP2 single display configs
-
From: Anthony Koo
- Remove unused dmub_fw_boot_options flag
Acked-by: Wayne Lin
Signed-off-by: Anthony Koo
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
From: Allen Pan
[Why]
the original wait for 2 static frames before enter static screen
was not good enough for IPS-enabled case since enter/exit takes more time.
[How]
Changed logic for hardcoded wait frame values.
Reviewed-by: Charlene Liu
Acked-by: Wayne Lin
Signed-off-by: Allen Pan
---
From: Ilya Bakoulin
[Why]
Under some circumstances, disabling an OPTC and attempting to reclaim
its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs
not being properly disconnected from the disabled OPTC.
[How]
Ensure that all OPPs are unassigned from an OPTC when it gets
From: Alvin Lee
[Description]
There is a corner case where the symclk otg flag is cleared
when disabling the phantom pipe for subvp (because the phantom
and main pipe share the same link). This is undesired because
we need the maintain the correct symclk otg flag state for
the main pipe.
For
From: Dillon Varone
[WHY?]
Phantom streams and planes were previously not referenced explcitly on creation.
[HOW?]
To reduce memory management complexity, add an additional phantom streams and
planes
reference into dc_state, and move mall_stream_config to stream_status inside
the state to make
From: Michael Strauss
[WHY]
Previous fix for multiple displays downstream of DP2 MST hub caused regression
[HOW]
Match sink IDs instead of sink struct addresses
Reviewed-by: Nicholas Kazlauskas
Reviewed-by: Charlene Liu
Acked-by: Wayne Lin
Signed-off-by: Michael Strauss
---
From: Nicholas Kazlauskas
[Why]
DMCUB can be in idle when we attempt to interface with the HW through
the GPINT mailbox resulting in a system hang.
[How]
Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep
sequence.
If the GPINT executes successfully then DMCUB will be put back
From: Nicholas Kazlauskas
[Why]
We can hang in place trying to send commands when the DMCUB isn't
powered on.
[How]
For functions that execute within a DC context or DC lock we can
wrap the direct calls to dm_execute_dmub_cmd/list with code that
exits idle power optimizations and reallows once
From: Nicholas Kazlauskas
[Why]
We can hang in place trying to send commands when the DMCUB isn't
powered on.
[How]
We need to exit out of the idle state prior to sending a command,
but the process that performs the exit also invokes a command itself.
Fixing this issue involves the following:
From: Roman Li
[Why]
Idle power optimization was disabled on dcn35 by default.
[How]
Enable by setting disable_idle_power_optimizations to false.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Wayne Lin
Signed-off-by: Roman Li
---
drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
From: Allen Pan
[why]
BIOS switches to use USB-C connector type 0x18, but VBIOS's
objectInfo table not supported yet. driver needs to patch it
based on enc_cap from system integration info table.
Reviewed-by: Charlene Liu
Acked-by: Wayne Lin
Signed-off-by: Allen Pan
---
From: Muhammad Ahmed
[why & how]
Add new option for debug usage
Reviewed-by: Charlene Liu
Acked-by: Wayne Lin
Signed-off-by: Muhammad Ahmed
---
drivers/gpu/drm/amd/display/dc/dc.h | 1 +
drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 3 ++-
2 files changed, 3
From: George Shen
[Why]
In certain cases, ODM pipe split can occur while stream already has test
pattern enabled. The new pipe used in the ODM combine config must be
configured to output the test pattern in this case.
[How]
If the stream is configured to output test pattern, then set the
From: Josip Pavic
[Why]
Driver incorrectly checks if pointer variable OutBpp is null instead of
if the value being pointed to is zero.
[How]
Dereference OutBpp before checking for a value of zero.
Reviewed-by: Chaitanya Dhere
Acked-by: Wayne Lin
Signed-off-by: Josip Pavic
---
From: Charlene Liu
[why & how]
we have two SSC_En:
we get ssc_info from dce_info for MPLL_SSC_EN.
we used to call VBIOS cmdtbl's smu_info's SS persentage for DPRECLK SS info,
is used for DP AUDIO and VBIOS' smu_info table was from
systemIntegrationInfoTable.
since dcn35 VBIOS removed smu_info,
From: Samson Tam
[Why]
On resume from S3, while DMUB is inactive, DMUB queue and execute
calls will not work. Skip reporting errors in these scenarios
[How]
Add new return code during DMUB queue and execute calls when DMUB
is in S3 state. Skip logging errors in these scenarios
Reviewed-by:
From: Josip Pavic
[Why]
This variable currently overflows after about 71 minutes. This doesn't
cause any known functional issues but it does make debugging more
difficult.
[How]
Make it a 64-bit variable.
Reviewed-by: Aric Cyr
Acked-by: Wayne Lin
Signed-off-by: Josip Pavic
---
From: Wayne Lin
[Why & how]
Refactor dc_is_dmub_outbox_supported() a bit and add case for dcn35 to
register dmub outbox notification irq to handle usb4 relevant hpd event.
Reviewed-by: Roman Li
Reviewed-by: Jun Lei
Signed-off-by: Wayne Lin
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 26
From: Johnson Chen
[why]
Allow devs to check raw clk register values by dumping them on the log
[how]
Add clk register dump implementation
Reviewed-by: Charlene Liu
Acked-by: Wayne Lin
Signed-off-by: Johnson Chen
---
.../display/dc/clk_mgr/dcn35/dcn35_clk_mgr.c | 7 +++
From: Aric Cyr
[why]
There is only a single call to dc_post_update_surfaces_to_stream so
there is no need to have two flags to control it. Unifying this to a
single flag allows dc_stream_adjust_vmin_vmax to skip actual
programming when there is no change required.
[how]
Remove
From: Alvin Lee
[Description]
Revert commit 8c5660987ee1 ("drm/amd/display: Use channel_width = 2 for vram
table 3.0")
Because the issue is being fixed from VBIOS side.
Reviewed-by: Samson Tam
Acked-by: Wayne Lin
Signed-off-by: Alvin Lee
---
From: Muhammad Ahmed
[why & how]
Add config to make HPO PG handled in dmubfw ips entry/exit
Reviewed-by: Charlene Liu
Acked-by: Wayne Lin
Signed-off-by: Muhammad Ahmed
---
drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Samson Tam
[Why]
On resume from S3, may get apply_idle_optimizations call while DMUB
is inactive which will just time out.
[How]
Set and track power state in dmub_srv and check power state before
sending commands to DMUB. Add interface in both dmub_srv and
dc_dmub_srv
Reviewed-by:
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
- change static screen wait frame_count for ips
- Fix hang/underflow when transitioning to ODM4:1
- Only clear symclk otg flag for HDMI
- Fix lightup regression with DP2 single display configs
- Refactor phantom
[Public]
Again, MES only knows to flush if there was something enqueued in the first
place.
SET_SHADER dictates what's on the process list.
SET_SHADER can be the last call prior to process termination with nothing
enqueued, hence no MES auto flush occurs.
MES doesn't block anything on the
[Public]
You try to add one new interface to inform mes about the context flush after
driver side finish process termination , from my understanding, mes already
know the process context need to be purged after all the related queues been
removed even without this notification. What do you
pm supports return vpe clock table and soc clock table
Signed-off-by: Peyton Lee
---
drivers/gpu/drm/amd/display/dc/dm_pp_smu.h| 2 ++
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 10 ++
drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 1 +
enable vpe dpm
Signed-off-by: Peyton Lee
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.c | 250
drivers/gpu/drm/amd/amdgpu/amdgpu_vpe.h | 12 ++
drivers/gpu/drm/amd/amdgpu/vpe_v6_1.c | 15 ++
3 files changed, 277 insertions(+)
diff --git
[AMD Official Use Only - General]
Issue: during evict or validate happened on amdgpu_bo, the 'from' and
'to' is always same in ftrace event of amdgpu_bo_move
where calling the 'trace_amdgpu_bo_move', the comment says move_notify
is called before move happens, but actually it is called after
On 12/12/2023 18:08, Oliver Schmidt wrote:
Hi Wayne,
On 12.12.23 17:06, Mario Limonciello wrote:
I looked through your bugs related to this and I didn't see a reference to the
specific docking station model.
The logs mentioned "Thinkpad dock" but no model.
Could you share more about it so that
[Public]
> -Original Message-
> From: Liu, Shaoyun
> Sent: Tuesday, December 12, 2023 7:08 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
>
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader
[AMD Official Use Only - General]
> -Original Message-
> From: Zhu, James
> Sent: Thursday, December 7, 2023 5:54 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix ; Greathouse, Joseph
> ; Yat Sin, David ;
> Zhu, James
> Subject: [PATCH v2 03/23] drm/amdkfd: enable pc
[Public]
I see, so the problem is after process context , set_shader been called with
disable parameter, do you know the reason why MES re-added the process
context into the list ?
Shaoyun.liu
-Original Message-
From: Kim, Jonathan
Sent: Tuesday, December 12, 2023 6:07 PM
To:
[Public]
> -Original Message-
> From: Liu, Shaoyun
> Sent: Tuesday, December 12, 2023 5:44 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
>
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader
[Public]
Do you mean SET_SHADER_DEBUGER can be called before ADD_QUEUE ? I think even
in that situation MES should still be able to handle it as long as MES already
remove the process context from its list , MES will treat the process context
as a new item. I still don't understand why
[Public]
> -Original Message-
> From: Liu, Shaoyun
> Sent: Tuesday, December 12, 2023 4:45 PM
> To: Kim, Jonathan ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
>
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader
[Public]
Shouldn't the driver side remove all the remaining queues for the process
during process termination ? If all the queues been removed for the process
, MES should purge the process context automatically , otherwise it's bug
inside MES .
Regard
Sshaoyun.liu
-Original
[Public]
> -Original Message-
> From: Liu, Shaoyun
> Sent: Tuesday, December 12, 2023 4:00 PM
> To: Huang, JinHuiEric ; Kim, Jonathan
> ; amd-gfx@lists.freedesktop.org
> Cc: Wong, Alice ; Kuehling, Felix
> ; Kasiviswanathan, Harish
>
> Subject: RE: [PATCH] drm/amdkfd: fix mes set shader
[AMD Official Use Only - General]
Does this requires the new MES FW for this process_ctx_flush requirement ?
Can driver side add logic to guaranty when call SET_SHADER_DEBUGGER, the
process address is always valid ?
Regards
Shaoyun.liu
-Original Message-
From: amd-gfx On Behalf
On 2023-12-11 16:16, Jonathan Kim wrote:
MES provides the driver a call to explicitly flush stale process memory
within the MES to avoid a race condition that results in a fatal
memory violation.
When SET_SHADER_DEBUGGER is called, the driver passes a memory address
that represents a process
On Mon, Dec 11, 2023 at 11:12:42PM -0800, Christoph Hellwig wrote:
> On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> > Actually tracking all possibly-FPU-tainted functions and their call sites is
> > probably possible, but a much larger task.
>
> I think objtool should be able
On Tue, Dec 12, 2023 at 12:37 PM Alex Deucher wrote:
>
> On Tue, Dec 12, 2023 at 12:30 PM Mario Limonciello
> wrote:
> >
> > commit 751e293f2c99 ("drm/amd: Move microcode init from sw_init to
> > early_init for SDMA v2.4") made a fateful mistake in
> > `adev->sdma.num_instances` wasn't declared
On Tue, Dec 12, 2023 at 12:30 PM Mario Limonciello
wrote:
>
> commit 751e293f2c99 ("drm/amd: Move microcode init from sw_init to
> early_init for SDMA v2.4") made a fateful mistake in
> `adev->sdma.num_instances` wasn't declared when sdma_v2_4_init_microcode()
> was run. This caused probing to
commit 751e293f2c99 ("drm/amd: Move microcode init from sw_init to
early_init for SDMA v2.4") made a fateful mistake in
`adev->sdma.num_instances` wasn't declared when sdma_v2_4_init_microcode()
was run. This caused probing to fail.
Move the declaration to right before sdma_v2_4_init_microcode().
On Tue, Dec 12, 2023 at 11:25 AM Mario Limonciello
wrote:
>
> On 12/12/2023 03:46, Johannes Berg wrote:
> > On Mon, 2023-12-11 at 12:02 +0100, Hans de Goede wrote:
> >> Hi Wifi and AMDGPU maintainers,
> >>
> >> Here is a pull-request for the platform-drivers-x86 parts of:
> >>
> >>
On 12/12/2023 03:46, Johannes Berg wrote:
On Mon, 2023-12-11 at 12:02 +0100, Hans de Goede wrote:
Hi Wifi and AMDGPU maintainers,
Here is a pull-request for the platform-drivers-x86 parts of:
https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
From my pov
On 12/12/2023 04:10, Lin, Wayne wrote:
[Public]
Hi Mario,
Thanks for the help.
My feeling is like this problem probably relates to specific dock. Need time to
take
further look.
Oliver,
I looked through your bugs related to this and I didn't see a reference
to the specific docking station
On Mon, Dec 11, 2023 at 7:28 PM Phillip Susi wrote:
>
> Phillip Susi writes:
>
> > And it works, but 6.7-rc5 does not, even though it includes that patch.
> > Here's the syslog from the attempt. I'll start bisecting again.
>
> I checked out the patch that got merged upstream and it also fails.
Including drm_edid.h from amdgpu_mode.h causes the rebuild of literally
hundreds of files when drm_edid.h is modified, while there are only a
handful of files that actually need to include drm_edid.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 2
On Mon, 2023-12-11 at 12:02 +0100, Hans de Goede wrote:
> Hi Wifi and AMDGPU maintainers,
>
> Here is a pull-request for the platform-drivers-x86 parts of:
>
> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
>
> From my pov the pdx86 bits are ready and the
Including drm_edid.h from radeon_mode.h causes the rebuild of more than
a hundred files when drm_edid.h is modified, while there are only a
handful of files that actually need to include drm_edid.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/radeon/atombios_encoders.c | 1 +
Applied with some minor fixups for our -next tree.
Thanks!
Alex
On Tue, Dec 12, 2023 at 9:10 AM Jani Nikula wrote:
>
> Including drm_edid.h from amdgpu_mode.h causes the rebuild of literally
> hundreds of files when drm_edid.h is modified, while there are only a
> handful of files that
Applied. Thanks!
Alex
On Tue, Dec 12, 2023 at 9:10 AM Jani Nikula wrote:
>
> Including drm_edid.h from radeon_mode.h causes the rebuild of more than
> a hundred files when drm_edid.h is modified, while there are only a
> handful of files that actually need to include drm_edid.h.
>
>
On Fri, Dec 1, 2023 at 7:18 PM Friedrich Vock wrote:
>
> This improves latency if the GPU is already busy with other work.
> This is useful for VR compositors that submit highly latency-sensitive
> compositing work on high-priority compute queues while the GPU is busy
> rendering the next frame.
[AMD Official Use Only - General]
Reviewed-by: Stanley.Yang
Regards,
Stanley
> -Original Message-
> From: Zhang, Hawking
> Sent: Tuesday, December 12, 2023 10:03 PM
> To: amd-gfx@lists.freedesktop.org; Yang, Stanley ;
> Wang, Yang(Kevin)
> Cc: Zhang, Hawking
> Subject: [PATCH]
[AMD Official Use Only - General]
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: Zhang, Hawking
Sent: Tuesday, December 12, 2023 10:03 PM
To: amd-gfx@lists.freedesktop.org; Yang, Stanley ; Wang,
Yang(Kevin)
Cc: Zhang, Hawking
Subject: [PATCH] drm/amdgpu: Switch
Instead of software managed counters.
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mca.h | 2 ++
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 6 --
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
On 2023-12-08 18:59, Alex Deucher wrote:
> On Fri, Dec 8, 2023 at 12:27 PM Joshua Ashton wrote:
>>
>> I heard some musings about dmabuf deadline kernel work recently, but not
>> sure if any of that is applicable to AMD.
>
> I think something like a workload hint would be more useful. We did a
>
[Public]
Hi Mario,
Thanks for the help.
My feeling is like this problem probably relates to specific dock. Need time to
take
further look.
Since reverting solves the issue now, feel free to add:
Acked-by: Wayne Lin
Thanks,
Wayne
> -Original Message-
> From: Limonciello, Mario
>
Am 11.12.23 um 05:29 schrieb Wang, Beyond:
[AMD Official Use Only - General]
Subject: [PATCH 1/1] drm/amdgpu: fix ftrace event amdgpu_bo_move
always move on same heap
Issue: during evict or validate happened on amdgpu_bo, the 'from' and
'to' is always same in ftrace event of
Am 12.12.23 um 00:43 schrieb Felix Kuehling:
On 2023-12-11 05:38, Christian König wrote:
Am 09.12.23 um 00:01 schrieb James Zhu:
Needn't do schedule for each hmm_range_fault, and use cond_resched
to replace schedule.
cond_resched() is usually NAKed upstream since it is a NO-OP in most
On Thu, Dec 07, 2023 at 10:49:53PM -0600, Samuel Holland wrote:
> Actually tracking all possibly-FPU-tainted functions and their call sites is
> probably possible, but a much larger task.
I think objtool should be able to do that reasonably easily, it already
does it for checking section where
On Mon, Dec 11, 2023 at 10:12:27AM -0600, Samuel Holland wrote:
> On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
>
> Unfortunately, not all of the relevant options can be no-prefixed:
Ok. That is another good argument for having the obj-fpu += syntax
I proposed. You might need help from the
Phillip Susi writes:
> And it works, but 6.7-rc5 does not, even though it includes that patch.
> Here's the syslog from the attempt. I'll start bisecting again.
I checked out the patch that got merged upstream and it also fails. I
looked at the two commits, and I see what happened. Your
68 matches
Mail list logo
