On 06/26/2012 01:27 PM, Thierry Reding wrote:

On Tue, Jun 26, 2012 at 11:41:43AM -0600, Stephen Warren wrote:

quoted

On 06/26/2012 08:02 AM, Terje Bergström wrote:

quoted

On 26.06.2012 16:41, Thierry Reding wrote:

quoted

On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergström
wrote:

quoted

We also assign certain host1x common resources per device
by convention, f.ex. sync points, channels etc. We
currently encode that information in the device node (3D
uses sync point number X, 2D uses numbers Y and Z). The
information is not actually describing hardware, as it
just describes the convention, so I'm not sure if device
tree is the proper place for it.

Are they configurable? If so I think we should provide for
them being specified in the device tree. They are still
hardware resources being assigned to devices.

Yes, they're configurable, and there's nothing hardware
specific in the assignment of a sync point to a particular use.
It's all just a software agreement. That's why I'm a bit
hesitant on putting it in device trees, which are supposed to
only describe hardware.

So I think that the DT can describe the existence of sync-points 
(presumably include a node for the sync-point HW device if it's 
separate). However, since the usage of each sync-point is
entirely arbitrary, that seems like something which should be
either assigned dynamically at run-time, or at least
managed/assigned in SW at runtime somehow, rather than hard-coded
into DT; it's more policy than HW.

The sync-points are part of the host1x device as I understand it.
If their usage is truly generic, then we can probably ignore them
safely. Maybe it'd make sense to carry a property that defines the
number of sync points available for the host1x hardware represented
by the DT?

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)?