[PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures

[Laurent Pinchart]

Hi Tomi,

On Tuesday 09 May 2017 15:02:36 Tomi Valkeinen wrote:
> On 08/05/17 14:32, Laurent Pinchart wrote:
> > Both structures describe features of a particular OMAP DSS version,
> > there's no reason to keep them separate. Merge them together, allowing
> > initialization of the features based on the DSS compatible string
> > instead of the OMAP SoC version.
> 
> I don't think this is the correct way. As I mentioned earlier,
> dss_features should go. We should work on moving the parts from
> dss_features to each individual driver. I think there are probably only
> a very few dss-features that need to be accessed by multiple files, and
> those features could have a function of their own to query them.

I don't disagree with that, but can't we do so on top of this series ? I don't 
think that these patches make the situation worse.

> But that may also be a bit bigger work, so... I thought about it already
> earlier in this series: wouldn't it be easier to first reconstruct the
> current OMAPDSS_VER_* with soc_device_match(), at module init time,
> which would allow us to keep most of the omapdss side unchanged. Then
> continue removing the arch/arm/ stuff.

I considered that to start with, but decided it was really a hack. I instead 
went for cleaning things up where possible, and keeping hacks where a proper 
rework would require a set of new patch series. The result is a balance 
between a few hacks and lots of cleanup patches, which I considered was right 
when I realized that the series was already 28 patches long.

> When that's done and merged, we could have follow up patches later to
> clean up dss_features, and add version handling to each driver, however
> is best in that particular file.
> 
> I feel that this series is perhaps doing a bit too much at once.

Then let's not add more ;-) More seriously, as lots of cleanups are here 
already, I think we should merge them. If there's any hack that you believe 
goes in the wrong direction and would make a proper rework more complex, let's 
discuss them. Otherwise, for the ones that either are too small improvements, 
or just keep the status quo, I plan to rework them later.

-- 
Regards,

Laurent Pinchart