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:
 <TY3PR01MB11346200C5A3DC24A3773EF7886A62@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Fri, 12 Jul 2024 07:53:26 +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.uj@...renesas.com>
Subject: RE: [PATCH v3 04/11] i2c: riic: Enable runtime PM autosuspend support

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@...on.dev>
> Sent: Friday, July 12, 2024 8:49 AM
> Subject: Re: [PATCH v3 04/11] i2c: riic: Enable runtime PM autosuspend support
> 
> 
> 
> On 12.07.2024 10:45, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: claudiu beznea <claudiu.beznea@...on.dev>
> >> Sent: Friday, July 12, 2024 8:41 AM
> >> Subject: Re: [PATCH v3 04/11] i2c: riic: Enable runtime PM
> >> autosuspend support
> >>
> >> Hi, Biju,
> >>
> >> On 12.07.2024 10:15, Biju Das wrote:
> >>> 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.
> >>
> >> The default delay is zero, see the following diff in this patch:
> >>
> >> @@ -479,6 +481,8 @@ static int riic_i2c_probe(struct platform_device
> >> *pdev)
> >>
> >>  	i2c_parse_fw_timings(dev, &i2c_t, true);
> >>
> >> +	pm_runtime_set_autosuspend_delay(dev, 0);
> >
> > I just provided justification, why you addes 0  msec here, compared to
> > xx msec in the original internal version.
> 
> Isn't it in the commit description already?
> 
> "The default chosen autosuspend delay is zero to keep the previous driver behavior."

That is correct. Some people may have different opinion like other driver
have non zero delays.  Just to get wider opinion.

Note:
Even the original internal patch has non zero delay and then I suggested you to
put 0. It is trade off between frequent transfer vs power usage.

Cheers,
Biju


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ