[PATCH v2 1/2] drm/msm/dpu: Add a function to retrieve the current CTL status

[PATCH v2 1/2] drm/msm/dpu: Add a function to retrieve the current CTL status

[AngeloGioacchino Del Regno]

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
-- 
2.32.0

[PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[AngeloGioacchino Del Regno]

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);
 }
 
-- 
2.32.0

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Marijn Suijten]

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
> 

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Dmitry Baryshkov]

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);
>   }
>   
> 


-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[AngeloGioacchino Del Regno]

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).

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Marijn Suijten]

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

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Dmitry Baryshkov]

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?

-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Marijn Suijten]

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

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[AngeloGioacchino Del Regno]

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

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Marijn Suijten]

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

Re: [PATCH v2 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

[Dmitry Baryshkov]

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);
>   }
>   


-- 
With best wishes
Dmitry

Re: [PATCH v2 1/2] drm/msm/dpu: Add a function to retrieve the current CTL status

[Dmitry Baryshkov]

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


-- 
With best wishes
Dmitry