aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/video
diff options
context:
space:
mode:
authorJonathan Herman <hermanjl@cs.unc.edu>2013-01-22 10:38:37 -0500
committerJonathan Herman <hermanjl@cs.unc.edu>2013-01-22 10:38:37 -0500
commitfcc9d2e5a6c89d22b8b773a64fb4ad21ac318446 (patch)
treea57612d1888735a2ec7972891b68c1ac5ec8faea /Documentation/video
parent8dea78da5cee153b8af9c07a2745f6c55057fe12 (diff)
Added missing tegra files.HEADmaster
Diffstat (limited to 'Documentation/video')
-rw-r--r--Documentation/video/tegra_dc_ext.txt83
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 @@
1The Tegra display controller (dc) driver has two frontends that implement
2different interfaces:
31. The traditional fbdev interface, implemented in drivers/video/tegra/fb.c
42. A new interface that exposes the unique capabilities of the controller,
5 implemented in drivers/video/tegra/dc/ext
6
7The Tegra fbdev capabilities are documented in fb/tegrafb.c [TODO]. This
8document will describe the new "extended" dc interface.
9
10The extended interface is only available when its frontend has been compiled
11in, i.e., CONFIG_TEGRA_DC_EXTENSIONS=y. The dc_ext frontend can coexist with
12tegrafb, but takes precedence (more on that later).
13
14The dc_ext frontend's interface to userspace is exposed through a set of
15device nodes: one for each controller (generally /dev/tegra_dc_N), and one
16"control" node (generally /dev/tegra_dc_ctrl). Communication through these
17device nodes is done with special IOCTLs. There is also an event delivery
18mechanism; userspace can wait for and receive events with read() or poll().
19
20The tegra_dc_N interface is stateful; each fresh open() of the device node
21creates a client instance. In order to prevent multiple processes from
22"fighting" for the hardware, only one client instance is permitted to control
23certain resources at a time, on a first-come, first-serve basis.
24
25Overview of tegra_dc_N IOCTLs:
26SET_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
30GET_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
34PUT_WINDOW: A dc_ext client may call this to release a window previously
35 reserved with GET_WINDOW.
36
37FLIP: 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
45GET_CURSOR: This is analogous to GET_WINDOW, but for the hardware cursor
46 instead of a window.
47
48PUT_CURSOR: This is analogous to PUT_WINDOW, but for the hardware cursor
49 instead of a window.
50
51SET_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
55SET_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
59SET_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
63GET_STATUS: This is used to retrieve general status about the dc.
64
65GET_VBLANK_SYNCPT: This is used to retrieve the auto-incrementing vblank
66 syncpoint for the head associated with this dc.
67
68
69Overview of tegra_dc_ctrl IOCTLs:
70GET_NUM_OUTPUTS: This returns the number of available output devices on the
71 system, which may exceed the number of display controllers.
72
73GET_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
77GET_OUTPUT_EDID: This returns the binary EDID read from the device connected
78 to the given output, if any.
79
80SET_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.