Re: [PATCH 2/2] 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 19:49, Abhinav Kumar wrote:
Hi Marek

On 8/2/2023 10:25 AM, Marek Vasut wrote:
On 8/2/23 15:08, neil.armstrong@xxxxxxxxxx wrote:
Hi Marek,

On 02/08/2023 14:25, Marek Vasut wrote:
On 8/2/23 10:39, neil.armstrong@xxxxxxxxxx wrote:
Hi Marek,

Hi,

On 13/07/2023 20:28, Marek Vasut wrote:

<snip>


MIPI_DSI_MODE_VIDEO_NO_HFP means the HBP period is just skipped by DSIM.

Maybe there is a need for new set of flags which differentiate between HBP skipped (i.e. NO HBP) and HBP LP11 ?


No, the section of the MIPI DSI spec I posted below clearly states there are two options:

1) send blanking packets during those periods
2) transition to LP11 during those periods

There is no 3rd option in the spec of not doing both like what you are suggesting. So DSIM should also be only transitioning to LP11 during those periods if its not sending the blanking packets with those flags set.

So, there is no need for any new set of flags to differentiate.

The flags and their interpretation is correct in MSM driver. I cannot comment on what exactly DSIM does with those flags.

How do you explain the comment in include/drm/drm_mipi_dsi.h:

128 /* disable hback-porch area */
129 #define MIPI_DSI_MODE_VIDEO_NO_HBP      BIT(6)

Can you specify how you determined those flags were needed on DSIM ? a vendor tree ? a datasheet ?

The following upstream commit:

996e1defca344 ("drm: exynos: dsi: Fix MIPI_DSI*_NO_* mode flags")

In the meantime, we should revert this patch because it regresses some Qcom based platforms until we figure out what's missing to make DSIM based boards
happy.

I'll send a revert change afterwards.

That change would break existing use case on i.MX8M then, I disagree with that revert.

As I understand the timeline is :

- 996e1defca344 was merged in v6.2-rc2 and caused regression on NXP platforms

- 8ddce13ae696 was merged in v6.5-rc1 to fix that but caused regression on QCOM platforms

Did I miss something ?

That looks about right.

I don't know how to handle this apart reverting 8ddce13ae696 and trying to find a proper fix that doesn't regress QCOM.

I provided a suggestion above -- I believe QCOM is misinterpreting the NO_H* flags and it needs separate flags for its behavior. The NXP hardware per MX8M{M,N,P} reference manual (which is available at NXP.com) skips the H* areas in the transfer, which matches the flags description:

include/drm/drm_mipi_dsi.h-/* disable hback-porch area */
include/drm/drm_mipi_dsi.h:#define MIPI_DSI_MODE_VIDEO_NO_HBP   BIT(6)

If the QCOM hardware does something else, it should introduce its own set of flags for that something else and that would be problem solved, for both platforms.

I don't have access to the QCOM hardware or datasheet however, is either available ?


Like I have written above, the DSI spec gives two options which we can do in the HBP/HSA/HFP periods:

1) Transition to LP11 which means blanking packets will not be sent
2) Send blanking packets during those periods

That flag controls exactly that and thats what MSM does.

There is no third option in the spec to not do either.

Now, are you saying that those flags are providing some other third option which is not even there in the DSI spec?

Can you please have a look at the i.MX8M reference manual and read exactly what that controller does , then compare it to the QCOM controller behavior ?



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux