[PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support

[Thierry Reding]

On Tue, Oct 15, 2013 at 09:19:18AM -0600, Stephen Warren wrote:
> On 10/15/2013 02:37 AM, Thierry Reding wrote:
> > On Mon, Oct 14, 2013 at 12:14:47PM -0600, Stephen Warren wrote:
> >> On 10/14/2013 08:00 AM, Thierry Reding wrote:
> >>> On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström
> >>> wrote:
> >>>> On 12.10.2013 01:43, Stephen Warren wrote:
> >>>>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >>>>>> The gr2d hardware in Tegra114 is compatible with that of 
> >>>>>> Tegra20 and Tegra30. No functionaly changes are
> >>>>>> required.
> >>>>> Similarly here, if the HW is 100% backwards-compatible,
> >>>>> there's no need to add compatible values to the driver.
> >>>> 
> >>>> We've used this mechanism for attaching a per-hw-version
> >>>> data structure in match table to accomodate differences in
> >>>> how the hardware is power gated, reset, booted, some per-soc
> >>>> performance related changes etc. It's also used in staging
> >>>> features for new chips, such as disabling power features when
> >>>> they're not working/verified yet.
> >>>> 
> >>>> Upstream driver is not yet in a state where that is
> >>>> relevant.
> >>>> 
> >>>> With this, would we still be able to do that with match
> >>>> table? It sounds like we could, because we can still (even
> >>>> with multiple compatible properties) add separate entries in
> >>>> match table and I guess the compatible properties matched in
> >>>> order.
> >>> 
> >>> Yes, as long as the device tree files includes the most
> >>> specific value in the compatible this should still be possible.
> >>> So we'd have this:
> >>> 
> >>> gr2d at 54140000 { compatible = "nvida,tegra114-gr2d", 
> >>> "nvidia,tegra20-gr2d"; ... };
> >>> 
> >>> and the driver will match on "nvidia,tegra20-gr2d" if the more 
> >>> specific "nvidia,tegra114-gr2d" is not there. When the driver
> >>> is updated to support Tegra114 specific functionality, then a
> >>> more specific entry can be added to the compatible table to
> >>> handle it.
> >> 
> >> True, but the DT fragment above is also only accurate /if/ a
> >> driver that only knows about "nvidia,tegra20-gr2d" can operate
> >> 100% of the features in Tegra20 HW on Tegra114 HW forever.
> > 
> > Yes, but given that we also list "nvidia,tegra114-gr2d" in the
> > property it will be possible to add that to the driver when new
> > functionality is implemented and immediately take advantage of it
> > on Tegra114 hardware with an old device tree file which has both
> > compatible values.
> 
> Taking advantage of new functionality isn't the issue. The issue is
> whether a driver that was written purely to the spec of Tegra20 can
> successfully operate on the HW. If it can't, then the HW is not
> compatible with Tegra20. Terje's previous comments sounded like the HW
> is not backwards-compatible, although his more recent comments make it
> sound like only SW policy differences, which shouldn't be part of DT
> anyway.

Well, as good as I can tell it is backwards-compatible. I've been
testing the code included in this series with the same simple test
program that clears a rectangle on Tegra20, Tegra30 and Tegra114.

Furthermore our internal register specification files are identical,
with the exception of some whitespace changes for all three generations.
I think that qualifies as backwards-compatible?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131016/e5541066/attachment.pgp>