On 04/06/2024 17:32, Dmitry Baryshkov wrote: > On Tue, Jun 04, 2024 at 05:22:03PM +0200, Krzysztof Kozlowski wrote: >> On 04/06/2024 17:14, Dmitry Baryshkov wrote: >>>>>>>> >>>>>>>> I didnt follow why this is a link property. Sorry , I didnt follow the >>>>>>>> split part. >>>>>>> >>>>>>> There is a link between the DSI host and the panel. I don't want to >>>>>>> end up in a situation when the properties of the link are split >>>>>>> between two different nodes. >>>>>>> >>>>>> >>>>>> It really depends on what the property denotes. I do not think this >>>>>> should be the reason to do it this way. >>>>> >>>>> It denotes how the panel signals DPU that it finished processing the >>>>> data (please excuse me for possibly inaccurate description). However >>>>> there is no direct link between the panel and the DPU. So we should be >>>>> using a link between DSI host and the panel. >>>>> >>>> >>>> Yes, I totally agree that we should be using a link between DSI host and the >>>> panel. >>>> >>>> My question from the beginning has been why the output port? >>>> >>>> It looks like to me we need to have another input port to the controller >>>> then? >>>> >>>> One from DPU and the other from panel? >>> >>> Dear DT maintainers, could you please comment on the OF graph entries? >>> Are they considered to be unidirectional or bidirectional? >>> >>> Would you suggest adding another arc to the OF graph in our case or is >>> it fine to have a signal generated by the panel in the 'panel_in' port? >> >> Which pin are we talking about? DSI or panel? Commit msg suggests DSI, >> so property is in DSI node part. Seems logical to me. > > Input pin on the DSI side. So adding it to panel schema is not even possible thus I am not sure if we discuss this option (maybe not, because it would be odd, considering you got Rb tag!). Adding some input node to DSI connecting panel output and DSI input... for what? I mean, what sort of data would it represent? Best regards, Krzysztof
