xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

DocBook/drm: (device|driver) specific' -> (device|driver)-specific'

Browse Source 
Signed-off-by: Michael Witten <mfwitten@gmail.com>
This commit is contained in:
Michael Witten
2011-08-29 18:05:52 +00:00
parent 5a462d58c8
commit a5294e01f2
1 changed files with 17 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
Documentation/DocBook/drm.tmpl
View File

@@ -238,7 +238,7 @@
</variablelist> </variablelist>
<para> <para>
In this specific case, the driver requires AGP and supports In this specific case, the driver requires AGP and supports
IRQs. DMA, as discussed later, is handled by device specific ioctls IRQs. DMA, as discussed later, is handled by device-specific ioctls
in this case. It also supports the kernel mode setting APIs, though in this case. It also supports the kernel mode setting APIs, though
unlike in the actual i915 driver source, this example unconditionally unlike in the actual i915 driver source, this example unconditionally
exports KMS capability. exports KMS capability.
@@ -277,7 +277,7 @@
to perform output discovery &amp; configuration at load time. to perform output discovery &amp; configuration at load time.
Likewise, if user-level drivers unaware of memory management are Likewise, if user-level drivers unaware of memory management are
in use, memory management and command buffer setup may need to in use, memory management and command buffer setup may need to
be omitted. These requirements are driver specific, and care be omitted. These requirements are driver-specific, and care
needs to be taken to keep both old and new applications and needs to be taken to keep both old and new applications and
libraries working. The i915 driver supports the "modeset" libraries working. The i915 driver supports the "modeset"
module parameter to control whether advanced features are module parameter to control whether advanced features are
@@ -288,7 +288,7 @@
<title>Driver private &amp; performance counters</title> <title>Driver private &amp; performance counters</title>
<para> <para>
The driver private hangs off the main drm_device structure and The driver private hangs off the main drm_device structure and
can be used for tracking various device specific bits of can be used for tracking various device-specific bits of
information, like register offsets, command buffer status, information, like register offsets, command buffer status,
register state for suspend/resume, etc. At load time, a register state for suspend/resume, etc. At load time, a
driver may simply allocate one and set drm_device.dev_priv driver may simply allocate one and set drm_device.dev_priv
@@ -313,7 +313,7 @@
<sect2> <sect2>
<title>Configuring the device</title> <title>Configuring the device</title>
<para> <para>
Obviously, device configuration is device specific. Obviously, device configuration is device-specific.
However, there are several common operations: finding a However, there are several common operations: finding a
device's PCI resources, mapping them, and potentially setting device's PCI resources, mapping them, and potentially setting
up an IRQ handler. up an IRQ handler.
@@ -340,8 +340,8 @@
<para> <para>
Once you have a register map, you may use the DRM_READn() and Once you have a register map, you may use the DRM_READn() and
DRM_WRITEn() macros to access the registers on your device, or DRM_WRITEn() macros to access the registers on your device, or
use driver specific versions to offset into your MMIO space use driver-specific versions to offset into your MMIO space
relative to a driver specific base pointer (see I915_READ for relative to a driver-specific base pointer (see I915_READ for
an example). an example).
</para> </para>
<para> <para>
@@ -399,7 +399,7 @@
and devices with dedicated video RAM (VRAM), i.e. most discrete and devices with dedicated video RAM (VRAM), i.e. most discrete
graphics devices. If your device has dedicated RAM, supporting graphics devices. If your device has dedicated RAM, supporting
TTM is desirable. TTM also integrates tightly with your TTM is desirable. TTM also integrates tightly with your
driver specific buffer execution function. See the radeon driver-specific buffer execution function. See the radeon
driver for examples. driver for examples.
</para> </para>
<para> <para>
@@ -427,7 +427,7 @@
created by the memory manager at runtime. Your global TTM should created by the memory manager at runtime. Your global TTM should
have a type of TTM_GLOBAL_TTM_MEM. The size field for the global have a type of TTM_GLOBAL_TTM_MEM. The size field for the global
object should be sizeof(struct ttm_mem_global), and the init and object should be sizeof(struct ttm_mem_global), and the init and
release hooks should point at your driver specific init and release hooks should point at your driver-specific init and
release routines, which probably eventually call release routines, which probably eventually call
ttm_mem_global_init and ttm_mem_global_release, respectively. ttm_mem_global_init and ttm_mem_global_release, respectively.
</para> </para>
@@ -438,7 +438,7 @@
provide a pool for buffer object allocation by clients and the provide a pool for buffer object allocation by clients and the
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
and its size should be sizeof(struct ttm_bo_global). Again, and its size should be sizeof(struct ttm_bo_global). Again,
driver specific init and release functions may be provided, driver-specific init and release functions may be provided,
likely eventually calling ttm_bo_global_init() and likely eventually calling ttm_bo_global_init() and
ttm_bo_global_release(), respectively. Also, like the previous ttm_bo_global_release(), respectively. Also, like the previous
object, ttm_global_item_ref() is used to create an initial reference object, ttm_global_item_ref() is used to create an initial reference
@@ -462,7 +462,7 @@
be initialized separately into its own DRM MM object. be initialized separately into its own DRM MM object.
</para> </para>
<para> <para>
Initialization is driver specific. In the case of Intel Initialization is driver-specific. In the case of Intel
integrated graphics chips like 965GM, GEM initialization can integrated graphics chips like 965GM, GEM initialization can
be done by calling the internal GEM init function, be done by calling the internal GEM init function,
i915_gem_do_init(). Since the 965GM is a UMA device i915_gem_do_init(). Since the 965GM is a UMA device
@@ -561,8 +561,8 @@ void intel_crt_init(struct drm_device *dev)
</programlisting> </programlisting>
<para> <para>
In the example above (again, taken from the i915 driver), a In the example above (again, taken from the i915 driver), a
CRT connector and encoder combination is created. A device CRT connector and encoder combination is created. A device-specific
specific i2c bus is also created for fetching EDID data and i2c bus is also created for fetching EDID data and
performing monitor detection. Once the process is complete, performing monitor detection. Once the process is complete,
the new connector is registered with sysfs to make its the new connector is registered with sysfs to make its
properties available to applications. properties available to applications.
@@ -704,8 +704,8 @@ void intel_crt_init(struct drm_device *dev)
<para> <para>
GEM-enabled drivers must provide gem_init_object() and GEM-enabled drivers must provide gem_init_object() and
gem_free_object() callbacks to support the core memory gem_free_object() callbacks to support the core memory
allocation routines. They should also provide several driver allocation routines. They should also provide several driver-specific
specific ioctls to support command execution, pinning, buffer ioctls to support command execution, pinning, buffer
read &amp; write, mapping, and domain ownership transfers. read &amp; write, mapping, and domain ownership transfers.
</para> </para>
<para> <para>
@@ -797,7 +797,7 @@ void intel_crt_init(struct drm_device *dev)
<para> <para>
Clients need to provide a framebuffer object which provides a source Clients need to provide a framebuffer object which provides a source
of pixels for a CRTC to deliver to the encoder(s) and ultimately the of pixels for a CRTC to deliver to the encoder(s) and ultimately the
connector(s). A framebuffer is fundamentally a driver specific memory connector(s). A framebuffer is fundamentally a driver-specific memory
object, made into an opaque handle by the DRM's addfb() function. object, made into an opaque handle by the DRM's addfb() function.
Once a framebuffer has been created this way, it may be passed to the Once a framebuffer has been created this way, it may be passed to the
KMS mode setting routines for use in a completed configuration. KMS mode setting routines for use in a completed configuration.
@@ -807,7 +807,7 @@ void intel_crt_init(struct drm_device *dev)
<sect1> <sect1>
<title>Command submission &amp; fencing</title> <title>Command submission &amp; fencing</title>
<para> <para>
This should cover a few device specific command submission This should cover a few device-specific command submission
implementations. implementations.
</para> </para>
</sect1> </sect1>
@@ -840,7 +840,7 @@ void intel_crt_init(struct drm_device *dev)
<para> <para>
The DRM core exports several interfaces to applications, The DRM core exports several interfaces to applications,
generally intended to be used through corresponding libdrm generally intended to be used through corresponding libdrm
wrapper functions. In addition, drivers export device specific wrapper functions. In addition, drivers export device-specific
interfaces for use by userspace drivers &amp; device aware interfaces for use by userspace drivers &amp; device aware
applications through ioctls and sysfs files. applications through ioctls and sysfs files.
</para> </para>