[people/ms/u-boot.git] / doc / driver-model / UDM-video.txt

The U-Boot Driver Model Project
===============================
Video output analysis
=====================
Marek Vasut <marek.vasut@gmail.com>
2012-02-20

I) Overview
-----------

The video drivers are most often registered with video subsystem. This subsystem
often expects to be allowed access to framebuffer of certain parameters. This
subsystem also provides calls for STDIO subsystem to allow it to output
characters on the screen. For this part, see [ UDM-stdio.txt ].

Therefore the API has two parts, the video driver part and the part where the
video driver core registers with STDIO API.

The video driver part will follow the current cfb_console approach, though
allowing it to be more dynamic.

II) Approach
------------

Registering the video driver into the video driver core is done by calling the
following function from the driver probe() function:

  video_device_register(struct instance *i, GraphicDevice *gd);

Because the video driver core is in charge or rendering characters as well as
bitmaps on the screen, it will in turn call stdio_device_register(i, so), where
"i" is the same instance as the video driver's one. But "so" will be special
static struct stdio_device_ops handling the character output.


III) Analysis of in-tree drivers
--------------------------------

  arch/powerpc/cpu/mpc8xx/video.c
  -------------------------------
  This driver copies the cfb_console [ see drivers/video/cfb_console.c ]
  approach and acts only as a STDIO device. Therefore there are currently two
  possible approaches, first being the conversion of this driver to usual STDIO
  device and second, long-term one, being conversion of this driver to video
  driver that provides console.

  arch/x86/lib/video.c
  --------------------
  This driver registers two separate STDIO devices and should be therefore
  converted as such.

  board/bf527-ezkit/video.c
  -------------------------
  This driver seems bogus as it behaves as STDIO device, but provides no input
  or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
  or present otherwise than as a dead code/define.

  board/bf533-stamp/video.c
  -------------------------
  This driver seems bogus as it behaves as STDIO device, but provides no input
  or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
  or present otherwise than as a dead code/define.

  board/bf548-ezkit/video.c
  -------------------------
  This driver seems bogus as it behaves as STDIO device, but provides no input
  or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
  or present otherwise than as a dead code/define.

  board/cm-bf548/video.c
  ----------------------
  This driver seems bogus as it behaves as STDIO device, but provides no input
  or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
  or present otherwise than as a dead code/define.
Commit	Line	Data
15c6935b MV	1	The U-Boot Driver Model Project
	2	===============================
	3	Video output analysis
	4	=====================
	5	Marek Vasut <marek.vasut@gmail.com>
	6	2012-02-20
	7
	8	I) Overview
	9	-----------
	10
	11	The video drivers are most often registered with video subsystem. This subsystem
	12	often expects to be allowed access to framebuffer of certain parameters. This
	13	subsystem also provides calls for STDIO subsystem to allow it to output
	14	characters on the screen. For this part, see [ UDM-stdio.txt ].
	15
	16	Therefore the API has two parts, the video driver part and the part where the
	17	video driver core registers with STDIO API.
	18
	19	The video driver part will follow the current cfb_console approach, though
	20	allowing it to be more dynamic.
	21
	22	II) Approach
	23	------------
	24
	25	Registering the video driver into the video driver core is done by calling the
	26	following function from the driver probe() function:
	27
	28	video_device_register(struct instance i, GraphicDevice gd);
	29
	30	Because the video driver core is in charge or rendering characters as well as
	31	bitmaps on the screen, it will in turn call stdio_device_register(i, so), where
	32	"i" is the same instance as the video driver's one. But "so" will be special
	33	static struct stdio_device_ops handling the character output.
	34
	35
	36	III) Analysis of in-tree drivers
	37	--------------------------------
	38
566c6e43 MY	39	arch/powerpc/cpu/mpc8xx/video.c
566c6e43 MY	40	-------------------------------
15c6935b MV	41	This driver copies the cfb_console [ see drivers/video/cfb_console.c ]
	42	approach and acts only as a STDIO device. Therefore there are currently two
	43	possible approaches, first being the conversion of this driver to usual STDIO
	44	device and second, long-term one, being conversion of this driver to video
	45	driver that provides console.
	46
566c6e43 MY	47	arch/x86/lib/video.c
566c6e43 MY	48	--------------------
15c6935b MV	49	This driver registers two separate STDIO devices and should be therefore
	50	converted as such.
	51
566c6e43 MY	52	board/bf527-ezkit/video.c
566c6e43 MY	53	-------------------------
15c6935b MV	54	This driver seems bogus as it behaves as STDIO device, but provides no input
	55	or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
	56	or present otherwise than as a dead code/define.
	57
566c6e43 MY	58	board/bf533-stamp/video.c
566c6e43 MY	59	-------------------------
15c6935b MV	60	This driver seems bogus as it behaves as STDIO device, but provides no input
	61	or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
	62	or present otherwise than as a dead code/define.
	63
566c6e43 MY	64	board/bf548-ezkit/video.c
566c6e43 MY	65	-------------------------
15c6935b MV	66	This driver seems bogus as it behaves as STDIO device, but provides no input
	67	or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
	68	or present otherwise than as a dead code/define.
	69
566c6e43 MY	70	board/cm-bf548/video.c
566c6e43 MY	71	----------------------
15c6935b MV	72	This driver seems bogus as it behaves as STDIO device, but provides no input
	73	or output capabilities. It relies on DEV_EXT_VIDEO, which is no longer in use
	74	or present otherwise than as a dead code/define.