Re: Controlling device power management from terminal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Andy,
Thanks for the explanation and help - now the PM runtime suspend and
resume are triggered. It was indeed the combination of bad
initialization and that I did not have "enter wakeup" on the read
data.

Currently, I view pm_runtime mode as a power saving mode (device
should be in low power) and normal running as running mode. However,
the sensor is able to report data in both modes - just reading is a
bit different. I also do not have a problem with autosuspend after
some time, but I do wonder how would user change the power mode from
pm_runtime to normal mode (reading, in this case, should not change
the mode). What is the recommended ABI for that?

On Mon, 25 Jul 2022 at 23:45, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
>
> On Mon, Jul 25, 2022 at 11:36 PM Crt Mori <cmo@xxxxxxxxxxx> wrote:
> > On Mon, 25 Jul 2022 at 23:27, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > > On Mon, Jul 25, 2022 at 10:48 AM Crt Mori <cmo@xxxxxxxxxxx> wrote:
> > > >
> > > > Hi,
> > > > I am implementing the power saving modes for mlx90632 device driver
> > > > and while I have implemented routines for SET_RUNTIME_PM_OPS
> > > > (runtime_pm_suspend and runtime_pm_resume) I am not able to find out
> > > > how to trigger them from the terminal.
> > > >
> > > > It could be that my driver code for power management implementation is
> > > > incomplete and I need to initialize something more.
> > > >
> > > > Maybe it is helpful, but the power submodule of the device contains below files:
> > > >
> > > > $ ls -al /sys/bus/iio/devices/iio\:device0/power
> > > > total 0
> > > > drwxrwxr-x 2 root gpio    0 Apr  6 14:17 .
> > > > drwxrwxr-x 3 root gpio    0 Apr  6 14:17 ..
> > > > -rw-rw-r-- 1 root gpio 4096 Apr  6 14:17 async
> > > > -rw-rw-r-- 1 root gpio 4096 Apr  6 14:17 autosuspend_delay_ms
> > > > -rw-rw-r-- 1 root gpio 4096 Apr  6 14:18 control
> > > > -r--r--r-- 1 root gpio 4096 Apr  6 14:17 runtime_active_kids
> > > > -r--r--r-- 1 root gpio 4096 Apr  6 14:17 runtime_active_time
> > > > -r--r--r-- 1 root gpio 4096 Apr  6 14:17 runtime_enabled
> > > > -r--r--r-- 1 root gpio 4096 Apr  6 14:17 runtime_status
> > > > -r--r--r-- 1 root gpio 4096 Apr  6 14:17 runtime_suspended_time
> > > > -r--r--r-- 1 root gpio 4096 Apr  6 14:17 runtime_usage
> > > >
> > > > And control is already set to "auto" which according to documentation
> > > > should allow the PM.
> > >
> > > 'auto' should enable it. So, whenever the driver thinks it's a time to
> > > power off/on the device it will call the methods.
> > >
> > > You may hack a bit to enable autosuspend (which often is not a good
> > > idea for IIO sensors) and see it done automatically after some time.
> >
> > So the idea is to wait?
>
> Yes.
>
> > How would I enable autosuspend - by lowering
> > the autosusped_delay_ms?
>
> Yep, if you wish. The driver should enable it though.

Is there a way for driver to attach a callback to
power/autosuspend_delay_ms request or to power/control?

>
> > How does the driver decide that it is time to
> > power off/on?
>
> I'm not a driver author, it seems you , who should answer this
> question (as you are about to add PM there, am I right?).
>
> > Do I need something else enabled to have this done automatically?
> > Autosuspend is 5000 in my case which would mean 5 seconds, so I am
> > quite sure I waited that long and I did not see printk's from the
> > driver.
>
> Something prevents it from doing (reference counting) or simply some
> initialization / enablement is forgotten. For different buses
> different PM runtime rules are applied (for example, IIRC, PCI core
> does it for you, while platform bus is on what driver wants basis).
>
> --
> With Best Regards,
> Andy Shevchenko



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux