Re: downscaling YUV fails

[Archit Taneja <archit@ti.com>]

On Wednesday 19 December 2012 05:29 PM, Tomi Valkeinen wrote:
> On 2012-12-19 13:52, Archit Taneja wrote:
>> On Wednesday 19 December 2012 04:51 PM, Tomi Valkeinen wrote:
>>> On 2012-12-19 13:19, Tomi Valkeinen wrote:
>>>> On 2012-12-19 12:51, Peter Meerwald wrote:
>>>>> Hello,
>>>>>
>>>>>> In the case we set it to 4, the DISPC_FCLK is fast enough to do the
>>>>>> required
>>>>>> downscaling, but in the case when it's set to 0, it might need to
>>>>>> pre decimate
>>>>>> rather than try to scale.
>>>>>
>>>>> this is my understanding as well
>>>>>
>>>>>>> I think there is a bug downscaling YUV data when resorting to
>>>>>>> pre-decimation; setting CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK is a
>>>>>>> workaround
>>>>>>> -- any ideas how this can be fixed?
>>>>>
>>>>>> Pre-decimation should work for YUV formats also. Could you share
>>>>>> DISPC reg
>>>>>> dumps when this happens:
>>>>>>
>>>>>> mount -t debugfs debugfs /sys/kernel/debug
>>>>>> cat /sys/kernel/debug/omapdss/dispc
>>>>>
>>>>> please find the files http://pmeerw.net/ok.dispc (with
>>>>> FCK_PER_PCK=4) and
>>>>> http://pmeerw.net/fail.dispc (FCK_PER_PCK=0)
>>>>
>>>> Something funny is going on here. I can reproduce on omap3 with a few
>>>> hacks that reduce the clocks. The PICTURE_SIZE's width field is
>>>> different for working and non-working cases, but I think it should be
>>>> the same for both.
>>>
>>> Ah, never mind. Of course the picture_size needs to be modified if
>>> predecimation is used...
>>
>> You said that you see the issue with RGB too. Did you mean the
>> picture_size, or visually also?
>
> Visually. I see skewed image for both RGB and YUV modes on omap3.
>
> It was a bit difficult to reproduce, but I first forced the clocks down,
> and then I was able to get predecimation for RGB, but not YUV. The
> reason was this:
>
> 		if (color_mode == OMAP_DSS_COLOR_RGB24U)
> 			core_clk <<= 1;
>
> So for some reason, the core_clk requirement for RGB24U is x2 than for
> others. I have _no_ idea why that is, the line has been there from the
> start...
>
> After I removed the if, so that the core_clk requirement is x2 always, I
> also got predecimation for YUV, and I see the same skew.
>
>> One thing I'm guessing is that DMA fetching with predecimation isn't
>> really optimised for omap3, if the pixel clock in Peter's setup is high,
>> the DISPC DMA might not be able to fetch pixels fast enough in
>> predecimation case. That sort of supports the possibility of a skewed
>> image seen.
>
> 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.

Archit