Why drm-mipi-dsi is built-in only?

[Thierry Reding]

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 at ffwll.ch> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160802/fc688b5e/attachment.sig>