On Fri, 22 Mar 2024, Maxime Ripard <mripard@xxxxxxxxxx> wrote: > On Fri, Mar 22, 2024 at 11:22:14AM +0200, Jani Nikula wrote: >> On Fri, 22 Mar 2024, Sui Jingfeng <sui.jingfeng@xxxxxxxxx> 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@xxxxxxxxxx> >> >> --- >> >> 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
