Re: [PATCH] Revert "drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/2/23 15:16, Dmitry Baryshkov wrote:
On 02/08/2023 15:07, Marek Vasut wrote:
On 8/2/23 10: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@xxxxxxx>
Cc: Robert Foss <rfoss@xxxxxxxxxx>
Cc: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>
Cc: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
Cc: Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx>
Fixes: 8ddce13ae69 ("drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet")
Reported-by: Amit Pundir <amit.pundir@xxxxxxxxxx>
Link: https://lore.kernel.org/r/CAMi1Hd0TD=2z_=bcDrht3H_wiLvAFcv8Z-U_r_KUOoeMc6UMjw@xxxxxxxxxxxxxx/
Signed-off-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx>

This breaks LT9611 operation on i.MX8M Mini/Nano/Plus, so, NAK.

I am currently using this LT9611 with Linux 6.1.y in production and this is not acceptable. I also believe the correct fix is on the MSM side, not on the LT9611 driver side, since MSM incorrectly implements these flags.

There is no indication that MSM gets these flags wrong.

Let me quote the DSI 1.3 (I think Abhinav already quoted DSI 1.2).

Chapter 8.11.1 Transmission Packet Sequences:

========
If a peripheral timing specification for HBP or HFP minimum period is zero, the corresponding Blanking Packet may be omitted. If the HBP or HFP maximum period is zero, the corresponding blanking packet
shall be omitted.
========

Next, chapter 8.11.2 Non-Burst Mode with Sync Pulses

======
Normally, periods shown as HSA (Horizontal Sync Active), HBP (Horizontal Back Porch) and HFP (Horizontal Front Porch) are filled by Blanking Packets, with lengths (including packet overhead) calculated to match the period specified by the peripheral’s data sheet. Alternatively, if there is sufficient time to transition from HS to LP mode and back again, a timed interval in LP mode may substitute for a Blanking Packet, thus saving power. During HSA, HBP and HFP periods, the bus should stay in the LP-11
state.
========

So, by the spec, sending the HSA / HBP / HFP as blanking packets should always be accepted (and it is the default mode). Switching to LP-11 should be permitted if there is a sufficient time to switch to LP-11 and back. Not sending the packets is only possible if the peripheral (lt9611) says so.

We already know that lt9611 breaks if we try switching to LP-11 during this period. We know that the there is a requirement time for the HSA / HBP / HFP, because the HDMI monitor needs them. Thus, I can only emphasise that the behaviour before the offending patch was correct.

Last, but not least, breaking the in-kernel platform for the out-of-tree peripheral doesn't sound correct.

Except the MX8M support is all in-tree now, so please drop the "out-of-tree" argument. That I am using 6.1.y on those platforms in production makes no difference.

I can only propose the following steps:

1. land the revert to unbreak existing users.

That's just trading breaking one set of users for breaking another set of users.

2. Marek to propose and land the DT bindings & driver change that will enable the workaround for the particular platform (i.MX8m).

Since I have no access to the QCOM hardware or datasheet, can you have a look at the NXP.com MX8M M/N/P datasheets (those are available) and compare their behavior with the QCOM behavior ? I assume you do have the QCOM datasheets available.



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux