DocBook/drm: can -> may
Signed-off-by: Michael Witten <mfwitten@gmail.com>
This commit is contained in:
parent
a78f6787a3
commit
f11aca045c
|
@ -32,7 +32,7 @@
|
|||
The Linux DRM layer contains code intended to support the needs
|
||||
of complex graphics devices, usually containing programmable
|
||||
pipelines well suited to 3D graphics acceleration. Graphics
|
||||
drivers in the kernel can make use of DRM functions to make
|
||||
drivers in the kernel may make use of DRM functions to make
|
||||
tasks like memory management, interrupt handling and DMA easier,
|
||||
and provide a uniform interface to applications.
|
||||
</para>
|
||||
|
@ -293,12 +293,12 @@
|
|||
can be used for tracking various device specific bits of
|
||||
information, like register offsets, command buffer status,
|
||||
register state for suspend/resume, etc. At load time, a
|
||||
driver can simply allocate one and set drm_device.dev_priv
|
||||
driver may simply allocate one and set drm_device.dev_priv
|
||||
appropriately; at unload the driver can free it and set
|
||||
drm_device.dev_priv to NULL.
|
||||
</para>
|
||||
<para>
|
||||
The DRM supports several counters which can be used for rough
|
||||
The DRM supports several counters which may be used for rough
|
||||
performance characterization. Note that the DRM stat counter
|
||||
system is not often used by applications, and supporting
|
||||
additional counters is completely optional.
|
||||
|
@ -323,7 +323,7 @@
|
|||
<para>
|
||||
Finding & mapping resources is fairly straightforward. The
|
||||
DRM wrapper functions, drm_get_resource_start() and
|
||||
drm_get_resource_len() can be used to find BARs on the given
|
||||
drm_get_resource_len() may be used to find BARs on the given
|
||||
drm_device struct. Once those values have been retrieved, the
|
||||
driver load function can call drm_addmap() to create a new
|
||||
mapping for the BAR in question. Note you probably want a
|
||||
|
@ -335,12 +335,12 @@
|
|||
<para>
|
||||
if compatibility with other operating systems isn't a concern
|
||||
(DRM drivers can run under various BSD variants and OpenSolaris),
|
||||
native Linux calls can be used for the above, e.g. pci_resource_*
|
||||
native Linux calls may be used for the above, e.g. pci_resource_*
|
||||
and iomap*/iounmap. See the Linux device driver book for more
|
||||
info.
|
||||
</para>
|
||||
<para>
|
||||
Once you have a register map, you can 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
|
||||
use driver specific versions to offset into your MMIO space
|
||||
relative to a driver specific base pointer (see I915_READ for
|
||||
|
@ -440,7 +440,7 @@
|
|||
provide a pool for buffer object allocation by clients and the
|
||||
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
|
||||
and its size should be sizeof(struct ttm_bo_global). Again,
|
||||
driver specific init and release functions can be provided,
|
||||
driver specific init and release functions may be provided,
|
||||
likely eventually calling ttm_bo_global_init and
|
||||
ttm_bo_global_release, respectively. Also like the previous
|
||||
object, ttm_global_item_ref is used to create an initial reference
|
||||
|
@ -483,7 +483,7 @@
|
|||
<!--!Edrivers/char/drm/drm_memrange.c-->
|
||||
</para>
|
||||
<para>
|
||||
Once the memory manager has been set up, we can allocate the
|
||||
Once the memory manager has been set up, we may allocate the
|
||||
command buffer. In the i915 case, this is also done with a
|
||||
GEM function, i915_gem_init_ringbuffer().
|
||||
</para>
|
||||
|
@ -572,7 +572,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
devices with PC-style architectures (i.e. a set of display planes
|
||||
for feeding pixels to encoders which are in turn routed to
|
||||
connectors). Devices with more complex requirements needing
|
||||
finer grained management can opt to use the core callbacks
|
||||
finer grained management may opt to use the core callbacks
|
||||
directly.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -637,7 +637,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
a client calls the vblank wait ioctl above.
|
||||
</para>
|
||||
<para>
|
||||
Devices that don't provide a count register can simply use an
|
||||
Devices that don't provide a count register may simply use an
|
||||
internal atomic counter incremented on every vertical blank
|
||||
interrupt, and can make their enable and disable vblank
|
||||
functions into no-ops.
|
||||
|
|
Loading…
Reference in a new issue