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
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
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
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
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
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
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/...)
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
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/...)
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
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
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
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
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
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
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
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
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
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
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
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
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
dri-devel@lists.freedesktop.org
-
Archit Taneja -
Hai Li -
hali＠codeaurora.org
-
Johansson, Werner -
Rob Clark -
Werner Johansson