On 23/04/18 23:09, Mauro Carvalho Chehab wrote:

quoted

I don't think it's worth it renaming the common symbols. They will change over 
time as omapdrm is under heavy rework, and it's painful enough without having 
to handle cross-tree changes.

It could just rename the namespace-conflicting FB_OMAP2 functions,
keeping the DRM ones as-is.

Yes, I'm fine with renaming omapfb functions if that helps. But still,
if omapdrm is enabled in the kernel as module or built-in, omapfb will
not work. So even if we get them to compile and link, it'll break at
runtime one way or another.

quoted

Let's just live with the fact that both drivers 
can't be compiled at the same time, given that omapfb is deprecated.

IMO, a driver that it is deprecated, being in a state where it
conflicts with a non-deprecated driver that is under heavy rework
is a very good candidate to go to drivers/staging or even to /dev/null.

The problem is that it supports old devices which are not supported by
omapdrm. But both omapfb and omapdrm support many of the same devices.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki