* Why drm-mipi-dsi is built-in only? @ 2016-07-22 14:30 Takashi Iwai 2016-07-22 16:55 ` Daniel Vetter 0 siblings, 1 reply; 8+ messages in thread From: Takashi Iwai @ 2016-07-22 14:30 UTC (permalink / raw) To: dri-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-07-22 14:30 Why drm-mipi-dsi is built-in only? Takashi Iwai @ 2016-07-22 16:55 ` Daniel Vetter 2016-08-01 13:59 ` Jani Nikula 0 siblings, 1 reply; 8+ messages in thread From: Daniel Vetter @ 2016-07-22 16:55 UTC (permalink / raw) To: Takashi Iwai; +Cc: dri-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-07-22 16:55 ` Daniel Vetter @ 2016-08-01 13:59 ` Jani Nikula 2016-08-01 18:04 ` Andrzej Hajda 0 siblings, 1 reply; 8+ messages in thread From: Jani Nikula @ 2016-08-01 13:59 UTC (permalink / raw) To: Daniel Vetter, Takashi Iwai; +Cc: Andrzej Hajda, Thierry Reding, dri-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-08-01 13:59 ` Jani Nikula @ 2016-08-01 18:04 ` Andrzej Hajda 2016-08-02 8:36 ` Thierry Reding 0 siblings, 1 reply; 8+ messages in thread From: Andrzej Hajda @ 2016-08-01 18:04 UTC (permalink / raw) To: Jani Nikula, Daniel Vetter, Takashi Iwai; +Cc: Thierry Reding, dri-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-08-01 18:04 ` Andrzej Hajda @ 2016-08-02 8:36 ` Thierry Reding 2016-08-02 10:47 ` Andrzej Hajda 0 siblings, 1 reply; 8+ messages in thread From: Thierry Reding @ 2016-08-02 8:36 UTC (permalink / raw) To: Andrzej Hajda; +Cc: dri-devel [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-08-02 8:36 ` Thierry Reding @ 2016-08-02 10:47 ` Andrzej Hajda 2016-08-02 11:47 ` Thierry Reding 0 siblings, 1 reply; 8+ messages in thread From: Andrzej Hajda @ 2016-08-02 10:47 UTC (permalink / raw) To: Thierry Reding; +Cc: dri-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-08-02 10:47 ` Andrzej Hajda @ 2016-08-02 11:47 ` Thierry Reding 2016-08-02 11:55 ` Takashi Iwai 0 siblings, 1 reply; 8+ messages in thread From: Thierry Reding @ 2016-08-02 11:47 UTC (permalink / raw) To: Andrzej Hajda; +Cc: dri-devel [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Why drm-mipi-dsi is built-in only? 2016-08-02 11:47 ` Thierry Reding @ 2016-08-02 11:55 ` Takashi Iwai 0 siblings, 0 replies; 8+ messages in thread From: Takashi Iwai @ 2016-08-02 11:55 UTC (permalink / raw) To: Thierry Reding; +Cc: Andrzej Hajda, dri-devel 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-08-02 11:55 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-22 14:30 Why drm-mipi-dsi is built-in only? Takashi Iwai 2016-07-22 16:55 ` Daniel Vetter 2016-08-01 13:59 ` Jani Nikula 2016-08-01 18:04 ` Andrzej Hajda 2016-08-02 8:36 ` Thierry Reding 2016-08-02 10:47 ` Andrzej Hajda 2016-08-02 11:47 ` Thierry Reding 2016-08-02 11:55 ` Takashi Iwai
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.