OMAPVideo (changes)

Showing changes from revision #13 to #14: Added | Removed | Changed

OMAPVideo

Introduction

The OMAPVideo module, located at bsd/RiscOS/Sources/Video/HWSupport/OMAPVideo in CVS, is a driver for the display subsystem of the OMAP 3 and 4 range of SoC’s. It uses the GraphicsV API to expose the hardware’s functionality to RISC OS, thus allowing RISC OS to use the hardware as a display device. The driver is far from complete, but implements most of the functionality supported by the current GraphicsV spec.

Current functionality & limitations

• Supports all current GraphicsV reason codes, except:
  • Only limited support for accelerated rectangle copy/fill operations – sources/destinations must be at least byte aligned, and only solid fills with limited ECF patterns are supported.
  • GraphicsV_SetInterlace and GraphicsV_SelectHead currently aren’t isn’t supported
• Has limited support for running on devices with fixed, ‘dumb’ LCD panels
• The driver has basic support for TV-out. Except for on Pandora and OMAP4, if a TV is detected on machine startup then the TV will be used as the main display instead of the DVI output.
• VIDC-style hardware scrolling isn’t supported, due to restrictions in the display hardware. In some situations it could be emulated via the use of extra overlays, but this probably isn’t worth the hassle, especially since RISC OS will fall back to the hardware-accelerated rectangle copies if full hardware scrolling isn’t available.

Known issues

• 16bpp modes rely on using the gamma table to map from RISC OS’s 5:5:5 16bpp pixel format to the OMAP’s 5:6:5 format. However this results in a mode with only 4 blue bits instead of 5, so a proper solution (i.e. implementing the Extended Framebuffer Format Specification) is stil desireable.
• In the old HAL-based driver, the DSI PLL would fail to lock if RISC OS was not loaded by U-Boot. No checks have been made to determine whether this problem also exists with the new driver.
• Mouse pointer updates lag behind the rest of the screen by 1 frame. This is because the display controller updates its internal registers from the shadow registers at the start of the vsync period, during which time RISC OS is probably only just entering the interrupt handler and calling the pointer update code. A better approach may be to program the controller to generate an interrupt a few scanlines before vsync is due, and use that as RISC OS’s vsync interrupt. With the right timing this will also allow programs that use double buffering & vsync-timed buffer flips to operate as expected.
• The driver may malfunction if given bad mode timings (e.g. requesting a pixel rate of 3.6kHz resulted in a division by zero error!)
• TV-out will be R/B swapped in 16 & 24bpp modes. The only way to fix this is to add support for extra pixel formats to RISC OS (e.g. the Extended Framebuffer Format Specification)

Future improvements

Most major improvements (YUV overlays, display scaling & rotation, etc.) will come as a result of finalising and implementing the Proposed GraphicsV enhancements. Other potential improvements, not dependent on the GraphicsV improvements, are as follows:

• Improved hardware acceleration
  • Optimising the code and/or converting to assembler may result in worthwhile gains for small render operations
  • Right-to-left rectangle copy operations, which are quite slow, may be sped up by splitting the copy rectangle into non-overlapping vertical strips, or making use of the new DMA list functionality in the AM/DM37x DMA controller.
• Implement the missing GraphicsV reason codes

As part of the development of the driver and the extensions to GraphicsV, some other parts of RISC OS are likely to see improvement as well (e.g. improving MakeModes and the display manager)

Debugging

A debug version of the module can be built by adding -options DEBUG=TRUE to the OMAPVideo line in the components file (BuildSys.Components.ROOL.OMAP3). At the moment the default method for debug output is to use HAL_DebugTX to output it all via the serial port – so unless you change it to something else you’ll need a serial cable connected to another machine to capture the output.

Once the debug option is enabled, an ordinary ROM recompile (Make ROM, Install ROM, Join ROM) is all that’s needed to produce the new ROM image.

Debug commands

The following * commands are available in debug builds of the module:

• VideoRegs – produces a dump of the main hardware registers
• TVMode <mode> <type> <testcard> – for playing with TV-out.
  • <mode> should be 0 for NTSC, or 1 for PAL.
  • <type> should be 0 for Composite, 1 for S-Video, or -1 to disable the output (Note that most boards only support S-Video)
  • <testcard> should be 1 to display the video encoder’s built in colour bars image, or 0 to display the graphics/video overlays.
• TVRegs – produces a dump of the VENC registers
• TVOut <mode> – 0 switches the desktop to DVI output, 1 to TV. You’ll need to change screen mode after issuing the command for it to have an effect.
• SDMARegs – produces a dump of the SDMA registers used for GraphicsV_Render acceleration

MDF entries

This list of MDF entries is primarily intended for users of ‘old’ OMAPs (revision 3 and below), which had rather tight restrictions on the range of values supported by the porch & sync timing registers. The restrictions meant that they were typically unable to recreate the standard VESA mode timings and instead had to rely on ‘reduced blanking’ modes (such as those listed below). Newer OMAPs (revision 3.1 and above) have less restrictive timing registers, and so are likely to work with standard MDFs – however owners of new OMAPs may still find use for some of the modes listed here (e.g. 1280×1024). Note that the OMAPVideo driver currently gives little indication to the user of what OMAP revision is in use, so some trial and error may be required!

Some other notes:

• Some of the standard modes listed below (e.g. 1280×720) exhibit timing issues on the beagleboard, where the screen is shifted down one scanline with the bottom scanline replicated at the top of the screen. I’ve seen this on two monitors and in both RISC OS and Linux, so I’m fairly certain it’s a hardware bug (JL)
• The 1920×1080 modes aren’t likely to work on many monitors due to their 30Hz (or lower) refresh rate.

file_format:1
monitor_title:Beagleboard modes
DPMS_state:3

# 640 x 256 (70Hz)
startmode
mode_name:
x_res:640
y_res:256
pixel_rate:25175
h_timings:92,24,22,640,22,0
v_timings:2,106,0,256,0,85
sync_pol:2
endmode

# 640x480@60Hz reduced blanking VESA CVT 0.31M3-R
startmode
mode_name:640 x 480
x_res:640
y_res:480
pixel_rate:23500
h_timings:32,80,0,640,0,48
v_timings:4,7,0,480,0,3
sync_pol:3
endmode

# 640 x 512 (55Hz)
startmode
mode_name:
x_res:640
y_res:512
pixel_rate:32000
h_timings:76,88,96,640,96,28
v_timings:3,19,16,512,16,2
sync_pol:0
endmode

# 800x600@60Hz reduced blanking VESA CVT 0.48M3-R
startmode
mode_name:800 x 600
x_res:800
y_res:600
pixel_rate:35500
h_timings:32,80,0,800,0,48
v_timings:4,11,0,600,0,3
sync_pol:3
endmode

# 1024x768@60Hz reduced blanking VESA CVT 0.79M3-R
startmode
mode_name:1024 x 768
x_res:1024
y_res:768
pixel_rate:56000
h_timings:32,80,0,1024,0,48
v_timings:4,15,0,768,0,3
sync_pol:3
endmode

# 1280x720@60Hz reduced blanking VESA CVT 0.79M3-R
startmode
mode_name:1280 x 720
x_res:1280
y_res:720
pixel_rate:64000
h_timings:32,80,0,1280,0,48
v_timings:5,13,0,720,0,3
sync_pol:3
endmode

# 720x480@60Hz CEA-861 Format 3
startmode
mode_name:720 x 480
x_res:720
y_res:480
pixel_rate:27027
h_timings:62,60,0,720,0,16
v_timings:6,30,0,480,0,9
sync_pol:3
endmode

# 720x576@60Hz CEA-861 Format 18
startmode
mode_name:720 x 576
x_res:720
y_res:576
pixel_rate:27000
h_timings:64,68,0,720,0,12
v_timings:5,39,0,576,0,5
sync_pol:3
endmode

# 1280x720@50Hz CEA-861B Format 19
startmode
mode_name:1280 x 720
x_res:1280
y_res:720
pixel_rate:74250
h_timings:40,220,0,1280,0,440
v_timings:5,5,0,720,0,20
sync_pol:3
endmode

# 1280x720@60Hz CEA-861B Format 4
startmode
mode_name:1280 x 720
x_res:1280
y_res:720
pixel_rate:74250
h_timings:40,220,0,1280,0,110
v_timings:5,5,0,720,0,20
sync_pol:3
endmode

# 1920x1080@24Hz CEA-861B Format 32
startmode
mode_name:1920 x 1080
x_res:1920
y_res:1080
pixel_rate:74250
h_timings:44,638,0,1920,0,148
v_timings:5,4,0,1080,0,36
sync_pol:3
endmode

# 1920x1080@25Hz CEA-861B Format 33
startmode
mode_name:1920 x 1080
x_res:1920
y_res:1080
pixel_rate:74250
h_timings:44,528,0,1920,0,148
v_timings:5,4,0,1080,0,36
sync_pol:3
endmode

# 1920x1080@30Hz CEA-861B Format 34
startmode
mode_name:1920 x 1080
x_res:1920
y_res:1080
pixel_rate:74250
h_timings:44,88,0,1920,0,148
v_timings:5,4,0,1080,0,36
sync_pol:3
endmode

# 1280x1024@57Hz
startmode
mode_name:1280 x 1024
x_res:1280
y_res:1024
pixel_rate:86000
h_timings:32,80,0,1280,0,48
v_timings:5,13,0,1024,0,3
sync_pol:3
endmode

# 1600x1000@45Hz
startmode
mode_name:1600 x 1000
x_res:1600
y_res:1000
pixel_rate:86000
h_timings:32,108,14,1600,0,98
v_timings:5,16,0,1000,0,0
sync_pol:3
endmode

# 1024 x 600 (98Hz)
startmode
mode_name:TouchBook
x_res:1024
y_res:600
pixel_rate:64000
h_timings:3,39,0,1024,0,3
v_timings:1,7,0,600,0,2
sync_pol:3
endmode