Daniel Mack <zonque@xxxxxxxxx> 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@xxxxxx: added error handling for runtime + suspend_late/early_resume] >>>> Signed-off-by: Nishanth Menon <nm@xxxxxx> >>>> Signed-off-by: Daniel Mack <zonque@xxxxxxxxx> >>>> Tested-by: Joel Fernandes <joelf@xxxxxx> >>>> Acked-by: Joel Fernandes <joelf@xxxxxx> >>> >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
