On 25/04/18 09:35, Pavel Machek wrote: >> 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 > > Manual update works for us, today, and you keep stalling it because > some restructuring might take place in the future. If the restructure > is ready, please commit it _now_. If it is not, can we get our > displays working, please? The restructuring has been going on for some time now and is still going on. See e.g. "[PATCH v2 00/30] omapdrm: Allocate objects dynamically" and "[PATCH/RFC 00/60] omapdrm: Reverse direction of DSS device (dis)connect operations" series sent to dri-devel some time back. >> 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? > > The feature already works. We need it for our devices to be usable. A feature that works means having support in the mainline kernel. We have a patch series that has known issues, conflicts with other posted serieses, and is sure to make the ongoing critical restructuring more difficult. >> 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. > > How does it save anyone's time? Same ammount of work still needs to be > done. It's much much more work to rewrite something, step by step, keeping it working at the same time, compared to just adding it essentially from scratch 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
