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

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
	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 12:07:44 +0200	[thread overview]
Message-ID: <2042929.xqZ0CNKz48@avalon> (raw)
In-Reply-To: <88473bd0-0273-3d80-2249-e3ec0d1ee928@ti.com>

Hi Tomi,

On Thursday 15 Dec 2016 10:08:47 Tomi Valkeinen wrote:
> 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?

Or retrieve the SoC revision in the driver. I know this is a bad thing to do 
in general, but when handling errata that are specific to certain ES versions, 
it's hard to avoid. https://patchwork.kernel.org/patch/9141381/ has been 
developed for that (or at least a very similar) purpose.

-- 
Regards,

Laurent Pinchart

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