From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Peter Meerwald <pmeerw@pmeerw.net>
Cc: Archit Taneja <archit@ti.com>, linux-omap@vger.kernel.org
Subject: Re: downscaling YUV fails
Date: Wed, 19 Dec 2012 13:19:24 +0200 [thread overview]
Message-ID: <50D1A2BC.4040605@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.01.1212191132250.16226@pmeerw.net>
[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]
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.
Even more interesting, with my tests I first setup the ovl with a test
picture, and see the issue (with RGB mode also). If I then use fbset to
first set the mode to YUV and then back to RGB, predecimation is not
used and the issue is not visible...
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
next prev parent reply other threads:[~2012-12-19 11:19 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 [this message]
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
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=50D1A2BC.4040605@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.