* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [180619 08:29]: > 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. Well grep matches dss also for drivers/video/fbdev/omap :) > 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? I counted four with: drivers/video/fbdev/omap drivers/video/fbdev/omap2 drivers/gpu/drm/omapdrm And then this new one. > 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. OK if it's different, it is different. > 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. OK. Usually the effort is best spent in making the related framework better for different hardware. Regards, Tony -- 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
