summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoe Rayhawk <jrayhawk@freedesktop.org>2013-04-14 00:29:05 -0700
committerJoe Rayhawk <jrayhawk@freedesktop.org>2013-04-14 00:29:05 -0700
commit4595bd44e183586e22edbdd6f89014805ecdabe4 (patch)
tree2e948ac583529b230049b3761f2b5fe3bbe6a92a
parentbaffa271dd4db570c2959c31ebe757f0cfb238f9 (diff)
moin2iki: fixing markdown's weird numbered list formating at multiples of four spaces
-rw-r--r--DrmMapHandling.mdwn8
1 files changed, 4 insertions, 4 deletions
diff --git a/DrmMapHandling.mdwn b/DrmMapHandling.mdwn
index 7cd2226..349f6eb 100644
--- a/DrmMapHandling.mdwn
+++ b/DrmMapHandling.mdwn
@@ -27,11 +27,11 @@ Separate from maps, but also involved in the process, are bufs, which are used f
So far map handles are of a machine dependent size. On 32-bit platform they are 32 bit wide while on 64-bit platforms their width is 64 bit. This creates problems on bi-arch architectures that can both run 32 and 64 bit binaries:
- 1. The driver private rec that's passed between the Xserver and the DRI client has a machine dependent size making it impossible to pass data between different machine size binaries (64-bit Xserver and 32-bit DRI client for example).
- 1. 64-bit handle that does not fit into 32-bit cannot be used as offset in a 32-bit binary (unless the code is compiled with -D_FILE_OFFSET_BITS=64).
+ 1. The driver private rec that's passed between the Xserver and the DRI client has a machine dependent size making it impossible to pass data between different machine size binaries (64-bit Xserver and 32-bit DRI client for example).
+ 1. 64-bit handle that does not fit into 32-bit cannot be used as offset in a 32-bit binary (unless the code is compiled with -D_FILE_OFFSET_BITS=64).
From the table above we can see the following: `handle` contains either the kernel virtual address or 0 while `offset` contains either the kernel virtual address or the bus base. Furthermore the kernel virtual address is meaningless in user space. The `offset` value of the drm_handle_t structure is not read back to user space. Instead `handle` contains the value of `offset` which is used to identify the map from user space. We could therefore use `handle` to pass a 32-bit value back to user space. If we assume that bus base addresses always fit into 32-bit. This can be done by:
- 1. finding a value range that is guranteed to never conflict with bus base addresses and storing the result in `offset` instead of the kernel virtual address or
- 1. adding another element to the drm_map_t struct that uniquly identifies the map and passing this back to user space. We can pass the bus base to user space if feasable (ie. it fits in 32 bit and the value has not been used to identify another range). This would require creating a new struct for in kernel use, so that nothing changes for user space.
+ 1. finding a value range that is guranteed to never conflict with bus base addresses and storing the result in `offset` instead of the kernel virtual address or
+ 1. adding another element to the drm_map_t struct that uniquly identifies the map and passing this back to user space. We can pass the bus base to user space if feasable (ie. it fits in 32 bit and the value has not been used to identify another range). This would require creating a new struct for in kernel use, so that nothing changes for user space.
This can be done by changing the name of every occurance of drm_map_t (except where copying from and to user space) or by using a different name for the drm_map_t in the kernel. The latter will produce a smaller patch, the former may be less confusing.
Inside of the DRM, the [[MapBufs|MapBufs]] ioctl does an mmap on behalf of the client, using the offset from the "agp_buffer_map," which is set by the driver to be the map that its buffers come from -- added as above as type AGP or SCATTER_GATHER or CONSISTENT.