[PATCH/RFC 0/7] Remove the omapdrm device from platform code

Tomi Valkeinen 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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161215/e568901a/attachment.sig>

More information about the dri-devel mailing list