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