Re: [PATCH v7 1/7] drm: atmel-hlcdc: add flag and driver ops to differentiate XLCDC and HLCDC IP
Dear Community Members,
I hope this message finds you well. I'm writing to kindly remind you
about this patch series my colleague submitted for review.
I understand that everyone is busy,I would greatly appreciate your
feedback. I thank everyone who participated in the review of the
previous revisions.
I strongly believe your feedback would help improve the quality of the
code. Thanks in advance.
Regards,
Hari
On 05/10/23 2:59 pm, Manikandan Muralidharan wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Add is_xlcdc flag and LCD IP specific ops in driver data to differentiate
> XLCDC and HLCDC code within the atmel-hlcdc driver files.
>
> Signed-off-by: Manikandan Muralidharan
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 37
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> index 5b5c774e0edf..d5e01ff8c7f9 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> @@ -177,6 +177,9 @@ struct atmel_hlcdc_layer_cfg_layout {
> int csc;
> };
>
> +struct atmel_hlcdc_plane_state;
> +struct atmel_hlcdc_dc;
> +
> /**
>* Atmel HLCDC DMA descriptor structure
>*
> @@ -288,6 +291,36 @@ atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer
> *layer)
> return container_of(layer, struct atmel_hlcdc_plane, layer);
> }
>
> +/**
> + * struct atmel_lcdc_dc_ops - describes atmel_lcdc ops group
> + * to differentiate HLCDC and XLCDC IP code support.
> + * @plane_setup_scaler: update the vertical and horizontal scaling factors
> + * @update_lcdc_buffers: update the each LCDC layers DMA registers.
> + * @lcdc_atomic_disable: disable LCDC interrupts and layers
> + * @lcdc_update_general_settings: update each LCDC layers general
> + * confiugration register.
> + * @lcdc_atomic_update: enable the LCDC layers and interrupts.
> + * @lcdc_csc_init: update the color space conversion co-efficient of
> + * High-end overlay register.
> + * @lcdc_irq_dbg: to raise alert incase of interrupt overrun in any LCDC
> layer.
> + */
> +struct atmel_lcdc_dc_ops {
> + void (*plane_setup_scaler)(struct atmel_hlcdc_plane *plane,
> + struct atmel_hlcdc_plane_state *state);
> + void (*update_lcdc_buffers)(struct atmel_hlcdc_plane *plane,
> + struct atmel_hlcdc_plane_state *state,
> + u32 sr, int i);
> + void (*lcdc_atomic_disable)(struct atmel_hlcdc_plane *plane);
> + void (*lcdc_update_general_settings)(struct atmel_hlcdc_plane *plane,
> +struct atmel_hlcdc_plane_state
> *state);
> + void (*lcdc_atomic_update)(struct atmel_hlcdc_plane *plane,
> + struct atmel_hlcdc_dc *dc);
> + void (*lcdc_csc_init)(struct atmel_hlcdc_plane *plane,
> + const struct atmel_hlcdc_layer_desc *desc);
> + void (*lcdc_irq_dbg)(struct atmel_hlcdc_plane *plane,
> +const struct atmel_hlcdc_layer_desc *desc);
> +};
> +
> /**
>* Atmel HLCDC Display Controller description structure.
>*
> @@ -304,8 +337,10 @@ atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer
> *layer)
>* @conflicting_output_formats: true if RGBXXX output formats conflict with
>* each other.
>* @fixed_clksrc: true if clock source is fixed
> + * @is_xlcdc: true if XLCDC IP is supported
>* @layers: a layer description table describing available layers
>* @nlayers: layer description table size
> + * @ops: atmel lcdc dc ops
>*/
> struct atmel_hlcdc_dc_desc {
> int min_width;
> @@ -317,8 +352,10 @@ struct atmel_hlcdc_dc_desc {
> int max_hpw;
> bool conflicting_output_formats;
> bool fixed_clksrc;
> + bool is_xlcdc;
> const struct atmel_hlcdc_layer_desc *layers;
> int nlayers;
> + const struct atmel_lcdc_dc_ops *ops;
> };
>
> /**
> --
> 2.25.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v7 00/20] Imagination Technologies PowerVR DRM driver
On 10.10.2023 16:37, Sarah Walker wrote: This patch series adds the initial DRM driver for Imagination Technologies PowerVR GPUs, starting with those based on our Rogue architecture. It's worth pointing out that this is a new driver, written from the ground up, rather than a refactored version of our existing downstream driver (pvrsrvkm). This new DRM driver supports: - GEM shmem allocations - dma-buf / PRIME - Per-context userspace managed virtual address space - DRM sync objects (binary and timeline) - Power management suspend / resume - GPU job submission (geometry, fragment, compute, transfer) - META firmware processor - MIPS firmware processor - GPU hang detection and recovery Currently our main focus is on the AXE-1-16M GPU. Testing so far has been done using a TI SK-AM62 board (AXE-1-16M GPU). Firmware for the AXE-1-16M can be found here: https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr And what about another PowerVR (rogue-based) GPU? There are a lot of different models of rogue GPU in existed SoCs. New driver uses v3 firmware, but vendors uses v1/v2 firmwares. Who will provide firmware/source code v3 for all the others models?
[ANNOUNCE] libdrm 2.4.117
Chia-I Wu (1):
modetest: print modifiers in hex as well
Dmitry Baryshkov (1):
modetest: custom mode support
Dylan Baker (3):
meson: fix intel requirements
meson: Use feature.require() and feature.allowed()
meson: replace deprecated program.path -> program.full_path
Ezequiel Garcia (1):
modetest: avoid erroring if there's no gamma legacy support
Geert Uytterhoeven (8):
amdgpu: Fix pointer/integer mismatch warning
amdgpu: Use PRI?64 to format uint64_t
util: add NV24 and NV42 frame buffer formats
util: add pattern support for DRM_FORMAT_NV{24,42}
modetest: add support for DRM_FORMAT_NV{24,42}
util: fix grey in YUV SMPTE patterns
modetest: fix mode_vrefresh() for interlace/dblscan/vscan
util: remove unused definitions of RED, GREEN, and BLUE
Jonathan Gray (5):
amdgpu: add marketing names from amd-5.4.6 (22.40.6)
amdgpu: add marketing names from amd-5.5.1 (23.10.1)
amdgpu: add marketing names from PRO Edition 23.Q3 W7000
amdgpu: add marketing names from Adrenalin 23.7.2
amdgpu: add marketing names from Adrenalin 23.9.1
Marijn Suijten (2):
modetest: document why no blob is created for linear gamma LUT
modetest: allocate and commit atomic request around set_property()
Neil Armstrong (2):
modetest: permit -r and -s to work together
modetest: allow using -r and -P
Rohith Iyer (1):
modetest: add support for writeback connector
Samuel Pitoiset (2):
amdgpu: amdgpu_drm.h for new GPUVM fault ioctl
amdgpu: add support for querying VM faults information
Simon Ser (3):
xf86drm: mark DRM_MAX_MINOR as deprecated
ci: bump FreeBSD to 13.2
build: bump version to 2.4.117
git tag: libdrm-2.4.117
https://dri.freedesktop.org/libdrm/libdrm-2.4.117.tar.xz
SHA256: a2888d69e3eb1c8a77adc08a75a60fbae01f0d208d26f034d1a12e362361242b
libdrm-2.4.117.tar.xz
SHA512:
326cf565548fb9d50a321562c13acb2a2f5ad5915ffdc2b08ef812fbac887f5b3d271cb2ce8c483633edddf2c55064d55810ff6697f713c179e2d0c8048eb544
libdrm-2.4.117.tar.xz
PGP: https://dri.freedesktop.org/libdrm/libdrm-2.4.117.tar.xz.sig
[git pull] drm fixes for 6.6-rc7
Hey Linus, Regular fixes for the week, amdgpu, i915, nouveau, with some other scattered around, nothing major. Dave. drm-fixes-2023-10-20: drm fixes for 6.6-rc7 amdgpu: - Fix possible NULL pointer dereference - Avoid possible BUG_ON in GPUVM updates - Disable AMD_CTX_PRIORITY_UNSET i915: - Fix display issue that was blocking S0ix - Retry gtt fault when out of fence registers bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup mediatek: - Correctly free sg_table in gem prime vmap The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb: Linux 6.6-rc6 (2023-10-15 13:34:39 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-10-20 for you to fetch changes up to 8b35ce3f7a9699e7580527fe4510d77f2a35f02d: Merge tag 'mediatek-drm-fixes-20231017' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes (2023-10-20 14:24:35 +1000) drm fixes for 6.6-rc7 amdgpu: - Fix possible NULL pointer dereference - Avoid possible BUG_ON in GPUVM updates - Disable AMD_CTX_PRIORITY_UNSET i915: - Fix display issue that was blocking S0ix - Retry gtt fault when out of fence registers bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup mediatek: - Correctly free sg_table in gem prime vmap Chen-Yu Tsai (1): drm/mediatek: Correctly free sg_table in gem prime vmap Dave Airlie (4): Merge tag 'amd-drm-fixes-6.6-2023-10-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2023-10-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2023-10-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'mediatek-drm-fixes-20231017' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Douglas Anderson (1): drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple Felix Kuehling (2): drm/amdgpu: Fix possible null pointer dereference drm/amdgpu: Reserve fences for VM update Hamza Mahfooz (1): drm/edid: add 8 bpc quirk to the BenQ GW2765 Jacek Lawrynowicz (1): accel/ivpu: Don't enter d0i3 during FLR Karol Herbst (1): drm/nouveau/disp: fix DP capable DSM connectors Karolina Stolarek (1): drm/ttm: Reorder sys manager cleanup step Khaled Almahallawy (1): drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned Luben Tuikov (2): drm/amdgpu: Unset context priority is now invalid gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET Randy Dunlap (1): drm/nouveau: exec: fix ioctl kernel-doc warning Stanislaw Gruszka (1): Revert "accel/ivpu: Use cached buffers for FW loading" Stephen Boyd (1): drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device Ville Syrjälä (1): drm/i915: Retry gtt fault when out of fence registers Wludzik, Jozef (1): accel/ivpu: Extend address range for MMU mmap drivers/accel/ivpu/ivpu_drv.c| 11 ++-- drivers/accel/ivpu/ivpu_drv.h| 1 + drivers/accel/ivpu/ivpu_fw.c | 9 +++--- drivers/accel/ivpu/ivpu_gem.h| 5 drivers/accel/ivpu/ivpu_hw.h | 8 ++ drivers/accel/ivpu/ivpu_hw_37xx.c| 1 + drivers/accel/ivpu/ivpu_hw_40xx.c| 1 + drivers/accel/ivpu/ivpu_mmu_context.c| 9 ++ drivers/accel/ivpu/ivpu_pm.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 5 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 5 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +- drivers/gpu/drm/bridge/ti-sn65dsi86.c| 14 +- drivers/gpu/drm/drm_edid.c | 3 ++ drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +++- drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c | 14 +- drivers/gpu/drm/panel/panel-edp.c| 29 drivers/gpu/drm/panel/panel-simple.c | 35 drivers/gpu/drm/ttm/ttm_device.c | 8 +++--- include/drm/gpu_scheduler.h
Re: [PATCH] drm/doc: ci: Require more context for flaky tests
On 19/10/2023 13:51, Helen Koike wrote:
On 19/10/2023 06:46, Maxime Ripard wrote:
Flaky tests can be very difficult to reproduce after the facts, which
will make it even harder to ever fix.
Let's document the metadata we agreed on to provide more context to
anyone trying to address these fixes.
Link:
https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/
Signed-off-by: Maxime Ripard
---
Documentation/gpu/automated_testing.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 469b6fb65c30..2dd0e221c2c3 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,6 +67,19 @@ Lists the tests that for a given driver on a
specific hardware revision are
known to behave unreliably. These tests won't cause a job to fail
regardless of
the result. They will still be run.
+Each new flake entry must be associated with a link to a bug report to
What do you mean by but report? Just a link to an email to the mailing
list is enough?
Also, I had made a mistake to the first flakes lists, which I corrected
with https://www.spinics.net/lists/kernel/msg4959629.html (there was a
bug in my script which ended up erroneous adding a bunch of tests in the
flake list, so I cleaned them up), I would like to kind request to let
me add those documentation in a future patch to not block that patch
series.
Thanks
Helen
+the author of the affected driver, the board name or Device Tree name of
+the board, the first kernel version affected, and an approximation of
+the failure rate.
+
+They should be provided under the following format::
+
+ # Bug Report: $LORE_OR_PATCHWORK_URL
I wonder if the commit adding the test into the flakes.txt file with and
Acked-by from the device maintainer shouldn't be already considered the
Bug Report.
+ # Board Name: broken-board.dtb
Maybe Board Name isn't required, since it is already in the name of the
file.
+ # Version: 6.6-rc1
+ # Failure Rate: 100
Maybe also:
# Pipeline url:
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/1014435
All this info will complicated a bit the update-xfails.py script, but
well, we can handle...
(see
https://patchwork.kernel.org/project/dri-devel/patch/20231020034124.136295-4-helen.ko...@collabora.com/
)
We need to update that script to make life easier.
Vignesh sent a patch adding at least the pipeline url to the file
https://patchwork.kernel.org/project/linux-arm-msm/patch/20231019070650.61159-9-vignesh.ra...@collabora.com/
but to meet this doc that needs to be updated too.
Regards,
Helen
+ flaky-test
+
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
[PATCH v2 9/9] drm/ci: docs: add step about how to request privileges
Clarify the procedure developer must follow to request privileges to run tests on Freedesktop gitlab CI. This measure was added to avoid untrusted people to misuse the infrastructure. Signed-off-by: Helen Koike Reviewed-by: David Heidelberg --- v2: - fix typo in commit message --- Documentation/gpu/automated_testing.rst | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/automated_testing.rst b/Documentation/gpu/automated_testing.rst index 469b6fb65c30..8ec1878b44ab 100644 --- a/Documentation/gpu/automated_testing.rst +++ b/Documentation/gpu/automated_testing.rst @@ -86,10 +86,13 @@ https://gitlab.freedesktop.org/janedoe/linux/-/settings/ci_cd), change the CI/CD configuration file from .gitlab-ci.yml to drivers/gpu/drm/ci/gitlab-ci.yml. -3. Next time you push to this repository, you will see a CI pipeline being +3. Request to be added to the drm/ci-ok group so that your user has the +necessary privileges to run the CI on https://gitlab.freedesktop.org/drm/ci-ok + +4. Next time you push to this repository, you will see a CI pipeline being created (eg. https://gitlab.freedesktop.org/janedoe/linux/-/pipelines) -4. The various jobs will be run and when the pipeline is finished, all jobs +5. The various jobs will be run and when the pipeline is finished, all jobs should be green unless a regression has been found. -- 2.39.2
[PATCH v2 8/9] drm/ci: do not automatically retry on error
Since the kernel doesn't use a bot like Mesa that requires tests to pass
in order to merge the patches, leave it to developers and/or maintainers
to manually retry.
Suggested-by: Rob Clark
Signed-off-by: Helen Koike
Reviewed-by: David Heidelberg
---
v2:
- no changes
---
drivers/gpu/drm/ci/gitlab-ci.yml | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index b99015afd6a0..97b959b54c45 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -55,20 +55,6 @@ default:
export CI_JOB_JWT="$(<${CI_JOB_JWT_FILE})" &&
rm "${CI_JOB_JWT_FILE}"
- # Retry when job fails.
- retry:
-max: 1
-# Ignore runner_unsupported, stale_schedule, archived_failure, or
-# unmet_prerequisites
-when:
- - api_failure
- - runner_system_failure
- - script_failure
- - job_execution_timeout
- - scheduler_failure
- - data_integrity_failure
- - unknown_failure
-
include:
- project: 'freedesktop/ci-templates'
ref: 16bc29078de5e0a067ff84a1a199a3760d3b3811
--
2.39.2
[PATCH v2 7/9] drm/ci: export kernel config
Export the resultant kernel config, making it easier to verify if the
resultant config was correctly generated.
Suggested-by: Rob Clark
Signed-off-by: Helen Koike
Acked-by: Dmitry Baryshkov
Reviewed-by: David Heidelberg
---
v2:
- no changes
---
drivers/gpu/drm/ci/build.sh | 1 +
drivers/gpu/drm/ci/image-tags.yml | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index e3908f4d71cb..e5c5dcedd108 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -153,6 +153,7 @@ mkdir -p artifacts/install/lib
mv install/* artifacts/install/.
rm -rf artifacts/install/modules
ln -s common artifacts/install/ci-common
+cp .config artifacts/${CI_JOB_NAME}_config
for image in ${KERNEL_IMAGE_NAME}; do
cp /lava-files/$image artifacts/install/.
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index 7dd3f995f8a2..7ab4f2514da8 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "2023-10-08-igt"
+ DEBIAN_BUILD_TAG: "2023-10-08-config"
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
--
2.39.2
[PATCH v2 6/9] drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shards
The Collabora Lava farm added a tag called `subset-1-gfx` to half of
devices the graphics community use.
Lets use this tag so we don't occupy all the resources.
This is particular important because Mesa3D shares the resources with
DRM-CI and use them to do pre-merge tests, so it can block developers
from getting their patches merged.
Signed-off-by: Helen Koike
Reviewed-by: David Heidelberg
---
v2:
- add subset-1-gfx tag to LAVA_TAGS
- update commit message
---
drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
drivers/gpu/drm/ci/test.yml | 23 ++-
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index ade6c65a1945..b99015afd6a0 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -26,7 +26,7 @@ variables:
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
# default kernel for rootfs before injecting the current kernel tree
KERNEL_IMAGE_BASE:
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
-
+ LAVA_TAGS: subset-1-gfx
LAVA_JOB_PRIORITY: 30
default:
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 3479d2a0108d..19dc0862e710 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -86,7 +86,7 @@ msm:sc7180:
extends:
- .lava-igt:arm64
stage: msm
- parallel: 2
+ parallel: 4
variables:
DRIVER_NAME: msm
DEVICE_TYPE: sc7180-trogdor-lazor-limozeen
@@ -155,7 +155,7 @@ rockchip:rk3399:
extends:
- .lava-igt:arm64
stage: rockchip
- parallel: 3
+ parallel: 2
variables:
DRIVER_NAME: rockchip
DEVICE_TYPE: rk3399-gru-kevin
@@ -178,7 +178,7 @@ rockchip:rk3399:
i915:apl:
extends:
- .i915
- parallel: 12
+ parallel: 3
variables:
DEVICE_TYPE: asus-C523NA-A20057-coral
GPU_VERSION: apl
@@ -187,7 +187,7 @@ i915:apl:
i915:glk:
extends:
- .i915
- parallel: 5
+ parallel: 2
variables:
DEVICE_TYPE: hp-x360-12b-ca0010nr-n4020-octopus
GPU_VERSION: glk
@@ -196,7 +196,7 @@ i915:glk:
i915:amly:
extends:
- .i915
- parallel: 8
+ parallel: 2
variables:
DEVICE_TYPE: asus-C433TA-AJ0005-rammus
GPU_VERSION: amly
@@ -205,7 +205,7 @@ i915:amly:
i915:kbl:
extends:
- .i915
- parallel: 5
+ parallel: 3
variables:
DEVICE_TYPE: hp-x360-14-G1-sona
GPU_VERSION: kbl
@@ -214,7 +214,7 @@ i915:kbl:
i915:whl:
extends:
- .i915
- parallel: 8
+ parallel: 2
variables:
DEVICE_TYPE: dell-latitude-5400-8665U-sarien
GPU_VERSION: whl
@@ -223,7 +223,7 @@ i915:whl:
i915:cml:
extends:
- .i915
- parallel: 6
+ parallel: 2
variables:
DEVICE_TYPE: asus-C436FA-Flip-hatch
GPU_VERSION: cml
@@ -232,7 +232,7 @@ i915:cml:
i915:tgl:
extends:
- .i915
- parallel: 6
+ parallel: 8
variables:
DEVICE_TYPE: asus-cx9400-volteer
GPU_VERSION: tgl
@@ -251,6 +251,7 @@ i915:tgl:
amdgpu:stoney:
extends:
- .amdgpu
+ parallel: 2
variables:
DEVICE_TYPE: hp-11A-G6-EE-grunt
GPU_VERSION: stoney
@@ -269,6 +270,7 @@ amdgpu:stoney:
mediatek:mt8173:
extends:
- .mediatek
+ parallel: 4
variables:
DEVICE_TYPE: mt8173-elm-hana
GPU_VERSION: mt8173
@@ -280,6 +282,7 @@ mediatek:mt8173:
mediatek:mt8183:
extends:
- .mediatek
+ parallel: 3
variables:
DEVICE_TYPE: mt8183-kukui-jacuzzi-juniper-sku16
GPU_VERSION: mt8183
@@ -289,6 +292,7 @@ mediatek:mt8183:
.mediatek:mt8192:
extends:
- .mediatek
+ parallel: 3
variables:
DEVICE_TYPE: mt8192-asurada-spherion-r0
GPU_VERSION: mt8192
@@ -307,6 +311,7 @@ mediatek:mt8183:
meson:g12b:
extends:
- .meson
+ parallel: 3
variables:
DEVICE_TYPE: meson-g12b-a311d-khadas-vim3
GPU_VERSION: g12b
--
2.39.2
[PATCH v2 5/9] drm/ci: clean up xfails (specially flakes list)
Since the script that collected the list of the expectation files was bogus and placing test to the flakes list incorrectly, restart the expectation files with the correct script. This reduces a lot the number of tests in the flakes list. Signed-off-by: Helen Koike Reviewed-by: David Heidelberg --- v2: - fix typo in the commit message - re-add kms_cursor_legacy@flip-vs-cursor-toggle back to msm-sdm845-flakes.txt - removed kms_async_flips@crc,Fail from i915-cml-fails.txt --- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 13 -- .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 20 - drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 9 .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 32 --- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 - drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 1 - drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 14 ++- drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 38 - drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 17 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 41 --- drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 7 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 26 drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt | 5 --- drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 1 - .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 0 .../drm/ci/xfails/mediatek-mt8183-fails.txt | 5 ++- .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 14 --- .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 14 --- .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 4 -- .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 4 -- .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 2 + .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 4 -- .../gpu/drm/ci/xfails/msm-sc7180-fails.txt| 15 --- .../gpu/drm/ci/xfails/msm-sc7180-flakes.txt | 24 +++ .../gpu/drm/ci/xfails/msm-sc7180-skips.txt| 18 +--- .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 9 +--- .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 19 + .../drm/ci/xfails/rockchip-rk3288-fails.txt | 6 +++ .../drm/ci/xfails/rockchip-rk3288-flakes.txt | 9 .../drm/ci/xfails/rockchip-rk3399-fails.txt | 40 +- .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 28 +++-- .../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0 33 files changed, 162 insertions(+), 289 deletions(-) delete mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index bd9392536e7c..aa57aaa8869b 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,8 +1,14 @@ kms_addfb_basic@bad-pitch-65536,Fail kms_addfb_basic@bo-too-small,Fail +kms_addfb_basic@too-high,Fail +kms_async_flips@async-flip-with-page-flip-events,Fail +kms_async_flips@crc,Fail kms_async_flips@invalid-async-flip,Fail -kms_atomic@plane-immutable-zpos,Fail +kms_atomic_transition@plane-all-modeset-transition-internal-panels,Fail +kms_atomic_transition@plane-all-transition,Fail +kms_atomic_transition@plane-all-transition-nonblocking,Fail kms_atomic_transition@plane-toggle-modeset-transition,Fail +kms_atomic_transition@plane-use-after-nonblocking-unbind,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail kms_bw@linear-tiling-2-displays-3840x2160p,Fail @@ -11,9 +17,10 @@ kms_color@degamma,Fail kms_cursor_crc@cursor-size-change,Fail kms_cursor_crc@pipe-A-cursor-size-change,Fail kms_cursor_crc@pipe-B-cursor-size-change,Fail -kms_cursor_legacy@forked-move,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail kms_hdr@bpc-switch,Fail kms_hdr@bpc-switch-dpms,Fail +kms_plane@pixel-format,Fail kms_plane_multiple@atomic-pipe-A-tiling-none,Fail -kms_rmfb@close-fd,Fail kms_rotation_crc@primary-rotation-180,Fail diff --git
[PATCH v2 4/9] drm/ci: uprev IGT and make sure core_getversion is run
IGT has recently merged a patch that makes code_getversion test to fails
if the driver isn't loaded or if it isn't the expected one defined in
variable IGT_FORCE_DRIVER.
Without this test, jobs were passing when the driver didn't load or
probe for some reason, giving the illusion that everything was ok.
Uprev IGT to include this modification and include core_getversion test
in all the shards.
Signed-off-by: Helen Koike
Reviewed-by: David Heidelberg
---
v2:
- fixed typo in the commit message
---
drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
drivers/gpu/drm/ci/igt_runner.sh | 31 ---
drivers/gpu/drm/ci/image-tags.yml | 2 +-
3 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 51b1af77b04f..ade6c65a1945 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -5,7 +5,7 @@ variables:
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
- IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663
+ IGT_VERSION: d1db7333d9c5fbbb05e50b0804123950d9dc1c46
DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git
DEQP_RUNNER_GIT_TAG: v0.15.0
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index 2bb759165063..2f815ee3a8a3 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -20,11 +20,16 @@ set +e
cat /sys/kernel/debug/dri/*/state
set -e
-# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the module in
/lib
-if [ "$IGT_FORCE_DRIVER" = "amdgpu" ]; then
-mv /install/modules/lib/modules/* /lib/modules/.
-modprobe amdgpu
-fi
+case "$DRIVER_NAME" in
+rockchip|mediatek|meson)
+export IGT_FORCE_DRIVER="panfrost"
+;;
+amdgpu)
+# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the
module in /lib
+mv /install/modules/lib/modules/* /lib/modules/.
+modprobe amdgpu
+;;
+esac
if [ -e "/install/xfails/$DRIVER_NAME-$GPU_VERSION-skips.txt" ]; then
IGT_SKIPS="--skips /install/xfails/$DRIVER_NAME-$GPU_VERSION-skips.txt"
@@ -48,6 +53,20 @@ fi
curl -L --retry 4 -f --retry-all-errors --retry-delay 60 -s
${FDO_HTTP_CACHE_URI:-}$PIPELINE_ARTIFACTS_BASE/$ARCH/igt.tar.gz | tar --zstd
-v -x -C /
+
+# If the job is parallel at the gitab job level, take the corresponding
fraction
+# of the caselist.
+if [ -n "$CI_NODE_INDEX" ]; then
+sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" /install/testlist.txt
+fi
+
+# core_getversion checks if the driver is loaded and probed correctly
+# so run it in all shards
+if ! grep -q "core_getversion" /install/testlist.txt; then
+# Add the line to the file
+echo "core_getversion" >> /install/testlist.txt
+fi
+
set +e
igt-runner \
run \
@@ -57,8 +76,6 @@ igt-runner \
$IGT_SKIPS \
$IGT_FLAKES \
$IGT_FAILS \
---fraction-start $CI_NODE_INDEX \
---fraction $CI_NODE_TOTAL \
--jobs 1
ret=$?
set -e
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index e1b387581c11..7dd3f995f8a2 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "2023-10-06-amd"
+ DEBIAN_BUILD_TAG: "2023-10-08-igt"
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
--
2.39.2
[PATCH v2 3/9] drm/ci: add helper script update-xfails.py
Add helper script that given a gitlab pipeline url, analyse which are
the failures and flakes and update the xfails folder accordingly.
Example:
Trigger a pipeline in gitlab infrastructure, than re-try a few jobs more
than once (so we can have data if failures are consistent across jobs
with the same name or if they are flakes) and execute:
update-xfails.py
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/970661
git diff should show you that it updated files in xfails folder.
Signed-off-by: Helen Koike
Tested-by: Vignesh Raman
Reviewed-by: David Heidelberg
---
Hello,
This script is being very handy for me, so I suppose it could be handy
to others, since I'm publishing it in the xfails folder.
Let me know your thoughts.
Derivative work from the RFC:
https://patchwork.kernel.org/project/dri-devel/patch/20230925195556.106090-1-helen.ko...@collabora.com/
what changed:
- refactor and fix the script, it had several bugs
- change the output to show a diff of what has changed
Regards,
Helen
---
v2:
- fixed typos
- remove test from fails.txt before adding to flakes.txt if present
- fix when the failures.csv is an empty string
---
drivers/gpu/drm/ci/xfails/requirements.txt | 17 ++
drivers/gpu/drm/ci/xfails/update-xfails.py | 204 +
2 files changed, 221 insertions(+)
create mode 100644 drivers/gpu/drm/ci/xfails/requirements.txt
create mode 100755 drivers/gpu/drm/ci/xfails/update-xfails.py
diff --git a/drivers/gpu/drm/ci/xfails/requirements.txt
b/drivers/gpu/drm/ci/xfails/requirements.txt
new file mode 100644
index ..f64fa608b3c4
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/requirements.txt
@@ -0,0 +1,17 @@
+git+https://gitlab.freedesktop.org/gfx-ci/ci-collate@811b4c3f7e6e372af6225c03843fc6717847bdbc
+termcolor==2.3.0
+
+# ci-collate dependencies
+certifi==2023.7.22
+charset-normalizer==3.2.0
+idna==3.4
+pip==23.2.1
+python-gitlab==3.15.0
+requests==2.31.0
+requests-toolbelt==1.0.0
+ruamel.yaml==0.17.32
+ruamel.yaml.clib==0.2.7
+setuptools==68.0.0
+tenacity==8.2.3
+urllib3==2.0.4
+wheel==0.41.1
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/xfails/update-xfails.py
b/drivers/gpu/drm/ci/xfails/update-xfails.py
new file mode 100755
index ..fd13e5bcde8c
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/update-xfails.py
@@ -0,0 +1,204 @@
+#!/usr/bin/env python3
+
+import argparse
+from collections import defaultdict
+import difflib
+import os
+import re
+from glcollate import Collate
+from termcolor import colored
+from urllib.parse import urlparse
+
+
+def get_canonical_name(job_name):
+return re.split(r" \d+/\d+", job_name)[0]
+
+
+def get_xfails_file_path(job_name, suffix):
+canonical_name = get_canonical_name(job_name)
+name = canonical_name.replace(":", "-")
+script_dir = os.path.dirname(os.path.abspath(__file__))
+return os.path.join(script_dir, f"{name}-{suffix}.txt")
+
+
+def get_unit_test_name_and_results(unit_test):
+if "Artifact results/failures.csv not found" in unit_test or '' ==
unit_test:
+return None, None
+unit_test_name, unit_test_result = unit_test.strip().split(",")
+return unit_test_name, unit_test_result
+
+
+def read_file(file_path):
+try:
+with open(file_path, "r") as file:
+f = file.readlines()
+if len(f):
+f[-1] = f[-1].strip() + "\n"
+return f
+except FileNotFoundError:
+return []
+
+
+def save_file(content, file_path):
+# delete file is content is empty
+if not content or not any(content):
+if os.path.exists(file_path):
+os.remove(file_path)
+return
+
+with open(file_path, "w") as file:
+file.writelines(content)
+
+
+def is_test_present_on_file(file_content, unit_test_name):
+return any(unit_test_name in line for line in file_content)
+
+
+def is_unit_test_present_in_other_jobs(unit_test, job_ids):
+return all(unit_test in job_ids[job_id] for job_id in job_ids)
+
+
+def remove_unit_test_if_present(lines, unit_test_name):
+if not is_test_present_on_file(lines, unit_test_name):
+return
+lines[:] = [line for line in lines if unit_test_name not in line]
+
+
+def add_unit_test_if_not_present(lines, unit_test_name, file_name):
+# core_getversion is mandatory
+if "core_getversion" in unit_test_name:
+print("WARNING: core_getversion should pass, not adding it to",
os.path.basename(file_name))
+elif all(unit_test_name not in line for line in lines):
+lines.append(unit_test_name + "\n")
+
+
+def update_unit_test_result_in_fails_txt(fails_txt, unit_test):
+unit_test_name, unit_test_result =
get_unit_test_name_and_results(unit_test)
+for i, line in enumerate(fails_txt):
+if unit_test_name in line:
+_, current_result = get_unit_test_name_and_results(line)
+fails_txt[i] = unit_test + "\n"
+return
+
+
+def
[PATCH v2 2/9] drm/ci: fix DEBIAN_ARCH and get amdgpu probing
amdgpu driver wasn't loading because amdgpu firmware wasn't being
installed in the rootfs due to the wrong DEBIAN_ARCH variable.
rename ARCH to DEBIAN_ARCH also, so we don't have the confusing
DEBIAN_ARCH, KERNEL_ARCH and ARCH.
Signed-off-by: Helen Koike
Reviewed-by: David Heidelberg
---
v2:
- fix typos in commit message
---
drivers/gpu/drm/ci/build.sh | 2 +-
drivers/gpu/drm/ci/image-tags.yml | 4 ++--
drivers/gpu/drm/ci/lava-submit.sh | 4 ++--
drivers/gpu/drm/ci/test.yml | 6 +++---
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 20a6ba8a7b04..e3908f4d71cb 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -35,7 +35,7 @@ elif [[ "$KERNEL_ARCH" = "arm" ]]; then
apt-get install -y libssl-dev:armhf
else
GCC_ARCH="x86_64-linux-gnu"
-DEBIAN_ARCH="x86_64"
+DEBIAN_ARCH="amd64"
DEVICE_TREES=""
fi
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index 157d987149f0..e1b387581c11 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,9 +4,9 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "${CONTAINER_TAG}"
+ DEBIAN_BUILD_TAG: "2023-10-06-amd"
- KERNEL_ROOTFS_TAG: "${CONTAINER_TAG}"
+ KERNEL_ROOTFS_TAG: "2023-10-06-amd"
DEBIAN_X86_64_TEST_BASE_IMAGE: "debian/x86_64_test-base"
DEBIAN_X86_64_TEST_IMAGE_GL_PATH: "debian/x86_64_test-gl"
diff --git a/drivers/gpu/drm/ci/lava-submit.sh
b/drivers/gpu/drm/ci/lava-submit.sh
index 379f26ea87cc..3d39b0c916a8 100755
--- a/drivers/gpu/drm/ci/lava-submit.sh
+++ b/drivers/gpu/drm/ci/lava-submit.sh
@@ -37,8 +37,8 @@ PYTHONPATH=artifacts/ artifacts/lava/lava_job_submitter.py \
--dump-yaml \
--pipeline-info "$CI_JOB_NAME: $CI_PIPELINE_URL on $CI_COMMIT_REF_NAME
${CI_NODE_INDEX}/${CI_NODE_TOTAL}" \
--rootfs-url-prefix "https://${BASE_SYSTEM_HOST_PATH}; \
- --kernel-url-prefix "https://${PIPELINE_ARTIFACTS_BASE}/${ARCH}; \
- --build-url
"${FDO_HTTP_CACHE_URI:-}https://${PIPELINE_ARTIFACTS_BASE}/${ARCH}/kernel-files.tar.zst;
\
+ --kernel-url-prefix "https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH};
\
+ --build-url
"${FDO_HTTP_CACHE_URI:-}https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/kernel-files.tar.zst;
\
--job-rootfs-overlay-url
"${FDO_HTTP_CACHE_URI:-}https://${JOB_ROOTFS_OVERLAY_PATH}; \
--job-timeout-min ${JOB_TIMEOUT:-80} \
--first-stage-init artifacts/ci-common/init-stage1.sh \
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 6473cddaa7a9..3479d2a0108d 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -23,7 +23,7 @@
- .lava-test:arm32
variables:
HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
-ARCH: "armhf"
+DEBIAN_ARCH: "armhf"
dependencies:
- testing:arm32
needs:
@@ -38,7 +38,7 @@
- .lava-test:arm64
variables:
HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
-ARCH: "arm64"
+DEBIAN_ARCH: "arm64"
dependencies:
- testing:arm64
needs:
@@ -53,7 +53,7 @@
- .lava-test:x86_64
variables:
HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
-ARCH: "x86_64"
+DEBIAN_ARCH: "amd64"
dependencies:
- testing:x86_64
needs:
--
2.39.2
[PATCH v2 1/9] drm/ci: uprev mesa version: fix container build & crosvm
When building containers, some rust packages were installed without
locking the dependencies version, which got updated and started giving
errors like:
error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts can be
found at `/tmp/cargo-installkNKRwf`
Caused by:
package `rustix v0.38.13` cannot be built because it requires rustc 1.63 or
newer, while the currently active rustc version is 1.60.0
A patch to Mesa was added fixing this error, so update it.
Also, commit in linux kernel 6.6 rc3 broke booting in crosvm.
Mesa has upreved crosvm to fix this issue.
Signed-off-by: Helen Koike
[crosvm mesa update]
Co-Developed-by: Vignesh Raman
Signed-off-by: Vignesh Raman
[v1 container build uprev]
Tested-by: Jessica Zhang
Acked-by: Jessica Zhang
Reviewed-by: David Heidelberg
---
v2:
- update to an even newer version of mesa to integrate crosvm uprev
---
drivers/gpu/drm/ci/build.yml | 1 +
drivers/gpu/drm/ci/gitlab-ci.yml | 20 +++-
drivers/gpu/drm/ci/image-tags.yml | 2 +-
drivers/gpu/drm/ci/lava-submit.sh | 2 +-
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ci/build.yml b/drivers/gpu/drm/ci/build.yml
index e6503f1c5927..17ab38304885 100644
--- a/drivers/gpu/drm/ci/build.yml
+++ b/drivers/gpu/drm/ci/build.yml
@@ -1,6 +1,7 @@
.build:
extends:
- .build-rules
+- .container+build-rules
stage: build
artifacts:
paths:
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 2c4df53f5dfe..51b1af77b04f 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
variables:
DRM_CI_PROJECT_PATH: mesa/mesa
- DRM_CI_COMMIT_SHA:
0dc961645c4f0241f8512cb0ec3ad59635842072
+ DRM_CI_COMMIT_SHA:
26c2c96d6228e27cdaa1335f798bf962df147bf1
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -24,6 +24,8 @@ variables:
PIPELINE_ARTIFACTS_BASE:
${S3_HOST}/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}
# per-job artifact storage on MinIO
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
+ # default kernel for rootfs before injecting the current kernel tree
+ KERNEL_IMAGE_BASE:
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
LAVA_JOB_PRIORITY: 30
@@ -86,6 +88,17 @@ include:
- '/.gitlab-ci/container/gitlab-ci.yml'
- '/.gitlab-ci/test/gitlab-ci.yml'
- '/.gitlab-ci/lava/lava-gitlab-ci.yml'
+ - '/src/microsoft/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/zink/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/crocus/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/softpipe/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/llvmpipe/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/virgl/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/nouveau/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/frontends/lavapipe/ci/gitlab-ci-inc.yml'
+ - '/src/intel/ci/gitlab-ci-inc.yml'
+ - '/src/freedreno/ci/gitlab-ci-inc.yml'
+ - '/src/amd/ci/gitlab-ci-inc.yml'
- drivers/gpu/drm/ci/image-tags.yml
- drivers/gpu/drm/ci/container.yml
- drivers/gpu/drm/ci/static-checks.yml
@@ -154,6 +167,11 @@ stages:
# Run automatically once all dependency jobs have passed
- when: on_success
+# When to automatically run the CI for container jobs
+.container+build-rules:
+ rules:
+- !reference [.no_scheduled_pipelines-rules, rules]
+- when: manual
.ci-deqp-artifacts:
artifacts:
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index f051b6c547c5..157d987149f0 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -1,5 +1,5 @@
variables:
- CONTAINER_TAG: "2023-08-10-mesa-uprev"
+ CONTAINER_TAG: "2023-10-11-mesa-uprev"
DEBIAN_X86_64_BUILD_BASE_IMAGE: "debian/x86_64_build-base"
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
diff --git a/drivers/gpu/drm/ci/lava-submit.sh
b/drivers/gpu/drm/ci/lava-submit.sh
index 0c4456b21b0f..379f26ea87cc 100755
--- a/drivers/gpu/drm/ci/lava-submit.sh
+++ b/drivers/gpu/drm/ci/lava-submit.sh
@@ -22,7 +22,7 @@ cp "$SCRIPTS_DIR"/setup-test-env.sh
results/job-rootfs-overlay/
# Prepare env vars for upload.
section_start variables "Variables passed through:"
-KERNEL_IMAGE_BASE_URL="https://${BASE_SYSTEM_HOST_PATH}; \
+KERNEL_IMAGE_BASE="https://${BASE_SYSTEM_HOST_PATH}; \
artifacts/ci-common/generate-env.sh | tee
results/job-rootfs-overlay/set-job-env-vars.sh
section_end variables
--
2.39.2
[PATCH v2 0/9] drm/ci: fixes and improvements
This series contains the several fixes, making drm/ci much more reliable and useful. Highlights: * Current DRM/CI in drm-misc is broken, this series fixes it with mesa uprev (commit 1/9). * The fails.txt and flakes.txt lists were generated by a bogus script, this series restart that initial list from scratch (commit 5/9), which reduced considerably the number of flakes. * Jobs are run in a subset of available DUTs in the Lava farm (commit 6/9) to not block merge requests for Mesa3D. * Add python script update-xfails.py to update the xfails lists (commit 3/9). Tested on https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/1014358 To work properly, the following patches are also required: [PATCH 2/2] drm/ci: force-enable CONFIG_MSM_MMCC_8996 as built-in https://patchwork.kernel.org/project/linux-arm-msm/patch/20231008132320.762542-2-dmitry.barysh...@linaro.org/ [PATCH] drm/ci: Enable CONFIG_BACKLIGHT_CLASS_DEVICE https://patchwork.kernel.org/project/dri-devel/patch/20231002164715.157298-1-robdcl...@gmail.com/ Helen Koike (9): drm/ci: uprev mesa version: fix container build & crosvm drm/ci: fix DEBIAN_ARCH and get amdgpu probing drm/ci: add helper script update-xfails.py drm/ci: uprev IGT and make sure core_getversion is run drm/ci: clean up xfails (specially flakes list) drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shards drm/ci: export kernel config drm/ci: do not automatically retry on error drm/ci: docs: add step about how to request privileges Documentation/gpu/automated_testing.rst | 7 +- drivers/gpu/drm/ci/build.sh | 3 +- drivers/gpu/drm/ci/build.yml | 1 + drivers/gpu/drm/ci/gitlab-ci.yml | 38 ++-- drivers/gpu/drm/ci/igt_runner.sh | 31 ++- drivers/gpu/drm/ci/image-tags.yml | 6 +- drivers/gpu/drm/ci/lava-submit.sh | 6 +- drivers/gpu/drm/ci/test.yml | 29 +-- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 13 +- .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 20 -- drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 9 + .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 32 --- drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 11 - drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 1 - drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 15 +- drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 38 drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 17 ++ drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 41 drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 7 + drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 26 --- drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 1 - drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt | 5 - drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 1 - .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 0 .../drm/ci/xfails/mediatek-mt8183-fails.txt | 5 +- .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 14 -- .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 14 +- .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 4 - .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 4 - .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 2 + .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 4 - .../gpu/drm/ci/xfails/msm-sc7180-fails.txt| 15 +- .../gpu/drm/ci/xfails/msm-sc7180-flakes.txt | 24 ++- .../gpu/drm/ci/xfails/msm-sc7180-skips.txt| 18 +- .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 9 +- .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 19 +- drivers/gpu/drm/ci/xfails/requirements.txt| 17 ++ .../drm/ci/xfails/rockchip-rk3288-fails.txt | 6 + .../drm/ci/xfails/rockchip-rk3288-flakes.txt | 9 - .../drm/ci/xfails/rockchip-rk3399-fails.txt | 40 +++- .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 28 +-- drivers/gpu/drm/ci/xfails/update-xfails.py| 204 ++ .../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0 43 files changed, 460 insertions(+), 334 deletions(-) delete mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/requirements.txt delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt create mode 100755
Re: linux-next: build failure after merge of the drm-misc tree
Hi all,
On Thu, 12 Oct 2023 12:27:49 +1100 Stephen Rothwell
wrote:
>
> On Thu, 12 Oct 2023 12:22:09 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/usb/typec/altmodes/displayport.c: In function 'dp_altmode_vdm':
> > drivers/usb/typec/altmodes/displayport.c:309:33: error: too few arguments
> > to function 'drm_connector_oob_hotplug_event'
> > 309 |
> > drm_connector_oob_hotplug_event(dp->connector_fwnode);
> > | ^~~
> > In file included from drivers/usb/typec/altmodes/displayport.c:17:
> > include/drm/drm_connector.h:1984:6: note: declared here
> > 1984 | void drm_connector_oob_hotplug_event(struct fwnode_handle
> > *connector_fwnode,
> > | ^~~
> >
> > Caused by commit
> >
> > fc93835bb0d7 ("drm: Add HPD state to drm_connector_oob_hotplug_event()")
> >
> > interacting with commit
> >
> > 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when
> > exiting mode")
> >
> > from the usb.current tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell
> > Date: Thu, 12 Oct 2023 12:17:31 +1100
> > Subject: [PATCH] fix up for "drm: Add HPD state to
> > drm_connector_oob_hotplug_event()"
> >
> > interacting with commit
> >
> > 89434b069e46 ("usb: typec: altmodes/displayport: Signal hpd low when
> > exiting mode")
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/usb/typec/altmodes/displayport.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/typec/altmodes/displayport.c
> > b/drivers/usb/typec/altmodes/displayport.c
> > index ddfb5b6ace4f..eb0bf08fc97a 100644
> > --- a/drivers/usb/typec/altmodes/displayport.c
> > +++ b/drivers/usb/typec/altmodes/displayport.c
> > @@ -306,7 +306,8 @@ static int dp_altmode_vdm(struct typec_altmode *alt,
> > dp->data.status = 0;
> > dp->data.conf = 0;
> > if (dp->hpd) {
> > -
> > drm_connector_oob_hotplug_event(dp->connector_fwnode);
> > +
> > drm_connector_oob_hotplug_event(dp->connector_fwnode
>
> Pretend that there is a comma at the end of the above line :-)
>
> > +
> > connector_status_disconnected);
> > dp->hpd = false;
> > sysfs_notify(>alt->dev.kobj, "displayport",
> > "hpd");
> > }
> > --
> > 2.40.1
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpJDSwoFWoze.pgp
Description: OpenPGP digital signature
[pull] amdgpu drm-fixes-6.6
Hi Dave, Sima, Fixes for 6.6. The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb: Linux 6.6-rc6 (2023-10-15 13:34:39 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.6-2023-10-19 for you to fetch changes up to 316baf09d355aec1179981b6dfe28eba50c5ee5b: drm/amdgpu: Reserve fences for VM update (2023-10-19 18:56:57 -0400) amd-drm-fixes-6.6-2023-10-19: amdgpu: - Fix possible NULL pointer dereference - Avoid possible BUG_ON in GPUVM updates Felix Kuehling (2): drm/amdgpu: Fix possible null pointer dereference drm/amdgpu: Reserve fences for VM update drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++- 2 files changed, 6 insertions(+), 2 deletions(-)
Re: [PATCH 1/2] drm/ci: pick up -external-fixes from the merge target repo
On 08/10/2023 10:23, Dmitry Baryshkov wrote:
In case of the merge requests it might be useful to push repo-specific
fixes which have not yet propagated to the -external-fixes branch in the
main UPSTREAM_REPO. For example, in case of drm/msm development, we are
staging fixes locally for testing, before pushing them to the drm/drm
repo. Thus, if the CI run was triggered by merge request, also pick up
the -external fixes basing on the the CI_MERGE target repo / and branch.
Signed-off-by: Dmitry Baryshkov
Acked-by: Helen Koike
Thanks!
---
drivers/gpu/drm/ci/build.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 7b014287a041..20a6ba8a7b04 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -64,10 +64,15 @@ if [ "$(git ls-remote --exit-code --heads ${UPSTREAM_REPO}
${TARGET_BRANCH}-exte
fi
# Try to merge fixes from local repo if this isn't a merge request
+# otherwise try merging the fixes from the merge target
if [ -z "$CI_MERGE_REQUEST_PROJECT_PATH" ]; then
if [ "$(git ls-remote --exit-code --heads origin
${TARGET_BRANCH}-external-fixes)" ]; then
git pull origin ${TARGET_BRANCH}-external-fixes
fi
+else
+if [ "$(git ls-remote --exit-code --heads ${CI_MERGE_REQUEST_PROJECT_URL}
${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}-external-fixes)" ]; then
+git pull ${CI_MERGE_REQUEST_PROJECT_URL}
${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}-external-fixes
+fi
fi
for opt in $ENABLE_KCONFIGS; do
Re: [v4 3/3] arm64: defconfig: Enable ILITEK_ILI9882T panel
Hi On Fri, Oct 13, 2023 at 2:19 AM Cong Yang wrote: > > DRM_PANEL_ILITEK_ILI9882T is being split out from > DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE > panel driver enabled, let's also enable the Ilitek driver. > > Reviewed-by: Douglas Anderson > Signed-off-by: Cong Yang > --- > arch/arm64/configs/defconfig | 1 + > 1 file changed, 1 insertion(+) Pushed to drm-misc-next: c2635c0ec8b4 arm64: defconfig: Enable ILITEK_ILI9882T panel
Re: [v4 2/3] drm/panel: ili9882t: Avoid blurred screen from fast sleep
Hi, On Fri, Oct 13, 2023 at 2:43 PM Doug Anderson wrote: > > Hi, > > On Fri, Oct 13, 2023 at 2:19 AM Cong Yang > wrote: > > > > At present, we have found that there may be a problem of blurred > > screen during fast sleep/resume. The direct cause of the blurred > > screen is that the IC does not receive 0x28/0x10. Because of the > > particularity of the IC, before the panel enters sleep hid must > > stop scanning, as i2c_hid_core_suspend before ili9882t_disable. > > If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare, > > touch reset will pull low before panel entersleep, which does not meet > > the timing requirements.. So in order to solve this problem, the IC > > can handle it through the exception mechanism when it cannot receive > > 0x28/0x10 command. Handling exceptions requires a reset 50ms delay. > > Refer to vendor detailed analysis [1]. > > > > Ilitek vendor also suggested switching the page before entering sleep to > > avoid panel IC not receiving 0x28/0x10 command. > > > > Note: 0x28 is display off, 0x10 is sleep in. > > > > [1]: > > https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence > > > > Signed-off-by: Cong Yang > > --- > > drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 22 ++- > > 1 file changed, 21 insertions(+), 1 deletion(-) > > As talked about in response to the previous version [1], we can work > to see if we can improve the sequencing. However, for now this seems > fine. > > Reviewed-by: Douglas Anderson > > [1] > https://lore.kernel.org/r/CAD=FV=w_lt9mpykjakp3ovudenpszxkhvn9np_hq+es6fe3...@mail.gmail.com Pushed to drm-misc-next: 5820a1932ce8 drm/panel: ili9882t: Avoid blurred screen from fast sleep
Re: [v4 1/3] drm/panel: ili9882t: Break out as separate driver
Hi, On Fri, Oct 13, 2023 at 2:19 AM Cong Yang wrote: > > The Starry ILI9882t-based panel should never have been part of the boe > tv101wum driver, it is clearly based on the Ilitek ILI9882t display > controller and if you look at the custom command sequences for the > panel these clearly contain the signature Ilitek page switch (0xff) > commands. The hardware has nothing in common with the other panels > supported by this driver. > > Break this out into a separate driver and config symbol instead. > > If the placement here is out of convenience for using similar code, > we should consider creating a helper library instead. > > Co-developed-by: Linus Walleij > Signed-off-by: Linus Walleij > Reviewed-by: Linus Walleij > Reviewed-by: Douglas Anderson > Signed-off-by: Cong Yang > --- > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 371 - > drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 759 ++ > 4 files changed, 769 insertions(+), 371 deletions(-) > create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9882t.c Pushed to drm-misc-next: e2450d32e5fb drm/panel: ili9882t: Break out as separate driver
[RFC PATCH v2 17/17] drm/vkms: Add kunit tests for linear and sRGB LUTs
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 38 ++-
drivers/gpu/drm/vkms/vkms_composer.c | 13 +--
drivers/gpu/drm/vkms/vkms_composer.h | 14 +++
3 files changed, 52 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
index 843b2e1d607e..14decb5d1b64 100644
--- a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
@@ -5,6 +5,7 @@
#include
#include "../vkms_composer.h"
+#include "../vkms_luts.h"
#define TEST_LUT_SIZE 16
@@ -33,7 +34,6 @@ const struct vkms_color_lut test_linear_lut = {
.channel_value2index_ratio = 0xf000fll
};
-
static void vkms_color_test_get_lut_index(struct kunit *test)
{
int i;
@@ -42,6 +42,19 @@ static void vkms_color_test_get_lut_index(struct kunit *test)
for (i = 0; i < TEST_LUT_SIZE; i++)
KUNIT_EXPECT_EQ(test,
drm_fixp2int_ceil(get_lut_index(_linear_lut, test_linear_array[i].red)),
i);
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_eotf, 0x0)),
0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x0)), 0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x101)), 0x1);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x202)), 0x2);
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_inv_eotf, 0x0)),
0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_inv_eotf,
0x0)), 0x0);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_inv_eotf,
0x101)), 0x1);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_inv_eotf,
0x202)), 0x2);
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0xfefe)), 0xfe);
+ KUNIT_EXPECT_EQ(test, drm_fixp2int_ceil(get_lut_index(_eotf,
0x)), 0xff);
}
static void vkms_color_test_lerp(struct kunit *test)
@@ -49,9 +62,32 @@ static void vkms_color_test_lerp(struct kunit *test)
KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, 0x8000), 0x8);
}
+static void vkms_color_test_linear(struct kunit *test)
+{
+ for (int i = 0; i < LUT_SIZE; i++) {
+ int linear = apply_lut_to_channel_value(_eotf, i *
0x101, LUT_RED);
+ KUNIT_EXPECT_EQ(test, DIV_ROUND_CLOSEST(linear, 0x101), i);
+ }
+}
+
+static void vkms_color_srgb_inv_srgb(struct kunit *test)
+{
+ u16 srgb, final;
+
+ for (int i = 0; i < LUT_SIZE; i++) {
+ srgb = apply_lut_to_channel_value(_eotf, i * 0x101,
LUT_RED);
+ final = apply_lut_to_channel_value(_inv_eotf, srgb,
LUT_RED);
+
+ KUNIT_EXPECT_GE(test, final / 0x101, i-1);
+ KUNIT_EXPECT_LE(test, final / 0x101, i+1);
+ }
+}
+
static struct kunit_case vkms_color_test_cases[] = {
KUNIT_CASE(vkms_color_test_get_lut_index),
KUNIT_CASE(vkms_color_test_lerp),
+ KUNIT_CASE(vkms_color_test_linear),
+ KUNIT_CASE(vkms_color_srgb_inv_srgb),
{}
};
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 73b7d5e94021..24c984f2876f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -110,18 +110,7 @@ s64 get_lut_index(const struct vkms_color_lut *lut, u16
channel_value)
return drm_fixp_mul(color_channel_fp, lut->channel_value2index_ratio);
}
-/*
- * This enum is related to the positions of the variables inside
- * `struct drm_color_lut`, so the order of both needs to be the same.
- */
-enum lut_channel {
- LUT_RED = 0,
- LUT_GREEN,
- LUT_BLUE,
- LUT_RESERVED
-};
-
-static u16 apply_lut_to_channel_value(const struct vkms_color_lut *lut, u16
channel_value,
+u16 apply_lut_to_channel_value(const struct vkms_color_lut *lut, u16
channel_value,
enum lut_channel channel)
{
s64 lut_index = get_lut_index(lut, channel_value);
diff --git a/drivers/gpu/drm/vkms/vkms_composer.h
b/drivers/gpu/drm/vkms/vkms_composer.h
index 11c5de9cc961..d92497c555eb 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.h
+++ b/drivers/gpu/drm/vkms/vkms_composer.h
@@ -8,4 +8,18 @@
s64 get_lut_index(const struct vkms_color_lut *lut, u16 channel_value);
u16 lerp_u16(u16 a, u16 b, s64 t);
+/*
+ * This enum is related to the positions of the variables inside
+ * `struct drm_color_lut`, so the order of both needs to be the same.
+ */
+enum
[RFC PATCH v2 15/17] drm/colorop: Add NEXT to colorop state print
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_colorop.c | 42 +++
include/drm/drm_colorop.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 781bd3aa1849..cfe9199a15d2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -803,6 +803,7 @@ static void drm_atomic_colorop_print_state(struct
drm_printer *p,
drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
drm_printf(p, "\tbypass=%u\n", state->bypass);
drm_printf(p, "\tcurve_1d_type=%s\n",
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+ drm_printf(p, "\tnext=%d\n", drm_colorop_get_next_property(colorop));
}
static void drm_atomic_plane_print_state(struct drm_printer *p,
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 1afd5fbe8776..ff6f938cc28c 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -340,3 +340,45 @@ void drm_colorop_set_next_property(struct drm_colorop
*colorop, struct drm_color
next->base.id);
}
EXPORT_SYMBOL(drm_colorop_set_next_property);
+
+/**
+ * drm_colorop_set_next_property - gets the next colorop ID
+ * @colorop: drm colorop
+ *
+ * Returns:
+ * The DRM object ID of the next colorop
+ */
+uint32_t drm_colorop_get_next_property(struct drm_colorop *colorop)
+{
+ uint64_t next_id = 0;
+
+ if (!colorop->next_property)
+ return 0;
+
+ drm_object_property_get_value(>base,
+ colorop->next_property,
+ _id);
+
+ return (uint32_t) next_id;
+}
+EXPORT_SYMBOL(drm_colorop_get_next_property);
+
+
+/**
+ * drm_colorop_set_next_property - gets the next colorop ID
+ * @colorop: drm colorop
+ *
+ * Returns:
+ * The DRM object ID of the next colorop
+ */
+struct drm_colorop *drm_colorop_get_next(struct drm_colorop *colorop)
+{
+ uint64_t next_id = drm_colorop_get_next_property(colorop);
+
+ if (!next_id)
+ return NULL;
+
+ return drm_colorop_find(colorop->dev, NULL, next_id);
+
+}
+EXPORT_SYMBOL(drm_colorop_get_next);
\ No newline at end of file
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 622a671d2458..2ba506a0ea4d 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -228,6 +228,8 @@ const char *drm_get_colorop_type_name(enum drm_colorop_type
type);
const char *drm_get_colorop_curve_1d_type_name(enum drm_colorop_curve_1d_type
type);
void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next);
+uint32_t drm_colorop_get_next_property(struct drm_colorop *colorop);
+struct drm_colorop *drm_colorop_get_next(struct drm_colorop *colorop);
#endif /* __DRM_COLOROP_H__ */
--
2.42.0
[RFC PATCH v2 14/17] drm/plane: Add COLOR PIPELINE property
We're adding a new enum COLOR PIPELINE property. This
property will have entries for each COLOR PIPELINE by
referencing the DRM object ID of the first drm_colorop
of the pipeline. 0 disables the entire COLOR PIPELINE.
Userspace can use this to discover the available color
pipelines, as well as set the desired one. The color
pipelines are programmed via properties on the actual
drm_colorop objects.
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_atomic.c | 46 +++
drivers/gpu/drm/drm_atomic_state_helper.c | 5 +++
drivers/gpu/drm/drm_atomic_uapi.c | 44 ++
include/drm/drm_atomic_uapi.h | 2 +
include/drm/drm_plane.h | 8
5 files changed, 105 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 15bd18c9e2be..781bd3aa1849 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1472,6 +1472,52 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
*state,
}
EXPORT_SYMBOL(drm_atomic_add_affected_planes);
+/**
+ * drm_atomic_add_affected_colorops - add colorops for plane
+ * @state: atomic state
+ * @plane: DRM plane
+ *
+ * This function walks the current configuration and adds all colorops
+ * currently used by @plane to the atomic configuration @state. This is useful
+ * when an atomic commit also needs to check all currently enabled colorop on
+ * @plane, e.g. when changing the mode. It's also useful when re-enabling a
plane
+ * to avoid special code to force-enable all colorops.
+ *
+ * Since acquiring a colorop state will always also acquire the w/w mutex of
the
+ * current plane for that colorop (if there is any) adding all the colorop
states for
+ * a plane will not reduce parallelism of atomic updates.
+ *
+ * Returns:
+ * 0 on success or can fail with -EDEADLK or -ENOMEM. When the error is EDEADLK
+ * then the w/w mutex code has detected a deadlock and the entire atomic
+ * sequence must be restarted. All other errors are fatal.
+ */
+int
+drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
+struct drm_plane *plane)
+{
+ struct drm_colorop *colorop;
+ struct drm_colorop_state *colorop_state;
+
+ WARN_ON(!drm_atomic_get_new_plane_state(state, plane));
+
+ drm_dbg_atomic(plane->dev,
+ "Adding all current colorops for [plane:%d:%s] to %p\n",
+ plane->base.id, plane->name, state);
+
+ drm_for_each_colorop(colorop, plane->dev) {
+ if (colorop->plane != plane)
+ continue;
+
+ colorop_state = drm_atomic_get_colorop_state(state, colorop);
+ if (IS_ERR(colorop_state))
+ return PTR_ERR(colorop_state);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_add_affected_colorops);
+
/**
* drm_atomic_check_only - check whether a given config would work
* @state: atomic configuration to check
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 784e63d70a42..3c5f2c8e33d0 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -267,6 +267,11 @@ void __drm_atomic_helper_plane_state_reset(struct
drm_plane_state *plane_state,
plane_state->color_range = val;
}
+ if (plane->color_pipeline_property) {
+ /* default is always NULL, i.e., bypass */
+ plane_state->color_pipeline = NULL;
+ }
+
if (plane->zpos_property) {
if (!drm_object_property_get_default_value(>base,
plane->zpos_property,
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index a8f7a8a6639a..c6629fdaa114 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -256,6 +256,38 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state
*plane_state,
}
EXPORT_SYMBOL(drm_atomic_set_fb_for_plane);
+
+/**
+ * drm_atomic_set_colorop_for_plane - set colorop for plane
+ * @plane_state: atomic state object for the plane
+ * @colorop: colorop to use for the plane
+ *
+ * Changing the assigned framebuffer for a plane requires us to grab a
reference
+ * to the new fb and drop the reference to the old fb, if there is one. This
+ * function takes care of all these details besides updating the pointer in the
+ * state object itself.
+ */
+void
[RFC PATCH v2 12/17] drm/colorop: Add atomic state print for drm_colorop
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_atomic.c | 29 +
include/drm/drm_colorop.h| 5 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 524bec520287..15bd18c9e2be 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -792,6 +792,19 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
return 0;
}
+
+
+static void drm_atomic_colorop_print_state(struct drm_printer *p,
+ const struct drm_colorop_state *state)
+{
+ struct drm_colorop *colorop = state->colorop;
+
+ drm_printf(p, "colorop[%u]:\n", colorop->base.id);
+ drm_printf(p, "\ttype=%s\n", drm_get_colorop_type_name(colorop->type));
+ drm_printf(p, "\tbypass=%u\n", state->bypass);
+ drm_printf(p, "\tcurve_1d_type=%s\n",
drm_get_colorop_curve_1d_type_name(state->curve_1d_type));
+}
+
static void drm_atomic_plane_print_state(struct drm_printer *p,
const struct drm_plane_state *state)
{
@@ -812,6 +825,13 @@ static void drm_atomic_plane_print_state(struct
drm_printer *p,
drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
drm_get_color_range_name(state->color_range));
+#if 0
+ drm_printf(p, "\tcolor-pipeline=%s\n",
+ drm_get_color_pipeline_name(state->color_pipeline));
+#else
+ drm_printf(p, "\tcolor-pipeline=%d\n",
+ state->color_pipeline ? state->color_pipeline->base.id : 0);
+#endif
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
@@ -1848,6 +1868,7 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
bool take_locks)
{
struct drm_mode_config *config = >mode_config;
+ struct drm_colorop *colorop;
struct drm_plane *plane;
struct drm_crtc *crtc;
struct drm_connector *connector;
@@ -1856,6 +1877,14 @@ static void __drm_state_dump(struct drm_device *dev,
struct drm_printer *p,
if (!drm_drv_uses_atomic_modeset(dev))
return;
+ list_for_each_entry(colorop, >colorop_list, head) {
+ if (take_locks)
+ drm_modeset_lock(>plane->mutex, NULL);
+ drm_atomic_colorop_print_state(p, colorop->state);
+ if (take_locks)
+ drm_modeset_unlock(>plane->mutex);
+ }
+
list_for_each_entry(plane, >plane_list, head) {
if (take_locks)
drm_modeset_lock(>mutex, NULL);
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 1ddd0e65fe36..622a671d2458 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -222,6 +222,11 @@ static inline unsigned int drm_colorop_index(const struct
drm_colorop *colorop)
#define drm_for_each_colorop(colorop, dev) \
list_for_each_entry(colorop, &(dev)->mode_config.colorop_list, head)
+const char *drm_get_color_pipeline_name(struct drm_colorop *colorop);
+
+const char *drm_get_colorop_type_name(enum drm_colorop_type type);
+const char *drm_get_colorop_curve_1d_type_name(enum drm_colorop_curve_1d_type
type);
+
void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next);
--
2.42.0
[RFC PATCH v2 16/17] drm/vkms: Add enumerated 1D curve colorop
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 introduce a new vkms_luts.c file that hard-codes sRGB EOTF,
sRGB Inverse EOTF, and a linear EOTF LUT. These have been
generated with 256 entries each as IGT is currently testing
only 8 bpc surfaces. We will likely need higher precision
but I'm reluctant to make that change without clear indication
that we need it. We'll revisit and, if necessary, regenerate
the LUTs when we have IGT tests for higher precision buffers.
v2:
- Add commit description
- Fix sRGB EOTF LUT definition
- Add linear and sRGB inverse EOTF LUTs
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/vkms/Makefile| 4 +-
drivers/gpu/drm/vkms/vkms_colorop.c | 85 +++
drivers/gpu/drm/vkms/vkms_composer.c | 46 ++
drivers/gpu/drm/vkms/vkms_drv.h | 4 +
drivers/gpu/drm/vkms/vkms_luts.c | 802 +++
drivers/gpu/drm/vkms/vkms_luts.h | 12 +
drivers/gpu/drm/vkms/vkms_plane.c| 2 +
7 files changed, 954 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index d3440f228f46..eb208f3e6780 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -6,7 +6,9 @@ vkms-y := \
vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
- vkms_writeback.o
+ vkms_writeback.o \
+ vkms_colorop.o \
+ vkms_luts.o
obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_colorop.c
b/drivers/gpu/drm/vkms/vkms_colorop.c
new file mode 100644
index ..9a26b9fdc4a2
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_colorop.c
@@ -0,0 +1,85 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_COLOR_PIPELINES 5
+
+const int vkms_initialize_tf_pipeline(struct drm_plane *plane, struct
drm_prop_enum_list *list)
+{
+
+ struct drm_colorop *op, *prev_op;
+ struct drm_device *dev = plane->dev;
+ int ret;
+
+ /* 1st op: 1d curve */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_1D_CURVE);
+ if (ret)
+ return ret;
+
+ list->type = op->base.id;
+ list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", op->base.id);
+
+ prev_op = op;
+
+ /* 2nd op: 1d curve */
+ op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
+ if (!op) {
+ DRM_ERROR("KMS: Failed to allocate colorop\n");
+ return -ENOMEM;
+ }
+
+ ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_1D_CURVE);
+ if (ret)
+ return ret;
+
+ drm_colorop_set_next_property(prev_op, op);
+
+ return 0;
+}
+
+int vkms_initialize_colorops(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_property *prop;
+ struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
+ int len = 0;
+ int ret;
+
+ /* Add "Bypass" (i.e. NULL) pipeline */
+ pipelines[len].type = 0;
+ pipelines[len].name = "Bypass";
+ len++;
+
+ /* Add pipeline consisting of transfer functions */
+ ret = vkms_initialize_tf_pipeline(plane, &(pipelines[len]));
+ if (ret)
+ return ret;
+ len++;
+
+ /* Create COLOR_PIPELINE property and attach */
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
+ "COLOR_PIPELINE",
+ pipelines, len);
+ if (!prop)
+ return -ENOMEM;
+
+ plane->color_pipeline_property = prop;
+
+ drm_object_attach_property(>base, prop, 0);
+
+ /* TODO do we even need this? */
+ if (plane->state)
+ plane->state->color_pipeline = NULL;
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index cf1dff162920..73b7d5e94021 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++
[RFC PATCH v2 13/17] drm/colorop: Add new IOCTLs to retrieve drm_colorop objects
Since we created a new DRM object we need new IOCTLs (and
new libdrm functions) to retrieve those objects.
TODO: Can we make these IOCTLs and libdrm functions generic
to allow for new DRM objects in the future without the need
for new IOCTLs and libdrm functions?
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_colorop.c | 51 +
drivers/gpu/drm/drm_crtc_internal.h | 4 +++
drivers/gpu/drm/drm_ioctl.c | 5 +++
include/uapi/drm/drm_mode.h | 21
4 files changed, 81 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index bc1250718baf..1afd5fbe8776 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -32,6 +32,57 @@
/* TODO big colorop doc, including properties, etc. */
+/* IOCTLs */
+
+int drm_mode_getcolorop_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_colorop_res *colorop_resp = data;
+ struct drm_colorop *colorop;
+ uint32_t __user *colorop_ptr;
+ int count = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EOPNOTSUPP;
+
+ colorop_ptr = u64_to_user_ptr(colorop_resp->colorop_id_ptr);
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ drm_for_each_colorop(colorop, dev) {
+ if (drm_lease_held(file_priv, colorop->base.id)) {
+ if (count < colorop_resp->count_colorops &&
+ put_user(colorop->base.id, colorop_ptr + count))
+ return -EFAULT;
+ count++;
+ }
+ }
+ colorop_resp->count_colorops = count;
+
+ return 0;
+}
+
+int drm_mode_getcolorop(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_colorop *colorop_resp = data;
+ struct drm_colorop *colorop;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EOPNOTSUPP;
+
+ colorop = drm_colorop_find(dev, file_priv, colorop_resp->colorop_id);
+ if (!colorop)
+ return -ENOENT;
+
+ colorop_resp->colorop_id = colorop->base.id;
+ colorop_resp->plane_id = colorop->plane ? colorop->plane->base.id : 0;
+
+ return 0;
+}
+
static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
};
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 8556c3b3ff88..252cd7e607e3 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -278,6 +278,10 @@ int drm_mode_getplane(struct drm_device *dev,
void *data, struct drm_file *file_priv);
int drm_mode_setplane(struct drm_device *dev,
void *data, struct drm_file *file_priv);
+int drm_mode_getcolorop_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+int drm_mode_getcolorop(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
int drm_mode_cursor_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
int drm_mode_cursor2_ioctl(struct drm_device *dev,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 77590b0f38fa..8a4b7d8d8a0b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -717,6 +717,11 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl,
DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_REVOKE_LEASE, drm_mode_revoke_lease_ioctl,
DRM_MASTER),
+
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCOLOROPRESOURCES,
drm_mode_getcolorop_res, 0),
+ /* TODO do we need GETCOLOROP? */
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCOLOROP, drm_mode_getcolorop, 0),
+
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE(drm_ioctls)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 009a800676ac..5c71eb011181 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -357,6 +357,27 @@ struct drm_mode_get_plane {
__u64 format_type_ptr;
};
+struct drm_mode_get_colorop_res {
+ __u64
[RFC PATCH v2 11/17] drm/colorop: Add NEXT property
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
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_colorop.c | 27 +++
include/drm/drm_colorop.h | 12
2 files changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index ff6331fe5d5e..bc1250718baf 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -104,6 +104,15 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->curve_1d_type_property,
0);
+ prop = drm_property_create_object(dev, DRM_MODE_PROP_IMMUTABLE |
DRM_MODE_PROP_ATOMIC,
+ "NEXT", DRM_MODE_OBJECT_COLOROP);
+ if (!prop)
+ return -ENOMEM;
+ colorop->next_property = prop;
+ drm_object_attach_property(>base,
+ colorop->next_property,
+ 0);
+
return ret;
}
EXPORT_SYMBOL(drm_colorop_init);
@@ -262,3 +271,21 @@ const char *drm_get_colorop_curve_1d_type_name(enum
drm_colorop_curve_1d_type ty
return colorop_curve_1d_type_name[type];
}
+
+/**
+ * drm_colorop_set_next_property - sets the next pointer
+ * @colorop: drm colorop
+ * @next: next colorop
+ *
+ * Should be used when constructing the color pipeline
+ */
+void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next)
+{
+ if (!colorop->next_property)
+ return;
+
+ drm_object_property_set_value(>base,
+ colorop->next_property,
+ next->base.id);
+}
+EXPORT_SYMBOL(drm_colorop_set_next_property);
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 69636f6752a0..1ddd0e65fe36 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -162,10 +162,20 @@ struct drm_colorop {
*/
struct drm_property *curve_1d_type_property;
+ /**
+* @next_property
+*
+* Read-only property to next colorop in the pipeline
+*/
+ struct drm_property *next_property;
+
};
#define obj_to_colorop(x) container_of(x, struct drm_colorop, base)
+
+
+
/**
* drm_crtc_find - look up a Colorop object from its ID
* @dev: DRM device
@@ -212,5 +222,7 @@ static inline unsigned int drm_colorop_index(const struct
drm_colorop *colorop)
#define drm_for_each_colorop(colorop, dev) \
list_for_each_entry(colorop, &(dev)->mode_config.colorop_list, head)
+void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
drm_colorop *next);
+
#endif /* __DRM_COLOROP_H__ */
--
2.42.0
[RFC PATCH v2 10/17] drm/colorop: Add BYPASS property
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
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 +-
drivers/gpu/drm/drm_colorop.c | 15 +++
include/drm/drm_colorop.h | 20
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 52b9b48e5757..a8f7a8a6639a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -670,7 +670,9 @@ static int drm_atomic_colorop_set_property(struct
drm_colorop *colorop,
struct drm_colorop_state *state, struct drm_file *file_priv,
struct drm_property *property, uint64_t val)
{
- if (property == colorop->curve_1d_type_property) {
+ if (property == colorop->bypass_property) {
+ state->bypass = val;
+ } else if (property == colorop->curve_1d_type_property) {
state->curve_1d_type = val;
} else {
drm_dbg_atomic(colorop->dev,
@@ -690,6 +692,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
{
if (property == colorop->type_property) {
*val = colorop->type;
+ } else if (property == colorop->bypass_property) {
+ *val = state->bypass;
} else if (property == colorop->curve_1d_type_property) {
*val = state->curve_1d_type;
} else {
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 8d8f9461950f..ff6331fe5d5e 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -78,6 +78,18 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->type_property,
colorop->type);
+ /* bypass */
+ /* TODO can we reuse the mode_config->active_prop? */
+ prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
+ "BYPASS");
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->bypass_property = prop;
+ drm_object_attach_property(>base,
+ colorop->bypass_property,
+ 1);
+
/* curve_1d_type */
/* TODO move to mode_config? */
prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
@@ -100,6 +112,8 @@ void __drm_atomic_helper_colorop_duplicate_state(struct
drm_colorop *colorop,
struct drm_colorop_state
*state)
{
memcpy(state, colorop->state, sizeof(*state));
+
+ state->bypass = true;
}
struct drm_colorop_state *
@@ -164,6 +178,7 @@ void __drm_colorop_state_reset(struct drm_colorop_state
*colorop_state,
struct drm_colorop *colorop)
{
colorop_state->colorop = colorop;
+ colorop_state->bypass = true;
}
EXPORT_SYMBOL(__drm_colorop_state_reset);
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 7701b61ff7e9..69636f6752a0 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -48,6 +48,14 @@ struct drm_colorop_state {
/* colorop properties */
+ /**
+* @bypass:
+*
+* True if colorop shall be bypassed. False if colorop is
+* enabled.
+*/
+ bool bypass;
+
/**
* @curve_1d_type:
*
@@ -135,6 +143,18 @@ struct drm_colorop {
*/
struct drm_property *type_property;
+ /**
+* @bypass_property:
+*
+* Boolean property to control enablement of the color
+* operation. Setting bypass to "true" shall always be supported
+* in order to allow compositors to quickly fall back to
+* alternate methods of color processing. This is important
+* since setting color operations can fail due to unique
+* HW constraints.
+*/
+ struct drm_property *bypass_property;
+
/**
* @curve_1d_type:
*
--
2.42.0
[RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed
v2: - Update colorop visualizations to match reality (Sebastian, Alex Hung) - Updated wording (Pekka) - Change BYPASS wording to make it non-mandatory (Sebastian) - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property section (Pekka) - Use PQ EOTF instead of its inverse in Pipeline Programming example (Melissa) - Add "Driver Implementer's Guide" section (Pekka) - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka) Signed-off-by: Harry Wentland 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 Brekenfeld Cc: Sima Cc: Uma Shankar Cc: Naseer Ahmed Cc: Christopher Braga Cc: Abhinav Kumar Cc: Arthur Grillo Cc: Hector Martin Cc: Liviu Dudau Cc: Sasha McIntosh --- Documentation/gpu/rfc/color_pipeline.rst | 347 +++ 1 file changed, 347 insertions(+) create mode 100644 Documentation/gpu/rfc/color_pipeline.rst diff --git a/Documentation/gpu/rfc/color_pipeline.rst b/Documentation/gpu/rfc/color_pipeline.rst new file mode 100644 index ..af5f2ea29116 --- /dev/null +++ b/Documentation/gpu/rfc/color_pipeline.rst @@ -0,0 +1,347 @@ + +Linux Color Pipeline API + + +What problem are we solving? + + +We would like to support pre-, and post-blending complex color +transformations in display controller hardware in order to allow for +HW-supported HDR use-cases, as well as to provide support to +color-managed applications, such as video or image editors. + +It is possible to support an HDR output on HW supporting the Colorspace +and HDR Metadata drm_connector properties, but that requires the +compositor or application to render and compose the content into one +final buffer intended for display. Doing so is costly. + +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other +operations to support color transformations. These operations are often +implemented in fixed-function HW and therefore much more power efficient than +performing similar operations via shaders or CPU. + +We would like to make use of this HW functionality to support complex color +transformations with no, or minimal CPU or shader load. + + +How are other OSes solving this problem? + + +The most widely supported use-cases regard HDR content, whether video or +gaming. + +Most OSes will specify the source content format (color gamut, encoding transfer +function, and other metadata, such as max and average light levels) to a driver. +Drivers will then program their fixed-function HW accordingly to map from a +source content buffer's space to a display's space. + +When fixed-function HW is not available the compositor will assemble a shader to +ask the GPU to perform the transformation from the source content format to the +display's format. + +A compositor's mapping function and a driver's mapping function are usually +entirely separate concepts. On OSes where a HW vendor has no insight into +closed-source compositor code such a vendor will tune their color management +code to visually match the compositor's. On other OSes, where both mapping +functions are open to an implementer they will ensure both mappings match. + +This results in mapping algorithm lock-in, meaning that no-one alone can +experiment with or introduce new mapping algorithms and achieve +consistent results regardless of which implementation path is taken. + +Why is Linux different? +=== + +Unlike other OSes, where there is one compositor for one or more drivers, on +Linux we have a many-to-many relationship. Many compositors; many drivers. +In addition each compositor vendor or community has their own view of how +color management should be done. This is what makes Linux so beautiful. + +This means that a HW vendor can now no longer tune their driver to one +compositor, as tuning it to one could make it look fairly different from +another compositor's color mapping. + +We need a better solution. + + +Descriptive API +=== + +An API that describes the source and destination colorspaces is a descriptive +API. It describes the input and output color spaces but does not describe +how precisely they should be mapped. Such a mapping includes many minute +design decision that can greatly affect the look of the final result. + +It is not feasible to describe such mapping with enough detail to ensure the +same result from each implementation. In fact, these mappings are a very active +research area. + + +Prescriptive API + + +A prescriptive API describes not the source and destination colorspaces. It +instead prescribes a recipe for how to manipulate pixel values to arrive at the +desired outcome. + +This recipe is generally an
[RFC PATCH v2 09/17] drm/color: Add 1D Curve subtype
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_atomic_uapi.c | 18 ++
drivers/gpu/drm/drm_colorop.c | 39 +++
include/drm/drm_colorop.h | 20
3 files changed, 72 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index f22bd8671236..52b9b48e5757 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -670,11 +670,17 @@ static int drm_atomic_colorop_set_property(struct
drm_colorop *colorop,
struct drm_colorop_state *state, struct drm_file *file_priv,
struct drm_property *property, uint64_t val)
{
- drm_dbg_atomic(colorop->dev,
- "[COLOROP:%d] unknown property [PROP:%d:%s]]\n",
- colorop->base.id,
- property->base.id, property->name);
- return -EINVAL;
+ if (property == colorop->curve_1d_type_property) {
+ state->curve_1d_type = val;
+ } else {
+ drm_dbg_atomic(colorop->dev,
+ "[COLOROP:%d:%d] unknown property
[PROP:%d:%s]]\n",
+ colorop->base.id, colorop->type,
+ property->base.id, property->name);
+ return -EINVAL;
+ }
+
+ return 0;
}
static int
@@ -684,6 +690,8 @@ drm_atomic_colorop_get_property(struct drm_colorop *colorop,
{
if (property == colorop->type_property) {
*val = colorop->type;
+ } else if (property == colorop->curve_1d_type_property) {
+ *val = state->curve_1d_type;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 33e7dbf4dbe4..8d8f9461950f 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -36,6 +36,11 @@ static const struct drm_prop_enum_list
drm_colorop_type_enum_list[] = {
{ DRM_COLOROP_1D_CURVE, "1D Curve" },
};
+static const struct drm_prop_enum_list drm_colorop_curve_1d_type_enum_list[] =
{
+ { DRM_COLOROP_1D_CURVE_SRGB_EOTF, "sRGB EOTF" },
+ { DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF, "sRGB Inverse EOTF" },
+};
+
/* Init Helpers */
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
@@ -73,6 +78,20 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->type_property,
colorop->type);
+ /* curve_1d_type */
+ /* TODO move to mode_config? */
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
+ "CURVE_1D_TYPE",
+ drm_colorop_curve_1d_type_enum_list,
+
ARRAY_SIZE(drm_colorop_curve_1d_type_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->curve_1d_type_property = prop;
+ drm_object_attach_property(>base,
+ colorop->curve_1d_type_property,
+ 0);
+
return ret;
}
EXPORT_SYMBOL(drm_colorop_init);
@@ -194,6 +213,11 @@ static const char * const colorop_type_name[] = {
[DRM_COLOROP_1D_CURVE] = "1D Curve",
};
+static const char * const colorop_curve_1d_type_name[] = {
+ [DRM_COLOROP_1D_CURVE_SRGB_EOTF] = "sRGB EOTF",
+ [DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF] = "sRGB Inverse EOTF",
+};
+
/**
* drm_get_colorop_type_name - return a string for colorop type
* @range: colorop type to compute name of
@@ -208,3 +232,18 @@ const char *drm_get_colorop_type_name(enum
drm_colorop_type type)
return colorop_type_name[type];
}
+
+/**
+ * drm_get_colorop_curve_1d_type_name - return a string for 1D curve type
+ * @range: 1d curve type to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorop_curve_1d_type_name(enum drm_colorop_curve_1d_type
type)
+{
+ if (WARN_ON(type >= ARRAY_SIZE(colorop_curve_1d_type_name)))
+ return "unknown";
+
+ return colorop_curve_1d_type_name[type];
+}
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 22a217372428..7701b61ff7e9 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -34,6 +34,11 @@ enum drm_colorop_type {
DRM_COLOROP_1D_CURVE
[RFC PATCH v2 04/17] drm/vkms: Add kunit tests for VKMS LUT handling
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: 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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/vkms/Kconfig | 5 ++
drivers/gpu/drm/vkms/Makefile | 2 +
drivers/gpu/drm/vkms/tests/.kunitconfig | 4 ++
drivers/gpu/drm/vkms/tests/Makefile | 4 ++
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 64 +++
drivers/gpu/drm/vkms/vkms_composer.c | 4 +-
drivers/gpu/drm/vkms/vkms_composer.h | 11
7 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
create mode 100644 drivers/gpu/drm/vkms/tests/Makefile
create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
create mode 100644 drivers/gpu/drm/vkms/vkms_composer.h
diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
index 1816562381a2..372cc5fa92f1 100644
--- a/drivers/gpu/drm/vkms/Kconfig
+++ b/drivers/gpu/drm/vkms/Kconfig
@@ -13,3 +13,8 @@ config DRM_VKMS
a VKMS.
If M is selected the module will be called vkms.
+
+config DRM_VKMS_KUNIT_TESTS
+ tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
+ depends on DRM_VKMS && KUNIT
+ default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 1b28a6a32948..d3440f228f46 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -9,3 +9,5 @@ vkms-y := \
vkms_writeback.o
obj-$(CONFIG_DRM_VKMS) += vkms.o
+
+obj-y += tests/
\ No newline at end of file
diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig
b/drivers/gpu/drm/vkms/tests/.kunitconfig
new file mode 100644
index ..70e378228cbd
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_VKMS=y
+CONFIG_DRM_VKMS_KUNIT_TESTS=y
diff --git a/drivers/gpu/drm/vkms/tests/Makefile
b/drivers/gpu/drm/vkms/tests/Makefile
new file mode 100644
index ..761465332ff2
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += \
+ vkms_color_tests.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
new file mode 100644
index ..843b2e1d607e
--- /dev/null
+++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#include
+
+#include
+
+#include "../vkms_composer.h"
+
+#define TEST_LUT_SIZE 16
+
+static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
+ { 0x0, 0x0, 0x0, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+ { 0x, 0x, 0x, 0 },
+};
+
+const struct vkms_color_lut test_linear_lut = {
+ .base = test_linear_array,
+ .lut_length = TEST_LUT_SIZE,
+ .channel_value2index_ratio = 0xf000fll
+};
+
+
+static void vkms_color_test_get_lut_index(struct kunit *test)
+{
+ int i;
+
+ KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_linear_lut,
test_linear_array[0].red)), 0);
+
+ for (i = 0; i < TEST_LUT_SIZE; i++)
+ KUNIT_EXPECT_EQ(test,
drm_fixp2int_ceil(get_lut_index(_linear_lut, test_linear_array[i].red)),
i);
+}
+
+static void vkms_color_test_lerp(struct kunit *test)
+{
+ KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, 0x8000), 0x8);
+}
+
+static struct kunit_case vkms_color_test_cases[] = {
+ KUNIT_CASE(vkms_color_test_get_lut_index),
+ KUNIT_CASE(vkms_color_test_lerp),
+ {}
+};
+
+static struct kunit_suite vkms_color_test_suite = {
+ .name = "vkms-color",
+ .test_cases = vkms_color_test_cases,
+};
+kunit_test_suite(vkms_color_test_suite);
+
+MODULE_LICENSE("GPL");
\ No newline at end of file
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 3c99fb8b54e2..a0a3a6fd2926 100644
---
[RFC PATCH v2 07/17] drm/colorop: Introduce new drm_colorop mode object
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
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_atomic.c| 79 +
drivers/gpu/drm/drm_atomic_helper.c | 12 ++
drivers/gpu/drm/drm_atomic_uapi.c | 48
drivers/gpu/drm/drm_colorop.c | 169
drivers/gpu/drm/drm_mode_config.c | 7 ++
drivers/gpu/drm/drm_plane_helper.c | 2 +-
include/drm/drm_atomic.h| 82 ++
include/drm/drm_atomic_uapi.h | 1 +
include/drm/drm_colorop.h | 157 ++
include/drm/drm_mode_config.h | 18 +++
include/drm/drm_plane.h | 2 +
include/uapi/drm/drm.h | 3 +
include/uapi/drm/drm_mode.h | 1 +
14 files changed, 581 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_colorop.c
create mode 100644 include/drm/drm_colorop.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8e1bde059170..7ba67f9775e7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,6 +16,7 @@ drm-y := \
drm_client.o \
drm_client_modeset.o \
drm_color_mgmt.o \
+ drm_colorop.o \
drm_connector.o \
drm_crtc.o \
drm_displayid.o \
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f1a503aafe5a..d55db5a06940 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -108,6 +109,7 @@ void drm_atomic_state_default_release(struct
drm_atomic_state *state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+ kfree(state->colorops);
kfree(state->private_objs);
}
EXPORT_SYMBOL(drm_atomic_state_default_release);
@@ -139,6 +141,10 @@ drm_atomic_state_init(struct drm_device *dev, struct
drm_atomic_state *state)
sizeof(*state->planes), GFP_KERNEL);
if (!state->planes)
goto fail;
+ state->colorops = kcalloc(dev->mode_config.num_colorop,
+ sizeof(*state->colorops), GFP_KERNEL);
+ if (!state->colorops)
+ goto fail;
/*
* Because drm_atomic_state can be committed asynchronously we need our
@@ -250,6 +256,20 @@ void drm_atomic_state_default_clear(struct
drm_atomic_state *state)
state->planes[i].new_state = NULL;
}
+ for (i = 0; i < config->num_colorop; i++) {
+ struct drm_colorop *colorop = state->colorops[i].ptr;
+
+ if (!colorop)
+ continue;
+
+ drm_colorop_atomic_destroy_state(colorop,
+state->colorops[i].state);
+ state->colorops[i].ptr = NULL;
+ state->colorops[i].state = NULL;
+ state->colorops[i].old_state = NULL;
+ state->colorops[i].new_state = NULL;
+ }
+
for (i = 0; i < state->num_private_objs; i++) {
struct drm_private_obj *obj = state->private_objs[i].ptr;
@@ -571,6 +591,65 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_plane_state);
+
+/**
+ * drm_atomic_get_colorop_state - get colorop state
+ * @state: global atomic state object
+ * @colorop: colorop to get state object for
+ *
+ * This function returns the colorop state for the given colorop, allocating it
+ * if needed. It will also grab the relevant plane lock to make sure that the
+ * state is consistent.
+ *
+ * Returns:
+ *
+ * Either the allocated state or the error code encoded into the pointer. When
+ * the error is EDEADLK then the w/w mutex code has detected a deadlock and the
+ * entire atomic sequence must be restarted. All other errors are fatal.
+ */
+struct drm_colorop_state *
+drm_atomic_get_colorop_state(struct drm_atomic_state *state,
+struct drm_colorop *colorop)
+{
+ int ret, index = drm_colorop_index(colorop);
+ struct drm_colorop_state *colorop_state;
+ struct drm_plane_state *plane_state;
+
+ WARN_ON(!state->acquire_ctx);
+
+ colorop_state =
[RFC PATCH v2 05/17] drm/vkms: Avoid reading beyond LUT array
When the floor LUT index (drm_fixp2int(lut_index) is the last
index of the array the ceil LUT index will point to an entry
beyond the array. Make sure we guard against it and use the
value of the floot LUT index.
Blurb about LUT creation and how first element should be 0x0 and
last one 0x.
Hold on, is that even correct? What should the ends of a LUT be?
How does UNORM work and how does it apply to LUTs?
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/vkms/vkms_composer.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index a0a3a6fd2926..cf1dff162920 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -123,6 +123,8 @@ static u16 apply_lut_to_channel_value(const struct
vkms_color_lut *lut, u16 chan
enum lut_channel channel)
{
s64 lut_index = get_lut_index(lut, channel_value);
+ u16 *floor_lut_value, *ceil_lut_value;
+ u16 floor_channel_value, ceil_channel_value;
/*
* This checks if `struct drm_color_lut` has any gap added by the
compiler
@@ -130,11 +132,15 @@ static u16 apply_lut_to_channel_value(const struct
vkms_color_lut *lut, u16 chan
*/
static_assert(sizeof(struct drm_color_lut) == sizeof(__u16) * 4);
- u16 *floor_lut_value = (__u16 *)>base[drm_fixp2int(lut_index)];
- u16 *ceil_lut_value = (__u16 *)>base[drm_fixp2int_ceil(lut_index)];
+ floor_lut_value = (__u16 *)>base[drm_fixp2int(lut_index)];
+ if (drm_fixp2int(lut_index) == (lut->lut_length - 1))
+ /* We're at the end of the LUT array, use same value for ceil
and floor */
+ ceil_lut_value = floor_lut_value;
+ else
+ ceil_lut_value = (__u16
*)>base[drm_fixp2int_ceil(lut_index)];
- u16 floor_channel_value = floor_lut_value[channel];
- u16 ceil_channel_value = ceil_lut_value[channel];
+ floor_channel_value = floor_lut_value[channel];
+ ceil_channel_value = ceil_lut_value[channel];
return lerp_u16(floor_channel_value, ceil_channel_value,
lut_index & DRM_FIXED_DECIMAL_MASK);
--
2.42.0
[RFC PATCH v2 08/17] drm/colorop: Add TYPE property
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
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_atomic.c | 4 +--
drivers/gpu/drm/drm_atomic_uapi.c | 8 +-
drivers/gpu/drm/drm_colorop.c | 43 ++-
include/drm/drm_colorop.h | 21 ++-
4 files changed, 71 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index d55db5a06940..524bec520287 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -636,8 +636,8 @@ drm_atomic_get_colorop_state(struct drm_atomic_state *state,
state->colorops[index].new_state = colorop_state;
colorop_state->state = state;
- drm_dbg_atomic(colorop->dev, "Added [COLOROP:%d] %p state to %p\n",
- colorop->base.id, colorop_state, state);
+ drm_dbg_atomic(colorop->dev, "Added [COLOROP:%d:%d] %p state to %p\n",
+ colorop->base.id, colorop->type, colorop_state, state);
/* TODO is this necessary? */
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 21da1b327ee9..f22bd8671236 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -682,7 +682,13 @@ drm_atomic_colorop_get_property(struct drm_colorop
*colorop,
const struct drm_colorop_state *state,
struct drm_property *property, uint64_t *val)
{
- return -EINVAL;
+ if (property == colorop->type_property) {
+ *val = colorop->type;
+ } else {
+ return -EINVAL;
+ }
+
+ return 0;
}
static int drm_atomic_set_writeback_fb_for_connector(
diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
index 78d6a0067f5b..33e7dbf4dbe4 100644
--- a/drivers/gpu/drm/drm_colorop.c
+++ b/drivers/gpu/drm/drm_colorop.c
@@ -32,12 +32,17 @@
/* TODO big colorop doc, including properties, etc. */
+static const struct drm_prop_enum_list drm_colorop_type_enum_list[] = {
+ { DRM_COLOROP_1D_CURVE, "1D Curve" },
+};
+
/* Init Helpers */
int drm_colorop_init(struct drm_device *dev, struct drm_colorop *colorop,
-struct drm_plane *plane)
+struct drm_plane *plane, enum drm_colorop_type type)
{
struct drm_mode_config *config = >mode_config;
+ struct drm_property *prop;
int ret = 0;
ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_COLOROP);
@@ -46,12 +51,28 @@ int drm_colorop_init(struct drm_device *dev, struct
drm_colorop *colorop,
colorop->base.properties = >properties;
colorop->dev = dev;
+ colorop->type = type;
colorop->plane = plane;
list_add_tail(>head, >colorop_list);
colorop->index = config->num_colorop++;
/* add properties */
+
+ /* type */
+ prop = drm_property_create_enum(dev,
+ DRM_MODE_PROP_IMMUTABLE |
DRM_MODE_PROP_ATOMIC,
+ "TYPE", drm_colorop_type_enum_list,
+ ARRAY_SIZE(drm_colorop_type_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ colorop->type_property = prop;
+
+ drm_object_attach_property(>base,
+ colorop->type_property,
+ colorop->type);
+
return ret;
}
EXPORT_SYMBOL(drm_colorop_init);
@@ -167,3 +188,23 @@ void drm_colorop_reset(struct drm_colorop *colorop)
__drm_colorop_reset(colorop, colorop->state);
}
EXPORT_SYMBOL(drm_colorop_reset);
+
+
+static const char * const colorop_type_name[] = {
+ [DRM_COLOROP_1D_CURVE] = "1D Curve",
+};
+
+/**
+ * drm_get_colorop_type_name - return a string for colorop type
+ * @range: colorop type to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorop_type_name(enum drm_colorop_type type)
+{
+ if (WARN_ON(type >= ARRAY_SIZE(colorop_type_name)))
+ return "unknown";
+
+ return colorop_type_name[type];
+}
diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
index 3dd169b0317d..22a217372428 100644
--- a/include/drm/drm_colorop.h
+++ b/include/drm/drm_colorop.h
@@ -30,6
[RFC PATCH v2 01/17] drm/atomic: Allow get_value for immutable properties on atomic drivers
drm_colorops use immutable properties, for type and next.
Even though drivers create these properties at initialization
they will need to look at the properties when parsing a
color pipeline for programming during an atomic check
or commit operation.
This aligns the get_value call with behavior of the set_value
call.
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
drivers/gpu/drm/drm_mode_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index ac0d2ce3f870..c9b1cd48547a 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -351,7 +351,8 @@ static int __drm_object_property_get_value(struct
drm_mode_object *obj,
int drm_object_property_get_value(struct drm_mode_object *obj,
struct drm_property *property, uint64_t *val)
{
- WARN_ON(drm_drv_uses_atomic_modeset(property->dev));
+ WARN_ON(drm_drv_uses_atomic_modeset(property->dev) &&
+ !(property->flags & DRM_MODE_PROP_IMMUTABLE));
return __drm_object_property_get_value(obj, property, val);
}
--
2.42.0
[RFC PATCH v2 02/17] drm: Don't treat 0 as -1 in drm_fixp2int_ceil
Unit testing this in VKMS shows that passing 0 into
this function returns -1, which is highly counter-
intuitive. Fix it by checking whether the input is
>= 0 instead of > 0.
Signed-off-by: Harry Wentland
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 Brekenfeld
Cc: Sima
Cc: Uma Shankar
Cc: Naseer Ahmed
Cc: Christopher Braga
Cc: Abhinav Kumar
Cc: Arthur Grillo
Cc: Hector Martin
Cc: Liviu Dudau
Cc: Sasha McIntosh
---
include/drm/drm_fixed.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 6ea339d5de08..0c9f917a4d4b 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -95,7 +95,7 @@ static inline int drm_fixp2int_round(s64 a)
static inline int drm_fixp2int_ceil(s64 a)
{
- if (a > 0)
+ if (a >= 0)
return drm_fixp2int(a + DRM_FIXED_ALMOST_ONE);
else
return drm_fixp2int(a - DRM_FIXED_ALMOST_ONE);
--
2.42.0
[RFC PATCH v2 03/17] drm/vkms: Create separate Kconfig file for VKMS
This aligns with most other DRM drivers and will allow us to add new VKMS config options without polluting the DRM Kconfig. Signed-off-by: Harry Wentland 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 Brekenfeld Cc: Sima Cc: Uma Shankar Cc: Naseer Ahmed Cc: Christopher Braga Cc: Abhinav Kumar Cc: Arthur Grillo Cc: Hector Martin Cc: Liviu Dudau Cc: Sasha McIntosh --- drivers/gpu/drm/Kconfig | 14 +- drivers/gpu/drm/vkms/Kconfig | 15 +++ 2 files changed, 16 insertions(+), 13 deletions(-) create mode 100644 drivers/gpu/drm/vkms/Kconfig diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 48ca28a2e4ff..61ebd682c9b0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -286,19 +286,7 @@ config DRM_VGEM as used by Mesa's software renderer for enhanced performance. If M is selected the module will be called vgem. -config DRM_VKMS - tristate "Virtual KMS (EXPERIMENTAL)" - depends on DRM && MMU - select DRM_KMS_HELPER - select DRM_GEM_SHMEM_HELPER - select CRC32 - default n - help - Virtual Kernel Mode-Setting (VKMS) is used for testing or for - running GPU in a headless machines. Choose this option to get - a VKMS. - - If M is selected the module will be called vkms. +source "drivers/gpu/drm/vkms/Kconfig" source "drivers/gpu/drm/exynos/Kconfig" diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig new file mode 100644 index ..1816562381a2 --- /dev/null +++ b/drivers/gpu/drm/vkms/Kconfig @@ -0,0 +1,15 @@ +# SPDX-License-Identifier: GPL-2.0+ + +config DRM_VKMS + tristate "Virtual KMS (EXPERIMENTAL)" + depends on DRM && MMU + select DRM_KMS_HELPER + select DRM_GEM_SHMEM_HELPER + select CRC32 + default n + help + Virtual Kernel Mode-Setting (VKMS) is used for testing or for + running GPU in a headless machines. Choose this option to get + a VKMS. + + If M is selected the module will be called vkms. -- 2.42.0
[RFC PATCH v2 00/17] Color Pipeline API w/ VKMS
This is an early RFC set for a color pipeline API, along with a sample implementation in VKMS. All the key API bits are here. VKMS now supports two named transfer function colorops and we have an IGT test that confirms that sRGB EOTF, followed by its inverse gives us expected results within +/- 1 8 bpc codepoint value. This patchset is grouped as follows: - Patches 1-2: couple general patches/fixes - Patches 3-5: introduce kunit to VKMS - Patch 6: description of motivation and details behind the Color Pipeline API. If you're reading nothing else but are interested in the topic I highly recommend you take a look at this. - Patches 7-15: Add core DRM API bits - Patches 15-17: VKMS implementation There are plenty of things that I would like to see here but haven't had a chance to look at. These will (hopefully) be addressed in future iterations: - Abandon IOCTLs and discover colorops as clients iterate the pipeline - Add color_pipeline client cap and deprecate existing color encoding and color range properties. See https://lists.freedesktop.org/archives/dri-devel/2023-September/422643.html - Add CTM colorop to VKMS - Add custom LUT colorops to VKMS - Add pre-blending 3DLUT with tetrahedral interpolation to VKMS - How to support HW which can't bypass entire pipeline? - Add ability to create colorops that don't have BYPASS - Can we do a LOAD / COMMIT model for LUTs (and other properties)? IGT tests can be found at https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1 IGT patches are also being sent to the igt-dev mailing list. libdrm changes to support the new IOCTLs are at https://gitlab.freedesktop.org/hwentland/drm/-/merge_requests/1 If you prefer a gitlab MR for review you can find it at https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5 A slightly different approach for a Color Pipeline API was sent by Uma Shankar and can be found at https://patchwork.freedesktop.org/series/123024/ The main difference is that his approach is not introducing a new DRM core object but instead exposes color pipelines via blob properties. There are pros and cons to both approaches. v2: - Rebased on drm-misc-next - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer - Incorporate feedback in color_pipeline.rst doc - Add support for sRGB inverse EOTF - Add 2nd enumerated TF colorop to VKMS - Fix LUTs and 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 Brekenfeld Cc: Sima Cc: Uma Shankar Cc: Naseer Ahmed Cc: Christopher Braga Cc: Abhinav Kumar Cc: Arthur Grillo Cc: Hector Martin Cc: Liviu Dudau Cc: Sasha McIntosh Harry Wentland (17): drm/atomic: Allow get_value for immutable properties on atomic drivers drm: Don't treat 0 as -1 in drm_fixp2int_ceil drm/vkms: Create separate Kconfig file for VKMS drm/vkms: Add kunit tests for VKMS LUT handling drm/vkms: Avoid reading beyond LUT array drm/doc/rfc: Describe why prescriptive color pipeline is needed drm/colorop: Introduce new drm_colorop mode object drm/colorop: Add TYPE property drm/color: Add 1D Curve subtype drm/colorop: Add BYPASS property drm/colorop: Add NEXT property drm/colorop: Add atomic state print for drm_colorop drm/colorop: Add new IOCTLs to retrieve drm_colorop objects drm/plane: Add COLOR PIPELINE property drm/colorop: Add NEXT to colorop state print drm/vkms: Add enumerated 1D curve colorop drm/vkms: Add kunit tests for linear and sRGB LUTs Documentation/gpu/rfc/color_pipeline.rst | 347 drivers/gpu/drm/Kconfig | 14 +- drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_atomic.c | 155 drivers/gpu/drm/drm_atomic_helper.c | 12 + drivers/gpu/drm/drm_atomic_state_helper.c | 5 + drivers/gpu/drm/drm_atomic_uapi.c | 110 +++ drivers/gpu/drm/drm_colorop.c | 384 + drivers/gpu/drm/drm_crtc_internal.h | 4 + drivers/gpu/drm/drm_ioctl.c | 5 + drivers/gpu/drm/drm_mode_config.c | 7 + drivers/gpu/drm/drm_mode_object.c | 3 +- drivers/gpu/drm/drm_plane_helper.c| 2 +- drivers/gpu/drm/vkms/Kconfig | 20 + drivers/gpu/drm/vkms/Makefile | 6 +- drivers/gpu/drm/vkms/tests/.kunitconfig | 4 + drivers/gpu/drm/vkms/tests/Makefile | 4 + drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 100 +++ drivers/gpu/drm/vkms/vkms_colorop.c | 85 ++ drivers/gpu/drm/vkms/vkms_composer.c | 77 +- drivers/gpu/drm/vkms/vkms_composer.h | 25 + drivers/gpu/drm/vkms/vkms_drv.h | 4 +
Re: [Intel-gfx] [PATCH 3/3] drm/i915/mtl: Add counters for engine busyness ticks
On 10/19/2023 09:21, Dong, Zhanjun wrote:
See comments inline below.
Zhanjun
On 2023-09-22 6:25 p.m., john.c.harri...@intel.com wrote:
From: Umesh Nerlige Ramappa
In new version of GuC engine busyness, GuC provides engine busyness
ticks as a 64 bit counter. Add a new counter to relay this value to the
user as is.
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 12
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 ++-
drivers/gpu/drm/i915/i915_pmu.c | 25 ++-
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
include/uapi/drm/i915_drm.h | 13 +++-
8 files changed, 116 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index b58c30ac8ef02..57af7ec8ecd82 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -249,6 +249,7 @@ void intel_engine_dump_active_requests(struct
list_head *requests,
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now);
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine);
void intel_engine_get_hung_entity(struct intel_engine_cs *engine,
struct intel_context **ce, struct i915_request
**rq);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 84a75c95f3f7d..1c9ffb1ae9889 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2426,6 +2426,22 @@ ktime_t intel_engine_get_busy_time(struct
intel_engine_cs *engine, ktime_t *now)
return engine->busyness(engine, now);
}
+/**
+ * intel_engine_get_busy_ticks() - Return current accumulated engine
busyness
+ * ticks
+ * @engine: engine to report on
+ *
+ * Returns accumulated ticks @engine was busy since engine stats
were enabled.
+ */
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine)
+{
+ if (!engine->busyness_ticks ||
+ !(engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS))
+ return 0;
+
+ return engine->busyness_ticks(engine);
+}
+
struct intel_context *
intel_engine_create_virtual(struct intel_engine_cs **siblings,
unsigned int count, unsigned long flags)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 40fd8f984d64b..a88d40c74d604 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -548,6 +548,11 @@ struct intel_engine_cs {
ktime_t (*busyness)(struct intel_engine_cs *engine,
ktime_t *now);
+ /*
+ * Get engine busyness ticks
+ */
+ u64 (*busyness_ticks)(struct intel_engine_cs *engine);
+
struct intel_engine_execlists execlists;
/*
@@ -574,6 +579,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_EU_PRIORITY BIT(10)
#define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
#define I915_ENGINE_USES_WA_HOLD_CCS_SWITCHOUT BIT(12)
+#define I915_ENGINE_SUPPORTS_TICKS_STATS BIT(13)
unsigned int flags;
/*
@@ -649,6 +655,12 @@ intel_engine_supports_stats(const struct
intel_engine_cs *engine)
return engine->flags & I915_ENGINE_SUPPORTS_STATS;
}
+static inline bool
+intel_engine_supports_tick_stats(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS;
+}
+
static inline bool
intel_engine_has_preemption(const struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index dcedff41a825f..69eb610b5ab0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -100,6 +100,7 @@ static void set_scheduler_caps(struct
drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+ MAP(SUPPORTS_TICKS_STATS, ENGINE_BUSY_TICKS_STATS),
#undef MAP
};
struct intel_engine_cs *engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0c1fee5360777..71749fb9ad35b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1289,12 +1289,7 @@ static void
busy_v1_guc_update_pm_timestamp(struct intel_guc *guc, ktime_t *now)
guc->busy.v1.gt_stamp = ((u64)gt_stamp_hi << 32) | gt_stamp_lo;
}
-/*
- * Unlike the execlist mode of submission total and active times are
in terms of
- * gt clocks. The *now parameter
Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023
Hey Chris, Am Donnerstag, 19. Oktober 2023, 16:43:56 CEST schrieb Chris Morgan: > On Thu, Oct 19, 2023 at 11:21:47AM +0200, Krzysztof Kozlowski wrote: > > On 18/10/2023 18:18, Chris Morgan wrote: > > > From: Chris Morgan > > > > > > The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and > > > powered by the Rockchip RK3566 SoC. > > > > > > Signed-off-by: Chris Morgan > > > --- > > > Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml > > > b/Documentation/devicetree/bindings/arm/rockchip.yaml > > > index a349bf4da6bc..a6612185a7ff 100644 > > > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml > > > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > > > @@ -674,6 +674,11 @@ properties: > > >- const: powkiddy,rgb30 > > >- const: rockchip,rk3566 > > > > > > + - description: Powkiddy RK2023 > > > +items: > > > + - const: powkiddy,rk2023 > > > > This cuold be just enum in previous entry :/ but I remember we talked > > about this once with Heiko. > > For hardware that requires a different device tree, is that possible? > While most of the devices I've worked on for the RK3566 series are very > similar for the moment only 1 is identical (the RG353P and the RG353M) > and can use the same device tree. In my reply I pointed to the Rock PI 4A/4A+/B/B+/C family, which also has different devicetrees but is part of the same family of device designs. So similar Powkiddy RK3568 based gaming handhelds also sound like a nice family name in the description ;-) . Heiko
Re: [PATCH 2/5] drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support
On 10/18/2023 9:18 AM, Chris Morgan wrote:
From: Chris Morgan
Refactor the driver to add support for the powkiddy,rk2023-panel
panel. This panel is extremely similar to the rg353p-panel but
requires a smaller vertical back porch and isn't as tolerant of
higher speeds.
Tested on my RG351V, RG353P, RG353V, and RK2023.
Signed-off-by: Chris Morgan
Hi Chris,
Thanks for the patch. Just have a minor question below.
---
.../gpu/drm/panel/panel-newvision-nv3051d.c | 56 +++
1 file changed, 45 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index 79de6c886292..d24c51503d68 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+ u32 mode_flags;
};
struct panel_nv3051d {
@@ -385,15 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
-
- /*
-* The panel in the RG351V is identical to the 353P, except it
-* requires MIPI_DSI_CLOCK_NON_CONTINUOUS to operate correctly.
-*/
- if (of_device_is_compatible(dev->of_node, "anbernic,rg351v-panel"))
- dsi->mode_flags |= MIPI_DSI_CLOCK_NON_CONTINUOUS;
+ dsi->mode_flags = ctx->panel_info->mode_flags;
drm_panel_init(>panel, >dev, _nv3051d_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -481,18 +474,59 @@ static const struct drm_display_mode
nv3051d_rgxx3_modes[] = {
},
};
-static const struct nv3051d_panel_info nv3051d_rgxx3_info = {
+static const struct drm_display_mode nv3051d_rk2023_modes[] = {
+ {
+ .hdisplay = 640,
+ .hsync_start= 640 + 40,
+ .hsync_end = 640 + 40 + 2,
+ .htotal = 640 + 40 + 2 + 80,
+ .vdisplay = 480,
+ .vsync_start= 480 + 18,
+ .vsync_end = 480 + 18 + 2,
+ .vtotal = 480 + 18 + 2 + 4,
+ .clock = 24150,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+ },
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
.display_modes = nv3051d_rgxx3_modes,
.num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg353p_info = {
+ .display_modes = nv3051d_rgxx3_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+ .width_mm = 70,
+ .height_mm = 57,
Will all the panels for this driver be 70x57? If so, would it be better
to set display_info.[width_mm|height_mm] directly?
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rk2023_info = {
+ .display_modes = nv3051d_rk2023_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rk2023_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
};
static const struct of_device_id newvision_nv3051d_of_match[] = {
- { .compatible = "newvision,nv3051d", .data = _rgxx3_info },
+ { .compatible = "anbernic,rg351v-panel", .data = _rg351v_info },
+ { .compatible = "anbernic,rg353p-panel", .data = _rg353p_info },
+ { .compatible = "powkiddy,rk2023-panel", .data = _rk2023_info },
{ /* sentinel */ }
};
+
I think you can drop this stray newline.
Thanks,
Jessica Zhang
MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
static struct mipi_dsi_driver newvision_nv3051d_driver = {
--
2.34.1
Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item
On Wed, Oct 18, 2023 at 09:25:36PM -0400, Luben Tuikov wrote:
> Hi,
>
> On 2023-10-17 11:09, Matthew Brost wrote:
> > Rather than call free_job and run_job in same work item have a dedicated
> > work item for each. This aligns with the design and intended use of work
> > queues.
> >
> > v2:
> >- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
> > timestamp in free_job() work item (Danilo)
> > v3:
> > - Drop forward dec of drm_sched_select_entity (Boris)
> > - Return in drm_sched_run_job_work if entity NULL (Boris)
> > v4:
> > - Replace dequeue with peek and invert logic (Luben)
> > - Wrap to 100 lines (Luben)
> > - Update comments for *_queue / *_queue_if_ready functions (Luben)
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/scheduler/sched_main.c | 287 +++--
> > include/drm/gpu_scheduler.h| 8 +-
> > 2 files changed, 178 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 273e0fbc4eab..b1b8d9f96da5 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -213,11 +213,12 @@ void drm_sched_rq_remove_entity(struct drm_sched_rq
> > *rq,
> > * drm_sched_rq_select_entity_rr - Select an entity which could provide a
> > job to run
> > *
> > * @rq: scheduler run queue to check.
> > + * @peek: Just find, don't set to current.
>
> The "peek" rename is good--thanks!
>
> > *
> > * Try to find a ready entity, returns NULL if none found.
> > */
> > static struct drm_sched_entity *
> > -drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
> > +drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq, bool peek)
> > {
> > struct drm_sched_entity *entity;
> >
> > @@ -227,8 +228,10 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
> > if (entity) {
> > list_for_each_entry_continue(entity, >entities, list) {
> > if (drm_sched_entity_is_ready(entity)) {
> > - rq->current_entity = entity;
> > - reinit_completion(>entity_idle);
> > + if (!peek) {
> > + rq->current_entity = entity;
> > + reinit_completion(>entity_idle);
> > + }
> > spin_unlock(>lock);
> > return entity;
> > }
> > @@ -238,8 +241,10 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
> > list_for_each_entry(entity, >entities, list) {
> >
> > if (drm_sched_entity_is_ready(entity)) {
> > - rq->current_entity = entity;
> > - reinit_completion(>entity_idle);
> > + if (!peek) {
> > + rq->current_entity = entity;
> > + reinit_completion(>entity_idle);
> > + }
> > spin_unlock(>lock);
> > return entity;
> > }
> > @@ -257,11 +262,12 @@ drm_sched_rq_select_entity_rr(struct drm_sched_rq *rq)
> > * drm_sched_rq_select_entity_fifo - Select an entity which provides a job
> > to run
> > *
> > * @rq: scheduler run queue to check.
> > + * @peek: Just find, don't set to current.
> > *
> > * Find oldest waiting ready entity, returns NULL if none found.
> > */
> > static struct drm_sched_entity *
> > -drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq)
> > +drm_sched_rq_select_entity_fifo(struct drm_sched_rq *rq, bool peek)
> > {
> > struct rb_node *rb;
> >
> > @@ -271,8 +277,10 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq
> > *rq)
> >
> > entity = rb_entry(rb, struct drm_sched_entity, rb_tree_node);
> > if (drm_sched_entity_is_ready(entity)) {
> > - rq->current_entity = entity;
> > - reinit_completion(>entity_idle);
> > + if (!peek) {
> > + rq->current_entity = entity;
> > + reinit_completion(>entity_idle);
> > + }
> > break;
> > }
> > }
> > @@ -282,13 +290,98 @@ drm_sched_rq_select_entity_fifo(struct drm_sched_rq
> > *rq)
> > }
> >
> > /**
> > - * drm_sched_wqueue_enqueue - enqueue scheduler submission
> > + * drm_sched_run_job_queue - enqueue run-job work
>
> Hmm... so this removes the change from patch 1 in this series, and as such
> obviates patch 1.
>
> Do you want to go with "run_job_queue" and the names introduced here?
>
Yes, I like the run_job_queue name here.
> In this case, we can have that in patch 1 instead, and this patch
> would only split the "free job" into its own work item.
>
Sure, so s/drm_sched_wqueue_enqueue/drm_sched_run_job_queue in patch #1?
> > + * @sched: scheduler instance
> > + */
> >
Re: [PATCH] drm/doc: ci: Require more context for flaky tests
On 19/10/2023 06:46, Maxime Ripard wrote:
Flaky tests can be very difficult to reproduce after the facts, which
will make it even harder to ever fix.
Let's document the metadata we agreed on to provide more context to
anyone trying to address these fixes.
Link:
https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/
Signed-off-by: Maxime Ripard
---
Documentation/gpu/automated_testing.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 469b6fb65c30..2dd0e221c2c3 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,6 +67,19 @@ Lists the tests that for a given driver on a specific
hardware revision are
known to behave unreliably. These tests won't cause a job to fail regardless
of
the result. They will still be run.
+Each new flake entry must be associated with a link to a bug report to
What do you mean by but report? Just a link to an email to the mailing
list is enough?
Also, I had made a mistake to the first flakes lists, which I corrected
with https://www.spinics.net/lists/kernel/msg4959629.html (there was a
bug in my script which ended up erroneous adding a bunch of tests in the
flake list, so I cleaned them up), I would like to kind request to let
me add those documentation in a future patch to not block that patch series.
Thanks
Helen
+the author of the affected driver, the board name or Device Tree name of
+the board, the first kernel version affected, and an approximation of
+the failure rate.
+
+They should be provided under the following format::
+
+ # Bug Report: $LORE_OR_PATCHWORK_URL
+ # Board Name: broken-board.dtb
+ # Version: 6.6-rc1
+ # Failure Rate: 100
+ flaky-test
+
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
unified LRU for ttm and svm
Hello all, As a follow up to this thread https://www.spinics.net/lists/dri-devel/msg410740.html, I looked further into the idea of a shared LRU list for both ttm/bo and svm (to achieve a mutual eviction b/t them). I came up a rough design which I think better to align with you before I move too far. As illustrated in below diagram: 1. There will be a global drm_lru_manager to maintain the shared LRU list. Each memory type will have a list, i.e., system memory has a list, gpu memory has a list. On system which has multiple gpu memory regions, we can have multiple GPU LRU 2. Move the LRU operation functions (such as bulk_move related) from ttm_resource_manager to drm_lru_manager 3. Drm_lru_manager should be initialized during device initialization. Ttm layer or svm layer can have weak reference to it for convenience. 4. Abstract a drm_lru_entity: This is supposed to be embedded in ttm_resource and svm_resource struct, as illustrated. Since ttm_resource and svm_resource are quite different in nature (ttm_resource is coupled with bo and svm_resource is struct page/pfn based), we can't provide unified eviction function for them. So a evict_func pointer is introduced in drm_lru_entity[Note 1]. 5. Lru_lock. Currently the lru_lock is in ttm_device structure. Ideally this can be moved to drm_lru_manager. But besides the lru list, lru_lock also protect other ttm specific thing such as ttm_device's pinned list. The current plan is to move lru_lock to xe_device/amdgpu_device and ttm_device or svm can have a weak reference for convenience. [cid:image001.png@01DA0285.844FA910] Note 1: I have been considering a structure like below. Each hmm/svm resource page is backed by a struct page and struct page already has a lru member. So theoretically the LRU list can be as below. This way we don't need to introduce the drm_lru_entity struct. The difficulty is, without modify the linux struct page, we can't cast a lru node to struct page or struct ttm_resource, since we don't know whether this node is used by ttm or svm. This is why I had to introduce drm_lru_entity to hold an evict_function above. But let me know if you have better idea. [cid:image002.png@01DA0289.9AD5D110] Thanks, Oak
Re: [PATCH v5 9/9] drm: ci: Update xfails
On 19/10/2023 13:42, Helen Koike wrote: On 19/10/2023 04:06, Vignesh Raman wrote: Update msm-apq8016-fails, mediatek-mt8173-fails and virtio_gpu-none-fails to include the tests which fail. Update mediatek-mt8173-flakes to include the tests which flakes. Update virtio_gpu-none-skips to include the tests that need to be skipped. Signed-off-by: Vignesh Raman --- v2: - No changes v3: - No changes v4: - No changes v5: - Generate fails and flakes file with the updated xfails script - https://www.spinics.net/lists/kernel/msg4959630.html --- .../drm/ci/xfails/mediatek-mt8173-fails.txt | 24 +- .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 9 + .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 17 +- .../drm/ci/xfails/virtio_gpu-none-fails.txt | 65 +- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 632 +- 5 files changed, 682 insertions(+), 65 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt index 671916067dba..d2261a40db11 100644 --- a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt @@ -1,5 +1,7 @@ +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013011 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012949 kms_3d,Fail -kms_addfb_basic@addfb25-bad-modifier,Fail kms_bw@linear-tiling-1-displays-1920x1080p,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail @@ -9,20 +11,22 @@ kms_bw@linear-tiling-2-displays-3840x2160p,Fail kms_bw@linear-tiling-3-displays-1920x1080p,Fail kms_bw@linear-tiling-3-displays-2560x1440p,Fail kms_bw@linear-tiling-3-displays-3840x2160p,Fail -kms_color@pipe-A-invalid-gamma-lut-sizes,Fail -kms_color@pipe-B-invalid-gamma-lut-sizes,Fail -kms_force_connector_basic@force-connector-state,Fail -kms_force_connector_basic@force-edid,Fail -kms_force_connector_basic@force-load-detect,Fail -kms_force_connector_basic@prune-stale-modes,Fail +kms_color@invalid-gamma-lut-sizes,Fail +kms_cursor_legacy@cursor-vs-flip-atomic,Fail +kms_cursor_legacy@cursor-vs-flip-legacy,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail +kms_flip@flip-vs-suspend,Fail +kms_flip@flip-vs-suspend-interruptible,Fail +kms_hdmi_inject@inject-4k,Fail kms_invalid_mode@int-max-clock,Fail +kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20,Fail +kms_plane_scaling@planes-downscale-factor-0-5-upscale-20x20,Fail +kms_plane_scaling@planes-downscale-factor-0-75-upscale-20x20,Fail kms_plane_scaling@planes-upscale-20x20,Fail kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25,Fail kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5,Fail kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75,Fail -kms_plane_scaling@upscale-with-modifier-20x20,Fail -kms_plane_scaling@upscale-with-pixel-format-20x20,Fail -kms_plane_scaling@upscale-with-rotation-20x20,Fail kms_properties@get_properties-sanity-atomic,Fail kms_properties@plane-properties-atomic,Fail kms_properties@plane-properties-legacy,Fail diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt new file mode 100644 index ..8b12e97d59f3 --- /dev/null +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt @@ -0,0 +1,9 @@ +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013138 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013011 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013055 +kms_cursor_legacy@cursor-vs-flip-atomic-transitions +kms_force_connector_basic@force-edid +kms_force_connector_basic@prune-stale-modes +kms_prop_blob@invalid-set-prop +kms_prop_blob@invalid-set-prop-any diff --git a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt index 9981682feab2..dcc49d560cef 100644 --- a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt @@ -1,15 +1,8 @@ +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012932 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 kms_3d,Fail kms_addfb_basic@addfb25-bad-modifier,Fail -kms_cursor_legacy@all-pipes-forked-bo,Fail -kms_cursor_legacy@all-pipes-forked-move,Fail -kms_cursor_legacy@all-pipes-single-bo,Fail -kms_cursor_legacy@all-pipes-single-move,Fail -kms_cursor_legacy@all-pipes-torture-bo,Fail -kms_cursor_legacy@all-pipes-torture-move,Fail -kms_cursor_legacy@pipe-A-forked-bo,Fail -kms_cursor_legacy@pipe-A-forked-move,Fail -kms_cursor_legacy@pipe-A-single-bo,Fail
Re: [PATCH v5 9/9] drm: ci: Update xfails
On 19/10/2023 04:06, Vignesh Raman wrote: Update msm-apq8016-fails, mediatek-mt8173-fails and virtio_gpu-none-fails to include the tests which fail. Update mediatek-mt8173-flakes to include the tests which flakes. Update virtio_gpu-none-skips to include the tests that need to be skipped. Signed-off-by: Vignesh Raman --- v2: - No changes v3: - No changes v4: - No changes v5: - Generate fails and flakes file with the updated xfails script - https://www.spinics.net/lists/kernel/msg4959630.html --- .../drm/ci/xfails/mediatek-mt8173-fails.txt | 24 +- .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 9 + .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 17 +- .../drm/ci/xfails/virtio_gpu-none-fails.txt | 65 +- .../drm/ci/xfails/virtio_gpu-none-skips.txt | 632 +- 5 files changed, 682 insertions(+), 65 deletions(-) create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt index 671916067dba..d2261a40db11 100644 --- a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt @@ -1,5 +1,7 @@ +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013011 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012949 kms_3d,Fail -kms_addfb_basic@addfb25-bad-modifier,Fail kms_bw@linear-tiling-1-displays-1920x1080p,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail @@ -9,20 +11,22 @@ kms_bw@linear-tiling-2-displays-3840x2160p,Fail kms_bw@linear-tiling-3-displays-1920x1080p,Fail kms_bw@linear-tiling-3-displays-2560x1440p,Fail kms_bw@linear-tiling-3-displays-3840x2160p,Fail -kms_color@pipe-A-invalid-gamma-lut-sizes,Fail -kms_color@pipe-B-invalid-gamma-lut-sizes,Fail -kms_force_connector_basic@force-connector-state,Fail -kms_force_connector_basic@force-edid,Fail -kms_force_connector_basic@force-load-detect,Fail -kms_force_connector_basic@prune-stale-modes,Fail +kms_color@invalid-gamma-lut-sizes,Fail +kms_cursor_legacy@cursor-vs-flip-atomic,Fail +kms_cursor_legacy@cursor-vs-flip-legacy,Fail +kms_flip@flip-vs-modeset-vs-hang,Fail +kms_flip@flip-vs-panning-vs-hang,Fail +kms_flip@flip-vs-suspend,Fail +kms_flip@flip-vs-suspend-interruptible,Fail +kms_hdmi_inject@inject-4k,Fail kms_invalid_mode@int-max-clock,Fail +kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20,Fail +kms_plane_scaling@planes-downscale-factor-0-5-upscale-20x20,Fail +kms_plane_scaling@planes-downscale-factor-0-75-upscale-20x20,Fail kms_plane_scaling@planes-upscale-20x20,Fail kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-25,Fail kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-5,Fail kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75,Fail -kms_plane_scaling@upscale-with-modifier-20x20,Fail -kms_plane_scaling@upscale-with-pixel-format-20x20,Fail -kms_plane_scaling@upscale-with-rotation-20x20,Fail kms_properties@get_properties-sanity-atomic,Fail kms_properties@plane-properties-atomic,Fail kms_properties@plane-properties-legacy,Fail diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt new file mode 100644 index ..8b12e97d59f3 --- /dev/null +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt @@ -0,0 +1,9 @@ +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013138 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013011 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013055 +kms_cursor_legacy@cursor-vs-flip-atomic-transitions +kms_force_connector_basic@force-edid +kms_force_connector_basic@prune-stale-modes +kms_prop_blob@invalid-set-prop +kms_prop_blob@invalid-set-prop-any diff --git a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt index 9981682feab2..dcc49d560cef 100644 --- a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt +++ b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt @@ -1,15 +1,8 @@ +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012932 +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 kms_3d,Fail kms_addfb_basic@addfb25-bad-modifier,Fail -kms_cursor_legacy@all-pipes-forked-bo,Fail -kms_cursor_legacy@all-pipes-forked-move,Fail -kms_cursor_legacy@all-pipes-single-bo,Fail -kms_cursor_legacy@all-pipes-single-move,Fail -kms_cursor_legacy@all-pipes-torture-bo,Fail -kms_cursor_legacy@all-pipes-torture-move,Fail -kms_cursor_legacy@pipe-A-forked-bo,Fail -kms_cursor_legacy@pipe-A-forked-move,Fail -kms_cursor_legacy@pipe-A-single-bo,Fail -kms_cursor_legacy@pipe-A-single-move,Fail
Re: [Intel-gfx] [PATCH 3/3] drm/i915/mtl: Add counters for engine busyness ticks
See comments inline below.
Zhanjun
On 2023-09-22 6:25 p.m., john.c.harri...@intel.com wrote:
From: Umesh Nerlige Ramappa
In new version of GuC engine busyness, GuC provides engine busyness
ticks as a 64 bit counter. Add a new counter to relay this value to the
user as is.
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_engine.h| 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 12
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 ++-
drivers/gpu/drm/i915/i915_pmu.c | 25 ++-
drivers/gpu/drm/i915/i915_pmu.h | 2 +-
include/uapi/drm/i915_drm.h | 13 +++-
8 files changed, 116 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index b58c30ac8ef02..57af7ec8ecd82 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -249,6 +249,7 @@ void intel_engine_dump_active_requests(struct list_head
*requests,
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine,
ktime_t *now);
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine);
void intel_engine_get_hung_entity(struct intel_engine_cs *engine,
struct intel_context **ce, struct
i915_request **rq);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 84a75c95f3f7d..1c9ffb1ae9889 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2426,6 +2426,22 @@ ktime_t intel_engine_get_busy_time(struct
intel_engine_cs *engine, ktime_t *now)
return engine->busyness(engine, now);
}
+/**
+ * intel_engine_get_busy_ticks() - Return current accumulated engine busyness
+ * ticks
+ * @engine: engine to report on
+ *
+ * Returns accumulated ticks @engine was busy since engine stats were enabled.
+ */
+u64 intel_engine_get_busy_ticks(struct intel_engine_cs *engine)
+{
+ if (!engine->busyness_ticks ||
+ !(engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS))
+ return 0;
+
+ return engine->busyness_ticks(engine);
+}
+
struct intel_context *
intel_engine_create_virtual(struct intel_engine_cs **siblings,
unsigned int count, unsigned long flags)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 40fd8f984d64b..a88d40c74d604 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -548,6 +548,11 @@ struct intel_engine_cs {
ktime_t (*busyness)(struct intel_engine_cs *engine,
ktime_t *now);
+ /*
+* Get engine busyness ticks
+*/
+ u64 (*busyness_ticks)(struct intel_engine_cs *engine);
+
struct intel_engine_execlists execlists;
/*
@@ -574,6 +579,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_EU_PRIORITYBIT(10)
#define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
#define I915_ENGINE_USES_WA_HOLD_CCS_SWITCHOUT BIT(12)
+#define I915_ENGINE_SUPPORTS_TICKS_STATS BIT(13)
unsigned int flags;
/*
@@ -649,6 +655,12 @@ intel_engine_supports_stats(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_SUPPORTS_STATS;
}
+static inline bool
+intel_engine_supports_tick_stats(const struct intel_engine_cs *engine)
+{
+ return engine->flags & I915_ENGINE_SUPPORTS_TICKS_STATS;
+}
+
static inline bool
intel_engine_has_preemption(const struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index dcedff41a825f..69eb610b5ab0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -100,6 +100,7 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+ MAP(SUPPORTS_TICKS_STATS, ENGINE_BUSY_TICKS_STATS),
#undef MAP
};
struct intel_engine_cs *engine;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0c1fee5360777..71749fb9ad35b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1289,12 +1289,7 @@ static void busy_v1_guc_update_pm_timestamp(struct
intel_guc *guc, ktime_t *now)
guc->busy.v1.gt_stamp = ((u64)gt_stamp_hi << 32) | gt_stamp_lo;
}
-/*
- * Unlike the execlist mode of
[PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2023-10-19: - Fix display issue that was blocking S0ix (Khaled) - Retry gtt fault when out of fence registers (Ville) Thanks, Rodrigo. The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb: Linux 6.6-rc6 (2023-10-15 13:34:39 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-10-19 for you to fetch changes up to e339c6d628fe66c9b64bf31040a55770952aec57: drm/i915: Retry gtt fault when out of fence registers (2023-10-17 22:08:54 -0400) - Fix display issue that was blocking S0ix (Khaled) - Retry gtt fault when out of fence registers (Ville) Khaled Almahallawy (1): drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned Ville Syrjälä (1): drm/i915: Retry gtt fault when out of fence registers drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + 2 files changed, 2 insertions(+), 2 deletions(-)
[PULL] drm-intel-next
Hi Dave and Daniel, This is our last pull request towards 6.7. I'm sending this on behalf of Jani, who was covering this round. The main reason for this extra PR is to ensure that we get MTL force_probe removed on 6.7. The platform has a good green picture in our BAT CI currently and is stable. Please notice that this is highly dependent on fixes that are coming through drm-intel-gt-next pull-request that Tvrtko just sent: https://lore.kernel.org/all/ZTFDFSbd%2FU7YP+hI@tursulin-desk/ Here goes drm-intel-next-2023-10-19: - Add new DG2 PCI IDs (Shekhar) - Remove watchdog timers for PSR on Lunar Lake (Mika Kahola) - DSB changes for proper handling of LUT programming (Ville) - Store DSC DPCD capabilities in the connector (Imre) - Clean up zero initializers (Ville) - Remove Meteor Lake force_probe protection (RK) Thanks, Rodrigo. The following changes since commit a6028afef98a6e3f059a014452914eb01035d530: drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2) (2023-10-12 12:41:54 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2023-10-19 for you to fetch changes up to 213c43676beb5f5a63cb27a0c8e8e71035b08445: drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake (2023-10-18 06:23:41 +0200) - Add new DG2 PCI IDs (Shekhar) - Remove watchdog timers for PSR on Lunar Lake (Mika Kahola) - DSB changes for proper handling of LUT programming (Ville) - Store DSC DPCD capabilities in the connector (Imre) - Clean up zero initializers (Ville) - Remove Meteor Lake force_probe protection (RK) Imre Deak (19): drm/i915/dp: Sanitize DPCD revision check in intel_dp_get_dsc_sink_cap() drm/i915/dp: Store DSC DPCD capabilities in the connector drm/i915/dp_mst: Set connector DSC capabilities and decompression AUX drm/i915/dp: Use i915/intel connector local variables in i915_dsc_fec_support_show() drm/i915/dp: Use connector DSC DPCD in i915_dsc_fec_support_show() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_max_bpp() drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_fec() drm/i915/dp: Use connector DSC DPCD in intel_dp_supports_dsc() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_max_sink_compressed_bppx16() drm/i915/dp: Pass connector DSC DPCD to drm_dp_dsc_sink_supported_input_bpcs() drm/i915/dp: Pass only the required i915 to intel_dp_source_dsc_version_minor() drm/i915/dp: Pass only the required DSC DPCD to intel_dp_sink_dsc_version_minor() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_params() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_supports_format() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_get_slice_count() drm/i915/dp: Use connector DSC DPCD in intel_dp_mode_valid() drm/i915/dp: Use connector DSC DPCD in intel_dp_dsc_compute_config() drm/i915/dp_mst: Use connector DSC DPCD in intel_dp_mst_mode_valid_ctx() drm/i915/dp: Remove unused DSC caps from intel_dp Mika Kahola (1): drm/i915/lnl: Remove watchdog timers for PSR Radhakrishna Sripada (1): drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake Shekhar Chauhan (1): drm/i915: Add new DG2 PCI IDs Ville Syrjälä (6): drm/i915/dsb: Allocate command buffer from local memory drm/i915/dsb: Correct DSB command buffer cache coherency settings drm/i915/dsb: Re-instate DSB for LUT updates drm/i915/display: Clean up zero initializers drm/i915/hdcp: Clean up zero initializers drm/i915/pci: Clean up zero initializers drivers/gpu/drm/i915/display/intel_acpi.c | 2 +- drivers/gpu/drm/i915/display/intel_color.c | 3 - drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +- .../gpu/drm/i915/display/intel_display_debugfs.c | 22 +-- drivers/gpu/drm/i915/display/intel_display_types.h | 8 +- drivers/gpu/drm/i915/display/intel_dp.c| 212 - drivers/gpu/drm/i915/display/intel_dp.h| 7 +- .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 +- drivers/gpu/drm/i915/display/intel_dp_mst.c| 37 +++- drivers/gpu/drm/i915/display/intel_dsb.c | 18 +- drivers/gpu/drm/i915/display/intel_gmbus.c | 2 +- .../gpu/drm/i915/display/intel_hdcp_gsc_message.c | 44 ++--- drivers/gpu/drm/i915/display/intel_plane_initial.c | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 10 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +- drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +- drivers/gpu/drm/i915/display/intel_wm.c| 2 +- drivers/gpu/drm/i915/i915_pci.c| 3 +- include/drm/i915_pciids.h | 6 +- 19 files changed, 235 insertions(+),
Re: [RFC PATCH 10/10] drm/vkms: Add enumerated 1D curve colorop
On 2023-10-10 12:27, Melissa Wen wrote:
> On 09/08, Harry Wentland wrote:
>> Signed-off-by: Harry Wentland
>> 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 Brekenfeld
>> Cc: Daniel Vetter
>> Cc: Uma Shankar
>> Cc: Naseer Ahmed
>> Cc: Christopher Braga
>> ---
>> drivers/gpu/drm/vkms/Makefile| 3 +-
>> drivers/gpu/drm/vkms/vkms_colorop.c | 108 +
>> drivers/gpu/drm/vkms/vkms_composer.c | 316 +++
>> drivers/gpu/drm/vkms/vkms_drv.h | 4 +
>> drivers/gpu/drm/vkms/vkms_plane.c| 2 +
>> 5 files changed, 432 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
>>
>> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
>> index 1b28a6a32948..bcf508873622 100644
>> --- a/drivers/gpu/drm/vkms/Makefile
>> +++ b/drivers/gpu/drm/vkms/Makefile
>> @@ -6,6 +6,7 @@ vkms-y := \
>> vkms_formats.o \
>> vkms_crtc.o \
>> vkms_composer.o \
>> -vkms_writeback.o
>> +vkms_writeback.o \
>> +vkms_colorop.o
>>
>> obj-$(CONFIG_DRM_VKMS) += vkms.o
>> diff --git a/drivers/gpu/drm/vkms/vkms_colorop.c
>> b/drivers/gpu/drm/vkms/vkms_colorop.c
>> new file mode 100644
>> index ..b3da0705bca7
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vkms/vkms_colorop.c
>> @@ -0,0 +1,108 @@
>> +/*
>> + * Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + *
>> + * Authors: AMD
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define MAX_COLOR_PIPELINES 5
>> +
>> +const int vkms_initialize_tf_pipeline(struct drm_plane *plane, struct
>> drm_prop_enum_list *list)
>> +{
>> +
>> +struct drm_colorop *op, *prev_op;
>> +struct drm_device *dev = plane->dev;
>> +int ret;
>> +
>> +/* 1st op: 1d curve */
>> +op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
>> +if (!op) {
>> +DRM_ERROR("KMS: Failed to allocate colorop\n");
>> +return -ENOMEM;
>> +}
>> +
>> +ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_1D_CURVE);
>> +if (ret)
>> +return ret;
>> +
>> +list->type = op->base.id;
>> +list->name = kasprintf(GFP_KERNEL, "Color Pipeline %d", op->base.id);
>> +
>> +prev_op = op;
>> +
>> +/* 2nd op: 1d curve */
>> +op = kzalloc(sizeof(struct drm_colorop), GFP_KERNEL);
>> +if (!op) {
>> +DRM_ERROR("KMS: Failed to allocate colorop\n");
>> +return -ENOMEM;
>> +}
>> +
>> +ret = drm_colorop_init(dev, op, plane, DRM_COLOROP_1D_CURVE);
>> +if (ret)
>> +return ret;
>> +
>> +drm_colorop_set_next_property(prev_op, op);
>> +
>> +return 0;
>> +}
>> +
>> +int vkms_initialize_colorops(struct drm_plane *plane)
>> +{
>> +struct drm_device *dev = plane->dev;
>> +struct drm_property *prop;
>> +struct drm_prop_enum_list pipelines[MAX_COLOR_PIPELINES];
>> +int len = 0;
>> +int ret;
>> +
>> +/* Add "Bypass" (i.e. NULL) pipeline */
>> +pipelines[len].type = 0;
>> +pipelines[len].name = "Bypass";
>> +len++;
>> +
>> +/* Add pipeline consisting of transfer functions */
>> +ret = vkms_initialize_tf_pipeline(plane, &(pipelines[len]));
>> +if (ret)
>> +return ret;
>> +len++;
>> +
>> +/* Create COLOR_PIPELINE property and attach */
>> +prop = drm_property_create_enum(dev, DRM_MODE_PROP_ATOMIC,
>> +"COLOR_PIPELINE",
>> +pipelines, len);
>> +if (!prop)
>> +return -ENOMEM;
>> +
>>
Re: [RFC PATCH 02/10] drm/colorop: Introduce new drm_colorop mode object
On 2023-10-10 12:19, Melissa Wen wrote:
> On 09/08, Harry Wentland wrote:
>> 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
>> 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 Brekenfeld
>> Cc: Daniel Vetter
>> Cc: Uma Shankar
>> Cc: Naseer Ahmed
>> Cc: Christopher Braga
>> ---
>> drivers/gpu/drm/Makefile| 1 +
>> drivers/gpu/drm/drm_atomic.c| 79 +
>> drivers/gpu/drm/drm_atomic_helper.c | 12 ++
>> drivers/gpu/drm/drm_atomic_uapi.c | 48
>> drivers/gpu/drm/drm_colorop.c | 169
>> drivers/gpu/drm/drm_mode_config.c | 7 ++
>> drivers/gpu/drm/drm_plane_helper.c | 2 +-
>> include/drm/drm_atomic.h| 82 ++
>> include/drm/drm_atomic_uapi.h | 1 +
>> include/drm/drm_colorop.h | 157 ++
>> include/drm/drm_mode_config.h | 18 +++
>> include/drm/drm_plane.h | 2 +
>> include/uapi/drm/drm.h | 3 +
>> include/uapi/drm/drm_mode.h | 1 +
>> 14 files changed, 581 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/drm_colorop.c
>> create mode 100644 include/drm/drm_colorop.h
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 1855863b4d7a..941de0269709 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -16,6 +16,7 @@ drm-y := \
>> drm_client.o \
>> drm_client_modeset.o \
>> drm_color_mgmt.o \
>> +drm_colorop.o \
>> drm_connector.o \
>> drm_crtc.o \
>> drm_displayid.o \
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 11f3a130f6f4..d734e9d5bfed 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -42,6 +42,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "drm_crtc_internal.h"
>> #include "drm_internal.h"
>> @@ -108,6 +109,7 @@ void drm_atomic_state_default_release(struct
>> drm_atomic_state *state)
>> kfree(state->connectors);
>> kfree(state->crtcs);
>> kfree(state->planes);
>> +kfree(state->colorops);
>> kfree(state->private_objs);
>> }
>> EXPORT_SYMBOL(drm_atomic_state_default_release);
>> @@ -139,6 +141,10 @@ drm_atomic_state_init(struct drm_device *dev, struct
>> drm_atomic_state *state)
>> sizeof(*state->planes), GFP_KERNEL);
>> if (!state->planes)
>> goto fail;
>> +state->colorops = kcalloc(dev->mode_config.num_colorop,
>> + sizeof(*state->colorops), GFP_KERNEL);
>> +if (!state->colorops)
>> +goto fail;
>>
>> state->dev = dev;
>>
>> @@ -244,6 +250,20 @@ void drm_atomic_state_default_clear(struct
>> drm_atomic_state *state)
>> state->planes[i].new_state = NULL;
>> }
>>
>> +for (i = 0; i < config->num_colorop; i++) {
>> +struct drm_colorop *colorop = state->colorops[i].ptr;
>> +
>> +if (!colorop)
>> +continue;
>> +
>> +drm_colorop_atomic_destroy_state(colorop,
>> + state->colorops[i].state);
>> +state->colorops[i].ptr = NULL;
>> +state->colorops[i].state = NULL;
>> +state->colorops[i].old_state = NULL;
>> +state->colorops[i].new_state = NULL;
>> +}
>> +
>> for (i = 0; i < state->num_private_objs; i++) {
>> struct drm_private_obj *obj = state->private_objs[i].ptr;
>>
>> @@ -562,6 +582,65 @@ drm_atomic_get_plane_state(struct drm_atomic_state
>> *state,
>> }
>> EXPORT_SYMBOL(drm_atomic_get_plane_state);
>>
>> +
>> +/**
>> + * drm_atomic_get_colorop_state - get colorop state
>> + * @state: global atomic state object
>> + * @colorop: colorop to get state object for
>> + *
>> + * This function returns the colorop state for the given colorop,
>> allocating it
>> + * if needed. It will also grab the relevant plane lock to make sure that
>> the
>> + * state is consistent.
>> + *
>> + * Returns:
>> + *
>> + * Either the allocated state or the error code encoded into the pointer.
>> When
>> + * the error is EDEADLK then the w/w mutex code has detected a deadlock and
>> the
>> + * entire atomic sequence must be restarted. All other errors are fatal.
>> + */
>> +struct drm_colorop_state *
>> +drm_atomic_get_colorop_state(struct drm_atomic_state *state,
>> + struct drm_colorop
Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On 2023-10-10 12:13, Melissa Wen wrote: > O 09/08, Harry Wentland wrote: >> Signed-off-by: Harry Wentland >> 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 Brekenfeld >> Cc: Daniel Vetter >> Cc: Uma Shankar >> Cc: Naseer Ahmed >> Cc: Christopher Braga >> --- >> Documentation/gpu/rfc/color_pipeline.rst | 278 +++ >> 1 file changed, 278 insertions(+) >> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst >> >> diff --git a/Documentation/gpu/rfc/color_pipeline.rst >> b/Documentation/gpu/rfc/color_pipeline.rst >> new file mode 100644 >> index ..bfa4a8f12087 >> --- /dev/null >> +++ b/Documentation/gpu/rfc/color_pipeline.rst >> @@ -0,0 +1,278 @@ >> + >> +Linux Color Pipeline API >> + >> + >> +What problem are we solving? >> + >> + >> +We would like to support pre-, and post-blending complex color >> transformations >> +in order to allow for HW-supported HDR use-cases, as well as to provide >> support >> +to color-managed applications, such as video or image editors. >> + >> +While it is possible to support an HDR output on HW supporting the >> Colorspace >> +and HDR Metadata drm_connector properties that requires the compositor or >> +application to render and compose the content into one final buffer >> intended for >> +display. Doing so is costly. >> + >> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other >> +operations to support color transformations. These operations are often >> +implemented in fixed-function HW and therefore much more power efficient >> than >> +performing similar operations via shaders or CPU. >> + >> +We would like to make use of this HW functionality to support complex color >> +transformations with no, or minimal CPU or shader load. >> + >> + >> +How are other OSes solving this problem? >> + >> + >> +The most widely supported use-cases regard HDR content, whether video or >> +gaming. >> + >> +Most OSes will specify the source content format (color gamut, encoding >> transfer >> +function, and other metadata, such as max and average light levels) to a >> driver. >> +Drivers will then program their fixed-function HW accordingly to map from a >> +source content buffer's space to a display's space. >> + >> +When fixed-function HW is not available the compositor will assemble a >> shader to >> +ask the GPU to perform the transformation from the source content format to >> the >> +display's format. >> + >> +A compositor's mapping function and a driver's mapping function are usually >> +entirely separate concepts. On OSes where a HW vendor has no insight into >> +closed-source compositor code such a vendor will tune their color management >> +code to visually match the compositor's. On other OSes, where both mapping >> +functions are open to an implementer they will ensure both mappings match. >> + >> + >> +Why is Linux different? >> +=== >> + >> +Unlike other OSes, where there is one compositor for one or more drivers, on >> +Linux we have a many-to-many relationship. Many compositors; many drivers. >> +In addition each compositor vendor or community has their own view of how >> +color management should be done. This is what makes Linux so beautiful. >> + >> +This means that a HW vendor can now no longer tune their driver to one >> +compositor, as tuning it to one will almost inevitably make it look very >> +different from another compositor's color mapping. >> + >> +We need a better solution. >> + >> + >> +Descriptive API >> +=== >> + >> +An API that describes the source and destination colorspaces is a >> descriptive >> +API. It describes the input and output color spaces but does not describe >> +how precisely they should be mapped. Such a mapping includes many minute >> +design decision that can greatly affect the look of the final result. >> + >> +It is not feasible to describe such mapping with enough detail to ensure the >> +same result from each implementation. In fact, these mappings are a very >> active >> +research area. >> + >> + >> +Prescriptive API >> + >> + >> +A prescriptive API describes not the source and destination colorspaces. It >> +instead prescribes a recipe for how to manipulate pixel values to arrive at >> the >> +desired outcome. >> + >> +This recipe is generally an order straight-forward operations, with clear >> +mathematical definitions, such as 1D LUTs, 3D LUTs, matrices, or other >> +operations that can be described in a precise manner. >> + >> + >> +The Color Pipeline API >> +== >> + >> +HW color management pipelines can significantly differ between
Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed
On 2023-09-13 07:29, Pekka Paalanen wrote:
> On Fri, 8 Sep 2023 11:02:26 -0400
> Harry Wentland wrote:
>
>> Signed-off-by: Harry Wentland
>> 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 Brekenfeld
>> Cc: Daniel Vetter
>> Cc: Uma Shankar
>> Cc: Naseer Ahmed
>> Cc: Christopher Braga
>> ---
>> Documentation/gpu/rfc/color_pipeline.rst | 278 +++
>> 1 file changed, 278 insertions(+)
>> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
>
> Hi Harry,
>
> it's really nice to see this!
>
Thanks for the feedback. I'm just putting a v2 together with comments
(partially) addressed.
> Sebastian started on the backward/forward compatibility, so I'll
> comment on everything else here, and leave the compatibility for that
> thread.
>
>> diff --git a/Documentation/gpu/rfc/color_pipeline.rst
>> b/Documentation/gpu/rfc/color_pipeline.rst
>> new file mode 100644
>> index ..bfa4a8f12087
>> --- /dev/null
>> +++ b/Documentation/gpu/rfc/color_pipeline.rst
...
>> +COLOR_PIPELINE Plane Property
>> +=
>> +
>> +Because we don't have existing KMS color properties in the pre-blending
>> +portion of display pipelines (i.e. on drm_planes) we are introducing
>> +color pipelines here first. Eventually we'll want to use the same
>> +concept for the post-blending portion, i.e. drm_crtcs.
>
> This paragraph might fit better in a cover letter.
>
>> +
>> +Color Pipelines are created by a driver and advertised via a new
>> +COLOR_PIPELINE enum property on each plane. Values of the property
>> +always include '0', which is the default and means all color processing
>> +is disabled. Additional values will be the object IDs of the first
>> +drm_colorop in a pipeline. A driver can create and advertise none, one,
>> +or more possible color pipelines. A DRM client will select a color
>> +pipeline by setting the COLOR PIPELINE to the respective value.
>> +
>> +In the case where drivers have custom support for pre-blending color
>> +processing those drivers shall reject atomic commits that are trying to
>> +set both the custom color properties, as well as the COLOR_PIPELINE
>
> s/set/use/ because one of them could be carried-over state from
> previous commits while not literally set in this one.
>
>> +property.
>> +
>> +An example of a COLOR_PIPELINE property on a plane might look like this::
>> +
>> +Plane 10
>> +├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
>> +├─ …
>> +└─ "color_pipeline": enum {0, 42, 52} = 0
>
> Enum values are string names. I presume the intention here is that the
> strings will never need to be parsed, and the uint64_t is always equal
> to the string representation, right?
>
> That needs a statement here. It differs from all previous uses of
> enums, and e.g. requires a little bit of new API in libweston's
> DRM-backend to handle since it has its own enums referring to the
> string names that get mapped to the uint64_t per owning KMS object.
>
I'm currently putting the DRM object ID in the "value" and use the
"name" as a descriptive name.
> struct drm_mode_property_enum {
> __u64 value;
> char name[DRM_PROP_NAME_LEN];
> };
This works well in IGT and gives us a nice descriptive name for
debugging, but I could consider changing this if it'd simplify
people's lives.
>> +
>> +
>> +Color Pipeline Discovery
>> +
>> +
>> +A DRM client wanting color management on a drm_plane will:
>> +
>> +1. Read all drm_colorop objects
>
> What does this do?
We probably don't need this, and with it we probably don't need
the new IOCTLs. I added this to align with IGT's current init
procedure where it reads all DRM core objects, like planes, etc.,
before using them. But realistically we can just look at the
colorop ID from the COLOR_PIPELINE property and then retrieve
the other colorops through the NEXT pointer.
>
>> +2. Get the COLOR_PIPELINE property of the plane
>> +3. iterate all COLOR_PIPELINE enum values
>> +4. for each enum value walk the color pipeline (via the NEXT pointers)
>> + and see if the available color operations are suitable for the
>> + desired color management operations
>> +
>> +An example of chained properties to define an AMD pre-blending color
>> +pipeline might look like this::
>> +
>> +Plane 10
>> +├─ "type": immutable enum {Overlay, Primary, Cursor} = Primary
>> +└─ "color_pipeline": enum {0, 42} = 0
>> +Color operation 42 (input CSC)
>
> I presume the string "(input CSC)" does not come from KMS, and is
> actually just a comment added here by hand?
>
Exactly. It only exists as a comment here. I'll remove it.
Harry
>
> Thanks,
> pq
>
>> +├─ "type": enum {Bypass, Matrix} = Matrix
>> +
[PULL] drm-intel-gt-next
Hi Dave, Daniel, Here is the final pull request for 6.7. As indicated that it may happen in the last pull, the remaining missing functionality for Meteorlake, enabling the GuC based TLB invalidation, has since been merged and platform thought to be ready for lifting out of force probe status. Also for Meteorlake a correction on how L3 flushing is done landed. Otherwise one fix for perf/OA and one for mmap gtt handling and some code base cleanups. Regards, Tvrtko drm-intel-gt-next-2023-10-19: Driver Changes: Fixes/improvements/new stuff: - Retry gtt fault when out of fence registers (Ville Syrjälä) - Determine context valid in OA reports [perf] (Umesh Nerlige Ramappa) Future platform enablement: - GuC based TLB invalidation for Meteorlake (Jonathan Cavitt, Prathap Kumar Valsan) - Don't set PIPE_CONTROL_FLUSH_L3 [mtl] (Vinay Belgaumkar) Miscellaneous: - Clean up zero initializers [guc,pxp] (Ville Syrjälä) - Prevent potential null-ptr-deref in engine_init_common (Nirmoy Das) The following changes since commit 039adf3947252693f7c882607dac2dc67e7f7ab2: drm/i915: More use of GT specific print helpers (2023-10-10 15:40:26 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2023-10-19 for you to fetch changes up to 7eeaedf79989a8f131939782832e21e9218ed2a0: drm/i915/perf: Determine context valid in OA reports (2023-10-18 16:19:56 -0700) Driver Changes: Fixes/improvements/new stuff: - Retry gtt fault when out of fence registers (Ville Syrjälä) - Determine context valid in OA reports [perf] (Umesh Nerlige Ramappa) Future platform enablement: - GuC based TLB invalidation for Meteorlake (Jonathan Cavitt, Prathap Kumar Valsan) - Don't set PIPE_CONTROL_FLUSH_L3 [mtl] (Vinay Belgaumkar) Miscellaneous: - Clean up zero initializers [guc,pxp] (Ville Syrjälä) - Prevent potential null-ptr-deref in engine_init_common (Nirmoy Das) Jonathan Cavitt (6): drm/i915: Add GuC TLB Invalidation device info flags drm/i915/guc: Add CT size delay helper drm/i915: No TLB invalidation on suspended GT drm/i915: No TLB invalidation on wedged GT drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck drm/i915: Enable GuC TLB invalidations for MTL Nirmoy Das (1): drm/i915: Prevent potential null-ptr-deref in engine_init_common Prathap Kumar Valsan (1): drm/i915: Define and use GuC and CTB TLB invalidation routines Umesh Nerlige Ramappa (1): drm/i915/perf: Determine context valid in OA reports Ville Syrjälä (3): drm/i915: Retry gtt fault when out of fence registers drm/i915/guc: Clean up zero initializers drm/i915/pxp: Clean up zero initializers Vinay Belgaumkar (1): drm/i915/mtl: Don't set PIPE_CONTROL_FLUSH_L3 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 + drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +- drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 ++- drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +- drivers/gpu/drm/i915/gt/selftest_tlb.c| 11 +- drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.h| 23 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c| 4 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 38 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 233 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 4 +- drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 8 +- drivers/gpu/drm/i915/pxp/intel_pxp_huc.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 8 +- 21 files changed, 407 insertions(+), 30 deletions(-)
Re: [PATCH] drm/amd/display: clean up some inconsistent indenting
Applied. Thanks! Alex On Wed, Oct 18, 2023 at 11:38 PM Jiapeng Chong wrote: > > No functional modification involved. > > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:2902 dm_resume() > warn: inconsistent indenting. > > Reported-by: Abaci Robot > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6940 > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 801f87a12ccf..0e1f8c5d7f9b 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -2899,7 +2899,7 @@ static int dm_resume(void *handle) > } > > /* power on hardware */ > -dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0); > + dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D0); > > /* program HPD filter */ > dc_resume(dm->dc); > -- > 2.20.1.7.g153144c >
Re: [PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles
On Thu, Oct 19, 2023 at 11:22:19AM +0200, Krzysztof Kozlowski wrote: > On 18/10/2023 18:18, Chris Morgan wrote: > > From: Chris Morgan > > > > Update the NewVision NV3051D compatible strings by adding a new panel, > > the powkiddy,rk2023-panel, and removing another entry, the > > anbernic,rg353v-panel. The rg353v-panel is exactly identical to the > > rg353p-panel and is not currently in use by any existing device tree. > > The rk2023-panel is similar to the rg353p-panel but has slightly > > different timings. > > This still does not explain me why do you want to remove old panel. When I originally wrote the driver I only had one piece of hardware and I set the compatible string in the driver as newvision,nv3051d. Unfortunately since then I've found 2 more devices in use that are *just* different enough to require the driver to do things a bit differently. In the case of the anbernic,rg351v-panel I need to enable a new DSI flag; in the case of the powkiddy,rk2023-panel I need to decrease the vertical back porch and drop the higher frequency timings. The best way to accomplish this was to change the strategy from having a single binding in the driver of newvision,nv3051d to a binding for each distinct hardware where the differences apply. Note that I've looked at querying the DSI panel ID, but for each device the value is identical (so it can't be used to differentiate the hardware sadly). So the driver now has 3 different compatible strings. I could in this case add a 4th compatible string of anbernic,rg353v-panel but it would be identical to anbernic,rg353p-panel. For the moment we are using anbernic,rg353p-panel everywhere (including the rg353v), so it makes sense to drop this unused value while we can, at least to me. Let me know if you have any more questions, thank you. Chris > > > > Best regards, > Krzysztof >
Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023
On Thu, Oct 19, 2023 at 11:21:47AM +0200, Krzysztof Kozlowski wrote: > On 18/10/2023 18:18, Chris Morgan wrote: > > From: Chris Morgan > > > > The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and > > powered by the Rockchip RK3566 SoC. > > > > Signed-off-by: Chris Morgan > > --- > > Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml > > b/Documentation/devicetree/bindings/arm/rockchip.yaml > > index a349bf4da6bc..a6612185a7ff 100644 > > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml > > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > > @@ -674,6 +674,11 @@ properties: > >- const: powkiddy,rgb30 > >- const: rockchip,rk3566 > > > > + - description: Powkiddy RK2023 > > +items: > > + - const: powkiddy,rk2023 > > This cuold be just enum in previous entry :/ but I remember we talked > about this once with Heiko. For hardware that requires a different device tree, is that possible? While most of the devices I've worked on for the RK3566 series are very similar for the moment only 1 is identical (the RG353P and the RG353M) and can use the same device tree. Also I have one more Powkiddy device to send probably in the next week or two, then I'll be breaking for a while from new devices. :-) Thank you, Chris > > Acked-by: Krzysztof Kozlowski > > > + - const: rockchip,rk3566 > > > > Best regards, > Krzysztof >
Re: [PATCH RFC v6 01/10] drm: Introduce pixel_source DRM plane property
For the uAPI: Acked-by: Simon Ser
[PATCH] drm/mgag200: Flush the cache to improve latency
We found a regression in v5.10 on real-time server, using the
rt-kernel and the mgag200 driver. It's some really specialized
workload, with <10us latency expectation on isolated core.
After the v5.10, the real time tasks missed their <10us latency
when something prints on the screen (fbcon or printk)
The regression has been bisected to 2 commits:
0b34d58b6c32 ("drm/mgag200: Enable caching for SHMEM pages")
4862ffaec523 ("drm/mgag200: Move vmap out of commit tail")
The first one changed the system memory framebuffer from Write-Combine
to the default caching.
Before the second commit, the mgag200 driver used to unmap the
framebuffer after each frame, which implicitly does a cache flush.
Both regressions are fixed by the following patch, which forces a
cache flush after each frame, reverting to almost v5.9 behavior.
This is necessary only if you have strong realtime constraints, so I
put the cache flush under the CONFIG_PREEMPT_RT config flag.
Also clflush is only availabe on x86, (and this issue has only been
reproduced on x86_64) so it's also under the CONFIG_X86 config flag.
Fixes: 0b34d58b6c32 ("drm/mgag200: Enable caching for SHMEM pages")
Fixes: 4862ffaec523 ("drm/mgag200: Move vmap out of commit tail")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index af3ce5a6a636..11660cd29cea 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
#include
@@ -436,6 +437,10 @@ static void mgag200_handle_damage(struct mga_device *mdev,
const struct iosys_ma
iosys_map_incr(, drm_fb_clip_offset(fb->pitches[0], fb->format,
clip));
drm_fb_memcpy(, fb->pitches, vmap, fb, clip);
+ /* On RT systems, flushing the cache reduces the latency for other RT
tasks */
+#if defined(CONFIG_X86) && defined(CONFIG_PREEMPT_RT)
+ drm_clflush_virt_range(vmap, fb->height * fb->pitches[0]);
+#endif
}
/*
base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
--
2.41.0
Re: [PATCH v1] dynamic_debug: add support for logs destination
śr., 18 paź 2023 o 05:08 napisał(a): > > adding in Jason, not sure how he got missed. > > On Mon, Oct 16, 2023 at 9:13 AM Łukasz Bartosik wrote: > > > > czw., 12 paź 2023 o 20:48 napisał(a): > > > > > > > If you want the kernel to keep separate flight recorders I guess we > > > > could > > > > add that, but I don't think it currently exists for the dyndbg stuff at > > > > least. Maybe a flight recorder v2 feature, once the basics are in. > > > > > > > > > > dyndbg has +pwrites to syslog > > > +T would separately independently write the same to global trace > > > > > > This would allow graceful switchover to tracefs, > > > without removing logging from dmesg, where most folks > > > (and any monitor tools) would expect it. > > > > > > Lukas (iiuc) wants to steer each site to just 1 destination. > > > Or maybe (in addition to +p > syslog) one trace destination, > > > either global via events, or a separate tracebuf > > > > > > Im ambivalent, but thinking the smooth rollover from syslog to trace > > > might be worth having to ease migration / weaning off syslog. > > > > > > And we have a 4 byte hole in struct _ddebug we could just use. > > > > I'm glad you brought that up. This means we can leave class_id field > > untouched, have separate +T in flags (for consistency) > > and dst_id can be easily 8 bits wide. > > > > Also can you point me to the latest version of writing debug logs to > > trace events (+T option). > > I would like to base trace instances work on that because both are > > closely related. > > > > Ive got 3 branches, all stacked up on rc6 > (last I checked, they were clean on drm-tip) > > https://github.com/jimc/linux/tree/dd-fix-7c > the regression fix, reposting this version next. > it also grabs another flag bit: _DPRINTK_FLAGS_INCL_LOOKUP > > > https://github.com/jimc/linux/tree/dd-shrink-3b > split modname,filename,function to new __dyndbg_sites section > loads the 3 column values and their intervals into 3 maple trees > and implements 3 accessor functions to retrieve the vals > from the descriptor addresses. > it "works" but doesnt erase intervals properly on rmmod > it also claims another flag - _DPRINTK_FLAGS_PREFIX_CACHED > and uses it to mark cached prefix fragment that get created for enabled calls. > > https://github.com/jimc/linux/tree/dd-kitchen-sink > this adds the +T flag stuff. > its still a little fuzzy, esp around the descriptor arg - > using it to render the prefix str at buffer-render time > got UNSAFE warnings - likely due to loadable module > descriptors which could or did go away between > capture and render (after rmmod) > Great, I will use commits related to adding +T from this tree as a baseline for adding trace instances. > > > > > > Unless the align 8 is optional on 32-bits, > > > > I verified with "gcc -g -m32 ..." that the align(8) is honored on 32 bits. > > > > this is sorta the opposite of what I was probing, but I think result > is the same. > istm align(8) is only for JUMP_LABEL, nothing else in the struct > appears to need it > so moving it to the top trades the hole for padding. > Ahh I see what you meant now. Although I have to admit that looking at the jump label code and static key usage cases around the kernel code I don't see where align(8) requirement for jump label comes from. > > > > > I think we're never gonna close the hole anywhere. > > > > > > > :) > > > > > is align 8 a generic expression of an architectural simplifying > > > constraint ? > > > or a need for 1-7 ptr offsets ? > > > > > > > > > > > > > > > > > That's my idea of it. It is interesting to see how far the > > > > > requirements > > > > > can be reasonably realised. > > > > > > > > I think aside from the "make it available directly to unpriviledged > > > > userspace" everything sounds reasonable and doable. > > > > > > > > More on the process side of things, I think Jim is very much looking for > > > > acks and tested-by by people who are interested in better drm logging > > > > infra. That should help that things are moving in a direction that's > > > > actually useful, even when it's not yet entirely complete. > > > > > > > > > > yes, please. Now posted at > > > > > > https://lore.kernel.org/lkml/20231012172137.3286566-1-jim.cro...@gmail.com/T/#t > > > > > > Lukas, I managed to miss your email in the send phase. > > > please consider yourself a direct recipient :-) > > > > > > thanks everyone > > > > > > > Cheers, Sima > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > http://blog.ffwll.ch
Re: [PATCH] drm/msm/dp: cleanup debugfs handling
On Thu, 19 Oct 2023 at 15:33, Abhinav Kumar wrote: > > > > On 10/19/2023 3:44 AM, Dmitry Baryshkov wrote: > > Currently there are two subdirs for DP debugfs files, e.g. DP-1, created > > by the drm core for the connector, and the msm_dp-DP-1, created by the > > DP driver itself. Merge those two, so that there are no extraneous > > connector-related subdirs. > > > > Signed-off-by: Dmitry Baryshkov > > --- > > > One concern with this is, we are migrating from one debugfs per > dp_display to one debugfs per bridge. > > Today we create one bridge per dp_display so its fine. > > With MST, I am unsure if there will be changes needed. For MST the add_connector callback creates a new connector with its own implementation of drm_connector_funcs. So if necessary we can create debugfs files for this new connector. > But, we will figure that out once we add that support, > > Hence, > > Reviewed-by: Abhinav Kumar -- With best wishes Dmitry
Re: [PATCH] drm/msm/dp: cleanup debugfs handling
On 10/19/2023 3:44 AM, Dmitry Baryshkov wrote:
Currently there are two subdirs for DP debugfs files, e.g. DP-1, created
by the drm core for the connector, and the msm_dp-DP-1, created by the
DP driver itself. Merge those two, so that there are no extraneous
connector-related subdirs.
Signed-off-by: Dmitry Baryshkov
---
One concern with this is, we are migrating from one debugfs per
dp_display to one debugfs per bridge.
Today we create one bridge per dp_display so its fine.
With MST, I am unsure if there will be changes needed.
But, we will figure that out once we add that support,
Hence,
Reviewed-by: Abhinav Kumar
Overall, nice cleanup!
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 ---
drivers/gpu/drm/msm/dp/dp_debug.c | 69 ++---
drivers/gpu/drm/msm/dp/dp_debug.h | 23 +++--
drivers/gpu/drm/msm/dp/dp_display.c | 5 +-
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dp/dp_drm.c | 16 ++
drivers/gpu/drm/msm/msm_drv.h | 6 ---
7 files changed, 42 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index fe7267b3bff5..f15cf7592212 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -275,8 +275,6 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct
drm_minor *minor)
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
struct drm_device *dev;
- struct msm_drm_private *priv;
- int i;
if (!p)
return -EINVAL;
@@ -286,7 +284,6 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct
drm_minor *minor)
return 0;
dev = dpu_kms->dev;
- priv = dev->dev_private;
entry = debugfs_create_dir("debug", minor->debugfs_root);
@@ -297,11 +294,6 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct drm_minor *minor)
dpu_debugfs_core_irq_init(dpu_kms, entry);
dpu_debugfs_sspp_init(dpu_kms, entry);
- for (i = 0; i < ARRAY_SIZE(priv->dp); i++) {
- if (priv->dp[i])
- msm_dp_debugfs_init(priv->dp[i], minor);
- }
-
return dpu_core_perf_debugfs_init(dpu_kms, entry);
}
#endif
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 3bba901afe33..6c281dc095b9 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -19,13 +19,9 @@
#define DEBUG_NAME "msm_dp"
struct dp_debug_private {
- struct dentry *root;
-
struct dp_link *link;
struct dp_panel *panel;
struct drm_connector *connector;
- struct device *dev;
- struct drm_device *drm_dev;
struct dp_debug dp_debug;
};
@@ -204,35 +200,33 @@ static const struct file_operations test_active_fops = {
.write = dp_test_active_write
};
-static void dp_debug_init(struct dp_debug *dp_debug, struct drm_minor *minor)
+static void dp_debug_init(struct dp_debug *dp_debug, struct dentry *root, bool
is_edp)
{
- char path[64];
struct dp_debug_private *debug = container_of(dp_debug,
struct dp_debug_private, dp_debug);
- snprintf(path, sizeof(path), "msm_dp-%s", debug->connector->name);
-
- debug->root = debugfs_create_dir(path, minor->debugfs_root);
-
- debugfs_create_file("dp_debug", 0444, debug->root,
+ debugfs_create_file("dp_debug", 0444, root,
debug, _debug_fops);
- debugfs_create_file("msm_dp_test_active", 0444,
- debug->root,
- debug, _active_fops);
+ if (!is_edp) {
+ debugfs_create_file("msm_dp_test_active", 0444,
+ root,
+ debug, _active_fops);
- debugfs_create_file("msm_dp_test_data", 0444,
- debug->root,
- debug, _test_data_fops);
+ debugfs_create_file("msm_dp_test_data", 0444,
+ root,
+ debug, _test_data_fops);
- debugfs_create_file("msm_dp_test_type", 0444,
- debug->root,
- debug, _test_type_fops);
+ debugfs_create_file("msm_dp_test_type", 0444,
+ root,
+ debug, _test_type_fops);
+ }
}
struct dp_debug *dp_debug_get(struct device *dev, struct dp_panel *panel,
struct dp_link *link,
- struct drm_connector *connector, struct drm_minor *minor)
+ struct drm_connector *connector,
+ struct dentry *root, bool is_edp)
{
struct dp_debug_private *debug;
struct dp_debug *dp_debug;
@@ -253,46 +247,15 @@ struct dp_debug *dp_debug_get(struct device *dev, struct
dp_panel
Re: (subset) [PATCH v1] dt-bindings: backlight: add brightness-levels related common properties
On Mon, 16 Oct 2023 17:05:54 +0200, Flavio Suligoi wrote: > Both files pwm-backlight.yaml and led-backlight.yaml contain properties > in common with each other, regarding the brightness levels: > > - brightness-levels > - default-brightness-level > > These properties can then be moved to backlight/common.yaml. > > [...] Applied, thanks! [1/1] dt-bindings: backlight: add brightness-levels related common properties commit: d5272d39995f4150062a67e6f2cef556edece740 -- Lee Jones [李琼斯]
[Bug 215631] Some Desktop oriented mode setting drivers are missing DRM PRIME support
https://bugzilla.kernel.org/show_bug.cgi?id=215631 bluescreen_aven...@verizon.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #2 from bluescreen_aven...@verizon.net --- I think 6b85aa68d9d5a27556b8b1015e7e515a371e77de 71e801b9b44f86ce8c816b06960c705f901c50e5 71a7974ac7019afeec105a54447ae1dc7216cbb3 resolve this -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v10 20/24] drm/mediatek: Add Padding to OVL adaptor
[PULL] drm-misc-fixes
Hi Dave and Daniel, this is the PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2023-10-19: Short summary of fixes pull: amdgpu: - Disable AMD_CTX_PRIORITY_UNSET bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup The following changes since commit c1165df2be2fffe3adeeaa68f4ee4325108c5e4e: drm/tiny: correctly print `struct resource *` on error (2023-10-12 10:57:07 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-10-19 for you to fetch changes up to 8f5ad367e8b884772945c6c9fb622ac94b7d3e32: accel/ivpu: Extend address range for MMU mmap (2023-10-19 08:01:20 +0200) Short summary of fixes pull: amdgpu: - Disable AMD_CTX_PRIORITY_UNSET bridge: - ti-sn65dsi86: Fix device lifetime edid: - Add quirk for BenQ GW2765 ivpu: - Extend address range for MMU mmap nouveau: - DP-connector fixes - Documentation fixes panel: - Move AUX B116XW03 into panel-simple scheduler: - Eliminate DRM_SCHED_PRIORITY_UNSET ttm: - Fix possible NULL-ptr deref in cleanup Douglas Anderson (1): drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple Hamza Mahfooz (1): drm/edid: add 8 bpc quirk to the BenQ GW2765 Jacek Lawrynowicz (1): accel/ivpu: Don't enter d0i3 during FLR Karol Herbst (1): drm/nouveau/disp: fix DP capable DSM connectors Karolina Stolarek (1): drm/ttm: Reorder sys manager cleanup step Luben Tuikov (2): drm/amdgpu: Unset context priority is now invalid gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET Randy Dunlap (1): drm/nouveau: exec: fix ioctl kernel-doc warning Stanislaw Gruszka (1): Revert "accel/ivpu: Use cached buffers for FW loading" Stephen Boyd (1): drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device Wludzik, Jozef (1): accel/ivpu: Extend address range for MMU mmap drivers/accel/ivpu/ivpu_drv.c| 11 ++-- drivers/accel/ivpu/ivpu_drv.h| 1 + drivers/accel/ivpu/ivpu_fw.c | 9 +++--- drivers/accel/ivpu/ivpu_gem.h| 5 drivers/accel/ivpu/ivpu_hw.h | 8 ++ drivers/accel/ivpu/ivpu_hw_37xx.c| 1 + drivers/accel/ivpu/ivpu_hw_40xx.c| 1 + drivers/accel/ivpu/ivpu_mmu_context.c| 9 ++ drivers/accel/ivpu/ivpu_pm.c | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 5 ++-- drivers/gpu/drm/bridge/ti-sn65dsi86.c| 14 +- drivers/gpu/drm/drm_edid.c | 3 ++ drivers/gpu/drm/nouveau/nvkm/engine/disp/uconn.c | 14 +- drivers/gpu/drm/panel/panel-edp.c| 29 drivers/gpu/drm/panel/panel-simple.c | 35 drivers/gpu/drm/ttm/ttm_device.c | 8 +++--- include/drm/gpu_scheduler.h | 3 +- include/uapi/drm/nouveau_drm.h | 4 +-- 18 files changed, 96 insertions(+), 67 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
Hi,
Am Donnerstag, 19. Oktober 2023, 13:19:51 CEST schrieb Dmitry Baryshkov:
> On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote:
> > On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
> > > The MIPI DSI links do not fully fall into the DRM callbacks model.
> >
> > Explaining why would help
>
> A kind of explanation comes afterwards, but probably I should change
> the order of the phrases and expand it:
>
> The atomic_pre_enable / atomic_enable and correspondingly
> atomic_disable / atomic_post_disable expect that the bridge links
> follow a simple paradigm: either it is off, or it is on and streaming
> video. Thus, it is fine to just enable the link at the enable time,
> doing some preparations during the pre_enable.
>
> But then it causes several issues with DSI. First, some of the DSI
> bridges and most of the DSI panels would like to send commands over
> the DSI link to setup the device. Next, some of the DSI hosts have
> limitations on sending the commands. The proverbial sunxi DSI host can
> not send DSI commands after the video stream has started. Thus most of
> the panels have opted to send all DSI commands from pre_enable (or
> prepare) callback (before the video stream has started).
>
> However this leaves no good place for the DSI host to power up the DSI
> link. By default the host's pre_enable callback is called after the
> DSI bridge's pre_enable. For quite some time we were powering up the
> DSI link from mode_set. This doesn't look fully correct. And also we
> got into the issue with ps8640 bridge, which requires for the DSI link
> to be quiet / unpowered at the bridge's reset time.
There are also bridges (e.g. tc358767) which require DSI-LP11 upon bridge
reset. And additionally this DSI-(e)DP bridge requires LP11 while accessing
DP-AUX channel, e.g. reading EDID. So bridges need at least some control over
DSI line state.
> Dave has come with the idea of pre_enable_prev_first /
> prepare_prev_first flags, which attempt to solve the issue by
> reversing the order of pre_enable callbacks. This mostly solves the
> issue. However during this cycle it became obvious that this approach
> is not ideal too. There is no way for the DSI host to know whether the
> DSI panel / bridge has been updated to use this flag or not, see the
> discussion at [1].
>
> Thus comes this proposal. It allows for the panels to explicitly bring
> the link up and down at the correct time, it supports automatic use
> case, where no special handling is required. And last, but not least,
> it allows the DSI host to note that the bridge / panel were not
> updated to follow new protocol and thus the link should be powered on
> at the mode_set time. This leaves us with the possibility of dropping
> support for this workaround once all in-kernel drivers are updated.
I want to use this series to support tc358767 properly, because
pre_enable_prev_first is not enough, see AUX channel above. I hope I'll find
any time soon.
Best regards,
Alexander
>
> > > The drm_bridge_funcs abstraction.
> >
> > Is there a typo or missing words?
>
> missing comma in front of The
>
> > > Instead of having just two states (off and on) the DSI hosts have
> > > separate LP-11 state. In this state the host is on, but the video
> > > stream is not yet enabled.
> > >
> > > Introduce API that allows DSI bridges / panels to control the DSI host
> > > power up state.
>
> [1]
> https://lore.kernel.org/dri-devel/6c0dd9fd-5d8e-537c-804f-7a03d5899a07@lina
> ro.org/
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > >
> > > drivers/gpu/drm/drm_mipi_dsi.c | 31 +++
> > > include/drm/drm_mipi_dsi.h | 29 +
> > > 2 files changed, 56 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c
> > > b/drivers/gpu/drm/drm_mipi_dsi.c index 14201f73aab1..c467162cb7d8
> > > 100644
> > > --- a/drivers/gpu/drm/drm_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> > > @@ -428,6 +428,37 @@ int devm_mipi_dsi_attach(struct device *dev,
> > >
> > > }
> > > EXPORT_SYMBOL_GPL(devm_mipi_dsi_attach);
> > >
> > > +bool mipi_dsi_host_power_control_available(struct mipi_dsi_host *host)
> > > +{
> > > + const struct mipi_dsi_host_ops *ops = host->ops;
> > > +
> > > + return ops && ops->power_up;
> > > +}
> > > +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_control_available);
> > > +
> > > +int mipi_dsi_host_power_up(struct mipi_dsi_host *host)
> > > +{
> > > + const struct mipi_dsi_host_ops *ops = host->ops;
> > > +
> > > + if (!mipi_dsi_host_power_control_available(host))
> > > + return -EOPNOTSUPP;
> > > +
> > > + return ops->power_up ? ops->power_up(host) : 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_up);
> > > +
> > > +void mipi_dsi_host_power_down(struct mipi_dsi_host *host)
> > > +{
> > > + const struct mipi_dsi_host_ops *ops = host->ops;
> > > +
> > > + if
[PULL] drm-misc-next
drm-misc-next-2023-10-19: drm-misc-next for v6.7-rc1: UAPI Changes: Cross-subsystem Changes: - Update maintainers entry for megachips STDPx-GE-B850V3-FW. Core Changes: - Add VM_BIND async document. - Dual-license drm_gpuvm to GPL-2.0 OR MIT. Driver Changes: - Assorted small fixes in ivpu, bridge/megachips, ssd130x, st7703, bridge/lt9611uxc, rockchip. - Handle differences between various adv7511 chips better, and improve HPD handling. - Clock fixes for bridge/synopsis dw-mipi-dsi. - Add Powkiddy RGB30 support to st7703. - Add driver and DT support for ssd132x OLED controller to ssd130x. The following changes since commit c395c83aafbb9cdbe4230f044d5b8eaf9080c0c5: drm/simpledrm: Fix power domain device link validity check (2023-10-12 10:39:48 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-10-19 for you to fetch changes up to 2d23e7d6bacb779c4a740dbd5e18978fb075d15e: dt-bindings: display: Add SSD132x OLED controllers (2023-10-18 09:53:33 +0200) drm-misc-next for v6.7-rc1: UAPI Changes: Cross-subsystem Changes: - Update maintainers entry for megachips STDPx-GE-B850V3-FW. Core Changes: - Add VM_BIND async document. - Dual-license drm_gpuvm to GPL-2.0 OR MIT. Driver Changes: - Assorted small fixes in ivpu, bridge/megachips, ssd130x, st7703, bridge/lt9611uxc, rockchip. - Handle differences between various adv7511 chips better, and improve HPD handling. - Clock fixes for bridge/synopsis dw-mipi-dsi. - Add Powkiddy RGB30 support to st7703. - Add driver and DT support for ssd132x OLED controller to ssd130x. Andy Yan (2): drm/rockchip: remove unused struct in vop2 drm/rockchip: remove NR_LAYERS macro on vop2 Biju Das (8): drm: adv7511: Add struct adv7511_chip_info and use i2c_get_match_data() drm: adv7511: Add max_mode_clock_khz variable to struct adv7511_chip_info drm: adv7511: Add max_lane_freq_khz variable to struct adv7511_chip_info drm: adv7511: Add supply_names and num_supplies variables to struct adv7511_chip_info drm: adv7511: Add reg_cec_offset variable to struct adv7511_chip_info drm: adv7511: Add has_dsi variable to struct adv7511_chip_info drm: adv7511: Add link_config variable to struct adv7511_chip_info drm: adv7511: Add hpd_override_enable variable to struct adv7511_chip_info Chris Morgan (3): dt-bindings: vendor-prefixes: document Powkiddy dt-bindings: panel: Add Powkiddy RGB30 panel compatible drm/panel: st7703: Add Powkiddy RGB30 Panel Support Dan Carpenter (1): drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map() Dmitry Baryshkov (1): drm/bridge: lt9611uxc: fix the race in the error path Frank Oltmanns (1): drm/panel: st7703: Fix timings when entering/exiting sleep Ian Ray (2): drm/bridge: megachips-stdp-ge-b850v3-fw: switch to drm_do_get_edid() MAINTAINERS: Update entry for megachips-stdp-ge-b850v3-fw Jacek Lawrynowicz (1): accel/ivpu: Add ivpu_bo_vaddr() and ivpu_bo_size() Javier Martinez Canillas (6): drm/ssd130x: Replace .page_height field in device info with a constant drm/ssd130x: Add a controller family id to the device info data drm/ssd130x: Rename commands that are shared across chip families drm/ssd130x: Add support for the SSD132x OLED controller family dt-bindings: display: Split common Solomon properties in their own schema dt-bindings: display: Add SSD132x OLED controllers Liu Ying (9): drm/bridge: synopsys: dw-mipi-dsi: Add dw_mipi_dsi_get_bridge() helper drm/bridge: synopsys: dw-mipi-dsi: Add input bus format negotiation support drm/bridge: synopsys: dw-mipi-dsi: Force input bus flags drm/bridge: synopsys: dw-mipi-dsi: Add mode fixup support drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbcc drm/bridge: synopsys: dw-mipi-dsi: Set minimum lane byte clock cycles for HSA and HBP drm/bridge: synopsys: dw-mipi-dsi: Disable HSTX and LPRX timeout check dt-bindings: display: bridge: Document Freescale i.MX93 MIPI DSI drm/bridge: imx: Add i.MX93 MIPI DSI support Ondrej Jirman (1): drm/panel: st7703: Pick different reset sequence Thomas Hellström (2): Documentation/gpu: Add a VM_BIND async document drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MIT Thomas Zimmermann (1): drm/ssd130x: Fix atomic_check for disabled planes .../display/bridge/fsl,imx93-mipi-dsi.yaml | 115 +++ .../display/panel/rocktech,jh057n00900.yaml| 2 + .../bindings/display/solomon,ssd-common.yaml | 42 + .../bindings/display/solomon,ssd1307fb.yaml| 28 +- .../bindings/display/solomon,ssd132x.yaml | 89 ++
Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023
Am Donnerstag, 19. Oktober 2023, 11:21:47 CEST schrieb Krzysztof Kozlowski: > On 18/10/2023 18:18, Chris Morgan wrote: > > From: Chris Morgan > > > > The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and > > powered by the Rockchip RK3566 SoC. > > > > Signed-off-by: Chris Morgan > > --- > > Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml > > b/Documentation/devicetree/bindings/arm/rockchip.yaml > > index a349bf4da6bc..a6612185a7ff 100644 > > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml > > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > > @@ -674,6 +674,11 @@ properties: > >- const: powkiddy,rgb30 > >- const: rockchip,rk3566 > > > > + - description: Powkiddy RK2023 > > +items: > > + - const: powkiddy,rk2023 > > This cuold be just enum in previous entry :/ but I remember we talked > about this once with Heiko. Keeping similar devices together is perfectly fine. Like we do for example with the Rock PI 4A/4A+/B/B+/C family directly below. The powkiddy,rk2023 really looks like very similar to the rgb30, so could do something similar. The variant I don't like is having one big enum for _all_ boards using the same soc. Heiko > Acked-by: Krzysztof Kozlowski > > > + - const: rockchip,rk3566 > > > > Best regards, > Krzysztof > >
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Thu, 19 Oct 2023 at 12:26, Maxime Ripard wrote:
>
> On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
> > The MIPI DSI links do not fully fall into the DRM callbacks model.
>
> Explaining why would help
A kind of explanation comes afterwards, but probably I should change
the order of the phrases and expand it:
The atomic_pre_enable / atomic_enable and correspondingly
atomic_disable / atomic_post_disable expect that the bridge links
follow a simple paradigm: either it is off, or it is on and streaming
video. Thus, it is fine to just enable the link at the enable time,
doing some preparations during the pre_enable.
But then it causes several issues with DSI. First, some of the DSI
bridges and most of the DSI panels would like to send commands over
the DSI link to setup the device. Next, some of the DSI hosts have
limitations on sending the commands. The proverbial sunxi DSI host can
not send DSI commands after the video stream has started. Thus most of
the panels have opted to send all DSI commands from pre_enable (or
prepare) callback (before the video stream has started).
However this leaves no good place for the DSI host to power up the DSI
link. By default the host's pre_enable callback is called after the
DSI bridge's pre_enable. For quite some time we were powering up the
DSI link from mode_set. This doesn't look fully correct. And also we
got into the issue with ps8640 bridge, which requires for the DSI link
to be quiet / unpowered at the bridge's reset time.
Dave has come with the idea of pre_enable_prev_first /
prepare_prev_first flags, which attempt to solve the issue by
reversing the order of pre_enable callbacks. This mostly solves the
issue. However during this cycle it became obvious that this approach
is not ideal too. There is no way for the DSI host to know whether the
DSI panel / bridge has been updated to use this flag or not, see the
discussion at [1].
Thus comes this proposal. It allows for the panels to explicitly bring
the link up and down at the correct time, it supports automatic use
case, where no special handling is required. And last, but not least,
it allows the DSI host to note that the bridge / panel were not
updated to follow new protocol and thus the link should be powered on
at the mode_set time. This leaves us with the possibility of dropping
support for this workaround once all in-kernel drivers are updated.
> > The drm_bridge_funcs abstraction.
>
> Is there a typo or missing words?
missing comma in front of The
>
> > Instead of having just two states (off and on) the DSI hosts have
> > separate LP-11 state. In this state the host is on, but the video
> > stream is not yet enabled.
> >
> > Introduce API that allows DSI bridges / panels to control the DSI host
> > power up state.
[1]
https://lore.kernel.org/dri-devel/6c0dd9fd-5d8e-537c-804f-7a03d5899...@linaro.org/
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/drm_mipi_dsi.c | 31 +++
> > include/drm/drm_mipi_dsi.h | 29 +
> > 2 files changed, 56 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> > index 14201f73aab1..c467162cb7d8 100644
> > --- a/drivers/gpu/drm/drm_mipi_dsi.c
> > +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> > @@ -428,6 +428,37 @@ int devm_mipi_dsi_attach(struct device *dev,
> > }
> > EXPORT_SYMBOL_GPL(devm_mipi_dsi_attach);
> >
> > +bool mipi_dsi_host_power_control_available(struct mipi_dsi_host *host)
> > +{
> > + const struct mipi_dsi_host_ops *ops = host->ops;
> > +
> > + return ops && ops->power_up;
> > +}
> > +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_control_available);
> > +
> > +int mipi_dsi_host_power_up(struct mipi_dsi_host *host)
> > +{
> > + const struct mipi_dsi_host_ops *ops = host->ops;
> > +
> > + if (!mipi_dsi_host_power_control_available(host))
> > + return -EOPNOTSUPP;
> > +
> > + return ops->power_up ? ops->power_up(host) : 0;
> > +}
> > +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_up);
> > +
> > +void mipi_dsi_host_power_down(struct mipi_dsi_host *host)
> > +{
> > + const struct mipi_dsi_host_ops *ops = host->ops;
> > +
> > + if (!mipi_dsi_host_power_control_available(host))
> > + return;
> > +
> > + if (ops->power_down)
> > + ops->power_down(host);
> > +}
> > +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_down);
> > +
>
> If this API is supposed to be used by DSI devices, it should probably
> take a mipi_dsi_device pointer as a parameter?
Ack.
>
> We should probably make sure it hasn't been powered on already too?
Ack, I can add an atomic count there and a WARN_ON. However I don't
think that it is a real problem.
>
> Maxime
--
With best wishes
Dmitry
Re: [PATCH] drm/loongson: Add support for the DC in LS2K1000 SoC
Hi, On 2023/10/19 16:11, Maxime Ripard wrote: On Fri, Oct 13, 2023 at 06:28:01PM +0800, Sui Jingfeng wrote: Hi, On 2023/10/13 16:22, Icenowy Zheng wrote: 在 2023-10-12星期四的 00:26 +0800，Sui Jingfeng写道： LS2K1000 is a low end SoC (two core 1.0gHz), it don't has dedicated VRAM. It requires the framebuffer to be phisically continguous to scanout. The display controller in LS2K1000 don't has built-in GPIO hardware, the structure (register bit field) of its pixel, DC, GPU, DDR PLL are also defferent from other model. But for the display controller itself, Most of hardware features of it are same with ls7a1000. Below is a simple dts for it. Why don't you write a proper, YAML-formatted binding? This patch use only one DT property, that is the "memory-region = <_reserved>;". But the memory-region property is a common property, I means that everyone know how to use this property. I'm not sure the if YAML documentation is strictly required now. AFAIK it is, and even if it's not, please do it. OK, thanks a lot for the feedback. I will try to solve this problem at the next version. I'm preparing the next version. Maxime
Re: [PATCH v3 1/3] pwm: make it possible to apply pwm changes in atomic context
On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote: > Hi Sean, > > On 10/17/23 11:17, Sean Young wrote: > > Some drivers require sleeping, for example if the pwm device is connected > > over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc > > with the generated IR signal when sleeping occurs. > > > > This patch makes it possible to use pwm when the driver does not sleep, > > by introducing the pwm_can_sleep() function. > > > > Signed-off-by: Sean Young > > I have no objection to this patch by itself, but it seems a bit > of unnecessary churn to change all current callers of pwm_apply_state() > to a new API. The idea is to improve the semantic of the function name, see https://lore.kernel.org/linux-pwm/20231013180449.mcdmklbsz2rly...@pengutronix.de for more context. I think it's very subjective if you consider this churn or not. While it's nice to have every caller converted in a single step, I'd go for #define pwm_apply_state(pwm, state) pwm_apply_cansleep(pwm, state) , keep that macro for a while and convert all users step by step. This way we don't needlessly break oot code and the changes to convert to the new API can go via their usual trees without time pressure. > Why not just keep pwm_apply_state() as is and introduce a new > pwm_apply_state_atomic() for callers which want to apply state > in a case where sleeping is not allowed ? There is a big spontaneous growth of function name patterns. I didn't claim having done a complete research, but not using a suffix for the fast variant and _cansleep for the sleeping one at least aligns to how the gpio subsystem names things. Grepping a bit more: - regmap has: regmap_might_sleep() and struct regmap::can_sleep The actual API doesn't have different functions to differentiate sleeping and non-sleeping calls. (Though there is regmap_read_poll_timeout_atomic().) - kmap() + kmap_atomic() - set_pte() + set_pte_atomic() - There is scmi_is_transport_atomic() and scmi_handle::is_transport_atomic() (Is this also about sleeping?) - There are quite a lot more symbols ending in _atomic and in _cansleep, but several of them don't exists to differentiate a slow and a fast procedure. (e.g. drm_mode_atomic) Not entirely sure what to read out of that. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH] drm/doc: ci: Require more context for flaky tests
On Thu, Oct 19, 2023 at 11:46:09AM +0200, Maxime Ripard wrote:
> Flaky tests can be very difficult to reproduce after the facts, which
> will make it even harder to ever fix.
>
> Let's document the metadata we agreed on to provide more context to
> anyone trying to address these fixes.
>
> Link:
> https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/
> Signed-off-by: Maxime Ripard
Not that my opinion matters much since I'm really not involved in the
details, and no opinion on the specific format and all that, but this
sounds like a very good idea too me.
Acked-by: Daniel Vetter
Cheers, Sima
> ---
> Documentation/gpu/automated_testing.rst | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/gpu/automated_testing.rst
> b/Documentation/gpu/automated_testing.rst
> index 469b6fb65c30..2dd0e221c2c3 100644
> --- a/Documentation/gpu/automated_testing.rst
> +++ b/Documentation/gpu/automated_testing.rst
> @@ -67,6 +67,19 @@ Lists the tests that for a given driver on a specific
> hardware revision are
> known to behave unreliably. These tests won't cause a job to fail regardless
> of
> the result. They will still be run.
>
> +Each new flake entry must be associated with a link to a bug report to
> +the author of the affected driver, the board name or Device Tree name of
> +the board, the first kernel version affected, and an approximation of
> +the failure rate.
> +
> +They should be provided under the following format::
> +
> + # Bug Report: $LORE_OR_PATCHWORK_URL
> + # Board Name: broken-board.dtb
> + # Version: 6.6-rc1
> + # Failure Rate: 100
> + flaky-test
> +
> drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
> ---
>
> --
> 2.41.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH RFC v6 01/10] drm: Introduce pixel_source DRM plane property
On Tue, Aug 29, 2023 at 10:48:16AM +0300, Pekka Paalanen wrote: > On Mon, 28 Aug 2023 17:05:07 -0700 > Jessica Zhang wrote: > > > Add support for pixel_source property to drm_plane and related > > documentation. In addition, force pixel_source to > > DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break > > legacy userspace. > > > > This enum property will allow user to specify a pixel source for the > > plane. Possible pixel sources will be defined in the > > drm_plane_pixel_source enum. > > > > Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the > > default value) and DRM_PLANE_PIXEL_SOURCE_NONE. > > > > Signed-off-by: Jessica Zhang > > --- > > drivers/gpu/drm/drm_atomic_state_helper.c | 1 + > > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ > > drivers/gpu/drm/drm_blend.c | 90 > > +++ > > drivers/gpu/drm/drm_plane.c | 19 +-- > > include/drm/drm_blend.h | 2 + > > include/drm/drm_plane.h | 21 > > 6 files changed, 133 insertions(+), 4 deletions(-) > > ... > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > index 6e74de833466..c3c57bae06b7 100644 > > --- a/drivers/gpu/drm/drm_blend.c > > +++ b/drivers/gpu/drm/drm_blend.c > > @@ -185,6 +185,21 @@ > > * plane does not expose the "alpha" property, then this is > > * assumed to be 1.0 > > * > > + * pixel_source: > > + * pixel_source is set up with drm_plane_create_pixel_source_property(). > > + * It is used to toggle the active source of pixel data for the plane. > > + * The plane will only display data from the set pixel_source -- any > > + * data from other sources will be ignored. > > + * > > + * Possible values: > > + * > > + * "NONE": > > + * No active pixel source. > > + * Committing with a NONE pixel source will disable the plane. > > + * > > + * "FB": > > + * Framebuffer source set by the "FB_ID" property. > > + * > > * Note that all the property extensions described here apply either to the > > * plane or the CRTC (e.g. for the background color, which currently is not > > * exposed and assumed to be black). > > This UAPI: > Acked-by: Pekka Paalanen Thanks Jessica, same for me Acked-by: Sebastian Wick > > > Thanks, > pq
[PATCH] drm/msm/dp: cleanup debugfs handling
Currently there are two subdirs for DP debugfs files, e.g. DP-1, created
by the drm core for the connector, and the msm_dp-DP-1, created by the
DP driver itself. Merge those two, so that there are no extraneous
connector-related subdirs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 ---
drivers/gpu/drm/msm/dp/dp_debug.c | 69 ++---
drivers/gpu/drm/msm/dp/dp_debug.h | 23 +++--
drivers/gpu/drm/msm/dp/dp_display.c | 5 +-
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dp/dp_drm.c | 16 ++
drivers/gpu/drm/msm/msm_drv.h | 6 ---
7 files changed, 42 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index fe7267b3bff5..f15cf7592212 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -275,8 +275,6 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct
drm_minor *minor)
void *p = dpu_hw_util_get_log_mask_ptr();
struct dentry *entry;
struct drm_device *dev;
- struct msm_drm_private *priv;
- int i;
if (!p)
return -EINVAL;
@@ -286,7 +284,6 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms, struct
drm_minor *minor)
return 0;
dev = dpu_kms->dev;
- priv = dev->dev_private;
entry = debugfs_create_dir("debug", minor->debugfs_root);
@@ -297,11 +294,6 @@ static int dpu_kms_debugfs_init(struct msm_kms *kms,
struct drm_minor *minor)
dpu_debugfs_core_irq_init(dpu_kms, entry);
dpu_debugfs_sspp_init(dpu_kms, entry);
- for (i = 0; i < ARRAY_SIZE(priv->dp); i++) {
- if (priv->dp[i])
- msm_dp_debugfs_init(priv->dp[i], minor);
- }
-
return dpu_core_perf_debugfs_init(dpu_kms, entry);
}
#endif
diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c
b/drivers/gpu/drm/msm/dp/dp_debug.c
index 3bba901afe33..6c281dc095b9 100644
--- a/drivers/gpu/drm/msm/dp/dp_debug.c
+++ b/drivers/gpu/drm/msm/dp/dp_debug.c
@@ -19,13 +19,9 @@
#define DEBUG_NAME "msm_dp"
struct dp_debug_private {
- struct dentry *root;
-
struct dp_link *link;
struct dp_panel *panel;
struct drm_connector *connector;
- struct device *dev;
- struct drm_device *drm_dev;
struct dp_debug dp_debug;
};
@@ -204,35 +200,33 @@ static const struct file_operations test_active_fops = {
.write = dp_test_active_write
};
-static void dp_debug_init(struct dp_debug *dp_debug, struct drm_minor *minor)
+static void dp_debug_init(struct dp_debug *dp_debug, struct dentry *root, bool
is_edp)
{
- char path[64];
struct dp_debug_private *debug = container_of(dp_debug,
struct dp_debug_private, dp_debug);
- snprintf(path, sizeof(path), "msm_dp-%s", debug->connector->name);
-
- debug->root = debugfs_create_dir(path, minor->debugfs_root);
-
- debugfs_create_file("dp_debug", 0444, debug->root,
+ debugfs_create_file("dp_debug", 0444, root,
debug, _debug_fops);
- debugfs_create_file("msm_dp_test_active", 0444,
- debug->root,
- debug, _active_fops);
+ if (!is_edp) {
+ debugfs_create_file("msm_dp_test_active", 0444,
+ root,
+ debug, _active_fops);
- debugfs_create_file("msm_dp_test_data", 0444,
- debug->root,
- debug, _test_data_fops);
+ debugfs_create_file("msm_dp_test_data", 0444,
+ root,
+ debug, _test_data_fops);
- debugfs_create_file("msm_dp_test_type", 0444,
- debug->root,
- debug, _test_type_fops);
+ debugfs_create_file("msm_dp_test_type", 0444,
+ root,
+ debug, _test_type_fops);
+ }
}
struct dp_debug *dp_debug_get(struct device *dev, struct dp_panel *panel,
struct dp_link *link,
- struct drm_connector *connector, struct drm_minor *minor)
+ struct drm_connector *connector,
+ struct dentry *root, bool is_edp)
{
struct dp_debug_private *debug;
struct dp_debug *dp_debug;
@@ -253,46 +247,15 @@ struct dp_debug *dp_debug_get(struct device *dev, struct
dp_panel *panel,
debug->dp_debug.debug_en = false;
debug->link = link;
debug->panel = panel;
- debug->dev = dev;
- debug->drm_dev = minor->dev;
- debug->connector = connector;
dp_debug = >dp_debug;
dp_debug->vdisplay = 0;
dp_debug->hdisplay = 0;
dp_debug->vrefresh = 0;
- dp_debug_init(dp_debug, minor);
+
Re: [PATCH v10 15/24] drm/mediatek: Remove ineffectual power management codes
Il 19/10/23 11:52, Shawn Sung (宋孝謙) ha scritto:
Hi Angelo,
On Thu, 2023-10-19 at 11:07 +0200, AngeloGioacchino Del Regno wrote:
Il 19/10/23 07:56, Hsiao Chien Sung ha scritto:
Display modules will be powered on when .atomic_enable(),
there is no need to do it again in mtk_crtc_ddp_hw_init().
Besides, the DRM devices are created manually when mtk-mmsys
is probed and there is no power domain linked to it.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
MT8173.")
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index bc4cc75cca18..c7edd80be428 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,7 +6,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -362,22 +361,16 @@ static int mtk_crtc_ddp_hw_init(struct
mtk_drm_crtc *mtk_crtc, struct drm_atomic
drm_connector_list_iter_end(_iter);
}
- ret = pm_runtime_resume_and_get(crtc->dev->dev);
- if (ret < 0) {
- DRM_ERROR("Failed to enable power domain: %d\n", ret);
- return ret;
- }
-
Are you really sure that writes to DISP_REG_OVL_xxx and others in
other modules,
called by the .layer_config() callback, can be successfully done on
an unpowered
and/or unclocked module, on all MediaTek SoCs?
This looks a bit odd.
Not sure if I get your point correctly. We removed this PM API because:
1. mtk_crtc_ddp_hw_init() is called by mtk_drm_crtc_atomic_enable(),
and the new inline function mtk_ddp_comp_power_on() is called before hw
init, we can make sure the power is on before configuring the hardware.
2. The device "crtc->dev->dev" here is assigned by the probe function
of mtk-mmsys, which will be look like "mediatek-drm.auto.13", and this
device is not linked to any power domain.
Thanks for the clarification. In this case:
Reviewed-by: AngeloGioacchino Del Regno
ret = mtk_mutex_prepare(mtk_crtc->mutex);
if (ret < 0) {
DRM_ERROR("Failed to enable mutex clock: %d\n", ret);
- goto err_pm_runtime_put;
+ goto error;
}
ret = mtk_crtc_ddp_clk_enable(mtk_crtc);
if (ret < 0) {
DRM_ERROR("Failed to enable component clocks: %d\n",
ret);
- goto err_mutex_unprepare;
+ goto error;
}
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
@@ -426,16 +419,13 @@ static int mtk_crtc_ddp_hw_init(struct
mtk_drm_crtc *mtk_crtc, struct drm_atomic
...because you could otherwise just call pm_runtime_put() here,
instead of removing
the pm_runtime_resume_and_get() call, which is something I would
advise to do.
Regards,
Angelo
Thanks,
Shawn
Re: [PATCH v10 20/24] drm/mediatek: Add Padding to OVL adaptor
Il 19/10/23 11:20, Shawn Sung (宋孝謙) ha scritto:
Hi Angelo,
On Thu, 2023-10-19 at 11:10 +0200, AngeloGioacchino Del Regno wrote:
static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] =
{
+ { .compatible = "mediatek,mt8188-padding", .data = (void
*)OVL_ADAPTOR_TYPE_PADDING },
Uhm, for consistency I'd call this "mediatek,mt8188-disp-padding"
(you don't have
to drop Reviewed-by tags for such a change, not here and not in the
yaml commit),
but it's fine if you have reasons against that.
So, regardless of this being changed or not
Reviewed-by: AngeloGioacchino Del Regno <
angelogioacchino.delre...@collabora.com>
{ .compatible = "mediatek,mt8195-disp-ethdr", .data = (void
*)OVL_ADAPTOR_TYPE_ETHDR },
{ .compatible = "mediatek,mt8195-disp-merge", .data = (void
*)OVL_ADAPTOR_TYPE_MERGE },
{ .compatible = "mediatek,mt8195-vdo1-rdma", .data = (void
*)OVL_ADAPTOR_TYPE_MDP_RDMA },
Thanks for pointing this out. Had changed Padding driver's name to
"mtk-disp-padding", but I just notice that Padding will also be used by
MDP and they will share the same driver with display. Should we change
the name again or is it just fine to use "mtk-disp-padding"?
That's like many other components in MediaTek, so we can keep the
mtk-disp-padding
name in devicetree, we will anyway use "mediatek,mt8195-mdp3-padding" as
one of
the compatible string(s).
This is the only way that we have to actually distinguish between components
used
for MDP3 and components used for the display subsystem, if we keep them
"generic"
we won't understand what's going on in case of issues.
The driver name should contain "disp" for consistency with all of the component
drivers in mediatek-drm; if this wasn't in this folder, we could've dropped the
"disp" in the name, but that's not the case.
Consistency is #1.
Cheers,
Angelo
Thanks,
Shawn
Re: [PATCH v10 15/24] drm/mediatek: Remove ineffectual power management codes
[PATCH] drm/doc: ci: Require more context for flaky tests
Flaky tests can be very difficult to reproduce after the facts, which
will make it even harder to ever fix.
Let's document the metadata we agreed on to provide more context to
anyone trying to address these fixes.
Link:
https://lore.kernel.org/dri-devel/CAPj87rPbJ1V1-R7WMTHkDat2A4nwSd61Df9mdGH2PR=ZzxaU=q...@mail.gmail.com/
Signed-off-by: Maxime Ripard
---
Documentation/gpu/automated_testing.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/gpu/automated_testing.rst
b/Documentation/gpu/automated_testing.rst
index 469b6fb65c30..2dd0e221c2c3 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -67,6 +67,19 @@ Lists the tests that for a given driver on a specific
hardware revision are
known to behave unreliably. These tests won't cause a job to fail regardless of
the result. They will still be run.
+Each new flake entry must be associated with a link to a bug report to
+the author of the affected driver, the board name or Device Tree name of
+the board, the first kernel version affected, and an approximation of
+the failure rate.
+
+They should be provided under the following format::
+
+ # Bug Report: $LORE_OR_PATCHWORK_URL
+ # Board Name: broken-board.dtb
+ # Version: 6.6-rc1
+ # Failure Rate: 100
+ flaky-test
+
drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt
---
--
2.41.0
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Mon, Oct 16, 2023 at 07:53:48PM +0300, Dmitry Baryshkov wrote:
> The MIPI DSI links do not fully fall into the DRM callbacks model.
Explaining why would help
> The drm_bridge_funcs abstraction.
Is there a typo or missing words?
> Instead of having just two states (off and on) the DSI hosts have
> separate LP-11 state. In this state the host is on, but the video
> stream is not yet enabled.
>
> Introduce API that allows DSI bridges / panels to control the DSI host
> power up state.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 31 +++
> include/drm/drm_mipi_dsi.h | 29 +
> 2 files changed, 56 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index 14201f73aab1..c467162cb7d8 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -428,6 +428,37 @@ int devm_mipi_dsi_attach(struct device *dev,
> }
> EXPORT_SYMBOL_GPL(devm_mipi_dsi_attach);
>
> +bool mipi_dsi_host_power_control_available(struct mipi_dsi_host *host)
> +{
> + const struct mipi_dsi_host_ops *ops = host->ops;
> +
> + return ops && ops->power_up;
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_control_available);
> +
> +int mipi_dsi_host_power_up(struct mipi_dsi_host *host)
> +{
> + const struct mipi_dsi_host_ops *ops = host->ops;
> +
> + if (!mipi_dsi_host_power_control_available(host))
> + return -EOPNOTSUPP;
> +
> + return ops->power_up ? ops->power_up(host) : 0;
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_up);
> +
> +void mipi_dsi_host_power_down(struct mipi_dsi_host *host)
> +{
> + const struct mipi_dsi_host_ops *ops = host->ops;
> +
> + if (!mipi_dsi_host_power_control_available(host))
> + return;
> +
> + if (ops->power_down)
> + ops->power_down(host);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dsi_host_power_down);
> +
If this API is supposed to be used by DSI devices, it should probably
take a mipi_dsi_device pointer as a parameter?
We should probably make sure it hasn't been powered on already too?
Maxime
Re: [PATCH 1/5] dt-bindings: display: panel: Update NewVision NV3051D compatibles
On 18/10/2023 18:18, Chris Morgan wrote: > From: Chris Morgan > > Update the NewVision NV3051D compatible strings by adding a new panel, > the powkiddy,rk2023-panel, and removing another entry, the > anbernic,rg353v-panel. The rg353v-panel is exactly identical to the > rg353p-panel and is not currently in use by any existing device tree. > The rk2023-panel is similar to the rg353p-panel but has slightly > different timings. This still does not explain me why do you want to remove old panel. Best regards, Krzysztof
Re: [PATCH 4/5] dt-bindings: arm: rockchip: Add Powkiddy RK2023
On 18/10/2023 18:18, Chris Morgan wrote: > From: Chris Morgan > > The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and > powered by the Rockchip RK3566 SoC. > > Signed-off-by: Chris Morgan > --- > Documentation/devicetree/bindings/arm/rockchip.yaml | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml > b/Documentation/devicetree/bindings/arm/rockchip.yaml > index a349bf4da6bc..a6612185a7ff 100644 > --- a/Documentation/devicetree/bindings/arm/rockchip.yaml > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > @@ -674,6 +674,11 @@ properties: >- const: powkiddy,rgb30 >- const: rockchip,rk3566 > > + - description: Powkiddy RK2023 > +items: > + - const: powkiddy,rk2023 This cuold be just enum in previous entry :/ but I remember we talked about this once with Heiko. Acked-by: Krzysztof Kozlowski > + - const: rockchip,rk3566 Best regards, Krzysztof
Re: [PATCH v10 20/24] drm/mediatek: Add Padding to OVL adaptor
Re: [PATCH v10 13/24] drm/mediatek: Manage component's clock with function pointers
Il 19/10/23 07:56, Hsiao Chien Sung ha scritto: By registering component related functions to the pointers, we can easily manage them within a for-loop and simplify the logic of clock control significantly. Signed-off-by: Hsiao Chien Sung Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v10 20/24] drm/mediatek: Add Padding to OVL adaptor
Il 19/10/23 07:56, Hsiao Chien Sung ha scritto:
Add MT8188 Padding to OVL adaptor to probe the driver.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
---
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 26 +++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index f46ca1c68610..f693b47745ba 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -29,6 +29,7 @@ enum mtk_ovl_adaptor_comp_type {
OVL_ADAPTOR_TYPE_ETHDR,
OVL_ADAPTOR_TYPE_MDP_RDMA,
OVL_ADAPTOR_TYPE_MERGE,
+ OVL_ADAPTOR_TYPE_PADDING,
OVL_ADAPTOR_TYPE_NUM,
};
@@ -46,6 +47,14 @@ enum mtk_ovl_adaptor_comp_id {
OVL_ADAPTOR_MERGE1,
OVL_ADAPTOR_MERGE2,
OVL_ADAPTOR_MERGE3,
+ OVL_ADAPTOR_PADDING0,
+ OVL_ADAPTOR_PADDING1,
+ OVL_ADAPTOR_PADDING2,
+ OVL_ADAPTOR_PADDING3,
+ OVL_ADAPTOR_PADDING4,
+ OVL_ADAPTOR_PADDING5,
+ OVL_ADAPTOR_PADDING6,
+ OVL_ADAPTOR_PADDING7,
OVL_ADAPTOR_ID_MAX
};
@@ -66,6 +75,7 @@ static const char * const private_comp_stem[OVL_ADAPTOR_TYPE_NUM] = {
[OVL_ADAPTOR_TYPE_ETHDR]= "ethdr",
[OVL_ADAPTOR_TYPE_MDP_RDMA] = "vdo1-rdma",
[OVL_ADAPTOR_TYPE_MERGE]= "merge",
+ [OVL_ADAPTOR_TYPE_PADDING] = "padding",
};
static const struct mtk_ddp_comp_funcs ethdr = {
@@ -80,6 +90,13 @@ static const struct mtk_ddp_comp_funcs merge = {
.clk_disable = mtk_merge_clk_disable,
};
+static const struct mtk_ddp_comp_funcs padding = {
+ .clk_enable = mtk_padding_clk_enable,
+ .clk_disable = mtk_padding_clk_disable,
+ .start = mtk_padding_start,
+ .stop = mtk_padding_stop,
+};
+
static const struct mtk_ddp_comp_funcs rdma = {
.power_on = mtk_mdp_rdma_power_on,
.power_off = mtk_mdp_rdma_power_off,
@@ -101,6 +118,14 @@ static const struct ovl_adaptor_comp_match
comp_matches[OVL_ADAPTOR_ID_MAX] = {
[OVL_ADAPTOR_MERGE1] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE2, 2,
},
[OVL_ADAPTOR_MERGE2] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE3, 3,
},
[OVL_ADAPTOR_MERGE3] = { OVL_ADAPTOR_TYPE_MERGE, DDP_COMPONENT_MERGE4, 4,
},
+ [OVL_ADAPTOR_PADDING0] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING0, 0, },
+ [OVL_ADAPTOR_PADDING1] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING1, 1, },
+ [OVL_ADAPTOR_PADDING2] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING2, 2, },
+ [OVL_ADAPTOR_PADDING3] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING3, 3, },
+ [OVL_ADAPTOR_PADDING4] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING4, 4, },
+ [OVL_ADAPTOR_PADDING5] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING5, 5, },
+ [OVL_ADAPTOR_PADDING6] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING6, 6, },
+ [OVL_ADAPTOR_PADDING7] = { OVL_ADAPTOR_TYPE_PADDING,
DDP_COMPONENT_PADDING7, 7, },
};
void mtk_ovl_adaptor_layer_config(struct device *dev, unsigned int idx,
@@ -436,6 +461,7 @@ static int ovl_adaptor_comp_get_id(struct device *dev,
struct device_node *node,
}
static const struct of_device_id mtk_ovl_adaptor_comp_dt_ids[] = {
+ { .compatible = "mediatek,mt8188-padding", .data = (void
*)OVL_ADAPTOR_TYPE_PADDING },
Uhm, for consistency I'd call this "mediatek,mt8188-disp-padding" (you don't
have
to drop Reviewed-by tags for such a change, not here and not in the yaml
commit),
but it's fine if you have reasons against that.
So, regardless of this being changed or not
Reviewed-by: AngeloGioacchino Del Regno
{ .compatible = "mediatek,mt8195-disp-ethdr", .data = (void
*)OVL_ADAPTOR_TYPE_ETHDR },
{ .compatible = "mediatek,mt8195-disp-merge", .data = (void
*)OVL_ADAPTOR_TYPE_MERGE },
{ .compatible = "mediatek,mt8195-vdo1-rdma", .data = (void
*)OVL_ADAPTOR_TYPE_MDP_RDMA },
Re: [PATCH v10 14/24] drm/mediatek: Power on/off devices with function pointers
Il 19/10/23 07:56, Hsiao Chien Sung ha scritto: Different from OVL, OVL adaptor is a pseudo device so we didn't define it in the device tree, consequently, pm_runtime_resume_and_get() called by .atomic_enable() powers on no device. For this reason, we implement a function to power on the RDMAs in OVL adaptor, and the system will make sure the IOMMUs are powered on as well because of the device link (iommus) in the RDMA nodes in DTS. This patch separates power and clock management process, it would be easier to maintain and extensions. Signed-off-by: Hsiao Chien Sung Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v10 15/24] drm/mediatek: Remove ineffectual power management codes
Il 19/10/23 07:56, Hsiao Chien Sung ha scritto:
Display modules will be powered on when .atomic_enable(),
there is no need to do it again in mtk_crtc_ddp_hw_init().
Besides, the DRM devices are created manually when mtk-mmsys
is probed and there is no power domain linked to it.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsiao Chien Sung
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index bc4cc75cca18..c7edd80be428 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -6,7 +6,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -362,22 +361,16 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc, struct drm_atomic
drm_connector_list_iter_end(_iter);
}
- ret = pm_runtime_resume_and_get(crtc->dev->dev);
- if (ret < 0) {
- DRM_ERROR("Failed to enable power domain: %d\n", ret);
- return ret;
- }
-
Are you really sure that writes to DISP_REG_OVL_xxx and others in other modules,
called by the .layer_config() callback, can be successfully done on an unpowered
and/or unclocked module, on all MediaTek SoCs?
This looks a bit odd.
ret = mtk_mutex_prepare(mtk_crtc->mutex);
if (ret < 0) {
DRM_ERROR("Failed to enable mutex clock: %d\n", ret);
- goto err_pm_runtime_put;
+ goto error;
}
ret = mtk_crtc_ddp_clk_enable(mtk_crtc);
if (ret < 0) {
DRM_ERROR("Failed to enable component clocks: %d\n", ret);
- goto err_mutex_unprepare;
+ goto error;
}
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
@@ -426,16 +419,13 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc, struct drm_atomic
...because you could otherwise just call pm_runtime_put() here, instead of
removing
the pm_runtime_resume_and_get() call, which is something I would advise to do.
Regards,
Angelo
return 0;
-err_mutex_unprepare:
+error:
mtk_mutex_unprepare(mtk_crtc->mutex);
-err_pm_runtime_put:
- pm_runtime_put(crtc->dev->dev);
return ret;
}
static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
{
- struct drm_device *drm = mtk_crtc->base.dev;
struct drm_crtc *crtc = _crtc->base;
int i;
@@ -465,8 +455,6 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
mtk_crtc_ddp_clk_disable(mtk_crtc);
mtk_mutex_unprepare(mtk_crtc->mutex);
- pm_runtime_put(drm->dev);
-
if (crtc->state->event && !crtc->state->active) {
spin_lock_irq(>dev->event_lock);
drm_crtc_send_vblank_event(crtc, crtc->state->event);
Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
Hi,
On 18/10/2023 17:19, Zhao Liu wrote:
Hi Rodrigo and Tvrtko,
It seems this series is missed in v6.5.
This work should not be forgotten. Let me rebase and refresh the version.
Right it seems we did not manage to social engineer any reviews. Please
do respin and we will try again.
Regards,
Tvrtko
Regards,
Zhao
On Mon, Apr 17, 2023 at 10:53:28AM -0400, Rodrigo Vivi wrote:
Date: Mon, 17 Apr 2023 10:53:28 -0400
From: Rodrigo Vivi
Subject: Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in
gem/i915_gem_execbuffer.c
On Mon, Apr 17, 2023 at 12:24:45PM +0100, Tvrtko Ursulin wrote:
On 14/04/2023 11:45, Zhao Liu wrote:
Hi Tvrtko,
On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
[snip]
[snip]
However I am unsure if disabling pagefaulting is needed or not. Thomas,
Matt, being the last to touch this area, perhaps you could have a look?
Because I notice we have a fallback iomap path which still uses
io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion is
safe, does the iomap side also needs converting to
io_mapping_map_local_wc? Or they have separate requirements?
AFAIK, the requirements for io_mapping_map_local_wc() are the same as for
kmap_local_page(): the kernel virtual address is _only_ valid in the caller
context, and map/unmap nesting must be done in stack-based ordering (LIFO).
I think a follow up patch could safely switch to io_mapping_map_local_wc() /
io_mapping_unmap_local_wc since the address is local to context.
However, not being an expert, reading your note now I suspect that I'm missing
something. Can I ask why you think that page-faults disabling might be
necessary?
I am not saying it is, was just unsure and wanted some people who worked on
this code most recently to take a look and confirm.
I guess it will work since the copying is done like this anyway:
/*
* This is the fast path and we cannot handle a pagefault
* whilst holding the struct mutex lest the user pass in the
* relocations contained within a mmaped bo. For in such a case
* we, the page fault handler would call i915_gem_fault() and
* we would try to acquire the struct mutex again. Obviously
* this is bad and so lockdep complains vehemently.
*/
pagefault_disable();
copied = __copy_from_user_inatomic(r, urelocs, count *
sizeof(r[0]));
pagefault_enable();
if (unlikely(copied)) {
remain = -EFAULT;
goto out;
}
Comment is a bit outdated since we don't use that global "struct mutex" any
longer, but in any case, if there is a page fault on the mapping where we need to recurse
into i915 again to satisfy if, we seem to have code already to handle it. So kmap_local
conversion I *think* can't regress anything.
Thanks for your explanation!
Patch to convert the io_mapping_map_atomic_wc can indeed come later.
Okay, I will also look at this.
In terms of logistics - if we landed this series to out branch it would be
queued only for 6.5. Would that work for you?
Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
Yes, but just because we failed to review and merge in time, not because you
did not provide patches in time.
It is worth mentioning that under drm we close the merge window earlier.
Around -rc5.
So, Linus' merge window for 6.4 didn't happen yet. But our drm-next that
is going to be sent there is already closed.
Regards,
Tvrtko
Re: [PATCH v4 13/17] platform/x86/amd/pmf: Add PMF-AMDGPU get interface
Am 18.10.23 um 19:05 schrieb Shyam Sundar S K: On 10/18/2023 9:37 PM, Christian König wrote: Am 18.10.23 um 17:47 schrieb Mario Limonciello: On 10/18/2023 08:40, Christian König wrote: Am 18.10.23 um 11:28 schrieb Shyam Sundar S K: On 10/18/2023 2:50 PM, Ilpo Järvinen wrote: On Wed, 18 Oct 2023, Shyam Sundar S K wrote: In order to provide GPU inputs to TA for the Smart PC solution to work, we need to have interface between the PMF driver and the AMDGPU driver. Add the initial code path for get interface from AMDGPU. Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Signed-off-by: Shyam Sundar S K --- drivers/gpu/drm/amd/amdgpu/Makefile | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c | 138 drivers/platform/x86/amd/pmf/Kconfig | 1 + drivers/platform/x86/amd/pmf/core.c | 1 + drivers/platform/x86/amd/pmf/pmf.h | 3 + drivers/platform/x86/amd/pmf/spc.c | 13 +++ drivers/platform/x86/amd/pmf/tee-if.c | 26 + include/linux/amd-pmf-io.h | 35 ++ 9 files changed, 220 insertions(+) create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c create mode 100644 include/linux/amd-pmf-io.h diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile b/drivers/gpu/drm/amd/amdgpu/Makefile index 384b798a9bad..7fafccefbd7a 100644 --- a/drivers/gpu/drm/amd/amdgpu/Makefile +++ b/drivers/gpu/drm/amd/amdgpu/Makefile @@ -86,6 +86,8 @@ amdgpu-$(CONFIG_PROC_FS) += amdgpu_fdinfo.o amdgpu-$(CONFIG_PERF_EVENTS) += amdgpu_pmu.o +amdgpu-$(CONFIG_AMD_PMF) += amdgpu_pmf.o + # add asic specific block amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o \ dce_v8_0.o gfx_v7_0.o cik_sdma.o uvd_v4_2.o vce_v2_0.o diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index a79d53bdbe13..26ffa1b4fe57 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -50,6 +50,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c new file mode 100644 index ..ac981848df50 --- /dev/null +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmf.c @@ -0,0 +1,138 @@ +/* + * Copyright 2023 Advanced Micro Devices, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. This is MIT, right? Add the required SPDX-License-Identifier line for it at the top of the file, thank you. all the files in drivers/gpu/drm/amd/amdgpu/* carry the same license text. So, have retained it to maintain uniformity. Please add the SPDX License Identifier for any file you add. OK. I thought to keep it same like the other files. I will change this to SPDX in the next revision. Apart from that the whole approach of attaching this directly to amdgpu looks extremely questionable to me. What's the long term outlook for things that are needed directly from amdgpu? Is there going to be more besides the backlight and the display count/type? Yeah, that goes into the same direction as my concern. PMF is an APU only feature and will need inputs from multiple subsystems (in this case its GPU) to send changing system information to PMF TA (Trusted Application, running on ASP/PSP) as input. Its not only about the display count/type and backlight, there are many others things in pipe like the GPU engine running time, utilization percentage etc, that guide the TA to make better decisions. This series is only targeted to build the initial plubming with the subsystems inside the kernel and later keep adding changes to get more information from other subsystems. Yeah, and that's what I strongly disagree on. Don't come up with such an approach without consulting with upstream maintainers first. What you propose here is a system wide framework for improving power management, that's fine.
Re: (subset) [PATCH 0/5] rockchip: Add Powkiddy RK2023
On Wed, 18 Oct 2023 11:18:43 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the Powkiddy RK2023, which is extremely similar to > existing devices from Anbernic. > > Chris Morgan (5): > dt-bindings: display: panel: Update NewVision NV3051D compatibles > drm/panel: nv3051d: Add Powkiddy RK2023 Panel Support > clk: rockchip: rk3568: Add PLL rate for 115.2MHz > dt-bindings: arm: rockchip: Add Powkiddy RK2023 > arm64: dts: rockchip: add Powkiddy RK2023 > > [...] Applied, thanks! [3/5] clk: rockchip: rk3568: Add PLL rate for 115.2MHz commit: ccf59682a0287b81015dc1939203fac70b818c6b I've gone forward and grabbed the PLL rate already, so it can go together with the other rate addition from the fixes series. Best regards, -- Heiko Stuebner
Re: [PATCH 0/2] fbdev/simplefb: Add missing simple-framebuffer features
Maxime Ripard writes:
Hello Maxime,
> Hi,
>
> On Wed, Oct 11, 2023 at 04:38:07PM +0200, Thierry Reding wrote:
>> From: Thierry Reding
>> This contains two patches that bring simplefb up to feature parity with
>> simpledrm. The patches add support for the "memory-region" property that
>> provides an alternative to the "reg" property to describe the memory
>> used for the framebuffer and allow attaching the simple-framebuffer
>> device to one or more generic power domains to make sure they aren't
>> turned off during the boot process and take down the display
>> configuration.
>
> I just talked with Sima about it in the hallway at XDC. I'm fine with
> those patches in principle, but it looks to me that simpledrm doesn't
> have support for power domains and we'll want that :)
>
It has support since commit 61df9ca23107 ("drm/simpledrm: Add support for
multiple "power-domains") AFAIK.
> Thanks!
> Maxime
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH 4/9] dma-buf: heaps: Initialise MediaTek secure heap
On 9/11/2023 8:00 AM, Yong Wu wrote:
> Initialise a mtk_svp heap. Currently just add a null heap, Prepare for
> the later patches.
>
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/Kconfig | 8 ++
> drivers/dma-buf/heaps/Makefile | 1 +
> drivers/dma-buf/heaps/mtk_secure_heap.c | 99 +
> 3 files changed, 108 insertions(+)
> create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c
>
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index a5eef06c4226..729c0cf3eb7c 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -12,3 +12,11 @@ config DMABUF_HEAPS_CMA
> Choose this option to enable dma-buf CMA heap. This heap is backed
> by the Contiguous Memory Allocator (CMA). If your system has these
> regions, you should say Y here.
> +
> +config DMABUF_HEAPS_MTK_SECURE
> + bool "DMA-BUF MediaTek Secure Heap"
> + depends on DMABUF_HEAPS && TEE
> + help
> + Choose this option to enable dma-buf MediaTek secure heap for Secure
> + Video Path. This heap is backed by TEE client interfaces. If in
> + doubt, say N.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index 974467791032..df559dbe33fe 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_MTK_SECURE)+= mtk_secure_heap.o
> diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c
> b/drivers/dma-buf/heaps/mtk_secure_heap.c
> new file mode 100644
> index ..bbf1c8dce23e
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF mtk_secure_heap exporter
> + *
> + * Copyright (C) 2023 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * MediaTek secure (chunk) memory type
> + *
> + * @KREE_MEM_SEC_CM_TZ: static chunk memory carved out for trustzone.
> + */
> +enum kree_mem_type {
> + KREE_MEM_SEC_CM_TZ = 1,
> +};
> +
> +struct mtk_secure_heap_buffer {
> + struct dma_heap *heap;
> + size_t size;
> +};
> +
> +struct mtk_secure_heap {
> + const char *name;
> + const enum kree_mem_type mem_type;
> +};
> +
> +static struct dma_buf *
> +mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
> + unsigned long fd_flags, unsigned long heap_flags)
> +{
> + struct mtk_secure_heap_buffer *sec_buf;
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret;
> +
> + sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
As we know, kzalloc can only allocate 4MB at max. So, secure heap has this
limitation.
can we have a way to allocate more memory in secure heap ? maybe similar to how
system heap does?
Thanks,
Vijay
> + if (!sec_buf)
> + return ERR_PTR(-ENOMEM);
> +
> + sec_buf->size = size;
> + sec_buf->heap = heap;
> +
> + exp_info.exp_name = dma_heap_get_name(heap);
> + exp_info.size = sec_buf->size;
> + exp_info.flags = fd_flags;
> + exp_info.priv = sec_buf;
> +
> + dmabuf = dma_buf_export(_info);
> + if (IS_ERR(dmabuf)) {
> + ret = PTR_ERR(dmabuf);
> + goto err_free_buf;
> + }
> +
> + return dmabuf;
> +
> +err_free_buf:
> + kfree(sec_buf);
> + return ERR_PTR(ret);
> +}
> +
> +static const struct dma_heap_ops mtk_sec_heap_ops = {
> + .allocate = mtk_sec_heap_allocate,
> +};
> +
> +static struct mtk_secure_heap mtk_sec_heap[] = {
> + {
> + .name = "mtk_svp",
> + .mem_type = KREE_MEM_SEC_CM_TZ,
> + },
> +};
> +
> +static int mtk_sec_heap_init(void)
> +{
> + struct mtk_secure_heap *sec_heap = mtk_sec_heap;
> + struct dma_heap_export_info exp_info;
> + struct dma_heap *heap;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(mtk_sec_heap); i++, sec_heap++) {
> + exp_info.name = sec_heap->name;
> + exp_info.ops = _sec_heap_ops;
> + exp_info.priv = (void *)sec_heap;
> +
> + heap = dma_heap_add(_info);
> + if (IS_ERR(heap))
> + return PTR_ERR(heap);
> + }
> + return 0;
> +}
> +
> +module_init(mtk_sec_heap_init);
> +MODULE_DESCRIPTION("MediaTek Secure Heap Driver");
> +MODULE_LICENSE("GPL");
Re: [PATCH 6/9] dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing
On 9/11/2023 8:00 AM, Yong Wu wrote:
> Add TEE service call for secure memory allocating/freeing.
>
> Signed-off-by: Anan Sun
> Signed-off-by: Yong Wu
> ---
> drivers/dma-buf/heaps/mtk_secure_heap.c | 69 -
> 1 file changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c
> b/drivers/dma-buf/heaps/mtk_secure_heap.c
> index e3da33a3d083..14c2a16a7164 100644
> --- a/drivers/dma-buf/heaps/mtk_secure_heap.c
> +++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
> @@ -17,6 +17,9 @@
>
> #define MTK_TEE_PARAM_NUM4
>
> +#define TZCMD_MEM_SECURECM_UNREF 7
> +#define TZCMD_MEM_SECURECM_ZALLOC15
> +
> /*
> * MediaTek secure (chunk) memory type
> *
> @@ -29,6 +32,8 @@ enum kree_mem_type {
> struct mtk_secure_heap_buffer {
> struct dma_heap *heap;
> size_t size;
> +
> + u32 sec_handle;
> };
>
> struct mtk_secure_heap {
> @@ -80,6 +85,63 @@ static int mtk_kree_secure_session_init(struct
> mtk_secure_heap *sec_heap)
> return ret;
> }
>
> +static int
> +mtk_sec_mem_tee_service_call(struct tee_context *tee_ctx, u32 session,
> + unsigned int command, struct tee_param *params)
> +{
> + struct tee_ioctl_invoke_arg arg = {0};
> + int ret;
> +
> + arg.num_params = MTK_TEE_PARAM_NUM;
> + arg.session = session;
> + arg.func = command;
> +
> + ret = tee_client_invoke_func(tee_ctx, , params);
> + if (ret < 0 || arg.ret) {
> + pr_err("%s: cmd %d ret %d:%x.\n", __func__, command, ret,
> arg.ret);
> + ret = -EOPNOTSUPP;
> + }
> + return ret;
> +}
> +
> +static int mtk_sec_mem_allocate(struct mtk_secure_heap *sec_heap,
> + struct mtk_secure_heap_buffer *sec_buf)
> +{
> + struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
> + u32 mem_session = sec_heap->mem_session;
> + int ret;
> +
> + params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> + params[0].u.value.a = SZ_4K;/* alignment */
> + params[0].u.value.b = sec_heap->mem_type; /* memory type */
> + params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> + params[1].u.value.a = sec_buf->size;
> + params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT;
> +
> + /* Always request zeroed buffer */
> + ret = mtk_sec_mem_tee_service_call(sec_heap->tee_ctx, mem_session,
> +TZCMD_MEM_SECURECM_ZALLOC, params);
I see here optee calls are being used to secure memory.
For a secure heap, there can be multiple ways on how we want to secure memory,
for eg : by using qcom_scm_assign_mem.
This interface restricts securing memory to only optee calls.
can we have a way to choose ops that we want to secure memory ?
Thanks,
Vijay
> + if (ret)
> + return -ENOMEM;
> +
> + sec_buf->sec_handle = params[2].u.value.a;
> + return 0;
> +}
> +
> +static void mtk_sec_mem_release(struct mtk_secure_heap *sec_heap,
> + struct mtk_secure_heap_buffer *sec_buf)
> +{
> + struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
> + u32 mem_session = sec_heap->mem_session;
> +
> + params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
> + params[0].u.value.a = sec_buf->sec_handle;
> + params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
> +
> + mtk_sec_mem_tee_service_call(sec_heap->tee_ctx, mem_session,
> + TZCMD_MEM_SECURECM_UNREF, params);
> +}
> +
> static struct dma_buf *
> mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
> unsigned long fd_flags, unsigned long heap_flags)
> @@ -107,6 +169,9 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
> sec_buf->size = size;
> sec_buf->heap = heap;
>
> + ret = mtk_sec_mem_allocate(sec_heap, sec_buf);
> + if (ret)
> + goto err_free_buf;
> exp_info.exp_name = dma_heap_get_name(heap);
> exp_info.size = sec_buf->size;
> exp_info.flags = fd_flags;
> @@ -115,11 +180,13 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t
> size,
> dmabuf = dma_buf_export(_info);
> if (IS_ERR(dmabuf)) {
> ret = PTR_ERR(dmabuf);
> - goto err_free_buf;
> + goto err_free_sec_mem;
> }
>
> return dmabuf;
>
> +err_free_sec_mem:
> + mtk_sec_mem_release(sec_heap, sec_buf);
> err_free_buf:
> kfree(sec_buf);
> return ERR_PTR(ret);
Re: [PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap
On 9/11/2023 8:00 AM, Yong Wu wrote: > This patchset consists of two parts, the first is from John and TJ. > It adds some heap interfaces, then our kernel users could allocate buffer > from special heap. The second part is adding MTK secure heap for SVP > (Secure Video Path). A total of two heaps are added, one is mtk_svp and > the other is mtk_svp_cma. The mtk_svp buffer is reserved for the secure > world after bootup and it is used for ES/working buffer, while the > mtk_svp_cma buffer is dynamically reserved for the secure world and will > be get ready when we start playing secure videos, this heap is used for the > frame buffer. Once the security video playing is complete, the CMA will be > released. > > For easier viewing, I've split the new heap file into several patches. > > The consumers of new heap and new interfaces are our codec and drm which > will send upstream soon, probably this week. > > Base on v6.6-rc1. > > John Stultz (2): > dma-heap: Add proper kref handling on dma-buf heaps > dma-heap: Provide accessors so that in-kernel drivers can allocate > dmabufs from specific heaps > > T.J. Mercier (1): > dma-buf: heaps: Deduplicate docs and adopt common format > > Yong Wu (6): > dma-buf: heaps: Initialise MediaTek secure heap > dma-buf: heaps: mtk_sec_heap: Initialise tee session > dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer > allocating/freeing > dma-buf: heaps: mtk_sec_heap: Add dma_ops > dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP > dma_buf: heaps: mtk_sec_heap: Add a new CMA heap > > .../mediatek,secure_cma_chunkmem.yaml | 42 ++ > drivers/dma-buf/dma-heap.c| 127 +++-- > drivers/dma-buf/heaps/Kconfig | 8 + > drivers/dma-buf/heaps/Makefile| 1 + > drivers/dma-buf/heaps/mtk_secure_heap.c | 458 ++ > include/linux/dma-heap.h | 42 +- > 6 files changed, 630 insertions(+), 48 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml > create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c > Thanks for this patch series. In Qualcomm as well we have similar usecases which need secure heap. We are working on posting them upstream, would share more details on usecases soon. Have few comments on the current implementation. 1) I see most the implementation here is mtk specific, even file names ,heap names etc. But secure heap is a common requirement, can we keep naming as well generic may be secure_heap ? 2) secure heap has two parts, one is allocation and other one is securing the memory. Have few comments on making these interfaces generic, would post those on corresponding patches. Thanks, Vijay
Re: [PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
On 9/11/2023 8:00 AM, Yong Wu wrote:
> This adds the binding for describing a CMA memory for MediaTek SVP(Secure
> Video Path).
>
> Signed-off-by: Yong Wu
> ---
> .../mediatek,secure_cma_chunkmem.yaml | 42 +++
> 1 file changed, 42 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
>
> b/Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
> new file mode 100644
> index ..cc10e00d35c4
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/reserved-memory/mediatek,secure_cma_chunkmem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Secure Video Path Reserved Memory
> +
> +description:
> + This binding describes the reserved memory for secure video path.
> +
> +maintainers:
> + - Yong Wu
> +
> +allOf:
> + - $ref: reserved-memory.yaml
> +
> +properties:
> + compatible:
> +const: mediatek,secure_cma_chunkmem
> +
> +required:
> + - compatible
> + - reg
> + - reusable
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +
> +reserved-memory {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +ranges;
> +
> +reserved-memory@8000 {
> +compatible = "mediatek,secure_cma_chunkmem";
> +reusable;
> +reg = <0x8000 0x1800>;
> +};
> +};
Instead of having a vendor specific binding for cma area, How about retrieving
https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunih...@socionext.com/
?
dma_heap_add_cma can just associate cma region and create a heap. So, we can
reuse cma heap
code for allocation instead of replicating that code here.
Thanks,
Vijay
Re: [PATCH v3 3/9] drm/vc4: hdmi: Add Broadcast RGB property to allow override of RGB range
Hi Maxime, On 19/10/2023 10:02, Maxime Ripard wrote: > Hi, > > On Wed, Oct 11, 2023 at 03:23:18PM +0200, Daniel Vetter wrote: >> On Mon, 6 Mar 2023 at 11:49, Maxime Ripard wrote: >>> >>> From: Dave Stevenson >>> >>> Copy Intel's "Broadcast RGB" property semantics to add manual override >>> of the HDMI pixel range for monitors that don't abide by the content >>> of the AVI Infoframe. >>> >>> Signed-off-by: Dave Stevenson >>> Signed-off-by: Maxime Ripard >> >> Stumbled over this grepping around, but would have been nice to lift >> this into drm code and document the property. It's one of the legacy >> ones from the table of horrors after all ... >> >> Shouldn't be an uapi problem because it's copypasted to much, just not great. > > We already discussed it on IRC, but just for the record I have a current > series that should address exactly that: > > https://lore.kernel.org/dri-devel/20230920-kms-hdmi-connector-state-v2-3-17932dadd...@kernel.org/ > > Maxime I've pasted a snippet from that patch below for a quick review: > /** > * DOC: HDMI connector properties > * > + * Broadcast RGB (HDMI Specific): Full vs Limited is actually not HDMI specific, DisplayPort can signal this as well for whatever it is worth. > + * Indicates the RGB Range (Full vs Limited) used. RGB Range -> RGB Quantization Range > + * > + * The value of this property can be one of the following: > + * > + * Automatic: > + * RGB Range is selected automatically based on the mode > + * according to the HDMI specifications. > + * > + * Full: > + * Full RGB Range is forced. > + * > + * Limited 16:235: It is very unfortunate that this is called "Limited 16:235" instead of just "Limited" since for color component bit depths > 8 these values are different. I have no idea if it is possible to add an alias "Limited" that you can use instead. In any case, this should document that it works just as well for higher bit depths, but with different limits. Regards, Hans > + * Limited RGB Range is forced. > + * > + * Drivers can set up this property by calling > + * drm_connector_attach_broadcast_rgb_property(). > + * > * content type (HDMI specific): > * Indicates content type setting to be used in HDMI infoframes to indicate > * content type for the external device, so that it adjusts its display
Re: [PATCH v5 9/9] drm: ci: Update xfails
Hi Vignesh, On Thu, 19 Oct 2023 at 09:07, Vignesh Raman wrote: > +# Some tests crashes with malloc error and IGT tests floods > +# the CI log with error messages and we end up with a warning message > +# Job's log exceeded limit of 4194304 bytes. > +# Job execution will continue but no more output will be collected. This is just from GitLab warning that we have a huge log, so not related to the actual fails here. > +# Below is the error log: > +# malloc(): corrupted top size > +# Received signal SIGABRT. > +# Stack trace: > +# #0 [fatal_sig_handler+0x17b] > +# #1 [__sigaction+0x40] > +# #2 [pthread_key_delete+0x14c] > +# #3 [gsignal+0x12] > +# #4 [abort+0xd3] > +# #5 [__fsetlocking+0x290] > +# #6 [timer_settime+0x37a] > +# #7 [__default_morecore+0x1f1b] > +# #8 [__libc_calloc+0x161] > +# #9 [drmModeGetPlaneResources+0x44] > +# #10 [igt_display_require+0x194] > +# #11 [__igt_uniquereal_main1356+0x93c] > +# #12 [main+0x3f] > +# #13 [__libc_init_first+0x8a] > +# #14 [__libc_start_main+0x85] > +# #15 [_start+0x21] > +# malloc(): corrupted top size By the time we get this error, it indicates that there was previously memory corruption, but it is only being noticed at a later point. The skip lists here are way too big - stuff like drm_read is common testing not affected by virtio at all - so we really need to isolate the test which is actually breaking things. The way to do this would be to use valgrind to detect where the memory corruption is. VirtIO can be run locally so this is something you can do on your machine. Cheers, Daniel
Re: [PATCH v5 9/9] drm: ci: Update xfails
Hi, On Thu, Oct 19, 2023 at 12:36:50PM +0530, Vignesh Raman wrote: > diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt > b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt > new file mode 100644 > index ..8b12e97d59f3 > --- /dev/null > +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt > @@ -0,0 +1,9 @@ > +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013138 > +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1012894 > +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013011 > +# https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1013055 > +kms_cursor_legacy@cursor-vs-flip-atomic-transitions > +kms_force_connector_basic@force-edid > +kms_force_connector_basic@prune-stale-modes > +kms_prop_blob@invalid-set-prop > +kms_prop_blob@invalid-set-prop-any We agreed recently to provide more context to flakes going forward, see: https://lore.kernel.org/dri-devel/ax6tspeffujmk2vpvh6rwclqkkavpezvcubra25vs2ev7f5njs@2rpnycg2rgnj/ I'll send a doc update to make that formal (and discuss it at XDC if needed) Maxime
Re: [PATCH] drm/loongson: Add support for the DC in LS2K1000 SoC
On Fri, Oct 13, 2023 at 06:28:01PM +0800, Sui Jingfeng wrote: > Hi, > > > On 2023/10/13 16:22, Icenowy Zheng wrote: > > 在 2023-10-12星期四的 00:26 +0800，Sui Jingfeng写道： > > > LS2K1000 is a low end SoC (two core 1.0gHz), it don't has dedicated > > > VRAM. > > > It requires the framebuffer to be phisically continguous to scanout. > > > The > > > display controller in LS2K1000 don't has built-in GPIO hardware, the > > > structure (register bit field) of its pixel, DC, GPU, DDR PLL are > > > also > > > defferent from other model. But for the display controller itself, > > > Most of > > > hardware features of it are same with ls7a1000. > > > > > > Below is a simple dts for it. > > Why don't you write a proper, YAML-formatted binding? > > > This patch use only one DT property, that is the "memory-region = > <_reserved>;". > But the memory-region property is a common property, I means that everyone > know how to > use this property. I'm not sure the if YAML documentation is strictly > required now. AFAIK it is, and even if it's not, please do it. Maxime
