[PATCH v6] drm/display: split DSC helpers from DP helpers
Currently the DRM DSC functions are selected by the DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI code (both panel and host drivers) end up selecting the seemingly irrelevant DP helpers. Split the DSC code to be guarded by the separate DRM_DISPLAY_DSC_HELPER Kconfig symbol. Reviewed-by: Jessica Zhang Reviewed-by: Marijn Suijten Acked-by: Rodrigo Vivi #i915 Signed-off-by: Dmitry Baryshkov --- Changes in v6: - Moved the Makefile entry to follow the sorting order (Thomas Zimmermann) - Link to v5: https://lore.kernel.org/r/20240623-panel-sw43408-fix-v5-1-5401ab61e...@linaro.org Changes in v5: - Drop applied patches - Link to v4: https://lore.kernel.org/r/20240528-panel-sw43408-fix-v4-0-330b42445...@linaro.org Changes in v4: - Reoder patches so that fixes come first, to be able to land them to drm-misc-fixes - Link to v3: https://lore.kernel.org/r/20240522-panel-sw43408-fix-v3-0-6902285ad...@linaro.org Changes in v3: - Split DRM_DISPLAY_DSC_HELPER from DRM_DISPLAY_DP_HELPER - Added missing Fixes tags - Link to v2: https://lore.kernel.org/r/20240510-panel-sw43408-fix-v2-0-d1ef91ee1...@linaro.org Changes in v2: - use SELECT instead of DEPEND to follow the reverted Kconfig changes - Link to v1: https://lore.kernel.org/r/20240420-panel-sw43408-fix-v1-0-b282ff725...@linaro.org --- drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + drivers/gpu/drm/display/Kconfig| 6 ++ drivers/gpu/drm/display/Makefile | 5 +++-- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/panel/Kconfig | 6 +++--- 6 files changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 0051fb1b437f..fc3237da8090 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -6,6 +6,7 @@ config DRM_AMDGPU depends on !UML select FW_LOADER select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index 479e62690d75..a2e42014ffe0 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -59,6 +59,12 @@ config DRM_DISPLAY_DP_TUNNEL_STATE_DEBUG If in doubt, say "N". +config DRM_DISPLAY_DSC_HELPER + bool + depends on DRM_DISPLAY_HELPER + help + DRM display helpers for VESA DSC (used by DSI and DisplayPort). + config DRM_DISPLAY_HDCP_HELPER bool depends on DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile index 629df2f4d322..a023f72fa139 100644 --- a/drivers/gpu/drm/display/Makefile +++ b/drivers/gpu/drm/display/Makefile @@ -6,10 +6,11 @@ drm_display_helper-y := drm_display_helper_mod.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += \ drm_dp_dual_mode_helper.o \ drm_dp_helper.o \ - drm_dp_mst_topology.o \ - drm_dsc_helper.o + drm_dp_mst_topology.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_TUNNEL) += \ drm_dp_tunnel.o +drm_display_helper-$(CONFIG_DRM_DISPLAY_DSC_HELPER) += \ + drm_dsc_helper.o drm_display_helper-$(CONFIG_DRM_DISPLAY_HDCP_HELPER) += drm_hdcp_helper.o drm_display_helper-$(CONFIG_DRM_DISPLAY_HDMI_HELPER) += \ drm_hdmi_helper.o \ diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index faa253b27664..db400aad88fa 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -11,6 +11,7 @@ config DRM_I915 select SHMEM select TMPFS select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 26a4c71da63a..420385c47193 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -112,6 +112,7 @@ config DRM_MSM_DSI depends on DRM_MSM select DRM_PANEL select DRM_MIPI_DSI + select DRM_DISPLAY_DSC_HELPER default y help Choose this option if you have a need for MIPI DSI connector diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 9f49b0189d3b..dac01ade7e2e 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -369,7 +369,7 @@ config DRM_PANEL_LG_SW43408 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for LG sw43408 panel. @@ -578,7 +578,7 @@ config DRM_PANEL_RAYDIUM_RM692E5 depends on OF depends on DR
Re: [PATCH v1] drm/ci: uprev IGT
On Thu, Jul 04, 2024 at 02:52:02PM GMT, Vignesh Raman wrote: > Uprev IGT to the latest version, which includes a fix for the > writeback tests issue on MSM devices. Enable debugging for > igt-runner to log output such as 'Begin test' and 'End test'. > This will help identify which test causes system freeze or hangs. > Update xfails and add metadata header for each flake test. > > Signed-off-by: Vignesh Raman > --- > > v1: > - https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1216850 > > --- > drivers/gpu/drm/ci/gitlab-ci.yml | 2 +- > drivers/gpu/drm/ci/igt_runner.sh | 1 + > .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 1 + > .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 14 +- > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 4 +- > drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 12 +- > .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 41 - > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 5 +- > drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 2 +- > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 4 +- > drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 14 +- > drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 9 +- > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 5 +- > drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 24 +-- > drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 8 +- > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 4 +- > drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 2 + > drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 2 +- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 4 +- > drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 25 +-- > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 4 +- > drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 17 +- > drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 2 +- > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 5 +- > .../drm/ci/xfails/mediatek-mt8173-fails.txt | 9 +- > .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 32 +++- > .../drm/ci/xfails/mediatek-mt8173-skips.txt | 4 +- > .../drm/ci/xfails/mediatek-mt8183-fails.txt | 2 +- > .../drm/ci/xfails/mediatek-mt8183-skips.txt | 2 +- > .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 2 +- > .../gpu/drm/ci/xfails/meson-g12b-skips.txt| 2 +- > .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 5 +- > .../gpu/drm/ci/xfails/msm-apq8016-skips.txt | 2 +- > .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 2 +- > .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 4 +- Acked-by: Dmitry Baryshkov # msm tests > .../msm-sc7180-trogdor-kingoftown-fails.txt | 145 -- > .../msm-sc7180-trogdor-kingoftown-flakes.txt | 18 ++- > .../msm-sc7180-trogdor-kingoftown-skips.txt | 5 +- > ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 145 -- > ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 11 +- > ...sm-sc7180-trogdor-lazor-limozeen-skips.txt | 2 +- > .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 105 - > .../gpu/drm/ci/xfails/msm-sdm845-skips.txt| 4 +- > .../drm/ci/xfails/rockchip-rk3288-fails.txt | 2 +- > .../drm/ci/xfails/rockchip-rk3288-skips.txt | 2 +- > .../drm/ci/xfails/rockchip-rk3399-fails.txt | 2 +- > .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 4 +- > .../drm/ci/xfails/rockchip-rk3399-skips.txt | 2 +- > .../drm/ci/xfails/virtio_gpu-none-fails.txt | 64 > .../drm/ci/xfails/virtio_gpu-none-skips.txt | 4 +- > drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 4 - > .../gpu/drm/ci/xfails/vkms-none-flakes.txt| 21 +++ > drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 105 - > 53 files changed, 527 insertions(+), 395 deletions(-) > > diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml > b/drivers/gpu/drm/ci/gitlab-ci.yml > index 80fb0f57ae46..b09976c3d2c2 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: 0df7b9b97f9da0e364f5ee30fe331004b8c86b56 > + IGT_VERSION: f13702b8e4e847c56da3ef6f0969065d686049c5 > >DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git >DEQP_RUNNER_GIT_TAG: v0.15.0 -- With best wishes Dmitry
[PATCH v5] drm/display: split DSC helpers from DP helpers
Currently the DRM DSC functions are selected by the DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI code (both panel and host drivers) end up selecting the seemingly irrelevant DP helpers. Split the DSC code to be guarded by the separate DRM_DISPLAY_DSC_HELPER Kconfig symbol. Reviewed-by: Jessica Zhang Reviewed-by: Marijn Suijten Signed-off-by: Dmitry Baryshkov --- To: Alex Deucher To: Christian König To: Pan, Xinhui To: David Airlie To: Daniel Vetter To: Maarten Lankhorst To: Maxime Ripard To: Thomas Zimmermann To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: Rob Clark To: Abhinav Kumar To: Sean Paul To: Marijn Suijten To: Neil Armstrong To: Jessica Zhang Cc: amd-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Dmitry Baryshkov Changes in v5: - Drop applied patches - Link to v4: https://lore.kernel.org/r/20240528-panel-sw43408-fix-v4-0-330b42445...@linaro.org Changes in v4: - Reoder patches so that fixes come first, to be able to land them to drm-misc-fixes - Link to v3: https://lore.kernel.org/r/20240522-panel-sw43408-fix-v3-0-6902285ad...@linaro.org Changes in v3: - Split DRM_DISPLAY_DSC_HELPER from DRM_DISPLAY_DP_HELPER - Added missing Fixes tags - Link to v2: https://lore.kernel.org/r/20240510-panel-sw43408-fix-v2-0-d1ef91ee1...@linaro.org Changes in v2: - use SELECT instead of DEPEND to follow the reverted Kconfig changes - Link to v1: https://lore.kernel.org/r/20240420-panel-sw43408-fix-v1-0-b282ff725...@linaro.org --- drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + drivers/gpu/drm/display/Kconfig| 6 ++ drivers/gpu/drm/display/Makefile | 3 ++- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/panel/Kconfig | 6 +++--- 6 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 4232ab27f990..5933ca8c6b96 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -6,6 +6,7 @@ config DRM_AMDGPU depends on !UML select FW_LOADER select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index 479e62690d75..a2e42014ffe0 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -59,6 +59,12 @@ config DRM_DISPLAY_DP_TUNNEL_STATE_DEBUG If in doubt, say "N". +config DRM_DISPLAY_DSC_HELPER + bool + depends on DRM_DISPLAY_HELPER + help + DRM display helpers for VESA DSC (used by DSI and DisplayPort). + config DRM_DISPLAY_HDCP_HELPER bool depends on DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile index 629df2f4d322..df8f22c7e916 100644 --- a/drivers/gpu/drm/display/Makefile +++ b/drivers/gpu/drm/display/Makefile @@ -6,7 +6,8 @@ drm_display_helper-y := drm_display_helper_mod.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += \ drm_dp_dual_mode_helper.o \ drm_dp_helper.o \ - drm_dp_mst_topology.o \ + drm_dp_mst_topology.o +drm_display_helper-$(CONFIG_DRM_DISPLAY_DSC_HELPER) += \ drm_dsc_helper.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_TUNNEL) += \ drm_dp_tunnel.o diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index faa253b27664..db400aad88fa 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -11,6 +11,7 @@ config DRM_I915 select SHMEM select TMPFS select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 1931ecf73e32..6dcd26180611 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -111,6 +111,7 @@ config DRM_MSM_DSI depends on DRM_MSM select DRM_PANEL select DRM_MIPI_DSI + select DRM_DISPLAY_DSC_HELPER default y help Choose this option if you have a need for MIPI DSI connector diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index bf4eadfe21cb..afae8b130e9a 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -349,7 +349,7 @@ config DRM_PANEL_LG_SW43408 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER
Re: [PATCH v7 2/9] drm: Support per-plane async flip configuration
On Tue, Jun 18, 2024 at 01:18:10PM GMT, André Almeida wrote:
> Em 18/06/2024 07:07, Dmitry Baryshkov escreveu:
> > On Tue, 18 Jun 2024 at 12:38, Jani Nikula
> > wrote:
> > >
> > > On Tue, 18 Jun 2024, André Almeida wrote:
> > > > Drivers have different capabilities on what plane types they can or
> > > > cannot perform async flips. Create a plane::async_flip field so each
> > > > driver can choose which planes they allow doing async flips.
> > > >
> > > > Signed-off-by: André Almeida
> > > > ---
> > > > include/drm/drm_plane.h | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > > > index 9507542121fa..0bebc72af5c3 100644
> > > > --- a/include/drm/drm_plane.h
> > > > +++ b/include/drm/drm_plane.h
> > > > @@ -786,6 +786,11 @@ struct drm_plane {
> > > > * @kmsg_panic: Used to register a panic notifier for this plane
> > > > */
> > > >struct kmsg_dumper kmsg_panic;
> > > > +
> > > > + /**
> > > > + * @async_flip: indicates if a plane can do async flips
> > > > + */
> > >
> > > When is it okay to set or change the value of this member?
> > >
> > > If you don't document it, people will find creative uses for this.
> >
> > Maybe it's better to have a callback instead of a static field? This
> > way it becomes clear that it's only relevant at the time of the
> > atomic_check().
> >
>
> So we would have something like bool (*async_flip) for struct
> drm_plane_funcs I suppose. Then each driver will implement this function and
> check on runtime if it should flip or not, right?
>
> I agree that it makes more clear, but as far as I can see this is not
> something that is subject to being changed at runtime at all, so it seems a
> bit overkill to me to encapsulate a static information like that. I prefer
> to improve the documentation on the struct member to see if this solves the
> problem. What do you think of the following comment:
It looks like I keep on mixing async_flips as handled via the
DRM_MODE_PAGE_FLIP_ASYNC and the plane flips that are governed by
.atomic_async_check / .atomic_async_update / drm_atomic_helper_check()
and which end up being used just for legacy cursor updates.
So, yes, those are two different code paths, but with your changes I
think it becomes even easier to get confused between
atomic_async_check() and .async_flip member.
> /**
> * @async_flip: indicates if a plane can perform async flips. The
> * driver should set this true only for planes that the hardware
> * supports flipping asynchronously. It may not be changed during
> * runtime. This field is checked inside drm_mode_atomic_ioctl() to
> * allow only the correct planes to go with DRM_MODE_PAGE_FLIP_ASYNC.
> */
--
With best wishes
Dmitry
Re: [PATCH v7 2/9] drm: Support per-plane async flip configuration
On Tue, 18 Jun 2024 at 12:38, Jani Nikula wrote:
>
> On Tue, 18 Jun 2024, André Almeida wrote:
> > Drivers have different capabilities on what plane types they can or
> > cannot perform async flips. Create a plane::async_flip field so each
> > driver can choose which planes they allow doing async flips.
> >
> > Signed-off-by: André Almeida
> > ---
> > include/drm/drm_plane.h | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> > index 9507542121fa..0bebc72af5c3 100644
> > --- a/include/drm/drm_plane.h
> > +++ b/include/drm/drm_plane.h
> > @@ -786,6 +786,11 @@ struct drm_plane {
> >* @kmsg_panic: Used to register a panic notifier for this plane
> >*/
> > struct kmsg_dumper kmsg_panic;
> > +
> > + /**
> > + * @async_flip: indicates if a plane can do async flips
> > + */
>
> When is it okay to set or change the value of this member?
>
> If you don't document it, people will find creative uses for this.
Maybe it's better to have a callback instead of a static field? This
way it becomes clear that it's only relevant at the time of the
atomic_check().
> > + bool async_flip;
> > };
> >
> > #define obj_to_plane(x) container_of(x, struct drm_plane, base)
>
> --
> Jani Nikula, Intel
--
With best wishes
Dmitry
Re: [PATCH v6 0/8] drm: Support per-plane async flip configuration
On Fri, Jun 14, 2024 at 12:35:27PM GMT, André Almeida wrote: > AMD hardware can do async flips with overlay planes, but currently there's no > easy way to enable that in DRM. To solve that, this patchset creates a new > drm_plane field, bool async_flip, that allows drivers to choose which plane > can > or cannot do async flips. This is latter used on drm_atomic_set_property when > users want to do async flips. > > Patch 1 allows async commits with IN_FENCE_ID in any driver. > > Patches 2 to 7 have no function change. As per current code, every driver that > allows async page flips using the atomic API, allows doing it only in the > primary plane. Those patches then enable it for every driver. > > Patch 8 finally enables async flip on overlay planes for amdgpu. > > Changes from v5: > - Instead of enabling plane->async_flip in the common code, move it to driver > code. > - Enable primary plane async flip on every driver > https://lore.kernel.org/dri-devel/20240612193713.167448-1-andrealm...@igalia.com/ > > André Almeida (8): > drm/atomic: Allow userspace to use explicit sync with atomic async > flips > drm: Support per-plane async flip configuration > drm/amdgpu: Enable async flips on the primary plane > drm: atmel-hlcdc: Enable async flips on the primary plane > drm/i915: Enable async flips on the primary plane > drm/nouveau: Enable async flips on the primary plane > drm/vc4: Enable async flips on the primary plane > drm/amdgpu: Make it possible to async flip overlay planes > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 2 ++ > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +++ > drivers/gpu/drm/drm_atomic_uapi.c | 8 +--- > drivers/gpu/drm/i915/display/i9xx_plane.c | 3 +++ > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 > drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 > drivers/gpu/drm/vc4/vc4_plane.c | 4 +++- The main question is why only these drivers were updated. > include/drm/drm_plane.h | 5 + > 8 files changed, 29 insertions(+), 4 deletions(-) > > -- > 2.45.2 > -- With best wishes Dmitry
Re: [PATCH v6 2/8] drm: Support per-plane async flip configuration
On Fri, Jun 14, 2024 at 12:35:29PM GMT, André Almeida wrote:
> Drivers have different capabilities on what plane types they can or
> cannot perform async flips. Create a plane::async_flip field so each
> driver can choose which planes they allow doing async flips.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> include/drm/drm_plane.h | 5 +
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 2e1d9391febe..ed1af3455477 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1079,9 +1079,9 @@ int drm_atomic_set_property(struct drm_atomic_state
> *state,
> break;
> }
>
> - if (async_flip && plane_state->plane->type !=
> DRM_PLANE_TYPE_PRIMARY) {
> + if (async_flip && !plane->async_flip) {
So, after this patch async flips becomes disabled until the driver
enables that manually. Whether that's desired or not is a separate
topic, but this definitely should be explicitly mentioned in the commit
message.
> drm_dbg_atomic(prop->dev,
> -"[OBJECT:%d] Only primary planes can be
> changed during async flip\n",
> +"[PLANE:%d] does not support async
> flips\n",
> obj->id);
> ret = -EINVAL;
> break;
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 9507542121fa..0bebc72af5c3 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -786,6 +786,11 @@ struct drm_plane {
>* @kmsg_panic: Used to register a panic notifier for this plane
>*/
> struct kmsg_dumper kmsg_panic;
> +
> + /**
> + * @async_flip: indicates if a plane can do async flips
> + */
> + bool async_flip;
> };
>
> #define obj_to_plane(x) container_of(x, struct drm_plane, base)
> --
> 2.45.2
>
--
With best wishes
Dmitry
Re: [PATCH v5 2/3] drm: Allow drivers to choose plane types to async flip
On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote: > Different planes may have different capabilities of doing async flips, > so create a field to let drivers allow async flip per plane type. > > Signed-off-by: André Almeida > --- > drivers/gpu/drm/drm_atomic_uapi.c | 4 ++-- > drivers/gpu/drm/drm_plane.c | 3 +++ > include/drm/drm_plane.h | 5 + > 3 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > index 57662a1fd345..bbcec3940636 100644 > --- a/drivers/gpu/drm/drm_plane.c > +++ b/drivers/gpu/drm/drm_plane.c > @@ -385,6 +385,9 @@ static int __drm_universal_plane_init(struct drm_device > *dev, > > drm_modeset_lock_init(>mutex); > > + if (type == DRM_PLANE_TYPE_PRIMARY) > + plane->async_flip = true; > + Why? Also note that the commit message writes about adding the field, not about enabling it for the primary planes. > plane->base.properties = >properties; > plane->dev = dev; > plane->funcs = funcs; -- With best wishes Dmitry
Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Thu, 30 May 2024 at 07:41, Limonciello, Mario wrote: > > > >> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if > >> someone needs this to work on non-ACPI system they get to figure out > >> how to abstract it better. acpi_lid_open() does seem to return != 0 > >> when ACPI is not supported, so at least it would err on the side > >> of enabling everything. > > > > Thanks. I was going to comment, but you got it first. I think a proper > > implementation should check for SW_LID input device instead of simply > > using acpi_lid_open(). This will handle the issue for other, > > non-ACPI-based laptops. > > > > Can you suggest how this would actually work? AFAICT the only way to > discover if input devices support SW_LID would be to iterate all the > input devices in the kernel and look for whether ->swbit has SW_LID set. > > This then turns into a dependency problem of whether any myriad of > drivers have started to report SW_LID. It's also a state machine > problem because other drivers can be unloaded at will. > > And then what do you if more than one sets SW_LID? It might be easier to handle this in the input subsystem. For example by using a refcount-like variable which handles all the LIDs and counts if all of them are closed. Or if any of the LIDs is closed. > > IOW - a lot of complexity for a non-ACPI system. Does such a problem > exist in non-ACPI systems? There are non-ACPI laptops. For example Chromebooks. Or Lenovo X13s, Lenovo Yoga C630, Lenovo Flex5G, etc. We are expecting more to come in the next few months. And I don't see why they won't have the same problem. -- With best wishes Dmitry
Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Wed, May 29, 2024 at 06:39:21PM +0300, Ville Syrjälä wrote:
> On Wed, May 29, 2024 at 09:45:55AM -0500, Mario Limonciello wrote:
> > On 5/29/2024 09:14, Ville Syrjälä wrote:
> > > On Tue, May 28, 2024 at 04:03:19PM -0500, Mario Limonciello wrote:
> > >> If the lid on a laptop is closed when eDP connectors are populated
> > >> then it remains enabled when the initial framebuffer configuration
> > >> is built.
> > >>
> > >> When creating the initial framebuffer configuration detect the ACPI
> > >> lid status and if it's closed disable any eDP connectors.
> > >>
> > >> Reported-by: Chris Bainbridge
> > >> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
> > >> Signed-off-by: Mario Limonciello
> > >> ---
> > >> Cc: hughsi...@gmail.com
> > >> v1->v2:
> > >> * Match LVDS as well
> > >> ---
> > >> drivers/gpu/drm/drm_client_modeset.c | 30
> > >> 1 file changed, 30 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > >> b/drivers/gpu/drm/drm_client_modeset.c
> > >> index 31af5cf37a09..0b0411086e76 100644
> > >> --- a/drivers/gpu/drm/drm_client_modeset.c
> > >> +++ b/drivers/gpu/drm/drm_client_modeset.c
> > >> @@ -8,6 +8,7 @@
> > >>*/
> > >>
> > >> #include "drm/drm_modeset_lock.h"
> > >> +#include
> > >> #include
> > >> #include
> > >> #include
> > >> @@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct
> > >> drm_connector **connectors,
> > >> enabled[i] = drm_connector_enabled(connectors[i],
> > >> false);
> > >> }
> > >>
> > >> +static void drm_client_match_edp_lid(struct drm_device *dev,
> > >> + struct drm_connector **connectors,
> > >> + unsigned int connector_count,
> > >> + bool *enabled)
> > >> +{
> > >> +int i;
> > >> +
> > >> +for (i = 0; i < connector_count; i++) {
> > >> +struct drm_connector *connector = connectors[i];
> > >> +
> > >> +switch (connector->connector_type) {
> > >> +case DRM_MODE_CONNECTOR_LVDS:
> > >> +case DRM_MODE_CONNECTOR_eDP:
What about DPI or DSI panels? I think they should also be handled in a
similar way. Not sure regarding the SPI.
> > >> +if (!enabled[i])
> > >> +continue;
> > >> +break;
> > >> +default:
> > >> +continue;
> > >> +}
> > >> +
> > >> +if (!acpi_lid_open()) {
> > >> +drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is
> > >> closed, disabling\n",
> > >> +connector->base.id,
> > >> connector->name);
> > >> +enabled[i] = false;
> > >> +}
> > >> +}
> > >> +}
> > >
[trimmed]
>
> The other potential issue here is whether acpi_lid_open() is actually
> trustworthy. Some kms drivers have/had some lid handling in their own
> code, and I'm pretty sure those have often needed quirks/modparams
> to actually do sensible things on certain machines.
>
> FWIW I ripped out all the lid crap from i915 long ago since it was
> half backed, mostly broken, and ugly, and I'm not looking to add it
> back there. But I do think handling that in drm_client does seem
> somewhat sane, as that should more or less match what userspace
> clients would do. Just a question of how bad the quirk situation
> will get...
Looking at drivers/acpi/button.c, the button driver handles some of the
quirks when posting the data to the input subsystem.
>
>
> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
> someone needs this to work on non-ACPI system they get to figure out
> how to abstract it better. acpi_lid_open() does seem to return != 0
> when ACPI is not supported, so at least it would err on the side
> of enabling everything.
Thanks. I was going to comment, but you got it first. I think a proper
implementation should check for SW_LID input device instead of simply
using acpi_lid_open(). This will handle the issue for other,
non-ACPI-based laptops.
--
With best wishes
Dmitry
Re: (subset) [PATCH v4 0/3] drm/panel: two fixes for lg-sw43408
On Tue, 28 May 2024 22:39:17 +0300, Dmitry Baryshkov wrote: > Fix two issues with the panel-lg-sw43408 driver reported by the kernel > test robot. > > Applied to drm-misc-fixes, thanks! [1/3] drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER commit: 33defcacd207196a6b35857087e6335590adad62 [2/3] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static commit: 8c318cb70c88aa02068db7518e852b909c9b400f Best regards, -- With best wishes Dmitry
Re: [PATCH v3 4/6] drm/ci: uprev IGT
On Wed, May 29, 2024 at 08:10:47AM +0530, Vignesh Raman wrote:
> test-list.txt and test-list-full.txt are not generated for
> cross-builds and they are required by drm-ci for testing
> arm32 targets. This is fixed in igt-gpu-tools. So uprev
> IGT to include the commit which fixes this issue. Also
> disable building xe driver tests for non-intel platforms.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Vignesh Raman
> ---
>
> v2:
> - Split IGT uprev to seperate patch.
>
> v3:
> - No changes.
>
> ---
> drivers/gpu/drm/ci/build-igt.sh | 4
> drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
> index b7d2a49a6db3..eddb5f782a5e 100644
> --- a/drivers/gpu/drm/ci/build-igt.sh
> +++ b/drivers/gpu/drm/ci/build-igt.sh
> @@ -45,6 +45,10 @@ MESON_OPTIONS="-Doverlay=disabled\
> -Dlibunwind=enabled \
> -Dprefix=/igt"
>
> +if [[ "$KERNEL_ARCH" = "arm64" ]] || [[ "$KERNEL_ARCH" = "arm" ]]; then
> +MESON_OPTIONS="$MESON_OPTIONS -Dxe_driver=disabled"
> +fi
> +
> mkdir -p /igt
> meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
> ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
> diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml
> b/drivers/gpu/drm/ci/gitlab-ci.yml
> index 8f32de63d92e..1b29c3b6406b 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: d2af13d9f5be5ce23d996e4afd3e45990f5ab977
> + IGT_VERSION: 0df7b9b97f9da0e364f5ee30fe331004b8c86b56
Let's land this, then I'll ask to uprev to
dc2d7fb4f978048b87707ea9ec32da748b01b378, which fixes an issue with the
writeback tests on MSM devices.
>
>DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git
>DEQP_RUNNER_GIT_TAG: v0.15.0
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [PATCH v3 6/6] drm/ci: update xfails for the new testlist
On Wed, May 29, 2024 at 08:10:49AM +0530, Vignesh Raman wrote: > Now the testlist is used from IGT build, so update > xfails with the new testlist. > > Set the timeout of all i915 jobs to 1h30m since some jobs > takes more than 1 hour to complete. > > Reviewed-by: Dmitry Baryshkov This had an explicit '# msm testlist' at the end. Please don't drop important parts of tags. I didn't review fails/flakes for other platforms. > Signed-off-by: Vignesh Raman > --- > > v2: > - Set the timeout of all i915 jobs to 1h30m and updated expectations file. > > v3: > - Add a link to the email reporting the flaky tests to the maintainers. > > --- > drivers/gpu/drm/ci/test.yml | 6 +- > .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 41 ++-- > .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 7 + > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 18 ++ > drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 31 > .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 9 + > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 11 ++ > drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 46 +++-- > drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 6 + > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 15 ++ > drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 38 > drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 6 + > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 41 +++- > drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 7 + > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 15 ++ > drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 42 ++--- > drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 7 +- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 25 +++ > drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 77 > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 17 ++ > drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 63 --- > drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 6 + > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 11 ++ > .../drm/ci/xfails/mediatek-mt8173-fails.txt | 30 ++- > .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 11 ++ > .../drm/ci/xfails/mediatek-mt8173-skips.txt | 4 + > .../drm/ci/xfails/mediatek-mt8183-fails.txt | 21 +-- > .../drm/ci/xfails/mediatek-mt8183-skips.txt | 4 + > .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 24 +-- > .../gpu/drm/ci/xfails/meson-g12b-skips.txt| 4 + > .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 12 +- > .../gpu/drm/ci/xfails/msm-apq8016-skips.txt | 4 + > .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 7 + > .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 6 + > .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 12 ++ > .../msm-sc7180-trogdor-kingoftown-fails.txt | 175 +- > .../msm-sc7180-trogdor-kingoftown-flakes.txt | 8 + > .../msm-sc7180-trogdor-kingoftown-skips.txt | 7 + > ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 175 +- > ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 6 + > ...sm-sc7180-trogdor-lazor-limozeen-skips.txt | 4 + > .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 38 +--- > .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 25 ++- > .../gpu/drm/ci/xfails/msm-sdm845-skips.txt| 7 + > .../drm/ci/xfails/rockchip-rk3288-fails.txt | 62 +-- > .../drm/ci/xfails/rockchip-rk3288-skips.txt | 4 + > .../drm/ci/xfails/rockchip-rk3399-fails.txt | 83 + > .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 13 +- > .../drm/ci/xfails/rockchip-rk3399-skips.txt | 4 + > drivers/gpu/drm/ci/xfails/update-xfails.py| 4 +- > .../drm/ci/xfails/virtio_gpu-none-fails.txt | 94 +++--- > .../drm/ci/xfails/virtio_gpu-none-skips.txt | 4 + > 53 files changed, 1023 insertions(+), 388 deletions(-) > create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt > > diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml > index 2615f67f6aa3..322cce714657 100644 > --- a/drivers/gpu/drm/ci/test.yml > +++ b/drivers/gpu/drm/ci/test.yml > @@ -19
Re: [PATCH v3 3/6] drm/ci: generate testlist from build
On Wed, May 29, 2024 at 08:10:46AM +0530, Vignesh Raman wrote: > Stop vendoring the testlist into the kernel. Instead, use the > testlist from the IGT build to ensure we do not miss renamed > or newly added tests. > > Signed-off-by: Vignesh Raman > --- > > v2: > - Fix testlist generation for arm and arm64 builds. > > v3: > - Rename generated testlist file to ci-testlist. > > --- > drivers/gpu/drm/ci/build-igt.sh | 35 + > drivers/gpu/drm/ci/igt_runner.sh |9 +- > drivers/gpu/drm/ci/testlist.txt | 2761 -- > 3 files changed, 40 insertions(+), 2765 deletions(-) > delete mode 100644 drivers/gpu/drm/ci/testlist.txt > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 2/6] drm/ci: add farm variable
On Wed, May 29, 2024 at 08:10:45AM +0530, Vignesh Raman wrote: > Mesa uses structured logs for logging and debug purpose, > https://mesa.pages.freedesktop.org/-/mesa/-/jobs/59165650/artifacts/results/job_detail.json > > Since drm-ci uses the mesa scripts, add the farm variable > and update the device type for missing jobs. > > Signed-off-by: Vignesh Raman > --- > > v3: > - New commit to add farm variable and update device type variable. > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v3 1/6] drm/ci: uprev mesa version
On Wed, May 29, 2024 at 08:10:44AM +0530, Vignesh Raman wrote: > zlib.net is not allowing tarball download anymore and results > in below error in kernel+rootfs_arm32 container build, > urllib.error.HTTPError: HTTP Error 403: Forbidden > urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type > > Uprev mesa to latest version which includes a fix for this issue. > https://gitlab.freedesktop.org/mesa/mesa/-/commit/908f444e > > Use id_tokens for JWT authentication. Since s3 bucket is migrated to > mesa-rootfs, update the variables accordingly. Also copy helper scripts > to install, so that the ci jobs can use these scripts for logging. > > Signed-off-by: Vignesh Raman > --- > > v2: > - Uprev to recent version and use id_tokens for JWT authentication > > v3: > - Move adding farm variable and updating device type variable to seperate > commit > > --- > drivers/gpu/drm/ci/build-igt.sh | 2 +- > drivers/gpu/drm/ci/build.sh | 6 +++-- > drivers/gpu/drm/ci/container.yml | 12 +++-- > drivers/gpu/drm/ci/gitlab-ci.yml | 44 +-- > drivers/gpu/drm/ci/image-tags.yml | 2 +- > drivers/gpu/drm/ci/lava-submit.sh | 4 +-- > 6 files changed, 42 insertions(+), 28 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH v4 3/3] drm/display: split DSC helpers from DP helpers
Currently the DRM DSC functions are selected by the DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI code (both panel and host drivers) end up selecting the seemingly irrelevant DP helpers. Split the DSC code to be guarded by the separate DRM_DISPLAY_DSC_HELPER Kconfig symbol. Reviewed-by: Jessica Zhang Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + drivers/gpu/drm/display/Kconfig| 6 ++ drivers/gpu/drm/display/Makefile | 3 ++- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/panel/Kconfig | 6 +++--- 6 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 4232ab27f990..5933ca8c6b96 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -6,6 +6,7 @@ config DRM_AMDGPU depends on !UML select FW_LOADER select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index 864a6488bfdf..f524cf95dec3 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -59,6 +59,12 @@ config DRM_DISPLAY_DP_TUNNEL_STATE_DEBUG If in doubt, say "N". +config DRM_DISPLAY_DSC_HELPER + bool + depends on DRM_DISPLAY_HELPER + help + DRM display helpers for VESA DSC (used by DSI and DisplayPort). + config DRM_DISPLAY_HDCP_HELPER bool depends on DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile index 17d2cc73ff56..2ec71e15c3cb 100644 --- a/drivers/gpu/drm/display/Makefile +++ b/drivers/gpu/drm/display/Makefile @@ -6,7 +6,8 @@ drm_display_helper-y := drm_display_helper_mod.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += \ drm_dp_dual_mode_helper.o \ drm_dp_helper.o \ - drm_dp_mst_topology.o \ + drm_dp_mst_topology.o +drm_display_helper-$(CONFIG_DRM_DISPLAY_DSC_HELPER) += \ drm_dsc_helper.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_TUNNEL) += \ drm_dp_tunnel.o diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 5932024f8f95..117b84260b1c 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -11,6 +11,7 @@ config DRM_I915 select SHMEM select TMPFS select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 1931ecf73e32..6dcd26180611 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -111,6 +111,7 @@ config DRM_MSM_DSI depends on DRM_MSM select DRM_PANEL select DRM_MIPI_DSI + select DRM_DISPLAY_DSC_HELPER default y help Choose this option if you have a need for MIPI DSI connector diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 2ae0eb0638f3..3e3f63479544 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -340,7 +340,7 @@ config DRM_PANEL_LG_SW43408 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for LG sw43408 panel. @@ -549,7 +549,7 @@ config DRM_PANEL_RAYDIUM_RM692E5 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for Raydium RM692E5-based @@ -907,7 +907,7 @@ config DRM_PANEL_VISIONOX_R66451 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for Visionox -- 2.39.2
[PATCH v4 1/3] drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER
This panel driver uses DSC PPS functions and as such depends on the
DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions
available to the driver.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Reviewed-by: Neil Armstrong
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 982324ef5a41..2ae0eb0638f3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -340,6 +340,8 @@ config DRM_PANEL_LG_SW43408
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_DISPLAY_DP_HELPER
+ select DRM_DISPLAY_HELPER
help
Say Y here if you want to enable support for LG sw43408 panel.
The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per
--
2.39.2
[PATCH v4 2/3] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Reviewed-by: Neil Armstrong
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
}
-const struct backlight_ops sw43408_backlight_ops = {
+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
};
--
2.39.2
[PATCH v4 0/3] drm/panel: two fixes for lg-sw43408
Fix two issues with the panel-lg-sw43408 driver reported by the kernel test robot. Signed-off-by: Dmitry Baryshkov --- Changes in v4: - Reoder patches so that fixes come first, to be able to land them to drm-misc-fixes - Link to v3: https://lore.kernel.org/r/20240522-panel-sw43408-fix-v3-0-6902285ad...@linaro.org Changes in v3: - Split DRM_DISPLAY_DSC_HELPER from DRM_DISPLAY_DP_HELPER - Added missing Fixes tags - Link to v2: https://lore.kernel.org/r/20240510-panel-sw43408-fix-v2-0-d1ef91ee1...@linaro.org Changes in v2: - use SELECT instead of DEPEND to follow the reverted Kconfig changes - Link to v1: https://lore.kernel.org/r/20240420-panel-sw43408-fix-v1-0-b282ff725...@linaro.org --- Dmitry Baryshkov (3): drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER drm/panel/lg-sw43408: mark sw43408_backlight_ops as static drm/display: split DSC helpers from DP helpers drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + drivers/gpu/drm/display/Kconfig | 6 ++ drivers/gpu/drm/display/Makefile | 3 ++- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/panel/Kconfig| 6 -- drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +- 7 files changed, 16 insertions(+), 4 deletions(-) --- base-commit: 6dc544b66971c7f9909ff038b62149105272d26a change-id: 20240420-panel-sw43408-fix-ff6549c121be Best regards, -- Dmitry Baryshkov
Re: [PATCH v2 1/6] drm/ci: uprev mesa version
On Thu, 23 May 2024 at 09:07, Vignesh Raman wrote:
>
> Hi Dmitry,
>
> On 20/05/24 16:13, Dmitry Baryshkov wrote:
> > On Fri, May 17, 2024 at 02:54:57PM +0530, Vignesh Raman wrote:
> >> zlib.net is not allowing tarball download anymore and results
> >> in below error in kernel+rootfs_arm32 container build,
> >> urllib.error.HTTPError: HTTP Error 403: Forbidden
> >> urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
> >>
> >> Uprev mesa to latest version which includes a fix for this issue.
> >> https://gitlab.freedesktop.org/mesa/mesa/-/commit/908f444e
> >>
> >> Use id_tokens for JWT authentication. Since s3 bucket is migrated to
> >> mesa-rootfs, update the variables accordingly. Also copy helper scripts
> >> to install, so that the ci jobs can use these scripts for logging.
> >>
> >> Signed-off-by: Vignesh Raman
> >> ---
> >>
> >> v2:
> >>- Uprev to recent version and use id_tokens for JWT authentication
> >>
> >> ---
> >> drivers/gpu/drm/ci/build-igt.sh | 2 +-
> >> drivers/gpu/drm/ci/build.sh | 6 +++--
> >> drivers/gpu/drm/ci/container.yml | 12 +++--
> >> drivers/gpu/drm/ci/gitlab-ci.yml | 44 +--
> >> drivers/gpu/drm/ci/image-tags.yml | 2 +-
> >> drivers/gpu/drm/ci/lava-submit.sh | 4 +--
> >> drivers/gpu/drm/ci/test.yml | 2 ++
> >> 7 files changed, 44 insertions(+), 28 deletions(-)
> >>
> >
> > [skipped]
> >
> >> diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
> >> index 8bc63912fddb..612c9ede3507 100644
> >> --- a/drivers/gpu/drm/ci/test.yml
> >> +++ b/drivers/gpu/drm/ci/test.yml
> >> @@ -150,6 +150,8 @@ msm:sdm845:
> >> BM_KERNEL: https://${PIPELINE_ARTIFACTS_BASE}/arm64/cheza-kernel
> >> GPU_VERSION: sdm845
> >> RUNNER_TAG: google-freedreno-cheza
> >> +DEVICE_TYPE: sdm845-cheza-r3
> >> +FARM: google
> >
> > I see that this is the only user of the FARM: tag. Is it correct?
>
> No, we need to add FARM variable for other jobs as well.
Why? Even if we have to, we don't have them now and the change doesn't
seem to be related to the uprev'ing of mesa. So this probably should
go to a separate commit.
>
> > Also we miss DEVICE_TYPE for several other boards. Should we be adding
> > them?
>
> Yes, device type needs to be added for msm:apq8016, msm:apq8096, virtio_gpu.
>
> I will add this. Thanks.
I'd guess, separate commit too.
>
> Regards,
> Vignesh
>
> >
> >> script:
> >> - ./install/bare-metal/cros-servo.sh
> >>
> >> --
> >> 2.40.1
> >>
> >
--
With best wishes
Dmitry
[PATCH v3 3/3] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Reviewed-by: Neil Armstrong
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
}
-const struct backlight_ops sw43408_backlight_ops = {
+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
};
--
2.39.2
[PATCH v3 2/3] drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER
This panel driver uses DSC PPS functions and as such depends on the
DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions
available to the driver.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4a2f621433ef..3e3f63479544 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -340,6 +340,8 @@ config DRM_PANEL_LG_SW43408
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_DISPLAY_DSC_HELPER
+ select DRM_DISPLAY_HELPER
help
Say Y here if you want to enable support for LG sw43408 panel.
The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per
--
2.39.2
[PATCH v3 0/3] drm/panel: two fixes for lg-sw43408
Fix two issues with the panel-lg-sw43408 driver reported by the kernel test robot. To: Neil Armstrong To: Jessica Zhang To: Sam Ravnborg To: Maarten Lankhorst To: Maxime Ripard To: Thomas Zimmermann To: David Airlie To: Daniel Vetter To: Sumit Semwal To: Caleb Connolly To: Alex Deucher To: Christian König To: Pan, Xinhui To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: Rob Clark To: Abhinav Kumar To: Sean Paul To: Marijn Suijten To: Vinod Koul To: Caleb Connolly Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: amd-gfx@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Dmitry Baryshkov Changes in v3: - Split DRM_DISPLAY_DSC_HELPER from DRM_DISPLAY_DP_HELPER - Added missing Fixes tags - Link to v2: https://lore.kernel.org/r/20240510-panel-sw43408-fix-v2-0-d1ef91ee1...@linaro.org Changes in v2: - use SELECT instead of DEPEND to follow the reverted Kconfig changes - Link to v1: https://lore.kernel.org/r/20240420-panel-sw43408-fix-v1-0-b282ff725...@linaro.org --- Dmitry Baryshkov (3): drm/display: split DSC helpers from DP helpers drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER drm/panel/lg-sw43408: mark sw43408_backlight_ops as static drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + drivers/gpu/drm/display/Kconfig | 6 ++ drivers/gpu/drm/display/Makefile | 3 ++- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/panel/Kconfig| 6 -- drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +- 7 files changed, 16 insertions(+), 4 deletions(-) --- base-commit: 8314289a8d50a4e05d8ece1ae0445a3b57bb4d3b change-id: 20240420-panel-sw43408-fix-ff6549c121be Best regards, -- Dmitry Baryshkov
[PATCH v3 1/3] drm/display: split DSC helpers from DP helpers
Currently the DRM DSC functions are selected by the DRM_DISPLAY_DP_HELPER Kconfig symbol. This is not optimal, since the DSI code (both panel and host drivers) end up selecting the seemingly irrelevant DP helpers. Split the DSC code to be guarded by the separate DRM_DISPLAY_DSC_HELPER Kconfig symbol. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + drivers/gpu/drm/display/Kconfig| 6 ++ drivers/gpu/drm/display/Makefile | 3 ++- drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/msm/Kconfig| 1 + drivers/gpu/drm/panel/Kconfig | 4 ++-- 6 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 22d88f8ef527..b69d5c4a5367 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -6,6 +6,7 @@ config DRM_AMDGPU depends on !UML select FW_LOADER select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Kconfig b/drivers/gpu/drm/display/Kconfig index 864a6488bfdf..f524cf95dec3 100644 --- a/drivers/gpu/drm/display/Kconfig +++ b/drivers/gpu/drm/display/Kconfig @@ -59,6 +59,12 @@ config DRM_DISPLAY_DP_TUNNEL_STATE_DEBUG If in doubt, say "N". +config DRM_DISPLAY_DSC_HELPER + bool + depends on DRM_DISPLAY_HELPER + help + DRM display helpers for VESA DSC (used by DSI and DisplayPort). + config DRM_DISPLAY_HDCP_HELPER bool depends on DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/display/Makefile b/drivers/gpu/drm/display/Makefile index 17d2cc73ff56..2ec71e15c3cb 100644 --- a/drivers/gpu/drm/display/Makefile +++ b/drivers/gpu/drm/display/Makefile @@ -6,7 +6,8 @@ drm_display_helper-y := drm_display_helper_mod.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_HELPER) += \ drm_dp_dual_mode_helper.o \ drm_dp_helper.o \ - drm_dp_mst_topology.o \ + drm_dp_mst_topology.o +drm_display_helper-$(CONFIG_DRM_DISPLAY_DSC_HELPER) += \ drm_dsc_helper.o drm_display_helper-$(CONFIG_DRM_DISPLAY_DP_TUNNEL) += \ drm_dp_tunnel.o diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 5932024f8f95..117b84260b1c 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -11,6 +11,7 @@ config DRM_I915 select SHMEM select TMPFS select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HDCP_HELPER select DRM_DISPLAY_HDMI_HELPER select DRM_DISPLAY_HELPER diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index 1931ecf73e32..6dcd26180611 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -111,6 +111,7 @@ config DRM_MSM_DSI depends on DRM_MSM select DRM_PANEL select DRM_MIPI_DSI + select DRM_DISPLAY_DSC_HELPER default y help Choose this option if you have a need for MIPI DSI connector diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 982324ef5a41..4a2f621433ef 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -547,7 +547,7 @@ config DRM_PANEL_RAYDIUM_RM692E5 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for Raydium RM692E5-based @@ -905,7 +905,7 @@ config DRM_PANEL_VISIONOX_R66451 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE - select DRM_DISPLAY_DP_HELPER + select DRM_DISPLAY_DSC_HELPER select DRM_DISPLAY_HELPER help Say Y here if you want to enable support for Visionox -- 2.39.2
Re: [PATCH v2 6/6] drm/ci: update xfails for the new testlist
On Fri, May 17, 2024 at 02:55:02PM +0530, Vignesh Raman wrote: > Now the testlist is used from IGT build, so update > xfails with the new testlist. > > Set the timeout of all i915 jobs to 1h30m since some jobs > takes more than 1 hour to complete. > > Signed-off-by: Vignesh Raman > --- > > v2: > - Set the timeout of all i915 jobs to 1h30m and updated expectations file. > > --- > drivers/gpu/drm/ci/test.yml | 6 +- > .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 41 ++-- > .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 6 + > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 18 ++ > drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 31 > .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 8 + > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 11 ++ > drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 46 +++-- > drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 5 + > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 15 ++ > drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 38 > drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 5 + > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 41 +++- > drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 6 + > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 15 ++ > drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 42 ++--- > drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 6 +- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 25 +++ > drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 77 > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 16 ++ > drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 63 --- > drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt | 5 + > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 11 ++ > .../drm/ci/xfails/mediatek-mt8173-fails.txt | 30 ++- > .../drm/ci/xfails/mediatek-mt8173-flakes.txt | 10 + > .../drm/ci/xfails/mediatek-mt8173-skips.txt | 4 + > .../drm/ci/xfails/mediatek-mt8183-fails.txt | 21 +-- > .../drm/ci/xfails/mediatek-mt8183-skips.txt | 4 + > .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 24 +-- > .../gpu/drm/ci/xfails/meson-g12b-skips.txt| 4 + > .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 12 +- > .../gpu/drm/ci/xfails/msm-apq8016-skips.txt | 4 + > .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 7 + > .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 5 + > .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 12 ++ > .../msm-sc7180-trogdor-kingoftown-fails.txt | 175 +- > .../msm-sc7180-trogdor-kingoftown-flakes.txt | 7 + > .../msm-sc7180-trogdor-kingoftown-skips.txt | 7 + > ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 175 +- > ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 5 + > ...sm-sc7180-trogdor-lazor-limozeen-skips.txt | 4 + > .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 38 +--- > .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 26 ++- > .../gpu/drm/ci/xfails/msm-sdm845-skips.txt| 7 + Reviewed-by: Dmitry Baryshkov # msm testlists We'd need to triage why the tests are failing, but at least it looks logical from my POV, no more full-test skips, etc. > .../drm/ci/xfails/rockchip-rk3288-fails.txt | 62 +-- > .../drm/ci/xfails/rockchip-rk3288-skips.txt | 4 + > .../drm/ci/xfails/rockchip-rk3399-fails.txt | 83 + > .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 12 +- > .../drm/ci/xfails/rockchip-rk3399-skips.txt | 4 + > drivers/gpu/drm/ci/xfails/update-xfails.py| 4 +- > .../drm/ci/xfails/virtio_gpu-none-fails.txt | 94 +++--- > .../drm/ci/xfails/virtio_gpu-none-skips.txt | 4 + > 53 files changed, 1010 insertions(+), 389 deletions(-) > create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt -- With best wishes Dmitry
Re: [PATCH v2 5/6] drm/ci: skip driver specific tests
On Fri, May 17, 2024 at 02:55:01PM +0530, Vignesh Raman wrote: > Skip driver specific tests and skip kms tests for > panfrost driver since it is not a kms driver. > > Signed-off-by: Vignesh Raman > --- I didn't perform a through check, but generally looks good. Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 4/6] drm/ci: uprev IGT
On Fri, May 17, 2024 at 02:55:00PM +0530, Vignesh Raman wrote: > test-list.txt and test-list-full.txt are not generated for > cross-builds and they are required by drm-ci for testing > arm32 targets. > > This is fixed in igt-gpu-tools. So uprev IGT to include the > commit which fixes this issue. Disable building xe driver > tests for non-intel platforms. > > Signed-off-by: Vignesh Raman > --- > > v2: > - Split IGT uprev to seperate patch. > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 3/6] drm/ci: build virtual GPU driver as module
On Fri, May 17, 2024 at 02:54:59PM +0530, Vignesh Raman wrote:
> With latest IGT, the tests tries to load the module and it
> fails. So build the virtual GPU driver for virtio as module.
Why? If the test fails on module loading (if the driver is built-in)
then it's the test that needs to be fixed, not the kerenel config.
It's fine as a temporal workaround, but please include a link to the
patch posted to fix the issue.
>
> Signed-off-by: Vignesh Raman
> ---
>
> v2:
> - No changes.
>
> ---
> drivers/gpu/drm/ci/build.sh | 1 -
> drivers/gpu/drm/ci/igt_runner.sh | 6 +++---
> drivers/gpu/drm/ci/image-tags.yml | 4 ++--
> drivers/gpu/drm/ci/test.yml | 1 +
> drivers/gpu/drm/ci/x86_64.config | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
> index a67871fdcd3f..e938074ac8e7 100644
> --- a/drivers/gpu/drm/ci/build.sh
> +++ b/drivers/gpu/drm/ci/build.sh
> @@ -157,7 +157,6 @@ fi
>
> 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
>
> diff --git a/drivers/gpu/drm/ci/igt_runner.sh
> b/drivers/gpu/drm/ci/igt_runner.sh
> index 20026612a9bd..55532f79fbdc 100755
> --- a/drivers/gpu/drm/ci/igt_runner.sh
> +++ b/drivers/gpu/drm/ci/igt_runner.sh
> @@ -30,10 +30,10 @@ case "$DRIVER_NAME" in
> export IGT_FORCE_DRIVER="panfrost"
> fi
> ;;
> -amdgpu)
> +amdgpu|virtio_gpu)
> # 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
> +mv /install/modules/lib/modules/* /lib/modules/. || true
> +modprobe --first-time $DRIVER_NAME
> ;;
> esac
>
> diff --git a/drivers/gpu/drm/ci/image-tags.yml
> b/drivers/gpu/drm/ci/image-tags.yml
> index 60323ebc7304..328f5c560742 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: "2023-10-08-config"
> + DEBIAN_BUILD_TAG: "2024-05-09-virtio"
>
> - KERNEL_ROOTFS_TAG: "2023-10-06-amd"
> + KERNEL_ROOTFS_TAG: "2024-05-09-virtio"
>
> 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/test.yml b/drivers/gpu/drm/ci/test.yml
> index 612c9ede3507..864ac3809d84 100644
> --- a/drivers/gpu/drm/ci/test.yml
> +++ b/drivers/gpu/drm/ci/test.yml
> @@ -350,6 +350,7 @@ virtio_gpu:none:
>script:
> - ln -sf $CI_PROJECT_DIR/install /install
> - mv install/bzImage /lava-files/bzImage
> +- mkdir -p /lib/modules
Is it necessary to create it manually here?
> - mkdir -p $CI_PROJECT_DIR/results
> - ln -sf $CI_PROJECT_DIR/results /results
> - install/crosvm-runner.sh install/igt_runner.sh
> diff --git a/drivers/gpu/drm/ci/x86_64.config
> b/drivers/gpu/drm/ci/x86_64.config
> index 1cbd49a5b23a..78479f063e8e 100644
> --- a/drivers/gpu/drm/ci/x86_64.config
> +++ b/drivers/gpu/drm/ci/x86_64.config
> @@ -91,7 +91,7 @@ CONFIG_KVM=y
> CONFIG_KVM_GUEST=y
> CONFIG_VIRT_DRIVERS=y
> CONFIG_VIRTIO_FS=y
> -CONFIG_DRM_VIRTIO_GPU=y
> +CONFIG_DRM_VIRTIO_GPU=m
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_VIRTIO_NET=y
> CONFIG_VIRTIO_CONSOLE=y
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [PATCH v2 2/6] drm/ci: generate testlist from build
On Fri, May 17, 2024 at 02:54:58PM +0530, Vignesh Raman wrote:
> Stop vendoring the testlist into the kernel. Instead, use the
> testlist from the IGT build to ensure we do not miss renamed
> or newly added tests.
>
> Signed-off-by: Vignesh Raman
> ---
>
> v2:
> - Fix testlist generation for arm and arm64 builds.
>
> ---
> drivers/gpu/drm/ci/build-igt.sh | 34 +
> drivers/gpu/drm/ci/igt_runner.sh |9 +-
> drivers/gpu/drm/ci/testlist.txt | 2761 --
> 3 files changed, 39 insertions(+), 2765 deletions(-)
> delete mode 100644 drivers/gpu/drm/ci/testlist.txt
>
> diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
> index 7859554756c4..e62244728613 100644
> --- a/drivers/gpu/drm/ci/build-igt.sh
> +++ b/drivers/gpu/drm/ci/build-igt.sh
[...]
> @@ -26,6 +50,16 @@ meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
> ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
> ninja -C build install
>
> +if [[ "$KERNEL_ARCH" = "arm64" ]]; then
> +export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/igt/lib/aarch64-linux-gnu
> +elif [[ "$KERNEL_ARCH" = "arm" ]]; then
> +export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/igt/lib
> +else
> +export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/igt/lib64
Could you please clarify this part? The arm64 vs arm don't look logical
from my point of view.
The rest LGTM.
> +fi
> +
> +generate_testlist
> +
> mkdir -p artifacts/
> tar -cf artifacts/igt.tar /igt
>
--
With best wishes
Dmitry
Re: [PATCH v2 1/6] drm/ci: uprev mesa version
On Fri, May 17, 2024 at 02:54:57PM +0530, Vignesh Raman wrote:
> zlib.net is not allowing tarball download anymore and results
> in below error in kernel+rootfs_arm32 container build,
> urllib.error.HTTPError: HTTP Error 403: Forbidden
> urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
>
> Uprev mesa to latest version which includes a fix for this issue.
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/908f444e
>
> Use id_tokens for JWT authentication. Since s3 bucket is migrated to
> mesa-rootfs, update the variables accordingly. Also copy helper scripts
> to install, so that the ci jobs can use these scripts for logging.
>
> Signed-off-by: Vignesh Raman
> ---
>
> v2:
> - Uprev to recent version and use id_tokens for JWT authentication
>
> ---
> drivers/gpu/drm/ci/build-igt.sh | 2 +-
> drivers/gpu/drm/ci/build.sh | 6 +++--
> drivers/gpu/drm/ci/container.yml | 12 +++--
> drivers/gpu/drm/ci/gitlab-ci.yml | 44 +--
> drivers/gpu/drm/ci/image-tags.yml | 2 +-
> drivers/gpu/drm/ci/lava-submit.sh | 4 +--
> drivers/gpu/drm/ci/test.yml | 2 ++
> 7 files changed, 44 insertions(+), 28 deletions(-)
>
[skipped]
> diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
> index 8bc63912fddb..612c9ede3507 100644
> --- a/drivers/gpu/drm/ci/test.yml
> +++ b/drivers/gpu/drm/ci/test.yml
> @@ -150,6 +150,8 @@ msm:sdm845:
> BM_KERNEL: https://${PIPELINE_ARTIFACTS_BASE}/arm64/cheza-kernel
> GPU_VERSION: sdm845
> RUNNER_TAG: google-freedreno-cheza
> +DEVICE_TYPE: sdm845-cheza-r3
> +FARM: google
I see that this is the only user of the FARM: tag. Is it correct?
Also we miss DEVICE_TYPE for several other boards. Should we be adding
them?
>script:
> - ./install/bare-metal/cros-servo.sh
>
> --
> 2.40.1
>
--
With best wishes
Dmitry
Re: [PATCH 09/11] drm/msm: Use fbdev client helpers
On Tue, May 07, 2024 at 01:58:30PM +0200, Thomas Zimmermann wrote: > Implement struct drm_client_funcs with the respective helpers and > remove the custom code from the emulation. The generic helpers are > equivalent in functionality. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/msm/msm_fbdev.c | 58 ++--- > 1 file changed, 3 insertions(+), 55 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v1 2/5] drm/ci: generate testlist from build
On Tue, Apr 30, 2024 at 02:41:18PM +0530, Vignesh Raman wrote:
> Stop vendoring the testlist into the kernel. Instead, use the
> testlist from the IGT build to ensure we do not miss renamed
> or newly added tests.
>
> Signed-off-by: Vignesh Raman
> ---
> drivers/gpu/drm/ci/build-igt.sh | 23 +
> drivers/gpu/drm/ci/igt_runner.sh |9 +-
> drivers/gpu/drm/ci/testlist.txt | 2761 --
> 3 files changed, 28 insertions(+), 2765 deletions(-)
> delete mode 100644 drivers/gpu/drm/ci/testlist.txt
>
> diff --git a/drivers/gpu/drm/ci/build-igt.sh b/drivers/gpu/drm/ci/build-igt.sh
> index 500fa4f5c30a..cedc62baba1e 100644
> --- a/drivers/gpu/drm/ci/build-igt.sh
> +++ b/drivers/gpu/drm/ci/build-igt.sh
> @@ -26,6 +26,29 @@ meson build $MESON_OPTIONS $EXTRA_MESON_ARGS
> ninja -C build -j${FDO_CI_CONCURRENT:-4} || ninja -C build -j 1
> ninja -C build install
>
> +set +ex
> +export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/igt/lib64
> +while read -r line; do
> +if [ "$line" = "TESTLIST" ] || [ "$line" = "END TESTLIST" ]; then
> +continue
> +fi
> +
> +tests=$(echo "$line" | tr ' ' '\n')
> +
> +for test in $tests; do
> +output=$(/igt/libexec/igt-gpu-tools/"$test" --list-subtests)
> +
> +if [ -z "$output" ]; then
> +echo "$test"
> +else
> +echo "$output" | while read -r subtest; do
> +echo "$test@$subtest"
> +done
> +fi
> +done
> +done < /igt/libexec/igt-gpu-tools/test-list.txt >
> /igt/libexec/igt-gpu-tools/testlist.txt
> +set -ex
Is the list in sync between x86 and arm/arm64 IGT builds? Is there a
chance of having a safety net here?
> +
> mkdir -p artifacts/
> tar -cf artifacts/igt.tar /igt
>
> diff --git a/drivers/gpu/drm/ci/igt_runner.sh
> b/drivers/gpu/drm/ci/igt_runner.sh
> index f1a08b9b146f..20026612a9bd 100755
> --- a/drivers/gpu/drm/ci/igt_runner.sh
> +++ b/drivers/gpu/drm/ci/igt_runner.sh
> @@ -59,25 +59,26 @@ 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 /
>
> +TESTLIST="/igt/libexec/igt-gpu-tools/testlist.txt"
>
> # 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
> +sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" $TESTLIST
> 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
> +if ! grep -q "core_getversion" $TESTLIST; then
> # Add the line to the file
> -echo "core_getversion" >> /install/testlist.txt
> +echo "core_getversion" >> $TESTLIST
> fi
>
> set +e
> igt-runner \
> run \
> --igt-folder /igt/libexec/igt-gpu-tools \
> ---caselist /install/testlist.txt \
> +--caselist $TESTLIST \
> --output /results \
> $IGT_SKIPS \
> $IGT_FLAKES \
--
With best wishes
Dmitry
Re: [PATCH v1 5/5] drm/ci: update xfails for the new testlist
On Tue, Apr 30, 2024 at 02:41:21PM +0530, Vignesh Raman wrote: > Now the testlist is used from IGT build, so update > xfails with the new testlist. > > Signed-off-by: Vignesh Raman > --- > .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 47 +++ > .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 8 +- > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 15 > drivers/gpu/drm/ci/xfails/i915-amly-fails.txt | 22 - > .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 8 ++ > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 8 ++ > drivers/gpu/drm/ci/xfails/i915-apl-fails.txt | 45 +- > drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt | 5 ++ > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt | 12 +++ > drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 26 +- > drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 6 ++ > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt | 8 ++ > drivers/gpu/drm/ci/xfails/i915-glk-fails.txt | 28 +-- > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt | 12 +++ > drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt | 39 - > drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 10 ++- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt | 21 + > drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt | 75 + > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt | 13 +++ > drivers/gpu/drm/ci/xfails/i915-whl-fails.txt | 46 +-- > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt | 8 ++ > .../drm/ci/xfails/mediatek-mt8173-fails.txt | 47 +++ > .../drm/ci/xfails/mediatek-mt8183-fails.txt | 17 +--- > .../drm/ci/xfails/mediatek-mt8183-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 20 + > .../gpu/drm/ci/xfails/meson-g12b-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-apq8016-fails.txt | 26 ++ > .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-apq8096-fails.txt | 5 +- > .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-apq8096-skips.txt | 67 +++ > .../msm-sc7180-trogdor-kingoftown-fails.txt | 34 > .../msm-sc7180-trogdor-kingoftown-flakes.txt | 5 ++ > ...sm-sc7180-trogdor-lazor-limozeen-fails.txt | 34 > ...m-sc7180-trogdor-lazor-limozeen-flakes.txt | 5 ++ > .../gpu/drm/ci/xfails/msm-sdm845-fails.txt| 75 - > .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt | 26 ++ > .../drm/ci/xfails/rockchip-rk3288-fails.txt | 54 > .../drm/ci/xfails/rockchip-rk3399-fails.txt | 80 ++ > .../drm/ci/xfails/rockchip-rk3399-flakes.txt | 7 -- > .../drm/ci/xfails/virtio_gpu-none-fails.txt | 82 +-- > .../drm/ci/xfails/virtio_gpu-none-skips.txt | 3 + > 42 files changed, 574 insertions(+), 495 deletions(-) > create mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-flakes.txt > create mode 100644 > drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-flakes.txt > delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-fails.txt > delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt > [skipped] > diff --git a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > index 44a5c62dedad..96e9faf0e607 100644 > --- a/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > +++ b/drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt > @@ -1,19 +1,9 @@ > +core_setmaster_vs_auth,Fail > +device_reset,Fail > +dumb_buffer,Fail This doesn't look correct, core tests should be passing. > 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 > -kms_cursor_legacy@pipe-A-torture-bo,Fail > -kms_cursor_legacy@pipe-A-torture-move,Fail > -kms_force_connector_basic@force-edid,Fail > -kms_hdmi_inject@inject-4k,Fail > -kms_selftest@drm_format,Timeout > -kms_selftest@drm_format_helper,Timeout Fine, kms_cursor_legacy tests were migrated to -flakes. But what happened with the rest of the failures? > -msm_mapping@ring,Fail >
Re: [PATCH v1 4/5] drm/ci: skip driver specific tests
On Tue, Apr 30, 2024 at 02:41:20PM +0530, Vignesh Raman wrote: > Skip driver specific tests and skip kms tests for > panfrost driver since it is not a kms driver. > > Signed-off-by: Vignesh Raman > --- > .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt | 14 +- > drivers/gpu/drm/ci/xfails/i915-amly-skips.txt | 14 +- > drivers/gpu/drm/ci/xfails/i915-apl-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-cml-skips.txt| 12 > drivers/gpu/drm/ci/xfails/i915-glk-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt| 14 +- > drivers/gpu/drm/ci/xfails/i915-whl-skips.txt| 14 +- > .../gpu/drm/ci/xfails/mediatek-mt8173-skips.txt | 12 > .../gpu/drm/ci/xfails/mediatek-mt8183-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt | 14 ++ > drivers/gpu/drm/ci/xfails/msm-apq8096-skips.txt | 14 +- Reviewed-by: Dmitry Baryshkov # msm skips > .../msm-sc7180-trogdor-kingoftown-skips.txt | 15 +++ > .../msm-sc7180-trogdor-lazor-limozeen-skips.txt | 15 +++ > drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt | 15 +++ > .../gpu/drm/ci/xfails/rockchip-rk3288-skips.txt | 17 - > .../gpu/drm/ci/xfails/rockchip-rk3399-skips.txt | 15 +++ > .../gpu/drm/ci/xfails/virtio_gpu-none-skips.txt | 15 ++- > 19 files changed, 260 insertions(+), 10 deletions(-) > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-skips.txt > create mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-skips.txt > create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-skips.txt > create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-skips.txt > -- With best wishes Dmitry
Re: [PATCH v1 3/4] drm/ci: uprev IGT and generate testlist from build
On Tue, 23 Apr 2024 at 13:24, Maíra Canal wrote: > > On 4/23/24 01:02, Vignesh Raman wrote: > > Uprev IGT to the latest version and stop vendoring the > > testlist into the kernel. Instead, use the testlist from > > the IGT build to ensure we do not miss renamed or newly > > added tests. > > Nitpick: wouldn't it be better to (1) stop vendoring the > testlist into the kernel in one patch and then (2) uprev > IGT to the latest version? I feel that this patch is changing > a lot of different stuff. Definitely. Otherwise it's hard to understand whether a change to fails/flakes is caused by the uprev or by the testlist change. E.g. in several cases the list of failing subtests seems to be replaced with the test itself. > > Best Regards, > - Maíra > > > > > Skip kms tests for panfrost driver since it is not a kms > > driver and skip driver-specific tests. Update xfails with > > the latest testlist. > > > > Increase the timoout of i915 jobs to 2h30m since some jobs > > takes more than 2 hours to complete. > > > > Signed-off-by: Vignesh Raman > > --- -- With best wishes Dmitry
Re: [PATCH 1/2] drm/print: drop include debugfs.h and include where needed
On Mon, Apr 22, 2024 at 03:10:10PM +0300, Jani Nikula wrote: > Surprisingly many places depend on debugfs.h to be included via > drm_print.h. Fix them. > > v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe > > v2: Also fix ivpu and vmwgfx > > Reviewed-by: Andrzej Hajda > Acked-by: Maxime Ripard > Link: > https://patchwork.freedesktop.org/patch/msgid/20240410141434.157908-1-jani.nik...@intel.com > Signed-off-by: Jani Nikula > > --- > > Cc: Jacek Lawrynowicz > Cc: Stanislaw Gruszka > Cc: Oded Gabbay > Cc: Russell King > Cc: David Airlie > Cc: Daniel Vetter > Cc: Andrzej Hajda > Cc: Neil Armstrong > Cc: Robert Foss > Cc: Laurent Pinchart > Cc: Jonas Karlman > Cc: Jernej Skrabec > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: Jani Nikula > Cc: Rodrigo Vivi > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Frank Binns > Cc: Matt Coster > Cc: Rob Clark > Cc: Abhinav Kumar > Cc: Dmitry Baryshkov > Cc: Sean Paul > Cc: Marijn Suijten > Cc: Karol Herbst > Cc: Lyude Paul > Cc: Danilo Krummrich > Cc: Alex Deucher > Cc: "Christian König" > Cc: "Pan, Xinhui" > Cc: Alain Volmat > Cc: Huang Rui > Cc: Zack Rusin > Cc: Broadcom internal kernel review list > > Cc: Lucas De Marchi > Cc: "Thomas Hellström" > Cc: dri-de...@lists.freedesktop.org > Cc: intel-...@lists.freedesktop.org > Cc: intel...@lists.freedesktop.org > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: amd-gfx@lists.freedesktop.org > --- > drivers/accel/ivpu/ivpu_debugfs.c | 2 ++ > drivers/gpu/drm/armada/armada_debugfs.c | 1 + > drivers/gpu/drm/bridge/ite-it6505.c | 1 + > drivers/gpu/drm/bridge/panel.c | 2 ++ > drivers/gpu/drm/drm_print.c | 6 +++--- > drivers/gpu/drm/i915/display/intel_dmc.c| 1 + > drivers/gpu/drm/imagination/pvr_fw_trace.c | 1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 ++ Acked-by: Dmitry Baryshkov # drm/msm > drivers/gpu/drm/nouveau/dispnv50/crc.c | 2 ++ > drivers/gpu/drm/radeon/r100.c | 1 + > drivers/gpu/drm/radeon/r300.c | 1 + > drivers/gpu/drm/radeon/r420.c | 1 + > drivers/gpu/drm/radeon/r600.c | 3 ++- > drivers/gpu/drm/radeon/radeon_fence.c | 1 + > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > drivers/gpu/drm/radeon/radeon_ib.c | 2 ++ > drivers/gpu/drm/radeon/radeon_pm.c | 1 + > drivers/gpu/drm/radeon/radeon_ring.c| 2 ++ > drivers/gpu/drm/radeon/radeon_ttm.c | 1 + > drivers/gpu/drm/radeon/rs400.c | 1 + > drivers/gpu/drm/radeon/rv515.c | 1 + > drivers/gpu/drm/sti/sti_drv.c | 1 + > drivers/gpu/drm/ttm/ttm_device.c| 1 + > drivers/gpu/drm/ttm/ttm_resource.c | 3 ++- > drivers/gpu/drm/ttm/ttm_tt.c| 5 +++-- > drivers/gpu/drm/vc4/vc4_drv.h | 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 2 ++ > drivers/gpu/drm/xe/xe_debugfs.c | 1 + > drivers/gpu/drm/xe/xe_gt_debugfs.c | 2 ++ > drivers/gpu/drm/xe/xe_uc_debugfs.c | 2 ++ > include/drm/drm_print.h | 2 +- > 31 files changed, 46 insertions(+), 8 deletions(-) -- With best wishes Dmitry
DisplayPort: handling of HPD events / link training
Hello, We are currently looking at checking and/or possibly redesigning the way the MSM DRM driver handles the HPD events and link training. After a quick glance at the drivers implementing DP support, I noticed following main approaches: - Perform link training at the atomic_enable time, don't report failures (mtk, analogix, zynqmp, tegra, nouveau) - Perform link training at the atomic_enable time, report errors using link_status property (i915, mhdp8546) - Perform link training on the plug event (msm, it8605). - Perform link training from the DPMS handler, also calling it from the enable callback (AMDGPU, radeon). It looks like the majority wins and we should move HPD to atomic_enable time. Is that assumption correct? Also two related questions: - Is there a plan to actually make use of the link_status property? Intel presented it at FOSDEM 2018, but since that time it was not picked up by other drivers. - Is there any plan to create generic DP link training helpers? After glancing through the DP drivers there is a lot of similar code in the link training functions, with minor differences here and there. And it's those minor differences that bug me. It means that drivers might respond differently to similar devices. Or that there might be minor bugs here and there. -- With best wishes Dmitry
Re: [PATCH -next 0/7] drm: Remove many unnecessary NULL values
On Wed, 09 Aug 2023 11:44:38 +0800, Ruan Jinjie wrote: > The NULL initialization of the pointers assigned by kzalloc() or > kunit_kzalloc() first is not necessary, because if the kzalloc() or > kunit_kzalloc() failed, the pointers will be assigned NULL, otherwise > it works as usual. so remove it. > > Ruan Jinjie (7): > drm/amdkfd: Remove unnecessary NULL values > drm/amd/display: Remove unnecessary NULL values > drm/msm: Remove unnecessary NULL values > drm/radeon: Remove unnecessary NULL values > drm/virtio: Remove an unnecessary NULL value > drm/format-helper: Remove unnecessary NULL values > drm: Remove unnecessary NULL values > > [...] Applied, thanks! [3/7] drm/msm: Remove unnecessary NULL values https://gitlab.freedesktop.org/lumag/msm/-/commit/92a48b6ed510 Best regards, -- Dmitry Baryshkov
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
On 18/08/2023 09:24, Simon Ser wrote: On Thursday, August 17th, 2023 at 21:33, Dmitry Baryshkov wrote: We have been looking for a way to document that the corresponding DP port is represented by the USB connector on the device. Consequently, I believe the best way to document it, would be to use DisplayPort / USB, when there is no dongle connected, switching to DisplayPort / HDMI, DisplayPort / VGA, DisplayPort / DisplayPort, etc. when the actual dongle / display is connected and then switching back to the DisplayPort / USB when it gets disconnected. If this sounds good to all parties, I'll post v2, adding this explanation to the cover letter. But how can user-space discover that the port is USB-C when it's connected? That information is lost at this point. Yes, unfortunately. (In addition, this clashes with the existing semantics of the subconnector prop as discussed before: USB-C is not sub-, it's super-.) Ok. How do we proceed then? Is it fine to add another property for DP case? Do you have any particular property name in mind? I will follow with addition of this property then. -- With best wishes Dmitry
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
Simon, Laurent, On 03/08/2023 23:46, Simon Ser wrote: On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart wrote: On Thu, Aug 03, 2023 at 03:31:16PM +, Simon Ser wrote: On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr wrote: The KMS docs describe "subconnector" to be defined as "downstream port" for DP. Can USB-C (or USB) be seen as a DP downstream port? To expand on this a bit: I'm wondering if we're mixing apples and oranges here. The current values of "subconnector" typically describe the lower-level protocol tunneled inside DP. For instance, VGA can be tunneled inside the DP cable when using DP → VGA adapter. Doesn't this contradict the example use case you gave in your previous e-mail, with wlroots stating "DP-3 via DVI-D" ? I understand that as DP carried over a DVI-D physical connector, did I get it wrong ? No, this is DVI carried over DP. DP cannot be carried over VGA/DVI/HDMI, but VGA/DVI/HDMI can be carried over DP. Please excuse me for the long delay, I was on vacation. Several notes on the subconnector topic. For TV and DVI-I we are really identifying a connector (or a part of the connector pins) present on the device. So, we can have e.g. following combinations (type / subtype): DVI-I / DVI-D (digital part of DVI connector) DVI-I / DVI-A (analog part of DVI connector) TV / S-Video (full S-Video connector) TV / Composite (either a separate Composite connector, or shared with S-Video) etc. For DP unfortunately we have mixed everything together. The physical connector present on the device can be DP / miniDP or USB-C (or micro-USB for SlimPort). The physical protocol can be DP or DVI / HDMI (but only for dual-mode DP ports). Over USB-C link the DP can be transferred using DP or USB signal levels. And last, but not least, we have the dongle / display connector type, which can be VGA (for active DP -> VGA converters), HDMI, DVI, DP, etc. If we were designing this from the scratch, I'd say that we should encode physical connector type to DRM connector type and the dongle type to subconnector. However AMD and Intel drivers have already reused DisplayPort connector type for USB-C connections. Subconnector type represents (if known) the type of downstream / dongle port. I'm not going to judge whether this was correct or not. We have to live with this and behave in a similar way. We have been looking for a way to document that the corresponding DP port is represented by the USB connector on the device. Consequently, I believe the best way to document it, would be to use DisplayPort / USB, when there is no dongle connected, switching to DisplayPort / HDMI, DisplayPort / VGA, DisplayPort / DisplayPort, etc. when the actual dongle / display is connected and then switching back to the DisplayPort / USB when it gets disconnected. If this sounds good to all parties, I'll post v2, adding this explanation to the cover letter. -- With best wishes Dmitry
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
On Thu, 3 Aug 2023 at 18:31, Simon Ser wrote: > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser wrote: > > > The KMS docs describe "subconnector" to be defined as "downstream port" for > > DP. > > Can USB-C (or USB) be seen as a DP downstream port? > > To expand on this a bit: I'm wondering if we're mixing apples and > oranges here. The current values of "subconnector" typically describe > the lower-level protocol tunneled inside DP. For instance, VGA can be > tunneled inside the DP cable when using DP → VGA adapter. My opinion hasn't changed: I think this should be the USB connector with proper DP / DVI / HDMI / etc. subconnector type (or lack of it). In the end, the physical connector on the side of laptop is USB-C. If we want to make it different from GUD, we might want to define a USB-DP connector type (which would also include SlimPort). > > However, in the USB-C case, DP itself is tunneled inside USB-C. And you > might use a USB-C → DP adapter. So it's not really *sub*connector, it's > more of a *super*connector, right? > > I think [1] is somewhat related, since it also allows user-space to > discover whether a connector uses USB-C. But relying on sysfs to figure > this out isn't super optimal perhaps. > > [1]: > https://lore.kernel.org/dri-devel/20221108185004.2263578-1-wonch...@google.com/ -- With best wishes Dmitry
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
On Thu, 3 Aug 2023 at 23:47, Simon Ser wrote: > > On Thursday, August 3rd, 2023 at 22:44, Laurent Pinchart > wrote: > > > On Thu, Aug 03, 2023 at 03:31:16PM +, Simon Ser wrote: > > > > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr > > > wrote: > > > > > > > The KMS docs describe "subconnector" to be defined as "downstream port" > > > > for DP. > > > > Can USB-C (or USB) be seen as a DP downstream port? > > > > > > To expand on this a bit: I'm wondering if we're mixing apples and > > > oranges here. The current values of "subconnector" typically describe > > > the lower-level protocol tunneled inside DP. For instance, VGA can be > > > tunneled inside the DP cable when using DP → VGA adapter. > > > > Doesn't this contradict the example use case you gave in your previous > > e-mail, with wlroots stating "DP-3 via DVI-D" ? I understand that as DP > > carried over a DVI-D physical connector, did I get it wrong ? > > No, this is DVI carried over DP. DP cannot be carried over VGA/DVI/HDMI, > but VGA/DVI/HDMI can be carried over DP. Well, not quite. It means that the sink (display) connected to this port identifies itself as an VGA / DVI / HDMI monitor. E.g. on if connect HDMI/DVI monitor through the DP-DVI dongle (native DP connector), AMD driver still identifies it as 'subconnector HDMI', despite dongle a DVI connector on the other side. -- With best wishes Dmitry
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
On Thu, 3 Aug 2023 at 18:43, Simon Ser wrote: > > On Thursday, August 3rd, 2023 at 17:36, Dmitry Baryshkov > wrote: > > > On Thu, 3 Aug 2023 at 18:31, Simon Ser cont...@emersion.fr wrote: > > > > > On Thursday, August 3rd, 2023 at 17:22, Simon Ser cont...@emersion.fr > > > wrote: > > > > > > > The KMS docs describe "subconnector" to be defined as "downstream port" > > > > for DP. > > > > Can USB-C (or USB) be seen as a DP downstream port? > > > > > > To expand on this a bit: I'm wondering if we're mixing apples and > > > oranges here. The current values of "subconnector" typically describe > > > the lower-level protocol tunneled inside DP. For instance, VGA can be > > > tunneled inside the DP cable when using DP → VGA adapter. > > > > My opinion hasn't changed: I think this should be the USB connector > > with proper DP / DVI / HDMI / etc. subconnector type (or lack of it). > > In the end, the physical connector on the side of laptop is USB-C. > > - Even if the connector is USB-C, the protocol used for display is > still DP. There's also the case of Thunderbolt. Yes. But the connector type is not about the protocol. > - This is inconsistent with existing drivers. i915 and amdgpu expose > DP ports for their USB-C ports. Changing that isn't possible without > causing user-space regressions (compositor config files use the > connector type). Yes, I know. Consider my phrase as a personal opinion or minority report. I think that using DisplayPort for USB-C connectors was a mistake, which we now have to cope with somehow. -- With best wishes Dmitry
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
2 августа 2023 г. 22:13:51 GMT+03:00, Laurent Pinchart
пишет:
>On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote:
>> On 02/08/2023 21:55, Laurent Pinchart wrote:
>> > Hi Dmitry,
>> >
>> > Thank you for the patch.
>> >
>> > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
>> >> To properly define the USB-C DP altmode connectors, add the USB
>> >> subconnector type.
>> >>
>> >> Suggested-by: Simon Ser
>> >> Signed-off-by: Dmitry Baryshkov
>> >> ---
>> >> drivers/gpu/drm/drm_connector.c | 1 +
>> >> include/uapi/drm/drm_mode.h | 1 +
>> >> 2 files changed, 2 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_connector.c
>> >> b/drivers/gpu/drm/drm_connector.c
>> >> index a6066e4a5e9a..9e96b038f5d0 100644
>> >> --- a/drivers/gpu/drm/drm_connector.c
>> >> +++ b/drivers/gpu/drm/drm_connector.c
>> >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
>> >> drm_dp_subconnector_enum_list[] = {
>> >> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
>> >> { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
>> >> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
>> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
>> >
>> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
>> > another USB type later ?
>>
>> Hmm, which id should I use for micro-USB then? (consider anx7808,
>> SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of
>> them. But maybe I should add another subtype for SlimPort.
>
>I suppose it depends on whether userspace needs a way to differentiate
>those. Do you have a good visibility on the userspace use cases ?
No. I'm not even sure, which userspace handles subtypes properly.
For the reference, SlimPort is mostly legacy hardware, think about Nexus 4, 5,
6, 7 (2013)
>
>> >> };
>> >>
>> >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> >> index 92d96a2b6763..0f74918b011c 100644
>> >> --- a/include/uapi/drm/drm_mode.h
>> >> +++ b/include/uapi/drm/drm_mode.h
>> >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector {
>> >> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
>> >> DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
>> >> DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
>> >> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
>> >> };
>> >>
>> >> #define DRM_MODE_CONNECTOR_Unknown 0
>
Re: [PATCH 1/4] drm: allow specifying default subtype for the DP subconnector property
On 02/08/2023 21:54, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:10AM +0300, Dmitry Baryshkov wrote:
In the embedded usecases the default subtype depends on the bridge
chain, so it is easier to specify the subtype at the proprety attachment
s/proprety/property/
type rather than specifying it later.
Did you mean s/type/time/ ?
I think I understand why you need this, looking at patch 2/4, but the
commit message isn't very clear. It would benefit from being reworded.
Ack, thanks for the feedback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 3 ++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 ++-
drivers/gpu/drm/drm_connector.c | 6 --
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
include/drm/drm_connector.h | 3 ++-
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index d34037b85cf8..c18459ecd4be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -2022,7 +2022,8 @@ amdgpu_connector_add(struct amdgpu_device *adev,
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
-
drm_connector_attach_dp_subconnector_property(_connector->base);
+
drm_connector_attach_dp_subconnector_property(_connector->base,
+
DRM_MODE_SUBCONNECTOR_Unknown);
}
return;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 943959012d04..297321f0199e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -759,7 +759,8 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_mst_topology_mgr_init(>mst_mgr,
adev_to_drm(dm->adev),
>dm_dp_aux.aux, 16, 4,
aconnector->connector_id);
- drm_connector_attach_dp_subconnector_property(>base);
+ drm_connector_attach_dp_subconnector_property(>base,
+
DRM_MODE_SUBCONNECTOR_Unknown);
}
int dm_mst_get_pbn_divider(struct dc_link *link)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a3d3e7dc08b2..a6066e4a5e9a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1577,10 +1577,12 @@ EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
/**
* drm_connector_attach_dp_subconnector_property - create subconnector
property for DP
* @connector: drm_connector to attach property
+ * @subtype: initial value for the subconnector type
*
* Called by a driver when DP connector is created.
*/
-void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector)
+void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector,
+ enum drm_mode_subconnector
subtype)
{
struct drm_mode_config *mode_config = >dev->mode_config;
@@ -1594,7 +1596,7 @@ void drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
drm_object_attach_property(>base,
mode_config->dp_subconnector_property,
- DRM_MODE_SUBCONNECTOR_Unknown);
+ subtype);
}
EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 474785110662..5819105187f6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5391,7 +5391,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
enum port port = dp_to_dig_port(intel_dp)->base.port;
if (!intel_dp_is_edp(intel_dp))
- drm_connector_attach_dp_subconnector_property(connector);
+ drm_connector_attach_dp_subconnector_property(connector,
+
DRM_MODE_SUBCONNECTOR_Unknown);
if (!IS_G4X(dev_priv) && port != PORT_A)
intel_attach_force_audio_property(connector);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5a8115dca359..a130a78f6e0f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1990,7 +1990,8 @@ const char *drm_get_hdcp_content_type_name(int val);
int drm_get_tv_mode_from_name(const char *name, size_t len);
int drm_mode
Re: [PATCH 2/4] drm/bridge-connector: handle subconnector types
On 02/08/2023 21:46, Laurent Pinchart wrote:
On Wed, Aug 02, 2023 at 12:05:50PM +0300, Dmitry Baryshkov wrote:
On Wed, 2 Aug 2023 at 11:35, Neil Armstrong wrote:
On 29/07/2023 02:49, Dmitry Baryshkov wrote:
If the created connector type supports subconnector type property,
create and attach corresponding it. The default subtype value is 0,
which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 33 +-
include/drm/drm_bridge.h | 4
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 07b5930b1282..a7b92f0d2430 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+ enum drm_mode_subconnector subconnector;
int connector_type;
+ int ret;
bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
if (!bridge_connector)
@@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
- if (!drm_bridge_get_next_bridge(bridge))
+ if (!drm_bridge_get_next_bridge(bridge)) {
connector_type = bridge->type;
+ subconnector = bridge->subtype;
+ }
#ifdef CONFIG_OF
if (!drm_bridge_get_next_bridge(bridge) &&
@@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (panel_bridge)
drm_panel_bridge_set_orientation(connector, panel_bridge);
+ if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ drm_connector_attach_dp_subconnector_property(connector,
subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
+ ret = drm_mode_create_dvi_i_properties(drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ drm_object_attach_property(>base,
+
drm->mode_config.dvi_i_subconnector_property,
+subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
+ ret = drm_mode_create_tv_properties(drm,
+ BIT(DRM_MODE_TV_MODE_NTSC) |
+
BIT(DRM_MODE_TV_MODE_NTSC_443) |
+ BIT(DRM_MODE_TV_MODE_NTSC_J) |
+ BIT(DRM_MODE_TV_MODE_PAL) |
+ BIT(DRM_MODE_TV_MODE_PAL_M) |
+ BIT(DRM_MODE_TV_MODE_PAL_N) |
+ BIT(DRM_MODE_TV_MODE_SECAM));
+ if (ret)
+ return ERR_PTR(ret);
I don't think this is right, this should be called from the appropriate encoder
device depending on the analog tv mode capabilities.
Good question. My logic was the following: the DRM device can have
different TV out ports with different capabilities (yeah, pure
theoretical construct). In this case it might be impossible to create
a single subset of values. Thus it is more correct to create the
property listing all possible values. The property is immutable anyway
(and so the user doesn't have control over the value).
Those ports would correspond to different connectors, so I agree with
Neil, I don't think it's right to create a single property with all
modes and attach it to all analog output connectors.
I agree that this case is mishandled currently (as current design
assumes a single property that fits for the complete device).
If you want to support multiple analog outputs that have different
capabilities, this will need changes to drm_mode_create_tv_properties()
to allow creating multiple properties. If you don't want to do so now,
and prefer limiting support to devices where all ports support the same
modes (which includes devices with a single analog output), then the
modes should reflect what the device supports.
Ack, I'll drop the create call and check for the property existence
before attaching it.
+
+ drm_object_attach_property(>base,
+
drm->mode_config.tv_subconnector_property,
+subconnector);
Here, only add the property if drm->mode_config.tv_subconnector_property exists,
and perhaps add a warning if not.
This property is created in the previ
Re: [PATCH 3/4] drm/uapi: document the USB subconnector type
On 02/08/2023 21:55, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
To properly define the USB-C DP altmode connectors, add the USB
subconnector type.
Suggested-by: Simon Ser
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a6066e4a5e9a..9e96b038f5d0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
{ DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
+ { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
another USB type later ?
Hmm, which id should I use for micro-USB then? (consider anx7808,
SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of
them. But maybe I should add another subtype for SlimPort.
};
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 92d96a2b6763..0f74918b011c 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -398,6 +398,7 @@ enum drm_mode_subconnector {
DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
+ DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
};
#define DRM_MODE_CONNECTOR_Unknown 0
--
With best wishes
Dmitry
Re: [PATCH 2/4] drm/bridge-connector: handle subconnector types
On Wed, 2 Aug 2023 at 11:35, Neil Armstrong wrote:
>
> On 29/07/2023 02:49, Dmitry Baryshkov wrote:
> > If the created connector type supports subconnector type property,
> > create and attach corresponding it. The default subtype value is 0,
> > which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/drm_bridge_connector.c | 33 +-
> > include/drm/drm_bridge.h | 4
> > 2 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> > b/drivers/gpu/drm/drm_bridge_connector.c
> > index 07b5930b1282..a7b92f0d2430 100644
> > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > @@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > struct drm_connector *connector;
> > struct i2c_adapter *ddc = NULL;
> > struct drm_bridge *bridge, *panel_bridge = NULL;
> > + enum drm_mode_subconnector subconnector;
> > int connector_type;
> > + int ret;
> >
> > bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
> > if (!bridge_connector)
> > @@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > if (bridge->ops & DRM_BRIDGE_OP_MODES)
> > bridge_connector->bridge_modes = bridge;
> >
> > - if (!drm_bridge_get_next_bridge(bridge))
> > + if (!drm_bridge_get_next_bridge(bridge)) {
> > connector_type = bridge->type;
> > + subconnector = bridge->subtype;
> > + }
> >
> > #ifdef CONFIG_OF
> > if (!drm_bridge_get_next_bridge(bridge) &&
> > @@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > if (panel_bridge)
> > drm_panel_bridge_set_orientation(connector, panel_bridge);
> >
> > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> > + drm_connector_attach_dp_subconnector_property(connector,
> > subconnector);
> > + } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
> > + ret = drm_mode_create_dvi_i_properties(drm);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + drm_object_attach_property(>base,
> > +
> > drm->mode_config.dvi_i_subconnector_property,
> > +subconnector);
> > + } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
> > + ret = drm_mode_create_tv_properties(drm,
> > +
> > BIT(DRM_MODE_TV_MODE_NTSC) |
> > +
> > BIT(DRM_MODE_TV_MODE_NTSC_443) |
> > +
> > BIT(DRM_MODE_TV_MODE_NTSC_J) |
> > + BIT(DRM_MODE_TV_MODE_PAL)
> > |
> > +
> > BIT(DRM_MODE_TV_MODE_PAL_M) |
> > +
> > BIT(DRM_MODE_TV_MODE_PAL_N) |
> > +
> > BIT(DRM_MODE_TV_MODE_SECAM));
> > + if (ret)
> > + return ERR_PTR(ret);
>
> I don't think this is right, this should be called from the appropriate
> encoder
> device depending on the analog tv mode capabilities.
Good question. My logic was the following: the DRM device can have
different TV out ports with different capabilities (yeah, pure
theoretical construct). In this case it might be impossible to create
a single subset of values. Thus it is more correct to create the
property listing all possible values. The property is immutable anyway
(and so the user doesn't have control over the value).
> > +
> > + drm_object_attach_property(>base,
> > +
> > drm->mode_config.tv_subconnector_property,
> > +subconnector);
>
> Here, only add the property if drm->mode_config.tv_subconnector_property
> exists,
> and perhaps add a warning if not.
This property is created in the previous call,
drm_mode_create_tv_properties() ->
drm_mode_create_tv_properties_legacy().
>
> AFAI
[PATCH 1/4] drm: allow specifying default subtype for the DP subconnector property
In the embedded usecases the default subtype depends on the bridge
chain, so it is easier to specify the subtype at the proprety attachment
type rather than specifying it later.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 3 ++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 ++-
drivers/gpu/drm/drm_connector.c | 6 --
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
include/drm/drm_connector.h | 3 ++-
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index d34037b85cf8..c18459ecd4be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -2022,7 +2022,8 @@ amdgpu_connector_add(struct amdgpu_device *adev,
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
-
drm_connector_attach_dp_subconnector_property(_connector->base);
+
drm_connector_attach_dp_subconnector_property(_connector->base,
+
DRM_MODE_SUBCONNECTOR_Unknown);
}
return;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 943959012d04..297321f0199e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -759,7 +759,8 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_mst_topology_mgr_init(>mst_mgr,
adev_to_drm(dm->adev),
>dm_dp_aux.aux, 16, 4,
aconnector->connector_id);
- drm_connector_attach_dp_subconnector_property(>base);
+ drm_connector_attach_dp_subconnector_property(>base,
+
DRM_MODE_SUBCONNECTOR_Unknown);
}
int dm_mst_get_pbn_divider(struct dc_link *link)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a3d3e7dc08b2..a6066e4a5e9a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1577,10 +1577,12 @@ EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
/**
* drm_connector_attach_dp_subconnector_property - create subconnector
property for DP
* @connector: drm_connector to attach property
+ * @subtype: initial value for the subconnector type
*
* Called by a driver when DP connector is created.
*/
-void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector)
+void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector,
+ enum drm_mode_subconnector
subtype)
{
struct drm_mode_config *mode_config = >dev->mode_config;
@@ -1594,7 +1596,7 @@ void drm_connector_attach_dp_subconnector_property(struct
drm_connector *connect
drm_object_attach_property(>base,
mode_config->dp_subconnector_property,
- DRM_MODE_SUBCONNECTOR_Unknown);
+ subtype);
}
EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 474785110662..5819105187f6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5391,7 +5391,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
enum port port = dp_to_dig_port(intel_dp)->base.port;
if (!intel_dp_is_edp(intel_dp))
- drm_connector_attach_dp_subconnector_property(connector);
+ drm_connector_attach_dp_subconnector_property(connector,
+
DRM_MODE_SUBCONNECTOR_Unknown);
if (!IS_G4X(dev_priv) && port != PORT_A)
intel_attach_force_audio_property(connector);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5a8115dca359..a130a78f6e0f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1990,7 +1990,8 @@ const char *drm_get_hdcp_content_type_name(int val);
int drm_get_tv_mode_from_name(const char *name, size_t len);
int drm_mode_create_dvi_i_properties(struct drm_device *dev);
-void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector);
+void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector,
+ enum drm_mode_subconnector
subtype);
int drm_mode_create_tv_margin_properties(struct drm_device *dev);
[PATCH 2/4] drm/bridge-connector: handle subconnector types
If the created connector type supports subconnector type property,
create and attach corresponding it. The default subtype value is 0,
which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 33 +-
include/drm/drm_bridge.h | 4
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 07b5930b1282..a7b92f0d2430 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+ enum drm_mode_subconnector subconnector;
int connector_type;
+ int ret;
bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
if (!bridge_connector)
@@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
- if (!drm_bridge_get_next_bridge(bridge))
+ if (!drm_bridge_get_next_bridge(bridge)) {
connector_type = bridge->type;
+ subconnector = bridge->subtype;
+ }
#ifdef CONFIG_OF
if (!drm_bridge_get_next_bridge(bridge) &&
@@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (panel_bridge)
drm_panel_bridge_set_orientation(connector, panel_bridge);
+ if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ drm_connector_attach_dp_subconnector_property(connector,
subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
+ ret = drm_mode_create_dvi_i_properties(drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ drm_object_attach_property(>base,
+
drm->mode_config.dvi_i_subconnector_property,
+ subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
+ ret = drm_mode_create_tv_properties(drm,
+ BIT(DRM_MODE_TV_MODE_NTSC) |
+
BIT(DRM_MODE_TV_MODE_NTSC_443) |
+
BIT(DRM_MODE_TV_MODE_NTSC_J) |
+ BIT(DRM_MODE_TV_MODE_PAL) |
+ BIT(DRM_MODE_TV_MODE_PAL_M)
|
+ BIT(DRM_MODE_TV_MODE_PAL_N)
|
+
BIT(DRM_MODE_TV_MODE_SECAM));
+ if (ret)
+ return ERR_PTR(ret);
+
+ drm_object_attach_property(>base,
+
drm->mode_config.tv_subconnector_property,
+ subconnector);
+ }
+
return connector;
}
EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index bf964cdfb330..68b14ac5ac0d 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -739,6 +739,10 @@ struct drm_bridge {
* identifies the type of connected display.
*/
int type;
+ /**
+* @subtype: the subtype of the connector for the DP/TV/DVI-I cases.
+*/
+ enum drm_mode_subconnector subtype;
/**
* @interlace_allowed: Indicate that the bridge can handle interlaced
* modes.
--
2.39.2
[PATCH 0/4] drm/bridge-connector: simplify handling of USB-C DP
During the discussion of DP connetors, it was pointed out that existing DP drivers supporting USB-C altmode (AMDGPU, Intel) use DRM_MODE_CONNECTOR_DisplayPort for such connectors rather than DRM_MODE_CONNECTOR_USB. This patchset attempts to solve this issue. It adds USB to the enum drm_dp_subconnector and then provides a simple yet efficient way to define DP-in-USB subconnector type for the drivers that use drm_bridge_connector. Dmitry Baryshkov (4): drm: allow specifying default subtype for the DP subconnector property drm/bridge-connector: handle subconnector types drm/uapi: document the USB subconnector type soc: qcom: pmic_glink: properly describe the DP connector .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 3 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 +- drivers/gpu/drm/drm_bridge_connector.c| 33 ++- drivers/gpu/drm/drm_connector.c | 7 ++-- drivers/gpu/drm/i915/display/intel_dp.c | 3 +- drivers/soc/qcom/pmic_glink_altmode.c | 3 +- include/drm/drm_bridge.h | 4 +++ include/drm/drm_connector.h | 3 +- include/uapi/drm/drm_mode.h | 1 + 9 files changed, 52 insertions(+), 8 deletions(-) -- 2.39.2
[PATCH 3/4] drm/uapi: document the USB subconnector type
To properly define the USB-C DP altmode connectors, add the USB
subconnector type.
Suggested-by: Simon Ser
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a6066e4a5e9a..9e96b038f5d0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
{ DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
+ { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
};
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 92d96a2b6763..0f74918b011c 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -398,6 +398,7 @@ enum drm_mode_subconnector {
DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
+ DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
};
#define DRM_MODE_CONNECTOR_Unknown 0
--
2.39.2
[PATCH 4/4] soc: qcom: pmic_glink: properly describe the DP connector
During the discussion of the DP connectors, it was suggested that USB-C DisplayPort connectors should have DRM_MODE_CONNECTOR_DisplayPort connector type. This follows the example provided by other drivers (AMDGPU, Intel). To distinguish them from native DP ports, they should have the freshly defined USB as a subconnector type. Suggested-by: Simon Ser Cc: Neil Armstrong Signed-off-by: Dmitry Baryshkov --- drivers/soc/qcom/pmic_glink_altmode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c index 1dedacc52aea..9094944c6cc0 100644 --- a/drivers/soc/qcom/pmic_glink_altmode.c +++ b/drivers/soc/qcom/pmic_glink_altmode.c @@ -417,7 +417,8 @@ static int pmic_glink_altmode_probe(struct auxiliary_device *adev, alt_port->bridge.funcs = _glink_altmode_bridge_funcs; alt_port->bridge.of_node = to_of_node(fwnode); alt_port->bridge.ops = DRM_BRIDGE_OP_HPD; - alt_port->bridge.type = DRM_MODE_CONNECTOR_USB; + alt_port->bridge.type = DRM_MODE_CONNECTOR_DisplayPort; + alt_port->bridge.subtype = DRM_MODE_SUBCONNECTOR_USB; ret = devm_drm_bridge_add(dev, _port->bridge); if (ret) -- 2.39.2
Re: [PATCH] drm/client: Send hotplug event after registering a client
On 11/07/2023 09:07, Thomas Zimmermann wrote: Hi Am 10.07.23 um 23:11 schrieb Dmitry Baryshkov: [...] --- drivers/gpu/drm/armada/armada_fbdev.c | 4 drivers/gpu/drm/drm_client.c | 21 + drivers/gpu/drm/drm_fbdev_dma.c | 4 drivers/gpu/drm/drm_fbdev_generic.c | 4 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 drivers/gpu/drm/gma500/fbdev.c | 4 drivers/gpu/drm/msm/msm_fbdev.c | 4 Reviewed-by: Dmitry Baryshkov # msm Thanks. drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 drivers/gpu/drm/radeon/radeon_fbdev.c | 4 drivers/gpu/drm/tegra/fbdev.c | 4 10 files changed, 21 insertions(+), 36 deletions(-) BTW: As you have been clearing this area. I see that significant amount of DRM drivers use exactly the same code for msm_fbdev_client_funcs and for the significant part of foo_fbdev_setup(). Do you have any plans for moving that into a library / generic code? If not, I can take a look at crafting the patch. You're not the first to ask. :) I've so far not attempted to address this duplication. I've been bitten by premature helperization before, so I wanted to wait a bit longer. A lot of the fbdev and client code is changing quite a bit. After things stabilized, I want to to try to do some more code sharing. Ack, thank you for sharing this. -- With best wishes Dmitry
Re: [PATCH] drm/client: Send hotplug event after registering a client
On 10/07/2023 12:10, Thomas Zimmermann wrote:
Generate a hotplug event after registering a client to allow the
client to configure its display. Remove the hotplug calls from the
existing clients for fbdev emulation. This change fixes a concurrency
bug between registering a client and receiving events from the DRM
core. The bug is present in the fbdev emulation of all drivers.
The fbdev emulation currently generates a hotplug event before
registering the client to the device. For each new output, the DRM
core sends an additional hotplug event to each registered client.
If the DRM core detects first output between sending the artificial
hotplug and registering the device, the output's hotplug event gets
lost. If this is the first output, the fbdev console display remains
dark. This has been observed with amdgpu and fbdev-generic.
Fix this by adding hotplug generation directly to the client's
register helper drm_client_register(). Registering the client and
receiving events are serialized by struct drm_device.clientlist_mutex.
So an output is either configured by the initial hotplug event, or
the client has already been registered.
The bug was originally added in commit 6e3f17ee73f7 ("drm/fb-helper:
generic: Call drm_client_add() after setup is done"), in which adding
a client and receiving a hotplug event switched order. It was hidden,
as most hardware and drivers have at least on static output configured.
Other drivers didn't use the internal DRM client or still had struct
drm_mode_config_funcs.output_poll_changed set. That callback handled
hotplug events as well. After not setting the callback in amdgpu in
commit 0e3172bac3f4 ("drm/amdgpu: Don't set struct
drm_driver.output_poll_changed"), amdgpu did not show a framebuffer
console if output events got lost. The bug got copy-pasted from
fbdev-generic into the other fbdev emulation.
Reported-by: Moritz Duge
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2649
Fixes: 6e3f17ee73f7 ("drm/fb-helper: generic: Call drm_client_add() after setup is
done")
Fixes: 8ab59da26bc0 ("drm/fb-helper: Move generic fbdev emulation into separate
source file")
Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA
helpers")
Fixes: 63c381552f69 ("drm/armada: Implement fbdev emulation as in-kernel
client")
Fixes: 49953b70e7d3 ("drm/exynos: Implement fbdev emulation as in-kernel
client")
Fixes: 8f1aaccb04b7 ("drm/gma500: Implement client-based fbdev emulation")
Fixes: 940b869c2f2f ("drm/msm: Implement fbdev emulation as in-kernel client")
Fixes: 9e69bcd88e45 ("drm/omapdrm: Implement fbdev emulation as in-kernel
client")
Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation")
Fixes: 71ec16f45ef8 ("drm/tegra: Implement fbdev emulation as in-kernel client")
Signed-off-by: Thomas Zimmermann
Tested-by: Moritz Duge
Tested-by: Torsten Krah
Tested-by: Paul Schyska
Cc: Daniel Vetter
Cc: David Airlie
Cc: Noralf Trønnes
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Javier Martinez Canillas
Cc: Russell King
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Patrik Jakobsson
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Tomi Valkeinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: Thierry Reding
Cc: Mikko Perttunen
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: # v5.2+
---
drivers/gpu/drm/armada/armada_fbdev.c | 4
drivers/gpu/drm/drm_client.c | 21 +
drivers/gpu/drm/drm_fbdev_dma.c | 4
drivers/gpu/drm/drm_fbdev_generic.c | 4
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4
drivers/gpu/drm/gma500/fbdev.c| 4
drivers/gpu/drm/msm/msm_fbdev.c | 4
Reviewed-by: Dmitry Baryshkov # msm
drivers/gpu/drm/omapdrm/omap_fbdev.c | 4
drivers/gpu/drm/radeon/radeon_fbdev.c | 4
drivers/gpu/drm/tegra/fbdev.c | 4
10 files changed, 21 insertions(+), 36 deletions(-)
BTW: As you have been clearing this area. I see that significant amount
of DRM drivers use exactly the same code for msm_fbdev_client_funcs and
for the significant part of foo_fbdev_setup(). Do you have any plans for
moving that into a library / generic code? If not, I can take a look at
crafting the patch.
--
With best wishes
Dmitry
Re: [PATCH 00/36] drm/amd/display: add AMD driver-specific properties for color mgmt
On 24/05/2023 01:14, Melissa Wen wrote: This series is a refined version of our RFC [1] for AMD driver-specific color management properties. It is a collection of contributions from Joshua, Harry and I to enhance AMD KMS color pipeline for Steam Deck/SteamOS by exposing the large set of color caps available in AMD display HW. Considering RFC feedback, this patchset differs from the previous one by removing the KConfig option and just guarding driver-specific properties with `AMD_PRIVATE_COLOR` - but we also removed the guards from internal elements and operations. We stopped to advertise CRTC shaper and 3D LUTs properties since they aren't in use in the Steam Deck color pipeline[2]. On the other hand, we keep mapping CRTC shaper and 3D LUTs (DM) to DC MPC setup. We also improved curve calculations to take into account HW color caps. In short, for pre-blending, we added the following properties: - plane degamma LUT and predefined transfer function; - plane HDR multiplier - plane shaper LUT/transfer function; - plane 3D LUT; and finally, - plane blend LUT/transfer function, just before blending. This set of properties sounds interesting and not fully AMD-specific. Could you please consider moving them to the more generic location? For the reference, MSM (Qualcomm) display hardware supports degamma/gamma LUTs for planes too. One of the suggested usecases for these degamma/gamma units is to support colorspace transfer functions. Thus, at least some of these properties can be implemented in drm/msm driver too. After blending, we already have DRM CRTC degamma/gamma LUTs and CTM, therefore, we extend post-blending color pipeline with CRTC gamma transfer function. The first three patches are on DRM KMS side. We expose DRM property helper for blob lookup and replacement so that we can use it for managing driver-specific properties. We add a tracked for plane color mgmt changes and increase the maximum number of properties to accommodate this expansion. The userspace case here is Gamescope which is the compositor for SteamOS. It's already using all of this functionality to implement its color management pipeline right now [3]. Current IGT tests kms_color and amdgpu/amd_color on DCN301 and DCN21 HW preserve the same results with and without the guard. Finally, I may have missed something, please let me know if that's the case. Best Regards, Melissa Wen [1] https://lore.kernel.org/dri-devel/20230423141051.702990-1-m...@igalia.com [2] https://github.com/ValveSoftware/gamescope/blob/master/src/docs/Steam%20Deck%20Display%20Pipeline.png [3] https://github.com/ValveSoftware/gamescope Harry Wentland (2): drm/amd/display: fix segment distribution for linear LUTs drm/amd/display: fix the delta clamping for shaper LUT Joshua Ashton (13): drm/amd/display: add plane degamma TF driver-specific property drm/amd/display: add plane HDR multiplier driver-specific property drm/amd/display: add plane blend LUT and TF driver-specific properties drm/amd/display: copy 3D LUT settings from crtc state to stream_update drm/amd/display: dynamically acquire 3DLUT resources for color changes drm/amd/display: add CRTC regamma TF support drm/amd/display: set sdr_ref_white_level to 80 for out_transfer_func drm/amd/display: add support for plane degamma TF and LUT properties drm/amd/display: add dc_fixpt_from_s3132 helper drm/adm/display: add HDR multiplier support drm/amd/display: handle empty LUTs in __set_input_tf drm/amd/display: add DRM plane blend LUT and TF support drm/amd/display: allow newer DC hardware to use degamma ROM for PQ/HLG Melissa Wen (21): drm/drm_mode_object: increase max objects to accommodate new color props drm/drm_property: make replace_property_blob_from_id a DRM helper drm/drm_plane: track color mgmt changes per plane drm/amd/display: add CRTC driver-specific property for gamma TF drm/amd/display: add plane driver-specific properties for degamma LUT drm/amd/display: add plane 3D LUT driver-specific properties drm/amd/display: add plane shaper LUT driver-specific properties drm/amd/display: add plane shaper TF driver-private property drm/amd/display: add comments to describe DM crtc color mgmt behavior drm/amd/display: encapsulate atomic regamma operation drm/amd/display: update lut3d and shaper lut to stream drm/amd/display: allow BYPASS 3D LUT but keep shaper LUT settings drm/amd/display: handle MPC 3D LUT resources for a given context drm/amd/display: add CRTC 3D LUT support drm/amd/display: add CRTC shaper LUT support drm/amd/display: add CRTC shaper TF support drm/amd/display: mark plane as needing reset if plane color mgmt changes drm/amd/display: decouple steps for mapping CRTC degamma to DC plane drm/amd/display: reject atomic commit if setting both plane and CRTC degamma drm/amd/display: program DPP shaper and 3D LUT if updated drm/amd/display: add plane
Re: [Freedreno] [PATCH v3 11/12] drm/fbdev-generic: Implement dedicated fbdev I/O helpers
On Mon, 22 May 2023 at 15:22, Thomas Zimmermann wrote:
>
> Implement dedicated fbdev helpers for framebuffer I/O instead
> of using DRM's helpers. Fbdev-generic was the only caller of the
> DRM helpers, so remove them from the helper module.
>
> v2:
> * use FB_SYS_HELPERS_DEFERRED option
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/Kconfig | 6 +-
> drivers/gpu/drm/drm_fb_helper.c | 107
> drivers/gpu/drm/drm_fbdev_generic.c | 47 ++--
> include/drm/drm_fb_helper.h | 41 ---
> 4 files changed, 43 insertions(+), 158 deletions(-)
Looking at this patch makes me wonder if we should have implemented
fb_dirty for the MSM driver. We have drm_framebuffer_funcs::dirty()
implemented (by wrapping the drm_atomic_helper_dirtyfb()).
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 77fb10ddd8a2..92a782827b7b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
> config DRM_KMS_HELPER
> tristate
> depends on DRM
> + select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION
> help
> CRTC helpers for KMS drivers.
>
> @@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> - select FB_DEFERRED_IO
> - select FB_SYS_FOPS
> - select FB_SYS_FILLRECT
> - select FB_SYS_COPYAREA
> - select FB_SYS_IMAGEBLIT
> select FRAMEBUFFER_CONSOLE if !EXPERT
> select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
> default y
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 8724e08c518b..ba0a808f14ee 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -729,113 +729,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info,
> struct list_head *pagerefli
> }
> EXPORT_SYMBOL(drm_fb_helper_deferred_io);
>
> -/**
> - * drm_fb_helper_sys_read - Implements struct _ops.fb_read for system
> memory
> - * @info: fb_info struct pointer
> - * @buf: userspace buffer to read from framebuffer memory
> - * @count: number of bytes to read from framebuffer memory
> - * @ppos: read offset within framebuffer memory
> - *
> - * Returns:
> - * The number of bytes read on success, or an error code otherwise.
> - */
> -ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
> - size_t count, loff_t *ppos)
> -{
> - return fb_sys_read(info, buf, count, ppos);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_sys_read);
> -
> -/**
> - * drm_fb_helper_sys_write - Implements struct _ops.fb_write for system
> memory
> - * @info: fb_info struct pointer
> - * @buf: userspace buffer to write to framebuffer memory
> - * @count: number of bytes to write to framebuffer memory
> - * @ppos: write offset within framebuffer memory
> - *
> - * Returns:
> - * The number of bytes written on success, or an error code otherwise.
> - */
> -ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
> - size_t count, loff_t *ppos)
> -{
> - struct drm_fb_helper *helper = info->par;
> - loff_t pos = *ppos;
> - ssize_t ret;
> - struct drm_rect damage_area;
> -
> - ret = fb_sys_write(info, buf, count, ppos);
> - if (ret <= 0)
> - return ret;
> -
> - if (helper->funcs->fb_dirty) {
> - drm_fb_helper_memory_range_to_clip(info, pos, ret,
> _area);
> - drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
> -drm_rect_width(_area),
> -drm_rect_height(_area));
> - }
> -
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_fb_helper_sys_write);
> -
> -/**
> - * drm_fb_helper_sys_fillrect - wrapper around sys_fillrect
> - * @info: fbdev registered by the helper
> - * @rect: info about rectangle to fill
> - *
> - * A wrapper around sys_fillrect implemented by fbdev core
> - */
> -void drm_fb_helper_sys_fillrect(struct fb_info *info,
> - const struct fb_fillrect *rect)
> -{
> - struct drm_fb_helper *helper = info->par;
> -
> - sys_fillrect(info, rect);
> -
> - if (helper->funcs->fb_dirty)
> - drm_fb_helper_damage(helper, rect->dx, rect->dy, rect->width,
> rect->height);
> -}
> -EXPORT_SYMBOL(drm_fb_helper_sys_fillrect);
> -
> -/**
> - * drm_fb_helper_sys_copyarea - wrapper around sys_copyarea
> - * @info: fbdev registered by the helper
> - * @area: info about area to copy
> - *
> - * A wrapper around sys_copyarea implemented by fbdev core
> - */
> -void drm_fb_helper_sys_copyarea(struct fb_info *info,
> - const struct fb_copyarea *area)
> -{
> - struct drm_fb_helper *helper = info->par;
> -
> -
Re: [PATCH v4 0/9] drm: fdinfo memory stats
On 15/05/2023 17:30, Rob Clark wrote: From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start. Basic gputop support: https://patchwork.freedesktop.org/series/116236/ And already nvtop support: https://github.com/Syllo/nvtop/pull/204 I've combined the separate series to add comm/cmdline override onto the end of this, simply out of convenience (they would otherwise conflict in a bunch of places). v2: Extend things to allow for multiple regions other than just system "memory", make drm_show_memory_stats() a helper so that, drivers can use it or not based on their needs (but in either case, re- use drm_print_memory_stats() v3: Docs fixes v4: use u64 for drm_memory_stats, small docs update and collected Tvrtko's a-b [1] https://patchwork.freedesktop.org/series/112397/ Rob Clark (9): drm/docs: Fix usage stats typos drm: Add common fdinfo helper drm/msm: Switch to fdinfo helper drm/amdgpu: Switch to fdinfo helper drm: Add fdinfo memory stats drm/msm: Add memory stats to fdinfo drm/doc: Relax fdinfo string constraints drm/fdinfo: Add comm/cmdline override fields drm/msm: Wire up comm/cmdline override for fdinfo Documentation/gpu/drm-usage-stats.rst | 101 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- drivers/gpu/drm/drm_file.c | 147 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 24 +++- drivers/gpu/drm/msm/msm_drv.c | 15 ++- drivers/gpu/drm/msm/msm_gem.c | 15 +++ drivers/gpu/drm/msm/msm_gpu.c | 2 - drivers/gpu/drm/msm/msm_gpu.h | 10 ++ include/drm/drm_drv.h | 7 + include/drm/drm_file.h | 51 +++ include/drm/drm_gem.h | 32 + 13 files changed, 378 insertions(+), 47 deletions(-) What is the expected merge plan for this series? msm-next? drm-misc? -- With best wishes Dmitry
Re: [PATCH 06/11] drm/msm: Use regular fbdev I/O helpers
On Fri, 12 May 2023 at 11:41, Thomas Zimmermann wrote: > > Use the regular fbdev helpers for framebuffer I/O instead of DRM's > helpers. Msm does not use damage handling, so DRM's fbdev helpers > are mere wrappers around the fbdev code. > > Add CONFIG_DRM_MSM_FBDEV_EMULATION to select the necessary > Kconfig options automatically. Make fbdev emulation depend on > the new config option. > > By using fbdev helpers directly within each DRM fbdev emulation, > we can eventually remove DRM's wrapper functions entirely. > > Signed-off-by: Thomas Zimmermann > Cc: Rob Clark > Cc: Abhinav Kumar > Cc: Dmitry Baryshkov > Cc: Sean Paul > --- > drivers/gpu/drm/msm/Kconfig | 9 + > drivers/gpu/drm/msm/Makefile| 2 +- > drivers/gpu/drm/msm/msm_drv.h | 2 +- > drivers/gpu/drm/msm/msm_fbdev.c | 12 +++- > 4 files changed, 18 insertions(+), 7 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 2/2] drm/probe_helper: warning on poll_enabled for issue catching
On 09/03/2023 07:48, Guchun Chen wrote:
In order to catch issues in other drivers to ensure proper call
sequence of polling function.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
Fixes: a4e771729a51("drm/probe_helper: sort out poll_running vs poll_enabled")
Previously it was suggested that this is not a fix, so the Fixes header
is incorrect.
Also please use -vN when preparing/sending patchsets. This is v2.
Reported-by: Bert Karwatzki
Suggested-by: Dmitry Baryshkov
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/drm_probe_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 8127be134c39..85e0e80d4a52 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -852,6 +852,8 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
*/
void drm_kms_helper_poll_disable(struct drm_device *dev)
{
+ WARN_ON(!dev->mode_config.poll_enabled);
+
if (dev->mode_config.poll_running)
drm_kms_helper_disable_hpd(dev);
--
With best wishes
Dmitry
Re: [PATCH 00/22] drm: Review of mode copies
On 22/03/2022 01:37, Ville Syrjälä wrote: On Tue, Mar 15, 2022 at 02:52:38PM -0400, Alex Deucher wrote: On Mon, Mar 14, 2022 at 6:12 PM Ville Syrjälä wrote: On Fri, Feb 18, 2022 at 12:03:41PM +0200, Ville Syrjala wrote: drm: Add drm_mode_init() drm/bridge: Use drm_mode_copy() drm/imx: Use drm_mode_duplicate() drm/panel: Use drm_mode_duplicate() drm/vc4: Use drm_mode_copy() These have been pushed to drm-misc-next. drm/amdgpu: Remove pointless on stack mode copies drm/amdgpu: Use drm_mode_init() for on-stack modes drm/amdgpu: Use drm_mode_copy() amdgpu ones are reviewed, but I'll leave them for the AMD folks to push to whichever tree they prefer. I pulled patches 2, 4, 5 into my tree. Thanks. For 3, I'm happy to have it land via drm-misc with the rest of the mode_init changes if you'd prefer. Either way works for me. I don't yet have reviews yet for the other drivers, so I'll proably hold off for a bit more at least. And the i915 patch I'll be merging via drm-intel. drm/radeon: Use drm_mode_copy() drm/gma500: Use drm_mode_copy() drm/tilcdc: Use drm_mode_copy() drm/i915: Use drm_mode_copy() Those are now all in. Which leaves us with these stragglers: drm/hisilicon: Use drm_mode_init() for on-stack modes drm/msm: Nuke weird on stack mode copy drm/msm: Use drm_mode_init() for on-stack modes drm/msm: Use drm_mode_copy() These three patches went beneath my radar for some reason. I have just sent a replacement for the first patch ([1]). Other two patches can be pulled in msm/msm-next (or msm/msm-fixes) during the next development cycle if that works for you. [1] https://patchwork.freedesktop.org/series/101682/ drm/mtk: Use drm_mode_init() for on-stack modes drm/rockchip: Use drm_mode_copy() drm/sti: Use drm_mode_copy() drm: Use drm_mode_init() for on-stack modes drm: Use drm_mode_copy() -- With best wishes Dmitry
Re: [PATCH v2 07/13] drm/msm: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
On 16/10/2021 21:42, Claudio Suarez wrote:
Once EDID is parsed, the monitor HDMI support information is available
through drm_display_info.is_hdmi. Retriving the same information with
drm_detect_hdmi_monitor() is less efficient. Change to
drm_display_info.is_hdmi
Signed-off-by: Claudio Suarez
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index 58707a1f3878..07585092f919 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -364,8 +364,8 @@ static int msm_hdmi_connector_get_modes(struct
drm_connector *connector)
hdmi_write(hdmi, REG_HDMI_CTRL, hdmi_ctrl);
- hdmi->hdmi_mode = drm_detect_hdmi_monitor(edid);
drm_connector_update_edid_property(connector, edid);
+ hdmi->hdmi_mode = connector->display_info.is_hdmi;
if (edid) {
ret = drm_add_edid_modes(connector, edid);
--
With best wishes
Dmitry
Re: [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
On 29/06/2021 16:58, Thomas Zimmermann wrote:
Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
change.
Signed-off-by: Thomas Zimmermann
---
[...]
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
Reviewed-by: Dmitry Baryshkov
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/drm_aperture.h| 14 +-
23 files changed, 43 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f30c525caac..accf9c1b967a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1278,7 +1278,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
#endif
/* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
"amdgpudrmfb");
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_kms_driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
index dab0a1f0983b..31925ae3ab72 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev)
}
/* Remove early framebuffers */
- ret = drm_aperture_remove_framebuffers(false, "armada-drm-fb");
+ ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5aa452b4efe6..86d5cd7b6318 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -100,7 +100,7 @@ static int ast_remove_conflicting_framebuffers(struct
pci_dev *pdev)
primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
#endif
- return drm_aperture_remove_conflicting_framebuffers(base, size, primary, "astdrmfb");
+ return drm_aperture_remove_conflicting_framebuffers(base, size, primary,
_driver);
}
static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index c828cadbabff..0d232b44ecd7 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -110,7 +110,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "bochsdrmfb");
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 9335d9d6cf9a..9ac39cf11694 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -33,6 +33,10 @@
*
* .. code-block:: c
*
+ * static const struct drm_driver example_driver = {
+ * ...
+ * };
+ *
*static int remove_conflicting_framebuffers(struct pci_dev *pdev)
*{
*bool primary = false;
@@ -46,7 +50,7 @@
*#endif
*
*return drm_aperture_remove_conflicting_framebuffers(base, size,
primary,
- * "example
driver");
+ *
_driver);
*}
*
*static int probe(struct pci_dev *pdev)
@@ -274,7 +278,7 @@ static void drm_aperture_detach_drivers(resource_size_t
base, resource_size_t si
* @base: the aperture's base address in physical memory
* @size: aperture size in bytes
* @primary: also kick vga16fb if present
- * @name: requesting driver name
+ * @req_driver: requesting DRM driver
*
* This function removes graphics device drivers which use memory range
described by
* @base and @size.
@@ -283,7 +287,7 @@ static void drm_aperture_detach_drivers(resource_size_t
base, resource_size_t si
* 0 on success, or a negative errno code otherwise
*/
int drm_apertur
Re: [PATCH v2 07/14] drm/msm: Convert to Linux IRQ interfaces
On 03/08/2021 12:06, Thomas Zimmermann wrote:
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
DRM IRQ callbacks are now being called directly or inlined.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Dmitry Baryshkov
Rob should probably also give his blessing on this patch though.
---
drivers/gpu/drm/msm/msm_drv.c | 113 --
drivers/gpu/drm/msm/msm_kms.h | 2 +-
2 files changed, 69 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 1594ae39d54f..a332b09a5a11 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -201,6 +200,71 @@ void msm_rmw(void __iomem *addr, u32 mask, u32 or)
msm_writel(val | or, addr);
}
+static irqreturn_t msm_irq(int irq, void *arg)
+{
+ struct drm_device *dev = arg;
+ struct msm_drm_private *priv = dev->dev_private;
+ struct msm_kms *kms = priv->kms;
+
+ BUG_ON(!kms);
+
+ return kms->funcs->irq(kms);
+}
+
+static void msm_irq_preinstall(struct drm_device *dev)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ struct msm_kms *kms = priv->kms;
+
+ BUG_ON(!kms);
+
+ kms->funcs->irq_preinstall(kms);
+}
+
+static int msm_irq_postinstall(struct drm_device *dev)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ struct msm_kms *kms = priv->kms;
+
+ BUG_ON(!kms);
+
+ if (kms->funcs->irq_postinstall)
+ return kms->funcs->irq_postinstall(kms);
+
+ return 0;
+}
+
+static int msm_irq_install(struct drm_device *dev, unsigned int irq)
+{
+ int ret;
+
+ if (irq == IRQ_NOTCONNECTED)
+ return -ENOTCONN;
+
+ msm_irq_preinstall(dev);
+
+ ret = request_irq(irq, msm_irq, 0, dev->driver->name, dev);
+ if (ret)
+ return ret;
+
+ ret = msm_irq_postinstall(dev);
+ if (ret) {
+ free_irq(irq, dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void msm_irq_uninstall(struct drm_device *dev)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ struct msm_kms *kms = priv->kms;
+
+ kms->funcs->irq_uninstall(kms);
+ free_irq(kms->irq, dev);
+}
+
struct msm_vblank_work {
struct work_struct work;
int crtc_id;
@@ -265,7 +329,7 @@ static int msm_drm_uninit(struct device *dev)
}
/* We must cancel and cleanup any pending vblank enable/disable
-* work before drm_irq_uninstall() to avoid work re-enabling an
+* work before msm_irq_uninstall() to avoid work re-enabling an
* irq after uninstall has disabled it.
*/
@@ -294,7 +358,7 @@ static int msm_drm_uninit(struct device *dev)
drm_mode_config_cleanup(ddev);
pm_runtime_get_sync(dev);
- drm_irq_uninstall(ddev);
+ msm_irq_uninstall(ddev);
pm_runtime_put_sync(dev);
if (kms && kms->funcs)
@@ -553,7 +617,7 @@ static int msm_drm_init(struct device *dev, const struct
drm_driver *drv)
if (kms) {
pm_runtime_get_sync(dev);
- ret = drm_irq_install(ddev, kms->irq);
+ ret = msm_irq_install(ddev, kms->irq);
pm_runtime_put_sync(dev);
if (ret < 0) {
DRM_DEV_ERROR(dev, "failed to install IRQ handler\n");
@@ -662,43 +726,6 @@ static void msm_postclose(struct drm_device *dev, struct
drm_file *file)
context_close(ctx);
}
-static irqreturn_t msm_irq(int irq, void *arg)
-{
- struct drm_device *dev = arg;
- struct msm_drm_private *priv = dev->dev_private;
- struct msm_kms *kms = priv->kms;
- BUG_ON(!kms);
- return kms->funcs->irq(kms);
-}
-
-static void msm_irq_preinstall(struct drm_device *dev)
-{
- struct msm_drm_private *priv = dev->dev_private;
- struct msm_kms *kms = priv->kms;
- BUG_ON(!kms);
- kms->funcs->irq_preinstall(kms);
-}
-
-static int msm_irq_postinstall(struct drm_device *dev)
-{
- struct msm_drm_private *priv = dev->dev_private;
- struct msm_kms *kms = priv->kms;
- BUG_ON(!kms);
-
- if (kms->funcs->irq_postinstall)
- return kms->funcs->irq_postinstall(kms);
-
- return 0;
-}
-
-static void msm_irq_uninstall(struct drm_device *dev)
-{
- struct msm_drm_private *priv = dev->dev_private;
- struct msm_kms *kms = priv->kms;
- BUG_ON(!kms);
- kms->funcs->irq_uninstall(kms);
-}
-
int msm_crtc_enable_vblank(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@
