linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Suzuki.Poulose@arm.com (Suzuki K Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings
Date: Tue, 3 Jul 2018 10:44:13 +0100	[thread overview]
Message-ID: <79d24815-278a-5465-65eb-afd3535236e7@arm.com> (raw)
In-Reply-To: <CAL_Jsq+0kExVY33kdDoR6bAxbr2VzRUzW2j0k+2wmv4CSNVnpQ@mail.gmail.com>

Hi Rob,

On 14/06/18 14:59, Rob Herring wrote:
> On Thu, Jun 14, 2018 at 2:53 AM, Suzuki K Poulose
> <Suzuki.Poulose@arm.com> wrote:
>> On 13/06/18 22:07, Matt Sealey wrote:
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>
>>>>> So, if the suggestion is to use an existing property "unit", I am fine
>>>>> 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
>> for specifying something specific to hardware) instead of "coresight,hwid".
>> I would prefer to stick to the DT graph bindings, because :
> 
> "unit" is not a standard property and I don't like it either.
> 
>>
>> 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,
>> we need information about both the end-points of a connection, which the DT
>> graph bindings solves.
>>
>> All we are missing is a way for specifying the "hardware port" number and
>> the
>> direction of flow. I don't see why do we need to create something new just
>> for
>> these two properties for something that exists today and works reasonably
>> 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 at 0 {
>      reg = <0>;
>      endpoint {...};
>    };
>    port at 1 {
>      reg = <1>;
>      endpoint {...};
>    };
> };
> out-ports {
>    port at 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 ?


Suzuki

  parent reply	other threads:[~2018-07-03  9:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-01 13:15 [RFC PATCH 0/8] coresight: Update device tree bindings Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 1/8] dts: binding: coresight: Document graph bindings Suzuki K Poulose
2018-06-01 16:14   ` Mathieu Poirier
2018-06-01 13:16 ` [RFC PATCH 2/8] coresight: Fix remote endpoint parsing Suzuki K Poulose
2018-06-01 19:38   ` Mathieu Poirier
2018-06-01 19:46     ` Mathieu Poirier
2018-06-04 10:34       ` Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 3/8] coresight: Cleanup platform description data Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 4/8] coresight: platform: Cleanup coresight connection handling Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 5/8] coresight: Handle errors in finding input/output ports Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings Suzuki K Poulose
2018-06-01 20:26   ` Mathieu Poirier
2018-06-12 20:48   ` Rob Herring
2018-06-13  9:45     ` Suzuki K Poulose
2018-06-13 12:49       ` Matt Sealey
2018-06-13 13:35         ` Suzuki K Poulose
2018-06-13 13:57           ` Rob Herring
2018-06-13 15:47           ` Matt Sealey
2018-06-13 17:07             ` Suzuki K Poulose
2018-06-13 19:40               ` Mathieu Poirier
2018-06-13 21:07                 ` Matt Sealey
2018-06-14  8:53                   ` Suzuki K Poulose
2018-06-14 13:59                     ` Rob Herring
2018-06-14 15:04                       ` Matt Sealey
2018-06-15  9:58                       ` Suzuki K Poulose
2018-07-03  9:44                       ` Suzuki K Poulose [this message]
2018-06-01 13:16 ` [RFC PATCH 7/8] dts: coresight: Define new bindings for direction of data flow Suzuki K Poulose
2018-06-01 20:39   ` Mathieu Poirier
2018-06-04 14:20     ` Suzuki K Poulose
2018-06-01 13:16 ` [RFC PATCH 8/8] dts: juno: Update coresight bindings for hw port Suzuki K Poulose
2018-06-01 20:59   ` Mathieu Poirier
2018-06-01 21:04 ` [RFC PATCH 0/8] coresight: Update device tree bindings Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=79d24815-278a-5465-65eb-afd3535236e7@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).