Re: Tegra DRM device tree bindings

["Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

On 26.06.2012 22:38, Stephen Warren wrote:

> I would assume this can safely be inferred from the compatible value;
> nvidia,tegra20-host1x v.s. nvidia,tegra30-host1x, and so there's no
> need to represent this in DT. I would assume (and it's certainly just
> an assumption) that there are numerous other small details that are
> different between the two SoCs, and so the driver will need to have
> some table mapping from compatible value to various information
> anyway. Terje, can you confirm/deny this (and hopefully use your
> knowledge of any future chips to guide the decision without giving
> anything away)?


I'll now discuss what is going in our internal driver, which will be
visible in our public git tree at some point.

Regarding just host1x, I have just parameterized per SoC the following
properties in the driver:
 * number of sync points
 * number of channels
 * number of wait bases
 * number of mlocks

In addition to this, per SoC we parameterize the mapping of sync points
to channels, the names of sync points (for debugging purposes) and
whether sync point is stream managed or client managed.

For host1x and other devices, we have parameters indicating ability to
power gate, idle times before clock gating and power gating, power
domain ids (also used for resetting), associated clocks and some other
stuff. In the driver parameters we have function pointers for context
management and clock scaling.

Of these, possibility to power gate, power domain ids, number of
resources are hardware properties, and rest are more of less agreements
on how software uses the resources. Context management is in the
borderline - each SoC has its own sequence to save and restore a context
for 3D and MPE.

We will also have different register layouts for host1x in different
SoCs and I have recently made nvhost ready for that.

Everything else except the register layout and the context management
could be encoded into device trees. The remaining things will ensure
that we will need to have some SoC specific code in the driver.

Terje