On 10/8/2010 3:18 AM, Felipe Contreras wrote:
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.
"streaming" (meaning dsp stream) buffers are passed through the SHM
(check page 9). The regular "big" buffers are passed through old DMM
(page 14) which is exactly as you describe it; but that SHM portion is
referring to stream buffers.
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().
Yes, on top of the regular buffer flush, you need to flush the specific
parts of the shared memory that the dsp is going to read, meaning: you
send a buffer to the dsp, then send the MBX interrupt, to let it know
there is a SHM message, DSP is going to read that SHM message from the
SHM memory.
You also need to invalidate if the dsp is going to write, so the next
time you read there is no mismatch in the data, meaning: DSP sends a SHM
message to slot 1, but you already read slot 1 from a previous
transaction so contents might be still in cache, so you need to
invalidate that memory and read again the new SHM message.
Now to know when to read/write you need to have 2 flags per operation,
one to know if you have new messages and other to know if you are
reading/writing any message (all in SHM), which are there right now for
this specific case; but if flushing the SHM, now you will need flags for
knowing if the first two have been already flushed... and then 2 for
these two... and so on. So in the end a better locking mechanism would
be needed for both ARM and DSP which is not based on memory which may or
may not have the latest contents (going the cacheable route).
As I have been saying, we can try this changes in the ARM tidspbridge
because we _freely_ see what is going on, but in the DSP we can't.
Regards,
Omar
--
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
