[RFC PATCHv2 0/9] drm/tidss: new display driver for TI's DSS6 & DSS7

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen at ti.com> [180619 08:29]:
> On 19/06/18 09:24, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen at ti.com> [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