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
Attachment:
pgp52PqyMhvMo.pgp
Description: PGP signature