> -----Original Message-----
> From: jackson.lee
> Sent: Thursday, June 20, 2024 8:57 AM
> To: Devarsh Thakkar <devarsht@xxxxxx>; mchehab@xxxxxxxxxx;
> nicolas@xxxxxxxxxxxx; sebastian.fricke@xxxxxxxxxxxxx
> Cc: linux-media@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> hverkuil@xxxxxxxxx; Nas Chung <nas.chung@xxxxxxxxxxxxxxx>; lafley.kim
> <lafley.kim@xxxxxxxxxxxxxxx>; b-brnich@xxxxxx; Nicolas Dufresne
> <nicolas.dufresne@xxxxxxxxxxxxx>
> Subject: RE: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime
> suspend/resume
>
> Hi Devarsh
>
> If there is no feeding bitstreams during encoding and decoding frames, then
> driver's status is switched to suspended automatically by autosuspend.
> And if we don’t use autosuspend, it is very difficult for us to catch if
> there is feeding or not while working a pipeline.
> So it is very efficient for managing power status.
>
> If the delay is very great value, we can adjust it.
>
> Thanks
> Jackson
>
One more thing,
When an instance is closed or started, we are currently putting a power status to suspend or resumed immediately.
The autospend feature is being only used when there is no feeding while working a pipeline.
I don’t think the delay is very great value.
Thanks
> > -----Original Message-----
> > From: Devarsh Thakkar <devarsht@xxxxxx>
> > Sent: Wednesday, June 19, 2024 10:00 PM
> > To: jackson.lee <jackson.lee@xxxxxxxxxxxxxxx>; mchehab@xxxxxxxxxx;
> > nicolas@xxxxxxxxxxxx; sebastian.fricke@xxxxxxxxxxxxx
> > Cc: linux-media@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > hverkuil@xxxxxxxxx; Nas Chung <nas.chung@xxxxxxxxxxxxxxx>; lafley.kim
> > <lafley.kim@xxxxxxxxxxxxxxx>; b-brnich@xxxxxx; Nicolas Dufresne
> > <nicolas.dufresne@xxxxxxxxxxxxx>
> > Subject: Re: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support
> > runtime suspend/resume
> >
> > Hi Jackson,
> >
> > Thanks for the patch.
> > On 17/06/24 16:18, Jackson.lee wrote:
> > > From: "jackson.lee" <jackson.lee@xxxxxxxxxxxxxxx>
> > >
> > > Add support for runtime suspend/resume in the encoder and decoder.
> > > This is achieved by saving the VPU state and powering it off while
> > > the VPU
> > idle.
> > >
> > > Signed-off-by: Jackson.lee <jackson.lee@xxxxxxxxxxxxxxx>
> > > Signed-off-by: Nas Chung <nas.chung@xxxxxxxxxxxxxxx>
> > > Reviewed-by: Nicolas Dufresne <nicolas.dufresne@xxxxxxxxxxxxx>
> >
> > [..]
> > > static int wave5_vpu_probe(struct platform_device *pdev) {
> > > int ret;
> > > @@ -268,6 +301,12 @@ 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_set_autosuspend_delay(&pdev->dev, 5000);
> >
> > Why are we putting 5s delay for autosuspend ? Without using
> > auto-suspend delay too, we can directly go to suspended state when
> > last instance is closed and resume back when first instance is open.
> >
> > I don't think having an autosuspend delay (especially of 5s) bodes
> > well with low power-centric devices such as AM62A where we would
> > prefer to go to suspend state as soon as possible when the last instance is
> closed.
> >
> > Also apologies for the delay in review, this didn't caught my eye
> > earlier as commit message did not mention it either.
> >
> > Regards
> > Devarsh
