• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 465 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dm365 memory map & linux

WingEdLizard
Intellectual 605 points

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,
        },
};

 

 

  • 0
    Prodigy 120 points

    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.

  • 0 in reply to Jon Povey
    Intellectual 605 points

    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

  • 0 in reply to WingEdLizard
    Prodigy 120 points

    Thanks. It looks like that may have already been fixed in 52e2c5d38ea6f13a19c29da7ba5183e6fac55400:

    http://comments.gmane.org/gmane.linux.alsa.devel/89280