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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
