diff mbox series

[RESEND,v0,3/5] wave5 : Support runtime suspend/resume.

Message ID 20240131013046.15687-4-jackson.lee@chipsnmedia.com
State New
Headers show
Series wave5 codec driver | expand

Commit Message

jackson.lee Jan. 31, 2024, 1:30 a.m. UTC
There are two device run-time PM callbacks defined in 'struct dev_pm_ops'
int (*runtime_suspend)(struct device *dev);
int (*runtime_resume)(struct device *dev);

Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
---
 .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
 .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
 .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
 .../platform/chips-media/wave5/wave5-vpu.c    | 68 +++++++++++++++++++
 .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
 .../media/platform/chips-media/wave5/wave5.h  |  3 +
 6 files changed, 99 insertions(+), 2 deletions(-)

Comments

Nicolas Dufresne Feb. 7, 2024, 6:29 p.m. UTC | #1
Hi Jackson,

Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a écrit :
> There are two device run-time PM callbacks defined in 'struct dev_pm_ops'
> int (*runtime_suspend)(struct device *dev);
> int (*runtime_resume)(struct device *dev);

I wonder how useful is it to teach everyone what the generic 'struct dev_pm_ops'
contains. Perhaps you simply wanted that this patch implement both suspend and
resume ops ?

> 
> Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> ---
>  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
>  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
>  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
>  .../platform/chips-media/wave5/wave5-vpu.c    | 68 +++++++++++++++++++
>  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
>  .../media/platform/chips-media/wave5/wave5.h  |  3 +
>  6 files changed, 99 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/chips-media/wave5/wave5-hw.c b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> index 8ad7f3a28ae1..8aade5a38439 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> @@ -503,6 +503,7 @@ int wave5_vpu_build_up_dec_param(struct vpu_instance *inst,
>  	/* This register must be reset explicitly */
>  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
>  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1, (COMMAND_QUEUE_DEPTH - 1));
> +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);

In some way, the relation between suspend and this register write is not
obvious. If its not related, please do this in its own patch. Otherwise you want
to explain why you needed this (possibly just in the commit message).

>  
>  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true, NULL, NULL);
>  	if (ret) {
> @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct device *dev, u8 *fw, size_t size)
>  	return setup_wave5_properties(dev);
>  }
>  
> -static int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const uint16_t *code,
> -				size_t size)
> +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const uint16_t *code,
> +			 size_t size)
>  {
>  	u32 reg_val;
>  	struct vpu_buf *common_vb;
> diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> index ef227af72348..328a7a8f26c5 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> @@ -5,6 +5,7 @@
>   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
>   */
>  
> +#include <linux/pm_runtime.h>
>  #include "wave5-helper.h"
>  
>  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> @@ -1387,9 +1388,17 @@ static int wave5_vpu_dec_start_streaming(struct vb2_queue *q, unsigned int count
>  
>  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst->state == VPU_INST_STATE_NONE) {
>  		struct dec_open_param open_param;
> +		int err = 0;
>  
>  		memset(&open_param, 0, sizeof(struct dec_open_param));
>  
> +		err = pm_runtime_resume_and_get(inst->dev->dev);
> +		if (err) {
> +			dev_err(inst->dev->dev, "decoder runtime resume failed %d\n", err);
> +			ret = -EINVAL;
> +			goto return_buffers;
> +		}
> +
>  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
>  		if (ret)
>  			goto return_buffers;
> diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> index 761775216cd4..ff73d69de41c 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> @@ -5,6 +5,7 @@
>   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
>   */
>  
> +#include <linux/pm_runtime.h>
>  #include "wave5-helper.h"
>  
>  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> @@ -1387,9 +1388,17 @@ static int wave5_vpu_enc_start_streaming(struct vb2_queue *q, unsigned int count
>  
>  	if (inst->state == VPU_INST_STATE_NONE && q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
>  		struct enc_open_param open_param;
> +		int err = 0;
>  
>  		memset(&open_param, 0, sizeof(struct enc_open_param));
>  
> +		err = pm_runtime_resume_and_get(inst->dev->dev);
> +		if (err) {
> +			dev_err(inst->dev->dev, "encoder runtime resume failed %d\n", err);
> +			ret = -EINVAL;
> +			goto return_buffers;
> +		}
> +
>  		wave5_set_enc_openparam(&open_param, inst);
>  
>  		ret = wave5_vpu_enc_open(inst, &open_param);
> diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> index 0d90b5820bef..f81409740a56 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> @@ -10,6 +10,7 @@
>  #include <linux/clk.h>
>  #include <linux/firmware.h>
>  #include <linux/interrupt.h>
> +#include <linux/pm_runtime.h>
>  #include "wave5-vpu.h"
>  #include "wave5-regdefine.h"
>  #include "wave5-vpuconfig.h"
> @@ -117,6 +118,65 @@ static int wave5_vpu_load_firmware(struct device *dev, const char *fw_name,
>  	return 0;
>  }
>  
> +static __maybe_unused int wave5_pm_suspend(struct device *dev)
> +{
> +	struct vpu_device *vpu = dev_get_drvdata(dev);
> +
> +	if (pm_runtime_suspended(dev))
> +		return 0;
> +
> +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> +
> +	return 0;
> +}
> +
> +static __maybe_unused int wave5_pm_resume(struct device *dev)
> +{
> +	struct vpu_device *vpu = dev_get_drvdata(dev);
> +	int ret = 0;
> +
> +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
> +	if (ret) {
> +		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
> +		return ret;
> +	}
> +
> +	return ret;
> +}
> +
> +static __maybe_unused int wave5_suspend(struct device *dev)
> +{
> +	struct vpu_device *vpu = dev_get_drvdata(dev);
> +	struct vpu_instance *inst;
> +
> +	list_for_each_entry(inst, &vpu->instances, list)
> +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> +
> +	return pm_runtime_force_suspend(dev);
> +}
> +
> +static __maybe_unused int wave5_resume(struct device *dev)
> +{
> +	struct vpu_device *vpu = dev_get_drvdata(dev);
> +	struct vpu_instance *inst;
> +	int ret = 0;
> +
> +	ret = pm_runtime_force_resume(dev);
> +	if (ret < 0)
> +		return ret;
> +
> +	list_for_each_entry(inst, &vpu->instances, list)
> +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> +
> +	return ret;
> +}

The functions wave5_suspend() and wave5_resume() are not just "maybe_unsued" but
actually never used. What was the intention ? Considering the usage of
__maybe_unused has been such a bad friend for this one, could you instead
bracket the functions with an explicit ?

#ifdef CONFIG_PM
#endif

This way the compiler will have a word if you implement something that you
forgot to actually use.

> +
> +static const struct dev_pm_ops wave5_pm_ops = {
> +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume, NULL)
> +};
> +
>  static int wave5_vpu_probe(struct platform_device *pdev)
>  {
>  	int ret;
> @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct platform_device *pdev)
>  		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
>  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev->product_code);
>  	dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision);
> +
> +	pm_runtime_enable(&pdev->dev);
> +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> +
>  	return 0;
>  
>  err_enc_unreg:
> @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct platform_device *pdev)
>  {
>  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
>  
> +	pm_runtime_put_sync(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
> +
>  	mutex_destroy(&dev->dev_lock);
>  	mutex_destroy(&dev->hw_lock);
>  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks);
> @@ -281,6 +348,7 @@ static struct platform_driver wave5_vpu_driver = {
>  	.driver = {
>  		.name = VPU_PLATFORM_DEVICE_NAME,
>  		.of_match_table = of_match_ptr(wave5_dt_ids),
> +		.pm = &wave5_pm_ops,
>  		},
>  	.probe = wave5_vpu_probe,
>  	.remove = wave5_vpu_remove,
> diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> index 1a3efb638dde..f1f8e4fc8474 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include <linux/bug.h>
> +#include <linux/pm_runtime.h>
>  #include "wave5-vpuapi.h"
>  #include "wave5-regdefine.h"
>  #include "wave5.h"
> @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct vpu_instance *inst, u32 *fail_res)
>  
>  	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
>  
> +	if (!pm_runtime_suspended(inst->dev->dev))
> +		pm_runtime_put_sync(inst->dev->dev);
> +
>  unlock_and_return:
>  	mutex_unlock(&vpu_dev->hw_lock);
>  
> @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct vpu_instance *inst, u32 *fail_res)
>  
>  	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
>  
> +	if (!pm_runtime_suspended(inst->dev->dev))
> +		pm_runtime_put_sync(inst->dev->dev);

This seems very unnatural. We do the get() in "start_streaming()", but the put()
is only done when the device is closed, or when the driver is removed. As this
is not balanced, you seem to have to check the suspended condition all over the
place.

I think we could aim for start_streaming()/stop_streaming() for your get/put
placement. At least they will be bound to an entirely balanced API. But then, a
media player in paused sate will prevent that device from being suspended.

If the HW is capable of preserving enough state, and From the short doc I have
it gives me the impression it can preserve that, I'd suggest to follow what
hantro driver is doing. What is does is that it will do get() in device_run(),
and put() whenever the job completes. This driver has been designed so when
there is no job, it means the firmware is currently idle and looking for more
work. So it seems like the perfect moment to do suspend it.

Nicolas

> +
>  	mutex_unlock(&vpu_dev->hw_lock);
>  
>  	return 0;
> diff --git a/drivers/media/platform/chips-media/wave5/wave5.h b/drivers/media/platform/chips-media/wave5/wave5.h
> index 063028eccd3b..6125eff938a8 100644
> --- a/drivers/media/platform/chips-media/wave5/wave5.h
> +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct vpu_device *vpu_dev, u32 *revision);
>  
>  int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
>  
> +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const uint16_t *code,
> +			 size_t size);
> +
>  int wave5_vpu_reset(struct device *dev, enum sw_reset_mode reset_mode);
>  
>  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst, struct dec_open_param *param);
jackson.lee Feb. 19, 2024, 4:04 a.m. UTC | #2
Hi Nicolas


> This seems very unnatural. We do the get() in "start_streaming()", but the
> put() is only done when the device is closed, or when the driver is
> removed. As this is not balanced, you seem to have to check the suspended
> condition all over the place.
> 
> I think we could aim for start_streaming()/stop_streaming() for your
> get/put placement. At least they will be bound to an entirely balanced API.
> But then, a media player in paused sate will prevent that device from
> being suspended.
> 
> If the HW is capable of preserving enough state, and From the short doc I
> have it gives me the impression it can preserve that, I'd suggest to
> follow what hantro driver is doing. What is does is that it will do get()
> in device_run(), and put() whenever the job completes. This driver has
> been designed so when there is no job, it means the firmware is currently
> idle and looking for more work. So it seems like the perfect moment to do
> suspend it.
>

Thanks your comment,

Currently they are not balanced, 
If we puts "the put functon" into the stop_streaming, our hw is stalled until doing wake-up command, so our v4l2 device become block.
so I'd like to update the below instead of calling get at the start_streaming function.


@@ -1867,6 +1868,13 @@ static int wave5_vpu_open_dec(struct file *filp)

        wave5_vdi_allocate_sram(inst->dev);

+       err = pm_runtime_resume_and_get(inst->dev->dev);
+       if (err) {
+               dev_err(inst->dev->dev, "decoder runtime resume failed %d\n", err);
+               ret = -EINVAL;
+               goto cleanup_inst;
+       }
+
        return 0;




> Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a écrit :
> > There are two device run-time PM callbacks defined in 'struct
> dev_pm_ops'
> > int (*runtime_suspend)(struct device *dev); int
> > (*runtime_resume)(struct device *dev);
> 
> I wonder how useful is it to teach everyone what the generic 'struct
> dev_pm_ops'
> contains. Perhaps you simply wanted that this patch implement both suspend
> and resume ops ?
> 
> >
> > Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > ---
> >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> >  .../platform/chips-media/wave5/wave5-vpu.c    | 68 +++++++++++++++++++
> >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
> > .../media/platform/chips-media/wave5/wave5.h  |  3 +
> >  6 files changed, 99 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > index 8ad7f3a28ae1..8aade5a38439 100644
> > --- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > @@ -503,6 +503,7 @@ int wave5_vpu_build_up_dec_param(struct vpu_instance
> *inst,
> >  	/* This register must be reset explicitly */
> >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > (COMMAND_QUEUE_DEPTH - 1));
> > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> 
> In some way, the relation between suspend and this register write is not
> obvious. If its not related, please do this in its own patch. Otherwise
> you want to explain why you needed this (possibly just in the commit
> message).
> 
> >
> >  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true, NULL,
> NULL);
> >  	if (ret) {
> > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct device *dev, u8 *fw,
> size_t size)
> >  	return setup_wave5_properties(dev);
> >  }
> >
> > -static int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake,
> const uint16_t *code,
> > -				size_t size)
> > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const
> uint16_t *code,
> > +			 size_t size)
> >  {
> >  	u32 reg_val;
> >  	struct vpu_buf *common_vb;
> > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > index ef227af72348..328a7a8f26c5 100644
> > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > @@ -5,6 +5,7 @@
> >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> >   */
> >
> > +#include <linux/pm_runtime.h>
> >  #include "wave5-helper.h"
> >
> >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > @@ -1387,9 +1388,17 @@ static int wave5_vpu_dec_start_streaming(struct
> > vb2_queue *q, unsigned int count
> >
> >  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst->state ==
> VPU_INST_STATE_NONE) {
> >  		struct dec_open_param open_param;
> > +		int err = 0;
> >
> >  		memset(&open_param, 0, sizeof(struct dec_open_param));
> >
> > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > +		if (err) {
> > +			dev_err(inst->dev->dev, "decoder runtime resume
> failed %d\n", err);
> > +			ret = -EINVAL;
> > +			goto return_buffers;
> > +		}
> > +
> >  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
> >  		if (ret)
> >  			goto return_buffers;
> > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > index 761775216cd4..ff73d69de41c 100644
> > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > @@ -5,6 +5,7 @@
> >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> >   */
> >
> > +#include <linux/pm_runtime.h>
> >  #include "wave5-helper.h"
> >
> >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > @@ -1387,9 +1388,17 @@ static int wave5_vpu_enc_start_streaming(struct
> > vb2_queue *q, unsigned int count
> >
> >  	if (inst->state == VPU_INST_STATE_NONE && q->type ==
> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> >  		struct enc_open_param open_param;
> > +		int err = 0;
> >
> >  		memset(&open_param, 0, sizeof(struct enc_open_param));
> >
> > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > +		if (err) {
> > +			dev_err(inst->dev->dev, "encoder runtime resume
> failed %d\n", err);
> > +			ret = -EINVAL;
> > +			goto return_buffers;
> > +		}
> > +
> >  		wave5_set_enc_openparam(&open_param, inst);
> >
> >  		ret = wave5_vpu_enc_open(inst, &open_param); diff --git
> > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > index 0d90b5820bef..f81409740a56 100644
> > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > @@ -10,6 +10,7 @@
> >  #include <linux/clk.h>
> >  #include <linux/firmware.h>
> >  #include <linux/interrupt.h>
> > +#include <linux/pm_runtime.h>
> >  #include "wave5-vpu.h"
> >  #include "wave5-regdefine.h"
> >  #include "wave5-vpuconfig.h"
> > @@ -117,6 +118,65 @@ static int wave5_vpu_load_firmware(struct device
> *dev, const char *fw_name,
> >  	return 0;
> >  }
> >
> > +static __maybe_unused int wave5_pm_suspend(struct device *dev) {
> > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > +
> > +	if (pm_runtime_suspended(dev))
> > +		return 0;
> > +
> > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> > +
> > +	return 0;
> > +}
> > +
> > +static __maybe_unused int wave5_pm_resume(struct device *dev) {
> > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > +	int ret = 0;
> > +
> > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
> > +	if (ret) {
> > +		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return ret;
> > +}
> > +
> > +static __maybe_unused int wave5_suspend(struct device *dev) {
> > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > +	struct vpu_instance *inst;
> > +
> > +	list_for_each_entry(inst, &vpu->instances, list)
> > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > +
> > +	return pm_runtime_force_suspend(dev); }
> > +
> > +static __maybe_unused int wave5_resume(struct device *dev) {
> > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > +	struct vpu_instance *inst;
> > +	int ret = 0;
> > +
> > +	ret = pm_runtime_force_resume(dev);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	list_for_each_entry(inst, &vpu->instances, list)
> > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > +
> > +	return ret;
> > +}
> 
> The functions wave5_suspend() and wave5_resume() are not just
> "maybe_unsued" but actually never used. What was the intention ?
> Considering the usage of __maybe_unused has been such a bad friend for
> this one, could you instead bracket the functions with an explicit ?
> 
> #ifdef CONFIG_PM
> #endif
> 
> This way the compiler will have a word if you implement something that you
> forgot to actually use.
> 
> > +
> > +static const struct dev_pm_ops wave5_pm_ops = {
> > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume, NULL) };
> > +
> >  static int wave5_vpu_probe(struct platform_device *pdev)  {
> >  	int ret;
> > @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct platform_device
> *pdev)
> >  		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
> >  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev->product_code);
> >  	dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision);
> > +
> > +	pm_runtime_enable(&pdev->dev);
> > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > +
> >  	return 0;
> >
> >  err_enc_unreg:
> > @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct platform_device
> > *pdev)  {
> >  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
> >
> > +	pm_runtime_put_sync(&pdev->dev);
> > +	pm_runtime_disable(&pdev->dev);
> > +
> >  	mutex_destroy(&dev->dev_lock);
> >  	mutex_destroy(&dev->hw_lock);
> >  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks); @@ -281,6
> > +348,7 @@ static struct platform_driver wave5_vpu_driver = {
> >  	.driver = {
> >  		.name = VPU_PLATFORM_DEVICE_NAME,
> >  		.of_match_table = of_match_ptr(wave5_dt_ids),
> > +		.pm = &wave5_pm_ops,
> >  		},
> >  	.probe = wave5_vpu_probe,
> >  	.remove = wave5_vpu_remove,
> > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > index 1a3efb638dde..f1f8e4fc8474 100644
> > --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > @@ -6,6 +6,7 @@
> >   */
> >
> >  #include <linux/bug.h>
> > +#include <linux/pm_runtime.h>
> >  #include "wave5-vpuapi.h"
> >  #include "wave5-regdefine.h"
> >  #include "wave5.h"
> > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct vpu_instance *inst,
> > u32 *fail_res)
> >
> >  	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
> >
> > +	if (!pm_runtime_suspended(inst->dev->dev))
> > +		pm_runtime_put_sync(inst->dev->dev);
> > +
> >  unlock_and_return:
> >  	mutex_unlock(&vpu_dev->hw_lock);
> >
> > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct vpu_instance *inst,
> > u32 *fail_res)
> >
> >  	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
> >
> > +	if (!pm_runtime_suspended(inst->dev->dev))
> > +		pm_runtime_put_sync(inst->dev->dev);
> 
> This seems very unnatural. We do the get() in "start_streaming()", but the
> put() is only done when the device is closed, or when the driver is
> removed. As this is not balanced, you seem to have to check the suspended
> condition all over the place.
> 
> I think we could aim for start_streaming()/stop_streaming() for your
> get/put placement. At least they will be bound to an entirely balanced API.
> But then, a media player in paused sate will prevent that device from
> being suspended.
> 
> If the HW is capable of preserving enough state, and From the short doc I
> have it gives me the impression it can preserve that, I'd suggest to
> follow what hantro driver is doing. What is does is that it will do get()
> in device_run(), and put() whenever the job completes. This driver has
> been designed so when there is no job, it means the firmware is currently
> idle and looking for more work. So it seems like the perfect moment to do
> suspend it.
> 
> Nicolas
> 
> > +
> >  	mutex_unlock(&vpu_dev->hw_lock);
> >
> >  	return 0;
> > diff --git a/drivers/media/platform/chips-media/wave5/wave5.h
> > b/drivers/media/platform/chips-media/wave5/wave5.h
> > index 063028eccd3b..6125eff938a8 100644
> > --- a/drivers/media/platform/chips-media/wave5/wave5.h
> > +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct vpu_device
> > *vpu_dev, u32 *revision);
> >
> >  int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
> >
> > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const
> uint16_t *code,
> > +			 size_t size);
> > +
> >  int wave5_vpu_reset(struct device *dev, enum sw_reset_mode
> > reset_mode);
> >
> >  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst, struct
> > dec_open_param *param);
Nicolas Dufresne Feb. 19, 2024, 9:20 p.m. UTC | #3
Hi Jackson,

Le lundi 19 février 2024 à 04:04 +0000, jackson.lee a écrit :
> Hi Nicolas
> 
> 
> > This seems very unnatural. We do the get() in "start_streaming()", but the
> > put() is only done when the device is closed, or when the driver is
> > removed. As this is not balanced, you seem to have to check the suspended
> > condition all over the place.
> > 
> > I think we could aim for start_streaming()/stop_streaming() for your
> > get/put placement. At least they will be bound to an entirely balanced API.
> > But then, a media player in paused sate will prevent that device from
> > being suspended.
> > 
> > If the HW is capable of preserving enough state, and From the short doc I
> > have it gives me the impression it can preserve that, I'd suggest to
> > follow what hantro driver is doing. What is does is that it will do get()
> > in device_run(), and put() whenever the job completes. This driver has
> > been designed so when there is no job, it means the firmware is currently
> > idle and looking for more work. So it seems like the perfect moment to do
> > suspend it.
> > 
> 
> Thanks your comment,
> 
> Currently they are not balanced, 
> If we puts "the put functon" into the stop_streaming, our hw is stalled until doing wake-up command, so our v4l2 device become block.
> so I'd like to update the below instead of calling get at the start_streaming function.
> 
> 
> @@ -1867,6 +1868,13 @@ static int wave5_vpu_open_dec(struct file *filp)
> 
>         wave5_vdi_allocate_sram(inst->dev);
> 
> +       err = pm_runtime_resume_and_get(inst->dev->dev);
> +       if (err) {
> +               dev_err(inst->dev->dev, "decoder runtime resume failed %d\n", err);
> +               ret = -EINVAL;
> +               goto cleanup_inst;
> +       }
> +
>         return 0;

I guess we need to discuss the power management strategy for this device. If you
do resume_and_get() in open(), and then put in close(), that seems balanced. But
in term of power saving, it might not be very strong. If you have a media player
that is set to pause and then placed in the background, you still keep the IP
running. This is extremely common, since application cannot close their device
without loosing the reference frames, and thus having to do extra work on resume
to seek back to the previous sync point and drop unneeded frames.

It seems like the whole point of asking the firmware to save the state and
suspend is to be able to do so while there is meaningful sate in the firt place.
If we are to suspend only when there is no meaningful state, we could just free
all resources and power it off completely. (This is just for illustration, its
probably to slow to boot the firmware at runtime)


I understand you suffered lockup with a start_streaming() for resume_and_get(),
and stop_streaming() for put(), this may simply indicate that some hardware
access are needed between these two. Can you write down a power management plan
that would effectively save power in common use cases ? We can certainly help in
refactoring the code to make that happen.

Nicolas

> 
> > Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a écrit :
> > > There are two device run-time PM callbacks defined in 'struct
> > dev_pm_ops'
> > > int (*runtime_suspend)(struct device *dev); int
> > > (*runtime_resume)(struct device *dev);
> > 
> > I wonder how useful is it to teach everyone what the generic 'struct
> > dev_pm_ops'
> > contains. Perhaps you simply wanted that this patch implement both suspend
> > and resume ops ?
> > 
> > > 
> > > Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> > > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > > ---
> > >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> > >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> > >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> > >  .../platform/chips-media/wave5/wave5-vpu.c    | 68 +++++++++++++++++++
> > >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
> > > .../media/platform/chips-media/wave5/wave5.h  |  3 +
> > >  6 files changed, 99 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > index 8ad7f3a28ae1..8aade5a38439 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > @@ -503,6 +503,7 @@ int wave5_vpu_build_up_dec_param(struct vpu_instance
> > *inst,
> > >  	/* This register must be reset explicitly */
> > >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> > >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > > (COMMAND_QUEUE_DEPTH - 1));
> > > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> > 
> > In some way, the relation between suspend and this register write is not
> > obvious. If its not related, please do this in its own patch. Otherwise
> > you want to explain why you needed this (possibly just in the commit
> > message).
> > 
> > > 
> > >  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true, NULL,
> > NULL);
> > >  	if (ret) {
> > > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct device *dev, u8 *fw,
> > size_t size)
> > >  	return setup_wave5_properties(dev);
> > >  }
> > > 
> > > -static int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake,
> > const uint16_t *code,
> > > -				size_t size)
> > > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const
> > uint16_t *code,
> > > +			 size_t size)
> > >  {
> > >  	u32 reg_val;
> > >  	struct vpu_buf *common_vb;
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > index ef227af72348..328a7a8f26c5 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > @@ -5,6 +5,7 @@
> > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > >   */
> > > 
> > > +#include <linux/pm_runtime.h>
> > >  #include "wave5-helper.h"
> > > 
> > >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > > @@ -1387,9 +1388,17 @@ static int wave5_vpu_dec_start_streaming(struct
> > > vb2_queue *q, unsigned int count
> > > 
> > >  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst->state ==
> > VPU_INST_STATE_NONE) {
> > >  		struct dec_open_param open_param;
> > > +		int err = 0;
> > > 
> > >  		memset(&open_param, 0, sizeof(struct dec_open_param));
> > > 
> > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > +		if (err) {
> > > +			dev_err(inst->dev->dev, "decoder runtime resume
> > failed %d\n", err);
> > > +			ret = -EINVAL;
> > > +			goto return_buffers;
> > > +		}
> > > +
> > >  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
> > >  		if (ret)
> > >  			goto return_buffers;
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > index 761775216cd4..ff73d69de41c 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > @@ -5,6 +5,7 @@
> > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > >   */
> > > 
> > > +#include <linux/pm_runtime.h>
> > >  #include "wave5-helper.h"
> > > 
> > >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > > @@ -1387,9 +1388,17 @@ static int wave5_vpu_enc_start_streaming(struct
> > > vb2_queue *q, unsigned int count
> > > 
> > >  	if (inst->state == VPU_INST_STATE_NONE && q->type ==
> > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > >  		struct enc_open_param open_param;
> > > +		int err = 0;
> > > 
> > >  		memset(&open_param, 0, sizeof(struct enc_open_param));
> > > 
> > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > +		if (err) {
> > > +			dev_err(inst->dev->dev, "encoder runtime resume
> > failed %d\n", err);
> > > +			ret = -EINVAL;
> > > +			goto return_buffers;
> > > +		}
> > > +
> > >  		wave5_set_enc_openparam(&open_param, inst);
> > > 
> > >  		ret = wave5_vpu_enc_open(inst, &open_param); diff --git
> > > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > index 0d90b5820bef..f81409740a56 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > @@ -10,6 +10,7 @@
> > >  #include <linux/clk.h>
> > >  #include <linux/firmware.h>
> > >  #include <linux/interrupt.h>
> > > +#include <linux/pm_runtime.h>
> > >  #include "wave5-vpu.h"
> > >  #include "wave5-regdefine.h"
> > >  #include "wave5-vpuconfig.h"
> > > @@ -117,6 +118,65 @@ static int wave5_vpu_load_firmware(struct device
> > *dev, const char *fw_name,
> > >  	return 0;
> > >  }
> > > 
> > > +static __maybe_unused int wave5_pm_suspend(struct device *dev) {
> > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > +
> > > +	if (pm_runtime_suspended(dev))
> > > +		return 0;
> > > +
> > > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > > +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +static __maybe_unused int wave5_pm_resume(struct device *dev) {
> > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > +	int ret = 0;
> > > +
> > > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > > +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
> > > +	if (ret) {
> > > +		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
> > > +		return ret;
> > > +	}
> > > +
> > > +	return ret;
> > > +}
> > > +
> > > +static __maybe_unused int wave5_suspend(struct device *dev) {
> > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > +	struct vpu_instance *inst;
> > > +
> > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > > +
> > > +	return pm_runtime_force_suspend(dev); }
> > > +
> > > +static __maybe_unused int wave5_resume(struct device *dev) {
> > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > +	struct vpu_instance *inst;
> > > +	int ret = 0;
> > > +
> > > +	ret = pm_runtime_force_resume(dev);
> > > +	if (ret < 0)
> > > +		return ret;
> > > +
> > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > > +
> > > +	return ret;
> > > +}
> > 
> > The functions wave5_suspend() and wave5_resume() are not just
> > "maybe_unsued" but actually never used. What was the intention ?
> > Considering the usage of __maybe_unused has been such a bad friend for
> > this one, could you instead bracket the functions with an explicit ?
> > 
> > #ifdef CONFIG_PM
> > #endif
> > 
> > This way the compiler will have a word if you implement something that you
> > forgot to actually use.
> > 
> > > +
> > > +static const struct dev_pm_ops wave5_pm_ops = {
> > > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume, NULL) };
> > > +
> > >  static int wave5_vpu_probe(struct platform_device *pdev)  {
> > >  	int ret;
> > > @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct platform_device
> > *pdev)
> > >  		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
> > >  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev->product_code);
> > >  	dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision);
> > > +
> > > +	pm_runtime_enable(&pdev->dev);
> > > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > > +
> > >  	return 0;
> > > 
> > >  err_enc_unreg:
> > > @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct platform_device
> > > *pdev)  {
> > >  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
> > > 
> > > +	pm_runtime_put_sync(&pdev->dev);
> > > +	pm_runtime_disable(&pdev->dev);
> > > +
> > >  	mutex_destroy(&dev->dev_lock);
> > >  	mutex_destroy(&dev->hw_lock);
> > >  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks); @@ -281,6
> > > +348,7 @@ static struct platform_driver wave5_vpu_driver = {
> > >  	.driver = {
> > >  		.name = VPU_PLATFORM_DEVICE_NAME,
> > >  		.of_match_table = of_match_ptr(wave5_dt_ids),
> > > +		.pm = &wave5_pm_ops,
> > >  		},
> > >  	.probe = wave5_vpu_probe,
> > >  	.remove = wave5_vpu_remove,
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > index 1a3efb638dde..f1f8e4fc8474 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > @@ -6,6 +6,7 @@
> > >   */
> > > 
> > >  #include <linux/bug.h>
> > > +#include <linux/pm_runtime.h>
> > >  #include "wave5-vpuapi.h"
> > >  #include "wave5-regdefine.h"
> > >  #include "wave5.h"
> > > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct vpu_instance *inst,
> > > u32 *fail_res)
> > > 
> > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
> > > 
> > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > +		pm_runtime_put_sync(inst->dev->dev);
> > > +
> > >  unlock_and_return:
> > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > 
> > > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct vpu_instance *inst,
> > > u32 *fail_res)
> > > 
> > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
> > > 
> > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > +		pm_runtime_put_sync(inst->dev->dev);
> > 
> > This seems very unnatural. We do the get() in "start_streaming()", but the
> > put() is only done when the device is closed, or when the driver is
> > removed. As this is not balanced, you seem to have to check the suspended
> > condition all over the place.
> > 
> > I think we could aim for start_streaming()/stop_streaming() for your
> > get/put placement. At least they will be bound to an entirely balanced API.
> > But then, a media player in paused sate will prevent that device from
> > being suspended.
> > 
> > If the HW is capable of preserving enough state, and From the short doc I
> > have it gives me the impression it can preserve that, I'd suggest to
> > follow what hantro driver is doing. What is does is that it will do get()
> > in device_run(), and put() whenever the job completes. This driver has
> > been designed so when there is no job, it means the firmware is currently
> > idle and looking for more work. So it seems like the perfect moment to do
> > suspend it.
> > 
> > Nicolas
> > 
> > > +
> > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > 
> > >  	return 0;
> > > diff --git a/drivers/media/platform/chips-media/wave5/wave5.h
> > > b/drivers/media/platform/chips-media/wave5/wave5.h
> > > index 063028eccd3b..6125eff938a8 100644
> > > --- a/drivers/media/platform/chips-media/wave5/wave5.h
> > > +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> > > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct vpu_device
> > > *vpu_dev, u32 *revision);
> > > 
> > >  int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
> > > 
> > > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const
> > uint16_t *code,
> > > +			 size_t size);
> > > +
> > >  int wave5_vpu_reset(struct device *dev, enum sw_reset_mode
> > > reset_mode);
> > > 
> > >  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst, struct
> > > dec_open_param *param);
>
jackson.lee Feb. 20, 2024, 5:12 a.m. UTC | #4
Hello Nicolas

Thanks your comment.


A pause is common state for media player, but our VPU could trigger an interrupt regardless of a player state.
So at a pause state if a power turns off, our driver becomes hang-up.
I think power on/off should be controlled in the open/close function.

Thanks.

> Le lundi 19 février 2024 à 04:04 +0000, jackson.lee a écrit :
> > Hi Nicolas
> >
> >
> > > This seems very unnatural. We do the get() in "start_streaming()",
> > > but the
> > > put() is only done when the device is closed, or when the driver is
> > > removed. As this is not balanced, you seem to have to check the
> > > suspended condition all over the place.
> > >
> > > I think we could aim for start_streaming()/stop_streaming() for your
> > > get/put placement. At least they will be bound to an entirely balanced
> API.
> > > But then, a media player in paused sate will prevent that device
> > > from being suspended.
> > >
> > > If the HW is capable of preserving enough state, and From the short
> > > doc I have it gives me the impression it can preserve that, I'd
> > > suggest to follow what hantro driver is doing. What is does is that
> > > it will do get() in device_run(), and put() whenever the job
> > > completes. This driver has been designed so when there is no job, it
> > > means the firmware is currently idle and looking for more work. So
> > > it seems like the perfect moment to do suspend it.
> > >
> >
> > Thanks your comment,
> >
> > Currently they are not balanced,
> > If we puts "the put functon" into the stop_streaming, our hw is stalled
> until doing wake-up command, so our v4l2 device become block.
> > so I'd like to update the below instead of calling get at the
> start_streaming function.
> >
> >
> > @@ -1867,6 +1868,13 @@ static int wave5_vpu_open_dec(struct file
> > *filp)
> >
> >         wave5_vdi_allocate_sram(inst->dev);
> >
> > +       err = pm_runtime_resume_and_get(inst->dev->dev);
> > +       if (err) {
> > +               dev_err(inst->dev->dev, "decoder runtime resume
> failed %d\n", err);
> > +               ret = -EINVAL;
> > +               goto cleanup_inst;
> > +       }
> > +
> >         return 0;
> 
> I guess we need to discuss the power management strategy for this device.
> If you do resume_and_get() in open(), and then put in close(), that seems
> balanced. But in term of power saving, it might not be very strong. If you
> have a media player that is set to pause and then placed in the background,
> you still keep the IP running. This is extremely common, since application
> cannot close their device without loosing the reference frames, and thus
> having to do extra work on resume to seek back to the previous sync point
> and drop unneeded frames.
> 
> It seems like the whole point of asking the firmware to save the state and
> suspend is to be able to do so while there is meaningful sate in the firt
> place.
> If we are to suspend only when there is no meaningful state, we could just
> free all resources and power it off completely. (This is just for
> illustration, its probably to slow to boot the firmware at runtime)
> 
> 
> I understand you suffered lockup with a start_streaming() for
> resume_and_get(), and stop_streaming() for put(), this may simply indicate
> that some hardware access are needed between these two. Can you write down
> a power management plan that would effectively save power in common use
> cases ? We can certainly help in refactoring the code to make that happen.
> 
> Nicolas
> 
> >
> > > Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a écrit :
> > > > There are two device run-time PM callbacks defined in 'struct
> > > dev_pm_ops'
> > > > int (*runtime_suspend)(struct device *dev); int
> > > > (*runtime_resume)(struct device *dev);
> > >
> > > I wonder how useful is it to teach everyone what the generic 'struct
> > > dev_pm_ops'
> > > contains. Perhaps you simply wanted that this patch implement both
> > > suspend and resume ops ?
> > >
> > > >
> > > > Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> > > > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > > > ---
> > > >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> > > >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> > > >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> > > >  .../platform/chips-media/wave5/wave5-vpu.c    | 68
> +++++++++++++++++++
> > > >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
> > > > .../media/platform/chips-media/wave5/wave5.h  |  3 +
> > > >  6 files changed, 99 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > index 8ad7f3a28ae1..8aade5a38439 100644
> > > > --- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > @@ -503,6 +503,7 @@ int wave5_vpu_build_up_dec_param(struct
> > > > vpu_instance
> > > *inst,
> > > >  	/* This register must be reset explicitly */
> > > >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> > > >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > > > (COMMAND_QUEUE_DEPTH - 1));
> > > > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> > >
> > > In some way, the relation between suspend and this register write is
> > > not obvious. If its not related, please do this in its own patch.
> > > Otherwise you want to explain why you needed this (possibly just in
> > > the commit message).
> > >
> > > >
> > > >  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true,
> > > > NULL,
> > > NULL);
> > > >  	if (ret) {
> > > > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct device *dev, u8
> > > > *fw,
> > > size_t size)
> > > >  	return setup_wave5_properties(dev);  }
> > > >
> > > > -static int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > i_sleep_wake,
> > > const uint16_t *code,
> > > > -				size_t size)
> > > > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake,
> > > > +const
> > > uint16_t *code,
> > > > +			 size_t size)
> > > >  {
> > > >  	u32 reg_val;
> > > >  	struct vpu_buf *common_vb;
> > > > diff --git
> > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > index ef227af72348..328a7a8f26c5 100644
> > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > @@ -5,6 +5,7 @@
> > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > >   */
> > > >
> > > > +#include <linux/pm_runtime.h>
> > > >  #include "wave5-helper.h"
> > > >
> > > >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > > > @@ -1387,9 +1388,17 @@ static int
> > > > wave5_vpu_dec_start_streaming(struct
> > > > vb2_queue *q, unsigned int count
> > > >
> > > >  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst-
> >state
> > > > ==
> > > VPU_INST_STATE_NONE) {
> > > >  		struct dec_open_param open_param;
> > > > +		int err = 0;
> > > >
> > > >  		memset(&open_param, 0, sizeof(struct dec_open_param));
> > > >
> > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > +		if (err) {
> > > > +			dev_err(inst->dev->dev, "decoder runtime resume
> > > failed %d\n", err);
> > > > +			ret = -EINVAL;
> > > > +			goto return_buffers;
> > > > +		}
> > > > +
> > > >  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
> > > >  		if (ret)
> > > >  			goto return_buffers;
> > > > diff --git
> > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > index 761775216cd4..ff73d69de41c 100644
> > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > @@ -5,6 +5,7 @@
> > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > >   */
> > > >
> > > > +#include <linux/pm_runtime.h>
> > > >  #include "wave5-helper.h"
> > > >
> > > >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > > > @@ -1387,9 +1388,17 @@ static int
> > > > wave5_vpu_enc_start_streaming(struct
> > > > vb2_queue *q, unsigned int count
> > > >
> > > >  	if (inst->state == VPU_INST_STATE_NONE && q->type ==
> > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > >  		struct enc_open_param open_param;
> > > > +		int err = 0;
> > > >
> > > >  		memset(&open_param, 0, sizeof(struct enc_open_param));
> > > >
> > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > +		if (err) {
> > > > +			dev_err(inst->dev->dev, "encoder runtime resume
> > > failed %d\n", err);
> > > > +			ret = -EINVAL;
> > > > +			goto return_buffers;
> > > > +		}
> > > > +
> > > >  		wave5_set_enc_openparam(&open_param, inst);
> > > >
> > > >  		ret = wave5_vpu_enc_open(inst, &open_param); diff --
> git
> > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > index 0d90b5820bef..f81409740a56 100644
> > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > @@ -10,6 +10,7 @@
> > > >  #include <linux/clk.h>
> > > >  #include <linux/firmware.h>
> > > >  #include <linux/interrupt.h>
> > > > +#include <linux/pm_runtime.h>
> > > >  #include "wave5-vpu.h"
> > > >  #include "wave5-regdefine.h"
> > > >  #include "wave5-vpuconfig.h"
> > > > @@ -117,6 +118,65 @@ static int wave5_vpu_load_firmware(struct
> > > > device
> > > *dev, const char *fw_name,
> > > >  	return 0;
> > > >  }
> > > >
> > > > +static __maybe_unused int wave5_pm_suspend(struct device *dev) {
> > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > +
> > > > +	if (pm_runtime_suspended(dev))
> > > > +		return 0;
> > > > +
> > > > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > > > +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> > > > +
> > > > +	return 0;
> > > > +}
> > > > +
> > > > +static __maybe_unused int wave5_pm_resume(struct device *dev) {
> > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > +	int ret = 0;
> > > > +
> > > > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > > > +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
> > > > +	if (ret) {
> > > > +		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
> > > > +		return ret;
> > > > +	}
> > > > +
> > > > +	return ret;
> > > > +}
> > > > +
> > > > +static __maybe_unused int wave5_suspend(struct device *dev) {
> > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > +	struct vpu_instance *inst;
> > > > +
> > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > > > +
> > > > +	return pm_runtime_force_suspend(dev); }
> > > > +
> > > > +static __maybe_unused int wave5_resume(struct device *dev) {
> > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > +	struct vpu_instance *inst;
> > > > +	int ret = 0;
> > > > +
> > > > +	ret = pm_runtime_force_resume(dev);
> > > > +	if (ret < 0)
> > > > +		return ret;
> > > > +
> > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > > > +
> > > > +	return ret;
> > > > +}
> > >
> > > The functions wave5_suspend() and wave5_resume() are not just
> > > "maybe_unsued" but actually never used. What was the intention ?
> > > Considering the usage of __maybe_unused has been such a bad friend
> > > for this one, could you instead bracket the functions with an
> explicit ?
> > >
> > > #ifdef CONFIG_PM
> > > #endif
> > >
> > > This way the compiler will have a word if you implement something
> > > that you forgot to actually use.
> > >
> > > > +
> > > > +static const struct dev_pm_ops wave5_pm_ops = {
> > > > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume,
> NULL) };
> > > > +
> > > >  static int wave5_vpu_probe(struct platform_device *pdev)  {
> > > >  	int ret;
> > > > @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct
> > > > platform_device
> > > *pdev)
> > > >  		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
> > > >  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev-
> >product_code);
> > > >  	dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision);
> > > > +
> > > > +	pm_runtime_enable(&pdev->dev);
> > > > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > > > +
> > > >  	return 0;
> > > >
> > > >  err_enc_unreg:
> > > > @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct
> > > > platform_device
> > > > *pdev)  {
> > > >  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
> > > >
> > > > +	pm_runtime_put_sync(&pdev->dev);
> > > > +	pm_runtime_disable(&pdev->dev);
> > > > +
> > > >  	mutex_destroy(&dev->dev_lock);
> > > >  	mutex_destroy(&dev->hw_lock);
> > > >  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks); @@ -
> 281,6
> > > > +348,7 @@ static struct platform_driver wave5_vpu_driver = {
> > > >  	.driver = {
> > > >  		.name = VPU_PLATFORM_DEVICE_NAME,
> > > >  		.of_match_table = of_match_ptr(wave5_dt_ids),
> > > > +		.pm = &wave5_pm_ops,
> > > >  		},
> > > >  	.probe = wave5_vpu_probe,
> > > >  	.remove = wave5_vpu_remove,
> > > > diff --git
> > > > a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > index 1a3efb638dde..f1f8e4fc8474 100644
> > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > @@ -6,6 +6,7 @@
> > > >   */
> > > >
> > > >  #include <linux/bug.h>
> > > > +#include <linux/pm_runtime.h>
> > > >  #include "wave5-vpuapi.h"
> > > >  #include "wave5-regdefine.h"
> > > >  #include "wave5.h"
> > > > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct vpu_instance
> > > > *inst,
> > > > u32 *fail_res)
> > > >
> > > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
> > > >
> > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > +
> > > >  unlock_and_return:
> > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > >
> > > > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct vpu_instance
> > > > *inst,
> > > > u32 *fail_res)
> > > >
> > > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
> > > >
> > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > +		pm_runtime_put_sync(inst->dev->dev);
> > >
> > > This seems very unnatural. We do the get() in "start_streaming()",
> > > but the
> > > put() is only done when the device is closed, or when the driver is
> > > removed. As this is not balanced, you seem to have to check the
> > > suspended condition all over the place.
> > >
> > > I think we could aim for start_streaming()/stop_streaming() for your
> > > get/put placement. At least they will be bound to an entirely balanced
> API.
> > > But then, a media player in paused sate will prevent that device
> > > from being suspended.
> > >
> > > If the HW is capable of preserving enough state, and From the short
> > > doc I have it gives me the impression it can preserve that, I'd
> > > suggest to follow what hantro driver is doing. What is does is that
> > > it will do get() in device_run(), and put() whenever the job
> > > completes. This driver has been designed so when there is no job, it
> > > means the firmware is currently idle and looking for more work. So
> > > it seems like the perfect moment to do suspend it.
> > >
> > > Nicolas
> > >
> > > > +
> > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > >
> > > >  	return 0;
> > > > diff --git a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > index 063028eccd3b..6125eff938a8 100644
> > > > --- a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct vpu_device
> > > > *vpu_dev, u32 *revision);
> > > >
> > > >  int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
> > > >
> > > > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake,
> > > > +const
> > > uint16_t *code,
> > > > +			 size_t size);
> > > > +
> > > >  int wave5_vpu_reset(struct device *dev, enum sw_reset_mode
> > > > reset_mode);
> > > >
> > > >  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst,
> > > > struct dec_open_param *param);
> >
Nicolas Dufresne Feb. 20, 2024, 7:06 p.m. UTC | #5
Le mardi 20 février 2024 à 05:12 +0000, jackson.lee a écrit :
> Hello Nicolas
> 
> Thanks your comment.
> 
> 
> A pause is common state for media player, but our VPU could trigger an interrupt regardless of a player state.
> So at a pause state if a power turns off, our driver becomes hang-up.
> I think power on/off should be controlled in the open/close function.

Please, avoid top posting, this breaks the discussion completely. Walk through
the comments, and reply to them underneath so we can have a proper discussion.

In our experience, and with the rework of the driver we did during up-streaming,
there is no more un-solicited IRQ. The way the driver state machine has been
built, when the m2m framework is idle (no jobs are active or pending), it means
the firmware is stalled, waiting on some application action. Combined with a
timer of course, so we don't actively suspend/resume, this seems adequate place
to do power management. If that application action never occurred passed a
decent delay, we can suspend. Later on, user actions like qbuf, will lead to
device_run() to be called again, and it would be a good place to resume it.
There is of course other places where you'll have to make sure the hardware is
resumed, like on close, as you want to remove the instance. There is also small
queries here and there that need to be surrounded with resume/put, but with the
redesign, most of the HW access now take place inside device_run() only.

Open/Close is not invalid, but it has a lot of issues, as any random application
can endup disabling the kernel ability to save power. Personally, I think we
should at least give it a try, and document valid reason not to do so if we find
hardware issues. Otherwise, this sounds like all we care is ticking the box
"this driver has runtime PM" without actually caring about effective power
saving.

Nicolas

> 
> Thanks.
> 
> > Le lundi 19 février 2024 à 04:04 +0000, jackson.lee a écrit :
> > > Hi Nicolas
> > > 
> > > 
> > > > This seems very unnatural. We do the get() in "start_streaming()",
> > > > but the
> > > > put() is only done when the device is closed, or when the driver is
> > > > removed. As this is not balanced, you seem to have to check the
> > > > suspended condition all over the place.
> > > > 
> > > > I think we could aim for start_streaming()/stop_streaming() for your
> > > > get/put placement. At least they will be bound to an entirely balanced
> > API.
> > > > But then, a media player in paused sate will prevent that device
> > > > from being suspended.
> > > > 
> > > > If the HW is capable of preserving enough state, and From the short
> > > > doc I have it gives me the impression it can preserve that, I'd
> > > > suggest to follow what hantro driver is doing. What is does is that
> > > > it will do get() in device_run(), and put() whenever the job
> > > > completes. This driver has been designed so when there is no job, it
> > > > means the firmware is currently idle and looking for more work. So
> > > > it seems like the perfect moment to do suspend it.
> > > > 
> > > 
> > > Thanks your comment,
> > > 
> > > Currently they are not balanced,
> > > If we puts "the put functon" into the stop_streaming, our hw is stalled
> > until doing wake-up command, so our v4l2 device become block.
> > > so I'd like to update the below instead of calling get at the
> > start_streaming function.
> > > 
> > > 
> > > @@ -1867,6 +1868,13 @@ static int wave5_vpu_open_dec(struct file
> > > *filp)
> > > 
> > >         wave5_vdi_allocate_sram(inst->dev);
> > > 
> > > +       err = pm_runtime_resume_and_get(inst->dev->dev);
> > > +       if (err) {
> > > +               dev_err(inst->dev->dev, "decoder runtime resume
> > failed %d\n", err);
> > > +               ret = -EINVAL;
> > > +               goto cleanup_inst;
> > > +       }
> > > +
> > >         return 0;
> > 
> > I guess we need to discuss the power management strategy for this device.
> > If you do resume_and_get() in open(), and then put in close(), that seems
> > balanced. But in term of power saving, it might not be very strong. If you
> > have a media player that is set to pause and then placed in the background,
> > you still keep the IP running. This is extremely common, since application
> > cannot close their device without loosing the reference frames, and thus
> > having to do extra work on resume to seek back to the previous sync point
> > and drop unneeded frames.
> > 
> > It seems like the whole point of asking the firmware to save the state and
> > suspend is to be able to do so while there is meaningful sate in the firt
> > place.
> > If we are to suspend only when there is no meaningful state, we could just
> > free all resources and power it off completely. (This is just for
> > illustration, its probably to slow to boot the firmware at runtime)
> > 
> > 
> > I understand you suffered lockup with a start_streaming() for
> > resume_and_get(), and stop_streaming() for put(), this may simply indicate
> > that some hardware access are needed between these two. Can you write down
> > a power management plan that would effectively save power in common use
> > cases ? We can certainly help in refactoring the code to make that happen.
> > 
> > Nicolas
> > 
> > > 
> > > > Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a écrit :
> > > > > There are two device run-time PM callbacks defined in 'struct
> > > > dev_pm_ops'
> > > > > int (*runtime_suspend)(struct device *dev); int
> > > > > (*runtime_resume)(struct device *dev);
> > > > 
> > > > I wonder how useful is it to teach everyone what the generic 'struct
> > > > dev_pm_ops'
> > > > contains. Perhaps you simply wanted that this patch implement both
> > > > suspend and resume ops ?
> > > > 
> > > > > 
> > > > > Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> > > > > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > > > > ---
> > > > >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> > > > >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> > > > >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> > > > >  .../platform/chips-media/wave5/wave5-vpu.c    | 68
> > +++++++++++++++++++
> > > > >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
> > > > > .../media/platform/chips-media/wave5/wave5.h  |  3 +
> > > > >  6 files changed, 99 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > index 8ad7f3a28ae1..8aade5a38439 100644
> > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > @@ -503,6 +503,7 @@ int wave5_vpu_build_up_dec_param(struct
> > > > > vpu_instance
> > > > *inst,
> > > > >  	/* This register must be reset explicitly */
> > > > >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> > > > >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > > > > (COMMAND_QUEUE_DEPTH - 1));
> > > > > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> > > > 
> > > > In some way, the relation between suspend and this register write is
> > > > not obvious. If its not related, please do this in its own patch.
> > > > Otherwise you want to explain why you needed this (possibly just in
> > > > the commit message).
> > > > 
> > > > > 
> > > > >  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true,
> > > > > NULL,
> > > > NULL);
> > > > >  	if (ret) {
> > > > > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct device *dev, u8
> > > > > *fw,
> > > > size_t size)
> > > > >  	return setup_wave5_properties(dev);  }
> > > > > 
> > > > > -static int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > i_sleep_wake,
> > > > const uint16_t *code,
> > > > > -				size_t size)
> > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake,
> > > > > +const
> > > > uint16_t *code,
> > > > > +			 size_t size)
> > > > >  {
> > > > >  	u32 reg_val;
> > > > >  	struct vpu_buf *common_vb;
> > > > > diff --git
> > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > index ef227af72348..328a7a8f26c5 100644
> > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > @@ -5,6 +5,7 @@
> > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > >   */
> > > > > 
> > > > > +#include <linux/pm_runtime.h>
> > > > >  #include "wave5-helper.h"
> > > > > 
> > > > >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > wave5_vpu_dec_start_streaming(struct
> > > > > vb2_queue *q, unsigned int count
> > > > > 
> > > > >  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst-
> > > state
> > > > > ==
> > > > VPU_INST_STATE_NONE) {
> > > > >  		struct dec_open_param open_param;
> > > > > +		int err = 0;
> > > > > 
> > > > >  		memset(&open_param, 0, sizeof(struct dec_open_param));
> > > > > 
> > > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > +		if (err) {
> > > > > +			dev_err(inst->dev->dev, "decoder runtime resume
> > > > failed %d\n", err);
> > > > > +			ret = -EINVAL;
> > > > > +			goto return_buffers;
> > > > > +		}
> > > > > +
> > > > >  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
> > > > >  		if (ret)
> > > > >  			goto return_buffers;
> > > > > diff --git
> > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > index 761775216cd4..ff73d69de41c 100644
> > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > @@ -5,6 +5,7 @@
> > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > >   */
> > > > > 
> > > > > +#include <linux/pm_runtime.h>
> > > > >  #include "wave5-helper.h"
> > > > > 
> > > > >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > wave5_vpu_enc_start_streaming(struct
> > > > > vb2_queue *q, unsigned int count
> > > > > 
> > > > >  	if (inst->state == VPU_INST_STATE_NONE && q->type ==
> > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > > >  		struct enc_open_param open_param;
> > > > > +		int err = 0;
> > > > > 
> > > > >  		memset(&open_param, 0, sizeof(struct enc_open_param));
> > > > > 
> > > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > +		if (err) {
> > > > > +			dev_err(inst->dev->dev, "encoder runtime resume
> > > > failed %d\n", err);
> > > > > +			ret = -EINVAL;
> > > > > +			goto return_buffers;
> > > > > +		}
> > > > > +
> > > > >  		wave5_set_enc_openparam(&open_param, inst);
> > > > > 
> > > > >  		ret = wave5_vpu_enc_open(inst, &open_param); diff --
> > git
> > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > index 0d90b5820bef..f81409740a56 100644
> > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > @@ -10,6 +10,7 @@
> > > > >  #include <linux/clk.h>
> > > > >  #include <linux/firmware.h>
> > > > >  #include <linux/interrupt.h>
> > > > > +#include <linux/pm_runtime.h>
> > > > >  #include "wave5-vpu.h"
> > > > >  #include "wave5-regdefine.h"
> > > > >  #include "wave5-vpuconfig.h"
> > > > > @@ -117,6 +118,65 @@ static int wave5_vpu_load_firmware(struct
> > > > > device
> > > > *dev, const char *fw_name,
> > > > >  	return 0;
> > > > >  }
> > > > > 
> > > > > +static __maybe_unused int wave5_pm_suspend(struct device *dev) {
> > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > +
> > > > > +	if (pm_runtime_suspended(dev))
> > > > > +		return 0;
> > > > > +
> > > > > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > > > > +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > > +static __maybe_unused int wave5_pm_resume(struct device *dev) {
> > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > +	int ret = 0;
> > > > > +
> > > > > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > > > > +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
> > > > > +	if (ret) {
> > > > > +		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
> > > > > +		return ret;
> > > > > +	}
> > > > > +
> > > > > +	return ret;
> > > > > +}
> > > > > +
> > > > > +static __maybe_unused int wave5_suspend(struct device *dev) {
> > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > +	struct vpu_instance *inst;
> > > > > +
> > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > > > > +
> > > > > +	return pm_runtime_force_suspend(dev); }
> > > > > +
> > > > > +static __maybe_unused int wave5_resume(struct device *dev) {
> > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > +	struct vpu_instance *inst;
> > > > > +	int ret = 0;
> > > > > +
> > > > > +	ret = pm_runtime_force_resume(dev);
> > > > > +	if (ret < 0)
> > > > > +		return ret;
> > > > > +
> > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > > > > +
> > > > > +	return ret;
> > > > > +}
> > > > 
> > > > The functions wave5_suspend() and wave5_resume() are not just
> > > > "maybe_unsued" but actually never used. What was the intention ?
> > > > Considering the usage of __maybe_unused has been such a bad friend
> > > > for this one, could you instead bracket the functions with an
> > explicit ?
> > > > 
> > > > #ifdef CONFIG_PM
> > > > #endif
> > > > 
> > > > This way the compiler will have a word if you implement something
> > > > that you forgot to actually use.
> > > > 
> > > > > +
> > > > > +static const struct dev_pm_ops wave5_pm_ops = {
> > > > > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume,
> > NULL) };
> > > > > +
> > > > >  static int wave5_vpu_probe(struct platform_device *pdev)  {
> > > > >  	int ret;
> > > > > @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct
> > > > > platform_device
> > > > *pdev)
> > > > >  		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
> > > > >  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev-
> > > product_code);
> > > > >  	dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision);
> > > > > +
> > > > > +	pm_runtime_enable(&pdev->dev);
> > > > > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > > > > +
> > > > >  	return 0;
> > > > > 
> > > > >  err_enc_unreg:
> > > > > @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct
> > > > > platform_device
> > > > > *pdev)  {
> > > > >  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
> > > > > 
> > > > > +	pm_runtime_put_sync(&pdev->dev);
> > > > > +	pm_runtime_disable(&pdev->dev);
> > > > > +
> > > > >  	mutex_destroy(&dev->dev_lock);
> > > > >  	mutex_destroy(&dev->hw_lock);
> > > > >  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks); @@ -
> > 281,6
> > > > > +348,7 @@ static struct platform_driver wave5_vpu_driver = {
> > > > >  	.driver = {
> > > > >  		.name = VPU_PLATFORM_DEVICE_NAME,
> > > > >  		.of_match_table = of_match_ptr(wave5_dt_ids),
> > > > > +		.pm = &wave5_pm_ops,
> > > > >  		},
> > > > >  	.probe = wave5_vpu_probe,
> > > > >  	.remove = wave5_vpu_remove,
> > > > > diff --git
> > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > index 1a3efb638dde..f1f8e4fc8474 100644
> > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > @@ -6,6 +6,7 @@
> > > > >   */
> > > > > 
> > > > >  #include <linux/bug.h>
> > > > > +#include <linux/pm_runtime.h>
> > > > >  #include "wave5-vpuapi.h"
> > > > >  #include "wave5-regdefine.h"
> > > > >  #include "wave5.h"
> > > > > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct vpu_instance
> > > > > *inst,
> > > > > u32 *fail_res)
> > > > > 
> > > > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
> > > > > 
> > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > > +
> > > > >  unlock_and_return:
> > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > 
> > > > > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct vpu_instance
> > > > > *inst,
> > > > > u32 *fail_res)
> > > > > 
> > > > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
> > > > > 
> > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > 
> > > > This seems very unnatural. We do the get() in "start_streaming()",
> > > > but the
> > > > put() is only done when the device is closed, or when the driver is
> > > > removed. As this is not balanced, you seem to have to check the
> > > > suspended condition all over the place.
> > > > 
> > > > I think we could aim for start_streaming()/stop_streaming() for your
> > > > get/put placement. At least they will be bound to an entirely balanced
> > API.
> > > > But then, a media player in paused sate will prevent that device
> > > > from being suspended.
> > > > 
> > > > If the HW is capable of preserving enough state, and From the short
> > > > doc I have it gives me the impression it can preserve that, I'd
> > > > suggest to follow what hantro driver is doing. What is does is that
> > > > it will do get() in device_run(), and put() whenever the job
> > > > completes. This driver has been designed so when there is no job, it
> > > > means the firmware is currently idle and looking for more work. So
> > > > it seems like the perfect moment to do suspend it.
> > > > 
> > > > Nicolas
> > > > 
> > > > > +
> > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > 
> > > > >  	return 0;
> > > > > diff --git a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > index 063028eccd3b..6125eff938a8 100644
> > > > > --- a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct vpu_device
> > > > > *vpu_dev, u32 *revision);
> > > > > 
> > > > >  int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
> > > > > 
> > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake,
> > > > > +const
> > > > uint16_t *code,
> > > > > +			 size_t size);
> > > > > +
> > > > >  int wave5_vpu_reset(struct device *dev, enum sw_reset_mode
> > > > > reset_mode);
> > > > > 
> > > > >  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst,
> > > > > struct dec_open_param *param);
> > > 
>
jackson.lee Feb. 21, 2024, 2:27 a.m. UTC | #6
Hello Nicolas


Thanks for your comment

> Le mardi 20 février 2024 à 05:12 +0000, jackson.lee a écrit :
> > A pause is common state for media player, but our VPU could trigger an
> interrupt regardless of a player state.
> > So at a pause state if a power turns off, our driver becomes hang-up.
> > I think power on/off should be controlled in the open/close function.
> 
> Please, avoid top posting, this breaks the discussion completely. Walk
> through the comments, and reply to them underneath so we can have a proper
> discussion.
> 
> In our experience, and with the rework of the driver we did during up-
> streaming, there is no more un-solicited IRQ. The way the driver state
> machine has been built, when the m2m framework is idle (no jobs are active
> or pending), it means the firmware is stalled, waiting on some application
> action. Combined with a timer of course, so we don't actively
> suspend/resume, this seems adequate place to do power management. If that
> application action never occurred passed a decent delay, we can suspend.
> Later on, user actions like qbuf, will lead to
> device_run() to be called again, and it would be a good place to resume it.

The above comment means like the below ?
The wave5_vpu_dec_finish_decode is called by IRQ if there is a decoded frame.
And at the end of the function, if there is no data queued, v4l2_m2m_job_finish is called.
You means suspend is called in that function and if app feeds new data into v4l2 driver, the device_run then is called,
In the device_run, resume is called.


I have a question, 
If app is paused or resumed , the v4l2's vidioc_decoder_cmd is always called ?

Thanks.


> There is of course other places where you'll have to make sure the
> hardware is resumed, like on close, as you want to remove the instance.
> There is also small queries here and there that need to be surrounded with
> resume/put, but with the redesign, most of the HW access now take place
> inside device_run() only.
> 
> Open/Close is not invalid, but it has a lot of issues, as any random
> application can endup disabling the kernel ability to save power.
> Personally, I think we should at least give it a try, and document valid
> reason not to do so if we find hardware issues. Otherwise, this sounds
> like all we care is ticking the box "this driver has runtime PM" without
> actually caring about effective power saving.
> 
> Nicolas
> 
> >
> > Thanks.
> >
> > > Le lundi 19 février 2024 à 04:04 +0000, jackson.lee a écrit :
> > > > Hi Nicolas
> > > >
> > > >
> > > > > This seems very unnatural. We do the get() in
> > > > > "start_streaming()", but the
> > > > > put() is only done when the device is closed, or when the driver
> > > > > is removed. As this is not balanced, you seem to have to check
> > > > > the suspended condition all over the place.
> > > > >
> > > > > I think we could aim for start_streaming()/stop_streaming() for
> > > > > your get/put placement. At least they will be bound to an
> > > > > entirely balanced
> > > API.
> > > > > But then, a media player in paused sate will prevent that device
> > > > > from being suspended.
> > > > >
> > > > > If the HW is capable of preserving enough state, and From the
> > > > > short doc I have it gives me the impression it can preserve
> > > > > that, I'd suggest to follow what hantro driver is doing. What is
> > > > > does is that it will do get() in device_run(), and put()
> > > > > whenever the job completes. This driver has been designed so
> > > > > when there is no job, it means the firmware is currently idle
> > > > > and looking for more work. So it seems like the perfect moment to
> do suspend it.
> > > > >
> > > >
> > > > Thanks your comment,
> > > >
> > > > Currently they are not balanced,
> > > > If we puts "the put functon" into the stop_streaming, our hw is
> > > > stalled
> > > until doing wake-up command, so our v4l2 device become block.
> > > > so I'd like to update the below instead of calling get at the
> > > start_streaming function.
> > > >
> > > >
> > > > @@ -1867,6 +1868,13 @@ static int wave5_vpu_open_dec(struct file
> > > > *filp)
> > > >
> > > >         wave5_vdi_allocate_sram(inst->dev);
> > > >
> > > > +       err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > +       if (err) {
> > > > +               dev_err(inst->dev->dev, "decoder runtime resume
> > > failed %d\n", err);
> > > > +               ret = -EINVAL;
> > > > +               goto cleanup_inst;
> > > > +       }
> > > > +
> > > >         return 0;
> > >
> > > I guess we need to discuss the power management strategy for this
> device.
> > > If you do resume_and_get() in open(), and then put in close(), that
> > > seems balanced. But in term of power saving, it might not be very
> > > strong. If you have a media player that is set to pause and then
> > > placed in the background, you still keep the IP running. This is
> > > extremely common, since application cannot close their device
> > > without loosing the reference frames, and thus having to do extra
> > > work on resume to seek back to the previous sync point and drop
> unneeded frames.
> > >
> > > It seems like the whole point of asking the firmware to save the
> > > state and suspend is to be able to do so while there is meaningful
> > > sate in the firt place.
> > > If we are to suspend only when there is no meaningful state, we
> > > could just free all resources and power it off completely. (This is
> > > just for illustration, its probably to slow to boot the firmware at
> > > runtime)
> > >
> > >
> > > I understand you suffered lockup with a start_streaming() for
> > > resume_and_get(), and stop_streaming() for put(), this may simply
> > > indicate that some hardware access are needed between these two. Can
> > > you write down a power management plan that would effectively save
> > > power in common use cases ? We can certainly help in refactoring the
> code to make that happen.
> > >
> > > Nicolas
> > >
> > > >
> > > > > Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a écrit :
> > > > > > There are two device run-time PM callbacks defined in 'struct
> > > > > dev_pm_ops'
> > > > > > int (*runtime_suspend)(struct device *dev); int
> > > > > > (*runtime_resume)(struct device *dev);
> > > > >
> > > > > I wonder how useful is it to teach everyone what the generic
> > > > > 'struct dev_pm_ops'
> > > > > contains. Perhaps you simply wanted that this patch implement
> > > > > both suspend and resume ops ?
> > > > >
> > > > > >
> > > > > > Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> > > > > > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > > > > > ---
> > > > > >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> > > > > >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> > > > > >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> > > > > >  .../platform/chips-media/wave5/wave5-vpu.c    | 68
> > > +++++++++++++++++++
> > > > > >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
> > > > > > .../media/platform/chips-media/wave5/wave5.h  |  3 +
> > > > > >  6 files changed, 99 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git
> > > > > > a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > index 8ad7f3a28ae1..8aade5a38439 100644
> > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > @@ -503,6 +503,7 @@ int wave5_vpu_build_up_dec_param(struct
> > > > > > vpu_instance
> > > > > *inst,
> > > > > >  	/* This register must be reset explicitly */
> > > > > >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> > > > > >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > > > > > (COMMAND_QUEUE_DEPTH - 1));
> > > > > > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> > > > >
> > > > > In some way, the relation between suspend and this register
> > > > > write is not obvious. If its not related, please do this in its
> own patch.
> > > > > Otherwise you want to explain why you needed this (possibly just
> > > > > in the commit message).
> > > > >
> > > > > >
> > > > > >  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true,
> > > > > > NULL,
> > > > > NULL);
> > > > > >  	if (ret) {
> > > > > > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct device
> > > > > > *dev, u8 *fw,
> > > > > size_t size)
> > > > > >  	return setup_wave5_properties(dev);  }
> > > > > >
> > > > > > -static int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > i_sleep_wake,
> > > > > const uint16_t *code,
> > > > > > -				size_t size)
> > > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > +i_sleep_wake, const
> > > > > uint16_t *code,
> > > > > > +			 size_t size)
> > > > > >  {
> > > > > >  	u32 reg_val;
> > > > > >  	struct vpu_buf *common_vb;
> > > > > > diff --git
> > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > > index ef227af72348..328a7a8f26c5 100644
> > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
> > > > > > @@ -5,6 +5,7 @@
> > > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > > >   */
> > > > > >
> > > > > > +#include <linux/pm_runtime.h>
> > > > > >  #include "wave5-helper.h"
> > > > > >
> > > > > >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > > wave5_vpu_dec_start_streaming(struct
> > > > > > vb2_queue *q, unsigned int count
> > > > > >
> > > > > >  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst-
> > > > state
> > > > > > ==
> > > > > VPU_INST_STATE_NONE) {
> > > > > >  		struct dec_open_param open_param;
> > > > > > +		int err = 0;
> > > > > >
> > > > > >  		memset(&open_param, 0, sizeof(struct dec_open_param));
> > > > > >
> > > > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > > +		if (err) {
> > > > > > +			dev_err(inst->dev->dev, "decoder runtime resume
> > > > > failed %d\n", err);
> > > > > > +			ret = -EINVAL;
> > > > > > +			goto return_buffers;
> > > > > > +		}
> > > > > > +
> > > > > >  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
> > > > > >  		if (ret)
> > > > > >  			goto return_buffers;
> > > > > > diff --git
> > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > > index 761775216cd4..ff73d69de41c 100644
> > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
> > > > > > @@ -5,6 +5,7 @@
> > > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > > >   */
> > > > > >
> > > > > > +#include <linux/pm_runtime.h>
> > > > > >  #include "wave5-helper.h"
> > > > > >
> > > > > >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > > wave5_vpu_enc_start_streaming(struct
> > > > > > vb2_queue *q, unsigned int count
> > > > > >
> > > > > >  	if (inst->state == VPU_INST_STATE_NONE && q->type ==
> > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > > > >  		struct enc_open_param open_param;
> > > > > > +		int err = 0;
> > > > > >
> > > > > >  		memset(&open_param, 0, sizeof(struct enc_open_param));
> > > > > >
> > > > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > > +		if (err) {
> > > > > > +			dev_err(inst->dev->dev, "encoder runtime resume
> > > > > failed %d\n", err);
> > > > > > +			ret = -EINVAL;
> > > > > > +			goto return_buffers;
> > > > > > +		}
> > > > > > +
> > > > > >  		wave5_set_enc_openparam(&open_param, inst);
> > > > > >
> > > > > >  		ret = wave5_vpu_enc_open(inst, &open_param); diff --
> > > git
> > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > index 0d90b5820bef..f81409740a56 100644
> > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > @@ -10,6 +10,7 @@
> > > > > >  #include <linux/clk.h>
> > > > > >  #include <linux/firmware.h>
> > > > > >  #include <linux/interrupt.h>
> > > > > > +#include <linux/pm_runtime.h>
> > > > > >  #include "wave5-vpu.h"
> > > > > >  #include "wave5-regdefine.h"
> > > > > >  #include "wave5-vpuconfig.h"
> > > > > > @@ -117,6 +118,65 @@ static int wave5_vpu_load_firmware(struct
> > > > > > device
> > > > > *dev, const char *fw_name,
> > > > > >  	return 0;
> > > > > >  }
> > > > > >
> > > > > > +static __maybe_unused int wave5_pm_suspend(struct device *dev)
> {
> > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > +
> > > > > > +	if (pm_runtime_suspended(dev))
> > > > > > +		return 0;
> > > > > > +
> > > > > > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > > > > > +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> > > > > > +
> > > > > > +	return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static __maybe_unused int wave5_pm_resume(struct device *dev) {
> > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > +	int ret = 0;
> > > > > > +
> > > > > > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > > > > > +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
> > > > > > +	if (ret) {
> > > > > > +		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
> > > > > > +		return ret;
> > > > > > +	}
> > > > > > +
> > > > > > +	return ret;
> > > > > > +}
> > > > > > +
> > > > > > +static __maybe_unused int wave5_suspend(struct device *dev) {
> > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > +	struct vpu_instance *inst;
> > > > > > +
> > > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > > > > > +
> > > > > > +	return pm_runtime_force_suspend(dev); }
> > > > > > +
> > > > > > +static __maybe_unused int wave5_resume(struct device *dev) {
> > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > +	struct vpu_instance *inst;
> > > > > > +	int ret = 0;
> > > > > > +
> > > > > > +	ret = pm_runtime_force_resume(dev);
> > > > > > +	if (ret < 0)
> > > > > > +		return ret;
> > > > > > +
> > > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > > > > > +
> > > > > > +	return ret;
> > > > > > +}
> > > > >
> > > > > The functions wave5_suspend() and wave5_resume() are not just
> > > > > "maybe_unsued" but actually never used. What was the intention ?
> > > > > Considering the usage of __maybe_unused has been such a bad
> > > > > friend for this one, could you instead bracket the functions
> > > > > with an
> > > explicit ?
> > > > >
> > > > > #ifdef CONFIG_PM
> > > > > #endif
> > > > >
> > > > > This way the compiler will have a word if you implement
> > > > > something that you forgot to actually use.
> > > > >
> > > > > > +
> > > > > > +static const struct dev_pm_ops wave5_pm_ops = {
> > > > > > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume,
> > > NULL) };
> > > > > > +
> > > > > >  static int wave5_vpu_probe(struct platform_device *pdev)  {
> > > > > >  	int ret;
> > > > > > @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct
> > > > > > platform_device
> > > > > *pdev)
> > > > > >  		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
> > > > > >  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev-
> > > > product_code);
> > > > > >  	dev_info(&pdev->dev, "Firmware Revision: %u\n",
> > > > > > fw_revision);
> > > > > > +
> > > > > > +	pm_runtime_enable(&pdev->dev);
> > > > > > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > > > > > +
> > > > > >  	return 0;
> > > > > >
> > > > > >  err_enc_unreg:
> > > > > > @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct
> > > > > > platform_device
> > > > > > *pdev)  {
> > > > > >  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
> > > > > >
> > > > > > +	pm_runtime_put_sync(&pdev->dev);
> > > > > > +	pm_runtime_disable(&pdev->dev);
> > > > > > +
> > > > > >  	mutex_destroy(&dev->dev_lock);
> > > > > >  	mutex_destroy(&dev->hw_lock);
> > > > > >  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks); @@ -
> > > 281,6
> > > > > > +348,7 @@ static struct platform_driver wave5_vpu_driver = {
> > > > > >  	.driver = {
> > > > > >  		.name = VPU_PLATFORM_DEVICE_NAME,
> > > > > >  		.of_match_table = of_match_ptr(wave5_dt_ids),
> > > > > > +		.pm = &wave5_pm_ops,
> > > > > >  		},
> > > > > >  	.probe = wave5_vpu_probe,
> > > > > >  	.remove = wave5_vpu_remove,
> > > > > > diff --git
> > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > > index 1a3efb638dde..f1f8e4fc8474 100644
> > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
> > > > > > @@ -6,6 +6,7 @@
> > > > > >   */
> > > > > >
> > > > > >  #include <linux/bug.h>
> > > > > > +#include <linux/pm_runtime.h>
> > > > > >  #include "wave5-vpuapi.h"
> > > > > >  #include "wave5-regdefine.h"
> > > > > >  #include "wave5.h"
> > > > > > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct
> > > > > > vpu_instance *inst,
> > > > > > u32 *fail_res)
> > > > > >
> > > > > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
> > > > > >
> > > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > > > +
> > > > > >  unlock_and_return:
> > > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > >
> > > > > > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct
> > > > > > vpu_instance *inst,
> > > > > > u32 *fail_res)
> > > > > >
> > > > > >  	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
> > > > > >
> > > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > >
> > > > > This seems very unnatural. We do the get() in
> > > > > "start_streaming()", but the
> > > > > put() is only done when the device is closed, or when the driver
> > > > > is removed. As this is not balanced, you seem to have to check
> > > > > the suspended condition all over the place.
> > > > >
> > > > > I think we could aim for start_streaming()/stop_streaming() for
> > > > > your get/put placement. At least they will be bound to an
> > > > > entirely balanced
> > > API.
> > > > > But then, a media player in paused sate will prevent that device
> > > > > from being suspended.
> > > > >
> > > > > If the HW is capable of preserving enough state, and From the
> > > > > short doc I have it gives me the impression it can preserve
> > > > > that, I'd suggest to follow what hantro driver is doing. What is
> > > > > does is that it will do get() in device_run(), and put()
> > > > > whenever the job completes. This driver has been designed so
> > > > > when there is no job, it means the firmware is currently idle
> > > > > and looking for more work. So it seems like the perfect moment to
> do suspend it.
> > > > >
> > > > > Nicolas
> > > > >
> > > > > > +
> > > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > >
> > > > > >  	return 0;
> > > > > > diff --git a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > index 063028eccd3b..6125eff938a8 100644
> > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct vpu_device
> > > > > > *vpu_dev, u32 *revision);
> > > > > >
> > > > > >  int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
> > > > > >
> > > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > +i_sleep_wake, const
> > > > > uint16_t *code,
> > > > > > +			 size_t size);
> > > > > > +
> > > > > >  int wave5_vpu_reset(struct device *dev, enum sw_reset_mode
> > > > > > reset_mode);
> > > > > >
> > > > > >  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst,
> > > > > > struct dec_open_param *param);
> > > >
> >
jackson.lee Feb. 23, 2024, 1:06 a.m. UTC | #7
Hello Nicolas

There is nothing in your reply, can you send us your comment again ?


thanks

> -----Original Message-----
> From: Nicolas Dufresne <nicolas@ndufresne.ca>
> Sent: Friday, February 23, 2024 5:56 AM
> To: jackson.lee <jackson.lee@chipsnmedia.com>; mchehab@kernel.org; linux-
> media@vger.kernel.org; linux-kernel@vger.kernel.org; Nas Chung
> <nas.chung@chipsnmedia.com>
> Cc: lafley.kim <lafley.kim@chipsnmedia.com>; b-brnich@ti.com
> Subject: Re: [RESEND PATCH v0 3/5] wave5 : Support runtime suspend/resume.
>
Nicolas Dufresne Feb. 23, 2024, 6:05 p.m. UTC | #8
Hi,

Le vendredi 23 février 2024 à 01:06 +0000, jackson.lee a écrit :
> Hello Nicolas
> 
> There is nothing in your reply, can you send us your comment again ?

Thanks for the notification, I've suffered issues with my email client it seems,
I will reply again and hope it will work this time.

Nicolas

> 
> 
> thanks
> 
> > -----Original Message-----
> > From: Nicolas Dufresne <nicolas@ndufresne.ca>
> > Sent: Friday, February 23, 2024 5:56 AM
> > To: jackson.lee <jackson.lee@chipsnmedia.com>; mchehab@kernel.org; linux-
> > media@vger.kernel.org; linux-kernel@vger.kernel.org; Nas Chung
> > <nas.chung@chipsnmedia.com>
> > Cc: lafley.kim <lafley.kim@chipsnmedia.com>; b-brnich@ti.com
> > Subject: Re: [RESEND PATCH v0 3/5] wave5 : Support runtime suspend/resume.
> > 
>
Nicolas Dufresne Feb. 23, 2024, 6:09 p.m. UTC | #9
Le jeudi 22 février 2024 à 03:57 +0000, jackson.lee a écrit :
> > 
> > > Le mercredi 21 février 2024 à 02:27 +0000, jackson.lee a écrit :
> > > > Hello Nicolas
> > > > 
> > > > 
> > > > Thanks for your comment
> > > > 
> > > > > Le mardi 20 février 2024 à 05:12 +0000, jackson.lee a écrit :
> > > > > > A pause is common state for media player, but our VPU could
> > > > > > trigger an
> > > > > interrupt regardless of a player state.
> > > > > > So at a pause state if a power turns off, our driver becomes hang-
> > up.
> > > > > > I think power on/off should be controlled in the open/close
> > function.
> > > > > 
> > > > > Please, avoid top posting, this breaks the discussion completely.
> > > > > Walk through the comments, and reply to them underneath so we can
> > > > > have a proper discussion.
> > > > > 
> > > > > In our experience, and with the rework of the driver we did during
> > > > > up- streaming, there is no more un-solicited IRQ. The way the
> > > > > driver state machine has been built, when the m2m framework is
> > > > > idle (no jobs are active or pending), it means the firmware is
> > > > > stalled, waiting on some application action. Combined with a timer
> > > > > of course, so we don't actively suspend/resume, this seems
> > > > > adequate place to do power management. If that application action
> > > > > never occurred passed a
> > > decent delay, we can suspend.
> > > > > Later on, user actions like qbuf, will lead to
> > > > > device_run() to be called again, and it would be a good place to
> > > resume it.
> > > > 
> > > > The above comment means like the below ?
> > > > The wave5_vpu_dec_finish_decode is called by IRQ if there is a
> > > > decoded
> > > frame.
> > > > And at the end of the function, if there is no data queued,
> > > v4l2_m2m_job_finish is called.
> > > > You means suspend is called in that function and if app feeds new
> > > > data into v4l2 driver, the device_run then is called, In the
> > > > device_run,
> > > resume is called.
> > > 
> > > That is the general idea. (Note that we don't forcefully suspect, for
> > > this type of HW, we should configure a delay. Just saying in case
> > > someone miss- interpret what was written here)
> > > 
> > > > 
> > > > 
> > > > I have a question,
> > > > If app is paused or resumed , the v4l2's vidioc_decoder_cmd is
> > > > always
> > > called ?
> > > 
> > > There is no indication if an app is paused / resumed. Runtime PM in
> > > fact should not depend on application actions in general. In the case
> > > of V4L2, most driver will configure a delay (like 5 seconds). If the
> > > driver has been idle (no pending work, no jobs) withing that delay, it
> > > will auto suspend. Then whenever new activity comes, like a QBUF, we
> > resume.
> > > 
> 
> Below is a pseudo code for configuring a delay for the Run time suspend/resume. 
> The logic you are saying means the below ?
> 
> Driver_probe 
> {
>  	pm_runtime_set_autosuspend_delay(vpu->dev, 100);
> 	pm_runtime_use_autosuspend(vpu->dev);
> 	pm_runtime_enable(vpu->dev);
> 
> }
> 
> Device_run 
> {
> 
> 	pm_runtime_resume_and_get(ctx->dev->dev);
> }
> 
> 
> Finish_job 
> {
> 	pm_runtime_mark_last_busy(vpu->dev);
> 	pm_runtime_put_autosuspend(vpu->dev);
> 
> }
> 

This is aligned with what I had in mind. There will be few cases were you'll
need to ensure the hardware is active outside of this (open() and close() are
examples), but otherwise this should in my perception gives the best power
saving. And finally, the delay might need tuning, at first 100ms seems a bit
low, the delay needs to be balanced against the suspend cost.

Nicolas

> 
> 
> Thanks.
> Jackson 
> 
> > 
> > The delay means a timer, so there is no input for 5 secs, then timeout
> > callback is called, And suspend is set, if new activity comes, the device
> > is resumed again ?
> > My understanding is correct ?
> > 
> 
> 
> > 
> > 
> > > Nicolas
> > > 
> > > > 
> > > > Thanks.
> > > > 
> > > > 
> > > > > There is of course other places where you'll have to make sure the
> > > > > hardware is resumed, like on close, as you want to remove the
> > instance.
> > > > > There is also small queries here and there that need to be
> > > > > surrounded with resume/put, but with the redesign, most of the HW
> > > > > access now take place inside device_run() only.
> > > > > 
> > > > > Open/Close is not invalid, but it has a lot of issues, as any
> > > > > random application can endup disabling the kernel ability to save
> > power.
> > > > > Personally, I think we should at least give it a try, and document
> > > > > valid reason not to do so if we find hardware issues. Otherwise,
> > > > > this sounds like all we care is ticking the box "this driver has
> > > > > runtime PM" without actually caring about effective power saving.
> > > > > 
> > > > > Nicolas
> > > > > 
> > > > > > 
> > > > > > Thanks.
> > > > > > 
> > > > > > > Le lundi 19 février 2024 à 04:04 +0000, jackson.lee a écrit :
> > > > > > > > Hi Nicolas
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > This seems very unnatural. We do the get() in
> > > > > > > > > "start_streaming()", but the
> > > > > > > > > put() is only done when the device is closed, or when the
> > > > > > > > > driver is removed. As this is not balanced, you seem to
> > > > > > > > > have to check the suspended condition all over the place.
> > > > > > > > > 
> > > > > > > > > I think we could aim for
> > > > > > > > > start_streaming()/stop_streaming()
> > > > > > > > > for your get/put placement. At least they will be bound to
> > > > > > > > > an entirely balanced
> > > > > > > API.
> > > > > > > > > But then, a media player in paused sate will prevent that
> > > > > > > > > device from being suspended.
> > > > > > > > > 
> > > > > > > > > If the HW is capable of preserving enough state, and From
> > > > > > > > > the short doc I have it gives me the impression it can
> > > > > > > > > preserve that, I'd suggest to follow what hantro driver is
> > > > > > > > > doing. What is does is that it will do get() in
> > > > > > > > > device_run(), and put() whenever the job completes. This
> > > > > > > > > driver has been designed so when there is no job, it means
> > > > > > > > > the firmware is currently idle and looking for more work.
> > > > > > > > > So it seems like the perfect moment to
> > > > > do suspend it.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks your comment,
> > > > > > > > 
> > > > > > > > Currently they are not balanced, If we puts "the put functon"
> > > > > > > > into the stop_streaming, our hw is stalled
> > > > > > > until doing wake-up command, so our v4l2 device become block.
> > > > > > > > so I'd like to update the below instead of calling get at
> > > > > > > > the
> > > > > > > start_streaming function.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > @@ -1867,6 +1868,13 @@ static int wave5_vpu_open_dec(struct
> > > > > > > > file
> > > > > > > > *filp)
> > > > > > > > 
> > > > > > > >         wave5_vdi_allocate_sram(inst->dev);
> > > > > > > > 
> > > > > > > > +       err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > > > > +       if (err) {
> > > > > > > > +               dev_err(inst->dev->dev, "decoder runtime
> > > > > > > > + resume
> > > > > > > failed %d\n", err);
> > > > > > > > +               ret = -EINVAL;
> > > > > > > > +               goto cleanup_inst;
> > > > > > > > +       }
> > > > > > > > +
> > > > > > > >         return 0;
> > > > > > > 
> > > > > > > I guess we need to discuss the power management strategy for
> > > > > > > this
> > > > > device.
> > > > > > > If you do resume_and_get() in open(), and then put in close(),
> > > > > > > that seems balanced. But in term of power saving, it might not
> > > > > > > be very strong. If you have a media player that is set to
> > > > > > > pause and then placed in the background, you still keep the IP
> > > > > > > running. This is extremely common, since application cannot
> > > > > > > close their device without loosing the reference frames, and
> > > > > > > thus having to do extra work on resume to seek back to the
> > > > > > > previous sync point and drop
> > > > > unneeded frames.
> > > > > > > 
> > > > > > > It seems like the whole point of asking the firmware to save
> > > > > > > the state and suspend is to be able to do so while there is
> > > > > > > meaningful sate in the firt place.
> > > > > > > If we are to suspend only when there is no meaningful state,
> > > > > > > we could just free all resources and power it off completely.
> > > > > > > (This is just for illustration, its probably to slow to boot
> > > > > > > the firmware at
> > > > > > > runtime)
> > > > > > > 
> > > > > > > 
> > > > > > > I understand you suffered lockup with a start_streaming() for
> > > > > > > resume_and_get(), and stop_streaming() for put(), this may
> > > > > > > simply indicate that some hardware access are needed between
> > > > > > > these two. Can you write down a power management plan that
> > > > > > > would effectively save power in common use cases ? We can
> > > > > > > certainly help in refactoring the
> > > > > code to make that happen.
> > > > > > > 
> > > > > > > Nicolas
> > > > > > > 
> > > > > > > > 
> > > > > > > > > Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee a
> > > écrit :
> > > > > > > > > > There are two device run-time PM callbacks defined in
> > > > > > > > > > 'struct
> > > > > > > > > dev_pm_ops'
> > > > > > > > > > int (*runtime_suspend)(struct device *dev); int
> > > > > > > > > > (*runtime_resume)(struct device *dev);
> > > > > > > > > 
> > > > > > > > > I wonder how useful is it to teach everyone what the
> > > > > > > > > generic 'struct dev_pm_ops'
> > > > > > > > > contains. Perhaps you simply wanted that this patch
> > > > > > > > > implement both suspend and resume ops ?
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Jackson Lee <jackson.lee@chipsnmedia.com>
> > > > > > > > > > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > > > > > > > > > ---
> > > > > > > > > >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> > > > > > > > > >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> > > > > > > > > >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> > > > > > > > > >  .../platform/chips-media/wave5/wave5-vpu.c    | 68
> > > > > > > +++++++++++++++++++
> > > > > > > > > >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7 ++
> > > > > > > > > > .../media/platform/chips-media/wave5/wave5.h  |  3 +
> > > > > > > > > >  6 files changed, 99 insertions(+), 2 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > > > > > index 8ad7f3a28ae1..8aade5a38439 100644
> > > > > > > > > > ---
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-hw.c
> > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-hw.
> > > > > > > > > > +++ c
> > > > > > > > > > @@ -503,6 +503,7 @@ int
> > > > > > > > > > wave5_vpu_build_up_dec_param(struct
> > > > > > > > > > vpu_instance
> > > > > > > > > *inst,
> > > > > > > > > >  	/* This register must be reset explicitly */
> > > > > > > > > >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> > > > > > > > > >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > > > > > > > > > (COMMAND_QUEUE_DEPTH - 1));
> > > > > > > > > > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> > > > > > > > > 
> > > > > > > > > In some way, the relation between suspend and this
> > > > > > > > > register write is not obvious. If its not related, please
> > > > > > > > > do this in its
> > > > > own patch.
> > > > > > > > > Otherwise you want to explain why you needed this
> > > > > > > > > (possibly just in the commit message).
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > >  	ret = send_firmware_command(inst, W5_CREATE_INSTANCE,
> > > > > > > > > > true, NULL,
> > > > > > > > > NULL);
> > > > > > > > > >  	if (ret) {
> > > > > > > > > > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct
> > > > > > > > > > device *dev, u8 *fw,
> > > > > > > > > size_t size)
> > > > > > > > > >  	return setup_wave5_properties(dev);  }
> > > > > > > > > > 
> > > > > > > > > > -static int wave5_vpu_sleep_wake(struct device *dev,
> > > > > > > > > > bool i_sleep_wake,
> > > > > > > > > const uint16_t *code,
> > > > > > > > > > -				size_t size)
> > > > > > > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > > > > > +i_sleep_wake, const
> > > > > > > > > uint16_t *code,
> > > > > > > > > > +			 size_t size)
> > > > > > > > > >  {
> > > > > > > > > >  	u32 reg_val;
> > > > > > > > > >  	struct vpu_buf *common_vb; diff --git
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec
> > > > > > > > > > .c
> > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec
> > > > > > > > > > .c index ef227af72348..328a7a8f26c5 100644
> > > > > > > > > > ---
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec
> > > > > > > > > > .c
> > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > +++ -d
> > > > > > > > > > +++ ec.c
> > > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > > > > > > >   */
> > > > > > > > > > 
> > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > >  #include "wave5-helper.h"
> > > > > > > > > > 
> > > > > > > > > >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > > > > > > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > > > > > > wave5_vpu_dec_start_streaming(struct
> > > > > > > > > > vb2_queue *q, unsigned int count
> > > > > > > > > > 
> > > > > > > > > >  	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE &&
> > > > > > > > > > inst-
> > > > > > > > state
> > > > > > > > > > ==
> > > > > > > > > VPU_INST_STATE_NONE) {
> > > > > > > > > >  		struct dec_open_param open_param;
> > > > > > > > > > +		int err = 0;
> > > > > > > > > > 
> > > > > > > > > >  		memset(&open_param, 0, sizeof(struct
> > > dec_open_param));
> > > > > > > > > > 
> > > > > > > > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > > > > > > +		if (err) {
> > > > > > > > > > +			dev_err(inst->dev->dev, "decoder runtime
> > > resume
> > > > > > > > > failed %d\n", err);
> > > > > > > > > > +			ret = -EINVAL;
> > > > > > > > > > +			goto return_buffers;
> > > > > > > > > > +		}
> > > > > > > > > > +
> > > > > > > > > >  		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
> > > > > > > > > >  		if (ret)
> > > > > > > > > >  			goto return_buffers; diff --git
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc
> > > > > > > > > > .c
> > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc
> > > > > > > > > > .c index 761775216cd4..ff73d69de41c 100644
> > > > > > > > > > ---
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc
> > > > > > > > > > .c
> > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > +++ -e
> > > > > > > > > > +++ nc.c
> > > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > > > > > > >   */
> > > > > > > > > > 
> > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > >  #include "wave5-helper.h"
> > > > > > > > > > 
> > > > > > > > > >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > > > > > > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > > > > > > wave5_vpu_enc_start_streaming(struct
> > > > > > > > > > vb2_queue *q, unsigned int count
> > > > > > > > > > 
> > > > > > > > > >  	if (inst->state == VPU_INST_STATE_NONE && q->type ==
> > > > > > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > > > > > > > >  		struct enc_open_param open_param;
> > > > > > > > > > +		int err = 0;
> > > > > > > > > > 
> > > > > > > > > >  		memset(&open_param, 0, sizeof(struct
> > > enc_open_param));
> > > > > > > > > > 
> > > > > > > > > > +		err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > > > > > > +		if (err) {
> > > > > > > > > > +			dev_err(inst->dev->dev, "encoder runtime
> > > resume
> > > > > > > > > failed %d\n", err);
> > > > > > > > > > +			ret = -EINVAL;
> > > > > > > > > > +			goto return_buffers;
> > > > > > > > > > +		}
> > > > > > > > > > +
> > > > > > > > > >  		wave5_set_enc_openparam(&open_param, inst);
> > > > > > > > > > 
> > > > > > > > > >  		ret = wave5_vpu_enc_open(inst, &open_param);
> > > diff --
> > > > > > > git
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > > > > > index 0d90b5820bef..f81409740a56 100644
> > > > > > > > > > ---
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
> > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > +++ .c
> > > > > > > > > > @@ -10,6 +10,7 @@
> > > > > > > > > >  #include <linux/clk.h>
> > > > > > > > > >  #include <linux/firmware.h>  #include
> > > > > > > > > > <linux/interrupt.h>
> > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > >  #include "wave5-vpu.h"
> > > > > > > > > >  #include "wave5-regdefine.h"
> > > > > > > > > >  #include "wave5-vpuconfig.h"
> > > > > > > > > > @@ -117,6 +118,65 @@ static int
> > > > > > > > > > wave5_vpu_load_firmware(struct device
> > > > > > > > > *dev, const char *fw_name,
> > > > > > > > > >  	return 0;
> > > > > > > > > >  }
> > > > > > > > > > 
> > > > > > > > > > +static __maybe_unused int wave5_pm_suspend(struct
> > > > > > > > > > +device
> > > > > > > > > > +*dev)
> > > > > {
> > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > +
> > > > > > > > > > +	if (pm_runtime_suspended(dev))
> > > > > > > > > > +		return 0;
> > > > > > > > > > +
> > > > > > > > > > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > > > > > > > > > +	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
> > > > > > > > > > +
> > > > > > > > > > +	return 0;
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > +static __maybe_unused int wave5_pm_resume(struct device
> > > *dev) {
> > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > +	int ret = 0;
> > > > > > > > > > +
> > > > > > > > > > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > > > > > > > > > +	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu-
> > > > clks);
> > > > > > > > > > +	if (ret) {
> > > > > > > > > > +		dev_err(dev, "Enabling clocks, fail: %d\n",
> > > ret);
> > > > > > > > > > +		return ret;
> > > > > > > > > > +	}
> > > > > > > > > > +
> > > > > > > > > > +	return ret;
> > > > > > > > > > +}
> > > > > > > > > > +
> > > > > > > > > > +static __maybe_unused int wave5_suspend(struct device
> > > > > > > > > > +*dev)
> > > {
> > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > +	struct vpu_instance *inst;
> > > > > > > > > > +
> > > > > > > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > > > > > > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > > > > > > > > > +
> > > > > > > > > > +	return pm_runtime_force_suspend(dev); }
> > > > > > > > > > +
> > > > > > > > > > +static __maybe_unused int wave5_resume(struct device
> > > > > > > > > > +*dev)
> > > {
> > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > +	struct vpu_instance *inst;
> > > > > > > > > > +	int ret = 0;
> > > > > > > > > > +
> > > > > > > > > > +	ret = pm_runtime_force_resume(dev);
> > > > > > > > > > +	if (ret < 0)
> > > > > > > > > > +		return ret;
> > > > > > > > > > +
> > > > > > > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > > > > > > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > > > > > > > > > +
> > > > > > > > > > +	return ret;
> > > > > > > > > > +}
> > > > > > > > > 
> > > > > > > > > The functions wave5_suspend() and wave5_resume() are not
> > > > > > > > > just "maybe_unsued" but actually never used. What was the
> > > intention ?
> > > > > > > > > Considering the usage of __maybe_unused has been such a
> > > > > > > > > bad friend for this one, could you instead bracket the
> > > > > > > > > functions with an
> > > > > > > explicit ?
> > > > > > > > > 
> > > > > > > > > #ifdef CONFIG_PM
> > > > > > > > > #endif
> > > > > > > > > 
> > > > > > > > > This way the compiler will have a word if you implement
> > > > > > > > > something that you forgot to actually use.
> > > > > > > > > 
> > > > > > > > > > +
> > > > > > > > > > +static const struct dev_pm_ops wave5_pm_ops = {
> > > > > > > > > > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume,
> > > > > > > NULL) };
> > > > > > > > > > +
> > > > > > > > > >  static int wave5_vpu_probe(struct platform_device *pdev)
> > {
> > > > > > > > > >  	int ret;
> > > > > > > > > > @@ -232,6 +292,10 @@ static int wave5_vpu_probe(struct
> > > > > > > > > > platform_device
> > > > > > > > > *pdev)
> > > > > > > > > >  		 (match_data->flags & WAVE5_IS_DEC) ?
> > > "'DECODE'" : "");
> > > > > > > > > >  	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev-
> > > > > > > > product_code);
> > > > > > > > > >  	dev_info(&pdev->dev, "Firmware Revision: %u\n",
> > > > > > > > > > fw_revision);
> > > > > > > > > > +
> > > > > > > > > > +	pm_runtime_enable(&pdev->dev);
> > > > > > > > > > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > > > > > > > > > +
> > > > > > > > > >  	return 0;
> > > > > > > > > > 
> > > > > > > > > >  err_enc_unreg:
> > > > > > > > > > @@ -254,6 +318,9 @@ static int wave5_vpu_remove(struct
> > > > > > > > > > platform_device
> > > > > > > > > > *pdev)  {
> > > > > > > > > >  	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
> > > > > > > > > > 
> > > > > > > > > > +	pm_runtime_put_sync(&pdev->dev);
> > > > > > > > > > +	pm_runtime_disable(&pdev->dev);
> > > > > > > > > > +
> > > > > > > > > >  	mutex_destroy(&dev->dev_lock);
> > > > > > > > > >  	mutex_destroy(&dev->hw_lock);
> > > > > > > > > >  	clk_bulk_disable_unprepare(dev->num_clks, dev->clks);
> > > @@
> > > > > > > > > > -
> > > > > > > 281,6
> > > > > > > > > > +348,7 @@ static struct platform_driver wave5_vpu_driver
> > > > > > > > > > += {
> > > > > > > > > >  	.driver = {
> > > > > > > > > >  		.name = VPU_PLATFORM_DEVICE_NAME,
> > > > > > > > > >  		.of_match_table = of_match_ptr(wave5_dt_ids),
> > > > > > > > > > +		.pm = &wave5_pm_ops,
> > > > > > > > > >  		},
> > > > > > > > > >  	.probe = wave5_vpu_probe,
> > > > > > > > > >  	.remove = wave5_vpu_remove, diff --git
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.
> > > > > > > > > > c
> > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.
> > > > > > > > > > c index 1a3efb638dde..f1f8e4fc8474 100644
> > > > > > > > > > ---
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.
> > > > > > > > > > c
> > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > +++ ap
> > > > > > > > > > +++ i.c
> > > > > > > > > > @@ -6,6 +6,7 @@
> > > > > > > > > >   */
> > > > > > > > > > 
> > > > > > > > > >  #include <linux/bug.h>
> > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > >  #include "wave5-vpuapi.h"
> > > > > > > > > >  #include "wave5-regdefine.h"
> > > > > > > > > >  #include "wave5.h"
> > > > > > > > > > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct
> > > > > > > > > > vpu_instance *inst,
> > > > > > > > > > u32 *fail_res)
> > > > > > > > > > 
> > > > > > > > > >  	wave5_vdi_free_dma_memory(vpu_dev,
> > > > > > > > > > &p_dec_info->vb_task);
> > > > > > > > > > 
> > > > > > > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > > > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > > > > > > > +
> > > > > > > > > >  unlock_and_return:
> > > > > > > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > > > > > > 
> > > > > > > > > > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct
> > > > > > > > > > vpu_instance *inst,
> > > > > > > > > > u32 *fail_res)
> > > > > > > > > > 
> > > > > > > > > >  	wave5_vdi_free_dma_memory(vpu_dev,
> > > > > > > > > > &p_enc_info->vb_task);
> > > > > > > > > > 
> > > > > > > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > > > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > > > > > > 
> > > > > > > > > This seems very unnatural. We do the get() in
> > > > > > > > > "start_streaming()", but the
> > > > > > > > > put() is only done when the device is closed, or when the
> > > > > > > > > driver is removed. As this is not balanced, you seem to
> > > > > > > > > have to check the suspended condition all over the place.
> > > > > > > > > 
> > > > > > > > > I think we could aim for
> > > > > > > > > start_streaming()/stop_streaming()
> > > > > > > > > for your get/put placement. At least they will be bound to
> > > > > > > > > an entirely balanced
> > > > > > > API.
> > > > > > > > > But then, a media player in paused sate will prevent that
> > > > > > > > > device from being suspended.
> > > > > > > > > 
> > > > > > > > > If the HW is capable of preserving enough state, and From
> > > > > > > > > the short doc I have it gives me the impression it can
> > > > > > > > > preserve that, I'd suggest to follow what hantro driver is
> > > > > > > > > doing. What is does is that it will do get() in
> > > > > > > > > device_run(), and put() whenever the job completes. This
> > > > > > > > > driver has been designed so when there is no job, it means
> > > > > > > > > the firmware is currently idle and looking for more work.
> > > > > > > > > So it seems like the perfect moment to
> > > > > do suspend it.
> > > > > > > > > 
> > > > > > > > > Nicolas
> > > > > > > > > 
> > > > > > > > > > +
> > > > > > > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > > > > > > 
> > > > > > > > > >  	return 0;
> > > > > > > > > > diff --git
> > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > index 063028eccd3b..6125eff938a8 100644
> > > > > > > > > > --- a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct
> > > > > > > > > > vpu_device *vpu_dev, u32 *revision);
> > > > > > > > > > 
> > > > > > > > > >  int wave5_vpu_init(struct device *dev, u8 *fw, size_t
> > > > > > > > > > size);
> > > > > > > > > > 
> > > > > > > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > > > > > +i_sleep_wake, const
> > > > > > > > > uint16_t *code,
> > > > > > > > > > +			 size_t size);
> > > > > > > > > > +
> > > > > > > > > >  int wave5_vpu_reset(struct device *dev, enum
> > > > > > > > > > sw_reset_mode reset_mode);
> > > > > > > > > > 
> > > > > > > > > >  int wave5_vpu_build_up_dec_param(struct vpu_instance
> > > > > > > > > > *inst, struct dec_open_param *param);
> > > > > > > > 
> > > > > > 
> > > > 
>
jackson.lee Feb. 26, 2024, 12:56 a.m. UTC | #10
Hello Nicolas

> 
> Le jeudi 22 février 2024 à 03:57 +0000, jackson.lee a écrit :
> > >
> > > > Le mercredi 21 février 2024 à 02:27 +0000, jackson.lee a écrit :
> > > > > Hello Nicolas
> > > > >
> > > > >
> > > > > Thanks for your comment
> > > > >
> > > > > > Le mardi 20 février 2024 à 05:12 +0000, jackson.lee a écrit :
> > > > > > > A pause is common state for media player, but our VPU could
> > > > > > > trigger an
> > > > > > interrupt regardless of a player state.
> > > > > > > So at a pause state if a power turns off, our driver becomes
> > > > > > > hang-
> > > up.
> > > > > > > I think power on/off should be controlled in the open/close
> > > function.
> > > > > >
> > > > > > Please, avoid top posting, this breaks the discussion completely.
> > > > > > Walk through the comments, and reply to them underneath so we
> > > > > > can have a proper discussion.
> > > > > >
> > > > > > In our experience, and with the rework of the driver we did
> > > > > > during
> > > > > > up- streaming, there is no more un-solicited IRQ. The way the
> > > > > > driver state machine has been built, when the m2m framework is
> > > > > > idle (no jobs are active or pending), it means the firmware is
> > > > > > stalled, waiting on some application action. Combined with a
> > > > > > timer of course, so we don't actively suspend/resume, this
> > > > > > seems adequate place to do power management. If that
> > > > > > application action never occurred passed a
> > > > decent delay, we can suspend.
> > > > > > Later on, user actions like qbuf, will lead to
> > > > > > device_run() to be called again, and it would be a good place
> > > > > > to
> > > > resume it.
> > > > >
> > > > > The above comment means like the below ?
> > > > > The wave5_vpu_dec_finish_decode is called by IRQ if there is a
> > > > > decoded
> > > > frame.
> > > > > And at the end of the function, if there is no data queued,
> > > > v4l2_m2m_job_finish is called.
> > > > > You means suspend is called in that function and if app feeds
> > > > > new data into v4l2 driver, the device_run then is called, In the
> > > > > device_run,
> > > > resume is called.
> > > >
> > > > That is the general idea. (Note that we don't forcefully suspect,
> > > > for this type of HW, we should configure a delay. Just saying in
> > > > case someone miss- interpret what was written here)
> > > >
> > > > >
> > > > >
> > > > > I have a question,
> > > > > If app is paused or resumed , the v4l2's vidioc_decoder_cmd is
> > > > > always
> > > > called ?
> > > >
> > > > There is no indication if an app is paused / resumed. Runtime PM
> > > > in fact should not depend on application actions in general. In
> > > > the case of V4L2, most driver will configure a delay (like 5
> > > > seconds). If the driver has been idle (no pending work, no jobs)
> > > > withing that delay, it will auto suspend. Then whenever new
> > > > activity comes, like a QBUF, we
> > > resume.
> > > >
> >
> > Below is a pseudo code for configuring a delay for the Run time
> suspend/resume.
> > The logic you are saying means the below ?
> >
> > Driver_probe
> > {
> >  	pm_runtime_set_autosuspend_delay(vpu->dev, 100);
> > 	pm_runtime_use_autosuspend(vpu->dev);
> > 	pm_runtime_enable(vpu->dev);
> >
> > }
> >
> > Device_run
> > {
> >
> > 	pm_runtime_resume_and_get(ctx->dev->dev);
> > }
> >
> >
> > Finish_job
> > {
> > 	pm_runtime_mark_last_busy(vpu->dev);
> > 	pm_runtime_put_autosuspend(vpu->dev);
> >
> > }
> >
> 
> This is aligned with what I had in mind. There will be few cases were
> you'll need to ensure the hardware is active outside of this (open() and
> close() are examples), but otherwise this should in my perception gives
> the best power saving. And finally, the delay might need tuning, at first
> 100ms seems a bit low, the delay needs to be balanced against the suspend
> cost.
> 
> Nicolas
> 

Thanks for your comment.

Thanks
Jackson







> >
> >
> > Thanks.
> > Jackson
> >
> > >
> > > The delay means a timer, so there is no input for 5 secs, then
> > > timeout callback is called, And suspend is set, if new activity
> > > comes, the device is resumed again ?
> > > My understanding is correct ?
> > >
> >
> >
> > >
> > >
> > > > Nicolas
> > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > > > There is of course other places where you'll have to make sure
> > > > > > the hardware is resumed, like on close, as you want to remove
> > > > > > the
> > > instance.
> > > > > > There is also small queries here and there that need to be
> > > > > > surrounded with resume/put, but with the redesign, most of the
> > > > > > HW access now take place inside device_run() only.
> > > > > >
> > > > > > Open/Close is not invalid, but it has a lot of issues, as any
> > > > > > random application can endup disabling the kernel ability to
> > > > > > save
> > > power.
> > > > > > Personally, I think we should at least give it a try, and
> > > > > > document valid reason not to do so if we find hardware issues.
> > > > > > Otherwise, this sounds like all we care is ticking the box
> > > > > > "this driver has runtime PM" without actually caring about
> effective power saving.
> > > > > >
> > > > > > Nicolas
> > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > > Le lundi 19 février 2024 à 04:04 +0000, jackson.lee a écrit :
> > > > > > > > > Hi Nicolas
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > This seems very unnatural. We do the get() in
> > > > > > > > > > "start_streaming()", but the
> > > > > > > > > > put() is only done when the device is closed, or when
> > > > > > > > > > the driver is removed. As this is not balanced, you
> > > > > > > > > > seem to have to check the suspended condition all over
> the place.
> > > > > > > > > >
> > > > > > > > > > I think we could aim for
> > > > > > > > > > start_streaming()/stop_streaming()
> > > > > > > > > > for your get/put placement. At least they will be
> > > > > > > > > > bound to an entirely balanced
> > > > > > > > API.
> > > > > > > > > > But then, a media player in paused sate will prevent
> > > > > > > > > > that device from being suspended.
> > > > > > > > > >
> > > > > > > > > > If the HW is capable of preserving enough state, and
> > > > > > > > > > From the short doc I have it gives me the impression
> > > > > > > > > > it can preserve that, I'd suggest to follow what
> > > > > > > > > > hantro driver is doing. What is does is that it will
> > > > > > > > > > do get() in device_run(), and put() whenever the job
> > > > > > > > > > completes. This driver has been designed so when there
> > > > > > > > > > is no job, it means the firmware is currently idle and
> looking for more work.
> > > > > > > > > > So it seems like the perfect moment to
> > > > > > do suspend it.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks your comment,
> > > > > > > > >
> > > > > > > > > Currently they are not balanced, If we puts "the put
> functon"
> > > > > > > > > into the stop_streaming, our hw is stalled
> > > > > > > > until doing wake-up command, so our v4l2 device become block.
> > > > > > > > > so I'd like to update the below instead of calling get
> > > > > > > > > at the
> > > > > > > > start_streaming function.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > @@ -1867,6 +1868,13 @@ static int
> > > > > > > > > wave5_vpu_open_dec(struct file
> > > > > > > > > *filp)
> > > > > > > > >
> > > > > > > > >         wave5_vdi_allocate_sram(inst->dev);
> > > > > > > > >
> > > > > > > > > +       err = pm_runtime_resume_and_get(inst->dev->dev);
> > > > > > > > > +       if (err) {
> > > > > > > > > +               dev_err(inst->dev->dev, "decoder runtime
> > > > > > > > > + resume
> > > > > > > > failed %d\n", err);
> > > > > > > > > +               ret = -EINVAL;
> > > > > > > > > +               goto cleanup_inst;
> > > > > > > > > +       }
> > > > > > > > > +
> > > > > > > > >         return 0;
> > > > > > > >
> > > > > > > > I guess we need to discuss the power management strategy
> > > > > > > > for this
> > > > > > device.
> > > > > > > > If you do resume_and_get() in open(), and then put in
> > > > > > > > close(), that seems balanced. But in term of power saving,
> > > > > > > > it might not be very strong. If you have a media player
> > > > > > > > that is set to pause and then placed in the background,
> > > > > > > > you still keep the IP running. This is extremely common,
> > > > > > > > since application cannot close their device without
> > > > > > > > loosing the reference frames, and thus having to do extra
> > > > > > > > work on resume to seek back to the previous sync point and
> > > > > > > > drop
> > > > > > unneeded frames.
> > > > > > > >
> > > > > > > > It seems like the whole point of asking the firmware to
> > > > > > > > save the state and suspend is to be able to do so while
> > > > > > > > there is meaningful sate in the firt place.
> > > > > > > > If we are to suspend only when there is no meaningful
> > > > > > > > state, we could just free all resources and power it off
> completely.
> > > > > > > > (This is just for illustration, its probably to slow to
> > > > > > > > boot the firmware at
> > > > > > > > runtime)
> > > > > > > >
> > > > > > > >
> > > > > > > > I understand you suffered lockup with a start_streaming()
> > > > > > > > for resume_and_get(), and stop_streaming() for put(), this
> > > > > > > > may simply indicate that some hardware access are needed
> > > > > > > > between these two. Can you write down a power management
> > > > > > > > plan that would effectively save power in common use cases
> > > > > > > > ? We can certainly help in refactoring the
> > > > > > code to make that happen.
> > > > > > > >
> > > > > > > > Nicolas
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > Le mercredi 31 janvier 2024 à 10:30 +0900, jackson.lee
> > > > > > > > > > a
> > > > écrit :
> > > > > > > > > > > There are two device run-time PM callbacks defined
> > > > > > > > > > > in 'struct
> > > > > > > > > > dev_pm_ops'
> > > > > > > > > > > int (*runtime_suspend)(struct device *dev); int
> > > > > > > > > > > (*runtime_resume)(struct device *dev);
> > > > > > > > > >
> > > > > > > > > > I wonder how useful is it to teach everyone what the
> > > > > > > > > > generic 'struct dev_pm_ops'
> > > > > > > > > > contains. Perhaps you simply wanted that this patch
> > > > > > > > > > implement both suspend and resume ops ?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Jackson Lee
> > > > > > > > > > > <jackson.lee@chipsnmedia.com>
> > > > > > > > > > > Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  .../platform/chips-media/wave5/wave5-hw.c     |  5 +-
> > > > > > > > > > >  .../chips-media/wave5/wave5-vpu-dec.c         |  9 +++
> > > > > > > > > > >  .../chips-media/wave5/wave5-vpu-enc.c         |  9 +++
> > > > > > > > > > >  .../platform/chips-media/wave5/wave5-vpu.c    | 68
> > > > > > > > +++++++++++++++++++
> > > > > > > > > > >  .../platform/chips-media/wave5/wave5-vpuapi.c |  7
> > > > > > > > > > > ++ .../media/platform/chips-media/wave5/wave5.h  |
> > > > > > > > > > > 3 +
> > > > > > > > > > >  6 files changed, 99 insertions(+), 2 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-hw.
> > > > > > > > > > > c
> > > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-hw.
> > > > > > > > > > > c index 8ad7f3a28ae1..8aade5a38439 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-hw.
> > > > > > > > > > > c
> > > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5-
> hw.
> > > > > > > > > > > +++ c
> > > > > > > > > > > @@ -503,6 +503,7 @@ int
> > > > > > > > > > > wave5_vpu_build_up_dec_param(struct
> > > > > > > > > > > vpu_instance
> > > > > > > > > > *inst,
> > > > > > > > > > >  	/* This register must be reset explicitly */
> > > > > > > > > > >  	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
> > > > > > > > > > >  	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1,
> > > > > > > > > > > (COMMAND_QUEUE_DEPTH - 1));
> > > > > > > > > > > +	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
> > > > > > > > > >
> > > > > > > > > > In some way, the relation between suspend and this
> > > > > > > > > > register write is not obvious. If its not related,
> > > > > > > > > > please do this in its
> > > > > > own patch.
> > > > > > > > > > Otherwise you want to explain why you needed this
> > > > > > > > > > (possibly just in the commit message).
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >  	ret = send_firmware_command(inst,
> > > > > > > > > > > W5_CREATE_INSTANCE, true, NULL,
> > > > > > > > > > NULL);
> > > > > > > > > > >  	if (ret) {
> > > > > > > > > > > @@ -1075,8 +1076,8 @@ int wave5_vpu_re_init(struct
> > > > > > > > > > > device *dev, u8 *fw,
> > > > > > > > > > size_t size)
> > > > > > > > > > >  	return setup_wave5_properties(dev);  }
> > > > > > > > > > >
> > > > > > > > > > > -static int wave5_vpu_sleep_wake(struct device *dev,
> > > > > > > > > > > bool i_sleep_wake,
> > > > > > > > > > const uint16_t *code,
> > > > > > > > > > > -				size_t size)
> > > > > > > > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > > > > > > +i_sleep_wake, const
> > > > > > > > > > uint16_t *code,
> > > > > > > > > > > +			 size_t size)
> > > > > > > > > > >  {
> > > > > > > > > > >  	u32 reg_val;
> > > > > > > > > > >  	struct vpu_buf *common_vb; diff --git
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > -dec
> > > > > > > > > > > .c
> > > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > -dec .c index ef227af72348..328a7a8f26c5 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > -dec
> > > > > > > > > > > .c
> > > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5
> > > > > > > > > > > +++ -vpu
> > > > > > > > > > > +++ -d
> > > > > > > > > > > +++ ec.c
> > > > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > > > > > > > >   */
> > > > > > > > > > >
> > > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > > >  #include "wave5-helper.h"
> > > > > > > > > > >
> > > > > > > > > > >  #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
> > > > > > > > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > > > > > > > wave5_vpu_dec_start_streaming(struct
> > > > > > > > > > > vb2_queue *q, unsigned int count
> > > > > > > > > > >
> > > > > > > > > > >  	if (q->type ==
> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE
> > > > > > > > > > > &&
> > > > > > > > > > > inst-
> > > > > > > > > state
> > > > > > > > > > > ==
> > > > > > > > > > VPU_INST_STATE_NONE) {
> > > > > > > > > > >  		struct dec_open_param open_param;
> > > > > > > > > > > +		int err = 0;
> > > > > > > > > > >
> > > > > > > > > > >  		memset(&open_param, 0, sizeof(struct
> > > > dec_open_param));
> > > > > > > > > > >
> > > > > > > > > > > +		err = pm_runtime_resume_and_get(inst-
> >dev->dev);
> > > > > > > > > > > +		if (err) {
> > > > > > > > > > > +			dev_err(inst->dev->dev, "decoder
> runtime
> > > > resume
> > > > > > > > > > failed %d\n", err);
> > > > > > > > > > > +			ret = -EINVAL;
> > > > > > > > > > > +			goto return_buffers;
> > > > > > > > > > > +		}
> > > > > > > > > > > +
> > > > > > > > > > >  		ret =
> wave5_vpu_dec_allocate_ring_buffer(inst);
> > > > > > > > > > >  		if (ret)
> > > > > > > > > > >  			goto return_buffers; diff --git
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > -enc
> > > > > > > > > > > .c
> > > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > -enc .c index 761775216cd4..ff73d69de41c 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > -enc
> > > > > > > > > > > .c
> > > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5
> > > > > > > > > > > +++ -vpu
> > > > > > > > > > > +++ -e
> > > > > > > > > > > +++ nc.c
> > > > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > > > >   * Copyright (C) 2021-2023 CHIPS&MEDIA INC
> > > > > > > > > > >   */
> > > > > > > > > > >
> > > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > > >  #include "wave5-helper.h"
> > > > > > > > > > >
> > > > > > > > > > >  #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
> > > > > > > > > > > @@ -1387,9 +1388,17 @@ static int
> > > > > > > > > > > wave5_vpu_enc_start_streaming(struct
> > > > > > > > > > > vb2_queue *q, unsigned int count
> > > > > > > > > > >
> > > > > > > > > > >  	if (inst->state == VPU_INST_STATE_NONE && q-
> >type
> > > > > > > > > > > ==
> > > > > > > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> > > > > > > > > > >  		struct enc_open_param open_param;
> > > > > > > > > > > +		int err = 0;
> > > > > > > > > > >
> > > > > > > > > > >  		memset(&open_param, 0, sizeof(struct
> > > > enc_open_param));
> > > > > > > > > > >
> > > > > > > > > > > +		err = pm_runtime_resume_and_get(inst-
> >dev->dev);
> > > > > > > > > > > +		if (err) {
> > > > > > > > > > > +			dev_err(inst->dev->dev, "encoder
> runtime
> > > > resume
> > > > > > > > > > failed %d\n", err);
> > > > > > > > > > > +			ret = -EINVAL;
> > > > > > > > > > > +			goto return_buffers;
> > > > > > > > > > > +		}
> > > > > > > > > > > +
> > > > > > > > > > >  		wave5_set_enc_openparam(&open_param,
> inst);
> > > > > > > > > > >
> > > > > > > > > > >  		ret = wave5_vpu_enc_open(inst,
> &open_param);
> > > > diff --
> > > > > > > > git
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > .c
> > > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > .c index 0d90b5820bef..f81409740a56 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-vpu
> > > > > > > > > > > .c
> > > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5
> > > > > > > > > > > +++ -vpu
> > > > > > > > > > > +++ .c
> > > > > > > > > > > @@ -10,6 +10,7 @@
> > > > > > > > > > >  #include <linux/clk.h>
> > > > > > > > > > >  #include <linux/firmware.h>  #include
> > > > > > > > > > > <linux/interrupt.h>
> > > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > > >  #include "wave5-vpu.h"
> > > > > > > > > > >  #include "wave5-regdefine.h"
> > > > > > > > > > >  #include "wave5-vpuconfig.h"
> > > > > > > > > > > @@ -117,6 +118,65 @@ static int
> > > > > > > > > > > wave5_vpu_load_firmware(struct device
> > > > > > > > > > *dev, const char *fw_name,
> > > > > > > > > > >  	return 0;
> > > > > > > > > > >  }
> > > > > > > > > > >
> > > > > > > > > > > +static __maybe_unused int wave5_pm_suspend(struct
> > > > > > > > > > > +device
> > > > > > > > > > > +*dev)
> > > > > > {
> > > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > > +
> > > > > > > > > > > +	if (pm_runtime_suspended(dev))
> > > > > > > > > > > +		return 0;
> > > > > > > > > > > +
> > > > > > > > > > > +	wave5_vpu_sleep_wake(dev, true, NULL, 0);
> > > > > > > > > > > +	clk_bulk_disable_unprepare(vpu->num_clks,
> > > > > > > > > > > +vpu->clks);
> > > > > > > > > > > +
> > > > > > > > > > > +	return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +static __maybe_unused int wave5_pm_resume(struct
> > > > > > > > > > > +device
> > > > *dev) {
> > > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > > +	int ret = 0;
> > > > > > > > > > > +
> > > > > > > > > > > +	wave5_vpu_sleep_wake(dev, false, NULL, 0);
> > > > > > > > > > > +	ret = clk_bulk_prepare_enable(vpu->num_clks,
> vpu-
> > > > > clks);
> > > > > > > > > > > +	if (ret) {
> > > > > > > > > > > +		dev_err(dev, "Enabling clocks,
> fail: %d\n",
> > > > ret);
> > > > > > > > > > > +		return ret;
> > > > > > > > > > > +	}
> > > > > > > > > > > +
> > > > > > > > > > > +	return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +static __maybe_unused int wave5_suspend(struct
> > > > > > > > > > > +device
> > > > > > > > > > > +*dev)
> > > > {
> > > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > > +	struct vpu_instance *inst;
> > > > > > > > > > > +
> > > > > > > > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > > > > > > > +		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
> > > > > > > > > > > +
> > > > > > > > > > > +	return pm_runtime_force_suspend(dev); }
> > > > > > > > > > > +
> > > > > > > > > > > +static __maybe_unused int wave5_resume(struct
> > > > > > > > > > > +device
> > > > > > > > > > > +*dev)
> > > > {
> > > > > > > > > > > +	struct vpu_device *vpu = dev_get_drvdata(dev);
> > > > > > > > > > > +	struct vpu_instance *inst;
> > > > > > > > > > > +	int ret = 0;
> > > > > > > > > > > +
> > > > > > > > > > > +	ret = pm_runtime_force_resume(dev);
> > > > > > > > > > > +	if (ret < 0)
> > > > > > > > > > > +		return ret;
> > > > > > > > > > > +
> > > > > > > > > > > +	list_for_each_entry(inst, &vpu->instances, list)
> > > > > > > > > > > +		v4l2_m2m_resume(inst->v4l2_m2m_dev);
> > > > > > > > > > > +
> > > > > > > > > > > +	return ret;
> > > > > > > > > > > +}
> > > > > > > > > >
> > > > > > > > > > The functions wave5_suspend() and wave5_resume() are
> > > > > > > > > > not just "maybe_unsued" but actually never used. What
> > > > > > > > > > was the
> > > > intention ?
> > > > > > > > > > Considering the usage of __maybe_unused has been such
> > > > > > > > > > a bad friend for this one, could you instead bracket
> > > > > > > > > > the functions with an
> > > > > > > > explicit ?
> > > > > > > > > >
> > > > > > > > > > #ifdef CONFIG_PM
> > > > > > > > > > #endif
> > > > > > > > > >
> > > > > > > > > > This way the compiler will have a word if you
> > > > > > > > > > implement something that you forgot to actually use.
> > > > > > > > > >
> > > > > > > > > > > +
> > > > > > > > > > > +static const struct dev_pm_ops wave5_pm_ops = {
> > > > > > > > > > > +	SET_RUNTIME_PM_OPS(wave5_pm_suspend,
> > > > > > > > > > > +wave5_pm_resume,
> > > > > > > > NULL) };
> > > > > > > > > > > +
> > > > > > > > > > >  static int wave5_vpu_probe(struct platform_device
> > > > > > > > > > > *pdev)
> > > {
> > > > > > > > > > >  	int ret;
> > > > > > > > > > > @@ -232,6 +292,10 @@ static int
> > > > > > > > > > > wave5_vpu_probe(struct platform_device
> > > > > > > > > > *pdev)
> > > > > > > > > > >  		 (match_data->flags & WAVE5_IS_DEC) ?
> > > > "'DECODE'" : "");
> > > > > > > > > > >  	dev_info(&pdev->dev, "Product Code:      0x%x\n",
> dev-
> > > > > > > > > product_code);
> > > > > > > > > > >  	dev_info(&pdev->dev, "Firmware Revision: %u\n",
> > > > > > > > > > > fw_revision);
> > > > > > > > > > > +
> > > > > > > > > > > +	pm_runtime_enable(&pdev->dev);
> > > > > > > > > > > +	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
> > > > > > > > > > > +
> > > > > > > > > > >  	return 0;
> > > > > > > > > > >
> > > > > > > > > > >  err_enc_unreg:
> > > > > > > > > > > @@ -254,6 +318,9 @@ static int
> > > > > > > > > > > wave5_vpu_remove(struct platform_device
> > > > > > > > > > > *pdev)  {
> > > > > > > > > > >  	struct vpu_device *dev =
> > > > > > > > > > > dev_get_drvdata(&pdev->dev);
> > > > > > > > > > >
> > > > > > > > > > > +	pm_runtime_put_sync(&pdev->dev);
> > > > > > > > > > > +	pm_runtime_disable(&pdev->dev);
> > > > > > > > > > > +
> > > > > > > > > > >  	mutex_destroy(&dev->dev_lock);
> > > > > > > > > > >  	mutex_destroy(&dev->hw_lock);
> > > > > > > > > > >  	clk_bulk_disable_unprepare(dev->num_clks,
> > > > > > > > > > > dev->clks);
> > > > @@
> > > > > > > > > > > -
> > > > > > > > 281,6
> > > > > > > > > > > +348,7 @@ static struct platform_driver
> > > > > > > > > > > +wave5_vpu_driver = {
> > > > > > > > > > >  	.driver = {
> > > > > > > > > > >  		.name = VPU_PLATFORM_DEVICE_NAME,
> > > > > > > > > > >  		.of_match_table =
> of_match_ptr(wave5_dt_ids),
> > > > > > > > > > > +		.pm = &wave5_pm_ops,
> > > > > > > > > > >  		},
> > > > > > > > > > >  	.probe = wave5_vpu_probe,
> > > > > > > > > > >  	.remove = wave5_vpu_remove, diff --git
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-
> vpuapi.
> > > > > > > > > > > c
> > > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5-
> vpuapi.
> > > > > > > > > > > c index 1a3efb638dde..f1f8e4fc8474 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5-
> vpuapi.
> > > > > > > > > > > c
> > > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5
> > > > > > > > > > > +++ -vpu
> > > > > > > > > > > +++ ap
> > > > > > > > > > > +++ i.c
> > > > > > > > > > > @@ -6,6 +6,7 @@
> > > > > > > > > > >   */
> > > > > > > > > > >
> > > > > > > > > > >  #include <linux/bug.h>
> > > > > > > > > > > +#include <linux/pm_runtime.h>
> > > > > > > > > > >  #include "wave5-vpuapi.h"
> > > > > > > > > > >  #include "wave5-regdefine.h"
> > > > > > > > > > >  #include "wave5.h"
> > > > > > > > > > > @@ -232,6 +233,9 @@ int wave5_vpu_dec_close(struct
> > > > > > > > > > > vpu_instance *inst,
> > > > > > > > > > > u32 *fail_res)
> > > > > > > > > > >
> > > > > > > > > > >  	wave5_vdi_free_dma_memory(vpu_dev,
> > > > > > > > > > > &p_dec_info->vb_task);
> > > > > > > > > > >
> > > > > > > > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > > > > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > > > > > > > > +
> > > > > > > > > > >  unlock_and_return:
> > > > > > > > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > > > > > > >
> > > > > > > > > > > @@ -734,6 +738,9 @@ int wave5_vpu_enc_close(struct
> > > > > > > > > > > vpu_instance *inst,
> > > > > > > > > > > u32 *fail_res)
> > > > > > > > > > >
> > > > > > > > > > >  	wave5_vdi_free_dma_memory(vpu_dev,
> > > > > > > > > > > &p_enc_info->vb_task);
> > > > > > > > > > >
> > > > > > > > > > > +	if (!pm_runtime_suspended(inst->dev->dev))
> > > > > > > > > > > +		pm_runtime_put_sync(inst->dev->dev);
> > > > > > > > > >
> > > > > > > > > > This seems very unnatural. We do the get() in
> > > > > > > > > > "start_streaming()", but the
> > > > > > > > > > put() is only done when the device is closed, or when
> > > > > > > > > > the driver is removed. As this is not balanced, you
> > > > > > > > > > seem to have to check the suspended condition all over
> the place.
> > > > > > > > > >
> > > > > > > > > > I think we could aim for
> > > > > > > > > > start_streaming()/stop_streaming()
> > > > > > > > > > for your get/put placement. At least they will be
> > > > > > > > > > bound to an entirely balanced
> > > > > > > > API.
> > > > > > > > > > But then, a media player in paused sate will prevent
> > > > > > > > > > that device from being suspended.
> > > > > > > > > >
> > > > > > > > > > If the HW is capable of preserving enough state, and
> > > > > > > > > > From the short doc I have it gives me the impression
> > > > > > > > > > it can preserve that, I'd suggest to follow what
> > > > > > > > > > hantro driver is doing. What is does is that it will
> > > > > > > > > > do get() in device_run(), and put() whenever the job
> > > > > > > > > > completes. This driver has been designed so when there
> > > > > > > > > > is no job, it means the firmware is currently idle and
> looking for more work.
> > > > > > > > > > So it seems like the perfect moment to
> > > > > > do suspend it.
> > > > > > > > > >
> > > > > > > > > > Nicolas
> > > > > > > > > >
> > > > > > > > > > > +
> > > > > > > > > > >  	mutex_unlock(&vpu_dev->hw_lock);
> > > > > > > > > > >
> > > > > > > > > > >  	return 0;
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > > b/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > > index 063028eccd3b..6125eff938a8 100644
> > > > > > > > > > > ---
> > > > > > > > > > > a/drivers/media/platform/chips-media/wave5/wave5.h
> > > > > > > > > > > +++ b/drivers/media/platform/chips-media/wave5/wave5
> > > > > > > > > > > +++ .h
> > > > > > > > > > > @@ -56,6 +56,9 @@ int wave5_vpu_get_version(struct
> > > > > > > > > > > vpu_device *vpu_dev, u32 *revision);
> > > > > > > > > > >
> > > > > > > > > > >  int wave5_vpu_init(struct device *dev, u8 *fw,
> > > > > > > > > > > size_t size);
> > > > > > > > > > >
> > > > > > > > > > > +int wave5_vpu_sleep_wake(struct device *dev, bool
> > > > > > > > > > > +i_sleep_wake, const
> > > > > > > > > > uint16_t *code,
> > > > > > > > > > > +			 size_t size);
> > > > > > > > > > > +
> > > > > > > > > > >  int wave5_vpu_reset(struct device *dev, enum
> > > > > > > > > > > sw_reset_mode reset_mode);
> > > > > > > > > > >
> > > > > > > > > > >  int wave5_vpu_build_up_dec_param(struct
> > > > > > > > > > > vpu_instance *inst, struct dec_open_param *param);
> > > > > > > > >
> > > > > > >
> > > > >
> >
diff mbox series

Patch

diff --git a/drivers/media/platform/chips-media/wave5/wave5-hw.c b/drivers/media/platform/chips-media/wave5/wave5-hw.c
index 8ad7f3a28ae1..8aade5a38439 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-hw.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-hw.c
@@ -503,6 +503,7 @@  int wave5_vpu_build_up_dec_param(struct vpu_instance *inst,
 	/* This register must be reset explicitly */
 	vpu_write_reg(inst->dev, W5_CMD_EXT_ADDR, 0);
 	vpu_write_reg(inst->dev, W5_CMD_NUM_CQ_DEPTH_M1, (COMMAND_QUEUE_DEPTH - 1));
+	vpu_write_reg(inst->dev, W5_CMD_ERR_CONCEAL, 0);
 
 	ret = send_firmware_command(inst, W5_CREATE_INSTANCE, true, NULL, NULL);
 	if (ret) {
@@ -1075,8 +1076,8 @@  int wave5_vpu_re_init(struct device *dev, u8 *fw, size_t size)
 	return setup_wave5_properties(dev);
 }
 
-static int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const uint16_t *code,
-				size_t size)
+int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const uint16_t *code,
+			 size_t size)
 {
 	u32 reg_val;
 	struct vpu_buf *common_vb;
diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
index ef227af72348..328a7a8f26c5 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-dec.c
@@ -5,6 +5,7 @@ 
  * Copyright (C) 2021-2023 CHIPS&MEDIA INC
  */
 
+#include <linux/pm_runtime.h>
 #include "wave5-helper.h"
 
 #define VPU_DEC_DEV_NAME "C&M Wave5 VPU decoder"
@@ -1387,9 +1388,17 @@  static int wave5_vpu_dec_start_streaming(struct vb2_queue *q, unsigned int count
 
 	if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && inst->state == VPU_INST_STATE_NONE) {
 		struct dec_open_param open_param;
+		int err = 0;
 
 		memset(&open_param, 0, sizeof(struct dec_open_param));
 
+		err = pm_runtime_resume_and_get(inst->dev->dev);
+		if (err) {
+			dev_err(inst->dev->dev, "decoder runtime resume failed %d\n", err);
+			ret = -EINVAL;
+			goto return_buffers;
+		}
+
 		ret = wave5_vpu_dec_allocate_ring_buffer(inst);
 		if (ret)
 			goto return_buffers;
diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
index 761775216cd4..ff73d69de41c 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu-enc.c
@@ -5,6 +5,7 @@ 
  * Copyright (C) 2021-2023 CHIPS&MEDIA INC
  */
 
+#include <linux/pm_runtime.h>
 #include "wave5-helper.h"
 
 #define VPU_ENC_DEV_NAME "C&M Wave5 VPU encoder"
@@ -1387,9 +1388,17 @@  static int wave5_vpu_enc_start_streaming(struct vb2_queue *q, unsigned int count
 
 	if (inst->state == VPU_INST_STATE_NONE && q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
 		struct enc_open_param open_param;
+		int err = 0;
 
 		memset(&open_param, 0, sizeof(struct enc_open_param));
 
+		err = pm_runtime_resume_and_get(inst->dev->dev);
+		if (err) {
+			dev_err(inst->dev->dev, "encoder runtime resume failed %d\n", err);
+			ret = -EINVAL;
+			goto return_buffers;
+		}
+
 		wave5_set_enc_openparam(&open_param, inst);
 
 		ret = wave5_vpu_enc_open(inst, &open_param);
diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpu.c b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
index 0d90b5820bef..f81409740a56 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpu.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpu.c
@@ -10,6 +10,7 @@ 
 #include <linux/clk.h>
 #include <linux/firmware.h>
 #include <linux/interrupt.h>
+#include <linux/pm_runtime.h>
 #include "wave5-vpu.h"
 #include "wave5-regdefine.h"
 #include "wave5-vpuconfig.h"
@@ -117,6 +118,65 @@  static int wave5_vpu_load_firmware(struct device *dev, const char *fw_name,
 	return 0;
 }
 
+static __maybe_unused int wave5_pm_suspend(struct device *dev)
+{
+	struct vpu_device *vpu = dev_get_drvdata(dev);
+
+	if (pm_runtime_suspended(dev))
+		return 0;
+
+	wave5_vpu_sleep_wake(dev, true, NULL, 0);
+	clk_bulk_disable_unprepare(vpu->num_clks, vpu->clks);
+
+	return 0;
+}
+
+static __maybe_unused int wave5_pm_resume(struct device *dev)
+{
+	struct vpu_device *vpu = dev_get_drvdata(dev);
+	int ret = 0;
+
+	wave5_vpu_sleep_wake(dev, false, NULL, 0);
+	ret = clk_bulk_prepare_enable(vpu->num_clks, vpu->clks);
+	if (ret) {
+		dev_err(dev, "Enabling clocks, fail: %d\n", ret);
+		return ret;
+	}
+
+	return ret;
+}
+
+static __maybe_unused int wave5_suspend(struct device *dev)
+{
+	struct vpu_device *vpu = dev_get_drvdata(dev);
+	struct vpu_instance *inst;
+
+	list_for_each_entry(inst, &vpu->instances, list)
+		v4l2_m2m_suspend(inst->v4l2_m2m_dev);
+
+	return pm_runtime_force_suspend(dev);
+}
+
+static __maybe_unused int wave5_resume(struct device *dev)
+{
+	struct vpu_device *vpu = dev_get_drvdata(dev);
+	struct vpu_instance *inst;
+	int ret = 0;
+
+	ret = pm_runtime_force_resume(dev);
+	if (ret < 0)
+		return ret;
+
+	list_for_each_entry(inst, &vpu->instances, list)
+		v4l2_m2m_resume(inst->v4l2_m2m_dev);
+
+	return ret;
+}
+
+static const struct dev_pm_ops wave5_pm_ops = {
+	SET_RUNTIME_PM_OPS(wave5_pm_suspend, wave5_pm_resume, NULL)
+};
+
 static int wave5_vpu_probe(struct platform_device *pdev)
 {
 	int ret;
@@ -232,6 +292,10 @@  static int wave5_vpu_probe(struct platform_device *pdev)
 		 (match_data->flags & WAVE5_IS_DEC) ? "'DECODE'" : "");
 	dev_info(&pdev->dev, "Product Code:      0x%x\n", dev->product_code);
 	dev_info(&pdev->dev, "Firmware Revision: %u\n", fw_revision);
+
+	pm_runtime_enable(&pdev->dev);
+	wave5_vpu_sleep_wake(&pdev->dev, true, NULL, 0);
+
 	return 0;
 
 err_enc_unreg:
@@ -254,6 +318,9 @@  static int wave5_vpu_remove(struct platform_device *pdev)
 {
 	struct vpu_device *dev = dev_get_drvdata(&pdev->dev);
 
+	pm_runtime_put_sync(&pdev->dev);
+	pm_runtime_disable(&pdev->dev);
+
 	mutex_destroy(&dev->dev_lock);
 	mutex_destroy(&dev->hw_lock);
 	clk_bulk_disable_unprepare(dev->num_clks, dev->clks);
@@ -281,6 +348,7 @@  static struct platform_driver wave5_vpu_driver = {
 	.driver = {
 		.name = VPU_PLATFORM_DEVICE_NAME,
 		.of_match_table = of_match_ptr(wave5_dt_ids),
+		.pm = &wave5_pm_ops,
 		},
 	.probe = wave5_vpu_probe,
 	.remove = wave5_vpu_remove,
diff --git a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
index 1a3efb638dde..f1f8e4fc8474 100644
--- a/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
+++ b/drivers/media/platform/chips-media/wave5/wave5-vpuapi.c
@@ -6,6 +6,7 @@ 
  */
 
 #include <linux/bug.h>
+#include <linux/pm_runtime.h>
 #include "wave5-vpuapi.h"
 #include "wave5-regdefine.h"
 #include "wave5.h"
@@ -232,6 +233,9 @@  int wave5_vpu_dec_close(struct vpu_instance *inst, u32 *fail_res)
 
 	wave5_vdi_free_dma_memory(vpu_dev, &p_dec_info->vb_task);
 
+	if (!pm_runtime_suspended(inst->dev->dev))
+		pm_runtime_put_sync(inst->dev->dev);
+
 unlock_and_return:
 	mutex_unlock(&vpu_dev->hw_lock);
 
@@ -734,6 +738,9 @@  int wave5_vpu_enc_close(struct vpu_instance *inst, u32 *fail_res)
 
 	wave5_vdi_free_dma_memory(vpu_dev, &p_enc_info->vb_task);
 
+	if (!pm_runtime_suspended(inst->dev->dev))
+		pm_runtime_put_sync(inst->dev->dev);
+
 	mutex_unlock(&vpu_dev->hw_lock);
 
 	return 0;
diff --git a/drivers/media/platform/chips-media/wave5/wave5.h b/drivers/media/platform/chips-media/wave5/wave5.h
index 063028eccd3b..6125eff938a8 100644
--- a/drivers/media/platform/chips-media/wave5/wave5.h
+++ b/drivers/media/platform/chips-media/wave5/wave5.h
@@ -56,6 +56,9 @@  int wave5_vpu_get_version(struct vpu_device *vpu_dev, u32 *revision);
 
 int wave5_vpu_init(struct device *dev, u8 *fw, size_t size);
 
+int wave5_vpu_sleep_wake(struct device *dev, bool i_sleep_wake, const uint16_t *code,
+			 size_t size);
+
 int wave5_vpu_reset(struct device *dev, enum sw_reset_mode reset_mode);
 
 int wave5_vpu_build_up_dec_param(struct vpu_instance *inst, struct dec_open_param *param);