On 08/02/2016 10:36 AM, Thierry Reding wrote: > 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. If you change initcall of mipi_dsi to module and then you compile it as built-in, only link order will guard correct initialization sequence. As for now panels are linked after mipi-dsi, so it should be OK, even if little bit hacky. Regards Andrzej _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
