On 2025-09-01 08:25, José Expósito wrote:
Allow to store the connector status in vkms_config_connector and add a
getter and a setter functions as well a KUnit test.
This change only adds the configuration, the connector status is not
used yet.
Tested-by: Mark Yacoub
Reviewed-by: Louis Chauv
On 2025-09-30 03:07, Pekka Paalanen wrote:
On Thu, 14 Aug 2025 21:50:06 -0600
Alex Hung wrote:
From: Harry Wentland
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
ments about function docs fixed these patches are
Reviewed-by: Harry Wentland
I went through them manually and also asked both GPT 4.1 and Claude
Sonnet 4 to review them for correctness against the configfs.rst docs.
Harry
Best wishes,
José Expósito
[1] https://github.com/JoseExposit
On 2025-09-25 04:11, Pekka Paalanen wrote:
On Tue, 23 Sep 2025 11:41:24 -0600
Alex Hung wrote:
On 9/23/25 10:16, Alex Hung wrote:
On 9/23/25 01:59, Pekka Paalanen wrote:
On Mon, 22 Sep 2025 21:16:45 -0600
Alex Hung wrote:
On 9/18/25 02:40, Pekka Paalanen wrote:
...
The problem
On 2025-09-17 15:49, Melissa Wen wrote:
>
>
> On 12/09/2025 15:50, Harry Wentland wrote:
>>
>> On 2025-09-11 13:21, Melissa Wen wrote:
>>> Don't update DC stream color components during atomic check. The driver
>>> will continue validating the
drm/amd/-/issues/
> Reported-by: Xaver Hugl
> Reviewed-by: Harry Wentland #v2
> Signed-off-by: Melissa Wen
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c
On 2025-06-18 11:19, Melissa Wen wrote:
> From: Rodrigo Siqueira
>
> Since DC is a shared code, this commit introduces a new file to work as
> a mid-layer in DC for the edid manipulation.
>
> Signed-off-by: Rodrigo Siqueira
> Co-developed-by: Melissa Wen
> Signed-off-by: Melissa Wen
>
> -
On 2025-06-18 11:19, Melissa Wen wrote:
> From: Rodrigo Siqueira
>
> As part of the effort of stopping using raw edid, this commit move the
> copy of the edid in DC to a dedicated function that will allow the usage
> of drm_edid in the next steps.
>
> Signed-off-by: Rodrigo Siqueira
> Co-dev
On 2025-06-18 11:19, Melissa Wen wrote:
> Add Linux opaque object to dc_sink for storing EDID data cross driver,
> drm_edid. Also include the Linux call to free this object, the
> drm_edid_free()
>
> Signed-off-by: Melissa Wen
>
> ---
>
> v3:
> - remove uneccessary include (jani)
>
> v5:
>
c)
This function is almost a duplicate of amdgpu_dm_update_crtc_color_mgmt,
without the part that sets the stream->out_transfer_func and without
the "Setup CRTC CTM" bits. I wonder whether it would make sense to
combine them in a way where the "update" function would look like:
int amdg
On 2025-08-11 17:47, Melissa Wen wrote:
>
>
> On 11/08/2025 18:26, Harry Wentland wrote:
>>
>> On 2025-08-11 17:09, Limonciello, Mario wrote:
>>> On 8/11/25 4:08 PM, Hung, Alex wrote:
>>>> Melissa,
>>>>
>>>> The patchset passe
On 2025-07-25 20:33, Melissa Wen wrote:
> Reduce direct handling of edid data by resorting to drm helpers that
> deal with this info inside drm_edid infrastructure.
>
> v3:
> - use dc_edid_sink_edid_free in link_detection
>
> v5:
> - no need of drm_edid duplication (Mario)
> - fix mem leak on
On 2025-07-25 20:33, Melissa Wen wrote:
> Add Linux opaque object to dc_sink for storing EDID data cross driver,
> drm_edid. Also include the Linux call to free this object, the
> drm_edid_free()
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 6 ++
On 2025-08-11 17:09, Limonciello, Mario wrote:
> On 8/11/25 4:08 PM, Hung, Alex wrote:
>> Melissa,
>>
>> The patchset passed promotion and CI.
>>
>> However, since our DC code is shared with the other OS, calling drm_*
>> functions in DC won't work for us. For example, calling
>> dc_edid_copy_
On 2025-08-04 04:20, Michel Dänzer wrote:
> On 31.07.25 22:51, Harry Wentland wrote:
>> Thanks for the series. It makes sense to me.
> I'm glad to hear it, thanks for taking a look.
>
> May I take this as R-b?
Yes, please do. :)
Harry
>
>
>>> di
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
On 2025-07-30 09:55, Murthy, Arun R wrote:
> On 30-07-2025 18:44, Harry Wentland wrote:
>>
>> On 2025-07-30 06:16, Arun R Murthy wrote:
>>> Add user readable error codes for failure cases in drm_atomic_ioctl() so
>>> that user can decode the error code
On 2025-07-30 06:16, Arun R Murthy wrote:
> Add user readable error codes for failure cases in drm_atomic_ioctl() so
> that user can decode the error code and take corrective measurements.
>
Thanks for doing this work.
> @@ -1541,6 +1548,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
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
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-13 02:15, Suraj Kandpal wrote:
> This series is for review comments only and is not tested.
> This series added a helper to be able to initialise writeback connector
> in a way where drivers can send their own connector and encoder.
>
I've only skimmed it but this looks nice. If I unde
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 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
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
y
>> async flips
>>
>> + Harry and Leo
I didn't go through the set thoroughly but had a look at
patches 1 and 2. It looks like it's simply a copy of
IN_FORMATS for async flips, which makes sense to me.
Patches 1 and 2 are
Acked-by: Harry Wentland
Harry
>>
>
ents").
>
> Cc: Lee Jones
> Cc: Lennart Poettering
> Cc: richard.pur...@linuxfoundation.org
> Link: https://github.com/systemd/systemd/pull/36881
> Signed-off-by: Mario Limonciello
> ---
> v2:
> * Add more explanation
Reviewed-by: Harry Wentland
Harry
> ---
>
[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-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-devel@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org; intel-...@lists.freedesktop.org; wayland-
>> de.
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-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-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-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-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-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 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 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-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-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
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-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-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: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-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
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-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
>>
>
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
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
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
Signed-off-by: Alex Hung
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 22ff9a31b592..1bfb
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.
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 +---
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
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
consists of a single colorop:
1. 1D curve colorop w/ sRGB EOTF
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
---
v6:
- cleanup if colorop alloc or init fails
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 3 +-
.../amd/display/amdgpu_dm/amdgpu_dm_color.c
plane-XR30-XR30-ctm_3x4_bt709_enc
kms_colorop --run plane-XR30-XR30-ctm_3x4_bt709_dec
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. 3x4 CTM
3. 1D curve colorop
4. 1D LUT
5. 1D curve colorop
6. 1D LUT
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
SIZE property which
is used by a driver to advertise the supported SIZE
of the LUT, as well as a DATA property which userspace
uses to set the LUT.
DATA and size function in the same way as current drm_crtc
GAMMA and DEGAMMA LUTs.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-develop
-pq_125_inv_eotf
kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf
kms_colorop --run plane-XR30-XR30-pq_125_eotf-pq_125_inv_eotf-pq_125_eotf
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 20 +--
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c
of as EOTF (electro-optical transfer function).
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_colorop.c | 2 ++
include/drm/drm_colorop.h | 19 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index
the following colorops:
1. 1D curve colorop
2. 1D curve colorop
3. 1D LUT
4. 1D curve colorop
5. 1D LUT
The 1D curve colorops support sRGB, BT2020, and PQ scaled to 125.0.
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 168
When the plane_color_pipeline bit is set we should ignore
deprecated properties, such as COLOR_RANGE and COLOR_ENCODING.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display
-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 11 ---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 10 +++---
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers
we need it. We'll revisit and, if necessary, regenerate
the LUTs when we have IGT tests for higher precision buffers.
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
---
v6:
- drop 'len' var (Louis Chauvet)
- cleanup if colorop alloc or init fails (Louis C
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_test.c | 38 +++-
drivers/gpu/drm/vkms/vkms_composer.c | 15 ++--
drivers/gpu/drm/vkms/vkms_composer.h | 13 +++
3 files changed, 53 insertions(+), 13 deletions(-)
diff --git a
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf
The color pipeline now consists of the following colorops:
1. 1D curve colorop w/ sRGB EOTF support
2. 1D curve colorop w/ sRGB Inverse EOTF support
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
a PQ
function that is scaled by 125, yielding 80 nit PQ values for
1.0 and 10,000 nits at 125.0.
This patch introduces this scaled PQ EOTF and its inverse as
1D curve types.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_colorop.c | 2 ++
include/drm/drm_colorop.h
-srgb_eotf
The color pipeline now consists of the following colorops:
1. 1D curve colorop w/ sRGB EOTF support
2. 1D curve colorop w/ sRGB Inverse EOTF support
3. 1D curve colorop w/ sRGB EOTF support
Signed-off-by: Alex Hung
Signed-off-by: Harry Wentland
Co-developed-by: Harry Wentland
e'll also invert the nesting of our
colorop processing loops. We now use the pixel iteration loop
on the outside and the colorop iteration on the inside.
Signed-off-by: Harry Wentland
---
v6:
- use clamp_val instead of manual clamping (Louis Chauvet)
v4:
- Clarify that we're pack
A whole slew of tests for CTM handling that greatly helped in
debugging the CTM code. The extent of tests might seem a bit
silly but they're fast and might someday help save someone
else's day when debugging this.
Signed-off-by: Harry Wentland
---
v6:
- update reference values since
From: Alex Hung
Create a new macro for_each_new_colorop_in_state to access new
drm_colorop_state updated from uapi.
Signed-off-by: Alex Hung
---
include/drm/drm_atomic.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.
Add the default Bypass pipeline and ensure it passes the
kms_colorop test plane-XR30-XR30-bypass.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm
Drivers will need to know whether an atomic check/commit
originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
so they can ignore deprecated properties, like COLOR_ENCODING
and COLOR_RANGE.
Pass the plane_color_pipeline bit to drm_atomic_state.
Signed-off-by: Harry Wentland
---
v5
Debugging LUT math is much easier when we can unit test
it. Add kunit functionality to VKMS and add tests for
- get_lut_index
- lerp_u16
Signed-off-by: Harry Wentland
Cc: Arthur Grillo
---
v6:
- Eliminate need to include test as .c file (Louis Chauvet)
v5:
- Bring back static for lerp_u16
1 - 100 of 1126 matches
Mail list logo
