Thread (59 messages) 59 messages, 3 authors, 2012-09-26

Re: [PATCH v2 16/18] OMAPDSS: DISPC: Configure writeback FIFOs

From: Archit Taneja <hidden>
Date: 2012-09-26 05:43:28
Also in: linux-omap

On Tuesday 25 September 2012 08:20 PM, Tomi Valkeinen wrote:
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
quoted
Extend the DISPC fifo functions to also configure the writeback FIFO thresholds.

The most optimal configuration for writeback is to push out data to the
interconnect the moment writeback pushes enough pixels in the FIFO to form a
burst. This reduces the chance of writeback overflowing it's FIFO.
Hmm, why is this optimal?

The FIFO for WB is the output fifo, right? In mem-to-mem mode the whole
WB pipeline can stall, so the fifo can't overflow? If so, isn't it
better to collect more data and flush all that to the memory, instead of
sending each burst-size piece one by one?
I guess this configuration is optimal for capture mode. Where the input 
side will push out data at the rate of pixel clock, and writeback has to 
collect this data and flush to memory. Writeback can't stall here.

About writeback FIFO overflowing in mem-to-mem mode, I'm not totally 
sure about this. But what you are saying seems valid, writeback would 
stall the input. So it should be safe to accumulate content in the FIFO, 
and push out large number of bursts together.
Then again, if the input side is reading pixels from the memory all the
time, even if the output fifo helps to keep the output side idle for
longer periods, it probably doesn't help as the input side keeps the
memory bus awake.
Maybe if the FIFOs are adjusted such that reading of the pixels from 
input side and writeback flushing out can be done at the same time, then 
we might idle the memory bus more. I don't know if this is possible though.

Archit
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help