Hi Tomi, On Tuesday 08 Aug 2017 15:56:10 Tomi Valkeinen wrote: > On 05/08/17 01:43, Laurent Pinchart wrote: > > Hello, > > > > This patch series is a third version of the code previously posted as > > "[PATCH v2 00/29] Remove the omapdrm and omapdss devices from platform > > code". > > > > The omapdss/omapdrm initialization code is quite a mess. The physical > > devices are instantiated from DT, but two virtual devices named omapdrm > > and omapdss are instanciated from platform code to pass various pieces of > > platform data to the drivers. > > > > The omapdrm and omapdss platform devices are currently used to pass data > > and function pointers from board code to the drivers for the purpose of > > > > - identifying the OMAP SoC revision > > - controlling the DSI pads > > - configuring bus throughput > > > > It turns out that all these can be handled in the omapdrm and omapdss > > drivers without the need for platform data. > > > > - The SoC revision is used to identify the version of various DSS IP > > cores, > > which can instead be done through compatible string matching (with the > > help of soc_device_match() in two cases where ES version is needed). > > > > - The DSI pads control can be performed by the driver directly without > > calling board code, accessing the related registers through syscon. > > > > - Bus throughput control is implemented in mach-omap2 as a no-op, so we > > can > > just drop the code. > > > > This patch series starts with a new patch that fixes soc_device_match() > > usage on OMAP2+. It turned out that OMAP2+ registers SoC device > > attributes at late init time, making soc_device_match() impossible to use > > for drivers at probe time, which is unfortunately the location where the > > feature is most needed. > > > > The next five patches (02/35 to 06/35) are small and simple unneeded or > > unused code removal. The next two patches (07/35 and 08/35) are cleanups > > that make sense by themselves and will be needed by later refactoring. > > I've picked patches 2-8 (inclusive). I think those can be applied > already, even if the rest of the series would need more work. I agree, let's try to apply as many as possible. > Patch 9 doesn't compile, it's referring to DSI_MODEL_OMAP4 which is not > defined. I might have forgotten to compile-test all patches individually after reordering them, I'm sorry for that. I'm fixing that now. If you can push your -next branch with patches 2-8 I can rebase on top of that, otherwise I'll keep the v4.13-rc2 base. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
