On 23/04/18 23:09, Mauro Carvalho Chehab wrote: >> 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. >> 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
