On 2025-08-01 04:39, Timur Kristóf wrote:
> On Fri, 2025-08-01 at 03:19 -0400, Alexandre Demers wrote:
>>> On 2025-07-30 13:08, Timur Kristóf wrote:
>>>> On Wed, 2025-07-30 at 10:34 -0400, Harry Wentland wrote:
>>>>>
>>>>>
>>>>
Thanks for the series. It makes sense to me.
Below are my thoughts on the deadline value on amdgpu.
On 2025-07-24 12:40, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Set it to the end of the front porch.
>
> Signed-off-by: Michel Dänzer
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> Suggested-by: Xaver Hugl
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3034
> Signed-off-by: Michel Dänzer
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/dri
On 2025-07-30 13:08, Timur Kristóf wrote:
> On Wed, 2025-07-30 at 10:34 -0400, Harry Wentland wrote:
>>
>>
>> On 2025-07-30 04:19, Timur Kristóf wrote:
>>> On Tue, 2025-07-29 at 14:21 -0400, Harry Wentland wrote:
>>>>
>>>>
>>>
On 2025-07-30 13:03, Timur Kristóf wrote:
> On Wed, 2025-07-30 at 10:30 -0400, Harry Wentland wrote:
>>
>>
>> On 2025-07-30 03:40, Timur Kristóf wrote:
>>> On Tue, 2025-07-29 at 14:03 -0400, Harry Wentland wrote:
>>>>
>>>>
>>>&
to DC to prepare for
> supporting analog stream and link encoders, then analog link
> detection is added along with polling, and finally DAC load
> detection support, which is useful for old displays and adapters.
>
The series looks good to me.
Patches 2-20 are
Reviewed-by: Harry Wentland
P
On 2025-07-30 04:19, Timur Kristóf wrote:
> On Tue, 2025-07-29 at 14:21 -0400, Harry Wentland wrote:
>>
>>
>> On 2025-07-23 11:58, Timur Kristóf wrote:
>>> Features like stereo sync and audio are not supported by RGB
>>> signals, so don't try t
On 2025-07-30 03:40, Timur Kristóf wrote:
> On Tue, 2025-07-29 at 14:03 -0400, Harry Wentland wrote:
>>
>>
>> On 2025-07-23 11:57, Timur Kristóf wrote:
>>> Previously, DC determined the DRM connector type based on the
>>> signal type, which becomes probl
On 2025-07-23 11:58, Timur Kristóf wrote:
> Features like stereo sync and audio are not supported by RGB
> signals, so don't try to use them.
>
Where does it say that?
Harry
> Also add a dc_is_rgb_signal similar to other dc_is_*_signal.
>
> Signed-off-by: Timur Kristóf
> ---
> drivers/gpu
On 2025-07-23 11:57, Timur Kristóf wrote:
> We are going to support analog encoders as well, not just digital,
> so we need to make space for them in various arrays.
>
> Signed-off-by: Timur Kristóf
> ---
> .../drm/amd/display/dc/core/dc_link_enc_cfg.c | 4 ++--
> .../gpu/drm/amd/display/dc/
On 2025-07-23 11:57, Timur Kristóf wrote:
> Previously, DC determined the DRM connector type based on the
> signal type, which becomes problematic when a connector may
> support different signal types, such as DVI-I.
>
> With this patch, it is now determined according to the actual
> connector
On 2025-07-28 13:18, Alex Deucher wrote:
> On Sun, Jul 20, 2025 at 10:23 AM Yann Dirson wrote:
>>
>> Signed-off-by: Yann Dirson
>> ---
>>
>> Notes (patch):
>> test patch note
>>
>> Documentation/gpu/amdgpu/amdgpu-glossary.rst | 3 +++
>> Documentation/gpu/amdgpu/display/dc-glossary.rs
On 2025-07-02 23:39, jackysliu wrote:
> A null pointer dereference vulnerability exists in the AMD display driver's
> (DC module) cleanup function dc_destruct().
> When display control context (dc->ctx) construction fails
> (due to memory allocation failure), this pointer remains NULL.
> During
gt; [How]
> If the compositor hasn't enabled scaling but a non-native resolution has
> been picked for an LVDS panel turn the scaler on anyway. This will ensure
> compatibility.
>
> Signed-off-by: Alex Deucher
Series is
Reviewed-by: Harry Wentland
Harry
> ---
On 2025-06-27 10:33, Alex Deucher wrote:
> Add PCI IDs to support display probe for cyan skillfish
> family of SOCs.
>
> Signed-off-by: Alex Deucher
Acked-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 8 +++-
> drivers/gpu/dr
tlab.freedesktop.org/drm/amd/-/issues/4176
> Signed-off-by: Melissa Wen
Sorry, Melissa, for the late response. I though we dealt with
this patch already but it looks like we didn't.
Thanks for the fix and your detailed explanation.
Reviewed-by: Harry Wentland
Harry
> ---
>
&
On 2025-06-03 06:51, Pekka Paalanen wrote:
> On Tue, 3 Jun 2025 08:30:23 +
> "Shankar, Uma" wrote:
>
>>> -Original Message-
>>> From: Pekka Paalanen
>>> Sent: Friday, May 30, 2025 7:28 PM
>>> To: Shankar, Uma
>>&
On 2025-05-22 11:27, Pekka Paalanen wrote:
> On Thu, 22 May 2025 09:54:50 -0400
> Harry Wentland wrote:
>
>> On 2025-05-22 09:49, Simon Ser wrote:
>>> On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
>>> wrote:
>>>
>>>>>> Wh
On 2025-05-22 10:36, Aurabindo Pillai wrote:
> FAMS is the successor to SubVP starting with DCN4x. Reuse the same
> debug option to disable FAMS for debugging purposes.
>
> Signed-off-by: Aurabindo Pillai
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd
On 2025-05-22 09:49, Simon Ser wrote:
> On Thursday, May 22nd, 2025 at 15:28, Harry Wentland
> wrote:
>
>>>> What we should
>>>> do is reject YCbCr-type buffers with the color pipeline until we
>>>> implement support for COLOR_ENCOD
On 2025-05-22 03:57, Pekka Paalanen wrote:
> On Wed, 21 May 2025 15:48:00 -0400
> Harry Wentland wrote:
>
>> On 2025-05-17 07:51, Xaver Hugl wrote:
>>> Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
>>> :
>>>>
>>>>
&
On 2025-05-17 07:51, Xaver Hugl wrote:
> Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
> :
>>
>>
>>
>> On 5/15/25 15:39, Daniel Stone wrote:
>>> Hi,
>>>
>>> On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
>>>
On 2025-05-20 16:13, Harry Wentland wrote:
>
>
> On 2025-05-19 19:43, Simon Ser wrote:
>> On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
>>
>>>> We can always make the property mutable on drivers that support it in
>>>
>>>> the
On 2025-05-19 19:43, Simon Ser wrote:
> On Sunday, May 18th, 2025 at 00:32, Xaver Hugl wrote:
>
>>> We can always make the property mutable on drivers that support it in
>>
>>> the future, much like the zpos property. I think we should keep it
>>> immutable for now.
>>
>> Sure, but I don't see
param that
can be set to 8, 10, 12, 14, or 16 so users with
problematic configurations can force the output
bitdepth to a value that works for them.
Signed-off-by: Harry Wentland
Cc: Steven J Abner
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdg
On 2025-05-15 13:19, Daniel Stone wrote:
> Hi,
>
> On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
>> On 2025-05-15 05:45, Simon Ser wrote:
>>> I've reviewed all of the core DRM patches :)
>>>
>>> Have there been updates from user-space
Hi Steven,
thanks for the bisect.
In order to avoid display artifacts (especially for HDR) we had to
allow higher bit depth color output on the wire. The driver should
fallback to a lower resolution as needed but looks like there's a
bug with this particular TV. Are you able to share the specific
On 2025-05-15 05:45, Simon Ser wrote:
> I've reviewed all of the core DRM patches :)
>
> Have there been updates from user-space implementations?
I know Leandro has been working on Weston to make use of
this and last year Xaver had a prototype in kwin.
Ideally we'd have gamescope adopt it and
r pipeline now consists of a single colorop:
>>>> 1. 1D curve colorop w/ sRGB EOTF
>>>>
>>>> Signed-off-by: Alex Hung
>>>> Co-developed-by: Harry Wentland
>>>> Signed-off-by: Harry Wentland
>>>> Reviewed-by: Daniel Stone
>&g
x wrong handling for AUX_DEFER case")
> Cc: sta...@vger.kernel.org
> Cc: Mario Limonciello
> Cc: Alex Deucher
> Signed-off-by: Wayne Lin
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 +++---
> 1 file ch
-off-by: Aurabindo Pillai
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 ++-
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/d
[Why]
We check for a NULL divisor but don't act on it.
This check does nothing other than throw a warning.
It does confuse static checkers though:
See https://lkml.org/lkml/2025/4/26/371
[How]
Drop the ASSERTs in both DC and SPL variants.
Signed-off-by: Harry Wentland
Cc: Linus Torvald
On 2025-04-22 10:58, Melissa Wen wrote:
> This reverts commit 272e6aab14bbf98d7a06b2b1cd6308a02d4a10a1.
>
> Applying degamma curve to the cursor by default breaks Linux userspace
> expectation.
>
> On Linux, AMD display manager enables cursor degamma ROM just for
> implict sRGB on HW versions
On 2025-04-10 03:53, Pekka Paalanen wrote:
> On Tue, 8 Apr 2025 13:30:46 -0400
> Harry Wentland wrote:
>
>> On 2025-04-08 12:40, Daniel Stone wrote:
>>> Hi there,
>>>
>>> On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
>>>> On Tuesda
On 2025-04-15 02:40, Shankar, Uma wrote:
>
>
>> -Original Message-
>> From: Simon Ser
>> Sent: Tuesday, April 15, 2025 11:47 AM
>> To: Shankar, Uma
>> Cc: Alex Hung ; dri-de...@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org; intel-...@lists.freedesktop.org; wayland-
>> de.
On 2025-04-08 12:40, Daniel Stone wrote:
> Hi there,
>
> On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
>> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
>> wrote:
>>> 'plane' seems really incongruous here. The colorop can be created for
>>> any number of planes, but we're setting it to a
On 2025-04-01 15:53, Simon Ser wrote:
>
>
>
>
>
> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> wrote:
>
>>
>>
>> Hi Alex,
>>
>> On Wed, 26 Mar 2025 at 23:50, Alex Hung alex.h...@amd.com wrote:
>>
>>> +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
>>> *co
On 2025-04-01 11:45, Shengyu Qu wrote:
>
>
> 在 2025/4/1 22:11, Michel Dänzer 写道:
>> On 2025-04-01 14:32, Shengyu Qu wrote:
>>> 在 2025/4/1 17:56, Michel Dänzer 写道:
On 2025-03-31 19:42, Alex Hung wrote:
> On 3/31/25 11:04, Shengyu Qu wrote:
>> Or we can add some kind of "linked with
On 2025-04-01 11:45, Melissa Wen wrote:
> On 03/31, Xaver Hugl wrote:
>>> Cursor plane has no color pipeline and thus it has no colorop either. It
>>> inherits color processing from its parent plane.
>>
>> Just to be sure: That means amdgpu will reject atomic commits that try
>> to set a color p
On 2025-03-31 08:34, Christian König wrote:
> Am 26.03.25 um 08:00 schrieb James Flowers:
>> msleep < 20ms will often sleep for ~20ms (according to
>> Documentation/timers/timers-howto.rst).
>
> Our display team has to decide but I don't think that this patch is justified.
>
> The time given
On 2025-02-25 06:18, Louis Chauvet wrote:
> Le 20/12/2024 à 05:33, Alex Hung a écrit :
>> From: Harry Wentland
>>
(snip)
>> + { 0xfbfb, 0xfbfb, 0xfbfb, 0 },
>> + { 0xfcfc, 0xfcfc, 0xfcfc, 0 },
>> + { 0xfdfd, 0xfdfd, 0xfdfd, 0 },
&g
On 2025-02-25 06:19, Louis Chauvet wrote:
>
>
> Le 20/12/2024 à 05:33, Alex Hung a écrit :
>> From: Harry Wentland
>>
>> Two tests are added to VKMS LUT handling:
>> - linear
>> - inv_srgb
>>
>> Reviewed-by: Louis Chauvet
>> S
On 2025-03-07 09:48, Alex Deucher wrote:
> On Thu, Mar 6, 2025 at 10:45 PM Kenneth Feng wrote:
>>
>> Reset the workload type when using MALL.
>> When there is no activity on the screen, dal requestes dmcub
>> to use MALL. However, gfx ring is not empty at the same time.
>> Currrently the worklo
> This is an unexpected experience for the display to turn back on.
> Adjust the flow so that during the S4 sequence display hardware is
> not turned back on.
>
> Reported-by: Xaver Hugl
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2038
> Cc: Muhammad Usama Anju
On 2025-02-25 05:05, Louis Chauvet wrote:
Le 20/12/2024 à 05:33, Alex Hung a écrit :
From: Harry Wentland
@@ -249,6 +255,20 @@ void drm_atomic_state_default_clear(struct
drm_atomic_state *state)
state->planes[i].new_state = NULL;
}
+ for (i = 0; i <
On 2025-02-25 04:51, Louis Chauvet wrote:
>
>
> Le 20/12/2024 à 05:33, Alex Hung a écrit :
>> From: Harry Wentland
>>
>> Debugging LUT math is much easier when we can unit test
>> it. Add kunit functionality to VKMS and add tests for
>> - get_lut_
On 2025-02-25 09:05, Louis Chauvet wrote:
>
>
> Le 25/02/2025 à 12:28, Simon Ser a écrit :
>> On Tuesday, February 25th, 2025 at 10:37, Louis Chauvet
>> wrote:
>>
>>> Can I extract this patch from the series and apply it on drm-misc-next?
>>
>> That sounds completely fine by me, and TBH it soun
On 2025-02-21 14:25, Aurabindo Pillai wrote:
> Chaitanya is no longer with AMD, and the responsibility has been
> taken over by Austin.
>
> Signed-off-by: Aurabindo Pillai
Reviewed-by: Harry Wentland
Harry
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1
On 2025-02-21 12:26, Alex Deucher wrote:
> Chaitanya's email is no longer valid.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> in
On 2025-02-13 13:21, Leo Li wrote:
>
>
>
> 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
On 2025-02-21 11:42, Simon Ser wrote:
> On Friday, February 21st, 2025 at 17:18, Harry Wentland
> wrote:
>
>> I did a brief survey of other enum properties and noticed
>> that this isn't well documented for others, such as the Content
>> Protection connector
360 ("drm/amd/display: Add new DCN401 sources")
> Signed-off-by: Aurabindo Pillai
Reviewed-by: Harry Wentland
Harry
> ---
> .../amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git
t;
>> The 1D curve colorops support sRGB, BT2020, and PQ scaled to 125.0.
>>
>> Signed-off-by: Alex Hung
>> Signed-off-by: Harry Wentland
>> ---
>> v7:
>> - Initialize uint32_t blend_size = 0 by default (kernel test robot)
>> - Modify s
On 2025-02-15 09:40, Simon Ser wrote:
> On Monday, February 10th, 2025 at 23:03, Harry Wentland
> wrote:
>
>>>> + * DOC: overview
>>>> + *
>>>> + * A colorop represents a single color operation. Colorops are chained
>>>> + * via the N
On 2025-02-19 13:46, Rodrigo Siqueira wrote:
> Signed-off-by: Rodrigo Siqueira
Reviewed-by: Harry Wentland
Harry
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c8b35ca294a0..a94abf
On 2025-02-19 13:46, Rodrigo Siqueira wrote:
> Map all of my previously used email addresses to my @igalia.com address.
>
> Signed-off-by: Rodrigo Siqueira
Acked-by: Harry Wentland
Harry
> ---
> .mailmap | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/.ma
On 2025-01-13 03:18, Simon Ser wrote:
> This patch should probably come after all patches introducing the
> properties referenced in the docs, e.g. NEXT and COLOR_PIPELINE.
> Probably after "[13/45] drm/colorop: Introduce
> DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE"?
>
>> +/**
>> + * DOC: overview
>>
On 2025-01-27 14:59, André Almeida wrote:
> amdgpu can handle async flips on overlay planes, so allow it for atomic
> async checks.
>
> Signed-off-by: André Almeida
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 10 ++
On 2025-01-30 12:51, Nathan Chancellor wrote:
> Hey Greg and Harry,
>
[snip]
>> A more robust solution would be to do a greater-than check here
>> (for all the cases) and only set -Wframe-larger-than if the value
>> is greater than the one defined by CONFIG_FRAME_WARN. There are
>> a few "-gt
On 2025-01-30 02:04, Greg KH wrote:
On Thu, Jan 30, 2025 at 07:47:59AM +0100, Greg KH wrote:
On Mon, Jan 06, 2025 at 12:29:32PM -0500, Alex Deucher wrote:
Applied. Thanks!
Thanks, but I am still getting this error on Linus's current tree right
now, with this commit applied:
CC [M] drive
xes: 0159f88a99c9 ("drm/amd/display: remove redundant freesync parser for
> DP")
> Signed-off-by: Melissa Wen
Yeah, we need to check IGNORE_MSA_TIMING_PARAM before
allowing Freesync / adaptive sync.
Thanks for the fix.
Reviewed-by: Harry Wentland
Harry
> ---
>
>
>
On 2025-01-17 04:19, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:49 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> Add kernel doc for AMD color pipeline.
>>
>> Signed-off-by: Alex Hung
>> Signed-off-by: Harry Wentland
>>
On 2025-01-17 04:06, Pekka Paalanen wrote:
> On Thu, 16 Jan 2025 10:56:22 +0200
> Pekka Paalanen wrote:
>
>> On Thu, 19 Dec 2024 21:33:37 -0700
>> Alex Hung wrote:
>>
>>> From: Harry Wentland
>>>
>>> The BT.709 and BT.2020 OETFs are th
On 2025-01-15 03:04, Simon Ser wrote:
>> The BT.709 and BT.2020 OETFs are the same, the only difference
>> being that the BT.2020 variant is defined with more precision
>> for 10 and 12-bit per color encodings.
>
> Just to make sure, the spec defines this precision, correct? It's
> not an AMD-s
On 2025-01-17 04:04, Pekka Paalanen wrote:
> On Thu, 19 Dec 2024 21:33:35 -0700
> Alex Hung wrote:
>
>> From: Harry Wentland
>>
>> The PQ function defines a mapping of code values to nits (cd/m^2).
>> The max code value maps to 10,000 nits.
>>
>&
On 2025-01-15 03:00, Simon Ser wrote:
> Is this 125 magic number something we can expect other hardware to
> implement as well?
>
It's based on MS's CCCS interpretation of 80 nits as 1.0f [1]. Based on
this definition one needs to use 125.0f to represent 10,000 nits,
the maximum value PQ can r
On 2025-01-15 02:56, Simon Ser wrote:
> Is this "ignore" something we could do at the core DRM level, instead
> of doing it in all drivers? e.g. by silently ignoring user-space requests
> to set the property?
>
I think it'd be better to reject setting the property. The problem
is that a client
On 2025-01-13 13:23, Simon Ser wrote:
>> v4:
>> - Don't block setting of COLOR_RANGE and COLOR_ENCODING
>>when client cap is set
>
> Can you remind me why these should not be blocked?
>
I initially blocked setting these when the client cap was set
but that caused some IGT tests to blow u
On 2025-01-21 08:57, Mario Limonciello wrote:
> From: Mario Limonciello
>
> The number of active surfaces is initialized to the number
> of active planes. If the number of planes aren't initialized
> properly then the last plane can end up not getting initialized
> which can be a divide by ze
function isn't called again.
>
> Also add a message the first time that they have passed to let
> the user know the stream will be used for seamless boot.
>
> Signed-off-by: Mario Limonciello
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> .../
On 2025-01-17 14:18, Alex Deucher wrote:
> This needs to be kerneldoc formatted.
>
> Fixes: 5349658fa4a1 ("drm/amd: Add debug option to disable subvp")
> Reported-by: Stephen Rothwell
> Signed-off-by: Alex Deucher
> Cc: Aurabindo Pillai
Reviewed-by: Harry Wentla
On 2025-01-14 14:37, Alex Deucher wrote:
> This needs to be kerneldoc formatted.
>
> Fixes: 7594874227e1 ("drm/amd/display: add CEC notifier to amdgpu driver")
> Reported-by: Stephen Rothwell
> Signed-off-by: Alex Deucher
> Cc: Kun Liu
Reviewed-by: Harry Wentla
On 2025-01-11 02:03, Tiezhu Yang wrote:
> On 01/11/2025 05:45 AM, Harry Wentland wrote:
>> On 2025-01-06 03:57, Tiezhu Yang wrote:
>>> As far as I can tell, with the current existing macro definitions, there
>>> is no better way to do the minimal and proper changes t
On 2025-01-06 03:57, Tiezhu Yang wrote:
> As far as I can tell, with the current existing macro definitions, there
> is no better way to do the minimal and proper changes to stop the control
> flow if the divisior is zero.
>
> In order to keep the current ability for the aim of debugging and avoid
Series is
Reviewed-by: Harry Wentland
Harry
On 2025-01-06 15:33, Alex Deucher wrote:
> At the momemt we only expose the i2c buses used by the driver
> for displays or EEPROMs. However, some OEMs/AIBs use extra i2c
> buses for things like RGB controls. Expose the extra i2c buses in
&
aciously ping regarding this series. Should it
>>> be merged as is (possibly requiring more R-B's)? Or should I rework it
>>> adding something like .mode_valid_new() callback which takes const
>>> argument?
>>
>> I think your patch is fine, and you can add my
>>
>> Reviewed-by: Maxime Ripard
>>
>> We seem to lack an Acked-by for amdgpu though?
>
> Yes. I think the AMD is the only one missing
>
>
For the amdgpu patch:
Reviewed-by: Harry Wentland
Harry
On 2024-12-30 03:15, Kun Liu wrote:
> This patch adds the cec_notifier feature to amdgpu driver.
> The changes will allow amdgpu driver code to notify EDID
> and HPD changes to an eventual CEC adapter.
>
> Signed-off-by: Kun Liu
> ---
> drivers/gpu/drm/amd/display/Kconfig | 2 +
>
On 2024-10-04 07:43, Louis Chauvet wrote:
> On 03/10/24 - 16:01, Harry Wentland wrote:
>> Certain operations require us to preserve values below 0.0 and
>> above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
>> such operation is a BT709 encoding operation follow
On 2024-12-16 10:31, Alex Deucher wrote:
> On Mon, Dec 16, 2024 at 10:12 AM Dmitry Baryshkov
> wrote:
>>
>> On Mon, 16 Dec 2024 at 16:53, Harry Wentland wrote:
>>>
>>>
>>>
>>> On 2024-12-10 16:20, Dmitry Baryshkov wrote:
>>>>
On 2024-12-16 06:34, Thomas Weißschuh wrote:
> The sysfs core now allows instances of 'struct bin_attribute' to be
> moved into read-only memory. Make use of that to protect them against
> accidental or malicious modifications.
>
> Signed-off-by: Thomas Weißschuh
Re
t;eld);
>> memcpy(buf, connector->eld, min(max_bytes, ret));
>> +mutex_unlock(&connector->eld_mutex);
All of this is wrapped by the adev->dm.audio_lock mutex. It might
be safer to modify the audio_lock mutex so it only guards the
aconnector->audio_inst access.
But I don't see any way these mutexes would otherwise interact,
so this change should be good as-is.
Reviewed-by: Harry Wentland
Harry
>>
>> break;
>> }
>>
>> --
>> 2.39.5
>>
>
Looks good now.
Series is
Reviewed-by: Harry Wentland
Haven't followed the whole panic support closely. Is there a
way to trigger a panic for testing, or is there any other
recommended way to test this?
Harry
On 2024-12-09 12:00, Alex Deucher wrote:
> + Harry
>
> Ping on this s
On 2024-12-09 10:44, Aurabindo Pillai wrote:
> From: Leo Li
>
> They were named with the incorrect dcn version.
>
> Signed-off-by: Aurabindo Pillai
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/clk_mgr/dcn201/dcn201_clk_mgr.c| 4 ++--
>
avoid tripping such
> problems.
>
> Suggested-by: Tobias Jakobi
> Reported-and-tested-by: Chris Bainbridge
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3782
> Fixes: c6a837088bed ("drm/amd/display: Fetch the EDID from _DDC if available
> for eDP")
>
; Fixes: 38077562e059 ("drm/amd/display: Implement new backlight_level_params
> structure")
> Signed-off-by: Mario Limonciello
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
.com
> Cc: hamishclax...@gmail.com
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> b/drivers/
On 2024-11-01 14:23, André Almeida wrote:
> amdgpu can handle async flips on overlay planes, so allow it for atomic
> async checks.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff
On 2024-11-05 09:06, Alex Deucher wrote:
> From: Jocelyn Falempe
>
> Add support for the drm_panic module, which displays a pretty user
> friendly message on the screen when a Linux kernel panic occurs.
>
> It doesn't work yet on laptop panels, maybe due to PSR.
>
> Adapted from Jocelyn's or
is organized.
>
> Cc: Leo Li
> Cc: Aurabindo Pillai
> Cc: Hamza Mahfooz
> Cc: Harry Wentland
> Cc: Mario Limonciello
> Cc: Christian Konig
> Cc: Alex Deucher
> Signed-off-by: Rodrigo Siqueira
Series is
Reviewed-by: Harry Wentland
Harry
> ---
> .../gp
issues around panel power are not specific to the low pwm values,
> so shouldn't have an impact on this series.
> (And are nearly imperceptible anyways)
>
I think these patches are good.
Reviewed-by: Harry Wentland
Harry
>> One solution would be a fixed firmware version, w
y default. It can
> still be enabled by setting sg_display=1 for those that
> want to play with it. These systems also generally had large
> carve outs so SG display was less of a factor.
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3356
> Signed-off-by: Alex Deucher
On 2024-08-27 13:49, Louis Chauvet wrote:
> Le 19/08/24 - 16:56, Harry Wentland a écrit :
>> This is an RFC set for a color pipeline API, along with implementations
>> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
>> found at [1]. The IGT tests
A short description about the AMD color pipeline.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
1 file changed, 102 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm
From: Alex Hung
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
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.
From: Alex Hung
This adds support for a multiplier. This multiplier is
programmed via the HDR Multiplier in DCN.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-multiply_125
kms_colorop --run plane-XR30-XR30-multiply_inv_125
The color pipeline now consists of th
From: Alex Hung
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
1. new drm_colorop_type: DRM_COLOROP_3D_LUT.
2. 3D LUT modes define hardware capabilities to userspace applications.
3. mode index points to current 3D LUT mode in lut_3d_modes.
From: Alex Hung
Swap the order of matrix and multiplier as designed in hardware.
Signed-off-by: Alex Hung
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 22 ++---
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 32 +--
2 files changed, 27 insertions(+), 27 deletion
Not all HW will be able to do bypass on all color
operations. Introduce an 'allow_bypass' boolean for
all colorop init functions and only create the BYPASS
property when it's true.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 22 +---
We want to make sure userspace is aware of the 1D LUT
interpolation. While linear interpolation is common it
might not be supported on all HW. Give driver implementers
a way to specify their interpolation.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 6
From: Alex Hung
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.
Signed-off-by: Alex Hung
---
drivers/gpu/drm/drm_atomic.c | 3 +++
driver
1 - 100 of 1141 matches
Mail list logo
