On 25/04/18 01:47, Tony Lindgren wrote:
>> My point was that as we don't support manual update, there can be no
>> regressions.
>
> Well it seems the manual update support got removed with commit
> 5a35876e2830 ("drm: omapdrm: Remove manual update display support").
> Reading the commit description I'd say the "interest in manual
> update displays" has been reality for close to a year now :)
No, we never had working manual update support in omapdrm. We had (still
have, I hope) it in omapfb. Omapdrm was partially based on omapfb, and
there was some attempts to add a few building blocks for manual update,
but it was never really there.
The commit you mention just dropped unused code.
>> With the current mainline code, if we so want, we can just rm
>> panel-dsi-cm and implement it and the related DSI code from scratch
>> using the DRM's panels. That's a lot easier than going from panel-dsi-cm
>> to DRM panels gradually, step by step, changing all the components in
>> the pipeline piece by piece and keeping things working after each commit.
>
> Eek, that sounds like a "flag day" plan:
>
> https://en.wikipedia.org/wiki/Flag_day_(computing)
>
> Trust me, we're better off keeping things working for every
> commit. It's good to have people using and testing the code.
I don't quite see the flag-day comparison. Manual update has never
worked. It is essentially a new feature. Do we want to add a new feature
right when we're doing a major restructuring, knowing that the new
feature needs to be partly or even mostly rewritten during the
restructuring? Or do we delay that new feature and implement it after
the restructuring?
I believe it will save everyone's time quite a bit if manual update is
added after the restructuring. The downside is that we won't have this
feature until after the restructuring is done.
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
