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

[Tomi Valkeinen]

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.

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