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

[Andrzej Hajda <a.hajda@samsung.com>]

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@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.

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel