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@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:-)
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
