Received-SPF: pass (google.com: domain of linux-kernel+bounces-111295-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 22 Mar 2024 11:31:06 +0100
From: Maxime Ripard <mripard@kernel.org>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, 
	Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, 
	Daniel Vetter <daniel@ffwll.ch>, Jonathan Corbet <corbet@lwn.net>, 
	Sandy Huang <hjc@rock-chips.com>, Heiko =?utf-8?Q?St=C3=BCbner?= <heiko@sntech.de>, 
	Chen-Yu Tsai <wens@csie.org>, Jernej Skrabec <jernej.skrabec@gmail.com>, 
	Samuel Holland <samuel@sholland.org>, Hans Verkuil <hverkuil@xs4all.nl>, 
	Sebastian Wick <sebastian.wick@redhat.com>, Ville =?utf-8?B?U3lyasOkbMOk?= <ville.syrjala@linux.intel.com>, 
	dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, 
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, 
	linux-sunxi@lists.linux.dev
Subject: Re: [v10,20/27] drm/connector: hdmi: Add Infoframes generation
Message-ID: <20240322-loose-resourceful-bullmastiff-92cfaf@houat>
References: <20240321-kms-hdmi-connector-state-v10-20-e6c178361898@kernel.org>
 <07125064-2a78-4515-bb48-655f2aec140f@linux.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="5rd3vuyyvq3awglq"
Content-Disposition: inline
In-Reply-To: <07125064-2a78-4515-bb48-655f2aec140f@linux.dev>


--5rd3vuyyvq3awglq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Mar 22, 2024 at 05:53:07AM +0800, Sui Jingfeng wrote:
> Hi,
>=20
>=20
> 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.
> >=20
> > 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.
> >=20
> > Signed-off-by: Maxime Ripard <mripard@kernel.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(+)
> >=20
> > 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
>=20
> 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

--5rd3vuyyvq3awglq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZf1d6QAKCRDj7w1vZxhR
xfhQAQCu0NBIAdBH+cxZxEu6wIBjCqIn1oD+nTHDxOSsluuItwEA9Oy60mNpP4Om
Xu9L4CIP02hqE9XIyC9VujJM0cW/LQA=
=XSYZ
-----END PGP SIGNATURE-----

--5rd3vuyyvq3awglq--