Thread (33 messages) 33 messages, 4 authors, 2018-07-03

Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

From: Mathieu Poirier <mathieu.poirier@linaro.org>
Date: 2018-07-03 16:15:32

On Tue, 3 Jul 2018 at 03:44, Suzuki K Poulose [off-list ref]
wrote:
Hi Rob,

On 14/06/18 14:59, Rob Herring wrote:
quoted
On Thu, Jun 14, 2018 at 2:53 AM, Suzuki K Poulose
[off-list ref] wrote:
quoted
On 13/06/18 22:07, Matt Sealey wrote:
quoted

quoted
-----Original Message-----
From: Mathieu Poirier <mathieu.poirier@linaro.org>
quoted
So, if the suggestion is to use an existing property "unit", I am
fine
quoted
quoted
quoted
quoted
quoted
with it, if people agree to it.

If we're going to have something sharply different than ACPI I prefer
Rob's idea.

No, the above comment is about using "unit" ( if it is a standard
property
quoted
quoted
for specifying something specific to hardware) instead of
"coresight,hwid".
quoted
quoted
I would prefer to stick to the DT graph bindings, because :
"unit" is not a standard property and I don't like it either.
quoted
1) The connections are bi-directional => Well, not necessarily
bi-directional
in terms of the data flow. But the connection information is critical.
i.e,
quoted
quoted
we need information about both the end-points of a connection, which
the DT
quoted
quoted
graph bindings solves.

All we are missing is a way for specifying the "hardware port" number
and
quoted
quoted
the
direction of flow. I don't see why do we need to create something new
just
quoted
quoted
for
these two properties for something that exists today and works
reasonably
quoted
quoted
well
for the usecase.
If you have "in-ports" and "out-ports" nodes, then that gives you
direction and you can use reg for the "hardware port".

in-ports {
   port@0 {
     reg = <0>;
     endpoint {...};
   };
   port@1 {
     reg = <1>;
     endpoint {...};
   };
};
out-ports {
   port@0 {
     reg = <0>;
     endpoint {...};
   };
};

I'll need to check, but dtc may need an update to not warn about this.
I did a quick check with the upstream dtc tool and the above form is
doesn't generate any errors.

Mathieu, Rob,

Shall I proceed with the proposal above ?

Yes - at the very least it will provide a new reference point to work form.

Thanks,
Mathieu

Suzuki
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help