License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
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.
|
|
|
|
|
2017-10-25 02:15:47 +08:00
|
|
|
# Add a set of useful warning flags and enable -Werror for CI to prevent
|
|
|
|
# trivial mistakes from creeping in. We have to do this piecemeal as we reject
|
|
|
|
# any patch that isn't warning clean, so turning on -Wall -Wextra (or W=1) we
|
|
|
|
# need to filter out dubious warnings. Still it is our interest
|
|
|
|
# to keep running locally with W=1 C=1 until we are completely clean.
|
|
|
|
#
|
|
|
|
# Note the danger in using -Wall -Wextra is that when CI updates gcc we
|
|
|
|
# will most likely get a sudden build breakage... Hopefully we will fix
|
|
|
|
# new warnings before CI updates!
|
2018-06-26 06:59:34 +08:00
|
|
|
subdir-ccflags-y := -Wall -Wextra
|
2017-10-31 01:29:27 +08:00
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, unused-parameter)
|
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, type-limits)
|
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
|
2018-02-09 00:16:39 +08:00
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
|
2018-05-02 02:24:40 +08:00
|
|
|
# clang warnings
|
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
|
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
|
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
|
2019-01-26 15:11:23 +08:00
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, uninitialized)
|
2020-04-27 05:42:15 +08:00
|
|
|
subdir-ccflags-y += $(call cc-disable-warning, frame-address)
|
2017-10-25 02:15:47 +08:00
|
|
|
subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
|
|
|
|
|
|
|
|
# Fine grained warnings disable
|
2017-10-31 01:29:27 +08:00
|
|
|
CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
|
kbuild: change *FLAGS_<basetarget>.o to take the path relative to $(obj)
Kbuild provides per-file compiler flag addition/removal:
CFLAGS_<basetarget>.o
CFLAGS_REMOVE_<basetarget>.o
AFLAGS_<basetarget>.o
AFLAGS_REMOVE_<basetarget>.o
CPPFLAGS_<basetarget>.lds
HOSTCFLAGS_<basetarget>.o
HOSTCXXFLAGS_<basetarget>.o
The <basetarget> is the filename of the target with its directory and
suffix stripped.
This syntax comes into a trouble when two files with the same basename
appear in one Makefile, for example:
obj-y += foo.o
obj-y += dir/foo.o
CFLAGS_foo.o := <some-flags>
Here, the <some-flags> applies to both foo.o and dir/foo.o
The real world problem is:
scripts/kconfig/util.c
scripts/kconfig/lxdialog/util.c
Both files are compiled into scripts/kconfig/mconf, but only the
latter should be given with the ncurses flags.
It is more sensible to use the relative path to the Makefile, like this:
obj-y += foo.o
CFLAGS_foo.o := <some-flags>
obj-y += dir/foo.o
CFLAGS_dir/foo.o := <other-flags>
At first, I attempted to replace $(basetarget) with $*. The $* variable
is replaced with the stem ('%') part in a pattern rule. This works with
most of cases, but does not for explicit rules.
For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
explicit rules, so $* will be empty, resulting in ignoring the per-file
AFLAGS.
I introduced a new variable, target-stem, which can be used also from
explicit rules.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Marc Zyngier <maz@kernel.org>
2019-08-30 12:34:01 +08:00
|
|
|
CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
|
2017-10-25 02:15:47 +08:00
|
|
|
|
2019-06-26 22:36:17 +08:00
|
|
|
subdir-ccflags-y += -I$(srctree)/$(src)
|
2019-04-25 01:48:39 +08:00
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
# Please keep these build lists sorted!
|
|
|
|
|
|
|
|
# core driver code
|
2019-04-03 21:52:36 +08:00
|
|
|
i915-y += i915_drv.o \
|
2020-05-09 18:50:21 +08:00
|
|
|
i915_config.o \
|
2015-07-24 19:55:10 +08:00
|
|
|
i915_irq.o \
|
2019-08-07 22:20:41 +08:00
|
|
|
i915_getparam.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_params.o \
|
2016-06-24 21:00:26 +08:00
|
|
|
i915_pci.o \
|
2019-05-28 17:29:50 +08:00
|
|
|
i915_scatterlist.o \
|
2018-12-05 19:06:08 +08:00
|
|
|
i915_suspend.o \
|
2019-10-04 20:20:18 +08:00
|
|
|
i915_switcheroo.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_sysfs.o \
|
2019-08-08 21:42:43 +08:00
|
|
|
i915_utils.o \
|
2016-07-05 17:40:20 +08:00
|
|
|
intel_device_info.o \
|
2020-02-25 19:15:07 +08:00
|
|
|
intel_dram.o \
|
2019-10-09 00:01:14 +08:00
|
|
|
intel_memory_region.o \
|
2019-08-07 20:04:15 +08:00
|
|
|
intel_pch.o \
|
2014-09-30 16:56:38 +08:00
|
|
|
intel_pm.o \
|
2018-04-11 00:12:46 +08:00
|
|
|
intel_runtime_pm.o \
|
2019-06-13 16:44:16 +08:00
|
|
|
intel_sideband.o \
|
|
|
|
intel_uncore.o \
|
2020-02-12 22:40:57 +08:00
|
|
|
intel_wakeref.o \
|
|
|
|
vlv_suspend.o
|
2019-04-25 01:48:39 +08:00
|
|
|
|
|
|
|
# core library code
|
|
|
|
i915-y += \
|
|
|
|
i915_memcpy.o \
|
|
|
|
i915_mm.o \
|
|
|
|
i915_sw_fence.o \
|
2019-08-22 03:16:06 +08:00
|
|
|
i915_sw_fence_work.o \
|
2019-04-25 01:48:39 +08:00
|
|
|
i915_syncmap.o \
|
|
|
|
i915_user_extensions.o
|
2014-09-30 16:56:38 +08:00
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
i915-$(CONFIG_COMPAT) += i915_ioc32.o
|
2019-12-05 23:43:40 +08:00
|
|
|
i915-$(CONFIG_DEBUG_FS) += \
|
|
|
|
i915_debugfs.o \
|
|
|
|
i915_debugfs_params.o \
|
2020-02-12 00:14:51 +08:00
|
|
|
display/intel_display_debugfs.o \
|
2019-12-05 23:43:40 +08:00
|
|
|
display/intel_pipe_crc.o
|
drm/i915/pmu: Expose a PMU interface for perf queries
From: Chris Wilson <chris@chris-wilson.co.uk>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
From: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
Functionality we are exporting to userspace is via the existing perf PMU
API and can be exercised via the existing tools. For example:
perf stat -a -e i915/rcs0-busy/ -I 1000
Will print the render engine busynnes once per second. All the performance
counters can be enumerated (perf list) and have their unit of measure
correctly reported in sysfs.
v1-v2 (Chris Wilson):
v2: Use a common timer for the ring sampling.
v3: (Tvrtko Ursulin)
* Decouple uAPI from i915 engine ids.
* Complete uAPI defines.
* Refactor some code to helpers for clarity.
* Skip sampling disabled engines.
* Expose counters in sysfs.
* Pass in fake regs to avoid null ptr deref in perf core.
* Convert to class/instance uAPI.
* Use shared driver code for rc6 residency, power and frequency.
v4: (Dmitry Rogozhkin)
* Register PMU with .task_ctx_nr=perf_invalid_context
* Expose cpumask for the PMU with the single CPU in the mask
* Properly support pmu->stop(): it should call pmu->read()
* Properly support pmu->del(): it should call stop(event, PERF_EF_UPDATE)
* Introduce refcounting of event subscriptions.
* Make pmu.busy_stats a refcounter to avoid busy stats going away
with some deleted event.
* Expose cpumask for i915 PMU to avoid multiple events creation of
the same type followed by counter aggregation by perf-stat.
* Track CPUs getting online/offline to migrate perf context. If (likely)
cpumask will initially set CPU0, CONFIG_BOOTPARAM_HOTPLUG_CPU0 will be
needed to see effect of CPU status tracking.
* End result is that only global events are supported and perf stat
works correctly.
* Deny perf driver level sampling - it is prohibited for uncore PMU.
v5: (Tvrtko Ursulin)
* Don't hardcode number of engine samplers.
* Rewrite event ref-counting for correctness and simplicity.
* Store initial counter value when starting already enabled events
to correctly report values to all listeners.
* Fix RC6 residency readout.
* Comments, GPL header.
v6:
* Add missing entry to v4 changelog.
* Fix accounting in CPU hotplug case by copying the approach from
arch/x86/events/intel/cstate.c. (Dmitry Rogozhkin)
v7:
* Log failure message only on failure.
* Remove CPU hotplug notification state on unregister.
v8:
* Fix error unwind on failed registration.
* Checkpatch cleanup.
v9:
* Drop the energy metric, it is available via intel_rapl_perf.
(Ville Syrjälä)
* Use HAS_RC6(p). (Chris Wilson)
* Handle unsupported non-engine events. (Dmitry Rogozhkin)
* Rebase for intel_rc6_residency_ns needing caller managed
runtime pm.
* Drop HAS_RC6 checks from the read callback since creating those
events will be rejected at init time already.
* Add counter units to sysfs so perf stat output is nicer.
* Cleanup the attribute tables for brevity and readability.
v10:
* Fixed queued accounting.
v11:
* Move intel_engine_lookup_user to intel_engine_cs.c
* Commit update. (Joonas Lahtinen)
v12:
* More accurate sampling. (Chris Wilson)
* Store and report frequency in MHz for better usability from
perf stat.
* Removed metrics: queued, interrupts, rc6 counters.
* Sample engine busyness based on seqno difference only
for less MMIO (and forcewake) on all platforms. (Chris Wilson)
v13:
* Comment spelling, use mul_u32_u32 to work around potential GCC
issue and somne code alignment changes. (Chris Wilson)
v14:
* Rebase.
v15:
* Rebase for RPS refactoring.
v16:
* Use the dynamic slot in the CPU hotplug state machine so that we are
free to setup our state as multi-instance. Previously we were re-using
the CPUHP_AP_PERF_X86_UNCORE_ONLINE slot which is neither used as
multi-instance, nor owned by our driver to start with.
* Register the CPU hotplug handlers after the PMU, otherwise the callback
will get called before the PMU is initialized which can end up in
perf_pmu_migrate_context with an un-initialized base.
* Added workaround for a probable bug in cpuhp core.
v17:
* Remove workaround for the cpuhp bug.
v18:
* Rebase for drm_i915_gem_engine_class getting upstream before us.
v19:
* Rebase. (trivial)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121181852.16128-2-tvrtko.ursulin@linux.intel.com
2017-11-22 02:18:45 +08:00
|
|
|
i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
|
2014-03-07 16:17:21 +08:00
|
|
|
|
2019-04-25 01:48:39 +08:00
|
|
|
# "Graphics Technology" (aka we talk to the gpu)
|
|
|
|
gt-y += \
|
2019-12-22 22:40:46 +08:00
|
|
|
gt/debugfs_engines.o \
|
|
|
|
gt/debugfs_gt.o \
|
|
|
|
gt/debugfs_gt_pm.o \
|
2020-06-01 15:24:12 +08:00
|
|
|
gt/gen2_engine_cs.o \
|
|
|
|
gt/gen6_engine_cs.o \
|
2020-01-07 21:40:09 +08:00
|
|
|
gt/gen6_ppgtt.o \
|
2020-03-06 08:09:57 +08:00
|
|
|
gt/gen7_renderclear.o \
|
2020-01-07 21:40:09 +08:00
|
|
|
gt/gen8_ppgtt.o \
|
2019-04-25 01:48:39 +08:00
|
|
|
gt/intel_breadcrumbs.o \
|
|
|
|
gt/intel_context.o \
|
2020-02-26 03:22:05 +08:00
|
|
|
gt/intel_context_param.o \
|
2020-01-31 18:45:42 +08:00
|
|
|
gt/intel_context_sseu.o \
|
2019-04-25 01:48:39 +08:00
|
|
|
gt/intel_engine_cs.o \
|
2019-10-22 01:43:39 +08:00
|
|
|
gt/intel_engine_heartbeat.o \
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
gt/intel_engine_pm.o \
|
2019-08-06 20:43:00 +08:00
|
|
|
gt/intel_engine_user.o \
|
2020-01-07 21:40:09 +08:00
|
|
|
gt/intel_ggtt.o \
|
2020-03-16 19:38:43 +08:00
|
|
|
gt/intel_ggtt_fencing.o \
|
2019-06-21 15:07:41 +08:00
|
|
|
gt/intel_gt.o \
|
2020-04-30 19:18:12 +08:00
|
|
|
gt/intel_gt_buffer_pool.o \
|
2020-04-25 00:28:05 +08:00
|
|
|
gt/intel_gt_clock_utils.o \
|
2019-08-12 05:06:33 +08:00
|
|
|
gt/intel_gt_irq.o \
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 04:07:17 +08:00
|
|
|
gt/intel_gt_pm.o \
|
2019-08-11 22:28:00 +08:00
|
|
|
gt/intel_gt_pm_irq.o \
|
2019-10-04 21:40:06 +08:00
|
|
|
gt/intel_gt_requests.o \
|
2020-01-07 21:40:09 +08:00
|
|
|
gt/intel_gtt.o \
|
2019-10-21 02:41:39 +08:00
|
|
|
gt/intel_llc.o \
|
2019-04-25 01:48:39 +08:00
|
|
|
gt/intel_lrc.o \
|
2019-10-24 18:03:44 +08:00
|
|
|
gt/intel_mocs.o \
|
2020-01-07 21:40:09 +08:00
|
|
|
gt/intel_ppgtt.o \
|
2019-09-27 19:08:49 +08:00
|
|
|
gt/intel_rc6.o \
|
2019-07-04 17:19:25 +08:00
|
|
|
gt/intel_renderstate.o \
|
2019-04-25 01:48:39 +08:00
|
|
|
gt/intel_reset.o \
|
2019-10-24 18:03:44 +08:00
|
|
|
gt/intel_ring.o \
|
|
|
|
gt/intel_ring_submission.o \
|
2019-10-25 05:16:41 +08:00
|
|
|
gt/intel_rps.o \
|
2019-04-25 01:48:39 +08:00
|
|
|
gt/intel_sseu.o \
|
2020-07-08 08:39:52 +08:00
|
|
|
gt/intel_sseu_debugfs.o \
|
2019-06-21 15:08:10 +08:00
|
|
|
gt/intel_timeline.o \
|
2020-02-28 21:17:10 +08:00
|
|
|
gt/intel_workarounds.o \
|
drm/i915/gt: Keep a no-frills swappable copy of the default context state
We need to keep the default context state around to instantiate new
contexts (aka golden rendercontext), and we also keep it pinned while
the engine is active so that we can quickly reset a hanging context.
However, the default contexts are large enough to merit keeping in
swappable memory as opposed to kernel memory, so we store them inside
shmemfs. Currently, we use the normal GEM objects to create the default
context image, but we can throw away all but the shmemfs file.
This greatly simplifies the tricky power management code which wants to
run underneath the normal GT locking, and we definitely do not want to
use any high level objects that may appear to recurse back into the GT.
Though perhaps the primary advantage of the complex GEM object is that
we aggressively cache the mapping, but here we are recreating the
vm_area everytime time we unpark. At the worst, we add a lightweight
cache, but first find a microbenchmark that is impacted.
Having started to create some utility functions to make working with
shmemfs objects easier, we can start putting them to wider use, where
GEM objects are overkill, such as storing persistent error state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429172429.6054-1-chris@chris-wilson.co.uk
2020-04-30 01:24:29 +08:00
|
|
|
gt/shmem_utils.o \
|
2020-02-28 21:17:10 +08:00
|
|
|
gt/sysfs_engines.o
|
2019-07-04 17:19:25 +08:00
|
|
|
# autogenerated null render state
|
|
|
|
gt-y += \
|
|
|
|
gt/gen6_renderstate.o \
|
|
|
|
gt/gen7_renderstate.o \
|
|
|
|
gt/gen8_renderstate.o \
|
|
|
|
gt/gen9_renderstate.o
|
2019-04-25 01:48:39 +08:00
|
|
|
i915-y += $(gt-y)
|
|
|
|
|
|
|
|
# GEM (Graphics Execution Management) code
|
2019-05-28 17:29:44 +08:00
|
|
|
gem-y += \
|
2019-05-28 17:29:53 +08:00
|
|
|
gem/i915_gem_busy.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_clflush.o \
|
2019-05-29 20:31:08 +08:00
|
|
|
gem/i915_gem_client_blt.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_context.o \
|
|
|
|
gem/i915_gem_dmabuf.o \
|
2019-05-28 17:29:48 +08:00
|
|
|
gem/i915_gem_domain.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_execbuffer.o \
|
2019-05-28 17:29:51 +08:00
|
|
|
gem/i915_gem_fence.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_internal.o \
|
2019-05-28 17:29:45 +08:00
|
|
|
gem/i915_gem_object.o \
|
2019-05-29 20:31:08 +08:00
|
|
|
gem/i915_gem_object_blt.o \
|
2019-10-25 23:37:22 +08:00
|
|
|
gem/i915_gem_lmem.o \
|
2019-05-28 17:29:47 +08:00
|
|
|
gem/i915_gem_mman.o \
|
2019-05-28 17:29:46 +08:00
|
|
|
gem/i915_gem_pages.o \
|
|
|
|
gem/i915_gem_phys.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_pm.o \
|
2019-10-09 00:01:14 +08:00
|
|
|
gem/i915_gem_region.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_shmem.o \
|
|
|
|
gem/i915_gem_shrinker.o \
|
|
|
|
gem/i915_gem_stolen.o \
|
2019-05-28 17:29:54 +08:00
|
|
|
gem/i915_gem_throttle.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gem_tiling.o \
|
|
|
|
gem/i915_gem_userptr.o \
|
2019-05-28 17:29:52 +08:00
|
|
|
gem/i915_gem_wait.o \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/i915_gemfs.o
|
2019-02-05 21:00:02 +08:00
|
|
|
i915-y += \
|
2019-05-28 17:29:44 +08:00
|
|
|
$(gem-y) \
|
2019-02-05 21:00:02 +08:00
|
|
|
i915_active.o \
|
2019-08-10 04:29:24 +08:00
|
|
|
i915_buddy.o \
|
2019-02-05 21:00:02 +08:00
|
|
|
i915_cmd_parser.o \
|
2010-08-07 18:01:23 +08:00
|
|
|
i915_gem_evict.o \
|
2010-11-26 02:00:26 +08:00
|
|
|
i915_gem_gtt.o \
|
2014-03-07 16:17:21 +08:00
|
|
|
i915_gem.o \
|
2019-02-28 18:20:33 +08:00
|
|
|
i915_globals.o \
|
2018-03-06 20:28:56 +08:00
|
|
|
i915_query.o \
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request.o \
|
2018-10-01 22:47:54 +08:00
|
|
|
i915_scheduler.o \
|
2009-08-25 18:15:50 +08:00
|
|
|
i915_trace_points.o \
|
2016-11-11 18:43:54 +08:00
|
|
|
i915_vma.o \
|
2019-10-25 23:37:22 +08:00
|
|
|
intel_region_lmem.o \
|
2018-03-14 08:32:50 +08:00
|
|
|
intel_wopcm.o
|
2014-03-07 16:17:21 +08:00
|
|
|
|
2015-08-12 22:43:36 +08:00
|
|
|
# general-purpose microcontroller (GuC) support
|
2019-07-13 18:00:11 +08:00
|
|
|
i915-y += gt/uc/intel_uc.o \
|
2020-03-27 02:11:20 +08:00
|
|
|
gt/uc/intel_uc_debugfs.o \
|
2019-07-13 18:00:11 +08:00
|
|
|
gt/uc/intel_uc_fw.o \
|
|
|
|
gt/uc/intel_guc.o \
|
|
|
|
gt/uc/intel_guc_ads.o \
|
|
|
|
gt/uc/intel_guc_ct.o \
|
2020-03-27 02:11:20 +08:00
|
|
|
gt/uc/intel_guc_debugfs.o \
|
2019-07-13 18:00:11 +08:00
|
|
|
gt/uc/intel_guc_fw.o \
|
|
|
|
gt/uc/intel_guc_log.o \
|
2020-03-27 02:11:20 +08:00
|
|
|
gt/uc/intel_guc_log_debugfs.o \
|
2019-07-13 18:00:11 +08:00
|
|
|
gt/uc/intel_guc_submission.o \
|
|
|
|
gt/uc/intel_huc.o \
|
2020-03-27 02:11:20 +08:00
|
|
|
gt/uc/intel_huc_debugfs.o \
|
2019-07-13 18:00:11 +08:00
|
|
|
gt/uc/intel_huc_fw.o
|
2015-08-12 22:43:36 +08:00
|
|
|
|
2014-03-07 16:17:21 +08:00
|
|
|
# modesetting core code
|
2019-06-13 16:44:16 +08:00
|
|
|
i915-y += \
|
|
|
|
display/intel_atomic.o \
|
|
|
|
display/intel_atomic_plane.o \
|
|
|
|
display/intel_audio.o \
|
|
|
|
display/intel_bios.o \
|
|
|
|
display/intel_bw.o \
|
|
|
|
display/intel_cdclk.o \
|
|
|
|
display/intel_color.o \
|
|
|
|
display/intel_combo_phy.o \
|
|
|
|
display/intel_connector.o \
|
2020-02-12 00:14:50 +08:00
|
|
|
display/intel_csr.o \
|
2019-06-13 16:44:16 +08:00
|
|
|
display/intel_display.o \
|
|
|
|
display/intel_display_power.o \
|
|
|
|
display/intel_dpio_phy.o \
|
|
|
|
display/intel_dpll_mgr.o \
|
2019-09-20 19:59:22 +08:00
|
|
|
display/intel_dsb.o \
|
2019-06-13 16:44:16 +08:00
|
|
|
display/intel_fbc.o \
|
|
|
|
display/intel_fifo_underrun.o \
|
|
|
|
display/intel_frontbuffer.o \
|
2020-01-21 01:47:24 +08:00
|
|
|
display/intel_global_state.o \
|
2019-06-13 16:44:16 +08:00
|
|
|
display/intel_hdcp.o \
|
|
|
|
display/intel_hotplug.o \
|
|
|
|
display/intel_lpe_audio.o \
|
|
|
|
display/intel_overlay.o \
|
|
|
|
display/intel_psr.o \
|
|
|
|
display/intel_quirks.o \
|
2019-06-28 22:36:15 +08:00
|
|
|
display/intel_sprite.o \
|
2019-10-01 23:25:06 +08:00
|
|
|
display/intel_tc.o \
|
|
|
|
display/intel_vga.o
|
2019-06-13 16:44:16 +08:00
|
|
|
i915-$(CONFIG_ACPI) += \
|
|
|
|
display/intel_acpi.o \
|
|
|
|
display/intel_opregion.o
|
|
|
|
i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
|
|
|
|
display/intel_fbdev.o
|
2014-03-07 16:17:21 +08:00
|
|
|
|
|
|
|
# modesetting output/encoder code
|
2019-06-13 16:44:15 +08:00
|
|
|
i915-y += \
|
|
|
|
display/dvo_ch7017.o \
|
|
|
|
display/dvo_ch7xxx.o \
|
|
|
|
display/dvo_ivch.o \
|
|
|
|
display/dvo_ns2501.o \
|
|
|
|
display/dvo_sil164.o \
|
|
|
|
display/dvo_tfp410.o \
|
|
|
|
display/icl_dsi.o \
|
|
|
|
display/intel_crt.o \
|
|
|
|
display/intel_ddi.o \
|
|
|
|
display/intel_dp.o \
|
|
|
|
display/intel_dp_aux_backlight.o \
|
|
|
|
display/intel_dp_link_training.o \
|
|
|
|
display/intel_dp_mst.o \
|
|
|
|
display/intel_dsi.o \
|
|
|
|
display/intel_dsi_dcs_backlight.o \
|
|
|
|
display/intel_dsi_vbt.o \
|
|
|
|
display/intel_dvo.o \
|
|
|
|
display/intel_gmbus.o \
|
|
|
|
display/intel_hdmi.o \
|
|
|
|
display/intel_lspcon.o \
|
|
|
|
display/intel_lvds.o \
|
|
|
|
display/intel_panel.o \
|
|
|
|
display/intel_sdvo.o \
|
|
|
|
display/intel_tv.o \
|
|
|
|
display/intel_vdsc.o \
|
|
|
|
display/vlv_dsi.o \
|
|
|
|
display/vlv_dsi_pll.o
|
2013-10-09 15:18:51 +08:00
|
|
|
|
2019-06-26 20:38:26 +08:00
|
|
|
i915-y += i915_perf.o
|
|
|
|
|
2016-10-12 17:05:18 +08:00
|
|
|
# Post-mortem debug and GPU hang state capture
|
|
|
|
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
|
2017-02-14 01:15:12 +08:00
|
|
|
i915-$(CONFIG_DRM_I915_SELFTEST) += \
|
2019-05-28 17:29:49 +08:00
|
|
|
gem/selftests/igt_gem_utils.o \
|
2017-02-14 01:15:12 +08:00
|
|
|
selftests/i915_random.o \
|
2018-05-05 17:10:13 +08:00
|
|
|
selftests/i915_selftest.o \
|
2020-01-03 18:45:15 +08:00
|
|
|
selftests/igt_atomic.o \
|
2018-11-30 16:02:53 +08:00
|
|
|
selftests/igt_flush_test.o \
|
2019-01-22 06:20:47 +08:00
|
|
|
selftests/igt_live_test.o \
|
2019-11-08 02:06:00 +08:00
|
|
|
selftests/igt_mmap.o \
|
2018-12-03 20:50:11 +08:00
|
|
|
selftests/igt_reset.o \
|
2020-04-17 23:20:17 +08:00
|
|
|
selftests/igt_spinner.o \
|
|
|
|
selftests/librapl.o
|
2016-10-12 17:05:18 +08:00
|
|
|
|
2015-02-10 19:05:47 +08:00
|
|
|
# virtual gpu code
|
|
|
|
i915-y += i915_vgpu.o
|
|
|
|
|
drm/i915: gvt: Introduce the basic architecture of GVT-g
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v12:
- Call intel_gvt_init() in driver early initialization stage. (Chris)
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig. (Joonas)
- Remove the macro GVT_ALIGN(), use round_down() instead. (Joonas)
- Make "struct intel_gvt" a data member in struct drm_i915_private.(Joonas)
- Remove {alloc, free}_gvt_device()
- Rename intel_gvt_{create, destroy}_gvt_device()
- Expost intel_gvt_init_host()
- Remove the dummy "struct intel_gvt" declaration in intel_gvt.h (Joonas)
v6:
- Refine introduction in Kconfig. (Chris)
- The exposed API functions will take struct intel_gvt * instead of
void *. (Chris/Tvrtko)
- Remove most memebers of strct intel_gvt_device_info. Will add them
in the device model patches.(Chris)
- Remove gvt_info() and gvt_err() in debug.h. (Chris)
- Move GVT kernel parameter into i915_params. (Chris)
- Remove include/drm/i915_gvt.h, as GVT-g will be built within i915.
- Remove the redundant struct i915_gvt *, as the functions in i915
will directly take struct intel_gvt *.
- Add more comments for reviewer.
v5:
Take Tvrtko's comments:
- Fix the misspelled words in Kconfig
- Let functions take drm_i915_private * instead of struct drm_device *
- Remove redundant prints/local varible initialization
v3:
Take Joonas' comments:
- Change file name i915_gvt.* to intel_gvt.*
- Move GVT kernel parameter into intel_gvt.c
- Remove redundant debug macros
- Change error handling style
- Add introductions for some stub functions
- Introduce drm/i915_gvt.h.
Take Kevin's comments:
- Move GVT-g host/guest check into intel_vgt_balloon in i915_gem_gtt.c
v2:
- Introduce i915_gvt.c.
It's necessary to introduce the stubs between i915 driver and GVT-g host,
as GVT-g components is configurable in kernel config. When disabled, the
stubs here do nothing.
Take Joonas' comments:
- Replace boolean return value with int.
- Replace customized info/warn/debug macros with DRM macros.
- Document all non-static functions like i915.
- Remove empty and unused functions.
- Replace magic number with marcos.
- Set GVT-g in kernel config to "n" by default.
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466078825-6662-5-git-send-email-zhi.a.wang@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-06-16 20:07:00 +08:00
|
|
|
ifeq ($(CONFIG_DRM_I915_GVT),y)
|
|
|
|
i915-y += intel_gvt.o
|
|
|
|
include $(src)/gvt/Makefile
|
|
|
|
endif
|
|
|
|
|
2016-08-19 23:54:28 +08:00
|
|
|
obj-$(CONFIG_DRM_I915) += i915.o
|
2018-12-07 16:16:53 +08:00
|
|
|
obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
|
2019-12-19 23:56:52 +08:00
|
|
|
|
|
|
|
# header test
|
|
|
|
|
|
|
|
# exclude some broken headers from the test coverage
|
|
|
|
no-header-test := \
|
|
|
|
display/intel_vbt_defs.h \
|
|
|
|
gvt/execlist.h \
|
|
|
|
gvt/fb_decoder.h \
|
|
|
|
gvt/gtt.h \
|
|
|
|
gvt/gvt.h \
|
|
|
|
gvt/interrupt.h \
|
|
|
|
gvt/mmio_context.h \
|
|
|
|
gvt/mpt.h \
|
2020-01-03 18:45:16 +08:00
|
|
|
gvt/scheduler.h
|
2019-12-19 23:56:52 +08:00
|
|
|
|
|
|
|
extra-$(CONFIG_DRM_I915_WERROR) += \
|
|
|
|
$(patsubst %.h,%.hdrtest, $(filter-out $(no-header-test), \
|
|
|
|
$(shell cd $(srctree)/$(src) && find * -name '*.h')))
|
|
|
|
|
|
|
|
quiet_cmd_hdrtest = HDRTEST $(patsubst %.hdrtest,%.h,$@)
|
2020-02-21 18:54:14 +08:00
|
|
|
cmd_hdrtest = $(CC) $(filter-out $(CFLAGS_GCOV), $(c_flags)) -S -o /dev/null -x c /dev/null -include $<; touch $@
|
2019-12-19 23:56:52 +08:00
|
|
|
|
|
|
|
$(obj)/%.hdrtest: $(src)/%.h FORCE
|
|
|
|
$(call if_changed_dep,hdrtest)
|