return 0;
+ return 0;
- ret = PTR_ERR(lcd);
unregister_framebuffer(info);
out_fb_dealloc_cmap:
Something is not right here. With the current patch you'll make the
unregister_framebuffer(info)
unreachable, because there is a return 0 in front.
Please check again.
See
On Thu, Oct 3, 2024 at 9:18 PM Wu Hoi Pok wrote:
>
> The patch is to solve null dereference in 'aux.dev', which is
> introduced in recent radeon rework. By having 'late_register',
> the connector should be registered after 'drm_dev_register'
> auto
I don't think there's an immediate use for this in drm-misc, so its
easier to merge through xe. :-)
Acked-by: Maarten Lankhorst
Den 2024-10-03 kl. 02:46, skrev john.c.harri...@intel.com:
From: Michal Wajdeczko
This drm printer wrapper can be used to increase the robustness of
the captured ou
Hi Adrian,
On 03/10/2024 00:45, Adrián Larumbe wrote:
Some drivers must allocate a considerable amount of memory for bookkeeping
structures and GPU's MCU-kernel shared communication regions. These are
often created as a result of the invocation of the driver's ioctl()
interface functions, so i
Add job that executes the IGT test suite for sm8350-hdk.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/arm64.config | 7 +-
drivers/gpu/drm/ci/build.sh | 1 +
drivers/gpu/drm/ci/test.yml | 16 ++
.../drm/ci/xfails/msm-sm8350-hdk-fails.
Add job that executes the IGT test suite for acer-cb317-1h-c3z6-dedede.
dedede boards use 64 bit Intel Jasper Lake processors.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/test.yml | 9
drivers/gpu/drm/ci/xfails/i915-jsl-fails.txt | 51 +++
drivers
Move common job configuration for software-driver
stage jobs to seperate job.
Signed-off-by: Vignesh Raman
---
drivers/gpu/drm/ci/test.yml | 59 +++--
1 file changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/
Add jobs that execute the IGT test suite for sm8350-hdk and dedede.
Also refactor software-driver stage jobs.
Successful pipeline link,
https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1283825
Once this patch series is reviewed, will send v2 with gitlab issues
link for flake tests
From: "Wachowski, Karol"
Apply Hardware Architecture Specification compatible delays
for main island power delivery for 50xx and above.
Signed-off-by: Wachowski, Karol
Signed-off-by: Maciej Falkowski
---
drivers/accel/ivpu/ivpu_hw_40xx_reg.h | 2 ++
drivers/accel/ivpu/ivpu_hw_ip.c | 49
Add support for the 5th generation of Intel NPU that
is going to be present in PTL_P (Panther Lake) CPUs.
NPU5 code reuses almost all of previous driver code.
Signed-off-by: Maciej Falkowski
---
drivers/accel/ivpu/ivpu_drv.c | 1 +
drivers/accel/ivpu/ivpu_drv.h | 10 +++---
drivers/accel/iv
This patchset adds initial support for 5th generation Intel NPU
that is going to be present in the upcoming Panther Lake CPUs.
Maciej Falkowski (1):
accel/ivpu: Add initial Panther Lake support
Wachowski, Karol (1):
accel/ivpu: Update power island delays
drivers/accel/ivpu/ivpu_drv.c
When running `kmscube` with one or more performance monitors enabled
via `GALLIUM_HUD`, the following kernel panic can occur:
[ 55.008324] Unable to handle kernel paging request at virtual address
052004a4
[ 55.008368] Mem abort info:
[ 55.008377] ESR = 0x9605
[ 55.0
Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4->active_perfmon`) is still
retained.
If we open a new file descriptor and submit a few jobs with perfor
Similar to commit f2a4bcb25328 ("drm/v3d: Use v3d_perfmon_find()"),
replace the open-coded `vc4_perfmon_find()` with the real thing.
Cc: Christian Gmeiner
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/dr
, Tony:
Thanks for the bug report. Can you provide the output of 'sudo lspci
-vvv' for the graphics device?
Thomas,
Sure. Here's the output (run on the v6.11.0 kernel)
Thanks. It doesn't look much different from other systems. IRQ is also
assigned.
Attached is a patch that fix
> static void apply_lut(const struct vkms_crtc_state *crtc_state, struct
> line_buffer *output_buffer)
> {
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.h
> b/drivers/gpu/drm/vkms/vkms_composer.h
> index 9316a053e7d7..67ae09913460 100644
> --- a/drivers/gpu/drm/v
On 03/10/24 - 16:00, Harry Wentland wrote:
> 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 .
On 03/10/24 - 16:01, Harry Wentland wrote:
> We add two 3x4 matrices into the VKMS color pipeline. The reason
> we're adding matrices is so that we can test that application
> of a matrix and its inverse yields an output equal to the input
> image.
>
> One complication with the matrix implementati
Few checkpatch warnings:
- line length of 103 exceeds 100 columns
- Blank lines aren't necessary before a close brace '}'
- adding a line without newline at end of file
With those fixed:
Reviewd-by: Louis Chauvet
On 03/10/24 - 16:01, Harry Wentland wrote:
> While working on the CTM implementatio
On 03/10/24 - 16:00, Harry Wentland wrote:
> This patch introduces a VKMS color pipeline that includes two
> drm_colorops for named transfer functions. For now the only ones
> supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
> We will expand this in the future but I don
On 03/10/24 - 16:01, Harry Wentland wrote:
> 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
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 followed by its
> decoding operation, or the reverse.
>
> We'll use s32 values a
On 03/10/24 - 16:01, Harry Wentland wrote:
> 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
Hi,
On Thu, Oct 03, 2024 at 02:18:48PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Allow imx/dcss to be built with COMPILE_TEST=y for greater
> coverage. Builds fine on x86/x86_64 at least.
>
> Cc: Laurentiu Palcu
> Cc: Lucas Stach
> Signed-off-by: Ville Syrjälä a
Reviewed-by: Laur
Hi,
On Thu, Oct 03, 2024 at 02:18:47PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the appropriate 64bit division helpers to make the code
> build on 32bit architectures.
>
> Cc: Laurentiu Palcu
> Cc: Lucas Stach
> Signed-off-by: Ville Syrjälä
Reviewed-by: Laurentiu Palcu
Th
On 10/3/2024 3:56 PM, Advait Dhamorikar wrote:
> Fix shift-count-overflow in JPEG instance
> multiplication. The expression's value may not be
> what the programmer intended, because the expression
> is evaluated using a narrower integer type.
>
> Fixes: f0b19b84d391 ("drm/amdgpu: add amdgpu_jp
0.24 um 18:15 schrieb Luck, Tony:
> >>>> Thanks for the bug report. Can you provide the output of 'sudo lspci
> >>>> -vvv' for the graphics device?
> >>> Thomas,
> >>>
> >>> Sure. Here's the output (run on the v6.11.0 k
e?
Thomas,
Sure. Here's the output (run on the v6.11.0 kernel)
Thanks. It doesn't look much different from other systems. IRQ is also
assigned.
Attached is a patch that fixes a possible off-by-one error in the
register settings. This would affect the bug you're reporting. If
possibl
On Fri, 2024-10-04 at 12:16 +0200, Peter Zijlstra wrote:
> On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellström wrote:
> > When using mutex_acquire_nest() with a nest_lock, lockdep refcounts
> > the
> > number of acquired lockdep_maps of mutexes of the same class, and
> > also
> > keeps a poi
This series adds support for the DisplayPort controller
and eDP PHY v5 found on the Qualcomm SA8775P platform.
---
v2: Fixed review comments from Dmitry and Bjorn
- Made aux_cfg array as const.
- Reused edp_swing_hbr_rbr and edp_swing_hbr2_hbr3 for v5.
v3: Fixed review comments fr
Add support for eDP PHY v5 found on the Qualcomm SA8775P platform.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Soutrik Mukhopadhyay
---
v2: Fixed review comments from Dmitry
- Reused edp_swing_hbr_rbr and edp_swing_hbr2_hbr3 for v5.
v3: No change
v4: No change
---
drivers/phy/qualco
In order to support different HW versions, introduce aux_cfg array
to move v4 specific aux configuration settings.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Soutrik Mukhopadhyay
---
v2: Fixed review comments from Bjorn and Dmitry
- Made aux_cfg array as const.
v3: Fixed review commen
Add compatible string for the supported eDP PHY on sa8775p platform.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Soutrik Mukhopadhyay
---
v2: No change
v3: No change
v4: No change
---
Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/
The Qualcomm SA8775P platform comes with 2 DisplayPort controllers
for each mdss, having different base offsets than the previous
SoCs. The support for all 4 DPTX have been added here, and
validation of only MDSS0 DPTX0 and DPTX1 have been conducted.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: S
Add compatible string for the DisplayPort controller found on the
Qualcomm SA8775P platform.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Soutrik Mukhopadhyay
---
v2: No change
v3: No change
v4: No change
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
1 file chang
Il 04/10/24 08:03, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-10-01 at 13:33 +0200, AngeloGioacchino Del Regno wrote:
Il 01/10/24 12:07, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-09-10 at 10:51 +, AngeloGioacchino Del Regno wrote:
It is impossible to add each and every possi
On Wed, Oct 02, 2024 at 02:56:11PM +0200, Thomas Hellström wrote:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
> number of acquired lockdep_maps of mutexes of the same class, and also
> keeps a pointer to the first acquired lockdep_map of a class. That pointer
> is then
> Sure. Here's the output (run on the v6.11.0 kernel)
>
> Thanks. It doesn't look much different from other systems. IRQ is also
> assigned.
>
> Attached is a patch that fixes a possible off-by-one error in the
> register settings. This would affect the bug you
Reviewed-by: Jacek Lawrynowicz
On 10/4/2024 11:41 AM, Sakari Ailus wrote:
> pm_runtime_put_autosuspend() will soon be changed to include a call to
> pm_runtime_mark_last_busy(). This patch switches the current users to
> __pm_runtime_put_autosuspend() which will continue to
pm_runtime_put_autosuspend() will soon be changed to include a call to
pm_runtime_mark_last_busy(). This patch switches the current users to
__pm_runtime_put_autosuspend() which will continue to have the
functionality of old pm_runtime_put_autosuspend().
Signed-off-by: Sakari Ailus
---
drivers
pm_runtime_put_autosuspend() will soon be changed to include a call to
pm_runtime_mark_last_busy(). This patch switches the current users to
__pm_runtime_put_autosuspend() which will continue to have the
functionality of old pm_runtime_put_autosuspend().
Signed-off-by: Sakari Ailus
---
drivers
pm_runtime_put_autosuspend() will soon be changed to include a call to
pm_runtime_mark_last_busy(). This patch switches the current users to
__pm_runtime_put_autosuspend() which will continue to have the
functionality of old pm_runtime_put_autosuspend().
Signed-off-by: Sakari Ailus
---
drivers
Hello everyone,
This set will switch the users of pm_runtime_put_autosuspend() to
__pm_runtime_put_autosuspend() while the former will soon be re-purposed
to include a call to pm_runtime_mark_last_busy(). The two are almost
always used together, apart from bugs which are likely common. Going
forwa
pm_runtime_put_autosuspend() will soon be changed to include a call to
pm_runtime_mark_last_busy(). This patch switches the current users to
__pm_runtime_put_autosuspend() which will continue to have the
functionality of old pm_runtime_put_autosuspend().
Signed-off-by: Sakari Ailus
---
drivers
pm_runtime_put_autosuspend() will soon be changed to include a call to
pm_runtime_mark_last_busy(). This patch switches the current users to
__pm_runtime_put_autosuspend() which will continue to have the
functionality of old pm_runtime_put_autosuspend().
Signed-off-by: Sakari Ailus
---
drivers
pm_runtime_put_autosuspend() will soon be changed to include a call to
pm_runtime_mark_last_busy(). This patch switches the current users to
__pm_runtime_put_autosuspend() which will continue to have the
functionality of old pm_runtime_put_autosuspend().
Signed-off-by: Sakari Ailus
---
drivers
On Thu, 03 Oct 2024, Christophe JAILLET wrote:
> kstrdup_const() and kfree_const() can be confusing in code built as a
> module. In such a case, it does not do what one could expect from the name
> of the functions.
>
> The code is not wrong by itself, but in such a case, it is equivalent to
> kst
RQ is also
assigned.
Attached is a patch that fixes a possible off-by-one error in the
register settings. This would affect the bug you're reporting. If
possible, please apply the patch to your 6.12-rc1, test and report the
result.
Best regards
Thomas
$ sudo lspci -vvv -s :08:00
All occurrences of this error fix should have been together in a single
patch both in _get and _set callbacks corresponding to f0b19b84d391,
please avoid separate patch for each occurrence.
Sorry Alex, I missed to note this yesterday.
Regards,
Sathish
On 10/4/2024 1:46 PM, Advait
Add support for the drm_panic module, which displays a pretty user
friendly message on the screen when a Linux kernel panic occurs.
It should work on all readeon using amdgpu_dm_plane.c, when the
framebuffer is linear (like when in a VT). For tiled framebuffer, it
will only work on radeon with dcn
Hi,
thanks for your patch.
> [PATCH] Subject: fbdev: sstfb: Make CONFIG_FB_DEVICE optional
'Subject:' should not be part of the subject line. Is that an issue with
your mail setup?
Am 02.10.24 um 23:45 schrieb Gonzalo Silvalde Blanco:
The sstfb driver currently depends on CON
Hi,
On 2024/9/30 21:03, Thomas Zimmermann wrote:
DRM's aperture functions have long been implemented as helpers
under drivers/video/ for use with fbdev. Avoid the DRM wrappers by
calling the video functions directly.
Okay!
Sometimes the aperture_remove_conflicting_devices() is more easier
to
Fix shift-count-overflow when creating mask.
The expression's value may not be what the
programmer intended, because the expression is
evaluated using a narrower integer type.
Fixes: f0b19b84d391 ("drm/amdgpu: add amdgpu_jpeg_sched_mask debugfs")
Signed-off-by: Advait Dhamorikar
---
drivers/gpu/
Thomas Zimmermann writes:
Hello Thomas,
> In probe, return the error code from the variable bochs, not dev. The
> variable dev has not been initialized at this point. In the case of an
> allocation error, the returned value would have been undefined.
>
> Reported-by: Kees Bakker
> Closes:
> ht
In probe, return the error code from the variable bochs, not dev. The
variable dev has not been initialized at this point. In the case of an
allocation error, the returned value would have been undefined.
Reported-by: Kees Bakker
Closes:
https://lore.kernel.org/dri-devel/8c5bfc12-cbcc-4102-9826-
Hi Krzysztof,
On Fri, 2024-10-04 at 08:35 +0200, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On Fri, Oct 04, 2024 at 11:12:45AM +0800, Moudy Ho wrote:
> > The display node in mt8195.dt
On 04/10/2024 01:07, Miguel Ojeda wrote:
Under `CONFIG_DRM_PANIC_SCREEN_QR_CODE=y`, zlib is used:
ld.lld: error: undefined symbol: zlib_deflate_workspacesize
>>> referenced by drm_panic.c
>>> drivers/gpu/drm/drm_panic.o:(drm_panic_qr_init) in
archive vmlinux.a
Thus
On Fri, Oct 04, 2024 at 11:12:45AM +0800, Moudy Ho wrote:
> The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
> to an excessively long 'clocks' property:
> display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
>
> To resolve this issue, the constraints for 'clo
Hi,
On 03-10-2024 15:13, Aradhya Bhatia wrote:
> Hi Wadim,
>
> Thanks for the patch.
>
> Probably a nit, but the dt-binding patch should come before the driver
> patch.
>
> On 03-10-2024 13:50, Wadim Egorov wrote:
>> Introduce a data-lines property to define the n
Am 03.10.24 um 15:26 schrieb Krzysztof Kozlowski:
On 03/10/2024 13:56, Wadim Egorov wrote:
Am 03.10.24 um 12:03 schrieb Krzysztof Kozlowski:
On 03/10/2024 10:20, Wadim Egorov wrote:
The SI9022 HDMI transmitter can be configured with 16, 18, or 24 input
data lines. This commit introduces t
The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'clocks' property:
display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
To resolve this issue, the constraints for 'clocks' and
other properties within the subschema will be reinforced.
Hi,
This patch contains an incorrect compatible name; please excuse the
oversight and discard this patch.
Sincerely,
Moudy Ho
On Fri, 2024-10-04 at 10:24 +0800, Moudy Ho wrote:
> The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
> to an excessively long 'clock
The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'clocks' property:
display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
To resolve this issue, the constraints for 'clocks' and
other properties within the subschemas will be reinforced.
The patch is to solve null dereference in 'aux.dev', which is
introduced in recent radeon rework. By having 'late_register',
the connector should be registered after 'drm_dev_register'
automatically, where in before it is the opposite.
Fixes: 90985660ba48 ("dr
On Thu, 03 Oct 2024 10:14:18 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
On Thu, 03 Oct 2024 10:14:22 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
On Thu, Oct 03, 2024 at 10:14:19AM +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of
On Thu, 03 Oct 2024 10:14:21 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
On Thu, 03 Oct 2024 10:14:20 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
Under `CONFIG_DRM_PANIC_SCREEN_QR_CODE=y`, zlib is used:
ld.lld: error: undefined symbol: zlib_deflate_workspacesize
>>> referenced by drm_panic.c
>>> drivers/gpu/drm/drm_panic.o:(drm_panic_qr_init) in
archive vmlinux.a
Thus select `CONFIG_ZLIB_DEFLATE`.
Fixes: cb5164a
Fri, Sep 06, 2024 at 01:01:29PM +0200, Daniel Gomez kirjoitti:
> The uuid_t struct defined in sys/types.h on macOS hosts conflicts with
> the one defined in file2alias, resulting in the typedef redefinition
> error below. To resolve this conflict, define the _UUID_T and
> __GETHOSTUUID_ in file2ali
&clps711x_lcd_ops);
- if (!IS_ERR(lcd))
- return 0;
+ return 0;
- ret = PTR_ERR(lcd);
unregister_framebuffer(info);
out_fb_dealloc_cmap:
Something is not right here. With the current patch you'll make the
unregister_framebuffer(info)
unreachable
On 9/17/24 2:08 PM, Colin Ian King wrote:
The mutex field has two following semicolons, replace this with just
one semicolon.
Signed-off-by: Colin Ian King
Applied to drm-misc-fixes, thanks!
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +-
1 file changed, 1 insertion(+), 1 d
Applied. Thanks!
On Thu, Oct 3, 2024 at 6:53 AM Sundararaju, Sathishkumar
wrote:
>
>
> The patch is Reviewed-by: Sathishkumar S
>
> Regards,
> Sathish
>
>
> On 10/3/2024 3:56 PM, Advait Dhamorikar wrote:
> > Fix shift-count-overflow in JPEG instance
> >
On Thu, Oct 03, 2024 at 05:41:10PM +0200, Louis Chauvet wrote:
> Some members of the drm_crtc structure have been deprecated in favor of
> equivalent members in the drm_crtc_state structure. As reported by Ville
> Syrjala [1], the VKMS driver was still using these deprecated fields. This
> commit u
EDID")
> Signed-off-by: Pin-yen Lin
> Reviewed-by: Dmitry Baryshkov
> Reviewed-by: Douglas Anderson
>
> ---
>
> Changes in v2:
> - Collect review tags
>
> drivers/gpu/drm/bridge/ite-it6505.c | 2 ++
> 1 file changed, 2 insertions(+)
Like with patch #1, meant to
an EDID read after system resume to fix this.
> >
> > Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP")
> > Signed-off-by: Pin-yen Lin
> > Reviewed-by: Dmitry Baryshkov
>
> I don't think it needs a re-spin, but for future referen
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 run a pixel-by-pixel compari
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 +---
drivers/gpu/drm/drm_
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
From: Alex Hung
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 color pipeline now consists
From: Alex Hung
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_oversaturate
kms_colorop --run
From: Alex Hung
We've previously introduced DRM_COLOROP_1D_CURVE for
pre-defined 1D curves. But we also have HW that supports
custom curves and userspace needs the ability to pass
custom curves, aka LUTs.
This patch introduces a new colorop type, called
DRM_COLOROP_1D_LUT that provides a
This patchset enables support for the PQ_125 EOTF and its inverse
on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this patchset the following IGT subtests are passing:
kms_colorop --run plane-XR30-XR30-pq_125_eotf
kms_colorop --run plane-XR30-XR30-pq_125_inv_
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.
Both are used as encoding functions for video content, and are
therefore defined as OETF (opto-electronic transfer function)
instead o
From: Alex Hung
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 pipeline now consists of
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/amdgpu_
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_inv_oetf
kms_colorop --run plane-XR30-XR30-bt2020_oetf
Signed-off
This patch introduces a VKMS color pipeline that includes two
drm_colorops for named transfer functions. For now the only ones
supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
We will expand this in the future but I don't want to do so
without accompanying IGT tests.
We introd
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/drivers
From: Alex Hung
Expose a 2nd curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to
perform the sRGB Inverse EOTF on the shaper block
when the colorop is not in bypass.
With this change the follow IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf
kms_co
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
901 - 1000 of 59109 matches
Mail list logo
