For GFX9.4.3, setup a reduced default CWSR grace period equal to
1000 cycles instead of 64000 cycles.
Signed-off-by: Mukul Joshi
Reviewed-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 2 +-
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 22 ++-
2
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of Eric
> Huang
> Sent: Monday, July 10, 2023 3:46 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, JinHuiEric ; Kim, Jonathan
>
> Subject: [PATCH] drm/amdkfd: enable grace period for xcp instance
>
>
On 10/07/2023 12:10, Thomas Zimmermann wrote:
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving
On 2023-07-10 16:19, Liu, Leo wrote:
[AMD Official Use Only - General]
[AMD Official Use Only - General]
-Original Message-
From: Jamadar, Saleemkhan
Sent: Monday, July 10, 2023 12:54 PM
To: Jamadar, Saleemkhan ; amd-gfx@lists.freedesktop.org; Liu, Leo
; Gopalakrishnan,
OK. Mukul, I will resend this patch based on top of yours.
Regards,
Eric
On 2023-07-10 18:24, Joshi, Mukul wrote:
[AMD Official Use Only - General]
-Original Message-
From: amd-gfx On Behalf Of Eric
Huang
Sent: Monday, July 10, 2023 3:46 PM
To: amd-gfx@lists.freedesktop.org
Cc:
[Public]
> -Original Message-
> From: Koenig, Christian
> Sent: Monday, July 10, 2023 6:16 PM
> To: Chen, Guchun ; amd-
> g...@lists.freedesktop.org; Deucher, Alexander
> ; Zhang, Hawking
> ; Milinkovic, Dusica
> ; Prica, Nikola ; Cui,
> Flora
> Cc: sta...@vger.kernel.org
> Subject: Re:
In below thousands of screen rotation loop tests with virtual display
enabled, a CPU hard lockup issue may happen, leading system to unresponsive
and crash.
do {
xrandr --output Virtual --rotate inverted
xrandr --output Virtual --rotate right
xrandr --output Virtual
Thomas Zimmermann writes:
Hello Thomas,
> Generate a hotplug event after registering a client to allow the
> client to configure its display. Remove the hotplug calls from the
> existing clients for fbdev emulation. This change fixes a concurrency
> bug between registering a client and
Am 10.07.23 um 08:38 schrieb Guchun Chen:
In below thousands of screen rotation loop tests with virtual display
enabled, a CPU hard lockup issue may happen, leading system to unresponsive
and crash.
do {
xrandr --output Virtual --rotate inverted
xrandr --output Virtual
It is advisable to utilize the max() function in the dc_dmub_srv.c file,
as it conforms better to programming conventions.
Signed-off-by: Yang Rong
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
mode change 100644 => 100755
Hi
Am 10.07.23 um 11:52 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in
Am 07.07.23 um 17:49 schrieb Philip Yang:
Retry faults are delegated to soft IH ring and then processed by
deferred worker. Current soft IH ring size PAGE_SIZE can store 128
entries, which may overflow and drop retry faults, causes HW stucks
because the retry fault is not recovered.
Increase
Am 07.07.23 um 17:20 schrieb Saleemkhan Jamadar:
add session context buffer to decoder ring test.
v5 - clear the session ct buffer (Christian)
v4 - data type, explain change of ib size change (Christian)
v3 - indent and v2 changes correction. (Christian)
v2 - put the buffer at the end of the
On Fri, 7 Jul 2023 19:40:59 -0300
André Almeida wrote:
> From: Pekka Paalanen
>
> Specify how the atomic state is maintained between userspace and
> kernel, plus the special case for async flips.
>
> Signed-off-by: Pekka Paalanen
> Signed-off-by: André Almeida
> ---
> v4: total rework by
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
In below thousands of screen rotation loop tests with virtual display
enabled, a CPU hard lockup issue may happen, leading system to unresponsive
and crash.
do {
xrandr --output Virtual --rotate inverted
xrandr --output Virtual --rotate right
xrandr --output Virtual
add session context buffer to decoder ring test for vcn v1 to v3.
v2 - add the buffer into IB (Leo liu)
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
Signed-off-by: Evan Quan
Reviewed-by: Mario
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 31 +++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
[Public]
> -Original Message-
> From: Chen, Guchun
> Sent: Friday, July 7, 2023 9:06 AM
> To: Koenig, Christian ; amd-
> g...@lists.freedesktop.org; Deucher, Alexander
> ; Zhang, Hawking
> ; Milinkovic, Dusica
> ; Prica, Nikola ; Cui,
> Flora
> Cc: sta...@vger.kernel.org
> Subject: RE:
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices
AMD has introduced an ACPI based mechanism to support WBRF for some
platforms with AMD dGPU + WLAN. This needs support from BIOS equipped
with necessary AML implementations and dGPU firmwares.
For those systems without the ACPI mechanism and developing solutions,
user can use the generic WBRF
Due to electrical and mechanical constraints in certain platform designs there
may
be likely interference of relatively high-powered harmonics of the (G-)DDR
memory
clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate
possible RFI interference producers can advertise
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Signed-off-by:
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
is 0 and the static declaration already clears the memory area of
sh7763fb_videomode. So remove the assignment.
Signed-off-by: Thomas Zimmermann
Cc: Yoshinori
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by a static declaration. So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by:
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by a static declaration. So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_FLAG_DEFAULT, the token can be removed.
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann
Cc: Helge Deller
---
include/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d5c13f34b09..43458f582f35 100644
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
[AMD Official Use Only - General]
-Original Message-
From: Jamadar, Saleemkhan
Sent: Monday, July 10, 2023 4:24 AM
To: Jamadar, Saleemkhan ;
amd-gfx@lists.freedesktop.org; Liu, Leo ; Gopalakrishnan,
Veerabadhran (Veera) ; Sundararaju,
Sathishkumar
Cc: Koenig, Christian ; Rao, Srinath
[AMD Official Use Only - General]
Thanks for looking into this.
I got an email about this from kernel test robot, can you add this also to the
commit message:
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202307080505.v12qs0oz-...@intel.com
Reviewed-by: Mukul
Hi!
On Mon, 2023-07-10 at 16:04 +0200, Thomas Zimmermann wrote:
> > > I won't argue with that, but the flag itself is wrong.
> > > FBINFO_FLAG_DEFAULT is/was for struct fb_info.flags. You have struct
> > > fb_videomode.flag. The valid flags for this field are at [1]. If
> > > anything, the field
Hi Thomas!
On Mon, 2023-07-10 at 15:52 +0200, Thomas Zimmermann wrote:
> > I would argue that the current code is more readable that your proposed
> > change.
> >
> > I agree that it's a no-op, but code is not just about functionality but also
> > readability, isn't it?
>
> I won't argue with
Hi Thomas!
On Mon, 2023-07-10 at 14:50 +0200, Thomas Zimmermann wrote:
> FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
> is 0 and the static declaration already clears the memory area of
>
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by devm_kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurences of FBINFO_DEFAULT, the token can be removed.
Signed-off-by: Thomas
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
>
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
>
> Flags should signal differences from the default values. After cleaning
> up all
Fix eleven occurrences of the checkpatch.pl error:
ERROR: that open brace { should be on the previous line
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/rv770.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rv770.c
Fix four occurrences of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/radeon_test.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_test.c
Fix four occurrences of the checkpatch.pl error:
ERROR: "(foo*)" should be "(foo *)"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/radeon_atombios.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
Fix nine occurrences of the checkpatch.pl error:
ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Ran Sun
---
drivers/gpu/drm/radeon/atom.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c
b/drivers/gpu/drm/radeon/atom.c
Hi
Am 10.07.23 um 15:59 schrieb John Paul Adrian Glaubitz:
Hi Thomas!
On Mon, 2023-07-10 at 15:52 +0200, Thomas Zimmermann wrote:
I would argue that the current code is more readable that your proposed change.
I agree that it's a no-op, but code is not just about functionality but also
Hi
Am 10.07.23 um 15:42 schrieb John Paul Adrian Glaubitz:
Hi Thomas!
On Mon, 2023-07-10 at 14:50 +0200, Thomas Zimmermann wrote:
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
is 0 and the static
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
>
> The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
> fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
> not set it.
`framebuffer_alloc()` does indeed use `kzalloc()`, but the docs do not
mention the
Hi
Am 10.07.23 um 16:24 schrieb Miguel Ojeda:
On Mon, Jul 10, 2023 at 3:01 PM Thomas Zimmermann wrote:
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
`framebuffer_alloc()` does indeed use
On 2023-07-10 06:54, Christian König
wrote:
Am
07.07.23 um 17:49 schrieb Philip Yang:
Retry faults are delegated to soft IH ring
and then processed by
deferred worker. Current soft IH ring size PAGE_SIZE can store
+regressions
On 7/10/2023 04:58, Thomas Zimmermann wrote:
Hi
Am 10.07.23 um 11:52 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
Applied. Thanks!
On Mon, Jul 10, 2023 at 3:38 AM wrote:
>
> Fix nine occurrences of the checkpatch.pl error:
> ERROR: "foo * bar" should be "foo *bar"
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/radeon/atom.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>
Applied. Thanks!
Alex
On Mon, Jul 10, 2023 at 3:52 AM wrote:
>
> Fix four occurrences of the checkpatch.pl error:
> ERROR: "(foo*)" should be "(foo *)"
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/radeon/radeon_test.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
Applied. Thanks!
On Mon, Jul 10, 2023 at 4:27 AM wrote:
>
> Fix four occurrences of the checkpatch.pl error:
> ERROR: "(foo*)" should be "(foo *)"
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/radeon/radeon_atombios.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
Hi Thomas,
On Mon, Jul 10, 2023 at 02:50:04PM +0200, Thomas Zimmermann wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit
On Mon, Jul 10, 2023 at 5:22 PM Thomas Zimmermann wrote:
>
> I'll append a patch to the series that documents this.
>
> Sure.
Thanks!
If you are planning to take it into some other tree:
Acked-by: Miguel Ojeda
Otherwise, I can take it into the `auxdisplay` tree.
Cheers,
Miguel
add session context buffer to decoder ring test fro vcn v1 to v3.
v3 - correct the cmd for sesssion ctx buf
v2 - add the buffer into IB (Leo liu)
Signed-off-by: Saleemkhan Jamadar
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
Applied. Thanks!
On Mon, Jul 10, 2023 at 5:06 AM wrote:
>
> Fix eleven occurrences of the checkpatch.pl error:
> ERROR: that open brace { should be on the previous line
>
> Signed-off-by: Ran Sun
> ---
> drivers/gpu/drm/radeon/rv770.c | 22 +++---
> 1 file changed, 11
- Add checks for Cursor update and dirty rects (sending updates to dmub)
- Add checks for dc_notify_vsync, and fbc and subvp
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/core/dc.c| 6 ++
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c|
Add various functions for replay, such as construct, destroy, enable
get_state, and copy_setting etc. These functions communicate with the
firmware to setup and enable panel replay
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/dce/Makefile | 2 +-
We need to make sure that the panel supports replay.
This info is inside the amd vsdb (vendor specific data block). Create a
function to parse the block and read the replay_mode bit.
Signed-off-by: Bhawanpreet Lakha
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 44 +++
Add Replay calls to clk_mgr updates (just like PSR)
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c
- Setup replay config on device init.
- Enable replay if feature is enabled (prioritize replay over PSR, since
it can be enabled in more usecases)
- Add debug masks to enable replay on supported ASICs
Signed-off-by: Bhawanpreet Lakha
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23
In some instances, the GPU is transmitting repeated frame to the sink
without any updates or changes in the content. These repeat transmission
are wasteful, resulting in power draw in different aspects of the system
1. DCN is fetching the frame of data from DF/UMC/DRAM. This memory traffic
This patch set introduces Freesync Panel Replay capability on DCN 3.1.4
and newer. Replay has been verified to be working with these patches (in
house)
These patches are enabling panel replay in static screen use-cases.
Other use cases will be added as they are ready
The importance of Replay
We need certain conditions for replay to be enabled, so create an
interface in DM to enable/disable replay.
Signed-off-by: Bhawanpreet Lakha
---
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 2 +-
.../amd/display/amdgpu_dm/amdgpu_dm_replay.c | 176 ++
Handle replay related hpd irqs
Signed-off-by: Bhawanpreet Lakha
---
.../dc/link/protocols/link_dp_irq_handler.c | 66 +++
1 file changed, 66 insertions(+)
diff --git
a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_irq_handler.c
Update infopackets for replay
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c | 4
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
Read DP_SINK_PR_PIXEL_DEVIATION_PER_LINE and
DP_SINK_PR_MAX_NUMBER_OF_DEVIATION_LINE
Signed-off-by: Bhawanpreet Lakha
---
.../amd/display/dc/link/protocols/link_dp_capability.c | 10 ++
drivers/gpu/drm/amd/display/include/dpcd_defs.h| 2 ++
2 files changed, 12 insertions(+)
Read/write grace period from/to first xcc instance of
xcp in kfd node.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 ---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c| 10
On Mon, Jul 10, 2023 at 3:27 PM Bhawanpreet Lakha
wrote:
>
> This patch set introduces Freesync Panel Replay capability on DCN 3.1.4
> and newer. Replay has been verified to be working with these patches (in
> house)
>
> These patches are enabling panel replay in static screen use-cases.
> Other
[AMD Official Use Only - General]
-Original Message-
From: Jamadar, Saleemkhan
Sent: Monday, July 10, 2023 12:54 PM
To: Jamadar, Saleemkhan ;
amd-gfx@lists.freedesktop.org; Liu, Leo ; Gopalakrishnan,
Veerabadhran (Veera) ; Sundararaju,
Sathishkumar
Cc: Koenig, Christian ; Rao,
83 matches
Mail list logo