[PATCH v3 00/35] omapdrm: Deconstruct DSS features

[Laurent Pinchart]

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