Message-ID: <d4d43f9e19a9d0ecf54167fd3fc71f1fc03aec2d.camel@ndufresne.ca>
Date: Fri, 23 Feb 2024 13:09:31 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: "jackson.lee" <jackson.lee@...psnmedia.com>, "mchehab@...nel.org"
	 <mchehab@...nel.org>, "linux-media@...r.kernel.org"
	 <linux-media@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	 <linux-kernel@...r.kernel.org>, Nas Chung <nas.chung@...psnmedia.com>
Cc: "lafley.kim" <lafley.kim@...psnmedia.com>, "b-brnich@...com"
	 <b-brnich@...com>
Subject: Re: [RESEND PATCH v0 3/5] wave5 : Support runtime suspend/resume.

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@...psnmedia.com>
> > > > > > > > > > Signed-off-by: Nas Chung <nas.chung@...psnmedia.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);
> > > > > > > > 
> > > > > > 
> > > > 
> 

Powered by blists - more mailing lists