summaryrefslogtreecommitdiff
path: root/DrmMapHandling.mdwn
diff options
context:
space:
mode:
authorJoe Rayhawk <jrayhawk@freedesktop.org>2013-04-14 00:24:47 -0700
committerJoe Rayhawk <jrayhawk@freedesktop.org>2013-04-14 00:24:47 -0700
commitbaffa271dd4db570c2959c31ebe757f0cfb238f9 (patch)
tree4b72fcd607c849f7feb10f0d5c8becc586efdf0f /DrmMapHandling.mdwn
parentb7447d31197f21fdddd2ca7c033d92a51e203a2e (diff)
moin2iki: Removing double newline from list that was accidently initiating a pre block
Diffstat (limited to 'DrmMapHandling.mdwn')
-rw-r--r--DrmMapHandling.mdwn5
1 files changed, 2 insertions, 3 deletions
diff --git a/DrmMapHandling.mdwn b/DrmMapHandling.mdwn
index b9f31d4..7cd2226 100644
--- a/DrmMapHandling.mdwn
+++ b/DrmMapHandling.mdwn
@@ -30,9 +30,8 @@ So far map handles are of a machine dependent size. On 32-bit platform they are
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.