- 17 Aug, 2019 1 commit
-
-
Mika Kuoppala authored
As we give page directory pointer (lvl 3) structure for pte insertion, we can fold both versions into one function by teaching it to get pdp regardless of top level. v2: naming and asserts (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 16 Aug, 2019 17 commits
-
-
Michal Wajdeczko authored
We really need to have separate NOT_SUPPORTED state (for lack of hardware support) and DISABLED state (to indicate user decision) as we will have to take special steps even if GuC firmware is now disabled but hardware exists and could have been previously used. v2: fix logic (Chris/CI) v3: use proper check to avoid probe failure (CI) v4: explain status transitions (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:
-
Daniele Ceraolo Spurio authored
To reduce the number of explicit dev_priv->uncore calls in the display code ahead of the introduction of dev_priv->de_uncore, this patch introduces a wrapper for one of the main usages of it, the register waits. When we transition to the new uncore, we can just update the wrapper to point to the appropriate structure. Since the vast majority of waits are on a set or clear of a bit or mask, add set & clear flavours of the wrapper to simplify the code. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
They're not related to registers, so move them to the more appropriate intel_gmbus.h Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
To remove the dependency between the GT headers and i915_reg.h, move the definition of the engine IDs/classes to intel_engine_types.h Signed-off-by:
-
Daniele Ceraolo Spurio authored
It has nothing to do with registers, so move it to the more appropriate intel_display_power.h Signed-off-by:
-
Chris Wilson authored
If we only call process_csb() from the tasklet, though we lose the ability to bypass ksoftirqd interrupt processing on direct submission paths, we can push it out of the irq-off spinlock. The penalty is that we then allow schedule_out to be called concurrently with schedule_in requiring us to handle the usage count (baked into the pointer itself) atomically. As we do kick the tasklets (via local_bh_enable()) after our submission, there is a possibility there to see if we can pull the local softirq processing back from the ksoftirqd. v2: Store the 'switch_priority_hint' on submission, so that we can safely check during process_csb(). Signed-off-by:
-
Chris Wilson authored
As every i915_active_request should be serialised by a dedicated lock, i915_active consists of a tree of locks; one for each node. Markup up the i915_active_request with what lock is supposed to be guarding it so that we can verify that the serialised updated are indeed serialised. Signed-off-by:
-
Chris Wilson authored
We use timeline->mutex to protect modifications to context->active_count, and the associated enable/disable callbacks. Due to complications with engine-pm barrier there is a path where we used a "superlock" to provide serialised protect and so could not unconditionally assert with lockdep that it was always held. However, we can mark the mutex as taken (noting that we may be nested underneath ourselves) which means we can be reassured the right timeline->mutex is always treated as held and let lockdep roam free. Signed-off-by:
-
Michal Wajdeczko authored
Move SPDX tag to first line, and update year to 2019. Signed-off-by:
-
Michal Wajdeczko authored
All WOPCM error messages are device specific, so use device specific error functions. Signed-off-by:
-
Michal Wajdeczko authored
If WOPCM layout is already locked in HW we shouldn't continue with our own partitioning as it could be likely different and we will be unable to enforce it and fail. Instead we should try to reuse what is already programmed, maybe there will be a fit. This should enable us to reload driver with slightly different HuC firmware (or even without HuC) without need to reboot. v2: reordered/rebased Signed-off-by:
-
Michal Wajdeczko authored
We can do WOPCM partitioning using rough estimates and limits and perform detailed check as separate step. v2: oops! s/max/min v3: consolidate overflow checks (Daniele) Signed-off-by:
-
Michał Winiarski authored
While we need to know WOPCM size to do this sanity check, it has more to do with FW than with WOPCM. Let's move the check to fetch phase, it's not like WOPCM is going to grow in the meantime. v2: rebased v3: use __intel_uc_fw_get_upload_size (Daniele) Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Matthew Auld authored
Since nodes are cached in a free-list, and potentially marked as free without actually being destroyed, thus allowing them to be opportunistically re-allocated, we should apply kmemleak_update_trace every time a node is given a new owner and marked as allocated, to aid in debugging. Suggested-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
If we are leaking nodes don't hide it. Also stop trying to be "defensive" and instead embrace Kasan et al. Signed-off-by:
-
Chris Wilson authored
We store the gt&uncore to use in the i915_address_space, so use it! Signed-off-by:
-
Chris Wilson authored
Move the active tracking for the frontbuffer operations out of the i915_gem_object and into its own first class (refcounted) object. In the process of detangling, we switch from low level request tracking to the easier i915_active -- with the plan that this avoids any potential atomic callbacks as the frontbuffer tracking wishes to sleep as it flushes. Signed-off-by:
-
- 15 Aug, 2019 11 commits
-
-
Chris Wilson authored
Forgo the struct_mutex requirement for request retirement as we have been transitioning over to only using the timeline->mutex for controlling the lifetime of a request on that timeline. Signed-off-by:
-
Chris Wilson authored
In preparation for removing struct_mutex from around context retirement, we need to make timeline pinning and unpinning safe. Since multiple engines/contexts can share a single timeline, we cannot rely on borrowing the context mutex (otherwise we could state that the timeline is only pinned/unpinned inside the context pin/unpin and so guarded by it). However, we only perform a sequence of atomic operations inside the timeline pin/unpin and the sequence of those operations is safe for a concurrent unpin / pin, so we can relax the struct_mutex requirement. Signed-off-by:
-
Chris Wilson authored
Convert the active_list manipulation of timelines to use spinlocks so that we can perform the updates from underneath a quick interrupt callback, if need be. Signed-off-by:
-
Chris Wilson authored
Lift moving the timeline to/from the active_list on enter/exit in order to shorten the active tracking span in comparison to the existing pin/unpin. Signed-off-by:
-
Anusha Srivatsa authored
The BSpec has added three new IDS for CML. Update the IDs in accordance to the Spec. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190812222737.29356-1-anusha.srivatsa@intel.com
-
Chris Wilson authored
Since __i915_request_queue() may be called from hardirq (timer) context, we cannot use local_bh_disable/enable at the lower level. As we do want to kick the tasklet to speed up initial submission or preemption for normal client submission, lift it to the normal process context callpath. Signed-off-by:
-
Mika Kuoppala authored
Flush according to what gen11 expects when writing breadcrumbs. As only the seqnowrite + flush differs between engine and gens, enclose the footer to helper. v2: avoid problem of sane local naming by not using them Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
On the set of invalidations, we need to add command cache invalidate as a new domain. Signed-off-by:
-
Mika Kuoppala authored
Add tile cache flushing for gen11. To relive us from the burden of previous obsolete workarounds, make a dedicated flush/invalidate callback for gen11. To fortify an independent single flush, do post sync op as there are indications that without it we don't flush everything. This should also make this callback more readily usable in tgl (see l3 fabric flush). v2: whitespacing Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matthew Auld authored
Dan reported the following static checker warning: drivers/gpu/drm/i915/selftests/i915_buddy.c:670 igt_buddy_alloc_range() error: we previously assumed 'block' could be null (see line 665) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Chris Wilson authored
Looking around the GT initialisation, we have a few log messages we think are interesting enough present to the user (such as the amount of L4 cache) and a few to inform them of the result of actions or conflicting HW restrictions (i.e. quirks). These are device specific messages, so use the dev family of printk. v2: shave off a few bytes of .rodata! Signed-off-by:
-
- 14 Aug, 2019 6 commits
-
-
Chris Wilson authored
We use the request pointer inside the i915_active_node as the indicator of the barrier's status; we mark it as used during i915_request_add_active_barriers(), and search for an available barrier in reuse_idle_barrier(). That check must be carefully serialised to ensure we do use an engine for the barrier and not just a random pointer. (Along the other reuse path, we are fully serialised by the timeline->mutex.) The acquisition of the barrier itself is ordered through the strong memory barrier in llist_del_all(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111397 Fixes: d8af05ff ("drm/i915: Allow sharing the idle-barrier from other kernel requests") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190813200905.11369-1-chris@chris-wilson.co.uk
-
Stuart Summers authored
Use render class instead of RCS0 when printing CCID. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Reviewed-by:
-
Chris Wilson authored
The fb_base is only used for communicating the GTT BAR from one piece of the display code (kms setup) to another (fbdev). What is required in the fbdev is just the aperture address which should be derived from the bo we allocate for the framebuffer directly. The same appears true for drm/; it is not used by the core or the uAPI, it is merely for conveniently passing a device address from bit of display management code to another. v2: Note that since we only expose enough of a system map to cover our single framebuffer, the screen_base/size and the smem are one and the same. Signed-off-by:
-
Chris Wilson authored
Some IGT would like to know the mmio address of each engine so make it available. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The engine->guc_id is GuC FW defined and it is not guaranteed to be below I915_NUM_ENGINES, so we shouldn't use it with the i915-defined client->submissions, as we might overflow. Instead of fixing it, just get rid of client->submissions, because the information we get from it is not interesting anymore now that we only have 1 client. Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 13 Aug, 2019 5 commits
-
-
José Roberto de Souza authored
A new macro that is going to be added in a further patch will need to adjust the offset returned by _MMIO_TRANS2(), so here adding _TRANS2() and moving most of the implementation of _MMIO_TRANS2() to it and while at it taking the opportunity to rename pipe to trans. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiya@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiya@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
José Roberto de Souza authored
Just moving it to reduce the tabs and avoid break code lines. No behavior changes intended here. v2: - Reading misc display IRQ outside of gen8_de_misc_irq_handler() as other irq handlers (Dhinakaran) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2019-08-13 - Enhance command parser for extra length check (Fred) - remove debugfs function return check (Greg) - batch buffer end double check after shadow copy (Tina) - one typo fix (Zhenyu) - klocwork warning fix (Zhi) - use struct_size() helper (Gustavo) Signed-off-by:
-
Chris Wilson authored
Stop assuming we only get called with irqs-on for disarming the breadcrumbs, and do a full save/restore spin_lock_irq. Signed-off-by:
-
Chris Wilson authored
If the backend wishes to defer the wakeref parking, make it responsible for unlocking the wakeref (i.e. bumping the counter). This allows it to time the unlock much more carefully in case it happens to needs the wakeref to be active during its deferral. For instance, during engine parking we may choose to emit an idle barrier (a request). To do so, we borrow the engine->kernel_context timeline and to ensure exclusive access we keep the engine->wakeref.count as 0. However, to submit that request to HW may require a intel_engine_pm_get() (e.g. to keep the submission tasklet alive) and before we allow that we have to rewake our wakeref to avoid a recursive deadlock. <4> [257.742916] IRQs not enabled as expected <4> [257.742930] WARNING: CPU: 0 PID: 0 at kernel/softirq.c:169 __local_bh_enable_ip+0xa9/0x100 <4> [257.742936] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel snd_hda_intel snd_intel_nhlt bluetooth snd_hda_codec coretemp snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul ecdh_generic ecc ghash_clmulni_intel snd_pcm r8169 realtek lpc_ich prime_numbers i2c_hid <4> [257.742991] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U W 5.3.0-rc3-g5d0a06cd532c-drmtip_340+ #1 <4> [257.742998] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F6 02/17/2015 <4> [257.743008] RIP: 0010:__local_bh_enable_ip+0xa9/0x100 <4> [257.743017] Code: 37 5b 5d c3 8b 80 50 08 00 00 85 c0 75 a9 80 3d 0b be 25 01 00 75 a0 48 c7 c7 f3 0c 06 ac c6 05 fb bd 25 01 01 e8 77 84 ff ff <0f> 0b eb 89 48 89 ef e8 3b 41 06 00 eb 98 e8 e4 5c f4 ff 5b 5d c3 <4> [257.743025] RSP: 0018:ffffa78600003cb8 EFLAGS: 00010086 <4> [257.743035] RAX: 0000000000000000 RBX: 0000000000000200 RCX: 0000000000010302 <4> [257.743042] RDX: 0000000080010302 RSI: 0000000000000000 RDI: 00000000ffffffff <4> [257.743050] RBP: ffffffffc0494bb3 R08: 0000000000000000 R09: 0000000000000001 <4> [257.743058] R10: 0000000014c8f0e9 R11: 00000000fee2ff8e R12: ffffa23ba8c38008 <4> [257.743065] R13: ffffa23bacc579c0 R14: ffffa23bb7db0f60 R15: ffffa23b9cc8c430 <4> [257.743074] FS: 0000000000000000(0000) GS:ffffa23bbba00000(0000) knlGS:0000000000000000 <4> [257.743082] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [257.743089] CR2: 00007fe477b20778 CR3: 000000011f72a000 CR4: 00000000001006f0 <4> [257.743096] Call Trace: <4> [257.743104] <IRQ> <4> [257.743265] __i915_request_commit+0x240/0x5d0 [i915] <4> [257.743427] ? __i915_request_create+0x228/0x4c0 [i915] <4> [257.743584] __engine_park+0x64/0x250 [i915] <4> [257.743730] ____intel_wakeref_put_last+0x1c/0x70 [i915] <4> [257.743878] i915_sample+0x2ee/0x310 [i915] <4> [257.744030] ? i915_pmu_cpu_offline+0xb0/0xb0 [i915] <4> [257.744040] __hrtimer_run_queues+0x11e/0x4b0 <4> [257.744068] hrtimer_interrupt+0xea/0x250 <4> [257.744079] ? lockdep_hardirqs_off+0x79/0xd0 <4> [257.744101] smp_apic_timer_interrupt+0x96/0x280 <4> [257.744114] apic_timer_interrupt+0xf/0x20 <4> [257.744125] RIP: 0010:__do_softirq+0xb3/0x4ae v2: Keep the priority_hint assert v3: That assert was desperately trying to point out my bug. Sorry, little assert. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111378Signed-off-by:
-
