diff options
author | Michael Witten <mfwitten@gmail.com> | 2011-08-25 17:18:08 +0000 |
---|---|---|
committer | Michael Witten <mfwitten@gmail.com> | 2011-08-25 17:18:08 +0000 |
commit | a78f6787a3dd7223bf185895fdcea661b408dc0a (patch) | |
tree | 6d75f9788541e0a18b148158f6af23d30182d0d5 | |
parent | caca9510ff4e5d842c0589110243d60927836222 (diff) | |
download | linux-a78f6787a3dd7223bf185895fdcea661b408dc0a.tar.gz linux-a78f6787a3dd7223bf185895fdcea661b408dc0a.tar.bz2 linux-a78f6787a3dd7223bf185895fdcea661b408dc0a.zip |
DocBook/drm: Eradicate inappropriate uses of the future tense
Signed-off-by: Michael Witten <mfwitten@gmail.com>
-rw-r--r-- | Documentation/DocBook/drm.tmpl | 50 |
1 files changed, 25 insertions, 25 deletions
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index c27915893974..0527ff2be37e 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -57,10 +57,10 @@ existing drivers. </para> <para> - First, we'll go over some typical driver initialization + First, we go over some typical driver initialization requirements, like setting up command buffers, creating an initial output configuration, and initializing core services. - Subsequent sections will cover core internals in more detail, + Subsequent sections cover core internals in more detail, providing implementation notes and examples. </para> <para> @@ -74,7 +74,7 @@ </para> <para> The core of every DRM driver is struct drm_driver. Drivers - will typically statically initialize a drm_driver structure, + typically statically initialize a drm_driver structure, then pass it to drm_init() at load time. </para> @@ -155,7 +155,7 @@ <para> In the example above, taken from the i915 DRM driver, the driver sets several flags indicating what core features it supports. - We'll go over the individual callbacks in later sections. Since + We go over the individual callbacks in later sections. Since flags indicate which features your driver supports to the DRM core, you need to set most of them prior to calling drm_init(). Some, like DRIVER_MODESET can be set later based on user supplied parameters, @@ -238,7 +238,7 @@ </variablelist> <para> In this specific case, the driver requires AGP and supports - IRQs. DMA, as we'll see, 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 unlike in the actual i915 driver source, this example unconditionally exports KMS capability. @@ -315,7 +315,7 @@ <sect2> <title>Configuring the device</title> <para> - Obviously, device configuration will be device specific. + Obviously, device configuration is device specific. However, there are several common operations: finding a device's PCI resources, mapping them, and potentially setting up an IRQ handler. @@ -326,7 +326,7 @@ drm_get_resource_len() can 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'll probably want a + mapping for the BAR in question. Note you probably want a drm_local_map_t in your driver private structure to track any mappings you create. <!-- !Fdrivers/gpu/drm/drm_bufs.c drm_get_resource_* --> @@ -357,7 +357,7 @@ </para> <!--!Fdrivers/char/drm/drm_irq.c drm_irq_install--> <para> - Once your interrupt handler is registered (it'll use your + Once your interrupt handler is registered (it uses your drm_driver.irq_handler as the actual interrupt handling function), you can safely enable interrupts on your device, assuming any other state your interrupt handler uses is also @@ -389,7 +389,7 @@ should support a memory manager. </para> <para> - If your driver supports memory management (it should!), you'll + If your driver supports memory management (it should!), you need to set that up at load time as well. How you initialize it depends on which memory manager you're using, TTM or GEM. </para> @@ -430,13 +430,13 @@ 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 release hooks should point at your driver specific init and - release routines, which will probably eventually call + release routines, which probably eventually call ttm_mem_global_init and ttm_mem_global_release respectively. </para> <para> Once your global TTM accounting structure is set up and initialized (done by calling ttm_global_item_ref on the global object you - just created), you'll need to create a buffer object TTM to + just created), you need to create a buffer object TTM to 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, @@ -455,8 +455,8 @@ than TTM, but has no VRAM management capability. Core GEM initialization is comprised of a basic drm_mm_init call to create a GTT DRM MM object, which provides an address space pool for - object allocation. In a KMS configuration, the driver will - need to allocate and initialize a command ring buffer following + object allocation. In a KMS configuration, the driver + needs to allocate and initialize a command ring buffer following basic GEM initialization. Most UMA devices have a so-called "stolen" memory region, which provides space for the initial framebuffer and large, contiguous memory regions required by the @@ -464,16 +464,16 @@ be initialized separately into its own DRM MM object. </para> <para> - Initialization will be driver specific, and will depend on + Initialization is driver specific, and depends on the architecture of the device. In the case of Intel integrated graphics chips like 965GM, GEM initialization can be done by calling the internal GEM init function, i915_gem_do_init(). Since the 965GM is a UMA device - (i.e. it doesn't have dedicated VRAM), GEM will manage + (i.e. it doesn't have dedicated VRAM), GEM manages making regular RAM available for GPU operations. Memory set aside by the BIOS (called "stolen" memory by the i915 - driver) will be managed by the DRM memrange allocator; the - rest of the aperture will be managed by GEM. + driver) is managed by the DRM memrange allocator; the + rest of the aperture is managed by GEM. <programlisting> /* Basic memrange allocator for stolen space (aka vram) */ drm_memrange_init(&dev_priv->vram, 0, prealloc_size); @@ -616,7 +616,7 @@ void intel_crt_init(struct drm_device *dev) <para> DRM_IOCTL_MODESET_CTL should be called by application level drivers before and after mode setting, since on many devices the - vertical blank counter will be reset at that time. Internally, + vertical blank counter is reset at that time. Internally, the DRM snapshots the last vblank count when the ioctl is called with the _DRM_PRE_MODESET command so that the counter won't go backwards (which is dealt with when _DRM_POST_MODESET is used). @@ -632,8 +632,8 @@ void intel_crt_init(struct drm_device *dev) register. The enable and disable vblank callbacks should enable and disable vertical blank interrupts, respectively. In the absence of DRM clients waiting on vblank events, the core DRM - code will use the disable_vblank() function to disable - interrupts, which saves power. They'll be re-enabled again when + code uses the disable_vblank() function to disable + interrupts, which saves power. They are re-enabled again when a client calls the vblank wait ioctl above. </para> <para> @@ -699,14 +699,14 @@ void intel_crt_init(struct drm_device *dev) performs any necessary flushing or synchronization to put the object into the desired coherency domain (note that the object may be busy, i.e. an active render target; in that case the set domain function - will block the client and wait for rendering to complete before + blocks the client and waits for rendering to complete before performing any necessary flushing operations). </para> <para> Perhaps the most important GEM function is providing a command execution interface to clients. Client programs construct command buffers containing references to previously allocated memory objects - and submit them to GEM. At that point, GEM will take care to bind + and submit them to GEM. At that point, GEM takes care to bind all the objects into the GTT, execute the buffer, and provide necessary synchronization between clients accessing the same buffers. This often involves evicting some objects from the GTT and re-binding @@ -767,7 +767,7 @@ void intel_crt_init(struct drm_device *dev) <para> In order to set a mode on a given CRTC, encoder and connector configuration, clients need to provide a framebuffer object which - will provide a source of pixels for the CRTC to deliver to the encoder(s) + provides a source of pixels for the CRTC to deliver to the encoder(s) and ultimately the connector(s) in the configuration. A framebuffer is fundamentally a driver specific memory object, made into an opaque handle by the DRM addfb function. Once an fb has been created this @@ -789,7 +789,7 @@ void intel_crt_init(struct drm_device *dev) <para> The DRM core provides some suspend/resume code, but drivers wanting full suspend/resume support should provide save() and - restore() functions. These will be called at suspend, + restore() functions. These are called at suspend, hibernate, or resume time, and should perform any state save or restore required by your device across suspend or hibernate states. @@ -823,7 +823,7 @@ void intel_crt_init(struct drm_device *dev) </para> <para> Cover generic ioctls and sysfs layout here. Only need high - level info, since man pages will cover the rest. + level info, since man pages should cover the rest. </para> </chapter> |