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
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
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.
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.
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
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
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
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@lists.freedesktop.org
-
Andrzej Hajda -
Daniel Vetter -
Jani Nikula -
Takashi Iwai -
Thierry Reding