DSS2 scaling questions

GoogleGroups
1

As I mentioned in my previous email, I've had some success with
getting scaling going. However, I have been unsuccessful with any
vertical scaling. Any time I try to change the vertical scaling, I end
up with errors and the display is shutdown. I suspect it has something
to do with the FCK/PCK settings, but that's just a guess, and playing
around with them don't produce any better results.
My config is:
Tomi's 2.6.29 DSS2 kernel ( from
http://www.bat.org/~tomba/git/linux-omap-dss.git )
OMAP2_DSS_VRAM_SIZE=12
OMAP2_DSS_DSI=n
OMAP2_DSS_MIN_FCK_PER_PCK=0
OMAP2_DSS_DEBUG_SUPPORT=y
FB_OMAP2_NUM_FBS=3
FB_OMAP2_DEBUG_SUPPORT=y

applicable boot args:
debug omapfb.debug=y omapdss.debug=y omapdss.def_disp=dvi
omapfb.test=y omapfb.mode=dvi:1024x768MR-24@60
omapfb.vram=0:3M,1:3M,2:3M

With the default fb/overlay setup, I can do this:
echo "512,768" > $ovl1/output_size
and get the fb1 graphics scaled properly horizontally. But if I try
the equivalent vertical scaling:
echo "1024,384" > $ovl1/output_size
I get this:
omapdss OVERLAY: check_overlay 1: (256,0 1024x768 -> 1024x384) disp (1024x768)
omapdss OVERLAY: check_overlay failed 1: 1024 < 256 + 1024

and if I try:
echo "512,384" > $ovl1/output_size

I get:
omapdss OVERLAY: check_overlay 1: (256,0 1024x768 -> 512x384) disp (1024x768)
omapdss MANAGER: omap_dss_mgr_apply(lcd)
omapdss OVERLAY: check_overlay 0: (0,0 1024x768 -> 1024x768) disp (1024x768)
omapdss DISPC: dispc_setup_plane 0, ch 0, pa 80488000, sw 1024, 0,0,
1024x768 -> 1024x768, ilace 0, cmode 80, rot 0, mir 0
omapdss DISPC: calc_rot(0): scrw 1024, 1024x768
omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
omapdss DISPC: 0,0 1024x768 -> 1024x768
omapdss DISPC: dispc_enable_plane 0, 1
omapdss OVERLAY: check_overlay 1: (256,0 1024x768 -> 512x384) disp (1024x768)
omapdss DISPC: dispc_setup_plane 1, ch 0, pa 80788000, sw 1024, 256,0,
1024x768 -> 512x384, ilace 0, cmode 80, rot 0, mir 0
omapdss DISPC: calc_rot(0): scrw 1024, 1024x768
omapdss DISPC: offset0 0, offset1 0, row_inc 1, pix_inc 1
omapdss DISPC: 256,0 1024x768 -> 512x384

omapdss DISPC: dispc_enable_plane 1, 1
omapdss DISPC: dispc_enable_plane 2, 0
omapdss DISPC: FIFO merge disabled
omapdss DISPC: fifo(0) size 1024, low/high old 960/1023, new 960/1023
omapdss DISPC: fifo(1) size 1024, low/high old 960/1023, new 960/1023
omapdss DISPC: GO LCD
DISPC IRQ: 0x48a3: SYNC_LOST
omapdss DISPC error: dispc irq error status 48a3
omapdss DISPC error: Excessive DISPC errors
Turning off lcd and digit
DISPC IRQ: 0x4000: SYNC_LOST
omapdss DISPC error: dispc irq error status 4000
omapdss DISPC error: Excessive DISPC errors
Turning off lcd and digit

Has anyone gotten vertical scaling to work?

Brett

2

Hi,

Executive summary: You probably can't use OMAP DISPC scaling with normal
DVI resolutions very reliably.

As I mentioned in my previous email, I've had some success with
getting scaling going. However, I have been unsuccessful with any
vertical scaling. Any time I try to change the vertical scaling, I end
up with errors and the display is shutdown. I suspect it has something
to do with the FCK/PCK settings, but that's just a guess, and playing
around with them don't produce any better results.

Scaling with OMAP DISPC is quite a heavy operation, especially
downscaling.

Without scaling the DSS FCK (functional clock for DSS) ratio to PCK (pixel
clock) can 2/1 (ie. FCK is two times PCK), which is the smallest ratio
possible. As maximum FCK is 173MHz (if I recall right), it gives maximum
PCK of 86.5MHz when the ratio is 2/1.

Now, with scaling, the ratio usually needs to be bigger. The needed ratio
depends on the scaling factor, but unfortunately there's no way to
accurately calculate it, so you just have to test and see if it works.
OMAP TRM lists some ratios for some scaling factors and resolutions, and I
think they go from 4/1 to 8/1, or was it even 16/1.

This means that if the required ratio is 8/1, the maximum possible PCK
drops to ~21MHz, which is not enough for any higher resolution mode.

This ratio can be set with the MIN_FCK_PER_PCK config setting, so for 8/1
you set it to 8. But for that to work you'll have to have a low resolution
mode. If I remember right, if your FCK/PCK ratio is too high the driver
will just drop the ratio requirement to get a working PCK, and thus the
setting will have no effect. (although I think it'll say something about
it in the debug prints).

My config is:
Tomi's 2.6.29 DSS2 kernel ( from
http://www.bat.org/~tomba/git/linux-omap-dss.git )
OMAP2_DSS_VRAM_SIZE=12
OMAP2_DSS_DSI=n
OMAP2_DSS_MIN_FCK_PER_PCK=0
OMAP2_DSS_DEBUG_SUPPORT=y
FB_OMAP2_NUM_FBS=3
FB_OMAP2_DEBUG_SUPPORT=y

applicable boot args:
debug omapfb.debug=y omapdss.debug=y omapdss.def_disp=dvi
omapfb.test=y omapfb.mode=dvi:1024x768MR-24@60
omapfb.vram=0:3M,1:3M,2:3M

With the default fb/overlay setup, I can do this:
echo "512,768" > $ovl1/output_size
and get the fb1 graphics scaled properly horizontally. But if I try
the equivalent vertical scaling:
echo "1024,384" > $ovl1/output_size
I get this:
omapdss OVERLAY: check_overlay 1: (256,0 1024x768 -> 1024x384) disp (1024x768)
omapdss OVERLAY: check_overlay failed 1: 1024 < 256 + 1024

Have you set overlay x position to 256 previously? The check seems to
fail, as overlay width is 1024 and xpos is 256, which would make the
overlay go out of the screen (which is 1024 wide).

If you want to experiment with scaling, I suggest to try it with small
overlays, say, 100x100. There are also hard limits to scaling factor, from
1/8 of the original to 8 times the original. But I think there's some code
missing still, and the working limits are from 1/4 to 4, or 1/2 to 2.

  Tomi

3

Executive summary: You probably can't use OMAP DISPC scaling with normal
DVI resolutions very reliably.

Thank you for the very quick response (although the answer wasn't what
I was hoping to hear, but that's not your fault :slight_smile:

Also, thanks for the detailed technical explanation. I was sort of
empirically finding that that FCK/PCK ratio was important and couldn't
be cranked any higher. As you say, if you try to make it too high for
your current resolution, on bootup you get:
omapdss DISPC error: Requested pixel clock not possible with the
current OMAP2_DSS_MIN_FCK_PER_PCK setting. Turning the constraint off.

I get this:
omapdss OVERLAY: check_overlay 1: (256,0 1024x768 -> 1024x384) disp (1024x768)
omapdss OVERLAY: check_overlay failed 1: 1024 < 256 + 1024

Have you set overlay x position to 256 previously? The check seems to
fail, as overlay width is 1024 and xpos is 256, which would make the
overlay go out of the screen (which is 1024 wide).

Yes, my mistake, sorry. When I reset the position to 0,0 I get the
clock errors as in the other case.

If you want to experiment with scaling, I suggest to try it with small
overlays, say, 100x100. There are also hard limits to scaling factor, from
1/8 of the original to 8 times the original. But I think there's some code
missing still, and the working limits are from 1/4 to 4, or 1/2 to 2.

OK, I'll give it a try. I'll still have to figure out some way to do
scaling of 1024x768 input video, but maybe we can use the FPGA on our
board to help it in some way. Do you have any other OMAP-based
suggestions beyond DISPC for scaling? We have a goal of pulling in two
1024x768 VGA signals (via A to D converters and an FPGA) and
merging/scaling them into an output 1024x768 VGA signal. I wonder if
the NEON stuff or PowerVR bits could be of use here... I guess it is
time for me to go read some more.

Thanks again.

Brett

4

There's a resizer in the ISP block. The angstrom kernel has an (untested) patch for it. The omap3evm beta PSP kernel recipe has some more patches (about 200).

regards,

Koen

5

Thanks, I'll take a look.
I'm also going to try splitting the 1024x768 region into two pieces (512x768 in size) and having each one on a separate framebuffer and overlay, to see if a half-size chunk can be resized quickly enough (assuming the scaler units operate in parallel).

One more question. After poking around in the kernel, I still can't tell for sure if the DSS pieces are affected by the ARM core clock speed. Is it possible that bumping the speed from 500MHz to 600MHz will speed up the scalers also, or are they on their own clock?

Brett

6

Brett Kuehner wrote:

Do you have any other OMAP-based

suggestions beyond DISPC for scaling? We have a goal of pulling in two
1024x768 VGA signals (via A to D converters and an FPGA) and
merging/scaling them into an output 1024x768 VGA signal.

There's a resizer in the ISP block. The angstrom kernel has an
(untested) patch for it. The omap3evm beta PSP kernel recipe has some
more patches (about 200).

Thanks, I'll take a look.
I'm also going to try splitting the 1024x768 region into two pieces (512x768 in size) and having each one on a separate framebuffer and overlay, to see if a half-size chunk can be resized quickly enough (assuming the scaler units operate in parallel).

could you post again what exact input and output sizes you are trying to scale? source size and crop and destination size?

One more question. After poking around in the kernel, I still can't tell for sure if the DSS pieces are affected by the ARM core clock speed. Is it possible that bumping the speed from 500MHz to 600MHz will speed up the scalers also, or are they on their own clock?

no, they have their own clock, max is the mentioned 173MHz

7

Brett Kuehner wrote:
> I'm also going to try splitting the 1024x768 region into two pieces
> (512x768 in size) and having each one on a separate framebuffer and
> overlay, to see if a half-size chunk can be resized quickly enough
> (assuming the scaler units operate in parallel).

could you post again what exact input and output sizes you are trying to
scale? source size and crop and destination size?

Source size is 1024x768, as is the final combined output size. We have two inputs- one will not be scaled (the bottom plane) and one will be scaled to a size between 50% to 100% (so between 512x384 to 1024x768) and placed on top of the bottom plane, possibly with an offset. Sort of a "Picture in Picture" effect with the second input appearing as a smaller box on top of the first input.

> One more question. After poking around in the kernel, I still can't
> tell for sure if the DSS pieces are affected by the ARM core clock
> speed. Is it possible that bumping the speed from 500MHz to 600MHz
> will speed up the scalers also, or are they on their own clock?

no, they have their own clock, max is the mentioned 173MHz

Thanks for the confirmation.

Brett