Stanislav Lisovskiy
ce52ad5dd5
drm/i915: Fix wrong escape clock divisor init for GLK
...
According to Bspec clock divisor registers in GeminiLake
should be initialized by shifting 1(<<) to amount of correspondent
divisor. While i915 was writing all this time that value as is.
Surprisingly that it by accident worked, until we met some issues
with Microtech Etab.
v2: Added Fixes tag and cc
v3: Added stable to cc as well.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com >
Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com >
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826
Fixes: bcc6570048 ("drm/i915/glk: Program txesc clock divider for GLK")
Cc: Deepak M <m.deepak@intel.com >
Cc: Madhav Chauhan <madhav.chauhan@intel.com >
Cc: Jani Nikula <jani.nikula@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: intel-gfx@lists.freedesktop.org
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com
2019-08-05 11:30:54 +03:00
Chris Wilson
b40d73784f
drm/i915: Replace struct_mutex for batch pool serialisation
...
Switch to tracking activity via i915_active on individual nodes, only
keeping a list of retired objects in the cache, and reaping the cache
when the engine itself idles.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-2-chris@chris-wilson.co.uk
2019-08-04 14:31:18 +01:00
Chris Wilson
a4e57f9031
drm/i915: Teach execbuffer to take the engine wakeref not GT
...
In the next patch, we would like to couple into the engine wakeref to
free the batch pool on idling. The caveat here is that we therefore want
to track the engine wakeref more precisely and to hold it instead of the
broader GT wakeref as we process the ioctl.
v2: Avoid introducing odd semantics for a shortlived timeline->mutex
acquisition interface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-1-chris@chris-wilson.co.uk
2019-08-04 14:31:17 +01:00
Chris Wilson
515b8b7e93
drm/i915: Flush the freed object list on file close
...
As we increase the number of RCU objects, it becomes easier for us to
have several hundred thousand objects in the deferred RCU free queues.
An example is gem_ctx_create/files which continually creates active
contexts, which are not immediately freed upon close as they are kept
alive by outstanding requests. This lack of backpressure allows the
context objects to persist until they overwhelm and starve the system.
We can increase our backpressure by flushing the freed object queue upon
closing the device fd which should then not impact other clients.
Testcase: igt/gem_ctx_create/*files
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-2-chris@chris-wilson.co.uk
2019-08-02 23:39:48 +01:00
Chris Wilson
1aff1903d0
drm/i915: Hide unshrinkable context objects from the shrinker
...
The shrinker cannot touch objects used by the contexts (logical state
and ring). Currently we mark those as "pin_global" to let the shrinker
skip over them, however, if we remove them from the shrinker lists
entirely, we don't event have to include them in our shrink accounting.
By keeping the unshrinkable objects in our shrinker tracking, we report
a large number of objects available to be shrunk, and leave the shrinker
deeply unsatisfied when we fail to reclaim those. The shrinker will
persist in trying to reclaim the unavailable objects, forcing the system
into a livelock (not even hitting the dread oomkiller).
v2: Extend unshrinkable protection for perma-pinned scratch and guc
allocations (Tvrtko)
v3: Notice that we should be pinned when marking unshrinkable and so the
link cannot be empty; merge duplicate paths.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-1-chris@chris-wilson.co.uk
2019-08-02 23:39:46 +01:00
Michal Wajdeczko
6bd0fbe156
drm/i915/wopcm: Don't fail on WOPCM partitioning failure
...
We don't have to immediately fail on WOPCM partitioning, we can wait
until we will start programming WOPCM registers. This should give us
more options if we decide to restore fallback in case of GuC failures.
v3: rebased
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-7-michal.wajdeczko@intel.com
2019-08-02 21:14:32 +01:00
Michal Wajdeczko
5d1ef2b427
drm/i915/uc: Inject probe errors into intel_uc_init_hw
...
Inject probe errors into intel_uc_init_hw to make sure we
correctly handle any uC initialization failure.
To avoid complains from CI about injected errors use
i915_probe_error to lower message level.
v4: rebased after moving hot fixes moved to separate patches
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk > #v1
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-6-michal.wajdeczko@intel.com
2019-08-02 21:14:32 +01:00
Michal Wajdeczko
32ff76e80c
drm/i915/uc: Move GuC error log to uc and release it on fini
...
When we fail to load GuC and want to abort probe, we hit:
<7> [229.915779] i915 0000:00:02.0: [drm:intel_uc_init_hw [i915]] GuC initialization failed -6
<7> [229.915813] i915 0000:00:02.0: [drm:i915_gem_init_hw [i915]] Enabling uc failed (-6)
<4> [229.953354] ------------[ cut here ]------------
<4> [229.953355] WARN_ON(dev_priv->mm.shrink_count)
<4> [229.953406] WARNING: CPU: 9 PID: 3287 at drivers/gpu/drm/i915/i915_gem.c:1684 i915_gem_cleanup_early+0xfc/0x110 [i915]
<4> [229.953464] Call Trace:
<4> [229.953489] i915_driver_late_release+0x19/0x60 [i915]
<4> [229.953514] i915_driver_probe+0xb82/0x18a0 [i915]
<4> [229.953519] ? __pm_runtime_resume+0x4f/0x80
<4> [229.953545] i915_pci_probe+0x43/0x1b0 [i915]
...
<4> [229.962951] ------------[ cut here ]------------
<4> [229.962956] DEBUG_LOCKS_WARN_ON(lock->magic != lock)
<4> [229.962959] WARNING: CPU: 8 PID: 2395 at kernel/locking/mutex.c:912 __mutex_lock+0x750/0x9b0
<4> [229.963091] Call Trace:
<4> [229.963129] ? i915_vma_destroy+0x86/0x350 [i915]
<4> [229.963166] ? i915_vma_destroy+0x86/0x350 [i915]
<4> [229.963201] i915_vma_destroy+0x86/0x350 [i915]
<4> [229.963236] __i915_gem_free_objects+0xb8/0x510 [i915]
<4> [229.963270] __i915_gem_free_work+0x5a/0x90 [i915]
<4> [229.963275] process_one_work+0x245/0x610
as since commit 6f76098fe0 ("drm/i915/uc: Move uC early functions
inside the GT ones") we cleanup uc after gem.
Move captured GuC load error log to uc struct and release it
in intel_uc_fini() instead of intel_uc_driver_late_release()
Note that intel_uc_driver_late_release() is now empty, but
we can leave it as a placeholder for future code.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-5-michal.wajdeczko@intel.com
2019-08-02 21:14:32 +01:00
Michal Wajdeczko
3243bd096b
drm/i915/uc: Reorder firmware status codes
...
On Gen9 when we try to reload HuC due to GuC upload error, we hit:
<7> [232.025927] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s)
<7> [232.026004] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin
<7> [232.026686] [drm:intel_uc_fw_upload [i915]] HuC fw xfer completed
<6> [232.026688] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)
<3> [232.026703] intel_uc_fw_copy_rsa:541 GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw))
as firmware that previously failed to load was wrongly treated as
unavailable since its status code was not matching status check logic.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-4-michal.wajdeczko@intel.com
2019-08-02 21:14:32 +01:00
Michal Wajdeczko
771051eaa7
drm/i915/uc: Do full sanitize instead of pure reset
...
On Gen9 when we try to reload HuC due to GuC upload error, we hit:
<7> [229.656688] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s)
<7> [229.656739] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin
<3> [229.656740] intel_uc_fw_upload:425 GEM_BUG_ON(intel_uc_fw_is_loaded(uc_fw))
as we performed only pure reset and didn't sanitized HuC fw status.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-3-michal.wajdeczko@intel.com
2019-08-02 21:14:32 +01:00
Michal Wajdeczko
50d84418f5
drm/i915: Add i915 to i915_inject_probe_failure
...
With i915 added to i915_inject_probe_failure we can use dedicated
printk when injecting artificial load failure.
Also make this function look like other i915 functions that return
error code and make it more flexible to return any provided error
code instead of previously assumed -ENODEV.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-2-michal.wajdeczko@intel.com
2019-08-02 21:14:29 +01:00
Chris Wilson
cd2a4eaf8c
drm/i915: Report resv_obj allocation failure
...
Since commit 64d6c500a3 ("drm/i915: Generalise GPU activity
tracking"), we have been prepared for i915_vma_move_to_active() to fail.
We can take advantage of this to report the failure for allocating the
shared-fence slot in the reservation_object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730205805.3733-1-chris@chris-wilson.co.uk
2019-08-02 16:03:53 +01:00
Michal Wajdeczko
e4661f1444
drm/i915: Fix documentation for __intel_wait_for_register_fw*
...
Use section name "Return" and proper error code -ETIMEDOUT
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802124739.12548-1-michal.wajdeczko@intel.com
2019-08-02 14:32:01 +01:00
Jani Nikula
ae0f8f0f9a
drm/i915/oa: update the generated files
...
Update the generated files to make the headers self-contained, switch to
the kernel preferred SPDX comment format, and update the copyright
year. Also add the Makefile stanza to run header tests on the files.
Other changes produced by gputop i915-perf-kernelgen.py were manually
stripped out, and left to the folks who actually know something about
the OA stuff.
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730113432.22146-3-jani.nikula@intel.com
2019-08-02 15:09:52 +03:00
Chris Wilson
d8af05ff38
drm/i915: Allow sharing the idle-barrier from other kernel requests
...
By placing our idle-barriers in the i915_active fence tree, we expose
those for reuse by other components that are issuing requests along the
kernel_context. Reusing the proto-barrier active_node is perfectly fine
as the new request implies a context-switch, and so an opportune point
to run the idle-barrier. However, the proto-barrier is not equivalent
to a normal active_node and care must be taken to avoid dereferencing the
ERR_PTR used as its request marker.
v2: Comment the more egregious cheek
v3: A glossary!
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Fixes: ce476c80b8 ("drm/i915: Keep contexts pinned until after the next kernel context switch")
Fixes: a9877da2d6 ("drm/i915/oa: Reconfigure contexts on the fly")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190802100015.1281-1-chris@chris-wilson.co.uk
2019-08-02 11:53:04 +01:00
Chris Wilson
576f058655
drm/i915: Flush extra hard after writing relocations through the GTT
...
Recently discovered in commit bdae33b8b8 ("drm/i915: Use maximum write
flush for pwrite_gtt") was that we needed to our full write barrier
before changing the GGTT PTE to ensure that our indirect writes through
the GTT landed before the PTE changed (and the writes end up in a
different page). That also applies to our GGTT relocation path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: stable@vger.kernel.org
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730112151.5633-4-chris@chris-wilson.co.uk
2019-08-02 08:38:45 +01:00
Chris Wilson
51fbd8de87
drm/i915/pmu: Atomically acquire the gt_pm wakeref
...
Currently, we only sample if the intel_gt is awake, but we acquire our
own runtime_pm wakeref. Since intel_gt has transitioned to tracking its
own wakeref, we can atomically test and acquire that wakeref instead.
v2: Take engine->wakeref for engine sampling
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801233616.23007-1-chris@chris-wilson.co.uk
2019-08-02 08:08:20 +01:00
Tvrtko Ursulin
518ea582cb
drm/i915/pmu: Make get_rc6 take intel_gt
...
RC6 is a GT state so make the function parameter reflect that.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-4-tvrtko.ursulin@linux.intel.com
2019-08-01 23:28:55 +01:00
Tvrtko Ursulin
08ce5c64b2
drm/i915/pmu: Convert sampling to gt
...
Engines and frequencies are a GT thing so adjust sampling routines to
match.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-3-tvrtko.ursulin@linux.intel.com
2019-08-01 23:28:55 +01:00
Tvrtko Ursulin
28fba0961d
drm/i915/pmu: Convert engine sampling to uncore mmio
...
Drops one macro using implicit dev_priv.
v2:
* Use ENGINE_READ_FW. (Chris)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-2-tvrtko.ursulin@linux.intel.com
2019-08-01 23:28:55 +01:00
Tvrtko Ursulin
908091c850
drm/i915/pmu: Make more struct i915_pmu centric
...
Just tidy the code a bit by removing a sea of overly verbose i915->pmu.*.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801162330.2729-1-tvrtko.ursulin@linux.intel.com
2019-08-01 23:28:55 +01:00
Jordan Justen
2b92a82fe0
drm/i915/tgl: allow the reg_read ioctl to read the RCS TIMESTAMP register
...
This enables the Mesa driver to advertise support for ARB_timer_query,
and thus an OpenGL version higher than 3.2.
Based on the ICL patch by Paulo Zanoni and CNL patch by Nanley Chery.
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-3-lucas.demarchi@intel.com
2019-08-01 14:36:54 -07:00
José Roberto de Souza
5d571068f7
drm/i915/tgl: Add and use new DC5 and DC6 residency counter registers
...
Tiger Lake has a new register offset for DC5 and DC6 residency counters.
v2:
- Rename registers since they are not in the CSR memory range
(requested by Anshuman)
- Fix type (requested by Matthew)
Signed-off-by: José Roberto de Souza <jose.souza@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190726002412.5827-2-lucas.demarchi@intel.com
2019-08-01 14:36:54 -07:00
Michal Wajdeczko
01158da721
drm/i915/uc: Stop sanitizing enable_guc modparam
...
As we already track GuC/HuC uses by other means than modparam
there is no point in sanitizing it. Just scan modparam for
major discrepancies between what was requested vs actual.
v2: rebased, reworded info messages
v3: oops
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801132840.33176-1-michal.wajdeczko@intel.com
2019-08-01 21:13:32 +01:00
Michal Wajdeczko
724df646c8
drm/i915/guc: Use dedicated flag to track submission mode
...
Instead of relying on enable_guc modparam to represent actual
GuC submission mode, use dedicated flag and look at modparam
only to check if submission was explicitly disabled by the user.
v2: rebased, simplified condition (Chris)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-4-michal.wajdeczko@intel.com
2019-08-01 21:13:29 +01:00
Michal Wajdeczko
db81bc6eb9
drm/i915/uc: Consider enable_guc modparam during fw selection
...
We can use value of enable_guc modparam during firmware path selection
and start using firmware status to see if GuC/HuC is being used.
This is first step to make enable_guc modparam read-only.
v2: rebased, don't care about <0 (Chris)
v3: oops
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-3-michal.wajdeczko@intel.com
2019-08-01 21:13:27 +01:00
Michal Wajdeczko
57a68c3507
drm/i915/uc: Rename intel_uc_is_using* into intel_uc_supports*
...
Rename intel_uc_is_using* into intel_uc_supports* to make clear
distinction from actual state (compare intel_uc_fw_is_running)
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190731223321.36436-2-michal.wajdeczko@intel.com
2019-08-01 21:13:25 +01:00
Daniele Ceraolo Spurio
9dfe3459ef
drm/i915/gt: Introduce intel_gt_runtime_suspend/resume
...
To be called from the top level runtime functions, to hide the
gt-specific bits (mainly related to intel_uc).
v2: rebased
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801005709.34092-3-daniele.ceraolospurio@intel.com
2019-08-01 17:58:54 +01:00
Daniele Ceraolo Spurio
6f76098fe0
drm/i915/uc: Move uC early functions inside the GT ones
...
uC is a subcomponent of GT, so initialize/clean it as part of it. The
wopcm_init_early doesn't have to be happen before the uC one, but since
in other parts of the code we consider WOPCM first do the same for
consistency.
v2: s/cleanup_early/late_release to match the caller
v3: s/late_release/driver_late_release/ (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com > #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801005709.34092-2-daniele.ceraolospurio@intel.com
2019-08-01 17:58:52 +01:00
Daniele Ceraolo Spurio
6cf72db68d
drm/i915/gt: Move gt_cleanup_early out of gem_cleanup_early
...
We don't call the init_early function from within the gem code, so we
shouldn't do it for the cleanup either.
v2: while at it, s/gt_cleanup_early/gt_late_release (Chris)
v3: s/late_release/driver_late_release/ (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com > #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190801005709.34092-1-daniele.ceraolospurio@intel.com
2019-08-01 17:58:50 +01:00
Chris Wilson
a1c9ca223c
drm/i915: Remove lrc default desc from GEM context
...
We only compute the lrc_descriptor() on pinning the context, i.e.
infrequently, so we do not benefit from storing the template as the
addressing mode is also fixed for the lifetime of the intel_context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com >
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730133035.1977-9-chris@chris-wilson.co.uk
2019-08-01 17:37:02 +01:00
Matt Roper
8ef7e3409c
drm/i915/ehl: Don't forget to handle port C's hotplug interrupts
...
We're mostly re-using ICL's interrupt handling on EHL, but we still need
to remember to account for the extra combo port that EHL has. Use TGP's
mask (which includes combo port C) rather than ICP's mask when
appropriate. Let's also skip reading TC-specific registers on this
platform since EHL doesn't have any TC ports.
v2: Base setup of SHOTPLUG_CTL_TC on whether the tc pin mask is non-zero
rather than performing another PCH type check. (Jose)
Cc: José Roberto de Souza <jose.souza@intel.com >
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com >
Cc: Lucas De Marchi <lucas.demarchi@intel.com >
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
Reviewed-by: José Roberto de Souza <jose.souza@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730220553.15300-1-matthew.d.roper@intel.com
2019-08-01 08:02:30 -07:00
Jani Nikula
8ad4ca6e9a
drm/i915/oa: add content to Makefile
...
Apparently the empty Makefile has caused some confusion. Add the
subdir-cc-flags-y as in 7fcc7ca549 ("drm/i915: add header search path
to subdir Makefiles") which should be useful.
The generated headers still aren't self-contained, so can't add that.
References: http://marc.info/?i=80bf2204-558a-6d3f-c493-bf17b891fc8a@infradead.org
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730113432.22146-1-jani.nikula@intel.com
2019-08-01 15:20:43 +03:00
Wei Yongjun
de70fdd7d2
drm/i915: fix possible memory leak in intel_hdcp_auth_downstream()
...
'ksv_fifo' is malloced in intel_hdcp_auth_downstream() and should be
freed before leaving from the error handling cases, otherwise it will
cause memory leak.
Fixes: f26ae6a652 ("drm/i915: SRM revocation check for HDCP1.4 and 2.2")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190704104534.12508-1-weiyongjun1@huawei.com
2019-08-01 13:08:34 +03:00
Chris Wilson
10e36489ab
drm/i915/execlists: Always clear pending&inflight requests on reset
...
If we skip the reset as we found the engine inactive at the time of the
reset, we still need to clear the residual inflight & pending request
bookkeeping to reflect the current state of HW.
Otherwise, we may end up stuck in a loop like:
<7> [416.490346] hangcheck rcs0
<7> [416.490371] hangcheck Awake? 1
<7> [416.490376] hangcheck Hangcheck: 8003 ms ago
<7> [416.490380] hangcheck Reset count: 0 (global 0)
<7> [416.490383] hangcheck Requests:
<7> [416.491210] hangcheck RING_START: 0x0017b000
<7> [416.491983] hangcheck RING_HEAD: 0x00000048
<7> [416.491992] hangcheck RING_TAIL: 0x00000048
<7> [416.492006] hangcheck RING_CTL: 0x00000000
<7> [416.492037] hangcheck RING_MODE: 0x00000200 [idle]
<7> [416.492044] hangcheck RING_IMR: 00000000
<7> [416.492809] hangcheck ACTHD: 0x00000000_9ca00048
<7> [416.492824] hangcheck BBADDR: 0x00000000_00001004
<7> [416.492838] hangcheck DMA_FADDR: 0x00000000_00000000
<7> [416.492845] hangcheck IPEIR: 0x00000000
<7> [416.492852] hangcheck IPEHR: 0x00000000
<7> [416.492863] hangcheck Execlist status: 0x00018001 00000000, entries 12
<7> [416.492869] hangcheck Execlist CSB read 1, write 1, tasklet queued? no (enabled)
<7> [416.492938] hangcheck Pending[0] ring:{start:0017b000, hwsp:fedf9000, seqno:00016fd6}, rq: 20ffa:16fd6!+ prio=-4094 @ 8307ms: signaled
<7> [416.492972] hangcheck Queue priority hint: -4093
<7> [416.492979] hangcheck Q 20ffa:16fd8- prio=-4093 @ 8307ms: [i915]
<7> [416.492985] hangcheck Q 20ffa:16fda prio=-4094 @ 8307ms: [i915]
<7> [416.492990] hangcheck Q 20ffa:16fdc prio=-4094 @ 8307ms: [i915]
<7> [416.492996] hangcheck Q 20ffa:16fde prio=-4094 @ 8307ms: [i915]
<7> [416.493001] hangcheck Q 20ffa:16fe0 prio=-4094 @ 8307ms: [i915]
<7> [416.493007] hangcheck Q 20ffa:16fe2 prio=-4094 @ 8307ms: [i915]
<7> [416.493013] hangcheck Q 20ffa:16fe4 prio=-4094 @ 8307ms: [i915]
<7> [416.493021] hangcheck ...skipping 21 queued requests...
<7> [416.493027] hangcheck Q 20ffa:17010 prio=-4094 @ 8307ms: [i915]
<7> [416.493081] hangcheck HWSP:
<7> [416.493089] hangcheck [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [416.493094] hangcheck *
<7> [416.493100] hangcheck [0040] 10008002 00000000 10000018 00000000 10000018 00000000 10000001 00000000
<7> [416.493106] hangcheck [0060] 10000018 00000000 10000001 00000000 10000018 00000000 10000001 00000000
<7> [416.493111] hangcheck *
<7> [416.493117] hangcheck [00a0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001
<7> [416.493123] hangcheck [00c0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [416.493127] hangcheck *
<7> [416.493132] hangcheck Idle? no
<6> [416.512124] i915 0000:00:02.0: GPU HANG: ecode 11:0:0x00000000, hang on rcs0
<6> [416.512205] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
<6> [416.512207] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
<6> [416.512208] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
<6> [416.512210] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
<6> [416.512212] [drm] GPU crash dump saved to /sys/class/drm/card0/error
<5> [416.513602] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
<7> [424.489258] hangcheck rcs0
<7> [424.489263] hangcheck Awake? 1
<7> [424.489267] hangcheck Hangcheck: 5954 ms ago
<7> [424.489271] hangcheck Reset count: 1 (global 0)
<7> [424.489274] hangcheck Requests:
<7> [424.490128] hangcheck RING_START: 0x00000000
<7> [424.490870] hangcheck RING_HEAD: 0x00000000
<7> [424.490877] hangcheck RING_TAIL: 0x00000000
<7> [424.490887] hangcheck RING_CTL: 0x00000000
<7> [424.490897] hangcheck RING_MODE: 0x00000200 [idle]
<7> [424.490904] hangcheck RING_IMR: 00000000
<7> [424.490917] hangcheck ACTHD: 0x00000000_00000000
<7> [424.490930] hangcheck BBADDR: 0x00000000_00000000
<7> [424.490943] hangcheck DMA_FADDR: 0x00000000_00000000
<7> [424.490950] hangcheck IPEIR: 0x00000000
<7> [424.490956] hangcheck IPEHR: 0x00000000
<7> [424.490968] hangcheck Execlist status: 0x00000001 00000000, entries 12
<7> [424.490972] hangcheck Execlist CSB read 11, write 11, tasklet queued? no (enabled)
<7> [424.490983] hangcheck Pending[0] ring:{start:0017b000, hwsp:fedf9000, seqno:00016fd6}, rq: 20ffa:16fd6!+ prio=-4094 @ 16305ms: signaled
<7> [424.490989] hangcheck Queue priority hint: -4093
<7> [424.490996] hangcheck Q 20ffa:16fd8- prio=-4093 @ 16305ms: [i915]
<7> [424.491001] hangcheck Q 20ffa:16fda prio=-4094 @ 16305ms: [i915]
<7> [424.491006] hangcheck Q 20ffa:16fdc prio=-4094 @ 16305ms: [i915]
<7> [424.491011] hangcheck Q 20ffa:16fde prio=-4094 @ 16305ms: [i915]
<7> [424.491016] hangcheck Q 20ffa:16fe0 prio=-4094 @ 16305ms: [i915]
<7> [424.491022] hangcheck Q 20ffa:16fe2 prio=-4094 @ 16305ms: [i915]
<7> [424.491048] hangcheck Q 20ffa:16fe4 prio=-4094 @ 16305ms: [i915]
<7> [424.491057] hangcheck ...skipping 21 queued requests...
<7> [424.491063] hangcheck Q 20ffa:17010 prio=-4094 @ 16305ms: [i915]
<7> [424.491095] hangcheck HWSP:
<7> [424.491102] hangcheck [0000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [424.491106] hangcheck *
<7> [424.491113] hangcheck [0040] 10008002 00000000 10000018 00000000 10000018 00000000 10000001 00000000
<7> [424.491118] hangcheck [0060] 10000018 00000000 10000001 00000000 10000018 00000000 10000001 00000000
<7> [424.491122] hangcheck *
<7> [424.491127] hangcheck [00a0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000b
<7> [424.491133] hangcheck [00c0] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [424.491136] hangcheck *
<7> [424.491141] hangcheck Idle? no
<5> [424.491834] i915 0000:00:02.0: Resetting rcs0 for hang on rcs0
Where not having cleared the pending array on reset, it persists
indefinitely.
Fixes: fff8102aae ("drm/i915/execlists: Process interrupted context on reset")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730133035.1977-2-chris@chris-wilson.co.uk
2019-08-01 09:24:59 +01:00
José Roberto de Souza
c2052d6e24
drm/i915/ehl: Ungate DDIC and DDID
...
Specification states that DDI_CLK_SEL needs to be mapped to MG clock
even if MG do not exist on EHL, this will ungate those DDIs.
BSpec: 20845
Cc: Matt Roper <matthew.d.roper@intel.com >
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com >
Signed-off-by: José Roberto de Souza <jose.souza@intel.com >
Reviewed-by: Matt Roper <matthew.d.roper@intel.com >
Tested-by: Matt Roper <matthew.d.roper@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730175121.16413-1-jose.souza@intel.com
2019-07-31 10:52:18 -07:00
Tvrtko Ursulin
1b6c3c6d46
drm/i915: Move MOCS setup to intel_mocs.c
...
Hide the details of MOCS setup from i915_gem by moving both current calls
into one in intel_mocs_init.
Cc: Stuart Summers <stuart.summers@intel.com >
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Stuart Summers <stuart.summers@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-21-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-6-lucas.demarchi@intel.com
2019-07-31 07:40:35 -07:00
Michel Thierry
a7a7a0e6eb
drm/i915/tgl: Tigerlake only has global MOCS registers
...
Until Icelake, each engine had its own set of 64 MOCS registers. In
order to simplify, Tigerlake moves to only 64 Global MOCS registers,
which are no longer part of the engine context. Since these registers
are now global, they also only need to be initialized once.
>From Gen12 onwards, MOCS must specify the target cache (3:2) and LRU
management (5:4) fields and cannot be programmed to 'use the value from
Private PAT', because these fields are no longer part of the PPAT. Also
cacheability control (1:0) field has changed, 00 no longer means 'use
controls from page table', but uncacheable (UC).
v2 (Lucas):
- Move the changes to the fault registers to a separate commit - the
old ones overlap with the range used by the new global MOCS
(requested by Daniele)
v3 (Lucas):
- Clarify comment about setting the unused entries to the same value
of index 0, that is the invalid entry (requested by Daniele)
- Move changes to DONE_REG and ERROR_GEN6 to a separate commit
(requested by Daniele)
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Michel Thierry <michel.thierry@intel.com >
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-5-lucas.demarchi@intel.com
2019-07-31 07:40:32 -07:00
Tomasz Lis
2ddf992179
drm/i915/tgl: Define MOCS entries for Tigerlake
...
The MOCS table is published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version 1 entries.
Two of the 3 legacy entries used for gen9 are no longer expected to work.
Although we are changing the gen11 table, those changes are supposed to
be backward compatible since we are only touching previously undefined
entries.
v2: Add the missing entries in 49-51 range and replace "HW reserved"
terminology to what it actually is: L1 is implicitly enabled
(from Daniele)
v3: Use a different table for Tiger Lake since entries 0 and 1 are not
the same (from Daniele)
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-4-lucas.demarchi@intel.com
2019-07-31 07:40:31 -07:00
Lucas De Marchi
23dea05191
drm/i915/tgl: stop using ERROR_GEN6 and DONE_REG
...
These registers have been removed on gen12.
v2: merge common branch for IS_GEN_RANGE(i915, 6, 11)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-3-lucas.demarchi@intel.com
2019-07-31 07:40:31 -07:00
Lucas De Marchi
91b59cd98a
drm/i915/tgl: Move fault registers to their new offset
...
The fault registers moved to another offset. The old location is now
taken by the global MOCS registers, to be added in a follow up change.
Based on previous patches by Michel Thierry <michel.thierry@intel.com >.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730180407.5993-2-lucas.demarchi@intel.com
2019-07-31 07:40:29 -07:00
Lucas De Marchi
900c9173ca
drm/i915: remove dangling forward declaration
...
Commit 20a7f2fc4d ("drm/i915: Convert intel_mocs_init_l3cc_table to
intel_gt") removed the only user.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730182614.14379-1-lucas.demarchi@intel.com
2019-07-31 07:40:10 -07:00
Daniele Ceraolo Spurio
63064d822c
drm/i915/uc: Move uC WOPCM setup in uc_init_hw
...
The register we write are not WOPCM regs but uC ones related to how
GuC and HuC are going to use the WOPCM, so it makes logical sense
for them to be programmed as part of uc_init_hw. The WOPCM map on the
other side is not uC-specific (although that is our main use-case), so
keep that separate.
v2: move write_and_verify to uncore, fix log, re-use err_out tag,
add intel_wopcm_guc_base, fix log
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730230743.19542-2-daniele.ceraolospurio@intel.com
2019-07-31 10:19:28 +01:00
Daniele Ceraolo Spurio
602776f96b
drm/i915/uc: Don't enable communication twice on resume
...
When coming out of S3/S4 we sanitize and re-init the HW, which includes
enabling communication during uc_init_hw. We therefore don't want to do
that again in uc_resume and can just tell GuC to reload its state.
v2: split uc_resume and uc_runtime_resume to match the suspend
functions and to better differentiate the expected state in the 2
scenarios (Chris)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730230743.19542-1-daniele.ceraolospurio@intel.com
2019-07-31 10:01:32 +01:00
Chris Wilson
f277bc0c98
drm/i915/selftests: Pass intel_context to igt_spinner
...
Teach igt_spinner to only use our internal structs, decoupling the
interface from the GEM contexts. This makes it easier to avoid
requiring ce->gem_context back references for kernel_context that may
have them in future.
v2: Lift engine lock to verify_wa() caller.
v3: Less than v2, but more so
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190731081126.9139-1-chris@chris-wilson.co.uk
2019-07-31 09:45:27 +01:00
Chris Wilson
cb0c43f30c
drm/i915: Avoid ce->gem_context->i915
...
My plan for the future is to have kernel contexts not to have a GEM
context backpointer (as they will not belong to any GEM context). In a
few places, we use ce->gem_context to simply obtain the i915 backpointer,
for which we can use ce->engine->i915 instead.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730163441.16477-1-chris@chris-wilson.co.uk
2019-07-31 07:43:42 +01:00
Lucas De Marchi
2e8de0879c
drm/i915: make i915_selftest.h self-contained
...
Fix build breakage:
In file included from <command-line>:
./drivers/gpu/drm/i915/i915_selftest.h:125:1: error: unknown type name ‘bool’
125 | bool __igt_timeout(unsigned long timeout, const char *fmt, ...);
| ^~~~
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20190730181759.26162-1-lucas.demarchi@intel.com
2019-07-30 13:41:35 -07:00
Lucas De Marchi
5552336014
drm/i915/tgl: handle DP aux interrupts
...
For Tiger Lake the DE Port Interrupt Definition bits changed, so use the
new bit definitions.
Cc: Jose Souza <jose.souza@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-7-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-4-lucas.demarchi@intel.com
2019-07-30 12:31:08 -07:00
José Roberto de Souza
48ef15d32a
drm/i915/tgl: Update north display hotplug detection to TGL connections
...
TGL has 3 combophys and 6 TC/TBT ports, so it has 2 more TC/TBT ports
than ICL and the PORT_C on TGL is a combophy.
So here adding a new hpd north table and function to detect long
pulse for TGL.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-6-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-3-lucas.demarchi@intel.com
2019-07-30 12:31:08 -07:00
Lucas De Marchi
52dfdba0a9
drm/i915/tgl: Add hpd interrupt handling
...
Add hotdplug detection for all ports on TGP. icp_hpd_detection_setup()
is refactored to be shared with TGP.
While we increase the number of pins, add a BUILD_BUG_ON() to avoid
going over the number of bits allowed.
v2: use BITS_PER_TYPE and correct type for BUILD_BUG_ON() check
(requested by Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Cc: Jose Souza <jose.souza@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com >
Reviewed-by: Matt Roper <matthew.d.roper@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-2-lucas.demarchi@intel.com
2019-07-30 12:31:08 -07:00