DocBook/drm: can -> may

Signed-off-by: Michael Witten <mfwitten@gmail.com>

1 files changed, 10 insertions, 10 deletions

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 0527ff2be37e..b9079386040d 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -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 &amp; 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.