On Fri, Mar 16, 2012 at 3:58 AM, Ville Syrjälä <syrjala@xxxxxx> wrote:
> On Thu, Mar 15, 2012 at 05:18:28PM +0530, Chandrabhanu Mahapatra wrote:
>> In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
>> up to 2 times in OMAP2. However, with predecimation, the image can be reduced
>> to 16 times by fetching only the necessary pixels in memory. Then this
>> predecimated image can be downscaled further by the DISPC scaler.
>
> Now, where does that number 16 come from? IIRC the hardware can skip
> basically any number of pixels/rows. I certainly didn't add any such
> limit to the code in the harmattan kernel, and distinctly remember
> being able to downscale the N9/N950 UI even down to 1 pixel size :)
>
Yes, you are right. I have done vertical predecimation to a size of 2
lines beyond which it failed.
This limitation of 16 is actually on horizontal predecimation as was
mentioned by the hardware guys. Let me explain what we once discussed
with Archit.
The pipeline is configured to use a burst of size 8 * 128 bits and DSS
uses 8 L3 clock cycles to fetch it. So, burst consists of 8 mini
bursts of 16 bytes each.
Now, there are two possible situations:
1) Each mini burst has some valid pixels, so all 16 bytes are fetched
by DISPC DMA and the uneeded pixels are discarded. This case can be
shown as
pixelinc -1 + bpp =< 16
2) Some mini bursts don't have any valid pixels, so these will not be
fecthed by the DISPC DMA. So, L3 interconnect may handover the bus
over so some other initiator and inturn delay the fecthing of pixels
leading to UNDERFLOWS. This case can be shown as
pixellinc -1 + bpp > 16.
To avoid these UNDERFLOWS we better have a limitation of 16 on
horizontal predecimation. Anyways, 16 times predecimation followed by
2/4 times downscaling (may it be horizontal or vertical) by DISPC
SCALER is more than enough for any usecase required.
>> Based on the downscaling required, a prior calculation of predecimation values
>> for width and height of an image is done. Since, Predecimation reduces quality
>> of an image higher priorty is given to DISPC Scaler for downscaling.
>>
>> This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
>> vertical predecimation worked fine except for some synclost errors due to
>> undocumented errata in OMAP3 which are fixed later and skewed images were seen
>> on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
>> the future patches.
>
> All the rotation offset calculations still look suspiciously different
> to what is in the harmattan kernel. I remember that the original code
> was quite broken, and I fixed a lot of things when I was implementing
> pre-decimation and some rotation stuff for the N9/N950. Too bad I never
> managed to push that stuff upstream...
>
A number of variables are different in mainline kernel from that used
in your code. I did fix some of the rotation code to get the best
results. I will consider your suggestions for further improvement.
> --
> Ville Syrjälä
> syrjala@xxxxxx
> http://www.sci.fi/~syrjala/
--
Chandrabhanu Mahapatra
Texas Instruments India Pvt. Ltd.
--
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
