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

[Tomi Valkeinen]

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
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

-------------- 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>