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

From: [email-masked] (Kevin Hilman)
Date: Tue, 03 Dec 2013 10:24:18 -0800

Daniel Mack <[email-masked]> 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 <[email-masked]>
>>>> Signed-off-by: Daniel Mack <[email-masked]>
>>>> Tested-by: Joel Fernandes <[email-masked]>
>>>> Acked-by: Joel Fernandes <[email-masked]>
>>>
>>> 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