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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
