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

From: Jani Nikula <jani.nikula@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Sui Jingfeng" <sui.jingfeng@linux.dev>,
	"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 Stübner" <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 Syrjälä" <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
Date: Fri, 22 Mar 2024 13:46:42 +0200	[thread overview]
Message-ID: <87plvmjxp9.fsf@intel.com> (raw)
In-Reply-To: <20240322-petite-fabulous-bustard-b168ec@houat>

On Fri, 22 Mar 2024, Maxime Ripard <mripard@kernel.org> wrote:
> On Fri, Mar 22, 2024 at 11:22:14AM +0200, Jani Nikula wrote:
>> On Fri, 22 Mar 2024, Sui Jingfeng <sui.jingfeng@linux.dev> 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@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(+)
>> >>
>> >> 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.
>> 
>> Can we stop abusing select instead of adding more selects to paper over
>> the issues?
>> 
>> Use select only for non-visible symbols (no prompts anywhere) and for
>> symbols with no dependencies.
>
> I don't really have an opinion there, but it looks like all the other
> helpers Kconfig symbols are using select everywhere, and I don't really
> see how we could turn them into visible symbols with depends on without
> breaking a number of defconfig.
>
> Could you expand a bit what you have in mind here?

Just my standard grumbling about the rampant select abuse.

Maybe one day someone takes the hint and starts fixing things up. :p

See the note under "reverse dependencies" at [1].

BR,
Jani.

[1] https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes

-- 
Jani Nikula, Intel