From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <1527858967-16047-1-git-send-email-suzuki.poulose@arm.com> <1527858967-16047-7-git-send-email-suzuki.poulose@arm.com> <20180612204802.GA15817@rob-hp-laptop> <5448BBB7-93FE-400F-9D87-FABF5DE0539C@arm.com> <075b99a1-2a29-f6dc-e9f2-99f895c27d35@arm.com> <5e013d65-9931-6b8d-ce7c-4333309d4ada@arm.com> <79d24815-278a-5465-65eb-afd3535236e7@arm.com> In-Reply-To: <79d24815-278a-5465-65eb-afd3535236e7@arm.com> From: Mathieu Poirier Date: Tue, 3 Jul 2018 10:15:32 -0600 Message-ID: Subject: Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings Content-Type: multipart/alternative; boundary="0000000000003bb44a05701aa02e" To: "Suzuki K. Poulose" Cc: Rob Herring , Matt Sealey , linux-arm-kernel , Sudeep Holla , Mark Rutland , Frank Rowand , Charles Garcia-Tobin , John Horley , Mike Leach , coresight@lists.linaro.org, Linux Kernel Mailing List , devicetree@vger.kernel.org List-ID: --0000000000003bb44a05701aa02e Content-Type: text/plain; charset="UTF-8" On Tue, 3 Jul 2018 at 03:44, Suzuki K Poulose wrote: > Hi Rob, > > On 14/06/18 14:59, Rob Herring wrote: > > On Thu, Jun 14, 2018 at 2:53 AM, Suzuki K Poulose > > wrote: > >> On 13/06/18 22:07, Matt Sealey wrote: > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mathieu Poirier > >>>> > >>>>> 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@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 > --0000000000003bb44a05701aa02e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , 3 Jul 2018 at 03:44, Suzuki K Poulose <Suzuki.Poulose@arm.com> wrote:
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 &= quot;unit", I am fine
>>>>> with it, if people agree to it.
>>>>
>>>>
>>>> If we're going to have something sharply different tha= n 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 "co= resight,hwid".
>> I would prefer to stick to the DT graph bindings, because :
>
> "unit" is not a standard property and I don't like it ei= ther.
>
>>
>> 1) The connections are bi-directional =3D> Well, not necessaril= y
>> bi-directional
>> in terms of the data flow. But the connection information is criti= cal. i.e,
>> we need information about both the end-points of a connection, whi= ch 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 someth= ing new just
>> for
>> these two properties for something that exists today and works rea= sonably
>> 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 {
>=C2=A0 =C2=A0 port@0 {
>=C2=A0 =C2=A0 =C2=A0 reg =3D <0>;
>=C2=A0 =C2=A0 =C2=A0 endpoint {...};
>=C2=A0 =C2=A0 };
>=C2=A0 =C2=A0 port@1 {
>=C2=A0 =C2=A0 =C2=A0 reg =3D <1>;
>=C2=A0 =C2=A0 =C2=A0 endpoint {...};
>=C2=A0 =C2=A0 };
> };
> out-ports {
>=C2=A0 =C2=A0 port@0 {
>=C2=A0 =C2=A0 =C2=A0 reg =3D <0>;
>=C2=A0 =C2=A0 =C2=A0 endpoint {...};
>=C2=A0 =C2=A0 };
> };
>
> I'll need to check, but dtc may need an update to not warn about t= his.
>

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 ?
=C2=A0

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

Thanks,
Mathieu
=C2= =A0
=C2=A0
Suzuki
--0000000000003bb44a05701aa02e--