On 18/10/2024 11:05, Krzysztof Kozlowski wrote:
On 17/10/2024 09:23, Tao Zhang wrote:
On 10/9/2024 6:52 PM, Suzuki K Poulose wrote:
Krzysztof
On 22/08/2024 12:50, Suzuki K Poulose wrote:
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
Please could you let us know if it is acceptable to extend "endpoint" node to have an optional property ?
Hi Krzysztof,
Kindly reminder, could you help comment on this?
I don't have any smart ideas and with earlier explanation sounds ok.
Just to confirm, are you OK with adding a property to the "endpoint" node that will indicate a phandle that the device allows on this endpoint ?
Kind regards Suzuki
Best regards, Krzysztof