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

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Tony Lindgren <tony@atomide.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-omap@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH/RFC 0/7] Remove the omapdrm device from platform code
Date: Thu, 15 Dec 2016 10:08:47 +0200	[thread overview]
Message-ID: <88473bd0-0273-3d80-2249-e3ec0d1ee928@ti.com> (raw)
In-Reply-To: <20161214150506.GV4920@atomide.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 1760 bytes --]

On 14/12/16 17:05, Tony Lindgren wrote:
> * Laurent Pinchart <laurent.pinchart@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

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel