Thread (1 message) 1 message, 1 author, 2012-06-26

Re: Tegra DRM device tree bindings

From: Thierry Reding <hidden>
Date: 2012-06-26 19:27:12
Also in: dri-devel, linux-tegra

Possibly related (same subject, not in this thread)

On Tue, Jun 26, 2012 at 11:41:43AM -0600, Stephen Warren wrote:
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?
quoted
quoted
quoted
Either way is fine for me. The full addresses are more familiar to me as
we tend to use them internally.
quoted
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.
Okay, I'll leave the ranges property as it is now.

Thierry

Attachments

  • (unnamed) [application/pgp-signature] 836 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help