On Mon, Aug 01, 2016 at 08:04:55PM +0200, Andrzej Hajda wrote: > On 08/01/2016 03:59 PM, Jani Nikula wrote: > > Cc Andrzej, Thierry > > > > On Fri, 22 Jul 2016, Daniel Vetter <daniel@xxxxxxxx> wrote: > >> On Fri, Jul 22, 2016 at 04:30:24PM +0200, Takashi Iwai wrote: > >>> Hi, > >>> > >>> is there any reason drm-mipi-dsi can't be a module? It's fixed as a > >>> built-in since its Kconfig is bool. > >> Probably none except embedded folks eshew modules ;-) Submit patch, I'll > >> apply. > > Possibly this? > > > > postcore_initcall(mipi_dsi_bus_init); > > If I remember correctly, the only reason for this is to have mipi_dsi bus > registered before mipi_dsi drivers, which usually are registered > at module initcall. But maybe bus registration can be performed at > first mipi_dsi driver registration. This way we could modularize it. I think it should work fine if this was built as a module. The purpose for having this as postcore_initcall() is simply so that the bus is fully initialized before any driver gets registered with it. If this code is built as a module, symbol dependencies will make sure that the drm_mipi_dsi.ko module will be loaded before any users. Two things are missing, though: 1) the drm_mipi_dsi.ko module would need to be reference counted so that the symbols stay around as long as there are any drivers (this might be covered by symbol dependencies already) and 2) there would need to be an exit function for the module to cleanup the bus. Thierry
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
