[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53ec46af-3438-44e0-82b2-9432fc7f0fcb@arm.com>
Date: Thu, 22 Aug 2024 12:50:19 +0100
From: Suzuki K Poulose <suzuki.poulose@....com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Tao Zhang <quic_taozha@...cinc.com>, Mike Leach <mike.leach@...aro.org>,
James Clark <james.clark@....com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Mathieu Poirier <mathieu.poirier@...aro.org>,
Leo Yan <leo.yan@...ux.dev>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v3 1/3] dt-bindings: arm:
qcom,coresight-static-replicator: Add property for source filtering
On 22/08/2024 11:34, Suzuki K Poulose wrote:
> On 22/08/2024 08:08, Krzysztof Kozlowski wrote:
>> On Wed, Aug 21, 2024 at 11:38:55AM +0100, Suzuki K Poulose wrote:
>>> On 21/08/2024 04:13, Tao Zhang wrote:
>>>> The is some "magic" hard coded filtering in the replicators,
>>>> which only passes through trace from a particular "source". Add
>>>> a new property "filter-src" to label a phandle to the coresight
>>>> trace source device matching the hard coded filtering for the port.
>>>
>>> Minor nit: Please do not use abbreviate "source" in the bindings.
>>> I am not an expert on other changes below and will leave it to
>>> Rob/Krzysztof to comment.
>>>
>>> Rob, Krzysztof,
>>>
>>> We need someway to "link" (add a phandle) from a "port". The patch below
>>> is extending "standard" port to add a phandle. Please let us know if
>>> there is a better way.
>>>
>>> e.g.:
>>>
>>> filters = list of tuples of port, phandle. ?
>>>
>>> e.g.:
>>>
>>> filters = < 0, <&tpdm_video>,
>>> 1, <&tpdm_mdss>
>>> >
>>>
>>
>> Current solution feels like band-aid - what if next time you need some
>> second filter? Or "wall"? Or whatever? Next property?
>
>
>
>>
>> Isn't filter just one endpoint in the graph?
>>
>> A <--> filter <--> B
>
> To be more precise, "Filter" is a "port (p0, p1, p2 below)" (among a
> multi output ports).
>
> For clearer example:
>
> A0 <--> .. <--> ..\ p0 / --> Filtered for (A1) <--> B1
> A1 <--> .. <--> .. - < L(filters> p1 - --> Filtered for (A2) <--> B2
> A2 <--> .. <--> ../ p2 \ --> Unfiltered <--> B0
>
>
>
>> Instead of
>>
>> A <----through-filter----> B?
>
> The problem is we need to know the components in the path from A0 to X
> through, (Not just A0 and L). And also we need to know "which port (p0
> vs p1 vs p2)" does the traffic take from a source (A0/A1/A2) out of the
> link "L".
>
> So ideally, we need a way to tie p0 -> A1, p1 -> A2.
>
> would we need something else in the future ? I don't know for sure.
> People could design their own things ;-). But this was the first time
> ever in the last 12yrs since we supported coresight in the kernel.
> (there is always a first time).
>
> Fundamentally, the "ports" cannot have additional properties today.
> Not sure if there are other usecases (I don't see why). So, we have
> to manually extend like above, which I think is not nice.
Replying to the other thread [0], made me realize that the above is not
true. Indeed it is possible to add properties for endpoints, e.g:
e.g.: media/video-interfaces.yaml
So extending the endpoint node is indeed acceptable (unlike I thought).
May be the we it is achieved in this patch is making it look otherwise.
Suzuki
[0] https://lkml.kernel.org/r/4b51d5a9-3706-4630-83c1-01b01354d9a4@arm.com
>
> Happy to proceed with anything that seems acceptable for you folks.
>
> Suzuki
>
>
>
>>
>> Best regards,
>> Krzysztof
>>
>
Powered by blists - more mailing lists