On Wednesday 09 October 2013 11:33 AM, Fernandes, Joel wrote: > Some temporary issues with my mua so forgive any artifacts in this email. > > On Oct 9, 2013, at 12:14 AM, "Hebbar, Gururaja" <gururaja.heb...@ti.com> > wrote: > >> On Wednesday 09 October 2013 09:58 AM, Joel Fernandes wrote: >>> On 10/01/2013 10:04 AM, Daniel Mack wrote: >>>> This patch makes the edma driver resume correctly after suspend. Tested >>>> on an AM33xx platform with cyclic audio streams. >>>> >>>> The code was shamelessly taken from an ancient BSP tree. >>>> >>>> Signed-off-by: Daniel Mack <zon...@gmail.com> >>>> --- >>>> arch/arm/common/edma.c | 133 >>>> +++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 133 insertions(+) >> >> ..snip.. >> ..snip.. >>> >>>> + edma_cc[j]->context.ch_map = >>>> + kzalloc((sizeof(unsigned int) * >>>> + edma_cc[j]->num_channels), GFP_KERNEL); >>>> + edma_cc[j]->context.que_num = >>>> + kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL); >>> >>> Can these allocations be moved to the suspend path? For systems that don't >>> suspend/resume even once, I feel we shouldn't allocate memory that we don't >>> use. >>> These allocations are better to do there. >> >> AFAIK, Suspend/resume should be quick. Allocating and deallocating on >> every iterating would be useless and time consuming. > > Nobody said allocate and deallocate on every iteration. Allocate once during > the first suspend call and then don't have to allocate on subsequent calls.
I couldn't find any code which allocates parameters inside suspend. Could you show me some code which does this? > > As for suspend resume being quick, that argument can flipped the other way > too, booting should be quick which is far more frequent than suspend/resume. > Apart from the fact that we're not allocating useless memory we would never > use. > >> >> Also this task is one time and quick. > > Exactly. i was referring to allocating in probe call.. > >> >> Are there any systems (Linux based for now) which doesn't >> suspend/resume? I believe the probability is very less. > > Nobody talked about suspend/resume not being supported in Linux so not sure > what your argument is here. I meant linux systems which doesn't go to suspend and resume. Not suspend/resume feature. Also, I was referring to your 1st comment "... For systems that don't suspend/resume even once, ...." regards Gururaja > > regards, > > -Joel > >> >> regards >> Gururaja >> >>> >>> -Joel >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
