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