On Wednesday 19 December 2012 06:07 PM, Tomi Valkeinen wrote:
On 2012-12-19 14:19, Archit Taneja wrote:
The image I get is stable, and clearly something that happens when, say,
row_inc is one pixel too much, or similar.
Ok, about the width in this case. The original width is 400, and what we
finally want is 220. After pre-decimation, the width would become 200,
and we would need our scalar to actually upscale to 220.
I am wondering if the driver gets confused when such a scenario occurs,
or the DSS HW is weird when we upscale some predecimated content. If you
look at the hinc(1024 * width/out_width) value in the FIR register, in
the "ok" regdumps, the value is 1861, which points to downscaling. And
in the fail case, it's 92, which is upscaling.
I can reproduce this with a very simple case. 400x200 -> 200x200, and
forcing horizontal predecimation. So this will cause no scaling to be
used, only the pixel_inc is used to downscale.
Ah okay. My guess was wrong then :)
The VID1 registers are as follows. They look right to me...
DISPC_OVL_BA0(VID1) 8d900000
DISPC_OVL_BA1(VID1) 8d900000
DISPC_OVL_POSITION(VID1) 00000000
DISPC_OVL_SIZE(VID1) 00c700c7
DISPC_OVL_ATTRIBUTES(VID1) 00608011
DISPC_OVL_FIFO_THRESHOLD(VID1) 03ff03c0
DISPC_OVL_FIFO_SIZE_STATUS(VID1) 00000400
DISPC_OVL_ROW_INC(VID1) 00000001
DISPC_OVL_PIXEL_INC(VID1) 00000005
DISPC_OVL_PRELOAD(VID1) 00000100
DISPC_OVL_FIR(VID1) 04000400
DISPC_OVL_PICTURE_SIZE(VID1) 00c700c7
DISPC_OVL_ACCU0(VID1) 00000000
DISPC_OVL_ACCU1(VID1) 00000000
DISPC_OVL_PRELOAD(VID1) 00000100
The only thing which seems not so nice is that vertical taps and vid
line buffer split are enabled in OVL_ATTRIBUTES. These shouldn't be
harmful though.
Archit
--
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
