On 2012-12-19 13:52, Archit Taneja wrote: > 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? Visually. I see skewed image for both RGB and YUV modes on omap3. It was a bit difficult to reproduce, but I first forced the clocks down, and then I was able to get predecimation for RGB, but not YUV. The reason was this: if (color_mode == OMAP_DSS_COLOR_RGB24U) core_clk <<= 1; So for some reason, the core_clk requirement for RGB24U is x2 than for others. I have _no_ idea why that is, the line has been there from the start... After I removed the if, so that the core_clk requirement is x2 always, I also got predecimation for YUV, and I see the same skew. > 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. The image I get is stable, and clearly something that happens when, say, row_inc is one pixel too much, or similar. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
