In the SPRS457B ( dm365 dmsoc) document, it lists (on the first page) memory as
16K Instruction cache
8K data cache
32K Ram
16K ROM
Later in the document (section 2.6) , it shows a memory map with an Instruction & Data RAM blocks.
Is the Instruction 'ARM RAM0' the same memory as the Data RAM0? Do they share the same memory ( just mapped differently to separate the Data and Instruction memories)?
The later kernels have an 'Audio dma over/under run fix', related to using the Internal RAM as a bounce buffer, but I don't see anybody using the sram_alloc() system call in the kernel. After linux boots are both of these blocks used as data?
dm365.c:
static struct map_desc dm365_io_desc[] = { ... { .virtual = SRAM_VIRT, .pfn = __phys_to_pfn(0x00010000), .length = SZ_32K, /* MT_MEMORY_NONCACHED requires supersection alignment */ .type = MT_DEVICE, },};
Hi Brett,
I wonder if you're still digging into DM365 audio corruption issues, as I am doing the same thing. I'd be interested in comparing notes.
I have seen similar clicks to those you describe in other threads, and have been playing with the sram ping/pong stuff in git kernel 3.0. I only get clicks while recording raw audio through ALSA, even when not encoding, and I get no clicks when recording H.264 video + AAC audio in my own DMAI app. I do sometimes see chunks of 32 samples doubled up, though! So blocks of 32 samples, A B C sometimes records as ABBC, which screws up all the timings and lip sync.
We've told TI about this problem. It has to do with the using EDMA registers to get the current position in the ring buffer. The docs say you can't use the counters while the DMA is running. It reports too much data sometimes.
Look at how linux/sound/soc/davinci/davinci-pcm.c:davinci_pcm_pointer() uses edma_get_position() to determine the offset into the ring buffer.
If you figure out a fix, send it to TI.
wl
Thanks. It looks like that may have already been fixed in 52e2c5d38ea6f13a19c29da7ba5183e6fac55400:
http://comments.gmane.org/gmane.linux.alsa.devel/89280