Marek Vasut | 15c6935 | 2012-08-08 01:42:17 +0000 | [diff] [blame^] | 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 | |
| 39 | 1) arch/powerpc/cpu/mpc8xx/video.c |
| 40 | ---------------------------------- |
| 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 | |
| 47 | 2) arch/x86/lib/video.c |
| 48 | ----------------------- |
| 49 | This driver registers two separate STDIO devices and should be therefore |
| 50 | converted as such. |
| 51 | |
| 52 | 3) board/bf527-ezkit/video.c |
| 53 | ---------------------------- |
| 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 | |
| 58 | 4) board/bf533-stamp/video.c |
| 59 | ---------------------------- |
| 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 | |
| 64 | 5) board/bf548-ezkit/video.c |
| 65 | ---------------------------- |
| 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 | |
| 70 | 6) board/cm-bf548/video.c |
| 71 | ---------------------------- |
| 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. |