linux-kernel - RE: [PATCH v3 04/11] i2c: riic: Enable runtime PM autosuspend support

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:
 <TY3PR01MB1134615117603F62796558D1486A62@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 12 Jul 2024 07:15:43 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Claudiu.Beznea <claudiu.beznea@...on.dev>, Chris Brandt
	<Chris.Brandt@...esas.com>, "andi.shyti@...nel.org" <andi.shyti@...nel.org>,
	"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
	<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"geert+renesas@...der.be" <geert+renesas@...der.be>, "magnus.damm@...il.com"
	<magnus.damm@...il.com>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
	"wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>
CC: "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Claudiu.Beznea
	<claudiu.beznea@...on.dev>, Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: RE: [PATCH v3 04/11] i2c: riic: Enable runtime PM autosuspend support

Hi Claudiu,

> -----Original Message-----
> From: Claudiu <claudiu.beznea@...on.dev>
> Sent: Thursday, July 11, 2024 12:52 PM
> Subject: [PATCH v3 04/11] i2c: riic: Enable runtime PM autosuspend support
> 
> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> 
> Enable runtime PM autosuspend support for the RIIC driver. With this, in case there are consecutive
> xfer requests the device wouldn't be runtime enabled/disabled after each consecutive xfer but after
> the the delay configured by user. With this, we can avoid touching hardware registers involved in
> runtime PM suspend/resume saving in this way some cycles. The default chosen autosuspend delay is
> zero to keep the previous driver behavior.

On the other hand, you are saving power. Currently the driver is highly optimized for 
Power usage.

Before transfer turn on the clock
After transfer turn off the clock, this is the optimal power usage correspond to suspend delay.

By adding suspend delay, you are consuming power corresponding to
that delay.

Cheers,
Biju