DocBook/drm: can -> may

      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>

	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.

      <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

      <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

	  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

<!--!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>

	    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>

      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.