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