On Thu, Oct 7, 2010 at 10:16 PM, Omar Ramirez Luna <omar.ramirez@xxxxxx> wrote: > On 10/7/2010 1:22 PM, Felipe Contreras wrote: > ... >> >> Note that the "shared memory" described in the document you share has >> nothing to do with the SHM pool. AFAIK that memory is used for other >> things, like MMU PTEs, and storing the base image and socket-nodes, >> thus it needs to be contiguous. > > hmmm, no. it is the same memory. i.e.: we propagate the current opp through > the shared memory so the dsp can read it if it went to sleep, with the > proper offset you can read that variable starting from the mempool base > address. The document mentions "shared memory" for buffer passing, normal memory is used for that, scattered, even user-space memory, not the SHM contiguous area. >> I don't see any problem flushing the SHM area when needed, which >> probably has performance implications when mmaping/unmapping buffers, >> at which point you need to flush bigger memory areas anyway, so that's >> not an issue. > > well, you would have to flush when loading the base image, or allocating a > socket node, but also minor flushes for opp propagation, SHM messages to > DSP, chnl params, those are the ones I can quickly think of. All those happen when you send buffers to the DSP, and when you do that you need to flush the buffer memory area, which is a much heavier operation. Except maybe the opp propagation, but that would require at most one page to be flushed, not a big deal I think, besides, it would be better if that specific area is handled differently than the rest of the SHM, so that we can allocate it with dma_alloc_coherent(). Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
