[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25f3026f-3d97-a5ac-862a-da6dc5f8d830@denx.de>
Date: Thu, 3 Aug 2023 20:10:10 +0200
From: Marek Vasut <marex@...x.de>
To: Rob Clark <robdclark@...il.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Amit Pundir <amit.pundir@...aro.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Robert Foss <rfoss@...nel.org>,
Jonas Karlman <jonas@...boo.se>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Jernej Skrabec <jernej.skrabec@...il.com>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Jagan Teki <jagan@...rulasolutions.com>
Subject: Re: [PATCH] Revert "drm/bridge: lt9611: Do not generate HFP/HBP/HSA
and EOT packet"
On 8/2/23 20:49, Rob Clark wrote:
> On Wed, Aug 2, 2023 at 11:16 AM Dmitry Baryshkov
> <dmitry.baryshkov@...aro.org> wrote:
>>
>> On Wed, 2 Aug 2023 at 20:34, Marek Vasut <marex@...x.de> wrote:
>>>
>>> On 8/2/23 15:38, Dmitry Baryshkov wrote:
>>>> On 02/08/2023 11:52, Neil Armstrong wrote:
>>>>> This reverts commit [1] to fix display regression on the Dragonboard 845c
>>>>> (SDM845) devboard.
>>>>>
>>>>> There's a mismatch on the real action of the following flags:
>>>>> - MIPI_DSI_MODE_VIDEO_NO_HSA
>>>>> - MIPI_DSI_MODE_VIDEO_NO_HFP
>>>>> - MIPI_DSI_MODE_VIDEO_NO_HBP
>>>>> which leads to a non-working display on qcom platforms.
>>>>>
>>>>> [1] 8ddce13ae696 ("drm/bridge: lt9611: Do not generate HFP/HBP/HSA and
>>>>> EOT packet")
>>>>>
>>>>> Cc: Marek Vasut <marex@...x.de>
>>>>> Cc: Robert Foss <rfoss@...nel.org>
>>>>> Cc: Jagan Teki <jagan@...rulasolutions.com>
>>>>> Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
>>>>> Cc: Abhinav Kumar <quic_abhinavk@...cinc.com>
>>>>> Fixes: 8ddce13ae69 ("drm/bridge: lt9611: Do not generate HFP/HBP/HSA
>>>>> and EOT packet")
>>>>> Reported-by: Amit Pundir <amit.pundir@...aro.org>
>>>>> Link:
>>>>> https://lore.kernel.org/r/CAMi1Hd0TD=2z_=bcDrht3H_wiLvAFcv8Z-U_r_KUOoeMc6UMjw@mail.gmail.com/
>>>>> Signed-off-by: Neil Armstrong <neil.armstrong@...aro.org>
>>>>> ---
>>>>> drivers/gpu/drm/bridge/lontium-lt9611.c | 4 +---
>>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>>
>>>> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@...aro.org> #fix db845c
>>>>
>>>> The boards broken by [1] are used in production by different parties
>>>> since 5.10, breaking them doesn't seem more acceptable than breaking the
>>>> new out-of-tree iMX8m hardware.
>>>
>>> The MX8M is also in-tree, so this does not apply.
>>
>> v6.5-rc4:
>>
>> $ git grep lontium,lt9611 | grep -v 9611uxc
>> Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml:$id:
>> http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>> Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml:
>> - lontium,lt9611
>> Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml:
>> compatible = "lontium,lt9611";
>> arch/arm64/boot/dts/qcom/sdm845-db845c.dts: compatible = "lontium,lt9611";
>> drivers/gpu/drm/bridge/lontium-lt9611.c: { "lontium,lt9611", 0 },
>> drivers/gpu/drm/bridge/lontium-lt9611.c: { .compatible = "lontium,lt9611" },
>>
>> next-20230802:
>>
>> $ git grep lontium,lt9611 | grep -v 9611uxc
>> Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml:$id:
>> http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>> Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml:
>> - lontium,lt9611
>> Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml:
>> compatible = "lontium,lt9611";
>> arch/arm64/boot/dts/qcom/sdm845-db845c.dts: compatible = "lontium,lt9611";
>> drivers/gpu/drm/bridge/lontium-lt9611.c: { "lontium,lt9611", 0 },
>> drivers/gpu/drm/bridge/lontium-lt9611.c: { .compatible = "lontium,lt9611" },
>>
>> Your device is not in the tree. Your commit broke existing users.
>>
>> Can we please end the argument, land the fix (this revert) for 6.5 and
>> work on the solution for 6.6 or 6.7?
>>
>
> Even if they were in-tree, breaking existing hw means revert and
> try-again. Especially as we get into later -rc's
Then just apply the revert, I don't have time to debug this right this
moment, and it is anyway meaningless until I can look at the bus with
DSI bus analyzer.
Powered by blists - more mailing lists