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