930N/A * Copyright (c) 2006, 2013, Oracle and/or its affiliates. All rights reserved. 930N/A * Copyright (c) 2009, 2013, Intel Corporation. 930N/A * Permission is hereby granted, free of charge, to any person obtaining a 930N/A * copy of this software and associated documentation files (the "Software"), 930N/A * to deal in the Software without restriction, including without limitation 930N/A * the rights to use, copy, modify, merge, publish, distribute, sublicense, 930N/A * and/or sell copies of the Software, and to permit persons to whom the 930N/A * Software is furnished to do so, subject to the following conditions: 930N/A * The above copyright notice and this permission notice (including the next 930N/A * paragraph) shall be included in all copies or substantial portions of the 930N/A * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 930N/A * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 930N/A * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 930N/A * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 930N/A * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 930N/A * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS * Eric Anholt <eric@anholt.net> * This file provides some of the base ioctls and library routines for * the graphics memory manager implemented by each device driver. * Because various devices have different requirements in terms of * synchronization and migration strategies, implementing that is left up to * the driver, and all that the general API provides should be generic -- * allocating objects, reading/writing data with the cpu, freeing objects. * Even there, platform-dependent optimizations for reading/writing data with * the CPU mean we'll likely hook those out to driver-specific calls. However, * the DRI2 implementation wants to have at least allocate/mmap be generic. * The goal was to have swap-backed object allocation managed through * struct file. However, file descriptors as handles to a struct file have * - Process limits prevent more than 1024 or so being used at a time by * - Inability to allocate high fds will aggravate the X Server's select() * handling, and likely that of many GL client applications as well. * This led to a plan of using our own integer IDs (called handles, following * DRM terminology) to mimic fds, and implement the fd syscalls we need as * ioctls. The objects themselves will still include the struct file so * that we can transition to fds if the required kernel infrastructure shows * up at a later date, and as our interface with shmfs for memory allocation. * We make up offsets for buffer objects so we can recognize them at /* memory pool is used for all platforms now */ * Initialize the GEM device fields 0xff000U,
/* dma_attr_addr_lo */ 0xffffffffU,
/* dma_attr_addr_hi */ 0xffffffffU,
/* dma_attr_count_max */ 4096,
/* dma_attr_align */ 0x1fffU,
/* dma_attr_burstsizes */ 1,
/* dma_attr_minxfer */ 0xffffffffU,
/* dma_attr_maxxfer */ 0xffffffffU,
/* dma_attr_seg */ 1,
/* dma_attr_sgllen, variable */ 4,
/* dma_attr_granular */ DRM_ERROR(
"ddi_dma_addr_bind_handle failed");
for (n = 0, i =
1; ; i++) {
/* Alloc GEM object by memory pool */ DRM_ERROR(
"Failed to alloc pages from memory pool");
DRM_ERROR(
"obj %p map incorrect 0x%lx != 0x%lx",
* Initialize an already allocate GEM object of the specified size with * Initialize an already allocated GEM object of the specified size with * no GEM provided backing store. Instead the caller is responsible for * backing the object and handling it. * Allocate a GEM object of the specified size with shmfs backing store /* Object_init mangles the global counters - readjust them. */ * Removes the mapping from handle to filp for this object. /* This is gross. The idr system doesn't let us try a delete and * return an error code. It just spews if you fail at deleting. * So, we have to grab a lock around finding the object and then * doing the delete on it and dropping the refcount, or the user * could race us to double-decrement the refcount and cause a * use-after-free later. Given the frequency of our handle lookups, * we may want to use ida for number allocation and a hash table * for the pointers, anyway. /* Check if we currently have a reference on the object */ /* Release reference and decrement refcount. */ * Create a handle for this object. This adds a handle reference * to the object, which includes a regular reference count. Callers * will likely want to dereference the object afterwards. * Get the user-visible handle using idr. /* ensure there is space available to allocate a handle */ /* do the allocation under our spinlock */ /** Returns a reference to the object named by the handle. */ /* Check if we currently have a reference on the object */ * Releases the handle to an mm object. * Create a global name for an object, returning the name. * Note that the name does not hold a reference; when the object * is freed, the name goes away. /* Allocate a reference for the name table. */ * Open an object using the global name, returning a handle and the size. * This handle (of course) holds a reference to the object, so the object * will not go away until the handle is deleted. * Called at device open time, sets up the structure for handling refcounting * Called at device close to release the file's * handle references on objects. * Called at close time when the filp is going away. * Releases any remaining references on objects by this filp. /* LINTED E_FUNC_ARG_UNUSED */ * Called after the last reference to the object has been lost. // BUG_ON(!mutex_is_locked(&dev->struct_mutex)); /* LINTED E_FUNC_ARG_UNUSED */ * Called after the last handle to the object has been closed * Removes any name for the object. Note that this must be * called before drm_gem_object_free or we'll be touching /* Remove any name for this object */ * The object name held a reference to this object, drop * This cannot be the last reference, since the handle holds one too. DRM_DEBUG(
"already freed, don't free more than once!");