[RFC] dmaengine: omap-dma: Allow DMA controller to prefetch data

[Mark A. Greer]

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.