[PATCH/RFC 0/7] Remove the omapdrm device from platform code
tomi.valkeinen at ti.com
Thu Dec 15 08:08:47 UTC 2016
On 14/12/16 17:05, Tony Lindgren wrote:
> * Laurent Pinchart <laurent.pinchart at ideasonboard.com> [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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the dri-devel