Mathieu Poirier <mathieu.poir...@linaro.org> writes: > On 30 June 2016 at 09:30, Alexander Shishkin > <alexander.shish...@linux.intel.com> wrote: >> Mathieu Poirier <mathieu.poir...@linaro.org> writes: >> >>> On 30 June 2016 at 06:56, Alexander Shishkin >>> <alexander.shish...@linux.intel.com> wrote: >>>> Currently, there's no runtime pm in stm class devices, which makes it >>>> harder for the underlying hardware drivers to handle their power >>>> management. >>>> >>>> This patch applies the following runtime pm policy to stm class devices, >>>> which their parents can rely on for their power management tracking: >>>> >>>> * device is in use during character device writes, >>>> * delayed autosuspend is used to keep it active between adjacent >>>> writes, >>>> * device is in use while mmio regions are mapped, >>>> * device is is use while any stm_source devices are linked to it. >>>> >>>> Signed-off-by: Alexander Shishkin <alexander.shish...@linux.intel.com> >>>> Cc: Mathieu Poirier <mathieu.poir...@linaro.org> >>>> Cc: Chunyan Zhang <zhang.chun...@linaro.org> >>> >>> Coresight power management on my Juno board (the only device with an >>> STM I have access to) is broken and as such, can't test if this code >>> does what is intended. But theoretically it looks good. >> >> Thanks for taking a look. >> >>> Throughout the driver, wouldn't it be better to use >>> pm_runtime_put_sync() rather than autosuspending with a hard coded >>> value? >> >> Yeah, the autosuspend is for the char write()ers that are likely to send >> multiple consequent write()s, so that we don't have to go in and out of >> suspend every time that happens. >> > > Yes, it's a trade off. Please add a comment in stm_register_device() > that explains the usage of the autosuspend functions and the choice of > '2000' value.
Will do. The 2000 is arbitrary, but it has to be configurable from a sysfs attribute and I thought that's a start as good as any. > Thanks, > > Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org> Thanks, -- Alex
