Re: [PATCH 04/11] drm/panel: merge the drm_kms_helper module into the drm module

Hi Maxime,

On Mon Aug 24, 2026 at 9:48 AM CEST, Maxime Ripard wrote:
> On Mon, Aug 17, 2026 at 02:27:58PM +0200, Luca Ceresoli wrote:
>> On Mon Aug 17, 2026 at 10:31 AM CEST, Maxime Ripard wrote:
>> > On Fri, Aug 14, 2026 at 04:05:52PM +0200, Luca Ceresoli wrote:
>> >> Work is in progress to make every drm_panel automatically create a
>> >> panel_bridge [0][1].
>> >>
>> >> This requires the panel code to call the drm_panel_bridge APIs. However
>> >> this would create a circular dependency loop on modular builds:
>> >>
>> >> __devm_drm_panel_alloc() [drm]
>> >>    -> drm_panel_bridge_add() [drm_kms_helper]
>> >>       -> drm_bridge.c APIs [drm]
>> >>
>> >> Moving just the panel_brige.o file from [drm_kms_helper] to [drm] does not
>> >> work because the panel bridge code uses the drm_atomic_helper and
>> >> drm_probe_helper which add further dependencies on symbols in the
>> >> [drm_kms_helper] module.
>> >>
>> >> So take a simple approach, and move the entire drm_kms_helper into the
>> >> [drm] module.
>> >>
>> >> Link: https://lore.kernel.org/all/emuj2innmp6zmzd7pyakqzjqpdzhly6qfhakya3ydwmd63pl26@5jwxaidpikjw/ [0]
>> >> Link: https://lore.kernel.org/lkml/[email protected]/ [1]
>> >> Signed-off-by: Luca Ceresoli <[email protected]>
>> >
>> > So, that's not an option. However, why do we need drm_panel_bridge_add()
>> > after this work is done? If we want to create a bridge for every panel,
>> > then the bridge implementation can live in drm_panel.c, which is part of
>> > the drm module.
>> >
>> > And we'd essentially move drm_panel_bridge into drm_panel.c, and make it
>> > private.
>>
>> Yes in theory, but the panel_bridge code uses other parts of the
>> drm_kms_helper module: drm_atomic_helper and drm_probe_helper, maybe more,
>> so we'd have to move them into the drm module too.
>
> Ah, right. What would happen if we were doing it the other way around
> then? Move drm_panel out of the main drm module?

Into the drm_kms_helper module?

I had a look and did some experiments and I found at least one user in the drm
module calling a drm_panel API, and guess who:

 drm_of_find_panel_or_bridge() (in drm_of.c, drm module)
    -> calls of_drm_find_panel (in drm_panel.c, drm_kms_helper module)

Based on our discussion after patch 3, I'm not sure
drm_of_find_panel_or_bridge() will disappear soon. If it doesn't, I guess
we can try to move drm_of_find_panel_or_bridge() into bridge/panel.c which
is in the drm_kms_helper module (and from drm_of.h info
drm_bridge.h?). That however might trigger build failures for drivers which
currently don't select DRM_KMS_HELPER and which would have to select it.

I'll give it a try, and if I see major drawbacks I will get back to moving
all the drm_kms_helper code into the main drm module.

>> Is it worth trying to identify only the closure of files in drm_kms_helpers
>> that are actually used by the panel_bridg, and move only them? That'd mean
>> having some *_helper.c files in the drm module and other *_helper.c files
>> in the drm module.
>>
>> There's a licensing aspect too: drm_panel.c is MIT-licensed, bridge/panel.c
>> is GPL-2.0-or-later. However my understanding is that we can merge the two
>> into a single file and the result would all be GPL-2.0-or-later, so that is
>> an option.
>
> Yeah, that's not a concern.

Good, thanks for the feedback on this.

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com