Re: [PATCH v3 1/3] dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering

[Suzuki K Poulose]

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@xxxxxxx

Please could you let us know if it is acceptable to extend "endpoint"
node to have an optional property ?

Suzuki


> > Happy to proceed with anything that seems acceptable for you folks.
> >
> > Suzuki
> >
> >
> >
> > > Best regards,
> > > Krzysztof