Hi Andy, On Wed, Jan 22, 2025 at 06:36:52PM +0200, Andy Shevchenko wrote: > On Wed, Jan 22, 2025 at 11:54:11AM +0000, Sakari Ailus wrote: > > On Mon, Jan 20, 2025 at 07:23:07PM +0200, Andy Shevchenko wrote: > > > On Mon, Jan 20, 2025 at 12:11:23PM +0200, Sakari Ailus wrote: > > > > Lift the xshutdown (enable) GPIO 1 ms after enabling the regulators, as > > > > required by the sensor's power-up sequence. > > ... > > > > > + usleep_range(1000, 1100); > > > > > > Why not fsleep() ? > > > > Could be, but fsleep() uses a range that is as large as the delay is. > > fsleep() is recommended way as it knows much better the implementation details > of the delay APIs and which one to choose based on input. As recently stated by > the fix series to delay APIs the fsleep() will give up to 25% on top of the > asked delay, meaning in this case somewhat 250us. Taking it into account the > resulting values I do not think usleep_range() should be here. I.o.w. I do not > see enough justification for _not_ using fsleep(). > > Also note that fsleep() ranges try to keep balance between oversleep and power > consumption. Your delay is rather tough as sometimes 100us is almost the time > needed to go to the deep sleep for the CPU package and return from it. Have you looked at what fsleep() does? I agree most of the time it's the best choice when you need to sleep (at least) some time, but generally sensor power-up time is critical. I'm fine using 1000 for both, too. -- Regards, Sakari Ailus
