[PATCH 1/2 v5] drm/pl111: Support the Versatile Express
Daniel Vetter
daniel at ffwll.ch
Thu May 3 03:41:09 PDT 2018
On Thu, May 3, 2018 at 11:58 AM, Linus Walleij <linus.walleij at linaro.org> wrote:
> On Thu, May 3, 2018 at 11:41 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>>Me:
> (...)
>>> ChangeLog v4->v5:
>>> - Collect Robin's Tested-by
>>> - Switch to builtin_platform_driver() for the muxfpga as this
>>> file is always built as "-y" for the arch and we need to
>>> avoid module collisions with the main PL111 driver.
>>> +builtin_platform_driver(vexpress_muxfpga_driver);
>>
>> LD [M] drivers/gpu/drm/pl111/pl111_drm.o
>> drivers/gpu/drm/pl111/pl111_vexpress.o: In function `vexpress_muxfpga_driver_init':
>> /home/daniel/linux/aarch64/drivers/gpu/drm/pl111/pl111_vexpress.c:125: multiple definition of `init_module'
>> drivers/gpu/drm/pl111/pl111_drv.o:/home/daniel/linux/aarch64/drivers/gpu/drm/pl111/pl111_drv.c:427: first defined here
>> make[4]: *** [scripts/Makefile.build:570: drivers/gpu/drm/pl111/pl111_drm.o] Error 1
>> make[3]: *** [scripts/Makefile.build:583: drivers/gpu/drm/pl111] Error 2
>> make[3]: *** Waiting for unfinished jobs....
>>
>> Using the default drm-misc configs.
>>
>> Please fix asap, and please compile-test before pushing using these
>> default configs so others aren't blocked. I've disabled the pl111 driver
>> in there for now, please also re-enable.
>
> That's typical. As you see in the ChangeLog I really tried to address
> exactly this. I got that build error from the zeroday build with v4,
> changed it to a builtin driver and pushed, then it did not give me
> the problem again.
>
> I guess the zeroday build robot isn't using the same configs...
>
> Hm, I will take suggestions on how to actually solve it, I guess
> this is due to the initcall infrastructure only allowing one initcall
> per module?
>
> In that case I guess I should either:
> - Break out the vexpress file into its own module
> - Call the vexpress init hooks from the initcalls in the
> main module
>
> I guess I will go for the latter even if it litters the driver with
> more cross-calls.
Yeah, that's what we generally do. Including #ifdef mess and all that,
since separate kmod tends to be even worse (you need piles of
EXPORT_SYMBOL all over). It's a bit silly that the module/initcall
stuff can't allow multiple entries ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the linux-arm-kernel
mailing list