cmd if
should_use_dmub_lock returns true.
This has been the case since dmub support has been added for PSR1.
This bug has landed on stable trees. Any chance for a review here?
Thanks.
Cascardo.
Thanks for the ping and fix!
Reviewed-by: Leo Li
Fix this by checking for dmub_srv
On 2024-12-19 23:33, Alex Hung wrote:
This adds support for a 3D LUT.
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. Multiplier
3. 3x4 CTM
4. 1D curve colorop
5. 1D LUT
6. 3D LUT
7. 1D curve colorop
8. 1D LUT
Signed-off-by: Alex Hung
---
v7:
- Simplify
On 2024-12-19 23:33, Alex Hung wrote:
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf
The co
On 2024-12-19 23:33, Alex Hung wrote:
This adds support for a 3x4 color transformation matrix.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversa
On 2024-12-19 23:33, Alex Hung wrote:
This patch adds colorops for custom 1D LUTs in the SHAPER and
BLND HW blocks.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut
The color p
On 2024-12-19 23:33, Alex Hung wrote:
From: Harry Wentland
This adds support for the BT.709/BT.2020 transfer functions
on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this change the following IGT subtests pass:
kms_colorop --run plane-XR30-XR30-bt2020_
On 2024-10-25 22:01, Melissa Wen wrote:
On 25/10/2024 16:37, Zaeem Mohamed wrote:
[why]
Prevent index-out-of-bounds due to requiring cursor overlay when
plane_count is MAX_SURFACES.
Hi Zaeem,
Thanks for working on this fix.
[how]
Bounds check on plane_count when requiring overlay curs
On 2024-10-23 09:53, Melissa Wen wrote:
There are two events to trace the beginning and the end of
amdgpu_dm_atomic_commit_tail, but only the one ate the beginning was
placed. Place amdgpu_dm_atomic_commit_tail_finish tracepoint at the end
than.
Signed-off-by: Melissa Wen
Reviewed-by: Leo
Hi Mikhail,
Can you give this patch a try to see if it helps?
https://gist.github.com/leeonadoh/3271e90ec95d768424c572c970ada743
Thanks,
Leo
On 2024-09-10 11:47, Leo Li wrote:
On 2024-09-08 19:30, Mikhail Gavrilov wrote:
I have done additional tests:
1. The computer does not hang with
On 2024-09-08 19:30, Mikhail Gavrilov wrote:
I have done additional tests:
1. The computer does not hang with 6900XT instead the screen flickers
when moving the cursor.
2. The computer does not hang with 7900XTX if I turn off VRR. But the
screen flickers when moving the cursor, as on 6900XT.
T
anes being used on my setup.
Third, in case these two issues are related, can you give the attached patch on
this issue thread a try as well?
https://gitlab.freedesktop.org/drm/amd/-/issues/3569#note_2558359
Thanks,
Leo
On 2024-09-05 02:06, Mikhail Gavrilov wrote:
On Thu, Sep 5, 2024 at 4:06
On 2024-09-04 18:21, Mikhail Gavrilov wrote:
On Wed, Sep 4, 2024 at 4:15 AM Leo Li wrote:
Hi Mike,
Super sorry for the ridiculous wait. Your first two emails slipped by my inbox,
which is really silly, given I'm first in the to field...
Thanks for bisecting and finding a free ga
On 2024-09-03 02:35, Mikhail Gavrilov wrote:
On Sun, Aug 25, 2024 at 2:12 AM Mikhail Gavrilov
wrote:
Hi,
Is anyone trying to look into it?
I continue to reproduce this issue on fresh kernel builds 6.11-rc4+.
In addition to the RenPy engine, the problem also reproduces on games
from Ubisoft
On 2024-08-07 01:13, Mario Limonciello wrote:
On 8/6/24 13:42, Sebastian Wick wrote:
From: Sebastian Wick
This reverts commit 63d0b87213a0ba241b3fcfba3fe7b0aed0cd1cc5.
The panel_power_savings sysfs entry can be used to change the displayed
colorimetry which breaks color managed setups.
Th
o bit mask
"Require low latency" PSR should be disabled.
When the property is restored to an empty bit mask ABM and PSR
can be enabled again.
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
Thanks!
---
v3->v4:
* Fix enabling again after disable (Xaver)
---
dri
o bit mask
"Require low latency" PSR should be disabled.
When the property is restored to an empty bit mask the previous
value of ABM and pSR will be restored.
Signed-off-by: Mario Limonciello
Reviewed-by: Leo Li
Thanks!
---
v2->v3:
* Use `disallow_edp_enter_psr` i
On 2024-05-22 18:08, Mario Limonciello wrote:
Verify that the property has disabled PSR
---
tests/amdgpu/amd_psr.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/tests/amdgpu/amd_psr.c b/tests/amdgpu/amd_psr.c
index 9da161a09..a9f4a6aa5 10064
Thanks for the tests! FYI IGT patches should also cc
igt-...@lists.freedesktop.org
Some comments inline:
On 2024-05-22 18:08, Mario Limonciello wrote:
From: Mario Limonciello
When the "panel power saving" property is set to forbidden the
compositor has indicated that userspace prefers to h
experience intended by the compositor.
Signed-off-by: Mario Limonciello
Acked-by: Leo Li
Thanks!
---
drivers/gpu/drm/drm_connector.c | 46 +
include/drm/drm_connector.h | 2 ++
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h
On 2024-05-22 18:05, Mario Limonciello wrote:
When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.
When the `power_saving_policy` property is set to bit mask
"Requ
On 2024-05-21 13:32, Mario Limonciello wrote:
On 5/21/2024 12:27, Leo Li wrote:
On 2024-05-21 12:21, Mario Limonciello wrote:
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to
On 2024-05-21 12:21, Mario Limonciello wrote:
On 5/21/2024 11:14, Xaver Hugl wrote:
Am Di., 21. Mai 2024 um 16:00 Uhr schrieb Mario Limonciello
:
On 5/21/2024 08:43, Simon Ser wrote:
This makes sense to me in general. I like the fact that it's simple and
vendor-neutral.
Do we want to hard
On 2024-04-16 10:10, Harry Wentland wrote:
On 2024-04-16 04:01, Pekka Paalanen wrote:
On Mon, 15 Apr 2024 18:33:39 -0400
Leo Li wrote:
On 2024-04-15 04:19, Pekka Paalanen wrote:
On Fri, 12 Apr 2024 16:14:28 -0400
Leo Li wrote:
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri
On 2024-04-15 04:19, Pekka Paalanen wrote:
On Fri, 12 Apr 2024 16:14:28 -0400
Leo Li wrote:
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen
wrote:
On Fri, 12 Apr 2024 10:28:52 -0400
Leo Li wrote:
On 2024-04-12 04:03, Pekka Paalanen wrote
On 2024-04-12 11:31, Alex Deucher wrote:
On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen
wrote:
On Fri, 12 Apr 2024 10:28:52 -0400
Leo Li wrote:
On 2024-04-12 04:03, Pekka Paalanen wrote:
On Thu, 11 Apr 2024 16:33:57 -0400
Leo Li wrote:
...
That begs the question of what can be
On 2024-04-12 04:03, Pekka Paalanen wrote:
On Thu, 11 Apr 2024 16:33:57 -0400
Leo Li wrote:
On 2024-04-04 10:22, Marius Vlad wrote:
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote:
Hi all,
On 2024-04-04 06:24, Pekka Paalanen wrote:
On Wed, 3 Apr 2024 17:32:46 -0400
On 2024-04-04 10:22, Marius Vlad wrote:
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote:
Hi all,
On 2024-04-04 06:24, Pekka Paalanen wrote:
On Wed, 3 Apr 2024 17:32:46 -0400
Leo Li wrote:
On 2024-03-28 10:33, Pekka Paalanen wrote:
On Fri, 15 Mar 2024 13:09:56 -0400
On 2024-03-28 10:33, Pekka Paalanen wrote:
On Fri, 15 Mar 2024 13:09:56 -0400
wrote:
From: Leo Li
These patches aim to make the amdgpgu KMS driver play nicer with compositors
when building multi-plane scanout configurations. They do so by:
1. Making cursor behavior more sensible.
2
On 2024-03-28 11:52, Harry Wentland wrote:
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to
points to this commit: b261509952bc19d1012cf732f853659be6ebc61e.
b261509952bc19d1012cf732f853659be6ebc61e is the first bad commit
commit b261509952bc19d1012cf732f853659be6ebc61e
Author: Leo Li
Date: Tue Aug 30 16:38:16 2022 -0400
drm/amd/display: Fix double cursor on non-video RGB MPO
: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
...@amd.com
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Leo Li
---
.../drm/amd/display/dc/core/dc_hw_sequencer.c | 38 -
drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h | 54 +++
2 files changed, 56 insertions
On 1/5/23 15:07, Hamza Mahfooz wrote:
On 1/5/23 13:29, Harry Wentland wrote:
On 1/5/23 12:38, Hamza Mahfooz wrote:
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that s
ts in fill_dc_dirty_rects().
Signed-off-by: Hamza Mahfooz
Thanks for the patch, it LGTM.
Reviewed-by: Leo Li
It would be good to add an IGT case to cover combinations of MPO &
damage clip commits. Perhaps something that covers the usecase of moving
a MPO video, while desktop UI updates. We'd
On 11/15/22 15:24, Hamza Mahfooz wrote:
Currently, userspace doesn't have a way to communicate selective updates
to displays. So, enable support for FB_DAMAGE_CLIPS for DCN ASICs newer
than DCN301, convert DRM damage clips to dc dirty rectangles and fill
them into dirty_rects in fill_dc_dirty_
t are only useful for debugging PSR
(and confusing otherwise). So, we can instead limit the filling of dirty
rectangles to only when PSR is enabled.
Signed-off-by: Hamza Mahfooz
Reviewed-by: Leo Li
Thanks
---
v2: give a more concrete reason.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.
> >
> > Despite the DMA completing successfully, no data was copied into the
> > buffer, leaving the original (now junk) contents. I probed the I2C bus
> > with an oscilloscope, and I verified that the transfer did indeed occur.
> > The timing between submission and completion seems reasonable for
> -Original Message-
> From: Sean Anderson
> Sent: Tuesday, September 20, 2022 11:21 AM
> To: Robin Murphy ; Oleksij Rempel
> ; Pengutronix Kernel Team
> ; linux-...@vger.kernel.org; linux-arm-kernel
> ; Vinod Koul ;
> dmaeng...@vger.kernel.org; Leo Li ; Lauren
> ; Linux Kernel Mailing List ker...@vger.kernel.org>; linux-me...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; Joy Zou
> ; Peng Ma ; Robin Gong
> ; Shawn Guo ; Leo Li
>
> Subject: [BUG] ls1046a: eDMA does not transfer data from I2C
&
On 2018-10-12 03:34 AM, Daniel Vetter wrote:
On Thu, Oct 11, 2018 at 08:27:43PM -0400, sunpeng...@amd.com wrote:
From: Leo Li
This fixes a general protection fault, caused by accessing the contents
of a flip_done completion object that has already been freed. It occurs
due to the preemption
481 ("drm/amd/display: Use DRM helper for
best_encoder").
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Andrey Grodzovsky
Cc: Tony Cheng
Cc: "Leo (Sunpeng) Li"
Cc: Shirish S
Acked-by: Harry Wentland
Thx for rebasing :)
Review
On 2018-09-03 12:54 PM, Daniel Vetter wrote:
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
Thanks for the patch! It seems I made an
On 2018-08-11 11:54 AM, Arnd Bergmann wrote:
Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
that do a comparison of floating-point variables:
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc
On 2018-07-31 02:24 PM, Dan Carpenter wrote:
[ Potential security issue, if I'm reading the code correctly. I don't
really know the code and I haven't looked at the larger context. -dan ]
Hello Leo (Sunpeng) Li,
The patch edf6ffe4f47e: "drm/amd/display: Read AUX channel even if
only statu
we
already gets as part of verify_crc_source.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4
On 2018-07-03 06:19 AM, Maarten Lankhorst wrote:
Op 02-07-18 om 13:07 schreef Mahesh Kumar:
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-
Updated IGT results seem sane:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html
Would someone be able to apply this patch?
Thanks,
Leo
On 2018-01-17 03:18 PM, Sean Paul wrote:
On Wed, Jan 17, 2018 at 10:39 AM, Maarten Lankhorst
wrote:
Op 17-01-18 om 19:29 schreef Sean Paul
On 2017-12-13 02:24 PM, Leo Li wrote:
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object during
non-blocking commits. Within drm_atomic_helper_setup_commit, a reference
to the commit objec
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object d
50 matches
Mail list logo
