drm/msm/dsi: hs_zero timing

drm/msm/dsi: hs_zero timing

[Johansson, Werner]

Hi,

In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly divisible by 8 - this will cause the DSI output to misbehave (typically leading to black screen). On the three panels I've tested I have different "unknown integers" which I can't immediately derive from the rest of the PHY timings:

(PHY timing debug output in this order: clk_pre, clk_post, clk_zero, clk_trail, clk_prepare, hs_exit, hs_zero, hs_prepare, hs_trail, hs_rqst)

Panasonic VVX panel (WUXGA): PHY timings: 47, 2, 259, 62, 42, 112, 118, 46, 66, 51 hs_zero calculated value of 118 does not work (neither does anything <74, 78, 86, 94, 102, 110, 126, 134, 142, 150, 158, 166, 174, 182, 190, 198, 206, 214, 222, 230, 238, 246, 254)

Sharp (1080p) on Xperia Z3: PHY timings: 44, 2, 238, 56, 38, 104, 110, 42, 60, 44 hs_zero calculated value of 110 works fine here but 104, 112, 120 and the remaining multiples of 8 does not.

Sharp (qHD) on Dragonboard 800: PHY timings: 28, 4, 139, 30, 20, 68, 72, 24, 34, 25 hs_zero calculated value of 72 works fine but 62, 70, 78, 86 and the remaining multiples of 8 does not.

hs_trail looked promising at first: a bad hs_zero value + hs_trail would be evenly divisible by 8 for Panasonic and the 1080p Sharp panel but not for the Sharp qHD display, and adjusting hs_trail did not solve the issue.

However, setting all the lane adjust values for hs_zero to 0 solves the problem for the troublesome WUXGA panel timing and does not create any apparent downsides for the other two.

Does anyone know of a reason this skew is implemented? If it is indeed needed in some cases would a move to DT instead of leaving it hard-coded make sense?

Thanks for any input!

/wj

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Hai Li]

Hi Werner,

When I made DSI changes, I tried to limit the information in DT (like our downstream driver), until there is a case driver really cannot figure it out by the existing information.
I think this is the requirement of upstream kernel.

If we see a panel requires different value in PHY_LN_CFG_4(x) register and cannot derive it from any other timings, we could think about adding it into DT.

Also, I am wondering if this Panasonic WUXGA panel works with downstream driver, since I see the same hardcoded values set for all the panels.


Thanks,
Hai

-----Original Message-----
From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Johansson, Werner
Sent: Friday, August 21, 2015 2:27 PM
To: dri-devel@lists.freedesktop.org
Subject: drm/msm/dsi: hs_zero timing

Hi,

In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly divisible by 8 - this will cause the DSI output to misbehave (typically leading to black screen). On the three panels I've tested I have different "unknown integers" which I can't immediately derive from the rest of the PHY timings:

(PHY timing debug output in this order: clk_pre, clk_post, clk_zero, clk_trail, clk_prepare, hs_exit, hs_zero, hs_prepare, hs_trail, hs_rqst)

Panasonic VVX panel (WUXGA): PHY timings: 47, 2, 259, 62, 42, 112, 118, 46, 66, 51 hs_zero calculated value of 118 does not work (neither does anything <74, 78, 86, 94, 102, 110, 126, 134, 142, 150, 158, 166, 174, 182, 190, 198, 206, 214, 222, 230, 238, 246, 254)

Sharp (1080p) on Xperia Z3: PHY timings: 44, 2, 238, 56, 38, 104, 110, 42, 60, 44 hs_zero calculated value of 110 works fine here but 104, 112, 120 and the remaining multiples of 8 does not.

Sharp (qHD) on Dragonboard 800: PHY timings: 28, 4, 139, 30, 20, 68, 72, 24, 34, 25 hs_zero calculated value of 72 works fine but 62, 70, 78, 86 and the remaining multiples of 8 does not.

hs_trail looked promising at first: a bad hs_zero value + hs_trail would be evenly divisible by 8 for Panasonic and the 1080p Sharp panel but not for the Sharp qHD display, and adjusting hs_trail did not solve the issue.

However, setting all the lane adjust values for hs_zero to 0 solves the problem for the troublesome WUXGA panel timing and does not create any apparent downsides for the other two.

Does anyone know of a reason this skew is implemented? If it is indeed needed in some cases would a move to DT instead of leaving it hard-coded make sense?

Thanks for any input!

/wj

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Johansson, Werner]

> From: Hai Li [mailto:hali@codeaurora.org]
> Sent: den 21 augusti 2015 12:56
> 
> When I made DSI changes, I tried to limit the information in DT (like
> our downstream driver), until there is a case driver really cannot
> figure it out by the existing information.
> I think this is the requirement of upstream kernel.
> 
> If we see a panel requires different value in PHY_LN_CFG_4(x) register
> and cannot derive it from any other timings, we could think about
> adding it into DT.

Not sure how these skew values can be determined from the rest of the timing? Am I correct in my understanding that these registers would compensate for differences in physical length of the dsi lanes, or are they designed for a different purpose? The documentation is very vague on this point. Adjusting the values down to the default zero still works fine on the other panels (and enabled the Panasonic panel to work properly too).

> Also, I am wondering if this Panasonic WUXGA panel works with
> downstream driver, since I see the same hardcoded values set for all
> the panels.

We have the Panasonic WUXGA panel working with the downstream driver (it's shipping in our Xperia Z2 tablets). The problem with our shipping kernel is that the timing values are derived from the Qualcomm Excel sheet and then hardcoded (in DT), the timing is not calculated on the fly as is the case here. It's very easy to just modify hs_zero value up or down one notch manually when having the timing hardcoded, but such a solution is certainly not generic.

Thanks!
/wj
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Rob Clark]

On Fri, Aug 21, 2015 at 4:38 PM, Johansson, Werner
<Werner.Johansson@sonymobile.com> wrote:
>> From: Hai Li [mailto:hali@codeaurora.org]
>> Sent: den 21 augusti 2015 12:56
>>
>> When I made DSI changes, I tried to limit the information in DT (like
>> our downstream driver), until there is a case driver really cannot
>> figure it out by the existing information.
>> I think this is the requirement of upstream kernel.
>>
>> If we see a panel requires different value in PHY_LN_CFG_4(x) register
>> and cannot derive it from any other timings, we could think about
>> adding it into DT.
>
> Not sure how these skew values can be determined from the rest of the timing? Am I correct in my understanding that these registers would compensate for differences in physical length of the dsi lanes, or are they designed for a different purpose? The documentation is very vague on this point. Adjusting the values down to the default zero still works fine on the other panels (and enabled the Panasonic panel to work properly too).
>

fwiw, if the values are related to the physical cabling/wiring, rather
than the panel timing, we should probably get them from DT..

if a combination of the timing and the wiring, that gets a bit more complicated

(I am not actually sure myself about these)

BR,
-R

>> Also, I am wondering if this Panasonic WUXGA panel works with
>> downstream driver, since I see the same hardcoded values set for all
>> the panels.
>
> We have the Panasonic WUXGA panel working with the downstream driver (it's shipping in our Xperia Z2 tablets). The problem with our shipping kernel is that the timing values are derived from the Qualcomm Excel sheet and then hardcoded (in DT), the timing is not calculated on the fly as is the case here. It's very easy to just modify hs_zero value up or down one notch manually when having the timing hardcoded, but such a solution is certainly not generic.
>
> Thanks!
> /wj
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Werner Johansson]

On Sat, Aug 22, 2015 at 6:25 AM, Rob Clark <robdclark@gmail.com> wrote:
>
> fwiw, if the values are related to the physical cabling/wiring, rather
> than the panel timing, we should probably get them from DT..
>
> if a combination of the timing and the wiring, that gets a bit more complicated
>
> (I am not actually sure myself about these)

Right, I don't see it being possible to calculate the timing
differences between lanes from any panel mode timing. There are some
dependencies to the length of calculated hs_zero and hs_prepare
values, depending on how these per-lane adjustments are setup, but it
would be safe to assume that if the per-lane values need tweaking
(from DT possibly) then you would have to know the details of the DSI
timing anyway, so that shouldn't pose much of a problem.

The description of the 5 bits in the CFG4 register isn't entirely
clear, the value in bit 0-3, possibly scaled by a factor of 16(?), has
to be less than the hs_prepare register if bit 4 is set or less than
the hs_zero register if bit 4 is clear.

/wj
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Hai Li]

Hi Werner,

Yes, the register is to adjust hs_zero.
Could you share the panel's video timing and dphy timings (or the panel DT), used by downstream driver?

The dphy timing calculations in the phy driver are from the excel sheet as well, I can check if there is any issue inside the calculation code making the difference.


Thanks,
Hai

-----Original Message-----
From: Rob Clark [mailto:robdclark@gmail.com] 
Sent: Saturday, August 22, 2015 9:25 AM
To: Johansson, Werner
Cc: Hai Li; dri-devel@lists.freedesktop.org
Subject: Re: drm/msm/dsi: hs_zero timing

On Fri, Aug 21, 2015 at 4:38 PM, Johansson, Werner <Werner.Johansson@sonymobile.com> wrote:
>> From: Hai Li [mailto:hali@codeaurora.org]
>> Sent: den 21 augusti 2015 12:56
>>
>> When I made DSI changes, I tried to limit the information in DT (like 
>> our downstream driver), until there is a case driver really cannot 
>> figure it out by the existing information.
>> I think this is the requirement of upstream kernel.
>>
>> If we see a panel requires different value in PHY_LN_CFG_4(x) ga
>> register and cannot derive it from any other timings, we could think 
>> about adding it into DT.
>
> Not sure how these skew values can be determined from the rest of the timing? Am I correct in my understanding that these registers would compensate for differences in physical length of the dsi lanes, or are they designed for a different purpose? The documentation is very vague on this point. Adjusting the values down to the default zero still works fine on the other panels (and enabled the Panasonic panel to work properly too).
>

fwiw, if the values are related to the physical cabling/wiring, rather than the panel timing, we should probably get them from DT..

if a combination of the timing and the wiring, that gets a bit more complicated

(I am not actually sure myself about these)

BR,
-R

>> Also, I am wondering if this Panasonic WUXGA panel works with 
>> downstream driver, since I see the same hardcoded values set for all 
>> the panels.
>
> We have the Panasonic WUXGA panel working with the downstream driver (it's shipping in our Xperia Z2 tablets). The problem with our shipping kernel is that the timing values are derived from the Qualcomm Excel sheet and then hardcoded (in DT), the timing is not calculated on the fly as is the case here. It's very easy to just modify hs_zero value up or down one notch manually when having the timing hardcoded, but such a solution is certainly not generic.
>
> Thanks!
> /wj
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Werner Johansson]

On Mon, Aug 24, 2015 at 7:32 AM, Hai Li <hali@codeaurora.org> wrote:
> Hi Werner,
>
> Yes, the register is to adjust hs_zero.
> Could you share the panel's video timing and dphy timings (or the panel DT), used by downstream driver?
>
> The dphy timing calculations in the phy driver are from the excel sheet as well, I can check if there is any issue inside the calculation code making the difference.
>
>
> Thanks,
> Hai

Hi Hai,

Yes definitely, our downstream DT definitions for the Panasonic panel
looks like this: (taken from our kernel available here:
https://github.com/sonyxperiadev/kernel-copyleft/blob/23.1.A.1.xxx/arch/arm/boot/dts/dsi-panel-castor.dtsi#L78-L145)

dsi_novatek_panasonic_wuxga_vid: somc,novatek_panasonic_wuxga_panel {
qcom,mdss-dsi-panel-name = "panasonic novatek wuxga video";
qcom,mdss-dsi-panel-controller = <&mdss_dsi0>;
qcom,mdss-dsi-panel-type = "dsi_video_mode";
qcom,mdss-dsi-panel-destination = "display_1";
qcom,mdss-dsi-panel-framerate = <60>;
qcom,mdss-dsi-virtual-channel-id = <0>;
qcom,mdss-dsi-stream = <0>;
qcom,mdss-dsi-panel-width = <1920>;
qcom,mdss-dsi-panel-height = <1200>;
qcom,mdss-dsi-h-front-porch = <152>;
qcom,mdss-dsi-h-back-porch = <20>;
qcom,mdss-dsi-h-pulse-width = <52>;
qcom,mdss-dsi-h-sync-skew = <0>;
qcom,mdss-dsi-v-back-porch = <48>;
qcom,mdss-dsi-v-front-porch = <24>;
qcom,mdss-dsi-v-pulse-width = <6>;
qcom,mdss-dsi-h-left-border = <0>;
qcom,mdss-dsi-h-right-border = <0>;
qcom,mdss-dsi-v-top-border = <0>;
qcom,mdss-dsi-v-bottom-border = <0>;
qcom,mdss-dsi-bpp = <24>;
qcom,mdss-dsi-underflow-color = <0x0>;
qcom,mdss-dsi-border-color = <0>;
qcom,mdss-dsi-on-command = [32 01 00 00 00 00 02 00 00];
qcom,mdss-dsi-on-command-state = "dsi_lp_mode";
qcom,mdss-dsi-h-sync-pulse = <1>;
qcom,mdss-dsi-traffic-mode = "non_burst_sync_event";
qcom,mdss-dsi-bllp-eof-power-mode;
qcom,mdss-dsi-bllp-power-mode;
qcom,mdss-dsi-lane-0-state;
qcom,mdss-dsi-lane-1-state;
qcom,mdss-dsi-lane-2-state;
qcom,mdss-dsi-lane-3-state;
qcom,mdss-dsi-panel-timings = [FB 3E 2A 00 70 74 2E 42 33 03 04 00];
qcom,mdss-dsi-t-clk-post = <0x02>;
qcom,mdss-dsi-t-clk-pre = <0x2E>;
qcom,mdss-dsi-bl-min-level = <1>;
qcom,mdss-dsi-bl-max-level = <255>;
qcom,mdss-brightness-max-level = <255>;
qcom,mdss-dsi-dma-trigger = "trigger_sw";
qcom,mdss-dsi-mdp-trigger = "none";
qcom,mdss-dsi-bl-pmic-control-type = "bl_ctrl_wled";
qcom,mdss-dsi-pan-enable-dynamic-fps;
qcom,mdss-dsi-pan-fps-update = "dfps_suspend_resume_mode";
qcom,cont-splash-enabled;
qcom,mdss-dsi-tx-eot-append;
somc,driver-ic = <3>;
somc,dric-gpio = <&msmgpio 26 0>;
somc,mul-channel-scaling = <3>;
somc,mdss-phy-size-mm = <217 135>;
somc,mdss-dsi-lane-config = [00 c2 ef 00 00 00 00 01 ff
00 c2 ef 00 00 00 00 01 ff
00 c2 ef 00 00 00 00 01 ff
00 c2 ef 00 00 00 00 01 ff
00 02 00 00 00 00 00 01 97];
somc,lcd-id = <1>;
somc,lcd-id-adc = <801000 917000>;
somc,disp-en-on-post = <251>;
somc,disp-en-off-pre = <86>;
somc,pw-down-period = <500>;
somc,mdss-dsi-uv-param-type = <0>;
somc,mdss-dsi-pcc-table-size = <1>;
somc,mdss-dsi-pcc-table = <
0x00 0x01 0x1C 0x1F 0x1C 0x1F 0x8000 0x8000 0x7D80>;
};

/wj
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Hai Li]

Hi Werner,

Thanks for sharing this. The DPHY timings in downstream dtsi are exactly the same as the excel calculation, but slightly different from the output of drm code as you posted. (e.g hs_zero is 116 vs 118)
I think it is caused by some precision loss during driver calculation, but I need to double check.

Could you help to try configuring the same DPHY timings as downstream, but leave the values in  DSIPHY_LNx_CFG4 as is, to see if it works?

This could help us to narrow down the issue.


Thanks,
Hai

-----Original Message-----
From: Werner Johansson [mailto:werner.johansson@gmail.com] 
Sent: Monday, August 24, 2015 9:24 PM
To: Hai Li
Cc: Rob Clark; Johansson, Werner; dri-devel@lists.freedesktop.org
Subject: Re: drm/msm/dsi: hs_zero timing

On Mon, Aug 24, 2015 at 7:32 AM, Hai Li <hali@codeaurora.org> wrote:
> Hi Werner,
>
> Yes, the register is to adjust hs_zero.
> Could you share the panel's video timing and dphy timings (or the panel DT), used by downstream driver?
>
> The dphy timing calculations in the phy driver are from the excel sheet as well, I can check if there is any issue inside the calculation code making the difference.
>
>
> Thanks,
> Hai

Hi Hai,

Yes definitely, our downstream DT definitions for the Panasonic panel looks like this: (taken from our kernel available here:
https://github.com/sonyxperiadev/kernel-copyleft/blob/23.1.A.1.xxx/arch/arm/boot/dts/dsi-panel-castor.dtsi#L78-L145)

dsi_novatek_panasonic_wuxga_vid: somc,novatek_panasonic_wuxga_panel { qcom,mdss-dsi-panel-name = "panasonic novatek wuxga video"; qcom,mdss-dsi-panel-controller = <&mdss_dsi0>; qcom,mdss-dsi-panel-type = "dsi_video_mode"; qcom,mdss-dsi-panel-destination = "display_1"; qcom,mdss-dsi-panel-framerate = <60>; qcom,mdss-dsi-virtual-channel-id = <0>; qcom,mdss-dsi-stream = <0>; qcom,mdss-dsi-panel-width = <1920>; qcom,mdss-dsi-panel-height = <1200>; qcom,mdss-dsi-h-front-porch = <152>; qcom,mdss-dsi-h-back-porch = <20>; qcom,mdss-dsi-h-pulse-width = <52>; qcom,mdss-dsi-h-sync-skew = <0>; qcom,mdss-dsi-v-back-porch = <48>; qcom,mdss-dsi-v-front-porch = <24>; qcom,mdss-dsi-v-pulse-width = <6>; qcom,mdss-dsi-h-left-border = <0>; qcom,mdss-dsi-h-right-border = <0>; qcom,mdss-dsi-v-top-border = <0>; qcom,mdss-dsi-v-bottom-border = <0>; qcom,mdss-dsi-bpp = <24>; qcom,mdss-dsi-underflow-color = <0x0>; qcom,mdss-dsi-border-color = <0>; qcom,mdss-dsi-on-command = [32 01 00 00 00 00 02 00 00]; qcom,mdss-dsi-on-command-state = "dsi_lp_mode"; qcom,mdss-dsi-h-sync-pulse = <1>; qcom,mdss-dsi-traffic-mode = "non_burst_sync_event"; qcom,mdss-dsi-bllp-eof-power-mode;
qcom,mdss-dsi-bllp-power-mode;
qcom,mdss-dsi-lane-0-state;
qcom,mdss-dsi-lane-1-state;
qcom,mdss-dsi-lane-2-state;
qcom,mdss-dsi-lane-3-state;
qcom,mdss-dsi-panel-timings = [FB 3E 2A 00 70 74 2E 42 33 03 04 00]; qcom,mdss-dsi-t-clk-post = <0x02>; qcom,mdss-dsi-t-clk-pre = <0x2E>; qcom,mdss-dsi-bl-min-level = <1>; qcom,mdss-dsi-bl-max-level = <255>; qcom,mdss-brightness-max-level = <255>; qcom,mdss-dsi-dma-trigger = "trigger_sw"; qcom,mdss-dsi-mdp-trigger = "none"; qcom,mdss-dsi-bl-pmic-control-type = "bl_ctrl_wled"; qcom,mdss-dsi-pan-enable-dynamic-fps;
qcom,mdss-dsi-pan-fps-update = "dfps_suspend_resume_mode"; qcom,cont-splash-enabled; qcom,mdss-dsi-tx-eot-append; somc,driver-ic = <3>; somc,dric-gpio = <&msmgpio 26 0>; somc,mul-channel-scaling = <3>; somc,mdss-phy-size-mm = <217 135>; somc,mdss-dsi-lane-config = [00 c2 ef 00 00 00 00 01 ff
00 c2 ef 00 00 00 00 01 ff
00 c2 ef 00 00 00 00 01 ff
00 c2 ef 00 00 00 00 01 ff
00 02 00 00 00 00 00 01 97];
somc,lcd-id = <1>;
somc,lcd-id-adc = <801000 917000>;
somc,disp-en-on-post = <251>;
somc,disp-en-off-pre = <86>;
somc,pw-down-period = <500>;
somc,mdss-dsi-uv-param-type = <0>;
somc,mdss-dsi-pcc-table-size = <1>;
somc,mdss-dsi-pcc-table = <
0x00 0x01 0x1C 0x1F 0x1C 0x1F 0x8000 0x8000 0x7D80>; };

/wj

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 951 bytes --]

On Aug 26, 2015 08:34, "Hai Li" <hali@codeaurora.org> wrote:
>
> Hi Werner,
>
> Thanks for sharing this. The DPHY timings in downstream dtsi are exactly
the same as the excel calculation, but slightly different from the output
of drm code as you posted. (e.g hs_zero is 116 vs 118)
> I think it is caused by some precision loss during driver calculation,
but I need to double check.
>
> Could you help to try configuring the same DPHY timings as downstream,
but leave the values in  DSIPHY_LNx_CFG4 as is, to see if it works?

116 to hs_zero works fine without any other changes (only 118 and every
eighth number up and down from there fails with this panel timing), so if
we can do something to make sure we hit a working value for hs_zero without
touching anything else that would be great!

Thanks for checking the timings and let me know if you want me to test
anything else. Is the excel formula considered public so we can discuss it
here?

/wj

[-- Attachment #1.2: Type: text/html, Size: 1148 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Rob Clark]

On Wed, Aug 26, 2015 at 1:39 PM, Werner Johansson
<werner.johansson@gmail.com> wrote:
>
> On Aug 26, 2015 08:34, "Hai Li" <hali@codeaurora.org> wrote:
>>
>> Hi Werner,
>>
>> Thanks for sharing this. The DPHY timings in downstream dtsi are exactly
>> the same as the excel calculation, but slightly different from the output of
>> drm code as you posted. (e.g hs_zero is 116 vs 118)
>> I think it is caused by some precision loss during driver calculation, but
>> I need to double check.
>>
>> Could you help to try configuring the same DPHY timings as downstream, but
>> leave the values in  DSIPHY_LNx_CFG4 as is, to see if it works?
>
> 116 to hs_zero works fine without any other changes (only 118 and every
> eighth number up and down from there fails with this panel timing), so if we
> can do something to make sure we hit a working value for hs_zero without
> touching anything else that would be great!
>
> Thanks for checking the timings and let me know if you want me to test
> anything else. Is the excel formula considered public so we can discuss it
> here?

btw, w/ some of these clk rounding issues, I suspect we need 'struct
drm_display_mode' to be able to represent mode clock with greater
accuracy than Khz..

The good news is that drm_display_mode is not part of userspace ABI
(although drm_mode_modeinfo is.. and that is one path to populate
drm_display_mode)..  The bad news is that either way,
drm_display_mode::clock is referenced in *many* places.

Maybe we could add a new field to drm_display_mode to hold remainder
in Hz, and driver just take that field from panel (and ignore whatever
userspace may pass in)??

BR,
-R


> /wj
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Hai Li]

[-- Attachment #1.1: Type: text/plain, Size: 1435 bytes --]

Thanks Werner to test it out. I will focus on the dphy timing calculation then.

 

It’s better to avoid discussing the excel formula publicly. :)

 

 

Thanks,

Hai

 

From: Werner Johansson [mailto:werner.johansson@gmail.com] 
Sent: Wednesday, August 26, 2015 1:39 PM
To: Hai Li
Cc: Rob Clark; werner.johansson@sonymobile.com; dri-devel@lists.freedesktop.org
Subject: RE: drm/msm/dsi: hs_zero timing

 


On Aug 26, 2015 08:34, "Hai Li" <hali@codeaurora.org <mailto:hali@codeaurora.org> > wrote:
>
> Hi Werner,
>
> Thanks for sharing this. The DPHY timings in downstream dtsi are exactly the same as the excel calculation, but slightly different from the output of drm code as you posted. (e.g hs_zero is 116 vs 118)
> I think it is caused by some precision loss during driver calculation, but I need to double check.
>
> Could you help to try configuring the same DPHY timings as downstream, but leave the values in  DSIPHY_LNx_CFG4 as is, to see if it works?

116 to hs_zero works fine without any other changes (only 118 and every eighth number up and down from there fails with this panel timing), so if we can do something to make sure we hit a working value for hs_zero without touching anything else that would be great! 

Thanks for checking the timings and let me know if you want me to test anything else. Is the excel formula considered public so we can discuss it here? 

/wj


[-- Attachment #1.2: Type: text/html, Size: 4871 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 312 bytes --]

On Aug 26, 2015 10:49, "Hai Li" <hali@codeaurora.org> wrote:
>
> Thanks Werner to test it out. I will focus on the dphy timing calculation
then.

Happy to help, we want this to work as much as you do!

> It’s better to avoid discussing the excel formula publicly. J

That's what I figured! :)

/wj

[-- Attachment #1.2: Type: text/html, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 849 bytes --]

On Aug 26, 2015 10:46, "Rob Clark" <robdclark@gmail.com> wrote:
>
> btw, w/ some of these clk rounding issues, I suspect we need 'struct
> drm_display_mode' to be able to represent mode clock with greater
> accuracy than Khz..

Interesting point! However, in this case I had to adjust the clock hundreds
of kHz to make it tick over one step of hs_zero, so it might not be
absolutely necessary here. Do we need better than 10ppm accuracy for
display timing (assuming 100MHz pixel clock, 1kHz step size and that I did
the math correctly)? We don't even have kHz accuracy with the PLLs in the
QC platforms we currently use..

I think the rounding error happens with the smaller numbers / intermediate
results but maybe clock should be represented in Hz internally anyway? Not
sure if it's worth changing the external-facing representation though?

/wj

[-- Attachment #1.2: Type: text/html, Size: 1036 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Rob Clark]

On Wed, Aug 26, 2015 at 2:22 PM, Werner Johansson
<werner.johansson@gmail.com> wrote:
>
> On Aug 26, 2015 10:46, "Rob Clark" <robdclark@gmail.com> wrote:
>>
>> btw, w/ some of these clk rounding issues, I suspect we need 'struct
>> drm_display_mode' to be able to represent mode clock with greater
>> accuracy than Khz..
>
> Interesting point! However, in this case I had to adjust the clock hundreds
> of kHz to make it tick over one step of hs_zero, so it might not be
> absolutely necessary here. Do we need better than 10ppm accuracy for display
> timing (assuming 100MHz pixel clock, 1kHz step size and that I did the math
> correctly)? We don't even have kHz accuracy with the PLLs in the QC
> platforms we currently use..
>
> I think the rounding error happens with the smaller numbers / intermediate
> results but maybe clock should be represented in Hz internally anyway? Not
> sure if it's worth changing the external-facing representation though?

I'm not completely sure.. I did observe that we calculated slightly
different settings w/ the auo novatek panel on z3, compared to what
downstream had hard-coded in dts (which presumably came from
magic-spreadsheet), because (I think) of rounding mode->clock to
integer KHz.  Although in the case of the z3 panel, it didn't seem to
matter.  What I am unsure about is whether other panels might be more
sensitive to different settings.

BR,
-R
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 1440 bytes --]

On Aug 26, 2015 11:31 AM, "Rob Clark" <robdclark@gmail.com> wrote:
>
> I'm not completely sure.. I did observe that we calculated slightly
> different settings w/ the auo novatek panel on z3, compared to what
> downstream had hard-coded in dts (which presumably came from
> magic-spreadsheet), because (I think) of rounding mode->clock to
> integer KHz.  Although in the case of the z3 panel, it didn't seem to
> matter.  What I am unsure about is whether other panels might be more
> sensitive to different settings.

Yes, the code definitely calculates different timing (as can be seen with
the calculations for this particular Panasonic panel as well). We need more
of the spreadsheet magic in the code it seems. This hs_zero issue seems to
be a bug of sorts inside the MSM SoC itself though, not an issue with the
panel (as exactly the same issue occurred with all three panels I tried.
The "every-eighth value fails" failure mode does not seem to be timing
related as I was able to fuzz the timing way outside of the specified
ranges and still have perfectly good display, as long as I stayed out of
the "every-eighth" value for hs_zero. The panels are typically not crystal
controlled so their frequency tolerances are wide.

The display mode seems a bit over-specified, can we derive clock from
htotal * vtotal * refreshrate instead and get the resolution needed (for
DSI that should always result in the correct clock, right)?

/wj

[-- Attachment #1.2: Type: text/html, Size: 1670 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Archit Taneja]

On 08/27/2015 07:12 AM, Werner Johansson wrote:
> On Aug 26, 2015 11:31 AM, "Rob Clark" <robdclark@gmail.com
> <mailto:robdclark@gmail.com>> wrote:
>  >
>  > I'm not completely sure.. I did observe that we calculated slightly
>  > different settings w/ the auo novatek panel on z3, compared to what
>  > downstream had hard-coded in dts (which presumably came from
>  > magic-spreadsheet), because (I think) of rounding mode->clock to
>  > integer KHz.  Although in the case of the z3 panel, it didn't seem to
>  > matter.  What I am unsure about is whether other panels might be more
>  > sensitive to different settings.
>
> Yes, the code definitely calculates different timing (as can be seen
> with the calculations for this particular Panasonic panel as well). We
> need more of the spreadsheet magic in the code it seems. This hs_zero
> issue seems to be a bug of sorts inside the MSM SoC itself though, not
> an issue with the panel (as exactly the same issue occurred with all
> three panels I tried. The "every-eighth value fails" failure mode does
> not seem to be timing related as I was able to fuzz the timing way
> outside of the specified ranges and still have perfectly good display,
> as long as I stayed out of the "every-eighth" value for hs_zero. The
> panels are typically not crystal controlled so their frequency
> tolerances are wide.
>
> The display mode seems a bit over-specified, can we derive clock from
> htotal * vtotal * refreshrate instead and get the resolution needed (for
> DSI that should always result in the correct clock, right)?

There are certain modes (generally for HDMI/DVI) where the refresh rate
isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The
above calculation may not work well with such modes.

For example, a 720p@59.94Hz mode requires 74.175 Mhz. This value can
be expressed relatively accurately in KHz if stored beforehand in
mode->clock. If we try to calculate the pixel clock here ourselves,
we'll need to round off the vrefresh to 60Hz, which gives us a less
accurate 74.25 Mhz.

We have platforms where the DSI output is connected to HDMI bridge
chips. So the issue I mentioned holds true for msm/dsi too.

Thanks,
Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 507 bytes --]

On Aug 27, 2015 10:56 PM, "Archit Taneja" <architt@codeaurora.org> wrote:
>
> There are certain modes (generally for HDMI/DVI) where the refresh rate
> isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The
> above calculation may not work well with such modes.
>
[...]
> We have platforms where the DSI output is connected to HDMI bridge
> chips. So the issue I mentioned holds true for msm/dsi too.

That makes sense, the non-integer vrefresh rates completely slipped my mind.

Thanks!

/wj

[-- Attachment #1.2: Type: text/html, Size: 700 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/msm/dsi: hs_zero timing

[hali]

>
>
> On 08/27/2015 07:12 AM, Werner Johansson wrote:
>> On Aug 26, 2015 11:31 AM, "Rob Clark" <robdclark@gmail.com
>> <mailto:robdclark@gmail.com>> wrote:
>>  >
>>  > I'm not completely sure.. I did observe that we calculated slightly
>>  > different settings w/ the auo novatek panel on z3, compared to what
>>  > downstream had hard-coded in dts (which presumably came from
>>  > magic-spreadsheet), because (I think) of rounding mode->clock to
>>  > integer KHz.  Although in the case of the z3 panel, it didn't seem to
>>  > matter.  What I am unsure about is whether other panels might be more
>>  > sensitive to different settings.
>>
>> Yes, the code definitely calculates different timing (as can be seen
>> with the calculations for this particular Panasonic panel as well). We
>> need more of the spreadsheet magic in the code it seems. This hs_zero
>> issue seems to be a bug of sorts inside the MSM SoC itself though, not
>> an issue with the panel (as exactly the same issue occurred with all
>> three panels I tried. The "every-eighth value fails" failure mode does
>> not seem to be timing related as I was able to fuzz the timing way
>> outside of the specified ranges and still have perfectly good display,
>> as long as I stayed out of the "every-eighth" value for hs_zero. The
>> panels are typically not crystal controlled so their frequency
>> tolerances are wide.
>>
>> The display mode seems a bit over-specified, can we derive clock from
>> htotal * vtotal * refreshrate instead and get the resolution needed (for
>> DSI that should always result in the correct clock, right)?
>
> There are certain modes (generally for HDMI/DVI) where the refresh rate
> isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The
> above calculation may not work well with such modes.
>
> For example, a 720p@59.94Hz mode requires 74.175 Mhz. This value can
> be expressed relatively accurately in KHz if stored beforehand in
> mode->clock. If we try to calculate the pixel clock here ourselves,
> we'll need to round off the vrefresh to 60Hz, which gives us a less
> accurate 74.25 Mhz.
>
> We have platforms where the DSI output is connected to HDMI bridge
> chips. So the issue I mentioned holds true for msm/dsi too.
>
> Thanks,
> Archit
>

For this specific dphy timing issue, the KHz pixel clock precision is good
enough, but I agree to change it to Hz for long term.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Hai Li]

[-- Attachment #1.1: Type: text/plain, Size: 991 bytes --]

Hi Werner,

 

Based on the discussion with our hw team, changing the LNn_CFG4 to all 0 is the solution for this issue.

I will prepare a change to this.

 

Thanks,

Hai

 

From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Werner Johansson
Sent: Friday, August 28, 2015 2:10 AM
To: Archit Taneja
Cc: dri-devel@lists.freedesktop.org
Subject: Re: drm/msm/dsi: hs_zero timing

 


On Aug 27, 2015 10:56 PM, "Archit Taneja" <architt@codeaurora.org <mailto:architt@codeaurora.org> > wrote:
>
> There are certain modes (generally for HDMI/DVI) where the refresh rate
> isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The
> above calculation may not work well with such modes.
>
[...] 
> We have platforms where the DSI output is connected to HDMI bridge
> chips. So the issue I mentioned holds true for msm/dsi too.

That makes sense, the non-integer vrefresh rates completely slipped my mind.

Thanks!

/wj


[-- Attachment #1.2: Type: text/html, Size: 4197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 333 bytes --]

On Sep 1, 2015 08:59, "Hai Li" <hali@codeaurora.org> wrote:
>
> Based on the discussion with our hw team, changing the LNn_CFG4 to all 0
is the solution for this issue.
>
> I will prepare a change to this.
>

That's great! I've run all my panels with the adjust zeroed and everything
just works.

Thanks for investigating this!

/wj

[-- Attachment #1.2: Type: text/html, Size: 504 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm/msm/dsi: hs_zero timing

[Werner Johansson]

[-- Attachment #1.1: Type: text/plain, Size: 1905 bytes --]

Hi,

In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic
number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting
the hs_zero period per lane). This causes some problems with certain panel
timings when timing->hs_zero plus an "unknown integer" becomes evenly
divisible by 8 - this will cause the DSI output to misbehave (typically
leading to black screen). On the three panels I've tested I have different
"unknown integers" which I can't immediately derive from the rest of the
PHY timings:

(PHY timing debug output in this order: clk_pre, clk_post, clk_zero,
clk_trail, clk_prepare, hs_exit, hs_zero, hs_prepare, hs_trail, hs_rqst)

Panasonic VVX panel (WUXGA): PHY timings: 47, 2, 259, 62, 42, 112, 118, 46,
66, 51
hs_zero calculated value of 118 does not work (neither does anything <74,
78, 86, 94, 102, 110, 126, 134, 142, 150, 158, 166, 174, 182, 190, 198,
206, 214, 222, 230, 238, 246, 254)

Sharp (1080p) on Xperia Z3: PHY timings: 44, 2, 238, 56, 38, 104, 110, 42,
60, 44
hs_zero calculated value of 110 works fine here but 104, 112, 120 and the
remaining multiples of 8 does not.

Sharp (qHD) on Dragonboard 800: PHY timings: 28, 4, 139, 30, 20, 68, 72,
24, 34, 25
hs_zero calculated value of 72 works fine but 62, 70, 78, 86 and the
remaining multiples of 8 does not.

hs_trail looked promising at first: a bad hs_zero value + hs_trail would be
evenly divisible by 8 for Panasonic and the 1080p Sharp panel but not for
the Sharp qHD display, and adjusting hs_trail did not solve the issue.

However, setting all the lane adjust values for hs_zero to 0 solves the
problem for the troublesome WUXGA panel timing and does not create any
apparent downsides for the other two.

Does anyone know of a reason this skew is implemented? If it is indeed
needed in some cases would a move to DT instead of leaving it hard-coded
make sense?

Thanks for any input!

/wj

[-- Attachment #1.2: Type: text/html, Size: 3645 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm/msm/dsi: hs_zero timing

[Johansson, Werner]

Hi,

In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly divisible by 8 - this will cause the DSI output to misbehave (typically leading to black screen). On the three panels I've tested I have different "unknown integers" which I can't immediately derive from the rest of the PHY timings:

(PHY timing debug output in this order: clk_pre, clk_post, clk_zero, clk_trail, clk_prepare, hs_exit, hs_zero, hs_prepare, hs_trail, hs_rqst)

Panasonic VVX panel (WUXGA): PHY timings: 47, 2, 259, 62, 42, 112, 118, 46, 66, 51
hs_zero calculated value of 118 does not work (neither does anything <74, 78, 86, 94, 102, 110, 126, 134, 142, 150, 158, 166, 174, 182, 190, 198, 206, 214, 222, 230, 238, 246, 254)

Sharp (1080p) on Xperia Z3: PHY timings: 44, 2, 238, 56, 38, 104, 110, 42, 60, 44
hs_zero calculated value of 110 works fine here but 104, 112, 120 and the remaining multiples of 8 does not.

Sharp (qHD) on Dragonboard 800: PHY timings: 28, 4, 139, 30, 20, 68, 72, 24, 34, 25
hs_zero calculated value of 72 works fine but 62, 70, 78, 86 and the remaining multiples of 8 does not.

hs_trail looked promising at first: a bad hs_zero value + hs_trail would be evenly divisible by 8 for Panasonic and the 1080p Sharp panel but not for the Sharp qHD display, and adjusting hs_trail did not solve the issue.

However, setting all the lane adjust values for hs_zero to 0 solves the problem for the troublesome WUXGA panel timing and does not create any apparent downsides for the other two.

Does anyone know of a reason this skew is implemented? If it is indeed needed in some cases would a move to DT instead of leaving it hard-coded make sense?

Thanks for any input!

/wj
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel