Re: [PATCH 2/6] ARM: tegra: Add auxiliary data for nvhost

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

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.