| Message ID | 20210911163919.47173-2-angelogioacchino.delregno@somainline.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/2] drm/msm/dpu: Add a function to retrieve the current CTL status | expand |
On 2021-09-11 18:39:19, AngeloGioacchino Del Regno wrote: > In function dpu_encoder_phys_cmd_wait_for_commit_done we are always > checking if the relative CTL is started by waiting for an interrupt > to fire: it is fine to do that, but then sometimes we call this > function while the CTL is up and has never been put down, but that > interrupt gets raised only when the CTL gets a state change from > 0 to 1 (disabled to enabled), so we're going to wait for something > that will never happen on its own. > > Solving this while avoiding to restart the CTL is actually possible > and can be done by just checking if it is already up and running > when the wait_for_commit_done function is called: in this case, so, > if the CTL was already running, we can say that the commit is done > if the command transmission is complete (in other terms, if the > interface has been flushed). > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> This has unfortunately not solved any ctl_start timeout issues for me/us on other platforms yet, but for the code: Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > index aa01698d6b25..aa5d3b3cef15 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > @@ -682,6 +682,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( > if (!dpu_encoder_phys_cmd_is_master(phys_enc)) > return 0; > > + if (phys_enc->hw_ctl->ops.is_started(phys_enc->hw_ctl)) > + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); > + > return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); > } > > -- > 2.32.0 >
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote: > In function dpu_encoder_phys_cmd_wait_for_commit_done we are always > checking if the relative CTL is started by waiting for an interrupt > to fire: it is fine to do that, but then sometimes we call this > function while the CTL is up and has never been put down, but that > interrupt gets raised only when the CTL gets a state change from > 0 to 1 (disabled to enabled), so we're going to wait for something > that will never happen on its own. > > Solving this while avoiding to restart the CTL is actually possible > and can be done by just checking if it is already up and running > when the wait_for_commit_done function is called: in this case, so, > if the CTL was already running, we can say that the commit is done > if the command transmission is complete (in other terms, if the > interface has been flushed). I've compared this with the MDP5 driver, where we always wait for PP_DONE interrupt. Would it be enough to always wait for it (= always call dpu_encoder_phys_cmd_wait_for_tx_complete())? > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > index aa01698d6b25..aa5d3b3cef15 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > @@ -682,6 +682,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( > if (!dpu_encoder_phys_cmd_is_master(phys_enc)) > return 0; > > + if (phys_enc->hw_ctl->ops.is_started(phys_enc->hw_ctl)) > + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); > + > return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); > } > >
Il 02/10/21 00:33, Dmitry Baryshkov ha scritto: > On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote: >> In function dpu_encoder_phys_cmd_wait_for_commit_done we are always >> checking if the relative CTL is started by waiting for an interrupt >> to fire: it is fine to do that, but then sometimes we call this >> function while the CTL is up and has never been put down, but that >> interrupt gets raised only when the CTL gets a state change from >> 0 to 1 (disabled to enabled), so we're going to wait for something >> that will never happen on its own. >> >> Solving this while avoiding to restart the CTL is actually possible >> and can be done by just checking if it is already up and running >> when the wait_for_commit_done function is called: in this case, so, >> if the CTL was already running, we can say that the commit is done >> if the command transmission is complete (in other terms, if the >> interface has been flushed). > > I've compared this with the MDP5 driver, where we always wait for PP_DONE > interrupt. Would it be enough to always wait for it (= always call > dpu_encoder_phys_cmd_wait_for_tx_complete())? > This sets my delay record to reply to two months. Great achievement! Jokes apart, yes it would make sense to do that, it's something that works at least... but we should verify that such a thing doesn't break new platforms (like sm8150 and newer).
On 2021-12-09 18:02:40, AngeloGioacchino Del Regno wrote: > Il 02/10/21 00:33, Dmitry Baryshkov ha scritto: > > On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote: > >> [..] > > I've compared this with the MDP5 driver, where we always wait for PP_DONE > > interrupt. Would it be enough to always wait for it (= always call > > dpu_encoder_phys_cmd_wait_for_tx_complete())? > > > > Jokes apart, yes it would make sense to do that, it's something that works > at least... but we should verify that such a thing doesn't break new platforms > (like sm8150 and newer). On sm6125 (keeping in mind that we're on llvmpipe, will bring up the GPU later) none of this hurts the display: - Without this patch, so only checking for wait_for_ctl_start; - With this patch, checking for idle if it was already started; - With this patch altered to only ever call wait_for_tx_complete (wait for idle), in place of wait_for_ctl_start. Working in the sense that glxgears, which actually reports a framerate of approx 170 despite being on llvmpipe on an SoC that is still in snail-mode, seems to update (commit) the panel smoothly on every occasion. On this note, does it perhaps make more sense to call the "internal" _dpu_encoder_phys_cmd_wait_for_idle function directly, instead of going through the "public" dpu_encoder_phys_cmd_wait_for_tx_complete which seems solely intended to handle the wait_for_tx_complete callback? - Marijn
On Sun, 12 Dec 2021 at 00:35, Marijn Suijten <marijn.suijten@somainline.org> wrote: > > On 2021-12-09 18:02:40, AngeloGioacchino Del Regno wrote: > > Il 02/10/21 00:33, Dmitry Baryshkov ha scritto: > > > On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote: > > >> [..] > > > I've compared this with the MDP5 driver, where we always wait for PP_DONE > > > interrupt. Would it be enough to always wait for it (= always call > > > dpu_encoder_phys_cmd_wait_for_tx_complete())? > > > > > > > Jokes apart, yes it would make sense to do that, it's something that works > > at least... but we should verify that such a thing doesn't break new platforms > > (like sm8150 and newer). > > On sm6125 (keeping in mind that we're on llvmpipe, will bring up the GPU > later) none of this hurts the display: > > - Without this patch, so only checking for wait_for_ctl_start; > - With this patch, checking for idle if it was already started; > - With this patch altered to only ever call wait_for_tx_complete (wait > for idle), in place of wait_for_ctl_start. > > Working in the sense that glxgears, which actually reports a framerate > of approx 170 despite being on llvmpipe on an SoC that is still in > snail-mode, seems to update (commit) the panel smoothly on every > occasion. > > On this note, does it perhaps make more sense to call the "internal" > _dpu_encoder_phys_cmd_wait_for_idle function directly, instead of going > through the "public" dpu_encoder_phys_cmd_wait_for_tx_complete which > seems solely intended to handle the wait_for_tx_complete callback? Either one would work. The main difference is the error message. Do you want to see it here if the wait times out or not?
On 2021-12-12 00:49:09, Dmitry Baryshkov wrote: > On Sun, 12 Dec 2021 at 00:35, Marijn Suijten > <marijn.suijten@somainline.org> wrote: > > [..] > > On this note, does it perhaps make more sense to call the "internal" > > _dpu_encoder_phys_cmd_wait_for_idle function directly, instead of going > > through the "public" dpu_encoder_phys_cmd_wait_for_tx_complete which > > seems solely intended to handle the wait_for_tx_complete callback? > > Either one would work. The main difference is the error message. Do > you want to see it here if the wait times out or not? I prefer calling _dpu_encoder_phys_cmd_wait_for_idle directly and optionally adding our own error message. IIRC DRM_ERROR prints source information such as the function this originated from, and that makes it impossible to distinguish between the wait_for_tx_complete callback or the invocation through dpu_encoder_phys_cmd_wait_for_commit_done anyway. - Marijn
Il 11/12/21 22:57, Marijn Suijten ha scritto: > On 2021-12-12 00:49:09, Dmitry Baryshkov wrote: >> On Sun, 12 Dec 2021 at 00:35, Marijn Suijten >> <marijn.suijten@somainline.org> wrote: >>> [..] >>> On this note, does it perhaps make more sense to call the "internal" >>> _dpu_encoder_phys_cmd_wait_for_idle function directly, instead of going >>> through the "public" dpu_encoder_phys_cmd_wait_for_tx_complete which >>> seems solely intended to handle the wait_for_tx_complete callback? >> >> Either one would work. The main difference is the error message. Do >> you want to see it here if the wait times out or not? > > I prefer calling _dpu_encoder_phys_cmd_wait_for_idle directly and > optionally adding our own error message. IIRC DRM_ERROR prints source > information such as the function this originated from, and that makes it > impossible to distinguish between the wait_for_tx_complete callback or > the invocation through dpu_encoder_phys_cmd_wait_for_commit_done anyway. > > - Marijn > I wouldn't be happy to find myself in a situation in which I get strange display slowness without any print to help me; for this reason, I find having the print in place useful for debugging of both perf and fault. Cheers, - Angelo
On 2021-12-22 12:28:52, AngeloGioacchino Del Regno wrote: > Il 11/12/21 22:57, Marijn Suijten ha scritto: > > On 2021-12-12 00:49:09, Dmitry Baryshkov wrote: > >> On Sun, 12 Dec 2021 at 00:35, Marijn Suijten > >> <marijn.suijten@somainline.org> wrote: > >>> [..] > >>> On this note, does it perhaps make more sense to call the "internal" > >>> _dpu_encoder_phys_cmd_wait_for_idle function directly, instead of going > >>> through the "public" dpu_encoder_phys_cmd_wait_for_tx_complete which > >>> seems solely intended to handle the wait_for_tx_complete callback? > >> > >> Either one would work. The main difference is the error message. Do > >> you want to see it here if the wait times out or not? > > > > I prefer calling _dpu_encoder_phys_cmd_wait_for_idle directly and > > optionally adding our own error message. IIRC DRM_ERROR prints source > > information such as the function this originated from, and that makes it > > impossible to distinguish between the wait_for_tx_complete callback or > > the invocation through dpu_encoder_phys_cmd_wait_for_commit_done anyway. > > > > - Marijn > > > > I wouldn't be happy to find myself in a situation in which I get strange > display slowness without any print to help me; for this reason, I find > having the print in place useful for debugging of both perf and fault. Same thought here, though dpu_encoder_phys_cmd_wait_for_tx_complete exists for the sole reason of printing a nice debug message, which I wouldn't want to be misused by dpu_encoder_phys_cmd_wait_for_commit_done punting its errors on wait_for_tx_complete - if that happens the first thing I'd do during debugging is assign individual messages to both, otherwise it is impossible to know which two functions is the cause: we might as well "duplicate" the error message right now and prevent such confusion from occurring in the first place? - Marijn > > Cheers, > - Angelo
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote: > In function dpu_encoder_phys_cmd_wait_for_commit_done we are always > checking if the relative CTL is started by waiting for an interrupt > to fire: it is fine to do that, but then sometimes we call this > function while the CTL is up and has never been put down, but that > interrupt gets raised only when the CTL gets a state change from > 0 to 1 (disabled to enabled), so we're going to wait for something > that will never happen on its own. > > Solving this while avoiding to restart the CTL is actually possible > and can be done by just checking if it is already up and running > when the wait_for_commit_done function is called: in this case, so, > if the CTL was already running, we can say that the commit is done > if the command transmission is complete (in other terms, if the > interface has been flushed). > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > index aa01698d6b25..aa5d3b3cef15 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c > @@ -682,6 +682,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( > if (!dpu_encoder_phys_cmd_is_master(phys_enc)) > return 0; > > + if (phys_enc->hw_ctl->ops.is_started(phys_enc->hw_ctl)) > + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); > + > return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); > } >
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index aa01698d6b25..aa5d3b3cef15 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -682,6 +682,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( if (!dpu_encoder_phys_cmd_is_master(phys_enc)) return 0; + if (phys_enc->hw_ctl->ops.is_started(phys_enc->hw_ctl)) + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); + return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); }
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ 1 file changed, 3 insertions(+)