[Samsung Galaxy SL i9003] gaurav2912:
I think i'm on to something here

Our phone uses OMAP 3630

so after a lot of research, i found some linux kernel documentation for OMAP 2/3

I read it and I can see that our devices can have TV-OUT but need a module or kernel to be flashed to our phones.

Due to lack of knowledge in linux i can do only so much and request some of you to look in to the documentation pasted below.

Persistence pays off :)

Source: http://www.mjmwired.net/kernel/Documentation/arm/OMAP/DSS

1	OMAP2/3 Display Subsystem

2	-------------------------

3

4	This is an almost total rewrite of the OMAP FB driver in drivers/video/omap

5	(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,

6	TV-out and multiple display support, but there are lots of small improvements

7	also.

8

9	The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,

10	panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live

11	currently side by side, you can choose which one to use.

12

13	Features

14	--------

15

16	Working and tested features include:

17

18	- MIPI DPI (parallel) output

19	- MIPI DSI output in command mode

20	- MIPI DBI (RFBI) output

21	- SDI output

22	- TV output

23	- All pieces can be compiled as a module or inside kernel

24	- Use DISPC to update any of the outputs

25	- Use CPU to update RFBI or DSI output

26	- OMAP DISPC planes

27	- RGB16, RGB24 packed, RGB24 unpacked

28	- YUV2, UYVY

29	- Scaling

30	- Adjusting DSS FCK to find a good pixel clock

31	- Use DSI DPLL to create DSS FCK

32

33	Tested boards include:

34	- OMAP3 SDP board

35	- Beagle board

36	- N810

37

38	omapdss driver

39	--------------

40

41	The DSS driver does not itself have any support for Linux framebuffer, V4L or

42	such like the current ones, but it has an internal kernel API that upper level

43	drivers can use.

44

45	The DSS driver models OMAP's overlays, overlay managers and displays in a

46	flexible way to enable non-common multi-display configuration. In addition to

47	modelling the hardware overlays, omapdss supports virtual overlays and overlay

48	managers. These can be used when updating a display with CPU or system DMA.

49

50	Panel and controller drivers

51	----------------------------

52

53	The drivers implement panel or controller specific functionality and are not

54	usually visible to users except through omapfb driver. They register

55	themselves to the DSS driver.

56

57	omapfb driver

58	-------------

59

60	The omapfb driver implements arbitrary number of standard linux framebuffers.

61	These framebuffers can be routed flexibly to any overlays, thus allowing very

62	dynamic display architecture.

63

64	The driver exports some omapfb specific ioctls, which are compatible with the

65	ioctls in the old driver.

66

67	The rest of the non standard features are exported via sysfs. Whether the final

68	implementation will use sysfs, or ioctls, is still open.

69

70	V4L2 drivers

71	------------

72

73	V4L2 is being implemented in TI.

74

75	From omapdss point of view the V4L2 drivers should be similar to framebuffer

76	driver.

77

78	Architecture

79	--------------------

80

81	Some clarification what the different components do:

82

83	- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the

84	pixel data for the image. Framebuffer has width and height and color

85	depth.

86	- Overlay defines where the pixels are read from and where they go on the

87	screen. The overlay may be smaller than framebuffer, thus displaying only

88	part of the framebuffer. The position of the overlay may be changed if

89	the overlay is smaller than the display.

90	- Overlay manager combines the overlays in to one image and feeds them to

91	display.

92	- Display is the actual physical display device.

93

94	A framebuffer can be connected to multiple overlays to show the same pixel data

95	on all of the overlays. Note that in this case the overlay input sizes must be

96	the same, but, in case of video overlays, the output size can be different. Any

97	framebuffer can be connected to any overlay.

98

99	An overlay can be connected to one overlay manager. Also DISPC overlays can be

100	connected only to DISPC overlay managers, and virtual overlays can be only

101	connected to virtual overlays.

102

103	An overlay manager can be connected to one display. There are certain

104	restrictions which kinds of displays an overlay manager can be connected:

105

106	- DISPC TV overlay manager can be only connected to TV display.

107	- Virtual overlay managers can only be connected to DBI or DSI displays.

108	- DISPC LCD overlay manager can be connected to all displays, except TV

109	display.

110

111	Sysfs

112	-----

113	The sysfs interface is mainly used for testing. I don't think sysfs

114	interface is the best for this in the final version, but I don't quite know

115	what would be the best interfaces for these things.

116

117	The sysfs interface is divided to two parts: DSS and FB.

118

119	/sys/class/graphics/fb? directory:

120	mirror	0=off, 1=on

121	rotate	Rotation 0-3 for 0, 90, 180, 270 degrees

122	rotate_type	0 = DMA rotation, 1 = VRFB rotation

123	overlays	List of overlay numbers to which framebuffer pixels go

124	phys_addr	Physical address of the framebuffer

125	virt_addr	Virtual address of the framebuffer

126	size	Size of the framebuffer

127

128	/sys/devices/platform/omapdss/overlay? directory:

129	enabled	0=off, 1=on

130	input_size	width,height (ie. the framebuffer size)

131	manager	Destination overlay manager name

132	name

133	output_size	width,height

134	position	x,y

135	screen_width	width

136	global_alpha	global alpha 0-255 0=transparent 255=opaque

137

138	/sys/devices/platform/omapdss/manager? directory:

139	display	Destination display

140	name

141	alpha_blending_enabled	0=off, 1=on

142	trans_key_enabled	0=off, 1=on

143	trans_key_type	gfx-destination, video-source

144	trans_key_value	transparency color key (RGB24)

145	default_color	default background color (RGB24)

146

147	/sys/devices/platform/omapdss/display? directory:

148	ctrl_name	Controller name

149	mirror	0=off, 1=on

150	update_mode	0=off, 1=auto, 2=manual

151	enabled	0=off, 1=on

152	name

153	rotate	Rotation 0-3 for 0, 90, 180, 270 degrees

154	timings	Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)

155	When writing, two special timings are accepted for tv-out:

156	"pal" and "ntsc"

157	panel_name

158	tear_elim	Tearing elimination 0=off, 1=on

159

160	There are also some debugfs files at <debugfs>/omapdss/ which show information

161	about clocks and registers.

162

163	Examples

164	--------

165

166	The following definitions have been made for the examples below:

167

168	ovl0=/sys/devices/platform/omapdss/overlay0

169	ovl1=/sys/devices/platform/omapdss/overlay1

170	ovl2=/sys/devices/platform/omapdss/overlay2

171

172	mgr0=/sys/devices/platform/omapdss/manager0

173	mgr1=/sys/devices/platform/omapdss/manager1

174

175	lcd=/sys/devices/platform/omapdss/display0

176	dvi=/sys/devices/platform/omapdss/display1

177	tv=/sys/devices/platform/omapdss/display2

178

179	fb0=/sys/class/graphics/fb0

180	fb1=/sys/class/graphics/fb1

181	fb2=/sys/class/graphics/fb2

182

183	Default setup on OMAP3 SDP

184	--------------------------

185

186	Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI

187	and TV-out are not in use. The columns from left to right are:

188	framebuffers, overlays, overlay managers, displays. Framebuffers are

189	handled by omapfb, and the rest by the DSS.

190

191	FB0 --- GFX -\ DVI

192	FB1 --- VID1 --+- LCD ---- LCD

193	FB2 --- VID2 -/ TV ----- TV

194

195	Example: Switch from LCD to DVI

196	----------------------

197

198	w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1`

199	h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1`

200

201	echo "0" > $lcd/enabled

202	echo "" > $mgr0/display

203	fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h

204	# at this point you have to switch the dvi/lcd dip-switch from the omap board

205	echo "dvi" > $mgr0/display

206	echo "1" > $dvi/enabled

207

208	After this the configuration looks like:

209

210	FB0 --- GFX -\ -- DVI

211	FB1 --- VID1 --+- LCD -/ LCD

212	FB2 --- VID2 -/ TV ----- TV

213

214	Example: Clone GFX overlay to LCD and TV

215	-------------------------------

216

217	w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`

218	h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`

219

220	echo "0" > $ovl0/enabled

221	echo "0" > $ovl1/enabled

222

223	echo "" > $fb1/overlays

224	echo "0,1" > $fb0/overlays

225

226	echo "$w,$h" > $ovl1/output_size

227	echo "tv" > $ovl1/manager

228

229	echo "1" > $ovl0/enabled

230	echo "1" > $ovl1/enabled

231

232	echo "1" > $tv/enabled

233

234	After this the configuration looks like (only relevant parts shown):

235

236	FB0 +-- GFX ---- LCD ---- LCD

237	\- VID1 ---- TV ---- TV

238

239	Misc notes

240	----------

241

242	OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.

243

244	Using DSI DPLL to generate pixel clock it is possible produce the pixel clock

245	of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.

246

247	Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB

248	does not support mirroring.

249

250	VRFB rotation requires much more memory than non-rotated framebuffer, so you

251	probably need to increase your vram setting before using VRFB rotation. Also,

252	many applications may not work with VRFB if they do not pay attention to all

253	framebuffer parameters.

254

255	Kernel boot arguments

256	---------------------

257

258	vram=<size>[,<physaddr>]

259	- Amount of total VRAM to preallocate and optionally a physical start

260	memory address. For example, "10M". omapfb allocates memory for

261	framebuffers from VRAM.

262

263	omapfb.mode=<display>:<mode>[,...]

264	- Default video mode for specified displays. For example,

265	"dvi:800x400MR-24@60". See drivers/video/modedb.c.

266	There are also two special modes: "pal" and "ntsc" that

267	can be used to tv out.

268

269	omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]

270	- VRAM allocated for a framebuffer. Normally omapfb allocates vram

271	depending on the display size. With this you can manually allocate

272	more or define the physical address of each framebuffer. For example,

273	"1:4M" to allocate 4M for fb1.

274

275	omapfb.debug=<y|n>

276	- Enable debug printing. You have to have OMAPFB debug support enabled

277	in kernel config.

278

279	omapfb.test=<y|n>

280	- Draw test pattern to framebuffer whenever framebuffer settings change.

281	You need to have OMAPFB debug support enabled in kernel config.

282

283	omapfb.vrfb=<y|n>

284	- Use VRFB rotation for all framebuffers.

285

286	omapfb.rotate=<angle>

287	- Default rotation applied to all framebuffers.

288	0 - 0 degree rotation

289	1 - 90 degree rotation

290	2 - 180 degree rotation

291	3 - 270 degree rotation

292

293	omapfb.mirror=<y|n>

294	- Default mirror for all framebuffers. Only works with DMA rotation.

295

296	omapdss.def_disp=<display>

297	- Name of default display, to which all overlays will be connected.

298	Common examples are "lcd" or "tv".

299

300	omapdss.debug=<y|n>

301	- Enable debug printing. You have to have DSS debug support enabled in

302	kernel config.

303

304	TODO

305	----

306

307	DSS locking

308

309	Error checking

310	- Lots of checks are missing or implemented just as BUG()

311

312	System DMA update for DSI

313	- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how

314	to skip the empty byte?)

315

316	OMAP1 support

317	- Not sure if needed