[PATCH v6] ARM: omap: edma: add suspend suspend/resume hooks

Kevin Hilman khilman at linaro.org
Tue Dec 3 13:24:18 EST 2013


Daniel Mack <zonque at gmail.com> writes:

> On 11/27/2013 02:22 PM, Sekhar Nori wrote:
>> + Kevin
>> 
>> On Monday 25 November 2013 11:04 PM, Joel Fernandes wrote:
>>> On 11/17/2013 04:19 PM, Daniel Mack wrote:
>>>> This patch makes the edma driver resume correctly after suspend. Tested
>>>> on an AM33xx platform with cyclic audio streams and omap_hsmmc.
>>>>
>>>> All information can be reconstructed by already known runtime
>>>> information.
>>>>
>>>> As we now use some functions that were previously only used from __init
>>>> context, annotations had to be dropped.
>>>>
>>>> [nm at ti.com: added error handling for runtime + suspend_late/early_resume]
>>>> Signed-off-by: Nishanth Menon <nm at ti.com>
>>>> Signed-off-by: Daniel Mack <zonque at gmail.com>
>>>> Tested-by: Joel Fernandes <joelf at ti.com>
>>>> Acked-by: Joel Fernandes <joelf at ti.com>
>>>
>>> Hi Sekhar,
>>>
>>> Can you consider pulling this patch? It has been tested and Acked. Thanks.
>> 
>> Kevin had some inputs on previous version of this patch. Were you able
>> to make sure he is okay with this version being merged?
>
> I had concerns about the feedback I got, and haven't got answers yet.
>
> In particular, I'm not convinced that using runtime PM to suspend
> channels would actually save any power during runtime, or have any other
> benefit. 

/me returning from a week off

The amount of power to be saved depends on the activity in the system.
If DMA is unused, at least the clocks could be gated allowing the
possibility of the enclosing power domain to be gated if other devices
are also clock gated, etc. etc.

However, my comments were not really about power saving, they were about
designing things in a way that are scalable and match the longer term
goals of converting drivers to be runtime PM centric.  For example, if
someone did want to add real runtime PM to this driver later, they would
need to rework much of this.  So my suggestion was to do runtime PM the
right way from the beginning.

That being said, I'm not the maintainer of this driver so don't get to
make the final call.  I will just say that from what I've seen here, I
don't think this is the right approach.

Kevin



More information about the linux-arm-kernel mailing list