On Mon, 29 Aug 2011 20:21:26 -0000, Michael Witten wrote:
> Fistly, Jesse, your technical opinion is probably only necessary for:
>
> [38] DocBook/drm: Refer to the domain-setting function as a
> device-specific ioctl
>
> The changes there may be erroneous. However, the rest of the patches are
> essentially trivial, so you needn't bother with them unless it interests
> you; of course, I've been told that the DRM documentation has grown quite
> stale, so it would be great if you could [find somebody to] update it.
Specifically:
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index ba20f9f..9ae328a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -724,11 +724,11 @@ void intel_crt_init(struct drm_device *dev)
has finished rendering to the object, then the object must be made
coherent with the CPU's view
of memory, usually involving GPU cache flushing of various kinds.
- This core CPU<->GPU coherency management is provided by the GEM
- set domain function, which evaluates an object's current domain and
+ This core CPU<->GPU coherency management is provided by a
+ device-specific ioctl, which evaluates an object's current domain and
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
+ i.e. an active render target; in that case, setting the domain
blocks the client and waits for rendering to complete before
performing any necessary flushing operations).
</para>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
