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

[Stephen Warren]

On 10/16/2013 02:48 AM, Thierry Reding wrote:
> 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.

All that means is that the subset of features we use so far is compatible.

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

On the other hand, that sounds like an almost perfect definition of
backwards-compatible. Can you also validate that any module
clock/power/reset inputs are identical? If so, the case is closed:-)