On 2012-12-19 15:00, Archit Taneja wrote: > 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.
Yep, I've tested disabling five_taps also, but it doesn't have any effect. I'm at loss here =). If I force pix inc to 1, I get what I expect: an image without skew, but the height is doubled as the left and right sides are shows on two lines. Then setting pix inc to 5 causes the skew. Colors are still correct, so the byte alignment is right. Tomi
signature.asc
Description: OpenPGP digital signature
