2008-05-29 08:09:59 +08:00
|
|
|
#
|
|
|
|
# Makefile for the drm device driver. This driver provides support for the
|
|
|
|
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
|
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
# Please keep these build lists sorted!
|
|
|
|
|
|
|
|
# core driver code
|
|
|
|
i915-y := i915_drv.o \
|
|
|
|
i915_params.o \
|
2008-07-31 03:06:12 +08:00
|
|
|
i915_suspend.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_sysfs.o \
|
2014-09-30 16:56:38 +08:00
|
|
|
intel_pm.o \
|
drm/i915/skl: Add support to load SKL CSR firmware.
Display Context Save and Restore support is needed for
various SKL Display C states like DC5, DC6.
This implementation is added based on first version of DMC CSR program
that we received from h/w team.
Here we are using request_firmware based design.
Finally this firmware should end up in linux-firmware tree.
For SKL platform its mandatory to ensure that we load this
csr program before enabling DC states like DC5/DC6.
As CSR program gets reset on various conditions, we should ensure
to load it during boot and in future change to be added to load
this system resume sequence too.
v1: Initial relese as RFC patch
v2: Design change as per Daniel, Damien and Shobit's review comments
request firmware method followed.
v3: Some optimization and functional changes.
Pulled register defines into drivers/gpu/drm/i915/i915_reg.h
Used kmemdup to allocate and duplicate firmware content.
Ensured to free allocated buffer.
v4: Modified as per review comments from Satheesh and Daniel
Removed temporary buffer.
Optimized number of writes by replacing I915_WRITE with I915_WRITE64.
v5:
Modified as per review comemnts from Damien.
- Changed name for functions and firmware.
- Introduced HAS_CSR.
- Reverted back previous change and used csr_buf with u8 size.
- Using cpu_to_be64 for endianness change.
Modified as per review comments from Imre.
- Modified registers and macro names to be a bit closer to bspec terminology
and the existing register naming in the driver.
- Early return for non SKL platforms in intel_load_csr_program function.
- Added locking around CSR program load function as it may be called
concurrently during system/runtime resume.
- Releasing the fw before loading the program for consistency
- Handled error path during f/w load.
v6: Modified as per review comments from Imre.
- Corrected out_freecsr sequence.
v7: Modified as per review comments from Imre.
Fail loading fw if fw->size%8!=0.
v8: Rebase to latest.
v9: Rebase on top of -nightly (Damien)
v10: Enabled support for dmc firmware ver 1.0.
According to ver 1.0 in a single binary package all the firmware's that are
required for different stepping's of the product will be stored. The package
contains the css header, followed by the package header and the actual dmc
firmwares. Package header contains the firmware/stepping mapping table and
the corresponding firmware offsets to the individual binaries, within the
package. Each individual program binary contains the header and the payload
sections whose size is specified in the header section. This changes are done
to extract the specific firmaware from the package. (Animesh)
v11: Modified as per review comemnts from Imre.
- Added code comment from bpec for header structure elements.
- Added __packed to avoid structure padding.
- Added helper functions for stepping and substepping info.
- Added code comment for CSR_MAX_FW_SIZE.
- Disabled BXT firmware loading, will be enabled with dmc 1.0 support.
- Changed skl_stepping_info based on bspec, earlier used from config DB.
- Removed duplicate call of cpu_to_be* from intel_csr_load_program function.
- Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned.
- Added sanity check for header length.
- Added sanity check for mmio address got from firmware binary.
- kmalloc done separately for dmc header and dmc firmware. (Animesh)
v12: Modified as per review comemnts from Imre.
- Corrected the typo error in skl stepping info structure.
- Added out-of-bound access for skl_stepping_info.
- Sanity check for mmio address modified.
- Sanity check added for stepping and substeppig.
- Modified the intel_dmc_info structure, cache only the required header info. (Animesh)
v13: clarify firmware load error message.
The reason for a firmware loading failure can be obscure if the driver
is built-in. Provide an explanation to the user about the likely reason for
the failure and how to resolve it. (Imre)
v14: Suggested by Jani.
- fix s/I915/CONFIG_DRM_I915/ typo
- add fw_path to the firmware object instead of using a static ptr (Jani)
v15:
1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link
with same name will help not to build kernel again.
2) Changes done as per review comments from Imre.
- Error check removed for intel_csr_ucode_init.
- Moved csr-specific data structure to intel_csr.h and optimization done on structure definition.
- fw->data used directly for parsing the header info & memory allocation
only done separately for payload. (Animesh)
v16:
- No need for out_regs label in i915_driver_load(), so removed it.
- Changed the firmware name as skl_dmc_ver1.bin, followed naming convention <platform>_dmc_<api-version>.bin (Animesh)
Issue: VIZ-2569
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 20:58:44 +08:00
|
|
|
intel_runtime_pm.o \
|
|
|
|
intel_csr.o
|
2014-09-30 16:56:38 +08:00
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
i915-$(CONFIG_COMPAT) += i915_ioc32.o
|
|
|
|
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
|
|
|
|
|
|
|
|
# GEM code
|
|
|
|
i915-y += i915_cmd_parser.o \
|
2014-12-12 04:13:08 +08:00
|
|
|
i915_gem_batch_pool.o \
|
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
|
|
|
i915_gem_context.o \
|
2014-05-14 22:02:16 +08:00
|
|
|
i915_gem_render_state.o \
|
2008-07-31 03:06:12 +08:00
|
|
|
i915_gem_debug.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_gem_dmabuf.o \
|
2010-08-07 18:01:23 +08:00
|
|
|
i915_gem_evict.o \
|
2010-11-26 02:00:26 +08:00
|
|
|
i915_gem_execbuffer.o \
|
|
|
|
i915_gem_gtt.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_gem.o \
|
2015-03-18 17:46:04 +08:00
|
|
|
i915_gem_shrinker.o \
|
2012-04-24 22:47:39 +08:00
|
|
|
i915_gem_stolen.o \
|
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_gem_tiling.o \
|
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
|
|
|
i915_gem_userptr.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_gpu_error.o \
|
|
|
|
i915_irq.o \
|
2009-08-25 18:15:50 +08:00
|
|
|
i915_trace_points.o \
|
2015-06-18 18:06:16 +08:00
|
|
|
intel_hotplug.o \
|
2014-07-25 00:04:10 +08:00
|
|
|
intel_lrc.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
intel_ringbuffer.o \
|
|
|
|
intel_uncore.o
|
|
|
|
|
2014-05-14 22:02:16 +08:00
|
|
|
# autogenerated null render state
|
|
|
|
i915-y += intel_renderstate_gen6.o \
|
|
|
|
intel_renderstate_gen7.o \
|
2014-10-23 23:34:28 +08:00
|
|
|
intel_renderstate_gen8.o \
|
|
|
|
intel_renderstate_gen9.o
|
2014-05-14 22:02:16 +08:00
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
# modesetting core code
|
2014-10-27 22:26:43 +08:00
|
|
|
i915-y += intel_audio.o \
|
|
|
|
intel_bios.o \
|
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
|
|
|
intel_display.o \
|
2014-12-09 00:09:10 +08:00
|
|
|
intel_fbc.o \
|
2014-09-30 16:56:46 +08:00
|
|
|
intel_fifo_underrun.o \
|
2014-09-20 00:27:27 +08:00
|
|
|
intel_frontbuffer.o \
|
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
|
|
|
intel_modes.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
intel_overlay.o \
|
2014-11-15 00:52:28 +08:00
|
|
|
intel_psr.o \
|
2013-05-22 20:36:16 +08:00
|
|
|
intel_sideband.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
intel_sprite.o
|
2014-03-18 16:43:56 +08:00
|
|
|
i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
|
2014-03-07 16:17:21 +08:00
|
|
|
i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
|
|
|
|
|
|
|
|
# modesetting output/encoder code
|
|
|
|
i915-y += dvo_ch7017.o \
|
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
|
|
|
dvo_ch7xxx.o \
|
|
|
|
dvo_ivch.o \
|
2012-07-19 01:22:30 +08:00
|
|
|
dvo_ns2501.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
dvo_sil164.o \
|
|
|
|
dvo_tfp410.o \
|
2015-01-22 08:35:44 +08:00
|
|
|
intel_atomic.o \
|
2014-12-24 02:41:52 +08:00
|
|
|
intel_atomic_plane.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
intel_crt.o \
|
|
|
|
intel_ddi.o \
|
|
|
|
intel_dp.o \
|
2014-05-02 12:02:48 +08:00
|
|
|
intel_dp_mst.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
intel_dsi.o \
|
|
|
|
intel_dsi_pll.o \
|
2014-05-24 00:05:27 +08:00
|
|
|
intel_dsi_panel_vbt.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
intel_dvo.o \
|
|
|
|
intel_hdmi.o \
|
|
|
|
intel_i2c.o \
|
|
|
|
intel_lvds.o \
|
|
|
|
intel_panel.o \
|
|
|
|
intel_sdvo.o \
|
|
|
|
intel_tv.o
|
2013-10-09 15:18:51 +08:00
|
|
|
|
2015-02-10 19:05:47 +08:00
|
|
|
# virtual gpu code
|
|
|
|
i915-y += i915_vgpu.o
|
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
# legacy horrors
|
2015-02-23 19:03:30 +08:00
|
|
|
i915-y += i915_dma.o
|
2013-12-16 19:10:36 +08:00
|
|
|
|
2008-05-29 08:09:59 +08:00
|
|
|
obj-$(CONFIG_DRM_I915) += i915.o
|
2010-05-03 20:24:41 +08:00
|
|
|
|
|
|
|
CFLAGS_i915_trace_points.o := -I$(src)
|