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

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

[Takashi Iwai]

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.


thanks,

Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Vetter]

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Jani Nikula]

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);


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Andrzej Hajda]

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.

Regards
Andrzej

>
>
> BR,
> Jani.
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1520 bytes --]

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.

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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Andrzej Hajda]

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

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

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1925 bytes --]

On Tue, Aug 02, 2016 at 12:47:06PM +0200, Andrzej Hajda wrote:
> 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.

I wasn't suggesting that we turn the postcore_initcall() into
module_init(). postcore_initcall() works just fine for modules (it's
automatically replaced by a module_init() if the code is built as a
module) and it will still do the right thing with regard to ordering
when built-in.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Takashi Iwai]

On Tue, 02 Aug 2016 13:47:10 +0200,
Thierry Reding wrote:
> 
> On Tue, Aug 02, 2016 at 12:47:06PM +0200, Andrzej Hajda wrote:
> > 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.
> 
> I wasn't suggesting that we turn the postcore_initcall() into
> module_init(). postcore_initcall() works just fine for modules (it's
> automatically replaced by a module_init() if the code is built as a
> module) and it will still do the right thing with regard to ordering
> when built-in.

Right, I already tested the code, just building as a module without
any other changes.  And it worked.

About the rest, what Thierry suggested:

> 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)

Yeah, the symbol dependency should cover it enough.

> and 2) there would need to be an exit function for the module to cleanup
> the bus.

So only this one is missing.  I'm going to cook this as well and
submit patches later.


thanks,

Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel