Re: [alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram

2009-07-06 Thread Troy Kisky
Mark Brown wrote: > On Sat, Jul 04, 2009 at 07:30:01PM -0700, Troy Kisky wrote: > If you mean that it should start and > stop the clocks Yes. > that causes issues in situations like TDM since there > can be transfers going on independantly of the CPU which may need the > clocks running. Not every

Re: [alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram

2009-07-07 Thread Troy Kisky
Mark Brown wrote: >>> battery life by setting up very big DMAs. On a similar vein is it worth >>> considering making this feature entirely optional and/or falling back to >>> non-SRAM if SRAM allocation fails? > >> Yes Chris Ring also asked for that, and it is fairly easy to allocate another >> S

Re: [alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram

2009-07-07 Thread Troy Kisky
Troy Kisky wrote: > Mark Brown wrote: > > Even when using SDRAM, there is still another advantage to double buffering. > That is tolerating very long interrupt latency on dma completion. The current > code sets up the next periods dma transfer on dma completion. This could > easily > lead to unde

Re: [alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram

2009-07-07 Thread Troy Kisky
Troy Kisky wrote: > Troy Kisky wrote: >> Mark Brown wrote: >> >> Even when using SDRAM, there is still another advantage to double buffering. >> That is tolerating very long interrupt latency on dma completion. The current >> code sets up the next periods dma transfer on dma completion. This could