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

Marek Vasut marex at denx.de
Sat Jul 8 19:47:44 UTC 2023


On 7/8/23 21:40, Dmitry Baryshkov wrote:
> On Sat, 8 Jul 2023 at 22:39, Marek Vasut <marex at denx.de> wrote:
>>
>> On 7/8/23 17:53, Dmitry Baryshkov wrote:
>>> On 08/07/2023 18:40, Marek Vasut wrote:
>>>> On 7/7/23 10:47, Neil Armstrong wrote:
>>>>> On 07/07/2023 09:18, Neil Armstrong wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 06/07/2023 11:20, Amit Pundir wrote:
>>>>>>> On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov
>>>>>>> <dmitry.baryshkov at linaro.org> wrote:
>>>>>>>>
>>>>>>>> [Adding freedreno@ to cc list]
>>>>>>>>
>>>>>>>> On Wed, 5 Jul 2023 at 08:31, Jagan Teki
>>>>>>>> <jagan at amarulasolutions.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Amit,
>>>>>>>>>
>>>>>>>>> On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
>>>>>>>>> <amit.pundir at linaro.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Marek,
>>>>>>>>>>
>>>>>>>>>> On Wed, 5 Jul 2023 at 01:48, Marek Vasut <marex at denx.de> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Do not generate the HS front and back porch gaps, the HSA gap and
>>>>>>>>>>> EOT packet, as these packets are not required. This makes the
>>>>>>>>>>> bridge
>>>>>>>>>>> work with Samsung DSIM on i.MX8MM and i.MX8MP.
>>>>>>>>>>
>>>>>>>>>> This patch broke display on Dragonboard 845c (SDM845) devboard
>>>>>>>>>> running
>>>>>>>>>> AOSP. This is what I see
>>>>>>>>>> https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg.
>>>>>>>>>> Reverting this patch fixes this regression for me.
>>>>>>>>>
>>>>>>>>> Might be msm dsi host require proper handling on these updated
>>>>>>>>> mode_flags? did they?
>>>>>>>>
>>>>>>>> The msm DSI host supports those flags. Also, I'd like to point out
>>>>>>>> that the patch didn't change the rest of the driver code. So even if
>>>>>>>> drm/msm ignored some of the flags, it should not have caused the
>>>>>>>> issue. Most likely the issue is on the lt9611 side. I's suspect that
>>>>>>>> additional programming is required to make it work with these flags.
>>>>>>>
>>>>>>> I spent some time today on smoke testing these flags (individually and
>>>>>>> in limited combination) on DB845c, to narrow down this breakage to one
>>>>>>> or more flag(s) triggering it. Here are my observations in limited
>>>>>>> testing done so far.
>>>>>>>
>>>>>>> There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled
>>>>>>> alone and system boots to UI as usual.
>>>>>>>
>>>>>>> MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the
>>>>>>> screenshot[1] shared earlier as well.
>>>>>>>
>>>>>>> Adding either of MIPI_DSI_MODE_VIDEO_NO_HSA and
>>>>>>> MIPI_DSI_MODE_VIDEO_NO_HBP always result in no display, unless paired
>>>>>>> with MIPI_DSI_MODE_VIDEO_NO_HFP and in that case we get the broken
>>>>>>> display as reported.
>>>>>>>
>>>>>>> In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags
>>>>>>> added in this commit break the display on DB845c one way or another.
>>>>>>
>>>>>> I think the investigation would be to understand why samsung-dsim
>>>>>> requires
>>>>>> such flags and/or what are the difference in behavior between MSM
>>>>>> DSI and samsung DSIM
>>>>>> for those flags ?
>>>>>>
>>>>>> If someone has access to the lt9611 datasheet, so it requires
>>>>>> HSA/HFP/HBP to be
>>>>>> skipped ? and does MSM DSI and samsung DSIM skip them in the same way ?
>>>>
>>>> I don't have the LT9611 datasheet, no.
>>>
>>> I also don't have an lt9611 datasheet, unfortunately. I was using the
>>> existing third-party drivers as a source.
>>>
>>>>
>>>> The MX8M DSI (samsung-dsim) skips the HSA/HFP/HBP completely (see
>>>> i.MX8MP RM 13.6.2.7.2 RGB Interface , there is infographics on the
>>>> following pages).
>>>
>>> Do you know, why did you have to disable HPB/HSA/HFP on your platform?
>>> What was the result otherwise?
>>
>> No image on the HDMI monitor at all. This flags change has fixed the
>> problem for multiple other bridges too btw, not just the LT9611, but
>> also TI SN65DSI83 and ICN6211. The flags were likely not set in all
>> those bridge drivers because no DSI host implemented them so far.
> 
> MSM DSI host have had those implemented for ages, but we never needed
> them AFAIR.

The MSM one is exception in more ways than one it seems (in a positive way).


More information about the dri-devel mailing list