- 23 Feb, 2018 3 commits
-
-
Ville Syrjälä authored
Just store function pointers that give us the correct register offsets instead of storing the register offsets themselves. Slightly less efficient perhaps but saves a few bytes and better matches how we do things elsewhere. v2: Keep a local array of data registers (Chris) Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180222181036.15251-3-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Since we no longer have a 1:1 correspondence between ports and AUX channels, let's give AUX channels their own enum. Makes it easier to tell the apples from the oranges, and we get rid of the port E AUX power domain FIXME since we now derive the power domain from the actual AUX CH. v2: Rebase due to AUX F v3: Split out the power domain fix (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> #v2 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v2 Signed-off-by:
-
Ville Syrjälä authored
Select the aux power domain based on the aux ch rather than based on the port. Now we can rid ourselves of the port E FIXME as well. v2: Split from the enum aux_ch patch (Rodrigo) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> #v1 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Signed-off-by:
-
- 22 Feb, 2018 13 commits
-
-
Ville Syrjälä authored
Currently the FBC code doesn't handle the 90/270 degree rotated case correctly. We would need the GTT tracking to monitor the fence on the normal GTT view (the rotated view doesn't even have a fence). Not quite sure how we should program the fence Y offset etc. in that case. For now we'll end up disabling FBC with 90/270 degree rotation. Add a FIXME to remind people about this fact. v2: Reword the text (Chris) Move the FIXME to the fbc code Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
We've replicated the fb pin/unpin code in a few places. Pull it into convenint helpers. Slight change in locking behaviour as intel_cleanup_plane_fb() now grab struct_mutex unconditionally. v2: Change the locking to be symmetric between pin and unpin Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
As only a subset of primary planes are FBC capable there's no need to waste fences on all of them. So let's skip the fence if the plane isn't even fbc capable. In the future we might extend this to skip the fence even for FBC capable planes if the crtc and/or plane state isn't suitable for FBC. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Let's record the information whether a plane can do fbc or not under struct inte_plane. v2: Rebase due to i9xx_plane_id Handle BDW/HSW correctly v3: Move inte_fbc_init() back since we depend on it happening even with i915.disable_display, and populate fbc->possible_framebuffer_bits directly from the plane init code instead v4: Add note about plane A being tied to pipe A on HSW+ Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Currently we pin a fence on every plane doing tiled scanout. The number of planes we have available is fast apporaching the number of fences so we really should stop wasting them. Only FBC needs the fence on gen4+, so let's use fences only for the primary planes on those platforms. v2: drop the tiling check from plane_uses_fence() as the obj is NULL during initial_plane_config() and we don't rally need the check since i915_vma_pin_fence() does the check anyway Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ville Syrjälä authored
Gen2/3 display engine depends on the fence for tiled scanout. So if we fail to get a fence fail the entire operation. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Johnson Lin authored
Some panels support limited range output (16-235) compared to full range RGB values (0-255). Also userspace can control the RGB range using "Broadcast RGB" property. Currently the code to handle full range to limited range is broken. This patch fixes the same by properly scaling down all the full range co-efficients with limited range scaling factor. v2: Fixed Ville's review comments. v3: Changed input to const and used correct data types as suggested by Ville v4: Fixed some missing data type corrections. Signed-off-by:Johnson Lin <johnson.lin@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Slightly smaller code and a bit more logical layout. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
It turns out that HSW has a register that tells us how many EUs are disabled per half-slice (roughly a similar notion to subslice). We didn't read those registers so far as most userspace drivers didn't need those values prior to Gen8, but an internal library would like to have access to this. Since we already have the getparam interface, there is no harm in exposing this. v2: Rename bits value (Joonas) v3: s/GEM_BUG_ON/MISSING_CASE/ (Joonas) v4: s/GEM_BUG_ON/MISSING_CASE/ again... (Lionel) Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221204902.23084-1-lionel.g.landwerlin@intel.com
-
Tvrtko Ursulin authored
Show GEN11 specific interrupt registers in debugfs v2: Update for POR changes. (Daniele Ceraolo Spurio) v3: get runtime pm ref. unify common parts with gen8 (Daniele) Cc: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180220153755.13509-2-mika.kuoppala@linux.intel.com
-
Paulo Zanoni authored
This is the current PCI ID list in our documentation. Let's leave the _gt#_ part out for now since our current documentation is not 100% clear and we don't need this info now anyway. v2: Use the new ICL_11 naming (Kelvin Gardiner). v3: Latest IDs as per BSpec (Oscar). v4: Make it compile (Paulo). v5: Remove comments (Lucas). v6: Multile rebases (Paulo). v7: Rebase (Mika) Reviewed-by: Anuj Phogat <anuj.phogat@intel.com> (v1) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180220153755.13509-1-mika.kuoppala@linux.intel.com
-
Chris Wilson authored
Print out the current request/context before doing the GEM_BUG_ON, so that we can inspect the values in the ftrace. Signed-off-by:
-
Chris Wilson authored
Include a GEM_TRACE to show when the context is complete and we advance the ELSP port. Signed-off-by:
-
- 21 Feb, 2018 6 commits
-
-
Chris Wilson authored
Load an empty ringbuffer for preemption, ignoring the lite-restore workaround as we know the preempt context is always idle before preemption. Note that after some digging by Michal Winiarski, we found that RING_HEAD is no longer being updated (due to inhibiting context save restore) so this patch is already in effect! Signed-off-by:
-
Chris Wilson authored
We want to de-emphasize the link between the request (dependency, execution and fence tracking) from GEM and so rename the struct from drm_i915_gem_request to i915_request. That is we may implement the GEM user interface on top of requests, but they are an abstraction for tracking execution rather than an implementation detail of GEM. (Since they are not tied to HW, we keep the i915 prefix as opposed to intel.) In short, the spatch: @@ @@ - struct drm_i915_gem_request + struct i915_request A corollary to contracting the type name, we also harmonise on using 'rq' shorthand for local variables where space if of the essence and repetition makes 'request' unwieldy. For globals and struct members, 'request' is still much preferred for its clarity. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Acked-by:
-
Dhinakaran Pandiyan authored
No code changes, fixes doc build warnings and polish some doc text. Reported-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Daniel Vetter authored
Noticed while reading some unrelated patches. Unfortunately Imre's patch to add our early/late hooks predated the device_link infrastructure by 2 years. Cc: Imre Deak <imre.deak@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Acked-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180220132017.30719-1-daniel.vetter@ffwll.ch
-
Tvrtko Ursulin authored
Commit fe49789f ("drm/i915: Deconstruct execute fence") re-arranged the code and moved the i915_gem_request_execute tracepoint to before the global seqno is assigned to the request. We need to move the tracepoint a bit later so this information is once again available. Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:
-
- 20 Feb, 2018 9 commits
-
-
Chris Wilson authored
Rather than trusting the cached value of plane_state->vma->fence to imply whether the plane_state itself holds a reference on the framebuffer's fence, use the information provided in the plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC is entirely bounded by the plane_state active life span; it's not clear if that is a safe assumption. Suggested-by:
-
Chris Wilson authored
Use the information about the fence state from the time of pinning to determine if the fbdev writes are going through a fence. This avoids any confusion in cases where the fence may appear or disappear unconnected to the use by fbdev. Suggested-by:
-
Chris Wilson authored
Currently we make the unilateral decision inside i915_gem_object_pin_to_display() where the VMA should resided (inside the fence and mappable region or above?). This is not our decision to make as it impacts on how the display engine can use the resulting scanout object, and it would rather instruct us where to place the VMA so that it can enable the features it wants. As such, make the pin flags an argument to i915_gem_object_pin_to_display() and control them from intel_pin_and_fence_fb_obj() Whilst taking control of the mapping for ourselves, start tracking how we use it to avoid trying to free a fence we never claimed: <3>[ 227.151869] GEM_BUG_ON(vma->fence->pin_count <= 0) <4>[ 227.152064] ------------[ cut here ]------------ <2>[ 227.152068] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:391! <4>[ 227.152084] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI <0>[ 227.152092] Dumping ftrace buffer: <0>[ 227.152099] (ftrace buffer empty) <4>[ 227.152102] Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me mei prime_numbers <4>[ 227.152131] CPU: 1 PID: 1587 Comm: kworker/u16:49 Tainted: G U 4.16.0-rc1-gbab67b2f6177-kasan_7+ #1 <4>[ 227.152134] Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A08 02/19/2008 <4>[ 227.152236] Workqueue: events_unbound intel_atomic_commit_work [i915] <4>[ 227.152292] RIP: 0010:intel_unpin_fb_vma+0x23a/0x2a0 [i915] <4>[ 227.152295] RSP: 0018:ffff88005aad7b68 EFLAGS: 00010286 <4>[ 227.152300] RAX: 0000000000000026 RBX: ffff88005c359580 RCX: 0000000000000000 <4>[ 227.152304] RDX: 0000000000000026 RSI: ffffffff8707d840 RDI: ffffed000b55af63 <4>[ 227.152307] RBP: ffff880056817e58 R08: 0000000000000001 R09: 0000000000000000 <4>[ 227.152311] R10: ffff88005aad7b88 R11: 0000000000000000 R12: ffff8800568184d0 <4>[ 227.152314] R13: ffff880065b5ab08 R14: 0000000000000000 R15: dffffc0000000000 <4>[ 227.152318] FS: 0000000000000000(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000 <4>[ 227.152322] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 227.152325] CR2: 00007f5fb25550a8 CR3: 0000000068c78000 CR4: 00000000000006e0 <4>[ 227.152328] Call Trace: <4>[ 227.152385] intel_cleanup_plane_fb+0x6b/0xd0 [i915] <4>[ 227.152395] drm_atomic_helper_cleanup_planes+0x166/0x280 <4>[ 227.152452] intel_atomic_commit_tail+0x159d/0x3380 [i915] <4>[ 227.152463] ? process_one_work+0x66e/0x1460 <4>[ 227.152516] ? skl_update_crtcs+0x9c0/0x9c0 [i915] <4>[ 227.152523] ? lock_acquire+0x13d/0x390 <4>[ 227.152527] ? lock_acquire+0x13d/0x390 <4>[ 227.152534] process_one_work+0x71a/0x1460 <4>[ 227.152540] ? __schedule+0x815/0x1e20 <4>[ 227.152547] ? pwq_dec_nr_in_flight+0x2b0/0x2b0 <4>[ 227.152553] ? _raw_spin_lock_irq+0xa/0x40 <4>[ 227.152559] worker_thread+0xdf/0xf60 <4>[ 227.152569] ? process_one_work+0x1460/0x1460 <4>[ 227.152573] kthread+0x2cf/0x3c0 <4>[ 227.152578] ? _kthread_create_on_node+0xa0/0xa0 <4>[ 227.152583] ret_from_fork+0x3a/0x50 <4>[ 227.152591] Code: c6 00 11 86 c0 48 c7 c7 e0 bd 85 c0 e8 60 e7 a9 c4 0f ff e9 1f fe ff ff 48 c7 c6 40 10 86 c0 48 c7 c7 e0 ca 85 c0 e8 2b 95 bd c4 <0f> 0b 48 89 ef e8 4c 44 e8 c4 e9 ef fd ff ff e8 42 44 e8 c4 e9 <1>[ 227.152720] RIP: intel_unpin_fb_vma+0x23a/0x2a0 [i915] RSP: ffff88005aad7b68 v2: i915_vma_pin_fence() is a no-op if a fence isn't required, so check vma->fence as well. Signed-off-by:
-
Chris Wilson authored
We cannot simply use !view as shorthand for all normal GGTT views as a few callers will always populate a i915_ggtt_view struct and set the type to NORMAL instead. So check for (!view || view->type == NORMAL) inside i915_gem_object_ggtt_pin(). Signed-off-by:
-
Ville Syrjälä authored
WaDoubleCursorLP3Latency was meant for pre-production hardware. Drop it. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
i965 and g4x still have the pipe select bits in the plane control registers, they're just hardcoded to select a specific pipe. However plane C on i965 can still move between the pipes, thus we should program the pipe select bits on i965 if we want to expose plane C some day. Since there is no harm in programming the bits on any plane on i965/g4x let's just always set them. This will also make our pre-computed register value match what the hardware register would read, should we want to cross check the two. Signed-off-by:
-
Ville Syrjälä authored
G4x cursor control registers still allow us to write to the pipe select bits even though cursors are supposed to be fixed to a specific pipe. Bspec tells us that we should only ever write 0 to these bits. Let's follow that recommendation. On ilk+ the bits become hardwired to 0. Also looks like ICL repurposes these bits for some other use, so we had better stop setting them to bogus values there. Signed-off-by:
-
Ville Syrjälä authored
Add some compile time assrts to the frontbuffer tracking to make sure that we have enough bits per pipe to cover all the planes, and that we have enough total bits to cover all the planes across all pipes. We'll ignore any potential clash between the overlay bit and the plane bits because that will allow us to keep using a total of 32 bits for the foreseeable future. While at it change the macros to use BIT() and GENMASK(). The latter gets rid of the hardcoded 0xff and thus means we can change the number of bits per pipe by just changing INTEL_FRONTBUFFER_BITS_PER_PIPE. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
During igt, we frequently call into the driver to reset both HW and driver state (idling the device, waiting for it to become idle and freeing off old objects) to ensure that we start each test/subtest/pass from known state. This process incurs an RCU barrier or two to ensure that any such pending frees are indeed flushed before we return. However, unconditionally waiting on the RCU barrier adds needless delay to many callers, which adds up to several seconds when repeated thousands of times. We can skip the rcu_barrier() if by tracking how many outstanding frees we have, we know there are none. The same path is used along suspend, where we may be able to save the unconditional RCU barrier. To put it into perspective with a completely meaningless microbenchmark, igt/gem_sync/idle is improved from 50ms to 30us on bdw. v2: Remove the extra synchronize_rcu() inside i915_drop_caches_set() Signed-off-by:
-
- 19 Feb, 2018 7 commits
-
-
Chris Wilson authored
clang spots drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (INTEL_GEN(dev_priv) >= 10) but fortunately for us we skip the function unless on a gen10+ device. However, to keep the function generic in case we do want to re-enable it for gen9 again, initialise trans_min to 0. References: ca47667f ("drm/i915/gen10: Calculate and enable transition WM") Signed-off-by: -
Chris Wilson authored
If we fail to unbind the vma (due to a signal on an active buffer that needs to be moved for the next execbuf), then we need to clear the persistent tracking state we setup for this execbuf. Fixes: c7c6e46f ("drm/i915: Convert execbuf to use struct-of-array packing for critical fields") Testcase: igt/gem_fenced_exec_thrash/no-spare-fences-busy* Signed-off-by:
-
Chris Wilson authored
The compiler is not automatically caching the i915->regs address inside a register and emitting a load for every mmio access. For simple functions like gen8_gt_irq_handler that are already using the raw accessors, we can open-code them for substantial savings: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-83 (-83) Function old new delta gen8_gt_irq_handler 290 266 -24 gen8_gt_irq_ack 181 122 -59 Total: Before=954637, After=954554, chg -0.01% v2: Add raw_reg_read/raw_reg_write. Signed-off-by:
-
Chris Wilson authored
Keep the master iir and use it to reduce the number of reads and writes to the GT iir array, i.e. only the bits marked as set by the master iir are valid inside GT iir array and will be handled during the interrupt. Signed-off-by:
-
Chris Wilson authored
As the driver is called to handle circumstances beyond it's control, we cannot assume that the pm_runtime core is happy to see us. For example, if we are called from shrink_slab to free up our pages during suspend, rpm may be disabled and pm_runtime_if_in_use() decides to fail with -EINVAL rather than simply say no. This is expected to happen, so don't warn. For example, [ 217.429228] Suspending console(s) (use no_console_suspend to debug) [ 217.557179] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 217.559399] sd 0:0:0:0: [sda] Stopping disk [ 218.661567] i915 0000:00:02.0: Resetting chip after gpu hang [ 219.523879] ------------[ cut here ]------------ [ 219.524474] pm_runtime_get_if_in_use() failed: -22 [ 219.524817] WARNING: CPU: 1 PID: 14 at drivers/gpu/drm/i915/intel_runtime_pm.c:3351 intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915] [ 219.524836] Modules linked in: vgem i915 snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec r8169 lpc_ich snd_hwdep mii snd_hda_core snd_pcm prime_numbers [ 219.525054] CPU: 1 PID: 14 Comm: cpuhp/1 Tainted: G U 4.16.0-rc1-g740f57c54ecf-kasan_6+ #1 [ 219.525070] Hardware name: /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010 [ 219.525294] RIP: 0010:intel_runtime_pm_get_if_in_use+0xe3/0x150 [i915] [ 219.525313] RSP: 0018:ffff880018f5edf8 EFLAGS: 00010286 [ 219.525344] RAX: dffffc0000000008 RBX: ffff880007fc0000 RCX: 0000000000000000 [ 219.525361] RDX: 0000000000000001 RSI: ffffffff850609c0 RDI: ffffffff872992a0 [ 219.525377] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 219.525394] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880007fc0000 [ 219.525411] R13: ffff880018f5f0f8 R14: ffff880007fc8de8 R15: ffff880018f5f0f0 [ 219.525429] FS: 0000000000000000(0000) GS:ffff880019c80000(0000) knlGS:0000000000000000 [ 219.525446] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 219.525463] CR2: 0000564df7897e86 CR3: 0000000000d7c000 CR4: 00000000000006e0 [ 219.525478] Call Trace: [ 219.525734] i915_gem_shrink+0x841/0xb50 [i915] [ 219.525802] ? debug_check_no_locks_freed+0x2a0/0x2a0 [ 219.525842] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 219.526083] ? i915_gem_shrinker_count+0x2f0/0x2f0 [i915] [ 219.526131] ? lock_acquire+0x138/0x3c0 [ 219.526157] ? lock_acquire+0x138/0x3c0 [ 219.526391] ? shrinker_lock+0x49/0x210 [i915] [ 219.526465] ? mutex_trylock+0x15c/0x1a0 [ 219.526694] ? shrinker_lock+0x49/0x210 [i915] [ 219.526969] ? i915_gem_shrinker_scan+0xc4/0x320 [i915] [ 219.527200] i915_gem_shrinker_scan+0xc4/0x320 [i915] [ 219.527448] ? i915_gem_shrinker_vmap+0x3a0/0x3a0 [i915] [ 219.527533] shrink_slab.part.18+0x2d0/0x8d0 [ 219.527613] ? unregister_shrinker+0x1f0/0x1f0 [ 219.527668] ? mem_cgroup_iter+0x37d/0xc50 [ 219.527728] shrink_node+0x882/0xbe0 [ 219.527847] ? shrink_node_memcg+0x11c0/0x11c0 [ 219.527882] ? mark_held_locks+0xa8/0xf0 [ 219.527931] ? trace_hardirqs_on_caller+0x33f/0x590 [ 219.527961] ? ktime_get+0xad/0x140 [ 219.528015] do_try_to_free_pages+0x2d3/0xd70 [ 219.528099] ? allow_direct_reclaim.part.23+0x1d0/0x1d0 [ 219.528132] ? shrink_node+0xbe0/0xbe0 [ 219.528213] try_to_free_pages+0x1cd/0x570 [ 219.528257] ? do_try_to_free_pages+0xd70/0xd70 [ 219.528355] __alloc_pages_nodemask+0xadf/0x2110 [ 219.528423] ? unwind_next_frame+0x870/0x1970 [ 219.528465] ? deref_stack_reg+0x97/0xc0 [ 219.528503] ? gfp_pfmemalloc_allowed+0x150/0x150 [ 219.528539] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.528588] ? unwind_next_frame+0x138/0x1970 [ 219.528619] ? kthread+0x30a/0x3d0 [ 219.528677] ? __read_once_size_nocheck.constprop.4+0x10/0x10 [ 219.528698] ? deref_stack_reg+0xc0/0xc0 [ 219.528762] ? __save_stack_trace+0x6e/0xd0 [ 219.528822] depot_save_stack+0x3bc/0x430 [ 219.528870] kasan_kmalloc+0x142/0x170 [ 219.528912] ? __kmalloc+0xf7/0x340 [ 219.528935] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.528957] ? partition_sched_domains+0x4d4/0x840 [ 219.528978] ? sched_cpu_deactivate+0x11b/0x150 [ 219.529001] ? cpuhp_invoke_callback+0x160/0x15f0 [ 219.529023] ? cpuhp_thread_fun+0x35e/0x710 [ 219.529044] ? smpboot_thread_fn+0x50a/0x7f0 [ 219.529065] ? kthread+0x30a/0x3d0 [ 219.529086] ? ret_from_fork+0x24/0x50 [ 219.529141] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529169] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529198] ? set_track+0x87/0x100 [ 219.529225] ? init_object+0x6e/0x80 [ 219.529275] ? ___slab_alloc.constprop.36+0x232/0x3e0 [ 219.529303] ? ___slab_alloc.constprop.36+0x232/0x3e0 [ 219.529325] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529410] ? mark_held_locks+0xa8/0xf0 [ 219.529453] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529479] ? trace_hardirqs_on_caller+0x33f/0x590 [ 219.529532] __kmalloc+0xf7/0x340 [ 219.529557] ? register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529604] register_sched_domain_sysctl+0x23a/0x1b90 [ 219.529684] ? sched_debug_show+0x20/0x20 [ 219.529713] ? debug_object_activate+0x530/0x530 [ 219.529771] ? rcu_lockdep_current_cpu_online+0xdc/0x130 [ 219.529802] ? partition_sched_domains+0x4ae/0x840 [ 219.529825] ? rcu_read_lock_sched_held+0x10f/0x130 [ 219.529875] partition_sched_domains+0x4d4/0x840 [ 219.529955] ? sched_init_domains+0x110/0x110 [ 219.529981] ? __wait_rcu_gp+0x24f/0x390 [ 219.530054] sched_cpu_deactivate+0x11b/0x150 [ 219.530086] ? sched_cpu_activate+0x1e0/0x1e0 [ 219.530112] ? __call_rcu.constprop.53+0x680/0x680 [ 219.530132] ? call_rcu_bh+0x10/0x10 [ 219.530166] ? debug_check_no_locks_freed+0x2a0/0x2a0 [ 219.530201] ? trace_raw_output_rcu_utilization+0xa0/0xa0 [ 219.530267] ? trace_raw_output_rcu_utilization+0xa0/0xa0 [ 219.530337] ? rcu_lockdep_current_cpu_online+0xdc/0x130 [ 219.530370] ? sched_cpu_activate+0x1e0/0x1e0 [ 219.530397] cpuhp_invoke_callback+0x160/0x15f0 [ 219.530424] ? lock_acquire+0x138/0x3c0 [ 219.530445] ? lock_acquire+0x138/0x3c0 [ 219.530471] ? cpuhp_thread_fun+0xaf/0x710 [ 219.530507] ? pci_mmcfg_check_reserved+0x100/0x100 [ 219.530565] cpuhp_thread_fun+0x35e/0x710 [ 219.530618] ? cpuhp_complete_idle_dead+0x10/0x10 [ 219.530639] smpboot_thread_fn+0x50a/0x7f0 [ 219.530678] ? sort_range+0x20/0x20 [ 219.530709] ? __kthread_parkme+0xba/0x1f0 [ 219.530739] ? schedule+0x84/0x1a0 [ 219.530768] ? __kthread_parkme+0xbf/0x1f0 [ 219.530805] ? sort_range+0x20/0x20 [ 219.530831] kthread+0x30a/0x3d0 [ 219.530859] ? _kthread_create_on_node+0xb0/0xb0 [ 219.530900] ret_from_fork+0x24/0x50 [ 219.530999] Code: 01 00 00 00 85 c0 74 4a 89 e8 5b 5d c3 80 3d 48 37 4e 00 00 75 f2 89 c6 48 c7 c7 40 f0 61 c0 c6 05 36 37 4e 00 01 e8 ed 2a e1 c2 <0f> ff eb d9 80 3d 3f 37 4e 00 00 75 94 48 c7 c7 60 e8 61 c0 c6 [ 219.531880] ---[ end trace 18ec0139488ea0c8 ]--- [ 219.607967] IRQ 16: no longer affine to CPU1 [ 219.670291] IRQ 24: no longer affine to CPU2 [ 219.701489] IRQ 8: no longer affine to CPU3 [ 219.701529] IRQ 9: no longer affine to CPU3 [ 219.701582] IRQ 18: no longer affine to CPU3 [ 219.701640] IRQ 25: no longer affine to CPU3 [ 219.743857] cache: parent cpu1 should not be sleeping [ 219.784549] cache: parent cpu2 should not be sleeping [ 219.816041] cache: parent cpu3 should not be sleeping v2: Add Returns: information to intel_runtime_pm_get_if_in_use() kerneldoc. Signed-off-by:
-
Mauro Carvalho Chehab authored
The in-lined comments for channel.port doesn't follow the syntax described at kernel-doc document, causing the following warning: $ ./scripts/kernel-doc -none drivers/gpu/drm/i915/intel_dpio_phy.c drivers/gpu/drm/i915/intel_dpio_phy.c:154: warning: Function parameter or member 'channel.port' not described in 'bxt_ddi_phy_info' While the best would be for the Kernel to deduce that from the context, supporting it is not trivial. So, let's just stick with the existing syntax. [Jani: depends on "scripts: kernel-doc: support in-line comments on nested structs/unions" to actually fix the warning.] Reported-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Maarten Lankhorst authored
Hitting the failure path through check_digital_port_conflicts triggers: ================================================ WARNING: lock held when returning to user space! 4.16.0-rc1-CI-kasan_1+ #1 Tainted: G W ------------------------------------------------ kms_3d/1439 is leaving the kernel with locks still held! 1 lock held by kms_3d/1439: #0: (drm_connector_list_iter){.+.+}, at: [<000000003745d183>] intel_atomic_check+0x1d9d/0x3ff0 [i915] Rearrange the code to have a single exit path through the unlock. Signed-off-by:Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
-
- 16 Feb, 2018 2 commits
-
-
Chris Wilson authored
We can't assert that the execlists are active before we set the flag. So perform the assert after we are expected to have marked the execlists active. Fixes: 339ccd35 ("drm/i915: Assert that we always complete a submission to guc/execlists") Signed-off-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180216153210.30551-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The continual resubmission model for execlists (and emulated over guc) requires that we keep feeding requests into the HW in order to generate more CS interrupts to drain the rest of the queue. Add a couple of asserts to ensure that we don't skip a cycle and come to a grinding halt. Signed-off-by:
-
