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? Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
