From: Krzysztof Kozlowski <krzk@kernel.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Krishna Manikandan <quic_mkrishn@quicinc.com>,
linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/7] dt-bindings: display/msm/dsi: allow specifying TE source
Date: Wed, 5 Jun 2024 08:58:55 +0200 [thread overview]
Message-ID: <c678c35d-9695-44c7-96ac-a7ce5fffba16@kernel.org> (raw)
In-Reply-To: <a380d953-a920-6cb1-3464-9aa925561393@quicinc.com>
On 04/06/2024 19:52, Abhinav Kumar wrote:
>
>
> On 6/4/2024 8:36 AM, Krzysztof Kozlowski wrote:
>> 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?
>>
>
> TE pin is an input signal from the panel to the DSI host.
>
> Today we have two ports in the DSI host node:
>
> 1) input to DSI node from DPU. This represents the pixel stream from DPU
> to DSI
>
> 2) DSI output node to represent pixel stream from DSI host to panel in
>
> Now, please explain to me how does TE pin belongs to (2) because thats
> where this property has been added.
Don't get what is a DPU, but anyway connections are kind of
bi-directional. So TE belongs there because this is the connection
between the DSI and the panel, with generic meaning that data flows from
the DSI to the panel.
Why we keep discussing this? You really need 3rd ack or this is just
bikeschedding?
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-06-05 6:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 12:12 [PATCH 0/7] drm/msm/dpu: handle non-default TE source pins Dmitry Baryshkov
2024-05-20 12:12 ` [PATCH 1/7] dt-bindings: display/msm/dsi: allow specifying TE source Dmitry Baryshkov
2024-05-22 14:45 ` Rob Herring
2024-05-22 18:38 ` Abhinav Kumar
2024-05-22 20:05 ` Dmitry Baryshkov
2024-05-22 23:57 ` Abhinav Kumar
2024-05-23 9:58 ` Dmitry Baryshkov
2024-05-29 22:57 ` Abhinav Kumar
2024-05-30 0:02 ` Dmitry Baryshkov
2024-05-30 1:08 ` Abhinav Kumar
2024-06-04 15:14 ` Dmitry Baryshkov
2024-06-04 15:22 ` Krzysztof Kozlowski
2024-06-04 15:32 ` Dmitry Baryshkov
2024-06-04 15:36 ` Krzysztof Kozlowski
2024-06-04 17:52 ` Abhinav Kumar
2024-06-05 6:58 ` Krzysztof Kozlowski [this message]
2024-06-04 15:41 ` Krzysztof Kozlowski
2024-05-20 12:12 ` [PATCH 2/7] drm/msm/dpu: convert vsync source defines to the enum Dmitry Baryshkov
2024-05-22 18:41 ` Abhinav Kumar
2024-05-22 20:01 ` Dmitry Baryshkov
2024-05-22 23:57 ` Abhinav Kumar
2024-05-20 12:12 ` [PATCH 3/7] drm/msm/dsi: drop unused GPIOs handling Dmitry Baryshkov
2024-05-22 18:44 ` Abhinav Kumar
2024-05-20 12:12 ` [PATCH 4/7] drm/msm/dpu: pull the is_cmd_mode out of _dpu_encoder_update_vsync_source() Dmitry Baryshkov
2024-05-22 18:46 ` Abhinav Kumar
2024-05-20 12:12 ` [PATCH 5/7] drm/msm/dpu: rework vsync_source handling Dmitry Baryshkov
2024-05-22 19:07 ` Abhinav Kumar
2024-05-20 12:12 ` [PATCH 6/7] drm/msm/dsi: parse vsync source from device tree Dmitry Baryshkov
2024-05-29 23:01 ` Abhinav Kumar
2024-05-20 12:12 ` [PATCH 7/7] drm/msm/dpu: support setting the TE source Dmitry Baryshkov
2024-05-22 18:39 ` [PATCH 0/7] drm/msm/dpu: handle non-default TE source pins Abhinav Kumar
2024-05-22 19:59 ` Dmitry Baryshkov
2024-05-29 23:11 ` Abhinav Kumar
2024-05-29 23:55 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c678c35d-9695-44c7-96ac-a7ce5fffba16@kernel.org \
--to=krzk@kernel.org \
--cc=airlied@gmail.com \
--cc=conor+dt@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_mkrishn@quicinc.com \
--cc=robdclark@gmail.com \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).