On Tue Sep 1, 2026 at 2:40 PM CEST, Luca Ceresoli wrote: [...]
>>> >> > 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. >> >> No, I meant into its own module. > > Looks like a good idea indeed, making the design more modular and > dependencies cleaner. > >> Do we have any dependency from the main >> drm module into drm_panel? > > As far as I can see there is only the one mentioned above: > > drm_of_find_panel_or_bridge() (in drm_of.c, drm module) > -> calls of_drm_find_panel (in drm_panel.c, would-be the new drm_panel > module) > > And while drm_of_find_panel_or_bridge() is possibly going to disappear at > the end of my series, moving drm_panel.c to its own module would make the > series non-build-bisectable, which would be very annoying. > > However there seem to be no calls from the drm module to > drm_of_find_panel_or_bridge(), so we could move it out as well. What about > a series doing, in this order: > > - move drm_of_find_panel_or_bridge() from the drm module to the > drm_kms_helper module > - move drm_panel.c to a new drm_panel module > - Main change: embed a drm_bridge into every panel > - convert drivers to stop using the panel_bridge, hopefully removing all > calls to drm_of_find_panel_or_bridge() > - remove drm_of_find_panel_or_bridge() Ah, no, that won't work. There would be a circular module dependency loop later on when we embed a drm_bridge into evern drm_panel: indeed at that point drm_panel will use the atomic and probe helpers to implement the embedded drm_bridge, resulting in: * the panel_bridge code in bridge/panel.c [drm_kms_helper module] already depends on the drm_panel.c code (it manipulates a drm_panel, OK) * additionally, the drm_panel.c code, in order to create a drm_bridge, will depend on the helpers in drm_atomic_helper and drm_probe_helper code [drm_kms_helper module] The loop is only between kernel modules (.ko), not in actual code. So I think this revised plan should work (the 2nd bullet is key): - move drm_of_find_panel_or_bridge() from the drm module to bridge/panel.c [currently drm_kms_helper module] - move bridge/panel.o to a new drm_panel_bridge module (NEW) - move drm_panel.c to a new drm_panel module - Main change: embed a drm_bridge into every panel - convert drivers to stop using the panel_bridge, hopefully removing all calls to drm_of_find_panel_or_bridge() - remove drm_of_find_panel_or_bridge() and all the drm_panel_bridge module What do you think about it? Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
