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

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

2023-08-02 Thread 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.armstr...@linaro.org wrote:

Hi Marek,

On 02/08/2023 14:25, Marek Vasut wrote:

On 8/2/23 10:39, neil.armstr...@linaro.org wrote:

Hi Marek,


Hi,


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





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 ?

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

2023-08-02 Thread Abhinav Kumar


Hi Marek

On 8/2/2023 10:25 AM, Marek Vasut wrote:

On 8/2/23 15:08, neil.armstr...@linaro.org wrote:

Hi Marek,

On 02/08/2023 14:25, Marek Vasut wrote:

On 8/2/23 10:39, neil.armstr...@linaro.org wrote:

Hi Marek,


Hi,


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





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?



So, The main issue is around the real meaning of the 
IPI_DSI_MODE_VIDEO_NO_* flags,
Exynos DRM removed the HSA, HBP and HFP packets, Qcom DSI moves the 
DSI lanes

state to LP-11 during the period.

The behavior is significantly different and the naming doesn't suggest 
any

correct behavior.

The only solution is to find out why :
- On Qcom platforms, having the HSA, HBP and HFP periods is OK, but 
not on DSIM

- On DSIM, removing the HSA, HBP and HFP periods is fine
- What's the exact requirement of the lt9611 bridge concerning those 
periods


See above.

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

2023-08-02 Thread Marek Vasut


On 8/2/23 15:08, neil.armstr...@linaro.org wrote:

Hi Marek,

On 02/08/2023 14:25, Marek Vasut wrote:

On 8/2/23 10:39, neil.armstr...@linaro.org wrote:

Hi Marek,


Hi,


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





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 ?


So, The main issue is around the real meaning of the 
IPI_DSI_MODE_VIDEO_NO_* flags,
Exynos DRM removed the HSA, HBP and HFP packets, Qcom DSI moves the DSI 
lanes

state to LP-11 during the period.

The behavior is significantly different and the naming doesn't suggest any
correct behavior.

The only solution is to find out why :
- On Qcom platforms, having the HSA, HBP and HFP periods is OK, but not 
on DSIM

- On DSIM, removing the HSA, HBP and HFP periods is fine
- What's the exact requirement of the lt9611 bridge concerning those 
periods


See above.

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

2023-08-02 Thread neil . armstrong


Hi Marek,

On 02/08/2023 14:25, Marek Vasut wrote:

On 8/2/23 10:39, neil.armstr...@linaro.org wrote:

Hi Marek,


Hi,


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





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 ?

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

So, The main issue is around the real meaning of the IPI_DSI_MODE_VIDEO_NO_* 
flags,
Exynos DRM removed the HSA, HBP and HFP packets, Qcom DSI moves the DSI lanes
state to LP-11 during the period.

The behavior is significantly different and the naming doesn't suggest any
correct behavior.

The only solution is to find out why :
- On Qcom platforms, having the HSA, HBP and HFP periods is OK, but not on DSIM
- On DSIM, removing the HSA, HBP and HFP periods is fine
- What's the exact requirement of the lt9611 bridge concerning those periods

Neil

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

2023-08-02 Thread Marek Vasut


On 8/2/23 10:39, neil.armstr...@linaro.org wrote:

Hi Marek,


Hi,


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





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.

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

2023-08-02 Thread neil . armstrong

Hi Marek,

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

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 ?

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.

Neil

Esp. the "disable" part. That to me reads as "don't send HBP packet".

Where do you see that quote above in the DSI spec (which chapter and which
version do you read) ?

It should be replacing those periods with LP11 too.

The traffic mode being used on this bridge is MIPI_DSI_MODE_VIDEO_SYNC_PULSE which is
"Non-Burst Mode with Sync Pulses".

As per this traffic mode in the DSI spec,

"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 we can either send the blanking packets or transition to LP state and those
3 flags are controlling exactly that during those periods for MSM driver.

If you stop sending the blanking packets, you need to replace that gap with LP.

I don't think that's what MIPI_DSI_MODE_VIDEO_NO_HBP means, the way I
understand MIPI_DSI_MODE_VIDEO_NO_HBP is that it skips the HBP completely. So
if you want HBP, then do not set MIPI_DSI_MODE_VIDEO_NO_HBP . And if you want
LP11 during HBP, that is I think up to the controller (or maybe another new
flag?).

No, there is no need of another new flag. There are only two options as per the
spec.

In fact, as per my checking with more folks, requiring LP11 during those
periods is something very rare.

Because usually horizontal period is usually a very short period, most of the
time we do not use the LP11 option and send the blanking packets instead.

So its something very unusual for DSIM.

That being said, I still think my previous question is important.

1) What is the difference between the resolution you are trying Vs what Amit is
trying?

2) Are you both using just standard HDMI monitors?

What is a "standard HDMI monitor" ?
I use DELL U2713HM .

[...]

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

2023-07-26 Thread Linux regression tracking (Thorsten Leemhuis)

Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.

What's the status wrt to this regression (caused by 8ddce13ae69 from
Marek)? It looks like things are stalled and the regression still is
unresolved, but I ask because I might be missing something.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

On 14.07.23 08:11, Amit Pundir wrote:
> On Thu, 13 Jul 2023 at 23:58, Marek Vasut  wrote:
>>
>> On 7/13/23 20:09, Abhinav Kumar wrote:
>>>
>>>
>>> On 7/12/2023 10:41 AM, Marek Vasut wrote:
 On 7/9/23 03:03, Abhinav Kumar wrote:
>
>
> On 7/7/2023 1:47 AM, 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
  wrote:
>
> [Adding freedreno@ to cc list]
>
> On Wed, 5 Jul 2023 at 08:31, Jagan Teki
>  wrote:
>>
>> Hi Amit,
>>
>> On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
>>  wrote:
>>>
>>> Hi Marek,
>>>
>>> On Wed, 5 Jul 2023 at 01:48, Marek Vasut  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 think there's a mismatch, where on one side this flags sets the
>> link in LP-11 while
>> in HSA/HFP/HPB while on the other it completely removes those
>> blanking packets.
>>
>> The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not
>> LP-11 while HPB.
>> the registers used in both controllers are different:
>> - samsung-dsim: DSIM_HBP_DISABLE_MODE
>> - msm dsi: DSI_VID_CFG0_HBP_POWER_STOP
>>
>> The first one suggest removing the packet, while the second one
>> suggests powering
>> off the line while in the blanking packet period.
>>
>> @Abhinav, can you comment on that ?
>>
>
> I dont get what it means by completely removes blanking packets in DSIM.

 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

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

2023-07-14 Thread Amit Pundir

On Thu, 13 Jul 2023 at 23:58, Marek Vasut  wrote:
>
> On 7/13/23 20:09, Abhinav Kumar wrote:
> >
> >
> > On 7/12/2023 10:41 AM, Marek Vasut wrote:
> >> On 7/9/23 03:03, Abhinav Kumar wrote:
> >>>
> >>>
> >>> On 7/7/2023 1:47 AM, 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
> >>  wrote:
> >>>
> >>> [Adding freedreno@ to cc list]
> >>>
> >>> On Wed, 5 Jul 2023 at 08:31, Jagan Teki
> >>>  wrote:
> 
>  Hi Amit,
> 
>  On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
>   wrote:
> >
> > Hi Marek,
> >
> > On Wed, 5 Jul 2023 at 01:48, Marek Vasut  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 think there's a mismatch, where on one side this flags sets the
>  link in LP-11 while
>  in HSA/HFP/HPB while on the other it completely removes those
>  blanking packets.
> 
>  The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not
>  LP-11 while HPB.
>  the registers used in both controllers are different:
>  - samsung-dsim: DSIM_HBP_DISABLE_MODE
>  - msm dsi: DSI_VID_CFG0_HBP_POWER_STOP
> 
>  The first one suggest removing the packet, while the second one
>  suggests powering
>  off the line while in the blanking packet period.
> 
>  @Abhinav, can you comment on that ?
> 
> >>>
> >>> I dont get what it means by completely removes blanking packets in DSIM.
> >>
> >> 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

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

2023-07-13 Thread Jagan Teki

On Thu, Jul 13, 2023 at 11:39 PM Abhinav Kumar
 wrote:
>
>
>
> On 7/12/2023 10:41 AM, Marek Vasut wrote:
> > On 7/9/23 03:03, Abhinav Kumar wrote:
> >>
> >>
> >> On 7/7/2023 1:47 AM, 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
> >  wrote:
> >>
> >> [Adding freedreno@ to cc list]
> >>
> >> On Wed, 5 Jul 2023 at 08:31, Jagan Teki
> >>  wrote:
> >>>
> >>> Hi Amit,
> >>>
> >>> On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
> >>>  wrote:
> 
>  Hi Marek,
> 
>  On Wed, 5 Jul 2023 at 01:48, Marek Vasut  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 think there's a mismatch, where on one side this flags sets the
> >>> link in LP-11 while
> >>> in HSA/HFP/HPB while on the other it completely removes those
> >>> blanking packets.
> >>>
> >>> The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not
> >>> LP-11 while HPB.
> >>> the registers used in both controllers are different:
> >>> - samsung-dsim: DSIM_HBP_DISABLE_MODE
> >>> - msm dsi: DSI_VID_CFG0_HBP_POWER_STOP
> >>>
> >>> The first one suggest removing the packet, while the second one
> >>> suggests powering
> >>> off the line while in the blanking packet period.
> >>>
> >>> @Abhinav, can you comment on that ?
> >>>
> >>
> >> I dont get what it means by completely removes blanking packets in DSIM.
> >
> > 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.

As many of them know all these flags are generic across controllers
I'm trying to add these flag notations from DSIM controller and how
they handle the driver.

HBP/HFP/HSA mode bits in i.MX8M Mini/Nano/Plus Processor Reference
Manuals specify a naming conversion as 'disable mode bit' due to its

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

2023-07-13 Thread Abhinav Kumar

On 7/13/2023 11:28 AM, Marek Vasut wrote:

On 7/13/23 20:09, Abhinav Kumar wrote:

On 7/12/2023 10:41 AM, Marek Vasut wrote:

On 7/9/23 03:03, Abhinav Kumar wrote:

On 7/7/2023 1:47 AM, 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
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut 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 think there's a mismatch, where on one side this flags sets the
link in LP-11 while
in HSA/HFP/HPB while on the other it completely removes those
blanking packets.

The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not
LP-11 while HPB.

the registers used in both controllers are different:
- samsung-dsim: DSIM_HBP_DISABLE_MODE
- msm dsi: DSI_VID_CFG0_HBP_POWER_STOP

The first one suggest removing the packet, while the second one
suggests powering

off the line while in the blanking packet period.

@Abhinav, can you comment on that ?

I dont get what it means by completely removes blanking packets in
DSIM.

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)

Esp. the "disable" part. That to me reads as "don't send HBP packet".

Yes the LP11 option doesnt send HBP packet. That comment should have
said "Dont send HBP packet and use LP11 instead" to match the spec.

Like I said there are two options:

1) Send the blanking (HBP) packet
2) Dont send the packet and transition to LP11

Thats what those flags are controlling and thats what MSM driver does too.

Where do you see that quote above in the DSI spec (which chapter and
which version do you read) ?

I am referring "8.11.2 Non-Burst Mode with Sync Pulses" of MIPI DSI 1.2
spec ( its slightly old ) but this part doenst change across revisions.

It should be replacing those periods with LP11 too.

The traffic mode being used on this bridge is
MIPI_DSI_MODE_VIDEO_SYNC_PULSE which is "Non-Burst Mode with Sync

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

2023-07-13 Thread Marek Vasut

On 7/13/23 20:09, Abhinav Kumar wrote:

On 7/12/2023 10:41 AM, Marek Vasut wrote:

On 7/9/23 03:03, Abhinav Kumar wrote:

On 7/7/2023 1:47 AM, 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
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut 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 think there's a mismatch, where on one side this flags sets the
link in LP-11 while
in HSA/HFP/HPB while on the other it completely removes those
blanking packets.

The name MIPI_DSI_MODE_VIDEO_NO_HBP suggests removal of HPB, not
LP-11 while HPB.

the registers used in both controllers are different:
- samsung-dsim: DSIM_HBP_DISABLE_MODE
- msm dsi: DSI_VID_CFG0_HBP_POWER_STOP

The first one suggest removing the packet, while the second one
suggests powering

off the line while in the blanking packet period.

@Abhinav, can you comment on that ?

I dont get what it means by completely removes blanking packets in DSIM.

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)

Esp. the "disable" part. That to me reads as "don't send HBP packet".

Where do you see that quote above in the DSI spec (which chapter and
which version do you read) ?

It should be replacing those periods with LP11 too.

The traffic mode being used on this bridge is
MIPI_DSI_MODE_VIDEO_SYNC_PULSE which is "Non-Burst Mode with Sync
Pulses".

As per this traffic mode in the DSI spec,

"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

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

2023-07-13 Thread Abhinav Kumar

On 7/12/2023 10:41 AM, Marek Vasut wrote:

On 7/9/23 03:03, Abhinav Kumar wrote:

On 7/7/2023 1:47 AM, 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
wrote:

[Adding freedreno@ to cc list]

On Wed, 5 Jul 2023 at 08:31, Jagan Teki
wrote:

Hi Amit,

On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir
wrote:

Hi Marek,

On Wed, 5 Jul 2023 at 01:48, Marek Vasut 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?

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.

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 ?