[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SE1P216MB13034CDE58672FEE1358AF2FEDC92@SE1P216MB1303.KORP216.PROD.OUTLOOK.COM>
Date: Fri, 21 Jun 2024 12:45:44 +0000
From: jackson.lee <jackson.lee@...psnmedia.com>
To: Devarsh Thakkar <devarsht@...com>, Nicolas Dufresne
<nicolas.dufresne@...labora.com>, "mchehab@...nel.org" <mchehab@...nel.org>,
"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>, "Luthra, Jai" <j-luthra@...com>, Vibhore
<vibhore@...com>, Dhruva Gole <d-gole@...com>, Aradhya <a-bhatia1@...com>,
"Raghavendra, Vignesh" <vigneshr@...com>
Subject: RE: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime
suspend/resume
> -----Original Message-----
> From: Devarsh Thakkar <devarsht@...com>
> Sent: Friday, June 21, 2024 8:55 PM
> To: jackson.lee <jackson.lee@...psnmedia.com>; Nicolas Dufresne
> <nicolas.dufresne@...labora.com>; mchehab@...nel.org;
> 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; Luthra, Jai <j-luthra@...com>;
> Vibhore <vibhore@...com>; Dhruva Gole <d-gole@...com>; Aradhya <a-
> bhatia1@...com>; Raghavendra, Vignesh <vigneshr@...com>
> Subject: Re: [RESEND PATCH v6 2/4] media: chips-media: wave5: Support runtime
> suspend/resume
>
> Hi Jackson,
>
> On 21/06/24 06:00, jackson.lee wrote:
> > Hi Nicolas / Devarsh
> >
> >
> > There are lots of mail thread in the loop, I have confusion.
> > I'd like to make check-up list for the "Support runtime suspend/resume"
> patch.
> >
> > 1. Profiling resume latency
> > 2. after that, adjusting the time.
> >
>
> Beyond above two points,
>
Hi Brandon
According to today meeting, should we take care of this ?
> 3. I think this patchset also breaks hrtimer polling and so the VPU operation
> on AM62A which completely relies on polling, you can test with removing the
> interrupt property from your dts file before/after this patch-set. With the
> polling it needs to be taken care that polling is started only after device
> is on power-on state and is stopped before device gets suspended.
>
Hi Devarsh
I have already sent some changes to fix this in the previous e-mail. Please refer to the e-mail.
> 4. There is some discussion going on between me and Nicholas on whether
> delayed suspend is really required after last instance close or not. My
> thought was that we should suspend immediately after last instance close, but
> Nicolas mentioned some concerns w.r.t use-cases such as gapless playback so I
> am following up with him.
>
> Regards
> Devarsh
Powered by blists - more mailing lists