On Tuesday 27 January 2009, Griffis, Brad wrote: > > > I think someone forgot an 'I' in edma_stop. Writing to ECR seems > > > pointless to me. I am assuming they meant to do SH_IECR instead of > > > SH_ECR. This also happens to fix the problem I was having with audio > > > stalls on dm6446. > > > > ECR == Event Clear Register, scrubbing out pending events > > IECR == Interrupt Enable Clear Register, disabling completion IRQs > > > > Wouldn't it make sense to clear *both*? > > Possibly, but there are some other considerations if you clear both. > Namely once you re-enable the EDMA you would need the peripherals > to generate new EDMA events.
Which is what I'd expect in any case. If there's any part of the transfer still pending, it's hardly a "stop" ... and the driver requesting the stop() will necessarily get confused. > For example, with the ASP/McBSP you > would need to turn it off and then back on. If you leave the event > pending then you would not need to restart ASP/McBSP. Being able to resume a transfer like that is the edma_pause() model. A stop() should be a full stop, IMO... > Personally > I think it's easier/cleaner to just let the event pend. That'd be a pause() not a stop(). I think it's clear that the current ASoC driver is confused there, since it implements SUSPEND and PAUSE_PUSH as stop(), not just the STOP operation. > Otherwise > the EDMA driver code has to interact with peripherals too. You have that backwards ... the peripheral driver uses EDMA as a tool, and the EDMA code just does what it's told. When the peripheral driver wants "transfer can continue" semantics, it should edma_pause() instead of edma_stop(). - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
