Thread (28 messages) 28 messages, 5 authors, 2018-05-15

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

From: Mauro Carvalho Chehab <hidden>
Date: 2018-04-23 14:25:26
Also in: dri-devel, linux-media

Em Mon, 23 Apr 2018 17:11:14 +0300
Tomi Valkeinen [off-list ref] escreveu:
On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote:
quoted
Ideally we should be able to build both drivers in the same kernel
(especially as modules).

I was hoping that it could be fixed easily but then I discovered
the root source of the problem:

drivers/gpu/drm/omapdrm/dss/display.o: In function `omapdss_unregister_display':
display.c:(.text+0x2c): multiple definition of `omapdss_unregister_display'
drivers/video/fbdev/omap2/omapfb/dss/display.o:display.c:(.text+0x198): first defined here  
The main problem is that omapdrm and omapfb are two different drivers
for the same HW. You need to pick one, even if we would change those
functions and fix the link issue.

At some point in time we could compile both as modules (but not
built-in), but the only use for that was development/testing and in the
end made our life more difficult. So, now you must fully disable one of
them to enable the other. And, actually, we even have boot-time code,
not included in the module itself, which gets enabled when omapdrm is
enabled.

While it's of course good to support COMPILE_TEST, if using COMPILE_TEST
with omapfb is problematic, I'm not sure if it's worth to spend time on
that. We should be moving away from omapfb to omapdrm.
Yeah, moving away from omapfb sounds the best alternative. As it seems that
there's just one driver currently depending on it, I guess it shouldn't be
that hard to do such change from Kernel's view, but I may be wrong, as I've
no clue what this would mean to userspace.

Thanks,
Mauro
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help