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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 25 September 2012 08:20 PM, Tomi Valkeinen wrote:
On Tue, 2012-09-25 at 11:49 +0530, Archit Taneja wrote:
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

--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Tourism]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux