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 17:22:37 +0530 [thread overview]
Message-ID: <50D1AA85.1000207@ti.com> (raw)
In-Reply-To: <50D1A34B.8030308@ti.com>
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?
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.
Peter,
Do you see any SYNC_LOST or UNDERFLOW prints when this happens?
Archit
next prev parent reply other threads:[~2012-12-19 11:53 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 [this message]
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=50D1AA85.1000207@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).