linux-kernel - Re: [PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus regulator control

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] [day] [month] [year] [list]

Message-ID: <idbp6ckhu2pdt5p6vapcblqlinezpq5miqzl4hrzmlbgrniw7o@ucd42tvbtfmr>
Date: Wed, 12 Mar 2025 00:16:31 +0100
From: Andi Shyti <andi.shyti@...nel.org>
To: Zoie Lin (林禹妡) <Zoie.Lin@...iatek.com>
Cc: Qii Wang (王琪) <Qii.Wang@...iatek.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, "matthias.bgg@...il.com" <matthias.bgg@...il.com>, 
	Teddy Chen (陳乾元) <Teddy.Chen@...iatek.com>, 
	Project_Global_Chrome_Upstream_Group <Project_Global_Chrome_Upstream_Group@...iatek.com>, 
	Shunchang Wang (王舜昌) <ot_shunchang.wang@...iatek.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, 
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, 
	Joseph-CC Chang (張欽洲) <Joseph-CC.Chang@...iatek.com>, 
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>, "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>, 
	Leilk Liu (刘磊) <Leilk.Liu@...iatek.com>
Subject: Re: [PATCH v4 0/1] i2c: mediatek: add runtime PM operations and bus
 regulator control

Hi Zoie,

On Tue, Mar 04, 2025 at 08:37:27AM +0000, Zoie Lin (林禹妡) wrote:
> 
> ...
> 
> On Thu, 2025-02-13 at 12:57 +0100, AngeloGioacchino Del Regno wrote:
> > 
> > 
> > Turning on and off regulators at start of transfer and end of
> > transfer respectively
> > is very expensive and, while it makes sense for power efficiency of
> > the controller,
> > it doesn't make sense for:
> > 
> >   1. Responsiveness (latency); and
> >   2. Platform power efficiency at a whole.
> > 
> > As a start, just set the autosuspend delay to 250ms; this gives you
> > at least time
> > to bring up clocks and regulators and usually finish a transfer at
> > 400KHz, giving
> > you the chance to also get some more requests before autosuspend
> > decides to, well,
> > auto..suspend the device.
> > 
> > The right way of choosing an autosuspend delay a bit more precisely,
> > though, for
> > this device, would be to check the bus speed and calculate the
> > autosuspend time
> > accordingly.
> 
> We understand the importance of balancing power efficiency and
> responsiveness. Given the diversity of I2C devices connected
> under each platform, it is indeed challenging to estimate an
> appropriate delay time for testing.
> 
> Therefore, we would like to proceed with your initial suggestion
> and set the autosuspend delay to 250ms. Based on our preliminary
> tests, this adjustment appears to be a practical solution across 
> our existing platforms.

Am I understanding correctly that you are planning a v2?

Andi