On Mon, Jul 06, 2009 at 06:10:25PM -0700, Troy Kisky wrote:
Mark Brown wrote:
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 everything will be able to gate the clocks, too.
What is TDM? time division multiplexing? You mean the frame carries more than just audio data? I think I'm misunderstanding something. Can you elaborate please.
Yes, time division multiplexing. The extra signals could be non-audio or they could be audio. For example, you could have the CPU, CODEC and a bluetooth chip connected to a single bus. In such a scenario you could have audio going directly between bluetooth and the CODEC with no CPU involvement (allowing the CPU to suspend itself during a call).
That's not the only case - sometimes people do other things that need the clocks running even when audio is off like sharing them with some unrelated functionality.
Is it perhaps saner to just look at the current position as being the position of the transfer to SRAM? This does mean more variation from the point at which data is audibly playing but on the other hand as far
Hmm. Good point. I just wanted as accurate lip-sync as possible.
Yeah, it's tricky to know what's best.
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 SDRAM buffer to use for the SRAM. But I'd rather another patch after this
Incremental patches sounds fine to me.
if I need to use plaform data. Maybe audio_sram_buffer_size = 0 in platform data to mean use SDRAM?
The only potential problem I see there is that that'd make disabling the SDRAM the default. I guess if people have been living without it so far that's not a big problem, though, and it'll stop people getting surprised by audio grabbing SDRAM when they weren't expecting it.
I guess if you're using SDRAM there's no need for the double buffering (though that could be a third patch)?