From: Archit Taneja <archit@ti.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>, linux-omap@vger.kernel.org
Subject: Re: downscaling YUV fails
Date: Wed, 19 Dec 2012 18:30:21 +0530 [thread overview]
Message-ID: <50D1BA65.2090806@ti.com> (raw)
In-Reply-To: <50D1B50D.3080909@ti.com>
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
next prev parent reply other threads:[~2012-12-19 13:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 9:51 downscaling YUV fails Peter Meerwald
2012-12-19 10:16 ` Archit Taneja
2012-12-19 10:51 ` Peter Meerwald
2012-12-19 11:19 ` Tomi Valkeinen
2012-12-19 11:21 ` Tomi Valkeinen
2012-12-19 11:52 ` Archit Taneja
2012-12-19 11:59 ` Tomi Valkeinen
2012-12-19 12:19 ` Archit Taneja
2012-12-19 12:37 ` Tomi Valkeinen
2012-12-19 13:00 ` Archit Taneja [this message]
2012-12-19 13:10 ` Tomi Valkeinen
2012-12-19 12:15 ` Peter Meerwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50D1BA65.2090806@ti.com \
--to=archit@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.