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

[Marek Vasut]

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 at linaro.org wrote:
>>> Hi Marek,
>>>
>>> On 02/08/2023 14:25, Marek Vasut wrote:
>>>> On 8/2/23 10:39, neil.armstrong at linaro.org 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 ?