linux-kernel - Re: [v10,20/27] drm/connector: hdmi: Add Infoframes generation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240322-loose-resourceful-bullmastiff-92cfaf@houat>
Date: Fri, 22 Mar 2024 11:31:06 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, 
	Daniel Vetter <daniel@...ll.ch>, Jonathan Corbet <corbet@....net>, 
	Sandy Huang <hjc@...k-chips.com>, Heiko Stübner <heiko@...ech.de>, 
	Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, 
	Samuel Holland <samuel@...lland.org>, Hans Verkuil <hverkuil@...all.nl>, 
	Sebastian Wick <sebastian.wick@...hat.com>, Ville Syrjälä <ville.syrjala@...ux.intel.com>, 
	dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, linux-rockchip@...ts.infradead.org, 
	linux-sunxi@...ts.linux.dev
Subject: Re: [v10,20/27] drm/connector: hdmi: Add Infoframes generation

Hi,

On Fri, Mar 22, 2024 at 05:53:07AM +0800, Sui Jingfeng wrote:
> Hi,
> 
> 
> On 2024/3/21 23:29, Maxime Ripard wrote:
> > Infoframes in KMS is usually handled by a bunch of low-level helpers
> > that require quite some boilerplate for drivers. This leads to
> > discrepancies with how drivers generate them, and which are actually
> > sent.
> > 
> > Now that we have everything needed to generate them in the HDMI
> > connector state, we can generate them in our common logic so that
> > drivers can simply reuse what we precomputed.
> > 
> > Signed-off-by: Maxime Ripard <mripard@...nel.org>
> > ---
> >   drivers/gpu/drm/Kconfig                            |   1 +
> >   drivers/gpu/drm/drm_atomic_state_helper.c          | 338 +++++++++++++++++++++
> >   drivers/gpu/drm/drm_connector.c                    |  14 +
> >   .../gpu/drm/tests/drm_atomic_state_helper_test.c   |   1 +
> >   drivers/gpu/drm/tests/drm_connector_test.c         |  12 +
> >   include/drm/drm_atomic_state_helper.h              |   8 +
> >   include/drm/drm_connector.h                        | 109 +++++++
> >   7 files changed, 483 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 16029435b750..3d3193c7aa5f 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST
> >   	  If in doubt, say "N".
> >   config DRM_KMS_HELPER
> >   	tristate
> >   	depends on DRM
> > +	select DRM_DISPLAY_HDMI_HELPER
> 
> Should we select DRM_DISPLAY_HELPER here? Otherwise there will have
> some compile error emerged with default config.

Which default config are you talking about? This compiles fine with all
drm-misc defconfig, x86 defconfig and allmodconfig.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)