On 18/10/2024 12:08, Suzuki K Poulose wrote: > 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@xxxxxxx >>>> >>>> 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 ? You mean the filter property in endpoint? if so, then yes. Best regards, Krzysztof
