On 11/26/2012 02:40 AM, Terje Bergström wrote: > On 24.11.2012 21:11, Thierry Reding wrote: >> On Sat, Nov 24, 2012 at 09:09:11AM +0200, Terje Bergström wrote: >>> The host1x specifics (number of channels, pts etc) are description of >>> hardware, so they could go to a device tree binding. >> >> I'm not sure that's even required. The number of syncpoints and channels >> should be static for a particular version of SoC, right? In that case it >> can be derived from the DT compatible property, can't it? > > I might be a bit confused here about the purpose of device trees. > > The register aperture, irqs and enumerated list of devices could also be > derived from the information about host1x compatibility properly. They > don't change within SoC version. Why do we have them in device tree? That's potentially true. But, consider something like an I2C controller. We have 4 or 5 instances of that. Each has a different register base, IRQ, etc. Hence, the per-instance information is in DT. Some HW modules are singleton so putting req/IRQ in DT might not be strictly necessary, but then the argument becomes that its better to be consistent and get reg/IRQ from DT in all cases, not only where strictly necessary. Another question is: Can we support likely future HW versions just by changing DT data? If so, putting the data in DT is probably a good things. Lets say that Tegra20 and Tegra30 host1x are exactly identical except for a different base address and different # of syncpoint registers. If we put that information in DT, we don't even need to add a new compatible value to the driver, nor a new table mapping that compatible value to the # syncpoints. That means new HW support without having to write code. There is obviously a trade-off to make in order to decide exactly what's best to go into DT and what's best to go into the driver. Something simple like #syncpoints might do well in DT. Something like the entire Tegra pin controller pin/group/... definitions don't really make sense to put in DT. -- 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
