Tegra DRM device tree bindings
Stephen Warren
swarren at wwwdotorg.org
Wed Jun 27 03:41:43 EST 2012
On 06/26/2012 08:02 AM, Terje Bergström wrote:
> On 26.06.2012 16:41, Thierry Reding wrote:
>
>> On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergström wrote:
>>> 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.
>>> Either way is fine for me. The full addresses are more familiar to me as
>>> we tend to use them internally.
>
>> Using the OF mechanism for translating the host1x bus addresses,
>> relative to the host1x base address, to CPU addresses seems "purer", but
>> either way should work fine.
>
> I'll let you decide, as I don't have a strong opinion either way. I
> guess whatever is the more common way wins.
I'd certainly prefer all the nodes to use the full/absolute address.
That way, the DT will exactly match the addresses in the documentation.
More information about the devicetree-discuss
mailing list