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
2fixp test that validates the above assumption.
I am also adding a test for the new sm2fixp function that converts
from a signed-magnitude fixed point to the twos-complement fixed
point.
Signed-off-by: Harry Wentland
---
v6:
- add missing MODULE_DESCRIPTION (Jeff Johnson)
- fix buffer ove
s are in signed-magnitude fixed
point, whereas the drm_fixed.h implementation uses 2s-complement.
The latter one is the one that we want for easy addition and
subtraction, so we convert all entries to 2s-complement.
Signed-off-by: Harry Wentland
---
v6:
- pre-compute colors (Louis Chauvet)
-
TA property for property types that
need it.
Signed-off-by: Harry Wentland
---
v6:
- take ref for DATA blob in duplicate_state func (Xaver Hugl)
v5:
- Add function signature for init (Sebastian)
- Fix kernel-doc
v4:
- Create helper function for creating 3x4 CTM colorop
- Fix CTM indexes in
We want to be able to bypass each colorop at all times.
Introduce a new BYPASS boolean property for this.
Signed-off-by: Harry Wentland
---
v6:
- clarify that bypass is only valid if BYPASS prop exists (Louis Chauvet)
drivers/gpu/drm/drm_atomic_uapi.c | 6 +-
drivers/gpu/drm
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 44c5b5dd8b33..0f4eba51ee4b 100644
--- a/drivers/gpu/drm/drm_atomic.c
Signed-off-by: Harry Wentland
---
v5:
- Drop unused header definitions
v3:
- Read NEXT ID from drm_colorop's next pointer
drivers/gpu/drm/drm_atomic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 12e787e
ll as set the desired one. The color
pipelines are programmed via properties on the actual
drm_colorop objects.
Signed-off-by: Harry Wentland
---
v4:
- Add pipeline property creation helper (Pekka)
- Fix function comment for
drm_atomic_set_colorop_for_plane (Pekka)
- Always create Bypass pip
these properties when
programming the HW.
Setting of the COLOR_PIPELINE plane property or drm_colorop
properties is only allowed for userspace that sets this
client cap.
Signed-off-by: Harry Wentland
---
v5:
- Fix kernel docs
v4:
- Don't block setting of COLOR_RANGE and COLOR_ENCODI
CTM values are defined as signed-magnitude values. Add
a helper that converts from CTM signed-magnitude fixed
point value to the twos-complement value used by
drm_fixed.
Signed-off-by: Harry Wentland
---
include/drm/drm_fixed.h | 18 ++
1 file changed, 18 insertions(+)
diff
We'll construct color pipelines out of drm_colorop by
chaining them via the NEXT pointer. NEXT will point to
the next drm_colorop in the pipeline, or by 0 if we're
at the end of the pipeline.
Signed-off-by: Harry Wentland
---
v5:
- move next comment here from Add 3x4 CTM patch
some issues with applying LUTs in VKMS
Cc: Ville Syrjala
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Harry Wentland
Cc: Melissa Wen
Cc: Jonas Ådahl
Cc: Sebastian Wick
Cc: Shashank Sharma
Cc: Alexander Goins
Cc: Joshua Ashton
Cc: Michel Dänzer
Cc: Aleix Pol
Cc: Xaver Hugl
Cc: Victoria Brekenfel
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Co-developed-by: Alex Hung
---
v5:
- Add drm_get_colorop_curve_1d_type_name in header
- Add drm_colorop_init
- Set default curve
- Add kernel docs
v4:
- Use drm_colorop_curve_1d_type_enum_list to get name (Pekka)
- Create separate
This patches introduces a new drm_colorop mode object. This
object represents color transformations and can be used to
define color pipelines.
We also introduce the drm_colorop_state here, as well as
various helpers and state tracking bits.
Signed-off-by: Harry Wentland
---
v6:
- Comment that
Signed-off-by: Harry Wentland
---
v5:
- Don't require BYPASS to succeed (Sebastian)
- use DATA for 1D and 3D LUT types (Sebastian)
- update 3DLUT ops to use 3DLUT_MODES and 3DLUT_MODE_INDEX
- Add section on drm_colorop extensibility
- Add color_pipeline.rst to RFC toc tree
v4:
-
Signed-off-by: Harry Wentland
---
v5:
- Drop TODO
Documentation/gpu/drm-kms.rst | 15 +++
drivers/gpu/drm/drm_colorop.c | 31 +++
2 files changed, 46 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index
fixp2int always rounds down, fixp2int_ceil rounds up. We need
the new fixp2int_round.
Signed-off-by: Harry Wentland
Reviewed-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
For now we're only introducing an enumerated 1D LUT type to
illustrate the concept.
Signed-off-by: Harry Wentland
---
v6:
- fix doc typo (Alex Hung)
v5:
On 2024-09-10 16:37, Alex Goins wrote:
> Hi Harry,
>
> Thanks for this. I just want to remind about a few things that would be
> required
> for NVIDIA hardware, as discussed at the Display Next Hackfest -- fully
> understand that they aren't currently included in this series because they
> aren't
2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Harry Wentland
Harry
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 5c39390ecbd5..417fe508c57f 100644
> --- a/drivers/gpu/drm/amd/display/dc/
1 - 100 of 1107 matches
Mail list logo
