[PATCH v2 22/30] drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data

[Laurent Pinchart]

Hi Tomi,

On Wednesday, 14 February 2018 10:31:17 EET Tomi Valkeinen wrote:
> Hi,
> 
> On 13/02/18 14:00, Laurent Pinchart wrote:
> > The dss_device is the top-level component in the omapdss driver. Give
> > the omapdrm driver access to the dss_device pointer in order to obtain
> > pointers to all other components from it. This requires a new global
> > variable in the omapdss driver that will be removed when merging the
> > omapdrm and omapdss drivers, but will already allow removal of several
> > other global variables.
> 
> How can we support different DSS versions with this change? So far the
> DSS functions used from omapdrm have been designed to be free of DSS
> specific parameters, and in the TI kernel we have a separate DSS driver
> for the DSS6, and omapdrm "just works" with either DSS2-5 and DSS6.
> 
> We could have the "struct dss_device *dss" and "struct dispc_device
> *dispc" in omap_drv.h as "struct device" pointers instead.

>From an omapdrm point of view the dss_device and dispc_device structures are 
opaque. We're free to do anything we want with them, from switching to struct 
device pointers to allow completely separate implementations of the DSS and 
DISPC on DSS2-5 and DSS6, or storing common data in struct dss_device and 
struct dispc_device, that we can then subclass with version-specific 
structures internally. I don't have a strong opinion at the moment as I 
haven't seen the DSS6 code and thus can't judge whether there's a need to 
share data and code. At this point what matters to me is making sure we always 
pass objects around explicitly to avoid global variables. We could go for 
struct device now and switch to something else later, or the other way around, 
or anything else that works for you.

> Alternatively, we could just create a totally new DRM driver for DSS6,
> having nothing in common with the current omapdrm. From naming
> perspective that would not be so bad, as OMAP is dead =). But if we ever
> get DSS7, perhaps that's again different enough that we don't want a
> single DSS driver for DSS6 and DSS7.

Again I haven't stupid the differences between DSS2-5 and DSS6 so I can't 
really comment, but being able to start from scratch without carrying device 
mistakes over is tempting. Of course that means we would just make different 
design mistakes :-)

-- 
Regards,

Laurent Pinchart