[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b2f7552d37075538e22640f7b42838d29d3f8b3e.camel@collabora.com>
Date: Thu, 20 Jun 2024 10:05:18 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Devarsh Thakkar <devarsht@...com>, "jackson.lee"
<jackson.lee@...psnmedia.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
Hi Devarsh,
Le jeudi 20 juin 2024 à 15:05 +0530, Devarsh Thakkar a écrit :
> In my view the delayed suspend functionality is generally helpful for devices
> where resume latencies are higher for e.g. this light sensor driver [2] uses
> it because it takes 250ms to stabilize after resumption and I don't see this
> being used in codec drivers generally since there is no such large resume
> latency. Please let me know if I am missing something or there is a strong
> reason to have delayed suspend for wave5.
It sounds like you did proper scientific testing of the suspend results calls,
mind sharing the actual data ?
Nicolas
Powered by blists - more mailing lists