openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
linux/drivers/gpu/drm/i915/Makefile

73 lines
1.5 KiB
Makefile
Raw Normal View History

drm: reorganise drm tree to be more future proof. With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: Dave Airlie <airlied@redhat.com>
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.
ccflags-y := -Iinclude/drm
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 \
drm: Add GEM ("graphics execution manager") to i915 driver. GEM allows the creation of persistent buffer objects accessible by the graphics device through new ioctls for managing execution of commands on the device. The userland API is almost entirely driver-specific to ensure that any driver building on this model can easily map the interface to individual driver requirements. GEM is used by the 2d driver for managing its internal state allocations and will be used for pixmap storage to reduce memory consumption and enable zero-copy GLX_EXT_texture_from_pixmap, and in the 3d driver is used to enable GL_EXT_framebuffer_object and GL_ARB_pixel_buffer_object. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-07-31 03:06:12 +08:00
i915_suspend.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
i915_sysfs.o \
intel_pm.o
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
# GEM code
i915-y += i915_cmd_parser.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 \
drm: Add GEM ("graphics execution manager") to i915 driver. GEM allows the creation of persistent buffer objects accessible by the graphics device through new ioctls for managing execution of commands on the device. The userland API is almost entirely driver-specific to ensure that any driver building on this model can easily map the interface to individual driver requirements. GEM is used by the 2d driver for managing its internal state allocations and will be used for pixmap storage to reduce memory consumption and enable zero-copy GLX_EXT_texture_from_pixmap, and in the 3d driver is used to enable GL_EXT_framebuffer_object and GL_ARB_pixel_buffer_object. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-07-31 03:06:12 +08:00
i915_gem_debug.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
i915_gem_dmabuf.o \
drm/i915: Move the eviction logic to its own file. The eviction code is the gnarly underbelly of memory management, and is clearer if kept separated from the normal domain management in GEM. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
2010-08-07 18:01:23 +08:00
i915_gem_evict.o \
drm/i915: Split i915_gem_execbuffer into its own file. A number of dragons have been seen lurking within the execbuffer code. The first step is then to isolate them from the rest and begin to scrutinise them in depth. Suggested by Daniel Vetter. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2010-11-26 02:00:26 +08:00
i915_gem_execbuffer.o \
i915_gem_gtt.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
i915_gem.o \
drm/i915: Split the stolen handling for GEM out of i915_dma.c We slightly modify the initialisation sequence to move the initialisation of the memory managers earlier and in particular before probing outputs and detecting any existing output configuration. This is essential if we wish to track preallocated objects and preserve them whilst initialising GEM. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
i915_gpu_error.o \
i915_irq.o \
drm/i915: Add tracepoints By adding tracepoint equivalents for WATCH_BUF/EXEC we are able to monitor the lifetimes of objects, requests and significant events. These events can then be probed using the tracing frameworks, such as systemtap and, in particular, perf. For example to record the stack trace for every GPU stall during a run, use $ perf record -e i915:i915_gem_request_wait_begin -c 1 -g And $ perf report to view the results. [Updated to fix compilation issues caused.] Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Ben Gamari <bgamari@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2009-08-25 18:15:50 +08:00
i915_trace_points.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
intel_ringbuffer.o \
intel_uncore.o
# modesetting core code
i915-y += 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 \
intel_modes.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
intel_overlay.o \
drm/i915: group sideband register accessors to a new file Group both the HSW/LPT SBI interface and VLV IOSF sideband register accessor functions into a new file. No functional changes. v2: also move intel_sbi_{read,write} (Daniel) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-22 20:36:16 +08:00
intel_sideband.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
intel_sprite.o
Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next Conflicts: drivers/gpu/drm/i915/Makefile Makefile cleanup in drm-intel-next conflicts with a build-fix to move intel_opregion under CONFIG_ACPI. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-18 16:43:56 +08:00
i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 \
drm/i915: Support for ns2501-DVO This patch adds support for the ns2501 DVO, found in some older Fujitsu/Siemens Labtops. It is in the state of "works for me". Includes now proper DPMS support. Includes switching between resolutions - from 640x480 to 1024x768. Currently assumes that the native display resolution is 1024x768. The ns2501 seems to be rather critical - if the output PLL is not running, the chip doesn't seem to be clocked and then doesn't react on i2c messages. Thus, a quick'n-dirty trick ensures that the DVO is active before submitting any i2c messages to it. This is probably to be reviewed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17902 Signed-off-by: Thomas Richter <thor@math.tu-berlin.de> [danvet: fixup whitespace fail.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-19 01:22:30 +08:00
dvo_ns2501.o \
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
dvo_sil164.o \
dvo_tfp410.o \
intel_crt.o \
intel_ddi.o \
intel_dp.o \
intel_dsi_cmd.o \
intel_dsi.o \
intel_dsi_pll.o \
intel_dvo.o \
intel_hdmi.o \
intel_i2c.o \
intel_lvds.o \
intel_panel.o \
intel_sdvo.o \
intel_tv.o
drm/i915: Kconfig option to disable the legacy fbdev support Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c v3: Use the right CONFIG variable, spotted by Chon Ming. Cc: Lee, Chon Ming <chon.ming.lee@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-09 15:18:51 +08:00
drm/i915: Go OCD on the Makefile Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07 16:17:21 +08:00
# legacy horrors
i915-y += i915_dma.o \
i915_ums.o
drm/i915: only build i915_debugfs.c when CONFIG_DEBUG_FS is enabled The whole file is wrapped around in #if defined(CONFIG_DEBUG_FS) anyway, so skip the file at the build level already. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-16 19:10:36 +08:00
drm: reorganise drm tree to be more future proof. With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-05-29 08:09:59 +08:00
obj-$(CONFIG_DRM_I915) += i915.o
drm/i915: Fix out of tree builds Fixes up include paths for i915_trace.h by setting additional CFLAGS for i915_trace_points.c to include the $src directory. The required TRACE_INCLUDE_PATH is then "." Signed-off-by: Peter Clifton <pcjc2@cam.ac.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
2010-05-03 20:24:41 +08:00
CFLAGS_i915_trace_points.o := -I$(src)