problems with DSS2 at 1024x768@30

GoogleGroups
1

As a potential solution to my previous problem (scaling
1024x768@60Hz), I want to try running the display at 30Hz. I know this
won't display on a standard monitor, but we have hardware that can
double it later to 60Hz, and I figure that by running the refresh at
half-speed, I'll get twice as many clock cycles to do the scaling (by
bumping up the FCK/PCK ratio).

However, the kernel doesn't seem to like 1024x768@30, it gives an
error "Refresh rate not CVT standard" and drops back to 640x480. Does
anyone have an idea how to force it to use the rate even though it is
non-standard? I'm going to poke at the source for a bit, but hints are
appreciated.

The relevant kernel args are:
omapfb.debug=y omapdss.debug=y omapdss.def_disp=dvi omapfb.test=y
omapfb.mode=dvi:1024x768M-24@30 omapfb.vram=0:3M,1:3M,2:3M

and on bootup I see:
OMAPFB: omapfb_init
OMAPFB: omapfb_probe
fbcvt: Refresh rate not CVT standard
fbcvt: 1024x768@30: CVT Name - Not a CVT standard - 0.786 Mega Pixel Image

omapfb omapfb: cannot parse default modes
OMAPFB: create 3 framebuffers
OMAPFB: fb_infos allocated
***allocating 3 frame buffers
***alloc_fbmem_display - fbnum:0, size:3145728l, paddr:0l
***alloc_fbmem_display - fbnum:0, size:3145728l, paddr:0l
***alloc_fbmem - aligned size:3145728l
allocating 3145728 bytes for fb 0
OMAPFB: allocated VRAM paddr 80488000, vaddr c8c00000
***alloc_fbmem_display - fbnum:1, size:3145728l, paddr:0l
***alloc_fbmem_display - fbnum:1, size:3145728l, paddr:0l
***alloc_fbmem - aligned size:3145728l
allocating 3145728 bytes for fb 1
OMAPFB: allocated VRAM paddr 80788000, vaddr c9000000
***alloc_fbmem_display - fbnum:2, size:3145728l, paddr:0l
***alloc_fbmem_display - fbnum:2, size:3145728l, paddr:0l
***alloc_fbmem - aligned size:3145728l
allocating 3145728 bytes for fb 2
OMAPFB: allocated VRAM paddr 80a88000, vaddr c9400000
OMAPFB: region0 phys 80488000 virt c8c00000 size=3145728
OMAPFB: region1 phys 80788000 virt c9000000 size=3145728
OMAPFB: region2 phys 80a88000 virt c9400000 size=3145728
OMAPFB: fbmems allocated
OMAPFB: check_fb_var 0
OMAPFB: max frame size 3145728, line size 2560
OMAPFB: xres = 640, yres = 480, vxres = 640, vyres = 480
OMAPFB: set_fb_fix
OMAPFB: check_fb_var 1
OMAPFB: max frame size 3145728, line size 2560
OMAPFB: xres = 640, yres = 480, vxres = 640, vyres = 480
OMAPFB: set_fb_fix
OMAPFB: check_fb_var 2
OMAPFB: max frame size 3145728, line size 2560
OMAPFB: xres = 640, yres = 480, vxres = 640, vyres = 480
OMAPFB: set_fb_fix
OMAPFB: fb_infos initialized

Brett

2

Hi ! I do run 1024x768 with this kernel options :
omap-dss.def_disp=dvi omapfb.video_mode=1024x768MR-24@60
omapfb.vram=2M,4M,4M omapfb.debug=y'

I also manage to display (but very instable with many DISCP errors)
1280x1024.

Selso.

3

As a potential solution to my previous problem (scaling
1024x768@60Hz), I want to try running the display at 30Hz. I know this
won't display on a standard monitor, but we have hardware that can
double it later to 60Hz, and I figure that by running the refresh at
half-speed, I'll get twice as many clock cycles to do the scaling (by
bumping up the FCK/PCK ratio).

However, the kernel doesn't seem to like 1024x768@30, it gives an
error "Refresh rate not CVT standard" and drops back to 640x480. Does
anyone have an idea how to force it to use the rate even though it is
non-standard? I'm going to poke at the source for a bit, but hints are
appreciated.

The relevant kernel args are:
omapfb.debug=y omapdss.debug=y omapdss.def_disp=dvi omapfb.test=y
omapfb.mode=dvi:1024x768M-24@30 omapfb.vram=0:3M,1:3M,2:3M

Use "1024x768MR-24@30" (note the R). Current OMAPs (earlier than ES3.1
or perhaps ES3.0) cannot display non-reduced timings.

Tomi

4

That works, thanks. I had tried it previously with "MR" but didn't
think it was accepted because I got these messages:
OMAPFB: omapfb_init
OMAPFB: omapfb_probe
fbcvt: Refresh rate not CVT standard
fbcvt: 60Hz refresh rate advised for reduced blanking
fbcvt: 1024x768@30: CVT Name - Not a CVT standard - 0.786 Mega Pixel Image

but I guess those are only warnings, not errors.

Brett

5

Brett Kuehner wrote:

6

How fast is the ISP resizer? Using it will also double the used memory bandwidth, doesn't it?

  Tomi

7

Tomi Valkeinen wrote:

Brett Kuehner wrote:

As a potential solution to my previous problem (scaling
1024x768@60Hz), I want to try running the display at 30Hz. I know this
won't display on a standard monitor, but we have hardware that can
double it later to 60Hz, and I figure that by running the refresh at
half-speed, I'll get twice as many clock cycles to do the scaling (by
bumping up the FCK/PCK ratio).

what you could also do is to use the resizer in the ISP block to do your resizing,
then just use the DSS to display without scaling.

The ISP resizer has no problem to downscale 1024x768 by 1/2.

How fast is the ISP resizer? Using it will also double the used memory bandwidth, doesn't it?

Yes and No. If you assume that the frame is already in memory, it will increase it,
but if the frame is captured via the ISP, then resizing it during capture and storing only
the scaled image will keep the mem BW the same compared to DSS scaling.

About the resizer speed, it does e.g. 720x576 to 640x480 in 5 ms (memory to memory)

8

Do you know of a driver available for the ISP that has access to the
resizer? I see mention of a driver here:
http://lwn.net/Articles/321692/
but it specifically says the resizer is not part of it.

Brett

9

The kernel in OE has a patch to enable the resizer, but I haven't heard of anyone actually using it.

regards,

Koen

10

Koen Kooi wrote:

Do you know of a driver available for the ISP that has access to the
resizer? I see mention of a driver here:
OMAP3 ISP and camera drivers [LWN.net]
but it specifically says the resizer is not part of it.

The kernel in OE has a patch to enable the resizer, but I haven't heard of anyone actually using it.

There is also a working driver in the Archos released OMAP3 kernel.

11

Can you tell me where to find this kernel? I did some googling but didn't turn up any source.

Brett

12

Brett Kuehner wrote: