On 16.10.2013 11:48, Thierry Reding wrote: > On Tue, Oct 15, 2013 at 09:19:18AM -0600, Stephen Warren wrote: >> 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? A driver written for Tegra20 2D works with Tegra114 2D. Not necessarily vice versa, because Tegra114's driver can ask for higher clocks, or it might want to power gate 2D. I mentioned earlier bringup activities. Perhaps Stephen took that in a way I didn't intend. Terje -- 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
