2005-04-17 06:20:36 +08:00
|
|
|
/* i915_dma.c -- DMA support for the I915 -*- linux-c -*-
|
|
|
|
*/
|
2006-01-02 17:14:23 +08:00
|
|
|
/*
|
2005-04-17 06:20:36 +08:00
|
|
|
* Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
|
|
|
|
* All Rights Reserved.
|
2005-06-23 20:46:46 +08:00
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the
|
|
|
|
* "Software"), to deal in the Software without restriction, including
|
|
|
|
* without limitation the rights to use, copy, modify, merge, publish,
|
|
|
|
* distribute, sub license, and/or sell copies of the Software, and to
|
|
|
|
* permit persons to whom the Software is furnished to do so, subject to
|
|
|
|
* the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
* of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
|
|
|
|
* OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
|
|
|
|
* IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
|
|
|
|
* ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
|
|
|
|
* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
|
|
|
|
* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
|
|
|
*
|
2006-01-02 17:14:23 +08:00
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-03-19 04:00:11 +08:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2014-05-29 05:39:03 +08:00
|
|
|
#include <linux/async.h>
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/drmP.h>
|
|
|
|
#include <drm/drm_crtc_helper.h>
|
|
|
|
#include <drm/drm_fb_helper.h>
|
2014-09-10 18:43:49 +08:00
|
|
|
#include <drm/drm_legacy.h>
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
#include "intel_drv.h"
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/i915_drm.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include "i915_drv.h"
|
2009-08-25 18:15:50 +08:00
|
|
|
#include "i915_trace.h"
|
2010-05-28 03:40:25 +08:00
|
|
|
#include <linux/pci.h>
|
2014-06-05 22:20:46 +08:00
|
|
|
#include <linux/console.h>
|
|
|
|
#include <linux/vt.h>
|
2009-09-21 12:33:58 +08:00
|
|
|
#include <linux/vgaarb.h>
|
2009-12-17 14:48:43 +08:00
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/pnp.h>
|
2010-02-01 13:38:10 +08:00
|
|
|
#include <linux/vga_switcheroo.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2010-08-19 23:09:23 +08:00
|
|
|
#include <acpi/video.h>
|
2013-12-07 06:32:13 +08:00
|
|
|
#include <linux/pm.h>
|
|
|
|
#include <linux/pm_runtime.h>
|
2014-05-21 00:47:20 +08:00
|
|
|
#include <linux/oom.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
2007-09-03 10:06:45 +08:00
|
|
|
static int i915_getparam(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file_priv)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-03-31 19:27:15 +08:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2007-09-03 10:06:45 +08:00
|
|
|
drm_i915_getparam_t *param = data;
|
2005-04-17 06:20:36 +08:00
|
|
|
int value;
|
|
|
|
|
2007-09-03 10:06:45 +08:00
|
|
|
switch (param->param) {
|
2005-04-17 06:20:36 +08:00
|
|
|
case I915_PARAM_IRQ_ACTIVE:
|
|
|
|
case I915_PARAM_ALLOW_BATCHBUFFER:
|
2006-01-02 17:14:23 +08:00
|
|
|
case I915_PARAM_LAST_DISPATCH:
|
2014-11-20 04:24:54 +08:00
|
|
|
/* Reject all old ums/dri params. */
|
2014-09-06 17:28:27 +08:00
|
|
|
return -ENODEV;
|
2008-08-20 23:08:52 +08:00
|
|
|
case I915_PARAM_CHIPSET_ID:
|
2013-10-04 19:53:40 +08:00
|
|
|
value = dev->pdev->device;
|
2008-08-20 23:08:52 +08:00
|
|
|
break;
|
2008-07-31 03:06:12 +08:00
|
|
|
case I915_PARAM_HAS_GEM:
|
2012-04-23 22:50:51 +08:00
|
|
|
value = 1;
|
2008-07-31 03:06:12 +08:00
|
|
|
break;
|
2009-01-27 09:10:45 +08:00
|
|
|
case I915_PARAM_NUM_FENCES_AVAIL:
|
|
|
|
value = dev_priv->num_fence_regs - dev_priv->fence_reg_start;
|
|
|
|
break;
|
2009-09-16 04:57:34 +08:00
|
|
|
case I915_PARAM_HAS_OVERLAY:
|
|
|
|
value = dev_priv->overlay ? 1 : 0;
|
|
|
|
break;
|
2009-11-20 02:49:07 +08:00
|
|
|
case I915_PARAM_HAS_PAGEFLIPPING:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2009-12-18 11:05:42 +08:00
|
|
|
case I915_PARAM_HAS_EXECBUF2:
|
|
|
|
/* depends on GEM */
|
2012-04-23 22:50:51 +08:00
|
|
|
value = 1;
|
2009-12-18 11:05:42 +08:00
|
|
|
break;
|
2010-05-31 13:58:47 +08:00
|
|
|
case I915_PARAM_HAS_BSD:
|
2012-05-11 21:29:32 +08:00
|
|
|
value = intel_ring_initialized(&dev_priv->ring[VCS]);
|
2010-05-31 13:58:47 +08:00
|
|
|
break;
|
2010-10-19 18:19:32 +08:00
|
|
|
case I915_PARAM_HAS_BLT:
|
2012-05-11 21:29:32 +08:00
|
|
|
value = intel_ring_initialized(&dev_priv->ring[BCS]);
|
2010-10-19 18:19:32 +08:00
|
|
|
break;
|
2013-05-29 10:22:34 +08:00
|
|
|
case I915_PARAM_HAS_VEBOX:
|
|
|
|
value = intel_ring_initialized(&dev_priv->ring[VECS]);
|
|
|
|
break;
|
2010-09-25 04:15:47 +08:00
|
|
|
case I915_PARAM_HAS_RELAXED_FENCING:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2010-12-05 18:30:40 +08:00
|
|
|
case I915_PARAM_HAS_COHERENT_RINGS:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2010-12-19 19:42:05 +08:00
|
|
|
case I915_PARAM_HAS_EXEC_CONSTANTS:
|
|
|
|
value = INTEL_INFO(dev)->gen >= 4;
|
|
|
|
break;
|
2011-03-01 23:24:41 +08:00
|
|
|
case I915_PARAM_HAS_RELAXED_DELTA:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2012-01-04 01:23:29 +08:00
|
|
|
case I915_PARAM_HAS_GEN7_SOL_RESET:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2012-01-18 00:43:53 +08:00
|
|
|
case I915_PARAM_HAS_LLC:
|
|
|
|
value = HAS_LLC(dev);
|
|
|
|
break;
|
2013-08-08 21:41:10 +08:00
|
|
|
case I915_PARAM_HAS_WT:
|
|
|
|
value = HAS_WT(dev);
|
|
|
|
break;
|
2012-02-16 06:50:25 +08:00
|
|
|
case I915_PARAM_HAS_ALIASING_PPGTT:
|
2014-08-06 21:04:51 +08:00
|
|
|
value = USES_PPGTT(dev);
|
2012-02-16 06:50:25 +08:00
|
|
|
break;
|
2012-06-06 06:24:25 +08:00
|
|
|
case I915_PARAM_HAS_WAIT_TIMEOUT:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2012-08-08 17:23:22 +08:00
|
|
|
case I915_PARAM_HAS_SEMAPHORES:
|
|
|
|
value = i915_semaphore_is_enabled(dev);
|
|
|
|
break;
|
2012-08-16 08:15:34 +08:00
|
|
|
case I915_PARAM_HAS_PRIME_VMAP_FLUSH:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2012-10-17 19:09:54 +08:00
|
|
|
case I915_PARAM_HAS_SECURE_BATCHES:
|
|
|
|
value = capable(CAP_SYS_ADMIN);
|
|
|
|
break;
|
2012-12-17 23:21:27 +08:00
|
|
|
case I915_PARAM_HAS_PINNED_BATCHES:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2013-01-18 05:23:36 +08:00
|
|
|
case I915_PARAM_HAS_EXEC_NO_RELOC:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2013-01-08 18:53:17 +08:00
|
|
|
case I915_PARAM_HAS_EXEC_HANDLE_LUT:
|
|
|
|
value = 1;
|
|
|
|
break;
|
2014-02-19 02:15:56 +08:00
|
|
|
case I915_PARAM_CMD_PARSER_VERSION:
|
|
|
|
value = i915_cmd_parser_get_version();
|
|
|
|
break;
|
2014-11-04 20:51:40 +08:00
|
|
|
case I915_PARAM_HAS_COHERENT_PHYS_GTT:
|
|
|
|
value = 1;
|
drm/i915: Support creation of unbound wc user mappings for objects
This patch provides support to create write-combining virtual mappings of
GEM object. It intends to provide the same funtionality of 'mmap_gtt'
interface without the constraints and contention of a limited aperture
space, but requires clients handles the linear to tile conversion on their
own. This is for improving the CPU write operation performance, as with such
mapping, writes and reads are almost 50% faster than with mmap_gtt. Similar
to the GTT mmapping, unlike the regular CPU mmapping, it avoids the cache
flush after update from CPU side, when object is passed onto GPU. This
type of mapping is specially useful in case of sub-region update,
i.e. when only a portion of the object is to be updated. Using a CPU mmap
in such cases would normally incur a clflush of the whole object, and
using a GTT mmapping would likely require eviction of an active object or
fence and thus stall. The write-combining CPU mmap avoids both.
To ensure the cache coherency, before using this mapping, the GTT domain
has been reused here. This provides the required cache flush if the object
is in CPU domain or synchronization against the concurrent rendering.
Although the access through an uncached mmap should automatically
invalidate the cache lines, this may not be true for non-temporal write
instructions and also not all pages of the object may be updated at any
given point of time through this mapping. Having a call to get_pages in
set_to_gtt_domain function, as added in the earlier patch 'drm/i915:
Broaden application of set-domain(GTT)', would guarantee the clflush and
so there will be no cachelines holding the data for the object before it
is accessed through this map.
The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has been
extended with a new flags field (defaulting to 0 for existent users). In
order for userspace to detect the extended ioctl, a new parameter
I915_PARAM_MMAP_VERSION has been added for versioning the ioctl interface.
v2: Fix error handling, invalid flag detection, renaming (ickle)
v3: Rebase to latest drm-intel-nightly codebase
The new mmapping is exercised by igt/gem_mmap_wc,
igt/gem_concurrent_blit and igt/gem_gtt_speed.
Change-Id: Ie883942f9e689525f72fe9a8d3780c3a9faa769a
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-02 18:59:30 +08:00
|
|
|
break;
|
|
|
|
case I915_PARAM_MMAP_VERSION:
|
|
|
|
value = 1;
|
2014-11-04 20:51:40 +08:00
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
default:
|
2013-06-01 02:28:45 +08:00
|
|
|
DRM_DEBUG("Unknown parameter %d\n", param->param);
|
2007-08-25 17:22:43 +08:00
|
|
|
return -EINVAL;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-12-11 18:34:44 +08:00
|
|
|
if (copy_to_user(param->value, &value, sizeof(int))) {
|
|
|
|
DRM_ERROR("copy_to_user failed\n");
|
2007-08-25 17:22:43 +08:00
|
|
|
return -EFAULT;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-09-03 10:06:45 +08:00
|
|
|
static int i915_setparam(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file_priv)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-03-31 19:27:15 +08:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2007-09-03 10:06:45 +08:00
|
|
|
drm_i915_setparam_t *param = data;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-09-03 10:06:45 +08:00
|
|
|
switch (param->param) {
|
2005-04-17 06:20:36 +08:00
|
|
|
case I915_SETPARAM_USE_MI_BATCHBUFFER_START:
|
|
|
|
case I915_SETPARAM_TEX_LRU_LOG_GRANULARITY:
|
|
|
|
case I915_SETPARAM_ALLOW_BATCHBUFFER:
|
2014-11-20 04:24:54 +08:00
|
|
|
/* Reject all old ums/dri params. */
|
2014-09-06 17:28:27 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
2009-01-27 09:10:45 +08:00
|
|
|
case I915_SETPARAM_NUM_USED_FENCES:
|
|
|
|
if (param->value > dev_priv->num_fence_regs ||
|
|
|
|
param->value < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
/* Userspace can use first N regs */
|
|
|
|
dev_priv->fence_reg_start = param->value;
|
|
|
|
break;
|
2005-04-17 06:20:36 +08:00
|
|
|
default:
|
2009-07-20 13:48:04 +08:00
|
|
|
DRM_DEBUG_DRIVER("unknown parameter %d\n",
|
2009-06-02 14:13:55 +08:00
|
|
|
param->param);
|
2007-08-25 17:22:43 +08:00
|
|
|
return -EINVAL;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-08-04 09:43:41 +08:00
|
|
|
static int i915_get_bridge_dev(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
|
2011-08-17 03:34:10 +08:00
|
|
|
dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
|
2009-08-04 09:43:41 +08:00
|
|
|
if (!dev_priv->bridge_dev) {
|
|
|
|
DRM_ERROR("bridge device not found\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-17 14:48:43 +08:00
|
|
|
#define MCHBAR_I915 0x44
|
|
|
|
#define MCHBAR_I965 0x48
|
|
|
|
#define MCHBAR_SIZE (4*4096)
|
|
|
|
|
|
|
|
#define DEVEN_REG 0x54
|
|
|
|
#define DEVEN_MCHBAR_EN (1 << 28)
|
|
|
|
|
|
|
|
/* Allocate space for the MCH regs if needed, return nonzero on error */
|
|
|
|
static int
|
|
|
|
intel_alloc_mchbar_resource(struct drm_device *dev)
|
|
|
|
{
|
2014-03-31 19:27:15 +08:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-09-17 07:32:17 +08:00
|
|
|
int reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
|
2009-12-17 14:48:43 +08:00
|
|
|
u32 temp_lo, temp_hi = 0;
|
|
|
|
u64 mchbar_addr;
|
2010-08-20 21:36:45 +08:00
|
|
|
int ret;
|
2009-12-17 14:48:43 +08:00
|
|
|
|
2010-09-17 07:32:17 +08:00
|
|
|
if (INTEL_INFO(dev)->gen >= 4)
|
2009-12-17 14:48:43 +08:00
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, reg + 4, &temp_hi);
|
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, reg, &temp_lo);
|
|
|
|
mchbar_addr = ((u64)temp_hi << 32) | temp_lo;
|
|
|
|
|
|
|
|
/* If ACPI doesn't have it, assume we need to allocate it ourselves */
|
|
|
|
#ifdef CONFIG_PNP
|
|
|
|
if (mchbar_addr &&
|
2010-08-20 21:36:45 +08:00
|
|
|
pnp_range_reserved(mchbar_addr, mchbar_addr + MCHBAR_SIZE))
|
|
|
|
return 0;
|
2009-12-17 14:48:43 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
/* Get some space for it */
|
2010-08-20 21:36:45 +08:00
|
|
|
dev_priv->mch_res.name = "i915 MCHBAR";
|
|
|
|
dev_priv->mch_res.flags = IORESOURCE_MEM;
|
|
|
|
ret = pci_bus_alloc_resource(dev_priv->bridge_dev->bus,
|
|
|
|
&dev_priv->mch_res,
|
2009-12-17 14:48:43 +08:00
|
|
|
MCHBAR_SIZE, MCHBAR_SIZE,
|
|
|
|
PCIBIOS_MIN_MEM,
|
2010-08-20 21:36:45 +08:00
|
|
|
0, pcibios_align_resource,
|
2009-12-17 14:48:43 +08:00
|
|
|
dev_priv->bridge_dev);
|
|
|
|
if (ret) {
|
|
|
|
DRM_DEBUG_DRIVER("failed bus alloc: %d\n", ret);
|
|
|
|
dev_priv->mch_res.start = 0;
|
2010-08-20 21:36:45 +08:00
|
|
|
return ret;
|
2009-12-17 14:48:43 +08:00
|
|
|
}
|
|
|
|
|
2010-09-17 07:32:17 +08:00
|
|
|
if (INTEL_INFO(dev)->gen >= 4)
|
2009-12-17 14:48:43 +08:00
|
|
|
pci_write_config_dword(dev_priv->bridge_dev, reg + 4,
|
|
|
|
upper_32_bits(dev_priv->mch_res.start));
|
|
|
|
|
|
|
|
pci_write_config_dword(dev_priv->bridge_dev, reg,
|
|
|
|
lower_32_bits(dev_priv->mch_res.start));
|
2010-08-20 21:36:45 +08:00
|
|
|
return 0;
|
2009-12-17 14:48:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Setup MCHBAR if possible, return true if we should disable it again */
|
|
|
|
static void
|
|
|
|
intel_setup_mchbar(struct drm_device *dev)
|
|
|
|
{
|
2014-03-31 19:27:15 +08:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-09-17 07:32:17 +08:00
|
|
|
int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
|
2009-12-17 14:48:43 +08:00
|
|
|
u32 temp;
|
|
|
|
bool enabled;
|
|
|
|
|
2014-03-04 06:27:57 +08:00
|
|
|
if (IS_VALLEYVIEW(dev))
|
|
|
|
return;
|
|
|
|
|
2009-12-17 14:48:43 +08:00
|
|
|
dev_priv->mchbar_need_disable = false;
|
|
|
|
|
|
|
|
if (IS_I915G(dev) || IS_I915GM(dev)) {
|
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
|
|
|
|
enabled = !!(temp & DEVEN_MCHBAR_EN);
|
|
|
|
} else {
|
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
|
|
|
|
enabled = temp & 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If it's already enabled, don't have to do anything */
|
|
|
|
if (enabled)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (intel_alloc_mchbar_resource(dev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
dev_priv->mchbar_need_disable = true;
|
|
|
|
|
|
|
|
/* Space is allocated or reserved, so enable it. */
|
|
|
|
if (IS_I915G(dev) || IS_I915GM(dev)) {
|
|
|
|
pci_write_config_dword(dev_priv->bridge_dev, DEVEN_REG,
|
|
|
|
temp | DEVEN_MCHBAR_EN);
|
|
|
|
} else {
|
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
|
|
|
|
pci_write_config_dword(dev_priv->bridge_dev, mchbar_reg, temp | 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
intel_teardown_mchbar(struct drm_device *dev)
|
|
|
|
{
|
2014-03-31 19:27:15 +08:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-09-17 07:32:17 +08:00
|
|
|
int mchbar_reg = INTEL_INFO(dev)->gen >= 4 ? MCHBAR_I965 : MCHBAR_I915;
|
2009-12-17 14:48:43 +08:00
|
|
|
u32 temp;
|
|
|
|
|
|
|
|
if (dev_priv->mchbar_need_disable) {
|
|
|
|
if (IS_I915G(dev) || IS_I915GM(dev)) {
|
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, DEVEN_REG, &temp);
|
|
|
|
temp &= ~DEVEN_MCHBAR_EN;
|
|
|
|
pci_write_config_dword(dev_priv->bridge_dev, DEVEN_REG, temp);
|
|
|
|
} else {
|
|
|
|
pci_read_config_dword(dev_priv->bridge_dev, mchbar_reg, &temp);
|
|
|
|
temp &= ~1;
|
|
|
|
pci_write_config_dword(dev_priv->bridge_dev, mchbar_reg, temp);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dev_priv->mch_res.start)
|
|
|
|
release_resource(&dev_priv->mch_res);
|
|
|
|
}
|
|
|
|
|
2009-09-21 12:33:58 +08:00
|
|
|
/* true = enable decode, false = disable decoder */
|
|
|
|
static unsigned int i915_vga_set_decode(void *cookie, bool state)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = cookie;
|
|
|
|
|
|
|
|
intel_modeset_vga_set_state(dev, state);
|
|
|
|
if (state)
|
|
|
|
return VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM |
|
|
|
|
VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
|
|
|
|
else
|
|
|
|
return VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM;
|
|
|
|
}
|
|
|
|
|
2010-02-01 13:38:10 +08:00
|
|
|
static void i915_switcheroo_set_state(struct pci_dev *pdev, enum vga_switcheroo_state state)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = pci_get_drvdata(pdev);
|
|
|
|
pm_message_t pmm = { .event = PM_EVENT_SUSPEND };
|
2014-06-02 22:59:39 +08:00
|
|
|
|
2010-02-01 13:38:10 +08:00
|
|
|
if (state == VGA_SWITCHEROO_ON) {
|
2012-03-19 04:00:11 +08:00
|
|
|
pr_info("switched on\n");
|
2010-12-07 07:20:40 +08:00
|
|
|
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
|
2010-02-01 13:38:10 +08:00
|
|
|
/* i915 resume handler doesn't set to D0 */
|
|
|
|
pci_set_power_state(dev->pdev, PCI_D0);
|
2014-10-24 00:23:27 +08:00
|
|
|
i915_resume_legacy(dev);
|
2010-12-07 07:20:40 +08:00
|
|
|
dev->switch_power_state = DRM_SWITCH_POWER_ON;
|
2010-02-01 13:38:10 +08:00
|
|
|
} else {
|
2012-03-19 04:00:11 +08:00
|
|
|
pr_err("switched off\n");
|
2010-12-07 07:20:40 +08:00
|
|
|
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
|
2014-10-24 00:23:27 +08:00
|
|
|
i915_suspend_legacy(dev, pmm);
|
2010-12-07 07:20:40 +08:00
|
|
|
dev->switch_power_state = DRM_SWITCH_POWER_OFF;
|
2010-02-01 13:38:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = pci_get_drvdata(pdev);
|
|
|
|
|
2013-11-04 03:46:34 +08:00
|
|
|
/*
|
|
|
|
* FIXME: open_count is protected by drm_global_mutex but that would lead to
|
|
|
|
* locking inversion with the driver load path. And the access here is
|
|
|
|
* completely racy anyway. So don't bother with locking for now.
|
|
|
|
*/
|
|
|
|
return dev->open_count == 0;
|
2010-02-01 13:38:10 +08:00
|
|
|
}
|
|
|
|
|
2012-05-11 13:51:17 +08:00
|
|
|
static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
|
|
|
|
.set_gpu_state = i915_switcheroo_set_state,
|
|
|
|
.reprobe = NULL,
|
|
|
|
.can_switch = i915_switcheroo_can_switch,
|
|
|
|
};
|
|
|
|
|
2011-03-29 17:40:27 +08:00
|
|
|
static int i915_load_modeset_init(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int ret;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
|
2010-10-14 16:14:51 +08:00
|
|
|
ret = intel_parse_bios(dev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
if (ret)
|
|
|
|
DRM_INFO("failed to find VBIOS tables\n");
|
|
|
|
|
2011-01-20 21:09:12 +08:00
|
|
|
/* If we have > 1 VGA cards, then we need to arbitrate access
|
|
|
|
* to the common VGA resources.
|
|
|
|
*
|
|
|
|
* If we are a secondary display controller (!PCI_DISPLAY_CLASS_VGA),
|
|
|
|
* then we do not take part in VGA arbitration and the
|
|
|
|
* vga_client_register() fails with -ENODEV.
|
|
|
|
*/
|
2013-10-11 13:12:04 +08:00
|
|
|
ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
|
|
|
|
if (ret && ret != -ENODEV)
|
|
|
|
goto out;
|
2009-09-21 12:33:58 +08:00
|
|
|
|
2010-10-08 07:01:13 +08:00
|
|
|
intel_register_dsm_handler();
|
|
|
|
|
2012-09-10 10:28:36 +08:00
|
|
|
ret = vga_switcheroo_register_client(dev->pdev, &i915_switcheroo_ops, false);
|
2010-02-01 13:38:10 +08:00
|
|
|
if (ret)
|
2010-06-06 17:50:03 +08:00
|
|
|
goto cleanup_vga_client;
|
2010-02-01 13:38:10 +08:00
|
|
|
|
2012-04-24 22:47:39 +08:00
|
|
|
/* Initialise stolen first so that we may reserve preallocated
|
|
|
|
* objects for the BIOS to KMS transition.
|
|
|
|
*/
|
|
|
|
ret = i915_gem_init_stolen(dev);
|
|
|
|
if (ret)
|
|
|
|
goto cleanup_vga_switcheroo;
|
|
|
|
|
2014-02-18 06:02:15 +08:00
|
|
|
intel_power_domains_init_hw(dev_priv);
|
|
|
|
|
2014-09-30 16:56:43 +08:00
|
|
|
ret = intel_irq_install(dev_priv);
|
2012-12-02 04:03:22 +08:00
|
|
|
if (ret)
|
|
|
|
goto cleanup_gem_stolen;
|
|
|
|
|
|
|
|
/* Important: The output setup functions called by modeset_init need
|
|
|
|
* working irqs for e.g. gmbus and dp aux transfers. */
|
2009-12-12 03:07:17 +08:00
|
|
|
intel_modeset_init(dev);
|
|
|
|
|
2012-04-24 22:47:41 +08:00
|
|
|
ret = i915_gem_init(dev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
if (ret)
|
2014-04-25 22:28:00 +08:00
|
|
|
goto cleanup_irq;
|
2011-03-29 17:40:27 +08:00
|
|
|
|
2012-12-02 04:03:22 +08:00
|
|
|
intel_modeset_gem_init(dev);
|
2011-03-29 17:40:27 +08:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
/* Always safe in the mode setting case. */
|
|
|
|
/* FIXME: do pre/post-mode set stuff in core KMS code */
|
2013-10-04 19:53:33 +08:00
|
|
|
dev->vblank_disable_allowed = true;
|
2014-04-25 22:28:00 +08:00
|
|
|
if (INTEL_INFO(dev)->num_pipes == 0)
|
2013-04-06 04:12:39 +08:00
|
|
|
return 0;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
|
2010-06-06 17:50:03 +08:00
|
|
|
ret = intel_fbdev_init(dev);
|
|
|
|
if (ret)
|
2012-12-02 04:03:22 +08:00
|
|
|
goto cleanup_gem;
|
|
|
|
|
2012-12-11 21:05:07 +08:00
|
|
|
/* Only enable hotplug handling once the fbdev is fully set up. */
|
2014-09-30 16:56:44 +08:00
|
|
|
intel_hpd_init(dev_priv);
|
2012-12-11 21:05:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Some ports require correctly set-up hpd registers for detection to
|
|
|
|
* work properly (leading to ghost connected connector status), e.g. VGA
|
|
|
|
* on gm45. Hence we can only set up the initial fbdev config after hpd
|
|
|
|
* irqs are fully enabled. Now we should scan for the initial config
|
|
|
|
* only once hotplug handling is enabled, but due to screwed-up locking
|
|
|
|
* around kms/fbdev init we can't protect the fdbev initial config
|
|
|
|
* scanning against hotplug events. Hence do this first and ignore the
|
|
|
|
* tiny window where we will loose hotplug notifactions.
|
|
|
|
*/
|
2014-05-29 05:39:03 +08:00
|
|
|
async_schedule(intel_fbdev_initial_config, dev_priv);
|
2012-12-11 21:05:07 +08:00
|
|
|
|
2010-05-07 14:42:51 +08:00
|
|
|
drm_kms_helper_poll_init(dev);
|
2010-10-19 17:13:00 +08:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
return 0;
|
|
|
|
|
2011-03-29 17:40:27 +08:00
|
|
|
cleanup_gem:
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
i915_gem_cleanup_ringbuffer(dev);
|
2013-05-26 03:26:39 +08:00
|
|
|
i915_gem_context_fini(dev);
|
2011-03-29 17:40:27 +08:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2014-04-25 22:28:00 +08:00
|
|
|
cleanup_irq:
|
2012-12-02 04:03:22 +08:00
|
|
|
drm_irq_uninstall(dev);
|
2012-04-24 22:47:39 +08:00
|
|
|
cleanup_gem_stolen:
|
|
|
|
i915_gem_cleanup_stolen(dev);
|
2010-06-06 17:50:03 +08:00
|
|
|
cleanup_vga_switcheroo:
|
|
|
|
vga_switcheroo_unregister_client(dev->pdev);
|
|
|
|
cleanup_vga_client:
|
|
|
|
vga_client_register(dev->pdev, NULL, NULL, NULL);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
out:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-12-17 17:00:54 +08:00
|
|
|
#if IS_ENABLED(CONFIG_FB)
|
2013-12-16 23:57:40 +08:00
|
|
|
static int i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
|
2012-06-12 17:28:17 +08:00
|
|
|
{
|
|
|
|
struct apertures_struct *ap;
|
|
|
|
struct pci_dev *pdev = dev_priv->dev->pdev;
|
|
|
|
bool primary;
|
2013-12-16 23:57:40 +08:00
|
|
|
int ret;
|
2012-06-12 17:28:17 +08:00
|
|
|
|
|
|
|
ap = alloc_apertures(1);
|
|
|
|
if (!ap)
|
2013-12-16 23:57:40 +08:00
|
|
|
return -ENOMEM;
|
2012-06-12 17:28:17 +08:00
|
|
|
|
2013-01-18 04:45:16 +08:00
|
|
|
ap->ranges[0].base = dev_priv->gtt.mappable_base;
|
2013-05-26 03:26:36 +08:00
|
|
|
ap->ranges[0].size = dev_priv->gtt.mappable_end;
|
2013-01-18 04:45:17 +08:00
|
|
|
|
2012-06-12 17:28:17 +08:00
|
|
|
primary =
|
|
|
|
pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
|
|
|
|
|
2013-12-16 23:57:40 +08:00
|
|
|
ret = remove_conflicting_framebuffers(ap, "inteldrmfb", primary);
|
2012-06-12 17:28:17 +08:00
|
|
|
|
|
|
|
kfree(ap);
|
2013-12-16 23:57:40 +08:00
|
|
|
|
|
|
|
return ret;
|
2012-06-12 17:28:17 +08:00
|
|
|
}
|
2013-10-09 15:18:51 +08:00
|
|
|
#else
|
2013-12-16 23:57:40 +08:00
|
|
|
static int i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
|
2013-10-09 15:18:51 +08:00
|
|
|
{
|
2013-12-16 23:57:40 +08:00
|
|
|
return 0;
|
2013-10-09 15:18:51 +08:00
|
|
|
}
|
|
|
|
#endif
|
2012-06-12 17:28:17 +08:00
|
|
|
|
2014-06-05 22:20:46 +08:00
|
|
|
#if !defined(CONFIG_VGA_CONSOLE)
|
|
|
|
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#elif !defined(CONFIG_DUMMY_CONSOLE)
|
|
|
|
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2014-07-08 16:02:43 +08:00
|
|
|
int ret = 0;
|
2014-06-05 22:20:46 +08:00
|
|
|
|
|
|
|
DRM_INFO("Replacing VGA console driver\n");
|
|
|
|
|
|
|
|
console_lock();
|
2014-07-08 16:02:43 +08:00
|
|
|
if (con_is_bound(&vga_con))
|
|
|
|
ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
|
2014-06-05 22:20:46 +08:00
|
|
|
if (ret == 0) {
|
|
|
|
ret = do_unregister_con_driver(&vga_con);
|
|
|
|
|
|
|
|
/* Ignore "already unregistered". */
|
|
|
|
if (ret == -ENODEV)
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
console_unlock();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2012-08-09 04:01:51 +08:00
|
|
|
static void i915_dump_device_info(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
2014-02-08 03:12:48 +08:00
|
|
|
const struct intel_device_info *info = &dev_priv->info;
|
2012-08-09 04:01:51 +08:00
|
|
|
|
2013-04-23 23:38:34 +08:00
|
|
|
#define PRINT_S(name) "%s"
|
|
|
|
#define SEP_EMPTY
|
2013-04-23 23:37:17 +08:00
|
|
|
#define PRINT_FLAG(name) info->name ? #name "," : ""
|
|
|
|
#define SEP_COMMA ,
|
2014-06-13 20:39:56 +08:00
|
|
|
DRM_DEBUG_DRIVER("i915 device info: gen=%i, pciid=0x%04x rev=0x%02x flags="
|
2013-04-23 23:38:34 +08:00
|
|
|
DEV_INFO_FOR_EACH_FLAG(PRINT_S, SEP_EMPTY),
|
2012-08-09 04:01:51 +08:00
|
|
|
info->gen,
|
|
|
|
dev_priv->dev->pdev->device,
|
2014-06-13 20:39:56 +08:00
|
|
|
dev_priv->dev->pdev->revision,
|
2013-04-23 23:37:17 +08:00
|
|
|
DEV_INFO_FOR_EACH_FLAG(PRINT_FLAG, SEP_COMMA));
|
2013-04-23 23:38:34 +08:00
|
|
|
#undef PRINT_S
|
|
|
|
#undef SEP_EMPTY
|
2013-04-23 23:37:17 +08:00
|
|
|
#undef PRINT_FLAG
|
|
|
|
#undef SEP_COMMA
|
2012-08-09 04:01:51 +08:00
|
|
|
}
|
|
|
|
|
2014-02-08 03:12:49 +08:00
|
|
|
/*
|
|
|
|
* Determine various intel_device_info fields at runtime.
|
|
|
|
*
|
|
|
|
* Use it when either:
|
|
|
|
* - it's judged too laborious to fill n static structures with the limit
|
|
|
|
* when a simple if statement does the job,
|
|
|
|
* - run-time checks (eg read fuse/strap registers) are needed.
|
2014-02-11 01:19:45 +08:00
|
|
|
*
|
|
|
|
* This function needs to be called:
|
|
|
|
* - after the MMIO has been setup as we are reading registers,
|
|
|
|
* - after the PCH has been detected,
|
|
|
|
* - before the first usage of the fields it can tweak.
|
2014-02-08 03:12:49 +08:00
|
|
|
*/
|
|
|
|
static void intel_device_info_runtime_init(struct drm_device *dev)
|
|
|
|
{
|
2014-02-11 01:19:45 +08:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2014-02-08 03:12:49 +08:00
|
|
|
struct intel_device_info *info;
|
2014-03-04 01:31:48 +08:00
|
|
|
enum pipe pipe;
|
2014-02-08 03:12:49 +08:00
|
|
|
|
2014-02-11 01:19:45 +08:00
|
|
|
info = (struct intel_device_info *)&dev_priv->info;
|
2014-02-08 03:12:49 +08:00
|
|
|
|
2014-02-13 03:13:31 +08:00
|
|
|
if (IS_VALLEYVIEW(dev) || INTEL_INFO(dev)->gen == 9)
|
2014-08-18 20:49:10 +08:00
|
|
|
for_each_pipe(dev_priv, pipe)
|
2014-03-04 01:31:48 +08:00
|
|
|
info->num_sprites[pipe] = 2;
|
|
|
|
else
|
2014-08-18 20:49:10 +08:00
|
|
|
for_each_pipe(dev_priv, pipe)
|
2014-03-04 01:31:48 +08:00
|
|
|
info->num_sprites[pipe] = 1;
|
2014-02-11 01:19:45 +08:00
|
|
|
|
2014-02-11 01:20:55 +08:00
|
|
|
if (i915.disable_display) {
|
|
|
|
DRM_INFO("Display disabled (module parameter)\n");
|
|
|
|
info->num_pipes = 0;
|
|
|
|
} else if (info->num_pipes > 0 &&
|
|
|
|
(INTEL_INFO(dev)->gen == 7 || INTEL_INFO(dev)->gen == 8) &&
|
|
|
|
!IS_VALLEYVIEW(dev)) {
|
2014-02-11 01:19:45 +08:00
|
|
|
u32 fuse_strap = I915_READ(FUSE_STRAP);
|
|
|
|
u32 sfuse_strap = I915_READ(SFUSE_STRAP);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SFUSE_STRAP is supposed to have a bit signalling the display
|
|
|
|
* is fused off. Unfortunately it seems that, at least in
|
|
|
|
* certain cases, fused off display means that PCH display
|
|
|
|
* reads don't land anywhere. In that case, we read 0s.
|
|
|
|
*
|
|
|
|
* On CPT/PPT, we can detect this case as SFUSE_STRAP_FUSE_LOCK
|
|
|
|
* should be set when taking over after the firmware.
|
|
|
|
*/
|
|
|
|
if (fuse_strap & ILK_INTERNAL_DISPLAY_DISABLE ||
|
|
|
|
sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
|
|
|
|
(dev_priv->pch_type == PCH_CPT &&
|
|
|
|
!(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
|
|
|
|
DRM_INFO("Display fused off, disabling\n");
|
|
|
|
info->num_pipes = 0;
|
|
|
|
}
|
|
|
|
}
|
2014-02-08 03:12:49 +08:00
|
|
|
}
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
/**
|
|
|
|
* i915_driver_load - setup chip and create an initial config
|
|
|
|
* @dev: DRM device
|
|
|
|
* @flags: startup flags
|
|
|
|
*
|
|
|
|
* The driver load routine has to do several things:
|
|
|
|
* - drive output discovery via intel_modeset_init()
|
|
|
|
* - initialize the memory manager
|
|
|
|
* - allocate initial config memory
|
|
|
|
* - setup the DRM framebuffer with the allocated memory
|
|
|
|
*/
|
2007-07-11 13:53:27 +08:00
|
|
|
int i915_driver_load(struct drm_device *dev, unsigned long flags)
|
2005-11-10 19:16:34 +08:00
|
|
|
{
|
2010-04-09 03:41:59 +08:00
|
|
|
struct drm_i915_private *dev_priv;
|
2014-02-08 03:12:48 +08:00
|
|
|
struct intel_device_info *info, *device_info;
|
2012-09-14 18:57:46 +08:00
|
|
|
int ret = 0, mmio_bar, mmio_size;
|
2012-03-26 15:45:41 +08:00
|
|
|
uint32_t aperture_size;
|
2010-11-23 20:09:30 +08:00
|
|
|
|
2012-03-27 03:33:18 +08:00
|
|
|
info = (struct intel_device_info *) flags;
|
|
|
|
|
|
|
|
/* Refuse to load on gen6+ without kms enabled. */
|
2013-10-10 20:25:37 +08:00
|
|
|
if (info->gen >= 6 && !drm_core_check_feature(dev, DRIVER_MODESET)) {
|
|
|
|
DRM_INFO("Your hardware requires kernel modesetting (KMS)\n");
|
|
|
|
DRM_INFO("See CONFIG_DRM_I915_KMS, nomodeset, and i915.modeset parameters\n");
|
2012-03-27 03:33:18 +08:00
|
|
|
return -ENODEV;
|
2013-10-10 20:25:37 +08:00
|
|
|
}
|
2012-03-27 03:33:18 +08:00
|
|
|
|
2013-12-11 18:34:33 +08:00
|
|
|
/* UMS needs agp support. */
|
|
|
|
if (!drm_core_check_feature(dev, DRIVER_MODESET) && !dev->agp)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-09-19 18:18:32 +08:00
|
|
|
dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
|
2007-11-22 12:14:14 +08:00
|
|
|
if (dev_priv == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2014-07-10 21:52:43 +08:00
|
|
|
dev->dev_private = dev_priv;
|
2008-07-31 03:06:12 +08:00
|
|
|
dev_priv->dev = dev;
|
2014-02-08 03:12:48 +08:00
|
|
|
|
2014-08-10 02:18:42 +08:00
|
|
|
/* Setup the write-once "constant" device info */
|
2014-02-08 03:12:48 +08:00
|
|
|
device_info = (struct intel_device_info *)&dev_priv->info;
|
2014-08-10 02:18:42 +08:00
|
|
|
memcpy(device_info, info, sizeof(dev_priv->info));
|
|
|
|
device_info->device_id = dev->pdev->device;
|
2007-11-22 12:14:14 +08:00
|
|
|
|
2013-07-17 14:22:58 +08:00
|
|
|
spin_lock_init(&dev_priv->irq_lock);
|
|
|
|
spin_lock_init(&dev_priv->gpu_error.lock);
|
2014-09-15 20:35:09 +08:00
|
|
|
mutex_init(&dev_priv->backlight_lock);
|
2013-07-20 03:36:52 +08:00
|
|
|
spin_lock_init(&dev_priv->uncore.lock);
|
2013-07-25 04:40:23 +08:00
|
|
|
spin_lock_init(&dev_priv->mm.object_stat_lock);
|
drm/i915: Replaced Blitter ring based flips with MMIO flips
This patch enables the framework for using MMIO based flip calls,
in contrast with the CS based flip calls which are being used currently.
MMIO based flip calls can be enabled on architectures where
Render and Blitter engines reside in different power wells. The
decision to use MMIO flips can be made based on workloads to give
100% residency for Media power well.
v2: The MMIO flips now use the interrupt driven mechanism for issuing the
flips when target seqno is reached. (Incorporating Ville's idea)
v3: Rebasing on latest code. Code restructuring after incorporating
Damien's comments
v4: Addressing Ville's review comments
-general cleanup
-updating only base addr instead of calling update_primary_plane
-extending patch for gen5+ platforms
v5: Addressed Ville's review comments
-Making mmio flip vs cs flip selection based on module parameter
-Adding check for DRIVER_MODESET feature in notify_ring before calling
notify mmio flip.
-Other changes mostly in function arguments
v6: -Having a seperate function to check condition for using mmio flips (Ville)
-propogating error code from i915_gem_check_olr (Ville)
v7: -Adding __must_check with i915_gem_check_olr (Chris)
-Renaming mmio_flip_data to mmio_flip (Chris)
-Rebasing on latest nightly
v8: -Rebasing on latest code
-squash 3rd patch in series(mmio setbase vs page flip race) with this patch
-Added new tiling mode update in intel_do_mmio_flip (Chris)
v9: -check for obj->last_write_seqno being 0 instead of obj->ring being NULL in
intel_postpone_flip, as this is a more restrictive condition (Chris)
v10: -Applied Chris's suggestions for squashing patches 2,3 into this patch.
These patches make the selection of CS vs MMIO flip at the page flip time, and
make the module parameter for using mmio flips as tristate, the states being
'force CS flips', 'force mmio flips', 'driver discretion'.
Changed the logic for driver discretion (Chris)
v11: Minor code cleanup(better readability, fixing whitespace errors, using
lockdep to check mutex locked status in postpone_flip, removal of __must_check
in function definition) (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # snb, ivb
[danvet: Fix up parameter alignement checkpatch spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-02 19:17:17 +08:00
|
|
|
spin_lock_init(&dev_priv->mmio_flip_lock);
|
2013-07-17 14:22:58 +08:00
|
|
|
mutex_init(&dev_priv->dpio_lock);
|
|
|
|
mutex_init(&dev_priv->modeset_restore_lock);
|
|
|
|
|
2013-12-06 17:17:53 +08:00
|
|
|
intel_pm_setup(dev);
|
2013-08-20 00:18:09 +08:00
|
|
|
|
2013-10-16 01:55:40 +08:00
|
|
|
intel_display_crc_init(dev);
|
|
|
|
|
2012-08-09 04:01:51 +08:00
|
|
|
i915_dump_device_info(dev_priv);
|
|
|
|
|
2013-08-13 01:34:08 +08:00
|
|
|
/* Not all pre-production machines fall into this category, only the
|
|
|
|
* very first ones. Almost everything should work, except for maybe
|
|
|
|
* suspend/resume. And we don't implement workarounds that affect only
|
|
|
|
* pre-production machines. */
|
|
|
|
if (IS_HSW_EARLY_SDV(dev))
|
|
|
|
DRM_INFO("This is an early pre-production Haswell machine. "
|
|
|
|
"It may not be fully functional.\n");
|
|
|
|
|
2009-08-04 09:43:41 +08:00
|
|
|
if (i915_get_bridge_dev(dev)) {
|
|
|
|
ret = -EIO;
|
|
|
|
goto free_priv;
|
|
|
|
}
|
|
|
|
|
2013-04-09 09:43:49 +08:00
|
|
|
mmio_bar = IS_GEN2(dev) ? 1 : 0;
|
|
|
|
/* Before gen4, the registers and the GTT are behind different BARs.
|
|
|
|
* However, from gen4 onwards, the registers and the GTT are shared
|
|
|
|
* in the same BAR, so we want to restrict this ioremap from
|
|
|
|
* clobbering the GTT which we want ioremap_wc instead. Fortunately,
|
|
|
|
* the register BAR remains the same size for all the earlier
|
|
|
|
* generations up to Ironlake.
|
|
|
|
*/
|
|
|
|
if (info->gen < 5)
|
|
|
|
mmio_size = 512*1024;
|
|
|
|
else
|
|
|
|
mmio_size = 2*1024*1024;
|
|
|
|
|
|
|
|
dev_priv->regs = pci_iomap(dev->pdev, mmio_bar, mmio_size);
|
|
|
|
if (!dev_priv->regs) {
|
|
|
|
DRM_ERROR("failed to map registers\n");
|
|
|
|
ret = -EIO;
|
|
|
|
goto put_bridge;
|
|
|
|
}
|
|
|
|
|
2013-10-09 07:31:03 +08:00
|
|
|
/* This must be called before any calls to HAS_PCH_* */
|
|
|
|
intel_detect_pch(dev);
|
|
|
|
|
|
|
|
intel_uncore_init(dev);
|
|
|
|
|
2012-11-05 01:21:27 +08:00
|
|
|
ret = i915_gem_gtt_init(dev);
|
|
|
|
if (ret)
|
2013-09-24 04:33:20 +08:00
|
|
|
goto out_regs;
|
2012-06-12 17:28:17 +08:00
|
|
|
|
2014-06-05 22:20:46 +08:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
|
2014-11-14 17:09:49 +08:00
|
|
|
/* WARNING: Apparently we must kick fbdev drivers before vgacon,
|
|
|
|
* otherwise the vga fbdev driver falls over. */
|
|
|
|
ret = i915_kick_out_firmware_fb(dev_priv);
|
2014-06-05 22:20:46 +08:00
|
|
|
if (ret) {
|
2014-11-14 17:09:49 +08:00
|
|
|
DRM_ERROR("failed to remove conflicting framebuffer drivers\n");
|
2014-06-05 22:20:46 +08:00
|
|
|
goto out_gtt;
|
|
|
|
}
|
|
|
|
|
2014-11-14 17:09:49 +08:00
|
|
|
ret = i915_kick_out_vgacon(dev_priv);
|
2013-12-16 23:57:40 +08:00
|
|
|
if (ret) {
|
2014-11-14 17:09:49 +08:00
|
|
|
DRM_ERROR("failed to remove conflicting VGA console\n");
|
2013-12-16 23:57:40 +08:00
|
|
|
goto out_gtt;
|
|
|
|
}
|
2014-06-05 22:20:46 +08:00
|
|
|
}
|
2012-06-12 17:28:17 +08:00
|
|
|
|
2011-12-19 19:15:29 +08:00
|
|
|
pci_set_master(dev->pdev);
|
|
|
|
|
2010-08-31 03:25:23 +08:00
|
|
|
/* overlay on gen2 is broken and can't address above 1G */
|
|
|
|
if (IS_GEN2(dev))
|
|
|
|
dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(30));
|
|
|
|
|
2011-03-02 06:24:16 +08:00
|
|
|
/* 965GM sometimes incorrectly writes to hardware status page (HWS)
|
|
|
|
* using 32bit addressing, overwriting memory if HWS is located
|
|
|
|
* above 4GB.
|
|
|
|
*
|
|
|
|
* The documentation also mentions an issue with undefined
|
|
|
|
* behaviour if any general state is accessed within a page above 4GB,
|
|
|
|
* which also needs to be handled carefully.
|
|
|
|
*/
|
|
|
|
if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
|
|
|
|
dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32));
|
|
|
|
|
2013-01-18 04:45:17 +08:00
|
|
|
aperture_size = dev_priv->gtt.mappable_end;
|
2010-10-28 01:46:52 +08:00
|
|
|
|
2013-01-18 04:45:15 +08:00
|
|
|
dev_priv->gtt.mappable =
|
|
|
|
io_mapping_create_wc(dev_priv->gtt.mappable_base,
|
2012-06-07 21:55:57 +08:00
|
|
|
aperture_size);
|
2013-01-18 04:45:15 +08:00
|
|
|
if (dev_priv->gtt.mappable == NULL) {
|
2009-02-25 09:35:11 +08:00
|
|
|
ret = -EIO;
|
2013-09-24 04:33:20 +08:00
|
|
|
goto out_gtt;
|
2009-02-25 09:35:11 +08:00
|
|
|
}
|
|
|
|
|
2013-06-28 07:30:23 +08:00
|
|
|
dev_priv->gtt.mtrr = arch_phys_wc_add(dev_priv->gtt.mappable_base,
|
|
|
|
aperture_size);
|
2010-09-07 02:08:44 +08:00
|
|
|
|
2010-09-09 19:46:34 +08:00
|
|
|
/* The i915 workqueue is primarily used for batched retirement of
|
|
|
|
* requests (and thus managing bo) once the task has been completed
|
|
|
|
* by the GPU. i915_gem_retire_requests() is called directly when we
|
|
|
|
* need high-priority retirement, such as waiting for an explicit
|
|
|
|
* bo.
|
|
|
|
*
|
|
|
|
* It is also used for periodic low-priority events, such as
|
2010-11-18 09:31:12 +08:00
|
|
|
* idle-timers and recording error state.
|
2010-09-09 19:46:34 +08:00
|
|
|
*
|
|
|
|
* All tasks on the workqueue are expected to acquire the dev mutex
|
|
|
|
* so there is no point in running more than one instance of the
|
2012-08-23 07:40:57 +08:00
|
|
|
* workqueue at any time. Use an ordered one.
|
2010-09-09 19:46:34 +08:00
|
|
|
*/
|
2012-08-23 07:40:57 +08:00
|
|
|
dev_priv->wq = alloc_ordered_workqueue("i915", 0);
|
2009-08-04 07:09:16 +08:00
|
|
|
if (dev_priv->wq == NULL) {
|
|
|
|
DRM_ERROR("Failed to create our workqueue.\n");
|
|
|
|
ret = -ENOMEM;
|
2011-07-11 04:12:17 +08:00
|
|
|
goto out_mtrrfree;
|
2009-08-04 07:09:16 +08:00
|
|
|
}
|
|
|
|
|
2014-05-02 12:02:48 +08:00
|
|
|
dev_priv->dp_wq = alloc_ordered_workqueue("i915-dp", 0);
|
|
|
|
if (dev_priv->dp_wq == NULL) {
|
|
|
|
DRM_ERROR("Failed to create our dp workqueue.\n");
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out_freewq;
|
|
|
|
}
|
|
|
|
|
2014-09-30 16:56:44 +08:00
|
|
|
intel_irq_init(dev_priv);
|
2013-10-05 12:22:49 +08:00
|
|
|
intel_uncore_sanitize(dev);
|
2009-02-07 02:22:41 +08:00
|
|
|
|
2009-12-17 14:48:43 +08:00
|
|
|
/* Try to make sure MCHBAR is enabled before poking at it */
|
|
|
|
intel_setup_mchbar(dev);
|
2010-07-21 06:44:45 +08:00
|
|
|
intel_setup_gmbus(dev);
|
2010-08-19 23:09:23 +08:00
|
|
|
intel_opregion_setup(dev);
|
2009-12-17 14:48:43 +08:00
|
|
|
|
2010-10-14 16:14:51 +08:00
|
|
|
intel_setup_bios(dev);
|
|
|
|
|
2008-07-31 03:06:12 +08:00
|
|
|
i915_gem_load(dev);
|
|
|
|
|
2008-07-30 03:10:39 +08:00
|
|
|
/* On the 945G/GM, the chipset reports the MSI capability on the
|
|
|
|
* integrated graphics even though the support isn't actually there
|
|
|
|
* according to the published specs. It doesn't appear to function
|
|
|
|
* correctly in testing on 945G.
|
|
|
|
* This may be a side effect of MSI having been made available for PEG
|
|
|
|
* and the registers being closely associated.
|
2008-10-17 15:44:42 +08:00
|
|
|
*
|
|
|
|
* According to chipset errata, on the 965GM, MSI interrupts may
|
2008-12-09 03:12:28 +08:00
|
|
|
* be lost or delayed, but we use them anyways to avoid
|
|
|
|
* stuck interrupts on some machines.
|
2008-07-30 03:10:39 +08:00
|
|
|
*/
|
2008-12-09 03:12:28 +08:00
|
|
|
if (!IS_I945G(dev) && !IS_I945GM(dev))
|
2008-11-04 06:46:17 +08:00
|
|
|
pci_enable_msi(dev->pdev);
|
2008-07-30 03:10:39 +08:00
|
|
|
|
2014-02-08 03:12:49 +08:00
|
|
|
intel_device_info_runtime_init(dev);
|
2013-04-03 02:22:20 +08:00
|
|
|
|
2013-04-06 04:12:39 +08:00
|
|
|
if (INTEL_INFO(dev)->num_pipes) {
|
|
|
|
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
|
|
|
|
if (ret)
|
|
|
|
goto out_gem_unload;
|
|
|
|
}
|
2008-11-19 01:30:25 +08:00
|
|
|
|
2014-02-18 06:02:02 +08:00
|
|
|
intel_power_domains_init(dev_priv);
|
2013-05-30 22:07:11 +08:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
|
2010-09-23 05:44:24 +08:00
|
|
|
ret = i915_load_modeset_init(dev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
DRM_ERROR("failed to init modeset\n");
|
2013-09-24 04:33:20 +08:00
|
|
|
goto out_power_well;
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-11 12:17:01 +08:00
|
|
|
i915_setup_sysfs(dev);
|
|
|
|
|
2013-04-06 04:12:39 +08:00
|
|
|
if (INTEL_INFO(dev)->num_pipes) {
|
|
|
|
/* Must be done after probing outputs */
|
|
|
|
intel_opregion_init(dev);
|
2013-07-26 03:43:39 +08:00
|
|
|
acpi_video_register();
|
2013-04-06 04:12:39 +08:00
|
|
|
}
|
2009-03-20 05:35:39 +08:00
|
|
|
|
2012-04-27 05:28:12 +08:00
|
|
|
if (IS_GEN5(dev))
|
|
|
|
intel_gpu_ips_init(dev_priv);
|
2010-12-21 10:40:06 +08:00
|
|
|
|
2014-09-30 16:56:39 +08:00
|
|
|
intel_runtime_pm_enable(dev_priv);
|
2013-12-07 06:32:13 +08:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
return 0;
|
|
|
|
|
2013-09-24 04:33:20 +08:00
|
|
|
out_power_well:
|
2014-09-30 16:56:39 +08:00
|
|
|
intel_power_domains_fini(dev_priv);
|
2013-09-24 04:33:20 +08:00
|
|
|
drm_vblank_cleanup(dev);
|
2010-11-09 01:10:29 +08:00
|
|
|
out_gem_unload:
|
2014-05-21 00:47:20 +08:00
|
|
|
WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
|
|
|
|
unregister_shrinker(&dev_priv->mm.shrinker);
|
2011-07-11 04:12:17 +08:00
|
|
|
|
2010-11-09 01:10:29 +08:00
|
|
|
if (dev->pdev->msi_enabled)
|
|
|
|
pci_disable_msi(dev->pdev);
|
|
|
|
|
|
|
|
intel_teardown_gmbus(dev);
|
|
|
|
intel_teardown_mchbar(dev);
|
2014-01-25 17:13:37 +08:00
|
|
|
pm_qos_remove_request(&dev_priv->pm_qos);
|
2014-05-02 12:02:48 +08:00
|
|
|
destroy_workqueue(dev_priv->dp_wq);
|
|
|
|
out_freewq:
|
2009-08-04 07:09:16 +08:00
|
|
|
destroy_workqueue(dev_priv->wq);
|
2011-07-11 04:12:17 +08:00
|
|
|
out_mtrrfree:
|
2013-06-28 07:30:23 +08:00
|
|
|
arch_phys_wc_del(dev_priv->gtt.mtrr);
|
2013-01-18 04:45:15 +08:00
|
|
|
io_mapping_free(dev_priv->gtt.mappable);
|
2013-09-24 04:33:20 +08:00
|
|
|
out_gtt:
|
2014-08-06 21:04:56 +08:00
|
|
|
i915_global_gtt_cleanup(dev);
|
2013-09-24 04:33:20 +08:00
|
|
|
out_regs:
|
2013-10-09 07:31:03 +08:00
|
|
|
intel_uncore_fini(dev);
|
2010-10-30 04:02:18 +08:00
|
|
|
pci_iounmap(dev->pdev, dev_priv->regs);
|
2009-08-04 09:43:41 +08:00
|
|
|
put_bridge:
|
|
|
|
pci_dev_put(dev_priv->bridge_dev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
free_priv:
|
2013-09-24 04:33:20 +08:00
|
|
|
if (dev_priv->slab)
|
|
|
|
kmem_cache_destroy(dev_priv->slab);
|
2009-03-25 03:23:04 +08:00
|
|
|
kfree(dev_priv);
|
2007-11-22 12:14:14 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_driver_unload(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-08-21 03:23:20 +08:00
|
|
|
int ret;
|
2007-11-22 12:14:14 +08:00
|
|
|
|
2013-12-02 21:26:07 +08:00
|
|
|
ret = i915_gem_suspend(dev);
|
|
|
|
if (ret) {
|
|
|
|
DRM_ERROR("failed to idle hardware: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-09-30 16:56:41 +08:00
|
|
|
intel_power_domains_fini(dev_priv);
|
2013-12-07 06:32:13 +08:00
|
|
|
|
2012-04-27 05:28:12 +08:00
|
|
|
intel_gpu_ips_teardown();
|
2010-05-21 05:28:11 +08:00
|
|
|
|
2012-04-11 12:17:01 +08:00
|
|
|
i915_teardown_sysfs(dev);
|
|
|
|
|
2014-05-21 00:47:20 +08:00
|
|
|
WARN_ON(unregister_oom_notifier(&dev_priv->mm.oom_notifier));
|
|
|
|
unregister_shrinker(&dev_priv->mm.shrinker);
|
2010-10-28 19:51:39 +08:00
|
|
|
|
2013-01-18 04:45:15 +08:00
|
|
|
io_mapping_free(dev_priv->gtt.mappable);
|
2013-06-28 07:30:23 +08:00
|
|
|
arch_phys_wc_del(dev_priv->gtt.mtrr);
|
2009-01-24 04:57:47 +08:00
|
|
|
|
2010-08-19 23:09:23 +08:00
|
|
|
acpi_video_unregister();
|
|
|
|
|
2014-10-16 01:15:04 +08:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET))
|
2010-10-04 22:33:04 +08:00
|
|
|
intel_fbdev_fini(dev);
|
2014-10-16 01:15:04 +08:00
|
|
|
|
|
|
|
drm_vblank_cleanup(dev);
|
|
|
|
|
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
|
2010-03-27 02:07:21 +08:00
|
|
|
intel_modeset_cleanup(dev);
|
|
|
|
|
2009-11-24 09:48:44 +08:00
|
|
|
/*
|
|
|
|
* free the memory space allocated for the child device
|
|
|
|
* config parsed from VBT
|
|
|
|
*/
|
2013-05-10 07:03:18 +08:00
|
|
|
if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
|
|
|
|
kfree(dev_priv->vbt.child_dev);
|
|
|
|
dev_priv->vbt.child_dev = NULL;
|
|
|
|
dev_priv->vbt.child_dev_num = 0;
|
2009-11-24 09:48:44 +08:00
|
|
|
}
|
2010-08-21 00:26:46 +08:00
|
|
|
|
2010-02-01 13:38:10 +08:00
|
|
|
vga_switcheroo_unregister_client(dev->pdev);
|
2009-09-21 12:33:58 +08:00
|
|
|
vga_client_register(dev->pdev, NULL, NULL, NULL);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
2010-08-21 03:25:11 +08:00
|
|
|
/* Free error state after interrupts are fully disabled. */
|
2012-11-15 00:14:04 +08:00
|
|
|
del_timer_sync(&dev_priv->gpu_error.hangcheck_timer);
|
|
|
|
cancel_work_sync(&dev_priv->gpu_error.work);
|
2010-08-21 03:25:11 +08:00
|
|
|
i915_destroy_error_state(dev);
|
2010-08-21 00:18:48 +08:00
|
|
|
|
2008-07-30 03:10:39 +08:00
|
|
|
if (dev->pdev->msi_enabled)
|
|
|
|
pci_disable_msi(dev->pdev);
|
|
|
|
|
2010-08-19 23:09:23 +08:00
|
|
|
intel_opregion_fini(dev);
|
2008-08-06 02:37:25 +08:00
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
|
2010-08-21 04:26:30 +08:00
|
|
|
/* Flush any outstanding unpin_work. */
|
|
|
|
flush_workqueue(dev_priv->wq);
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
i915_gem_cleanup_ringbuffer(dev);
|
2014-12-12 04:13:09 +08:00
|
|
|
i915_gem_batch_pool_fini(&dev_priv->mm.batch_pool);
|
2012-06-20 03:55:32 +08:00
|
|
|
i915_gem_context_fini(dev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2012-04-24 22:47:39 +08:00
|
|
|
i915_gem_cleanup_stolen(dev);
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
}
|
|
|
|
|
2010-07-21 06:44:45 +08:00
|
|
|
intel_teardown_gmbus(dev);
|
2009-12-17 14:48:43 +08:00
|
|
|
intel_teardown_mchbar(dev);
|
|
|
|
|
2014-05-02 12:02:48 +08:00
|
|
|
destroy_workqueue(dev_priv->dp_wq);
|
2010-08-21 00:18:48 +08:00
|
|
|
destroy_workqueue(dev_priv->wq);
|
drm/i915: irq-drive the dp aux communication
At least on the platforms that have a dp aux irq and also have it
enabled - vlvhsw should have one, too. But I don't have a machine to
test this on. Judging from docs there's no dp aux interrupt for gm45.
Also, I only have an ivb cpu edp machine, so the dp aux A code for
snb/ilk is untested.
For dpcd probing when nothing is connected it slashes about 5ms of cpu
time (cpu time is now negligible), which agrees with 3 * 5 400 usec
timeouts.
A previous version of this patch increases the time required to go
through the dp_detect cycle (which includes reading the edid) from
around 33 ms to around 40 ms. Experiments indicated that this is
purely due to the irq latency - the hw doesn't allow us to queue up
dp aux transactions and hence irq latency directly affects throughput.
gmbus is much better, there we have a 8 byte buffer, and we get the
irq once another 4 bytes can be queued up.
But by using the pm_qos interface to request the lowest possible cpu
wake-up latency this slowdown completely disappeared.
Since all our output detection logic is single-threaded with the
mode_config mutex right now anyway, I've decide not ot play fancy and
to just reuse the gmbus wait queue. But this would definitely prep the
way to run dp detection on different ports in parallel
v2: Add a timeout for dp aux transfers when using interrupts - the hw
_does_ prevent this with the hw-based 400 usec timeout, but if the
irq somehow doesn't arrive we're screwed. Lesson learned while
developing this ;-)
v3: While at it also convert the busy-loop to wait_for_atomic, so that
we don't run the risk of an infinite loop any more.
v4: Ensure we have the smallest possible irq latency by using the
pm_qos interface.
v5: Add a comment to the code to explain why we frob pm_qos. Suggested
by Chris Wilson.
v6: Disable dp irq for vlv, that's easier than trying to get at docs
and hw.
v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the
dp aux registers aren't at a fixed offset any more, but can be on the
PCH while the DP port is on the cpu die.
Reviewed-by: Imre Deak <imre.deak@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-01 20:53:48 +08:00
|
|
|
pm_qos_remove_request(&dev_priv->pm_qos);
|
2010-08-21 00:18:48 +08:00
|
|
|
|
2014-08-06 21:04:56 +08:00
|
|
|
i915_global_gtt_cleanup(dev);
|
2013-05-22 22:47:13 +08:00
|
|
|
|
2013-08-26 20:46:09 +08:00
|
|
|
intel_uncore_fini(dev);
|
|
|
|
if (dev_priv->regs != NULL)
|
|
|
|
pci_iounmap(dev->pdev, dev_priv->regs);
|
|
|
|
|
2012-11-15 19:32:30 +08:00
|
|
|
if (dev_priv->slab)
|
|
|
|
kmem_cache_destroy(dev_priv->slab);
|
2010-08-21 00:18:48 +08:00
|
|
|
|
2009-08-04 09:43:41 +08:00
|
|
|
pci_dev_put(dev_priv->bridge_dev);
|
2014-05-14 04:21:59 +08:00
|
|
|
kfree(dev_priv);
|
2007-11-22 12:14:14 +08:00
|
|
|
|
2005-11-10 19:16:34 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-09-24 23:02:42 +08:00
|
|
|
int i915_driver_open(struct drm_device *dev, struct drm_file *file)
|
2008-07-31 03:06:12 +08:00
|
|
|
{
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-26 00:34:56 +08:00
|
|
|
int ret;
|
2008-07-31 03:06:12 +08:00
|
|
|
|
drm/i915: Boost RPS frequency for CPU stalls
If we encounter a situation where the CPU blocks waiting for results
from the GPU, give the GPU a kick to boost its the frequency.
This should work to reduce user interface stalls and to quickly promote
mesa to high frequencies - but the cost is that our requested frequency
stalls high (as we do not idle for long enough before rc6 to start
reducing frequencies, nor are we aggressive at down clocking an
underused GPU). However, this should be mitigated by rc6 itself powering
off the GPU when idle, and that energy use is dependent upon the workload
of the GPU in addition to its frequency (e.g. the math or sampler
functions only consume power when used). Still, this is likely to
adversely affect light workloads.
In particular, this nearly eliminates the highly noticeable wake-up lag
in animations from idle. For example, expose or workspace transitions.
(However, given the situation where we fail to downclock, our requested
frequency is almost always the maximum, except for Baytrail where we
manually downclock upon idling. This often masks the latency of
upclocking after being idle, so animations are typically smooth - at the
cost of increased power consumption.)
Stéphane raised the concern that this will punish good applications and
reward bad applications - but due to the nature of how mesa performs its
client throttling, I believe all mesa applications will be roughly
equally affected. To address this concern, and to prevent applications
like compositors from permanently boosting the RPS state, we ratelimit the
frequency of the wait-boosts each client recieves.
Unfortunately, this techinique is ineffective with Ironlake - which also
has dynamic render power states and suffers just as dramatically. For
Ironlake, the thermal/power headroom is shared with the CPU through
Intelligent Power Sharing and the intel-ips module. This leaves us with
no GPU boost frequencies available when coming out of idle, and due to
hardware limitations we cannot change the arbitration between the CPU and
GPU quickly enough to be effective.
v2: Limit each client to receiving a single boost for each active period.
Tested by QA to only marginally increase power, and to demonstrably
increase throughput in games. No latency measurements yet.
v3: Cater for front-buffer rendering with manual throttling.
v4: Tidy up.
v5: Sadly the compositor needs frequent boosts as it may never idle, but
due to its picking mechanism (using ReadPixels) may require frequent
waits. Those waits, along with the waits for the vrefresh swap, conspire
to keep the GPU at low frequencies despite the interactive latency. To
overcome this we ditch the one-boost-per-active-period and just ratelimit
the number of wait-boosts each client can receive.
Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Cc: Owen Taylor <otaylor@redhat.com>
Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com>
Cc: "Zhuang, Lena" <lena.zhuang@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: No extern for function prototypes in headers.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-26 00:34:56 +08:00
|
|
|
ret = i915_gem_open(dev, file);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
|
2008-07-31 03:06:12 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
/**
|
|
|
|
* i915_driver_lastclose - clean up after all DRM clients have exited
|
|
|
|
* @dev: DRM device
|
|
|
|
*
|
|
|
|
* Take care of cleaning up after all DRM clients have exited. In the
|
|
|
|
* mode setting case, we want to restore the kernel's initial mode (just
|
|
|
|
* in case the last client left us in a bad state).
|
|
|
|
*
|
2012-03-26 15:45:41 +08:00
|
|
|
* Additionally, in the non-mode setting case, we'll tear down the GTT
|
DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported. HDMI, DisplayPort and additional SDVO output support will
follow.
Support for the mode setting code is controlled by the new 'modeset'
module option. A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.
Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing. So use caution when
enabling this code; be sure your user level code supports the new
interfaces.
A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.
Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-11-08 06:24:08 +08:00
|
|
|
* and DMA structures, since the kernel won't be using them, and clea
|
|
|
|
* up any GEM state.
|
|
|
|
*/
|
2014-06-02 22:59:39 +08:00
|
|
|
void i915_driver_lastclose(struct drm_device *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-11-20 03:36:49 +08:00
|
|
|
intel_fbdev_restore_mode(dev);
|
|
|
|
vga_switcheroo_process_delayed_switch();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-06-27 01:23:52 +08:00
|
|
|
void i915_driver_preclose(struct drm_device *dev, struct drm_file *file)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-12-04 22:52:06 +08:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2014-06-27 01:23:52 +08:00
|
|
|
i915_gem_context_close(dev, file);
|
|
|
|
i915_gem_release(dev, file);
|
2013-12-04 22:52:06 +08:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2014-08-06 19:02:51 +08:00
|
|
|
|
|
|
|
if (drm_core_check_feature(dev, DRIVER_MODESET))
|
|
|
|
intel_modeset_preclose(dev, file);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-09-24 23:02:42 +08:00
|
|
|
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
|
2008-07-31 03:06:12 +08:00
|
|
|
{
|
2010-09-24 23:02:42 +08:00
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2008-07-31 03:06:12 +08:00
|
|
|
|
2014-04-17 10:37:40 +08:00
|
|
|
if (file_priv && file_priv->bsd_ring)
|
|
|
|
file_priv->bsd_ring = NULL;
|
2010-09-24 23:02:42 +08:00
|
|
|
kfree(file_priv);
|
2008-07-31 03:06:12 +08:00
|
|
|
}
|
|
|
|
|
2014-11-24 18:21:52 +08:00
|
|
|
static int
|
|
|
|
i915_gem_reject_pin_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2013-08-03 01:27:49 +08:00
|
|
|
const struct drm_ioctl_desc i915_ioctls[] = {
|
2014-11-20 04:23:55 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_INIT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_FLUSH, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_FLIP, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, drm_noop, DRM_AUTH),
|
2013-08-26 00:29:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH|DRM_RENDER_ALLOW),
|
2010-08-14 18:20:34 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
2012-01-17 19:50:12 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
2014-11-20 04:23:55 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, drm_noop, DRM_AUTH),
|
2012-01-17 19:50:12 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
2012-04-27 05:28:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
2014-11-20 04:23:55 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, drm_noop, DRM_AUTH),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
|
2014-11-20 04:40:13 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
|
2010-08-14 18:20:34 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, DRM_AUTH|DRM_UNLOCKED),
|
2013-08-26 00:29:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
2014-11-24 18:21:52 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
|
2013-08-26 00:29:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
2014-11-20 03:36:47 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
|
2013-08-26 00:29:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
2010-08-14 18:20:34 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_PIPE_FROM_CRTC_ID, intel_get_pipe_from_crtc_id, DRM_UNLOCKED),
|
2013-08-26 00:29:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
2010-08-14 18:20:34 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
|
2012-01-04 00:05:39 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_set_colorkey, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_COLORKEY, intel_sprite_get_colorkey, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
|
2013-08-26 00:29:01 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE, i915_gem_context_create_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY, i915_gem_context_destroy_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
|
|
|
DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
2013-10-30 21:44:16 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS, i915_get_reset_stats_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).
v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-05-16 21:22:37 +08:00
|
|
|
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
|
2005-07-07 19:03:38 +08:00
|
|
|
};
|
|
|
|
|
2014-06-09 21:39:49 +08:00
|
|
|
int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
|
2005-07-10 15:31:26 +08:00
|
|
|
|
2012-03-26 15:45:41 +08:00
|
|
|
/*
|
|
|
|
* This is really ugly: Because old userspace abused the linux agp interface to
|
|
|
|
* manage the gtt, we need to claim that all intel devices are agp. For
|
|
|
|
* otherwise the drm core refuses to initialize the agp support code.
|
2005-07-10 15:31:26 +08:00
|
|
|
*/
|
2014-06-02 22:59:39 +08:00
|
|
|
int i915_driver_device_is_agp(struct drm_device *dev)
|
2005-07-10 15:31:26 +08:00
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|