Re: [QUEUED v20160630 1/4] stm class: Add runtime power management handling

[Alexander Shishkin <alexander.shishkin@linux.intel.com>]

Mathieu Poirier <mathieu.poirier@linaro.org> writes:

> On 30 June 2016 at 09:30, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
>> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>>
>>> On 30 June 2016 at 06:56, Alexander Shishkin
>>> <alexander.shishkin@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.shishkin@linux.intel.com>
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Chunyan Zhang <zhang.chunyan@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.poirier@linaro.org>

Thanks,
--
Alex