* [PATCH 0/3] drm/msm/mdp5: Emit vsync signal often enough @ 2021-04-06 21:47 ` Marijn Suijten 0 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Konrad Dybcio, Martin Botka, Marijn Suijten, Rob Clark, Sean Paul, David Airlie, Daniel Vetter, Sai Prakash Ranjan, linux-arm-msm, dri-devel, freedreno, linux-kernel This set of patches corrects and improves VSync-related register setup on the MDP5 block. Values written to the registers were way too high leading to the MDSS block counting way too many ticks on the vclk before emitting a vsync interrupt, resulting in significant update issues on command- and video-mode panels. With lower values - that match those of downstream kernels - the panels on Sony devices (Xperia X, XA2 Ultra, and more) update at an acceptable rate without "pp_done" timeouts. The Driver-IC in these panels is also able to drive an interrupt line and a future patchset will enable the use of this "disp-te" GPIO beyond acquiring it in dsi_host. This fixes panel framerate the correct way (instead of running at half the desired framerate), but these patches are still needed to aid development now and shorten lockup times when the TE interrupt misbehaves by not arriving at all. AngeloGioacchino Del Regno (1): drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init Marijn Suijten (2): drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal drm/msm/mdp5: Do not multiply vclk line count by 100 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) -- 2.31.1 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 0/3] drm/msm/mdp5: Emit vsync signal often enough @ 2021-04-06 21:47 ` Marijn Suijten 0 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Martin Botka, ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Marijn Suijten, Sean Paul This set of patches corrects and improves VSync-related register setup on the MDP5 block. Values written to the registers were way too high leading to the MDSS block counting way too many ticks on the vclk before emitting a vsync interrupt, resulting in significant update issues on command- and video-mode panels. With lower values - that match those of downstream kernels - the panels on Sony devices (Xperia X, XA2 Ultra, and more) update at an acceptable rate without "pp_done" timeouts. The Driver-IC in these panels is also able to drive an interrupt line and a future patchset will enable the use of this "disp-te" GPIO beyond acquiring it in dsi_host. This fixes panel framerate the correct way (instead of running at half the desired framerate), but these patches are still needed to aid development now and shorten lockup times when the TE interrupt misbehaves by not arriving at all. AngeloGioacchino Del Regno (1): drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init Marijn Suijten (2): drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal drm/msm/mdp5: Do not multiply vclk line count by 100 drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) -- 2.31.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-06 21:47 ` Marijn Suijten @ 2021-04-06 21:47 ` Marijn Suijten -1 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Konrad Dybcio, Martin Botka, Marijn Suijten, Rob Clark, Sean Paul, David Airlie, Daniel Vetter, Sai Prakash Ranjan, linux-arm-msm, dri-devel, freedreno, linux-kernel Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up. In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq. Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index ff2c1d583c79..2d5ac03dbc17 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); mdp5_write(mdp5_kms, - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); mdp5_write(mdp5_kms, REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1); -- 2.31.1 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal @ 2021-04-06 21:47 ` Marijn Suijten 0 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Martin Botka, ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Marijn Suijten, Sean Paul Leaving this at a close-to-maximum register value 0xFFF0 means it takes very long for the MDSS to generate a software vsync interrupt when the hardware TE interrupt doesn't arrive. Configuring this to double the vtotal (like some downstream kernels) leads to a frame to take at most twice before the vsync signal, until hardware TE comes up. In this case the hardware interrupt responsible for providing this signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at all. This solves severe panel update issues observed on at least the Xperia Loire and Tone series, until said gpio is properly hooked up to an irq. Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index ff2c1d583c79..2d5ac03dbc17 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); mdp5_write(mdp5_kms, - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); mdp5_write(mdp5_kms, REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + 1); -- 2.31.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-06 21:47 ` Marijn Suijten @ 2021-04-07 18:19 ` abhinavk -1 siblings, 0 replies; 19+ messages in thread From: abhinavk @ 2021-04-07 18:19 UTC (permalink / raw) To: Marijn Suijten Cc: phone-devel, freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Rob Clark, Martin Botka, ~postmarketos/upstreaming, Daniel Vetter, AngeloGioacchino Del Regno, Sean Paul Hi Marijn On 2021-04-06 14:47, Marijn Suijten wrote: > Leaving this at a close-to-maximum register value 0xFFF0 means it takes > very long for the MDSS to generate a software vsync interrupt when the > hardware TE interrupt doesn't arrive. Configuring this to double the > vtotal (like some downstream kernels) leads to a frame to take at most > twice before the vsync signal, until hardware TE comes up. > > In this case the hardware interrupt responsible for providing this > signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic > at > all. This solves severe panel update issues observed on at least the > Xperia Loire and Tone series, until said gpio is properly hooked up to > an irq. The reason the CONFIG_HEIGHT was at such a high value is to make sure that we always get the TE only from the panel vsync and not false positives coming from the tear check logic itself. When you say that disp-te gpio is not hooked up, is it something incorrect with the schematic OR panel is not generating the TE correctly? > > Suggested-by: AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > Reviewed-by: AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> > --- > drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > index ff2c1d583c79..2d5ac03dbc17 100644 > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct > drm_encoder *encoder, > > mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); > mdp5_write(mdp5_kms, > - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); > + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); > mdp5_write(mdp5_kms, > REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); > mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + > 1); ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal @ 2021-04-07 18:19 ` abhinavk 0 siblings, 0 replies; 19+ messages in thread From: abhinavk @ 2021-04-07 18:19 UTC (permalink / raw) To: Marijn Suijten Cc: Sean Paul, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Martin Botka, ~postmarketos/upstreaming, AngeloGioacchino Del Regno, phone-devel, freedreno Hi Marijn On 2021-04-06 14:47, Marijn Suijten wrote: > Leaving this at a close-to-maximum register value 0xFFF0 means it takes > very long for the MDSS to generate a software vsync interrupt when the > hardware TE interrupt doesn't arrive. Configuring this to double the > vtotal (like some downstream kernels) leads to a frame to take at most > twice before the vsync signal, until hardware TE comes up. > > In this case the hardware interrupt responsible for providing this > signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic > at > all. This solves severe panel update issues observed on at least the > Xperia Loire and Tone series, until said gpio is properly hooked up to > an irq. The reason the CONFIG_HEIGHT was at such a high value is to make sure that we always get the TE only from the panel vsync and not false positives coming from the tear check logic itself. When you say that disp-te gpio is not hooked up, is it something incorrect with the schematic OR panel is not generating the TE correctly? > > Suggested-by: AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> > Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > Reviewed-by: AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> > --- > drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > index ff2c1d583c79..2d5ac03dbc17 100644 > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct > drm_encoder *encoder, > > mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); > mdp5_write(mdp5_kms, > - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); > + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); > mdp5_write(mdp5_kms, > REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); > mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), mode->vdisplay + > 1); _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-07 18:19 ` abhinavk @ 2021-04-07 19:11 ` AngeloGioacchino Del Regno -1 siblings, 0 replies; 19+ messages in thread From: AngeloGioacchino Del Regno @ 2021-04-07 19:11 UTC (permalink / raw) To: abhinavk, Marijn Suijten Cc: phone-devel, freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Rob Clark, Martin Botka, ~postmarketos/upstreaming, Daniel Vetter, Sean Paul Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: > Hi Marijn > > On 2021-04-06 14:47, Marijn Suijten wrote: >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes >> very long for the MDSS to generate a software vsync interrupt when the >> hardware TE interrupt doesn't arrive. Configuring this to double the >> vtotal (like some downstream kernels) leads to a frame to take at most >> twice before the vsync signal, until hardware TE comes up. >> >> In this case the hardware interrupt responsible for providing this >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at >> all. This solves severe panel update issues observed on at least the >> Xperia Loire and Tone series, until said gpio is properly hooked up to >> an irq. > > The reason the CONFIG_HEIGHT was at such a high value is to make sure that > we always get the TE only from the panel vsync and not false positives > coming > from the tear check logic itself. > > When you say that disp-te gpio is not hooked up, is it something > incorrect with > the schematic OR panel is not generating the TE correctly? > Sometimes, some panels aren't getting correctly configured by the OEM/ODM in the first place: especially when porting devices from downstream to upstream, developers often get in a situation in which their TE line is either misconfigured or the DriverIC is not configured to raise V-Sync interrupts. Please remember: some DDICs need a "commands sequence" to enable generating the TE interrupts, sometimes this is not standard, and sometimes OEMs/ODMs are not even doing that in their downstream code (but instead they work around it in creative ways "for reasons", even though their DDIC supports indeed sending TE events). This mostly happens when bringing up devices that have autorefresh enabled from the bootloader (when the bootloader sets up the splash screen) by using simple-panel as a (hopefully) temporary solution to get through the initial stages of porting. We are not trying to cover cases related to incorrect schematics or hardware mistakes here, as the fix for that - as you know - is to just fix your hardware. What we're trying to do here is to stop freezes and, in some cases, lockups, other than false positives making the developer go offroad when the platform shows that something is wrong during early porting. Also, sometimes, some DDICs will not generate TE interrupts when expected... in these cases we get a PP timeout and a MDP5 recovery: this is totally avoidable if we rely on the 2*vtotal, as we wouldn't get through the very time consuming task of recovering the entire MDP. Of course, if something is wrong in the MDP and the block really needs recovery, this "trick" won't save anyone and the recovery will anyway be triggered, as the PP-done will anyway timeout. >> >> Suggested-by: AngeloGioacchino Del Regno >> <angelogioacchino.delregno@somainline.org> >> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> >> Reviewed-by: AngeloGioacchino Del Regno >> <angelogioacchino.delregno@somainline.org> >> --- >> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> index ff2c1d583c79..2d5ac03dbc17 100644 >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct >> drm_encoder *encoder, >> >> mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); >> mdp5_write(mdp5_kms, >> - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); >> + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); >> mdp5_write(mdp5_kms, >> REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); >> mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), >> mode->vdisplay + 1); ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal @ 2021-04-07 19:11 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 19+ messages in thread From: AngeloGioacchino Del Regno @ 2021-04-07 19:11 UTC (permalink / raw) To: abhinavk, Marijn Suijten Cc: Sean Paul, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Martin Botka, ~postmarketos/upstreaming, phone-devel, freedreno Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: > Hi Marijn > > On 2021-04-06 14:47, Marijn Suijten wrote: >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes >> very long for the MDSS to generate a software vsync interrupt when the >> hardware TE interrupt doesn't arrive. Configuring this to double the >> vtotal (like some downstream kernels) leads to a frame to take at most >> twice before the vsync signal, until hardware TE comes up. >> >> In this case the hardware interrupt responsible for providing this >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at >> all. This solves severe panel update issues observed on at least the >> Xperia Loire and Tone series, until said gpio is properly hooked up to >> an irq. > > The reason the CONFIG_HEIGHT was at such a high value is to make sure that > we always get the TE only from the panel vsync and not false positives > coming > from the tear check logic itself. > > When you say that disp-te gpio is not hooked up, is it something > incorrect with > the schematic OR panel is not generating the TE correctly? > Sometimes, some panels aren't getting correctly configured by the OEM/ODM in the first place: especially when porting devices from downstream to upstream, developers often get in a situation in which their TE line is either misconfigured or the DriverIC is not configured to raise V-Sync interrupts. Please remember: some DDICs need a "commands sequence" to enable generating the TE interrupts, sometimes this is not standard, and sometimes OEMs/ODMs are not even doing that in their downstream code (but instead they work around it in creative ways "for reasons", even though their DDIC supports indeed sending TE events). This mostly happens when bringing up devices that have autorefresh enabled from the bootloader (when the bootloader sets up the splash screen) by using simple-panel as a (hopefully) temporary solution to get through the initial stages of porting. We are not trying to cover cases related to incorrect schematics or hardware mistakes here, as the fix for that - as you know - is to just fix your hardware. What we're trying to do here is to stop freezes and, in some cases, lockups, other than false positives making the developer go offroad when the platform shows that something is wrong during early porting. Also, sometimes, some DDICs will not generate TE interrupts when expected... in these cases we get a PP timeout and a MDP5 recovery: this is totally avoidable if we rely on the 2*vtotal, as we wouldn't get through the very time consuming task of recovering the entire MDP. Of course, if something is wrong in the MDP and the block really needs recovery, this "trick" won't save anyone and the recovery will anyway be triggered, as the PP-done will anyway timeout. >> >> Suggested-by: AngeloGioacchino Del Regno >> <angelogioacchino.delregno@somainline.org> >> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> >> Reviewed-by: AngeloGioacchino Del Regno >> <angelogioacchino.delregno@somainline.org> >> --- >> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> index ff2c1d583c79..2d5ac03dbc17 100644 >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c >> @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct >> drm_encoder *encoder, >> >> mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); >> mdp5_write(mdp5_kms, >> - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); >> + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); >> mdp5_write(mdp5_kms, >> REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); >> mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), >> mode->vdisplay + 1); _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-07 19:11 ` AngeloGioacchino Del Regno @ 2021-04-08 19:05 ` Rob Clark -1 siblings, 0 replies; 19+ messages in thread From: Rob Clark @ 2021-04-08 19:05 UTC (permalink / raw) To: AngeloGioacchino Del Regno Cc: Abhinav Kumar, Marijn Suijten, phone-devel, freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, dri-devel, Martin Botka, ~postmarketos/upstreaming, Daniel Vetter, Sean Paul On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> wrote: > > Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: > > Hi Marijn > > > > On 2021-04-06 14:47, Marijn Suijten wrote: > >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes > >> very long for the MDSS to generate a software vsync interrupt when the > >> hardware TE interrupt doesn't arrive. Configuring this to double the > >> vtotal (like some downstream kernels) leads to a frame to take at most > >> twice before the vsync signal, until hardware TE comes up. > >> > >> In this case the hardware interrupt responsible for providing this > >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at > >> all. This solves severe panel update issues observed on at least the > >> Xperia Loire and Tone series, until said gpio is properly hooked up to > >> an irq. > > > > The reason the CONFIG_HEIGHT was at such a high value is to make sure that > > we always get the TE only from the panel vsync and not false positives > > coming > > from the tear check logic itself. > > > > When you say that disp-te gpio is not hooked up, is it something > > incorrect with > > the schematic OR panel is not generating the TE correctly? > > > > Sometimes, some panels aren't getting correctly configured by the > OEM/ODM in the first place: especially when porting devices from > downstream to upstream, developers often get in a situation in which > their TE line is either misconfigured or the DriverIC is not configured > to raise V-Sync interrupts. > Please remember: some DDICs need a "commands sequence" to enable > generating the TE interrupts, sometimes this is not standard, and > sometimes OEMs/ODMs are not even doing that in their downstream code > (but instead they work around it in creative ways "for reasons", even > though their DDIC supports indeed sending TE events). > > This mostly happens when bringing up devices that have autorefresh > enabled from the bootloader (when the bootloader sets up the splash > screen) by using simple-panel as a (hopefully) temporary solution to get > through the initial stages of porting. > > We are not trying to cover cases related to incorrect schematics or > hardware mistakes here, as the fix for that - as you know - is to just > fix your hardware. > What we're trying to do here is to stop freezes and, in some cases, > lockups, other than false positives making the developer go offroad when > the platform shows that something is wrong during early porting. > > Also, sometimes, some DDICs will not generate TE interrupts when > expected... in these cases we get a PP timeout and a MDP5 recovery: this > is totally avoidable if we rely on the 2*vtotal, as we wouldn't get > through the very time consuming task of recovering the entire MDP. > > Of course, if something is wrong in the MDP and the block really needs > recovery, this "trick" won't save anyone and the recovery will anyway be > triggered, as the PP-done will anyway timeout. So, is this (mostly) a workaround due to TE not wired up? In which case I think it is ok, but maybe should have a comment about the interaction with TE? Currently I have this patch in msm-next-staging but I guess we need to decide in the next day or so whether to drop it or smash in a comment? BR, -R > >> > >> Suggested-by: AngeloGioacchino Del Regno > >> <angelogioacchino.delregno@somainline.org> > >> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > >> Reviewed-by: AngeloGioacchino Del Regno > >> <angelogioacchino.delregno@somainline.org> > >> --- > >> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> index ff2c1d583c79..2d5ac03dbc17 100644 > >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct > >> drm_encoder *encoder, > >> > >> mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); > >> mdp5_write(mdp5_kms, > >> - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); > >> + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); > >> mdp5_write(mdp5_kms, > >> REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); > >> mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), > >> mode->vdisplay + 1); > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal @ 2021-04-08 19:05 ` Rob Clark 0 siblings, 0 replies; 19+ messages in thread From: Rob Clark @ 2021-04-08 19:05 UTC (permalink / raw) To: AngeloGioacchino Del Regno Cc: Sean Paul, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, Abhinav Kumar, Martin Botka, dri-devel, Marijn Suijten, phone-devel, freedreno, ~postmarketos/upstreaming On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> wrote: > > Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: > > Hi Marijn > > > > On 2021-04-06 14:47, Marijn Suijten wrote: > >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes > >> very long for the MDSS to generate a software vsync interrupt when the > >> hardware TE interrupt doesn't arrive. Configuring this to double the > >> vtotal (like some downstream kernels) leads to a frame to take at most > >> twice before the vsync signal, until hardware TE comes up. > >> > >> In this case the hardware interrupt responsible for providing this > >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at > >> all. This solves severe panel update issues observed on at least the > >> Xperia Loire and Tone series, until said gpio is properly hooked up to > >> an irq. > > > > The reason the CONFIG_HEIGHT was at such a high value is to make sure that > > we always get the TE only from the panel vsync and not false positives > > coming > > from the tear check logic itself. > > > > When you say that disp-te gpio is not hooked up, is it something > > incorrect with > > the schematic OR panel is not generating the TE correctly? > > > > Sometimes, some panels aren't getting correctly configured by the > OEM/ODM in the first place: especially when porting devices from > downstream to upstream, developers often get in a situation in which > their TE line is either misconfigured or the DriverIC is not configured > to raise V-Sync interrupts. > Please remember: some DDICs need a "commands sequence" to enable > generating the TE interrupts, sometimes this is not standard, and > sometimes OEMs/ODMs are not even doing that in their downstream code > (but instead they work around it in creative ways "for reasons", even > though their DDIC supports indeed sending TE events). > > This mostly happens when bringing up devices that have autorefresh > enabled from the bootloader (when the bootloader sets up the splash > screen) by using simple-panel as a (hopefully) temporary solution to get > through the initial stages of porting. > > We are not trying to cover cases related to incorrect schematics or > hardware mistakes here, as the fix for that - as you know - is to just > fix your hardware. > What we're trying to do here is to stop freezes and, in some cases, > lockups, other than false positives making the developer go offroad when > the platform shows that something is wrong during early porting. > > Also, sometimes, some DDICs will not generate TE interrupts when > expected... in these cases we get a PP timeout and a MDP5 recovery: this > is totally avoidable if we rely on the 2*vtotal, as we wouldn't get > through the very time consuming task of recovering the entire MDP. > > Of course, if something is wrong in the MDP and the block really needs > recovery, this "trick" won't save anyone and the recovery will anyway be > triggered, as the PP-done will anyway timeout. So, is this (mostly) a workaround due to TE not wired up? In which case I think it is ok, but maybe should have a comment about the interaction with TE? Currently I have this patch in msm-next-staging but I guess we need to decide in the next day or so whether to drop it or smash in a comment? BR, -R > >> > >> Suggested-by: AngeloGioacchino Del Regno > >> <angelogioacchino.delregno@somainline.org> > >> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > >> Reviewed-by: AngeloGioacchino Del Regno > >> <angelogioacchino.delregno@somainline.org> > >> --- > >> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> index ff2c1d583c79..2d5ac03dbc17 100644 > >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > >> @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct > >> drm_encoder *encoder, > >> > >> mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); > >> mdp5_write(mdp5_kms, > >> - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); > >> + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); > >> mdp5_write(mdp5_kms, > >> REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); > >> mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), > >> mode->vdisplay + 1); > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-08 19:05 ` Rob Clark (?) @ 2021-04-08 23:16 ` AngeloGioacchino Del Regno 2021-04-09 0:08 ` Rob Clark -1 siblings, 1 reply; 19+ messages in thread From: AngeloGioacchino Del Regno @ 2021-04-08 23:16 UTC (permalink / raw) To: Rob Clark Cc: Sean Paul, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, Abhinav Kumar, Martin Botka, dri-devel, AngeloGioacchino Del Regno, Marijn Suijten, phone-devel, freedreno, ~postmarketos/upstreaming [-- Attachment #1.1: Type: text/plain, Size: 4986 bytes --] Il gio 8 apr 2021, 21:05 Rob Clark <robdclark@gmail.com> ha scritto: > On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> wrote: > > > > Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: > > > Hi Marijn > > > > > > On 2021-04-06 14:47, Marijn Suijten wrote: > > >> Leaving this at a close-to-maximum register value 0xFFF0 means it > takes > > >> very long for the MDSS to generate a software vsync interrupt when the > > >> hardware TE interrupt doesn't arrive. Configuring this to double the > > >> vtotal (like some downstream kernels) leads to a frame to take at most > > >> twice before the vsync signal, until hardware TE comes up. > > >> > > >> In this case the hardware interrupt responsible for providing this > > >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic > at > > >> all. This solves severe panel update issues observed on at least the > > >> Xperia Loire and Tone series, until said gpio is properly hooked up to > > >> an irq. > > > > > > The reason the CONFIG_HEIGHT was at such a high value is to make sure > that > > > we always get the TE only from the panel vsync and not false positives > > > coming > > > from the tear check logic itself. > > > > > > When you say that disp-te gpio is not hooked up, is it something > > > incorrect with > > > the schematic OR panel is not generating the TE correctly? > > > > > > > Sometimes, some panels aren't getting correctly configured by the > > OEM/ODM in the first place: especially when porting devices from > > downstream to upstream, developers often get in a situation in which > > their TE line is either misconfigured or the DriverIC is not configured > > to raise V-Sync interrupts. > > Please remember: some DDICs need a "commands sequence" to enable > > generating the TE interrupts, sometimes this is not standard, and > > sometimes OEMs/ODMs are not even doing that in their downstream code > > (but instead they work around it in creative ways "for reasons", even > > though their DDIC supports indeed sending TE events). > > > > This mostly happens when bringing up devices that have autorefresh > > enabled from the bootloader (when the bootloader sets up the splash > > screen) by using simple-panel as a (hopefully) temporary solution to get > > through the initial stages of porting. > > > > We are not trying to cover cases related to incorrect schematics or > > hardware mistakes here, as the fix for that - as you know - is to just > > fix your hardware. > > What we're trying to do here is to stop freezes and, in some cases, > > lockups, other than false positives making the developer go offroad when > > the platform shows that something is wrong during early porting. > > > > Also, sometimes, some DDICs will not generate TE interrupts when > > expected... in these cases we get a PP timeout and a MDP5 recovery: this > > is totally avoidable if we rely on the 2*vtotal, as we wouldn't get > > through the very time consuming task of recovering the entire MDP. > > > > Of course, if something is wrong in the MDP and the block really needs > > recovery, this "trick" won't save anyone and the recovery will anyway be > > triggered, as the PP-done will anyway timeout. > > So, is this (mostly) a workaround due to TE not wired up? In which > case I think it is ok, but maybe should have a comment about the > interaction with TE? > Mostly, yes. > Currently I have this patch in msm-next-staging but I guess we need to > decide in the next day or so whether to drop it or smash in a comment? > > BR, > -R > Marijn, can you please urgently throw a comment in, reminding that these timers are interacting with TE and send a fast V2? Cheers, - Angelo > > >> > > >> Suggested-by: AngeloGioacchino Del Regno > > >> <angelogioacchino.delregno@somainline.org> > > >> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> > > >> Reviewed-by: AngeloGioacchino Del Regno > > >> <angelogioacchino.delregno@somainline.org> > > >> --- > > >> drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +- > > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > >> > > >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > > >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > > >> index ff2c1d583c79..2d5ac03dbc17 100644 > > >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > > >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c > > >> @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct > > >> drm_encoder *encoder, > > >> > > >> mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg); > > >> mdp5_write(mdp5_kms, > > >> - REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0); > > >> + REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal)); > > >> mdp5_write(mdp5_kms, > > >> REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay); > > >> mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id), > > >> mode->vdisplay + 1); > [-- Attachment #1.2: Type: text/html, Size: 7514 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-08 23:16 ` AngeloGioacchino Del Regno @ 2021-04-09 0:08 ` Rob Clark 0 siblings, 0 replies; 19+ messages in thread From: Rob Clark @ 2021-04-09 0:08 UTC (permalink / raw) To: AngeloGioacchino Del Regno Cc: Abhinav Kumar, Marijn Suijten, phone-devel, freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, dri-devel, Martin Botka, ~postmarketos/upstreaming, Daniel Vetter, Sean Paul On Thu, Apr 8, 2021 at 4:16 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> wrote: > > > Il gio 8 apr 2021, 21:05 Rob Clark <robdclark@gmail.com> ha scritto: >> >> On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno >> <angelogioacchino.delregno@somainline.org> wrote: >> > >> > Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: >> > > Hi Marijn >> > > >> > > On 2021-04-06 14:47, Marijn Suijten wrote: >> > >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes >> > >> very long for the MDSS to generate a software vsync interrupt when the >> > >> hardware TE interrupt doesn't arrive. Configuring this to double the >> > >> vtotal (like some downstream kernels) leads to a frame to take at most >> > >> twice before the vsync signal, until hardware TE comes up. >> > >> >> > >> In this case the hardware interrupt responsible for providing this >> > >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at >> > >> all. This solves severe panel update issues observed on at least the >> > >> Xperia Loire and Tone series, until said gpio is properly hooked up to >> > >> an irq. >> > > >> > > The reason the CONFIG_HEIGHT was at such a high value is to make sure that >> > > we always get the TE only from the panel vsync and not false positives >> > > coming >> > > from the tear check logic itself. >> > > >> > > When you say that disp-te gpio is not hooked up, is it something >> > > incorrect with >> > > the schematic OR panel is not generating the TE correctly? >> > > >> > >> > Sometimes, some panels aren't getting correctly configured by the >> > OEM/ODM in the first place: especially when porting devices from >> > downstream to upstream, developers often get in a situation in which >> > their TE line is either misconfigured or the DriverIC is not configured >> > to raise V-Sync interrupts. >> > Please remember: some DDICs need a "commands sequence" to enable >> > generating the TE interrupts, sometimes this is not standard, and >> > sometimes OEMs/ODMs are not even doing that in their downstream code >> > (but instead they work around it in creative ways "for reasons", even >> > though their DDIC supports indeed sending TE events). >> > >> > This mostly happens when bringing up devices that have autorefresh >> > enabled from the bootloader (when the bootloader sets up the splash >> > screen) by using simple-panel as a (hopefully) temporary solution to get >> > through the initial stages of porting. >> > >> > We are not trying to cover cases related to incorrect schematics or >> > hardware mistakes here, as the fix for that - as you know - is to just >> > fix your hardware. >> > What we're trying to do here is to stop freezes and, in some cases, >> > lockups, other than false positives making the developer go offroad when >> > the platform shows that something is wrong during early porting. >> > >> > Also, sometimes, some DDICs will not generate TE interrupts when >> > expected... in these cases we get a PP timeout and a MDP5 recovery: this >> > is totally avoidable if we rely on the 2*vtotal, as we wouldn't get >> > through the very time consuming task of recovering the entire MDP. >> > >> > Of course, if something is wrong in the MDP and the block really needs >> > recovery, this "trick" won't save anyone and the recovery will anyway be >> > triggered, as the PP-done will anyway timeout. >> >> So, is this (mostly) a workaround due to TE not wired up? In which >> case I think it is ok, but maybe should have a comment about the >> interaction with TE? > > > Mostly, yes. > >> >> Currently I have this patch in msm-next-staging but I guess we need to >> decide in the next day or so whether to drop it or smash in a comment? >> >> BR, >> -R > > > Marijn, can you please urgently throw a comment in, reminding that these timers are interacting with TE and send a fast V2? > Or just reply on list w/ a comment to smash in, if that is easier BR, -R ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal @ 2021-04-09 0:08 ` Rob Clark 0 siblings, 0 replies; 19+ messages in thread From: Rob Clark @ 2021-04-09 0:08 UTC (permalink / raw) To: AngeloGioacchino Del Regno Cc: Sean Paul, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, Abhinav Kumar, Martin Botka, dri-devel, Marijn Suijten, phone-devel, freedreno, ~postmarketos/upstreaming On Thu, Apr 8, 2021 at 4:16 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> wrote: > > > Il gio 8 apr 2021, 21:05 Rob Clark <robdclark@gmail.com> ha scritto: >> >> On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno >> <angelogioacchino.delregno@somainline.org> wrote: >> > >> > Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: >> > > Hi Marijn >> > > >> > > On 2021-04-06 14:47, Marijn Suijten wrote: >> > >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes >> > >> very long for the MDSS to generate a software vsync interrupt when the >> > >> hardware TE interrupt doesn't arrive. Configuring this to double the >> > >> vtotal (like some downstream kernels) leads to a frame to take at most >> > >> twice before the vsync signal, until hardware TE comes up. >> > >> >> > >> In this case the hardware interrupt responsible for providing this >> > >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at >> > >> all. This solves severe panel update issues observed on at least the >> > >> Xperia Loire and Tone series, until said gpio is properly hooked up to >> > >> an irq. >> > > >> > > The reason the CONFIG_HEIGHT was at such a high value is to make sure that >> > > we always get the TE only from the panel vsync and not false positives >> > > coming >> > > from the tear check logic itself. >> > > >> > > When you say that disp-te gpio is not hooked up, is it something >> > > incorrect with >> > > the schematic OR panel is not generating the TE correctly? >> > > >> > >> > Sometimes, some panels aren't getting correctly configured by the >> > OEM/ODM in the first place: especially when porting devices from >> > downstream to upstream, developers often get in a situation in which >> > their TE line is either misconfigured or the DriverIC is not configured >> > to raise V-Sync interrupts. >> > Please remember: some DDICs need a "commands sequence" to enable >> > generating the TE interrupts, sometimes this is not standard, and >> > sometimes OEMs/ODMs are not even doing that in their downstream code >> > (but instead they work around it in creative ways "for reasons", even >> > though their DDIC supports indeed sending TE events). >> > >> > This mostly happens when bringing up devices that have autorefresh >> > enabled from the bootloader (when the bootloader sets up the splash >> > screen) by using simple-panel as a (hopefully) temporary solution to get >> > through the initial stages of porting. >> > >> > We are not trying to cover cases related to incorrect schematics or >> > hardware mistakes here, as the fix for that - as you know - is to just >> > fix your hardware. >> > What we're trying to do here is to stop freezes and, in some cases, >> > lockups, other than false positives making the developer go offroad when >> > the platform shows that something is wrong during early porting. >> > >> > Also, sometimes, some DDICs will not generate TE interrupts when >> > expected... in these cases we get a PP timeout and a MDP5 recovery: this >> > is totally avoidable if we rely on the 2*vtotal, as we wouldn't get >> > through the very time consuming task of recovering the entire MDP. >> > >> > Of course, if something is wrong in the MDP and the block really needs >> > recovery, this "trick" won't save anyone and the recovery will anyway be >> > triggered, as the PP-done will anyway timeout. >> >> So, is this (mostly) a workaround due to TE not wired up? In which >> case I think it is ok, but maybe should have a comment about the >> interaction with TE? > > > Mostly, yes. > >> >> Currently I have this patch in msm-next-staging but I guess we need to >> decide in the next day or so whether to drop it or smash in a comment? >> >> BR, >> -R > > > Marijn, can you please urgently throw a comment in, reminding that these timers are interacting with TE and send a fast V2? > Or just reply on list w/ a comment to smash in, if that is easier BR, -R _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal 2021-04-09 0:08 ` Rob Clark @ 2021-04-09 8:22 ` Marijn Suijten -1 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-09 8:22 UTC (permalink / raw) To: Abhinav Kumar, Rob Clark, AngeloGioacchino Del Regno Cc: phone-devel, freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, dri-devel, Martin Botka, ~postmarketos/upstreaming, Daniel Vetter, Sean Paul Hi Abhinav, Angelo, Rob, On 4/9/21 2:08 AM, Rob Clark wrote: > On Thu, Apr 8, 2021 at 4:16 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> wrote: >> >> >> Il gio 8 apr 2021, 21:05 Rob Clark <robdclark@gmail.com> ha scritto: >>> >>> On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno >>> <angelogioacchino.delregno@somainline.org> wrote: >>>> >>>> Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: >>>>> Hi Marijn >>>>> >>>>> On 2021-04-06 14:47, Marijn Suijten wrote: >>>>>> Leaving this at a close-to-maximum register value 0xFFF0 means it takes >>>>>> very long for the MDSS to generate a software vsync interrupt when the >>>>>> hardware TE interrupt doesn't arrive. Configuring this to double the >>>>>> vtotal (like some downstream kernels) leads to a frame to take at most >>>>>> twice before the vsync signal, until hardware TE comes up. >>>>>> >>>>>> In this case the hardware interrupt responsible for providing this >>>>>> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at >>>>>> all. This solves severe panel update issues observed on at least the >>>>>> Xperia Loire and Tone series, until said gpio is properly hooked up to >>>>>> an irq. >>>>> >>>>> The reason the CONFIG_HEIGHT was at such a high value is to make sure that >>>>> we always get the TE only from the panel vsync and not false positives >>>>> coming >>>>> from the tear check logic itself. Correct, most CAF kernels mention such behaviour in comments, with fallbacks to vtotal*2 for safety or vtotal when an emulated panel does not support hardware TE at all. We don't seem to (need to) support the latter case but one might at some point want to configure the tearcheck logic to emit a signal for every frame, by means of a DT property or automatically when disp-te is not defined. >>>>> >>>>> When you say that disp-te gpio is not hooked up, is it something >>>>> incorrect with >>>>> the schematic OR panel is not generating the TE correctly? >>>>> The GPIO is currently not used at all by this kernel driver besides a call to devm_gpiod_get_optional. As mentioned in the cover letter we have patches in progress to hook up this interrupt line to the pp_done infrastructure and complete vsync requests that way instead of waiting for this "simulated" interrupt from the MDP. >>> Currently I have this patch in msm-next-staging but I guess we need to >>> decide in the next day or so whether to drop it or smash in a comment? >> >> Marijn, can you please urgently throw a comment in, reminding that these timers are interacting with TE and send a fast V2? > > Or just reply on list w/ a comment to smash in, if that is easier How about a comment along the lines of: Tearcheck emits a blanking signal every vclks_line * vtotal * 2 ticks on the vsync_clk equating to roughly half the desired panel refresh rate. This is only necessary as stability fallback if interrupts from the panel arrive too late or not at all, but is currently used by default because these panel interrupts are not wired up yet. I'd place this comment right above REG_MDP5_PP_SYNC_CONFIG_VSYNC, and perhaps add a newline after REG_MDP5_PP_SYNC_CONFIG_HEIGHT to make it clear this applies to those two registers specifically. We can also involve MDP5_PP_SYNC_CONFIG_VSYNC_COUNT(vclks_line) in the mix. Then, when the panel TE is wired up we can be smarter about the situation and print warnings when the user has disp-te hooked up but is receiving interrupts from the MDSS block instead of the panel directly (except if incidentally). This likely means that SET_TEAR_ON was not sent to the panel or the GPIO is wrong. In that sense this patch (together with x100 removal) is concealing configuration mistakes, but we might also revert back to 0xfff0 if the GPIO is specified in DT and accept the timeout+recovery which did not seem to hamper devices on downstream kernels anyway. - Marijn ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal @ 2021-04-09 8:22 ` Marijn Suijten 0 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-09 8:22 UTC (permalink / raw) To: Abhinav Kumar, Rob Clark, AngeloGioacchino Del Regno Cc: Sean Paul, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, Linux Kernel Mailing List, dri-devel, Martin Botka, ~postmarketos/upstreaming, phone-devel, freedreno Hi Abhinav, Angelo, Rob, On 4/9/21 2:08 AM, Rob Clark wrote: > On Thu, Apr 8, 2021 at 4:16 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@somainline.org> wrote: >> >> >> Il gio 8 apr 2021, 21:05 Rob Clark <robdclark@gmail.com> ha scritto: >>> >>> On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno >>> <angelogioacchino.delregno@somainline.org> wrote: >>>> >>>> Il 07/04/21 20:19, abhinavk@codeaurora.org ha scritto: >>>>> Hi Marijn >>>>> >>>>> On 2021-04-06 14:47, Marijn Suijten wrote: >>>>>> Leaving this at a close-to-maximum register value 0xFFF0 means it takes >>>>>> very long for the MDSS to generate a software vsync interrupt when the >>>>>> hardware TE interrupt doesn't arrive. Configuring this to double the >>>>>> vtotal (like some downstream kernels) leads to a frame to take at most >>>>>> twice before the vsync signal, until hardware TE comes up. >>>>>> >>>>>> In this case the hardware interrupt responsible for providing this >>>>>> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at >>>>>> all. This solves severe panel update issues observed on at least the >>>>>> Xperia Loire and Tone series, until said gpio is properly hooked up to >>>>>> an irq. >>>>> >>>>> The reason the CONFIG_HEIGHT was at such a high value is to make sure that >>>>> we always get the TE only from the panel vsync and not false positives >>>>> coming >>>>> from the tear check logic itself. Correct, most CAF kernels mention such behaviour in comments, with fallbacks to vtotal*2 for safety or vtotal when an emulated panel does not support hardware TE at all. We don't seem to (need to) support the latter case but one might at some point want to configure the tearcheck logic to emit a signal for every frame, by means of a DT property or automatically when disp-te is not defined. >>>>> >>>>> When you say that disp-te gpio is not hooked up, is it something >>>>> incorrect with >>>>> the schematic OR panel is not generating the TE correctly? >>>>> The GPIO is currently not used at all by this kernel driver besides a call to devm_gpiod_get_optional. As mentioned in the cover letter we have patches in progress to hook up this interrupt line to the pp_done infrastructure and complete vsync requests that way instead of waiting for this "simulated" interrupt from the MDP. >>> Currently I have this patch in msm-next-staging but I guess we need to >>> decide in the next day or so whether to drop it or smash in a comment? >> >> Marijn, can you please urgently throw a comment in, reminding that these timers are interacting with TE and send a fast V2? > > Or just reply on list w/ a comment to smash in, if that is easier How about a comment along the lines of: Tearcheck emits a blanking signal every vclks_line * vtotal * 2 ticks on the vsync_clk equating to roughly half the desired panel refresh rate. This is only necessary as stability fallback if interrupts from the panel arrive too late or not at all, but is currently used by default because these panel interrupts are not wired up yet. I'd place this comment right above REG_MDP5_PP_SYNC_CONFIG_VSYNC, and perhaps add a newline after REG_MDP5_PP_SYNC_CONFIG_HEIGHT to make it clear this applies to those two registers specifically. We can also involve MDP5_PP_SYNC_CONFIG_VSYNC_COUNT(vclks_line) in the mix. Then, when the panel TE is wired up we can be smarter about the situation and print warnings when the user has disp-te hooked up but is receiving interrupts from the MDSS block instead of the panel directly (except if incidentally). This likely means that SET_TEAR_ON was not sent to the panel or the GPIO is wrong. In that sense this patch (together with x100 removal) is concealing configuration mistakes, but we might also revert back to 0xfff0 if the GPIO is specified in DT and accept the timeout+recovery which did not seem to hamper devices on downstream kernels anyway. - Marijn _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 2/3] drm/msm/mdp5: Do not multiply vclk line count by 100 2021-04-06 21:47 ` Marijn Suijten @ 2021-04-06 21:47 ` Marijn Suijten -1 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Konrad Dybcio, Martin Botka, Marijn Suijten, Rob Clark, Sean Paul, David Airlie, Daniel Vetter, Sai Prakash Ranjan, linux-arm-msm, dri-devel, freedreno, linux-kernel Neither vtotal nor drm_mode_vrefresh contain a value that is premultiplied by 100 making the x100 variable name incorrect and resulting in vclks_line to become 100 times larger than it is supposed to be. The hardware counts 100 clockticks too many before tearcheck, leading to severe panel issues on at least the Sony Xperia lineup. This is likely an artifact from the original MDSS DSI panel driver where the calculation [1] corrected for a premultiplied reference framerate by 100 [2]. It does not appear that the above values were ever premultiplied in the history of the DRM MDP5 driver. With this change applied the value written to the SYNC_CONFIG_VSYNC register is now identical to downstream kernels. [1]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_mdp_intf_cmd.c?h=LA.UM.8.6.c26-02400-89xx.0#n288 [2]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_dsi_panel.c?h=LA.UM.8.6.c26-02400-89xx.0#n1648 Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index 2d5ac03dbc17..0bda4257823a 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -20,7 +20,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, { struct mdp5_kms *mdp5_kms = get_kms(encoder); struct device *dev = encoder->dev->dev; - u32 total_lines_x100, vclks_line, cfg; + u32 total_lines, vclks_line, cfg; long vsync_clk_speed; struct mdp5_hw_mixer *mixer = mdp5_crtc_get_mixer(encoder->crtc); int pp_id = mixer->pp; @@ -30,8 +30,8 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, return -EINVAL; } - total_lines_x100 = mode->vtotal * drm_mode_vrefresh(mode); - if (!total_lines_x100) { + total_lines = mode->vtotal * drm_mode_vrefresh(mode); + if (!total_lines) { DRM_DEV_ERROR(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n", __func__, mode->vtotal, drm_mode_vrefresh(mode)); return -EINVAL; @@ -43,7 +43,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, vsync_clk_speed); return -EINVAL; } - vclks_line = vsync_clk_speed * 100 / total_lines_x100; + vclks_line = vsync_clk_speed / total_lines; cfg = MDP5_PP_SYNC_CONFIG_VSYNC_COUNTER_EN | MDP5_PP_SYNC_CONFIG_VSYNC_IN_EN; -- 2.31.1 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/3] drm/msm/mdp5: Do not multiply vclk line count by 100 @ 2021-04-06 21:47 ` Marijn Suijten 0 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Martin Botka, ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Marijn Suijten, Sean Paul Neither vtotal nor drm_mode_vrefresh contain a value that is premultiplied by 100 making the x100 variable name incorrect and resulting in vclks_line to become 100 times larger than it is supposed to be. The hardware counts 100 clockticks too many before tearcheck, leading to severe panel issues on at least the Sony Xperia lineup. This is likely an artifact from the original MDSS DSI panel driver where the calculation [1] corrected for a premultiplied reference framerate by 100 [2]. It does not appear that the above values were ever premultiplied in the history of the DRM MDP5 driver. With this change applied the value written to the SYNC_CONFIG_VSYNC register is now identical to downstream kernels. [1]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_mdp_intf_cmd.c?h=LA.UM.8.6.c26-02400-89xx.0#n288 [2]: https://source.codeaurora.org/quic/la/kernel/msm-3.18/tree/drivers/video/msm/mdss/mdss_dsi_panel.c?h=LA.UM.8.6.c26-02400-89xx.0#n1648 Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index 2d5ac03dbc17..0bda4257823a 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -20,7 +20,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, { struct mdp5_kms *mdp5_kms = get_kms(encoder); struct device *dev = encoder->dev->dev; - u32 total_lines_x100, vclks_line, cfg; + u32 total_lines, vclks_line, cfg; long vsync_clk_speed; struct mdp5_hw_mixer *mixer = mdp5_crtc_get_mixer(encoder->crtc); int pp_id = mixer->pp; @@ -30,8 +30,8 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, return -EINVAL; } - total_lines_x100 = mode->vtotal * drm_mode_vrefresh(mode); - if (!total_lines_x100) { + total_lines = mode->vtotal * drm_mode_vrefresh(mode); + if (!total_lines) { DRM_DEV_ERROR(dev, "%s: vtotal(%d) or vrefresh(%d) is 0\n", __func__, mode->vtotal, drm_mode_vrefresh(mode)); return -EINVAL; @@ -43,7 +43,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, vsync_clk_speed); return -EINVAL; } - vclks_line = vsync_clk_speed * 100 / total_lines_x100; + vclks_line = vsync_clk_speed / total_lines; cfg = MDP5_PP_SYNC_CONFIG_VSYNC_COUNTER_EN | MDP5_PP_SYNC_CONFIG_VSYNC_IN_EN; -- 2.31.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init 2021-04-06 21:47 ` Marijn Suijten @ 2021-04-06 21:47 ` Marijn Suijten -1 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Konrad Dybcio, Martin Botka, Marijn Suijten, Rob Clark, Sean Paul, David Airlie, Daniel Vetter, Sai Prakash Ranjan, linux-arm-msm, dri-devel, freedreno, linux-kernel From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> If pp autorefresh is up (from bootloader splash), we will surely get vblank and pp timeouts. Ensure it is turned off. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index 0bda4257823a..66315b82dd6e 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -59,6 +59,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_THRESH(pp_id), MDP5_PP_SYNC_THRESH_START(4) | MDP5_PP_SYNC_THRESH_CONTINUE(4)); + mdp5_write(mdp5_kms, REG_MDP5_PP_AUTOREFRESH_CONFIG(pp_id), 0x0); return 0; } -- 2.31.1 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 3/3] drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init @ 2021-04-06 21:47 ` Marijn Suijten 0 siblings, 0 replies; 19+ messages in thread From: Marijn Suijten @ 2021-04-06 21:47 UTC (permalink / raw) To: phone-devel Cc: freedreno, Sai Prakash Ranjan, David Airlie, linux-arm-msm, Konrad Dybcio, linux-kernel, dri-devel, Martin Botka, ~postmarketos/upstreaming, AngeloGioacchino Del Regno, Marijn Suijten, Sean Paul From: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> If pp autorefresh is up (from bootloader splash), we will surely get vblank and pp timeouts. Ensure it is turned off. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c index 0bda4257823a..66315b82dd6e 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c @@ -59,6 +59,7 @@ static int pingpong_tearcheck_setup(struct drm_encoder *encoder, mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_THRESH(pp_id), MDP5_PP_SYNC_THRESH_START(4) | MDP5_PP_SYNC_THRESH_CONTINUE(4)); + mdp5_write(mdp5_kms, REG_MDP5_PP_AUTOREFRESH_CONFIG(pp_id), 0x0); return 0; } -- 2.31.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply related [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-04-09 8:22 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-06 21:47 [PATCH 0/3] drm/msm/mdp5: Emit vsync signal often enough Marijn Suijten 2021-04-06 21:47 ` Marijn Suijten 2021-04-06 21:47 ` [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal Marijn Suijten 2021-04-06 21:47 ` Marijn Suijten 2021-04-07 18:19 ` [Freedreno] " abhinavk 2021-04-07 18:19 ` abhinavk 2021-04-07 19:11 ` AngeloGioacchino Del Regno 2021-04-07 19:11 ` AngeloGioacchino Del Regno 2021-04-08 19:05 ` Rob Clark 2021-04-08 19:05 ` Rob Clark 2021-04-08 23:16 ` AngeloGioacchino Del Regno 2021-04-09 0:08 ` Rob Clark 2021-04-09 0:08 ` Rob Clark 2021-04-09 8:22 ` Marijn Suijten 2021-04-09 8:22 ` Marijn Suijten 2021-04-06 21:47 ` [PATCH 2/3] drm/msm/mdp5: Do not multiply vclk line count by 100 Marijn Suijten 2021-04-06 21:47 ` Marijn Suijten 2021-04-06 21:47 ` [PATCH 3/3] drm/msm/mdp5: Disable pingpong autorefresh at tearcheck init Marijn Suijten 2021-04-06 21:47 ` Marijn Suijten
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.