* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [180425 13:37]: > On 25/04/18 16:13, Tony Lindgren wrote: > > >> 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. > > > > Care to describe what is the status of the restructuring? > > Laurent can give a better explanation, but the 60 patch series is the > first step on changing how the omapdrm panels and encoders operate, and > the intro letter gives a brief about it. > > The next step is probably changing the rest of the panel/bridge > operations. Then it gets a bit unclear to me, how to make the step from > OMAP APIs to the DRM ones. I hope Laurent has a plan =). > > So, lots has been done, lots to do. As there's still lots to do, I > reiterate that I'm fine with merging manual update (after the issues > with the series have been fixed), if Laurent thinks it won't cause a big > additional burden on the restructuring. OK yeah good, let's wait for Laurent's comments then. > But I have to keep the restructuring the top priority. It's blocking us > from adding DRA7 panels, AM5 panels, AM4 EVM HDMI encoder, K2G display > support, to mention some. Well, not exactly blocking. We could also add > all these as omapdrm specific drivers, adding even more burden to be > converted to DRM model... Well we've seen many times that restructuring is best done in a way where new features are first added, then the old features are dropped few merge cycles after when nobody needs the old features. Maybe add some translation layer to keep the old panels working until they can be just dropped? > >> 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. > > > > This sounds alarming to me. How are you able to change some > > panels but not others without breaking things? > > I didn't get this one. If you mean that we could not change DSI manual > update panels without breaking things, I did not say that. We can manage > manual update displays too. It'll just increase the amount of work, and > probably much more than an auto update panel would, because of the quite > different functional model of manual update. Sorry no I meant that I'm worried about the existing panels too now :) After rebasing the manual mode patches for testing few times already, it's really just few extra function calls there to trigger the update. So yeah yet another panel to convert, but at least we can get a bunch of people to test the code changes. 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
