linux-kernel - RE: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime suspend/resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SE1P216MB130382374B76CD8BC9FFCFE5EDC82@SE1P216MB1303.KORP216.PROD.OUTLOOK.COM>
Date: Thu, 20 Jun 2024 00:11:24 +0000
From: jackson.lee <jackson.lee@...psnmedia.com>
To: Devarsh Thakkar <devarsht@...com>, "mchehab@...nel.org"
	<mchehab@...nel.org>, "nicolas@...fresne.ca" <nicolas@...fresne.ca>,
	"sebastian.fricke@...labora.com" <sebastian.fricke@...labora.com>
CC: "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hverkuil@...all.nl" <hverkuil@...all.nl>, Nas Chung
	<nas.chung@...psnmedia.com>, lafley.kim <lafley.kim@...psnmedia.com>,
	"b-brnich@...com" <b-brnich@...com>, Nicolas Dufresne
	<nicolas.dufresne@...labora.com>
Subject: RE: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime
 suspend/resume



> -----Original Message-----
> From: jackson.lee
> Sent: Thursday, June 20, 2024 8:57 AM
> To: Devarsh Thakkar <devarsht@...com>; mchehab@...nel.org;
> nicolas@...fresne.ca; sebastian.fricke@...labora.com
> Cc: linux-media@...r.kernel.org; linux-kernel@...r.kernel.org;
> hverkuil@...all.nl; Nas Chung <nas.chung@...psnmedia.com>; lafley.kim
> <lafley.kim@...psnmedia.com>; b-brnich@...com; Nicolas Dufresne
> <nicolas.dufresne@...labora.com>
> 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@...com>
> > Sent: Wednesday, June 19, 2024 10:00 PM
> > To: jackson.lee <jackson.lee@...psnmedia.com>; mchehab@...nel.org;
> > nicolas@...fresne.ca; sebastian.fricke@...labora.com
> > Cc: linux-media@...r.kernel.org; linux-kernel@...r.kernel.org;
> > hverkuil@...all.nl; Nas Chung <nas.chung@...psnmedia.com>; lafley.kim
> > <lafley.kim@...psnmedia.com>; b-brnich@...com; Nicolas Dufresne
> > <nicolas.dufresne@...labora.com>
> > 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@...psnmedia.com>
> > >
> > > 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@...psnmedia.com>
> > > Signed-off-by: Nas Chung <nas.chung@...psnmedia.com>
> > > Reviewed-by: Nicolas Dufresne <nicolas.dufresne@...labora.com>
> >
> > [..]
> > >  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