diff options
| author | Jonathan Herman <hermanjl@cs.unc.edu> | 2013-01-22 10:38:37 -0500 |
|---|---|---|
| committer | Jonathan Herman <hermanjl@cs.unc.edu> | 2013-01-22 10:38:37 -0500 |
| commit | fcc9d2e5a6c89d22b8b773a64fb4ad21ac318446 (patch) | |
| tree | a57612d1888735a2ec7972891b68c1ac5ec8faea /Documentation/video | |
| parent | 8dea78da5cee153b8af9c07a2745f6c55057fe12 (diff) | |
Diffstat (limited to 'Documentation/video')
| -rw-r--r-- | Documentation/video/tegra_dc_ext.txt | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/Documentation/video/tegra_dc_ext.txt b/Documentation/video/tegra_dc_ext.txt new file mode 100644 index 00000000000..6fc3394c665 --- /dev/null +++ b/Documentation/video/tegra_dc_ext.txt | |||
| @@ -0,0 +1,83 @@ | |||
| 1 | The Tegra display controller (dc) driver has two frontends that implement | ||
| 2 | different interfaces: | ||
| 3 | 1. The traditional fbdev interface, implemented in drivers/video/tegra/fb.c | ||
| 4 | 2. A new interface that exposes the unique capabilities of the controller, | ||
| 5 | implemented in drivers/video/tegra/dc/ext | ||
| 6 | |||
| 7 | The Tegra fbdev capabilities are documented in fb/tegrafb.c [TODO]. This | ||
| 8 | document will describe the new "extended" dc interface. | ||
| 9 | |||
| 10 | The extended interface is only available when its frontend has been compiled | ||
| 11 | in, i.e., CONFIG_TEGRA_DC_EXTENSIONS=y. The dc_ext frontend can coexist with | ||
| 12 | tegrafb, but takes precedence (more on that later). | ||
| 13 | |||
| 14 | The dc_ext frontend's interface to userspace is exposed through a set of | ||
| 15 | device nodes: one for each controller (generally /dev/tegra_dc_N), and one | ||
| 16 | "control" node (generally /dev/tegra_dc_ctrl). Communication through these | ||
| 17 | device nodes is done with special IOCTLs. There is also an event delivery | ||
| 18 | mechanism; userspace can wait for and receive events with read() or poll(). | ||
| 19 | |||
| 20 | The tegra_dc_N interface is stateful; each fresh open() of the device node | ||
| 21 | creates a client instance. In order to prevent multiple processes from | ||
| 22 | "fighting" for the hardware, only one client instance is permitted to control | ||
| 23 | certain resources at a time, on a first-come, first-serve basis. | ||
| 24 | |||
| 25 | Overview of tegra_dc_N IOCTLs: | ||
| 26 | SET_NVMAP_FD: This is used to associate your nvmap client with this dc_ext | ||
| 27 | client instance. This is necessary so that the kernel can | ||
| 28 | appropriately enforce permissions on nvmap buffers. | ||
| 29 | |||
| 30 | GET_WINDOW: A dc_ext client must call this on each window that it wishes to | ||
| 31 | control. This strictly enforces a single dc_ext client on a | ||
| 32 | window at a time. | ||
| 33 | |||
| 34 | PUT_WINDOW: A dc_ext client may call this to release a window previously | ||
| 35 | reserved with GET_WINDOW. | ||
| 36 | |||
| 37 | FLIP: This ioctl is used to actually display an nvmap surface using one or | ||
| 38 | more window. Each time a dc_ext client performs a FLIP, the request is | ||
| 39 | put on a flip queue and executed asynchronously (the FLIP ioctl will | ||
| 40 | return immediately). Various parameters are available in the | ||
| 41 | tegra_dc_ext_flip structure. | ||
| 42 | A dc_ext client may only use this on windows that it has previously | ||
| 43 | reserved with a successful GET_WINDOW call. | ||
| 44 | |||
| 45 | GET_CURSOR: This is analogous to GET_WINDOW, but for the hardware cursor | ||
| 46 | instead of a window. | ||
| 47 | |||
| 48 | PUT_CURSOR: This is analogous to PUT_WINDOW, but for the hardware cursor | ||
| 49 | instead of a window. | ||
| 50 | |||
| 51 | SET_CURSOR_IMAGE: This is used to change the hardware cursor image. May only | ||
| 52 | be used by a client who has successfully performed a | ||
| 53 | GET_CURSOR call. | ||
| 54 | |||
| 55 | SET_CURSOR: This is used to actually place the hardware cursor on the screen. | ||
| 56 | May only be used by a client who has successfully performed a | ||
| 57 | GET_CURSOR call. | ||
| 58 | |||
| 59 | SET_CSC: This may be used to set a color space conversion matrix on a window. | ||
| 60 | A dc_ext client may only use this on windows that it has previously | ||
| 61 | reserved with a successful GET_WINDOW call. | ||
| 62 | |||
| 63 | GET_STATUS: This is used to retrieve general status about the dc. | ||
| 64 | |||
| 65 | GET_VBLANK_SYNCPT: This is used to retrieve the auto-incrementing vblank | ||
| 66 | syncpoint for the head associated with this dc. | ||
| 67 | |||
| 68 | |||
| 69 | Overview of tegra_dc_ctrl IOCTLs: | ||
| 70 | GET_NUM_OUTPUTS: This returns the number of available output devices on the | ||
| 71 | system, which may exceed the number of display controllers. | ||
| 72 | |||
| 73 | GET_OUTPUT_PROPERTIES: This returns data about the given output, such as what | ||
| 74 | kind of output it is, whether it's currently associated | ||
| 75 | with a head, etc. | ||
| 76 | |||
| 77 | GET_OUTPUT_EDID: This returns the binary EDID read from the device connected | ||
| 78 | to the given output, if any. | ||
| 79 | |||
| 80 | SET_EVENT_MASK: A dc_ext client may call this ioctl with a bitmask of events | ||
| 81 | that it wishes to receive. These events will then be | ||
| 82 | available to that client on a subsequent read() on the same | ||
| 83 | file descriptor. | ||
