* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [180425 06:08]:
> 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.
It was dropped because it was broken. Which meant nobody could
add any manual update displays without fixing it. And this is
how it became unused. Then Sebastian posted patches to fix it.
> >> 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?
But this is a flag day event :) You've been talking about this
magical event for years now and used it to block panels and
connectors.
And now I'm actually worried what other things will break this
time around. Clearly this change needs to be done in a way where
we can test every step for various features.
> 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.
Let's not do that. That's exactly how we end up with losing
lots of the features again because of bugs because we can't
test things properly.
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
