Hello Linus and Jonathan > -----Original Message----- > From: Linus Walleij <linus.walleij@xxxxxxxxxx> > Sent: 11 February 2022 02:12 > To: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > Cc: TOSCANELLI Massimo <massimo.toscanelli@xxxxxxxxxxxxxxxxxxxx>; > linux-kernel@xxxxxxxxxxxxxxx; jic23@xxxxxxxxxx; lars@xxxxxxxxxx; > caihuoqing@xxxxxxxxx; aardelean@xxxxxxxxxxx; > andy.shevchenko@xxxxxxxxx; hdegoede@xxxxxxxxxx; LI Qingwu <qing- > wu.li@xxxxxxxxxxxxxxxxxxxxxxx>; stephan@xxxxxxxxxxx; linux- > iio@xxxxxxxxxxxxxxx; GEO-CHHER-bsp-development <bsp- > development.geo@xxxxxxxxxxxxxxxxxxxx> > Subject: Re: [PATCH RESEND 0/2] Solve data access delay of ST sensors > > > On Mon, Feb 7, 2022 at 2:59 PM Jonathan Cameron > <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Mon, 7 Feb 2022 09:04:41 +0000 > > Massimo Toscanelli <massimo.toscanelli@xxxxxxxxxxxxxxxxxxxx> wrote: > > > The standard approach to avoiding rapid power up and power down cycles > > is to use runtime_pm with autosuspend and a period set at a period of > > perhaps 1 second. Would that work for you? You'll pay the costs of > > power up only on the first read after a period of not reading. > > > > Exposing the control to userspace for this sort of thing is normally a > > bad idea because userspace generally has no idea if it should use it > > as there is no clean way of telling userspace the costs of not using > > it (as those will be device specific). > > > > If you have a usecase that requires regular reading you should also > > think about whether using the buffered interface is more appropriate. > > IIRC that will keep these devices powered up continuously whilst the > > buffer is enabled and will provide a lower overhead way of reading > > data than sysfs reads. > > I see that I have repeted similar comments. > Thanks a lot for your suggestions, I decided to go for the second solution proposed by Jonathan. Using the buffered interface should be enough, you can discard the patches. Massimo
