Hi Tomi, On Thursday 15 Dec 2016 10:08:47 Tomi Valkeinen wrote: > On 14/12/16 17:05, Tony Lindgren wrote: > > * Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> [161213 15:38]: > >> The series will be annoying to merge given how interleaved the ARM and > >> driver patches are. The easiest solution would be to merge everything > >> through the ARM tree (as the risk of conflict on the DRM side is low), > >> in which case some patches could be squashed together if desired > >> (especially the last two that wouldn't require renaming the driver > >> internally anymore). > > > > Maybe Tomi can set up an immutable branch once the patches have been > > reviewed? That way also I can merge it in too as needed. > > Yes, I think that's a good option. Then the series doesn't have to be so > artificially split into linux-omap and drm parts. > > I don't think there are much chances with conflicts on the linux-omap > side, as the only files touched are display.c and drm.c (well, and a > small change in Makefile). > > I like the series in general, but I still need to go through it in detail. > > And speaking of removing of platform data... > > Tony, the only big reason we still have the omapdss platform data > (include/linux/platform_data/omapdss.h) is the omapdss_version, which is > based on the OMAP SoC version. > > We need that in the driver, as the DSS IP revision hasn't been updated > in a couple of cases, or the issue comes from outside DSS. But there are > only a few of these cases, mostly we would do just fine with the DSS IP > revision. > > What do you think of a scheme, where we'd drop the platform data, but at > early platform init code we would inject a DT property or two into DSS's > DT data in those problematic cases? > > Or do you have any other ideas how to pass flags to the driver based on > the SoC revision? Or retrieve the SoC revision in the driver. I know this is a bad thing to do in general, but when handling errata that are specific to certain ES versions, it's hard to avoid. https://patchwork.kernel.org/patch/9141381/ has been developed for that (or at least a very similar) purpose. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
