| Message ID | 1348553993-8083-17-git-send-email-archit@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? 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. Tomi
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-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c index ca28a88..d6f120d 100644 --- a/drivers/video/omap2/dss/dispc.c +++ b/drivers/video/omap2/dss/dispc.c @@ -993,7 +993,7 @@ void dispc_wb_set_channel_in(enum dss_writeback_channel channel) static void dispc_ovl_set_burst_size(enum omap_plane plane, enum omap_burst_size burst_size) { - static const unsigned shifts[] = { 6, 14, 14, 14, }; + static const unsigned shifts[] = { 6, 14, 14, 14, 14, }; int shift; shift = shifts[plane]; @@ -1225,6 +1225,14 @@ void dispc_ovl_compute_fifo_thresholds(enum omap_plane plane, if (manual_update && dss_has_feature(FEAT_OMAP3_DSI_FIFO_BUG)) { *fifo_low = ovl_fifo_size - burst_size * 2; *fifo_high = total_fifo_size - burst_size; + } else if (plane == OMAP_DSS_WB) { + /* + * 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 + */ + *fifo_low = 0; + *fifo_high = burst_size; } else { *fifo_low = ovl_fifo_size - burst_size; *fifo_high = total_fifo_size - buf_unit;
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. Signed-off-by: Archit Taneja <archit@ti.com> --- drivers/video/omap2/dss/dispc.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)