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

Hi Maxime,

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.

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.

Luca

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