Add a function that returns whether the requested CTL is active or not: this will be used in a later commit to fix command mode panel issues.
Signed-off-by: AngeloGioacchino Del Regno angelogioacchino.delregno@somainline.org --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++++++ 2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c index 64740ddb983e..3b6fd73eb3a8 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c @@ -91,6 +91,11 @@ static inline void dpu_hw_ctl_trigger_start(struct dpu_hw_ctl *ctx) DPU_REG_WRITE(&ctx->hw, CTL_START, 0x1); }
+static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx) +{ + return !!(DPU_REG_READ(&ctx->hw, CTL_START) & BIT(0)); +} + static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx) { trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask, @@ -579,6 +584,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops, ops->get_pending_flush = dpu_hw_ctl_get_pending_flush; ops->get_flush_register = dpu_hw_ctl_get_flush_register; ops->trigger_start = dpu_hw_ctl_trigger_start; + ops->is_started = dpu_hw_ctl_is_started; ops->trigger_pending = dpu_hw_ctl_trigger_pending; ops->reset = dpu_hw_ctl_reset_control; ops->wait_reset_status = dpu_hw_ctl_wait_reset_status; diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h index 806c171e5df2..ac1544474022 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h @@ -61,6 +61,13 @@ struct dpu_hw_ctl_ops { */ void (*trigger_start)(struct dpu_hw_ctl *ctx);
+ /** + * check if the ctl is started + * @ctx : ctl path ctx pointer + * @Return: true if started, false if stopped + */ + bool (*is_started)(struct dpu_hw_ctl *ctx); + /** * kickoff prepare is in progress hw operation for sw * controlled interfaces: DSI cmd mode and WB interface
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(+)
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); }
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); }
On 11/09/2021 19:39, AngeloGioacchino Del Regno wrote:
Add a function that returns whether the requested CTL is active or not: this will be used in a later commit to fix command mode panel issues.
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_hw_ctl.c | 6 ++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++++++ 2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c index 64740ddb983e..3b6fd73eb3a8 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c @@ -91,6 +91,11 @@ static inline void dpu_hw_ctl_trigger_start(struct dpu_hw_ctl *ctx) DPU_REG_WRITE(&ctx->hw, CTL_START, 0x1); }
+static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx) +{
- return !!(DPU_REG_READ(&ctx->hw, CTL_START) & BIT(0));
+}
- static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx) { trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask,
@@ -579,6 +584,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops, ops->get_pending_flush = dpu_hw_ctl_get_pending_flush; ops->get_flush_register = dpu_hw_ctl_get_flush_register; ops->trigger_start = dpu_hw_ctl_trigger_start;
- ops->is_started = dpu_hw_ctl_is_started; ops->trigger_pending = dpu_hw_ctl_trigger_pending; ops->reset = dpu_hw_ctl_reset_control; ops->wait_reset_status = dpu_hw_ctl_wait_reset_status;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h index 806c171e5df2..ac1544474022 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h @@ -61,6 +61,13 @@ struct dpu_hw_ctl_ops { */ void (*trigger_start)(struct dpu_hw_ctl *ctx);
- /**
* check if the ctl is started* @ctx : ctl path ctx pointer* @Return: true if started, false if stopped*/- bool (*is_started)(struct dpu_hw_ctl *ctx);
- /**
- kickoff prepare is in progress hw operation for sw
- controlled interfaces: DSI cmd mode and WB interface
dri-devel@lists.freedesktop.org
-
AngeloGioacchino Del Regno -
Dmitry Baryshkov -
Marijn Suijten