On Fri, Oct 19, 2012 at 12:33:35AM +0100, Russell King - ARM Linux wrote: > On Thu, Oct 18, 2012 at 04:24:05PM -0700, Mark A. Greer wrote: > > On Thu, Oct 18, 2012 at 11:55:40PM +0100, Russell King - ARM Linux wrote: > > > On Thu, Oct 18, 2012 at 03:20:46PM -0700, Mark A. Greer wrote: > > > > This patch seems fairly stable but I've only tested omap-sham (crypto) > > > > and omap_hsmmc (mmc) on an am37x EVM. I also enabled burst mode but > > > > that made the system unstable when exercising either omap-sham or > > > > omap_hsmmc. I'm unaware of any errata that would make this an unwanted > > > > modification but I haven't checked all of the SoCs. Are there other > > > > reasons that this should be applied?? > > > > > > It definitely needs checking with audio, because it will affect the > > > pointer position in relation to audio output, and it will have an > > > effect on how much audio data is lost over a pause/resume event. > > > > > > Unfortunately, the OMAP DMA hardware has no way to do a proper "pause", > > > it can only do a "stop" which involves dumping its FIFOs on the floor > > > in the case of anything but a DEV->MEM transfer. So the more data > > > held in the DMA hardware, the more is lost on pause. > > > > Hmm, interesting. > > > > Is there a way to tweak DMA params like this on a per logical channel > > basis using the dmaengine API? I don't see any but I could have missed it. > > > > If not, are you open to adding such a thing (e.g., extend 'enum dma_ctrl_flags' > > with DMA_ENABL_PREFETCH)? > > I would suggest getting some feedback from the ASoC people first, before > trying to invent new APIs to work around this stuff. If they can live > with having prefetch enabled on OMAP then there isn't an issue here. If > not, we need a solution to this. > > I do not believe that precisely stopping and starting playback across a > suspend/resume event is really necessary (it's desirable but the world > doesn't collapse if you miss a few samples.) It could be more of an > issue for pause/resume though, but as I say, that's for ASoC people to > comment on. > > I'm merely pointing out here that we need their feedback here before > deciding if there's anything further that needs to happen. Thanks, I will do that. -- 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
