On 19/06/18 09:24, Tony Lindgren wrote: > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [180618 13:25]: >> Hi, >> >> This is a new DRM driver for Texas Instruments' Keystone K2G and AM6 >> SoCs. >> >> K2G has DSS6 IP, which is related to the OMAP DSS IPs handled by the >> omapdrm driver. While on higher level the DSS6 resembles the older DSS >> versions, the registers and the internal pipelines differ a lot. DSS6 >> IP on K2G is a "ultra-light" version, and has only a single plane and a >> single output. > > This smells like deja vu to me. Are you really really sure this hardware > is "different" considering this will be fork number four in the mainline > kernel tree of dss-something? We did move to DRM from fbdev, but that's not related to the HW, and there was no way around it. And long, long time before that we created the "new" omapfb driver, which did not support OMAP1. I think that made sense, as OMAP1's display controller is not DSS. But nothing else comes to my mind right away... We have supported the different DSS IPs from OMAP2 to OMAP5 to DRA7 in a single driver (two, if you want to count DRM/omapfb). What are these four forks? In any case, I have been thinking about this a lot since a year ago when I wrote the first driver versions. We initially did have the DSS6/7 support in omapdrm, which worked, but it felt rather forced. The registers are different, the internal layout of DISPC components is different, irqs are different, DSS/DISPC device boundary is different... With the omapdrm version, we ended up with "compatibility" layers, making either the older DSSes look like DSS6/7, or the other way around. We spent a lot of time writing those layers, trying to make things work and clean. I got frustrated, and wrote a new driver in a few weeks which, I think, is much cleaner and more manageable than anything we had earlier. I think the core question is: how much code would there be to share? I don't think it would be much, mostly plumbing code at the driver/DRM level. Second question is, how much more work would it be to have a single omapdrm driver and maintain it across all these different DSS IPs and DSS SoC integrations. I think it would increase the amount of work tenfold. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html