[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <31c5956f-eda9-4084-b080-1192ce1a8192@ti.com>
Date: Fri, 25 Apr 2025 17:12:45 +0530
From: Jayesh Choudhary <j-choudhary@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>, <dianders@...omium.org>,
<andrzej.hajda@...el.com>, <neil.armstrong@...aro.org>,
<rfoss@...nel.org>, <Laurent.pinchart@...asonboard.com>,
<dri-devel@...ts.freedesktop.org>, <tomi.valkeinen@...asonboard.com>
CC: <jonas@...boo.se>, <jernej.skrabec@...il.com>,
<maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
<tzimmermann@...e.de>, <airlied@...il.com>, <simona@...ll.ch>,
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] drm/bridge: ti-sn65dsi86: Enable HPD functionality
Hello Krzysztof,
On 25/04/25 11:04, Krzysztof Kozlowski wrote:
> On 24/04/2025 12:54, Jayesh Choudhary wrote:
>> For TI SoC J784S4, the display pipeline looks like:
>> TIDSS -> CDNS-DSI -> SN65DSI86 -> DisplayConnector -> DisplaySink
>> This requires HPD to detect connection form the connector.
>> By default, the HPD is disabled for eDP. So enable it conditionally
>> based on a new flag 'keep-hpd' as mentioned in the comments in the
>> driver.
>>
>> Signed-off-by: Jayesh Choudhary <j-choudhary@...com>
>> ---
>>
>> Hello All,
>>
>> Sending this RFC patch to get some thoughts on hpd for sn65dsi86.
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
>
> <form letter>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
>
> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> people, so fix your workflow. Tools might also fail if you work on some
> ancient tree (don't, instead use mainline) or work on fork of kernel
> (don't, instead use mainline). Just use b4 and everything should be
> fine, although remember about `b4 prep --auto-to-cc` if you added new
> patches to the patchset.
>
> You missed at least devicetree list (maybe more), so this won't be
> tested by automated tooling. Performing review on untested code might be
> a waste of time.
>
> Please kindly resend and include all necessary To/Cc entries.
> </form letter>
>
> (But if intention was not to get review, then of course it is fine)
>
I might have have taken unwarranted liberty while sending this patch
thinking that it was an RFC PATCH.
I was looking for comments from bridge driver maintainers to see
if this was correct approach or not. It was not ready for bindings
review yet.
This was misjudgement from my end.
(DO-NOT-MERGE tag should have been there I guess..)
I will adhere to proper flow for RFCs as well from here on.
Will resend this properly.
Thanks.
-Jayesh
Powered by blists - more mailing lists