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. Thanks, Reviewed-by: Mathieu Poirier <mathieu.poir...@linaro.org> > Thanks, > -- > Alex
