From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Archit Taneja <archit@ti.com>
Cc: Peter Meerwald <pmeerw@pmeerw.net>, linux-omap@vger.kernel.org
Subject: Re: downscaling YUV fails
Date: Wed, 19 Dec 2012 14:37:33 +0200 [thread overview]
Message-ID: <50D1B50D.3080909@ti.com> (raw)
In-Reply-To: <50D1B0D1.6010703@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
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.
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
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
next prev parent reply other threads:[~2012-12-19 12:37 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 [this message]
2012-12-19 13:00 ` Archit Taneja
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=50D1B50D.3080909@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=archit@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
/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.