- 05 Apr, 2016 5 commits
-
-
Chris Wilson authored
If the core runs out of vmap address space, it will call a notifier in case any driver can reap some of its vmaps. As i915.ko is possibily holding onto vmap address space that could be recovered, hook into the notifier chain and try and reap objects holding onto vmaps. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Rientjes <rientjes@google.com> Cc: Roman Pen <r.peniaev@gmail.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459777603-23618-4-git-send-email-chris@chris-wilson.co.ukReviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
vmaps are temporary kernel mappings that may be of long duration. Reusing a vmap on an object is preferrable for a driver as the cost of setting up the vmap can otherwise dominate the operation on the object. However, the vmap address space is rather limited on 32bit systems and so we add a notification for vmap pressure in order for the driver to release any cached vmappings. The interface is styled after the oom-notifier where the callees are passed a pointer to an unsigned long counter for them to indicate if they have freed any space. v2: Guard the blocking notifier call with gfpflags_allow_blocking() v3: Correct typo in forward declaration and move to head of file Signed-off-by:
-
Chris Wilson authored
Since we only attempt to purge an object if can_release_pages() report true, we should also only add it to the count of potential recoverable pages when can_release_pages() is true. Signed-off-by:
-
Jani Nikula authored
Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/65d58c578adecc205a741102329bc9c9f6eb79cf.1458299160.git.jani.nikula@intel.com
-
Jani Nikula authored
In sequence block v2, and only in v2, the gpio source (i.e. IOSF port) is specified separately. v2: initialize gpio_source to 0 and handle v1 and v2 in the same branch Reviewed-by:
-
- 04 Apr, 2016 2 commits
-
-
Tvrtko Ursulin authored
Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: ffff8800aae88000 ti: ffff8800aae90000 task.ti: ffff8800aae90000 RIP: 0010:[<ffffffff8104a3c2>] [<ffffffff8104a3c2>] __do_softirq+0x72/0x1d0 RSP: 0000:ffff88014f403f38 EFLAGS: 00000206 RAX: ffff8800aae94000 RBX: 0000000000000000 RCX: 00000000000006e0 RDX: 0000000000000020 RSI: 0000000004208060 RDI: 0000000000215d80 RBP: ffff88014f403f80 R08: 0000000b1b42c180 R09: 0000000000000022 R10: 0000000000000004 R11: 00000000ffffffff R12: 000000000000a030 R13: 0000000000000082 R14: ffff8800aa4d0080 R15: 0000000000000082 FS: 0000000000000000(0000) GS:ffff88014f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa53b90c000 CR3: 0000000001a0a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a 0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080 0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8 Call Trace: <IRQ> [<ffffffff8104a716>] irq_exit+0x86/0x90 [<ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90 <EOI> [<ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915] [<ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20 [<ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915] [<ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0 [<ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915] [<ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915] [<ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915] [<ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915] [<ffffffff81063852>] ? finish_task_switch+0x72/0x1c0 [<ffffffff8105ab29>] process_one_work+0x139/0x350 [<ffffffff8105b186>] worker_thread+0x126/0x490 [<ffffffff8105b060>] ? rescuer_thread+0x320/0x320 [<ffffffff8105fa64>] kthread+0xc4/0xe0 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 [<ffffffff814f351f>] ret_from_fork+0x3f/0x70 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. Another benefit compared to the hard-irq handling is that now work on all engines can be dispatched in parallel since we can have up to number of CPUs active tasklets. (While previously a single hard-irq would serially dispatch on one engine after another.) More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) v4: * Mention dispatch parallelism in commit. (Chris Wilson) * Do not hold uncore.lock over MMIO reads since the block is already serialised per-engine via the tasklet itself. (Chris Wilson) * intel_lrc_irq_handler should be static. (Chris Wilson) * Cancel/sync the tasklet on GPU reset. (Chris Wilson) * Document and WARN that tasklet cannot be active/pending on engine cleanup. (Chris Wilson/Imre Deak) Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Testcase: igt/gem_exec_nop/all Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350Reviewed-by:
-
Chris Wilson authored
Silences src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used uninitialized in this function [-Wuninitialized] Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- 03 Apr, 2016 2 commits
-
-
Chris Wilson authored
As the current PCI power state is an essential feature of runtime pm, include it in the debugfs/i915_runtime_pm_status. v2: Use pci_power_name() Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459689261-7920-2-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since describe_obj() looks at state guarded by the struct_mutex, we need to be holding it. [ 580.201054] drv_suspend: starting subtest debugfs-reader [ 580.239652] ------------[ cut here ]------------ [ 580.239696] WARNING: CPU: 0 PID: 920 at include/linux/list_check.h:25 describe_obj+0x419/0x440() [ 580.239725] CPU: 0 PID: 920 Comm: cat Not tainted 4.5.0-rc6+ #835 [ 580.239745] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 580.239767] 0000000000000000 ffff88027554fcf8 ffffffff812c1135 0000000000000000 [ 580.239815] ffffffff8193dc42 ffff88027554fd30 ffffffff8107419d ffff880071727c00 [ 580.239858] ffff8802757d8000 ffffffff818f693c ffffffff818f693c ffff8802757b9048 [ 580.239896] Call Trace: [ 580.239917] [<ffffffff812c1135>] dump_stack+0x67/0x92 [ 580.239939] [<ffffffff8107419d>] warn_slowpath_common+0x7d/0xb0 [ 580.239959] [<ffffffff810742ba>] warn_slowpath_null+0x1a/0x20 [ 580.239981] [<ffffffff813ce579>] describe_obj+0x419/0x440 [ 580.240006] [<ffffffff813ced22>] i915_gem_framebuffer_info+0xa2/0x100 [ 580.240033] [<ffffffff811a9286>] seq_read+0xe6/0x3b0 [ 580.240059] [<ffffffff81182288>] __vfs_read+0x28/0xd0 [ 580.240085] [<ffffffff81173378>] ? SyS_fadvise64+0x228/0x2c0 [ 580.240112] [<ffffffff811823b2>] vfs_read+0x82/0x110 [ 580.240137] [<ffffffff811827d9>] SyS_read+0x49/0xa0 [ 580.240162] [<ffffffff815bac57>] entry_SYSCALL_64_fastpath+0x12/0x6b [ 580.240187] ---[ end trace 3e2cbf34576c9878 ]--- [ 580.281900] ------------[ cut here ]------------ Signed-off-by:
-
- 01 Apr, 2016 17 commits
-
-
Ville Syrjälä authored
Deal with errors from drm_universal_plane_init() in primary and cursor plane init paths (sprites were already covered). Also make the code neater by using goto for error handling. v2: Rebased due to drm_universal_plane_init() 'name' parameter v3: Another rebase due to s/""/NULL/ v4: Rebased on drm-nightly (Matthew Auld) v5: Fix email address (Matthew Auld) Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458571402-32749-1-git-send-email-matthew.auld@intel.com
-
Ville Syrjälä authored
VLV DPLL is somewhat sane and doesn't run on luck. Signed-off-by:
-
Ville Syrjälä authored
Supposedly the power sequencer still locks out the DPLL registers on CHV, so let's issue a warning if it's still locked when enabling the DPLL. Also drop the redundant IS_MOBILE() check for VLV when we check the same thing. Signed-off-by:
-
Ville Syrjälä authored
Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local pipe variable. Also makes it look more like the corresponding CHV code. While at is change the CHV code to enum pipe from int, Signed-off-by:
-
Ville Syrjälä authored
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B) to either pipe B or C. So do that to make pixel repeat work on pipes B and C. Pipe A is fine without any tricks. Fortunately the pixel repeat propagation appears to be a oneshot operation, so once the value has been written we can clear the chicken bits. So it is still possible to drive pipe B and C with different pixel multipliers simultaneosly. Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B) for this to work. But since we keep that bit always set in all DPLLs there's no problem. This of course means we can't reliably read out the pixel multiplier for pipes B and C. That would make the state checker unhappy, so I added shadow copies of those registers in to dev_priv. The other option would have been to skip pixel multiplier, dpll_md an dotclock checks entirely on CHV, but that feels like a serious loss of cross checking, so just pretending that we have working DPLL MD registers seemed better. Obviously with the shadow copies we can't detect if the pixel multiplier was properly configured, nor can we take over its state from the BIOS, but hopefully people won't have displays that would be limitd to such crappy modes. There is one strange flicker still remaining. It's visible on pipe C/HDMID when HDMIB is enabled while driven by pipe B. It doesn't occur if pipe A drives HDMIB, nor is there any glitch on pipe B/HDMIB when port C/HDMID starts up. I don't have a board with HDMIC so not sure if it happens there too. So I'm not sure if it's somehow tied in with this strange linkage between pipe B and C. Sadly I was unable to find an enable sequence that would avoid the glitch, but at least it's not fatal ie. the output recovers afterwards. Signed-off-by:
-
Ville Syrjälä authored
The VLV and CHV DPLL disable and update are almost identical in how the DPLL/DPLL_MD registers need to be set up. But the code looks more different than it really is. Try to bring them into line. Note that we now leave the refclock always enabled for both DPLLs in the dual channel PHY. But that's perfectly fine since it's the same clock, and we anyway already do that when turning the disp2d power well on. v2: s/chv_update_pll/chv_compute_dpll/ v3: Add a note that we leave refclocks enabled for both DPLLs (Jani) Signed-off-by:
-
Ville Syrjälä authored
These BUGs don't serve any purpose IMO. Throw them out. Signed-off-by:
-
Ville Syrjälä authored
Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists FDI RX disable both as step 13 and step 18 in the sequence. But I dug up an old BUN mail from Art that moved the FDI RX disable to happen before DDI_BUF_CTL disable. That BUN did not renumber the steps and just added a note: "Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL." The BUN described the symptoms of the fixed issue as: "PCH display underflow and a black screen on the analog CRT port that happened after a FDI re-train" I suppose later someone tried to renumber the steps to match, but forgot to remove the FDI RX disable from its old position in the sequence. They also forgot to update the note describing what should be done in case of an FDI training failure. Currently it says: "To retry FDI training, follow the Disable Sequence steps to Disable FDI, but skip the steps related to clocks and PLLs (16, 19, and 20), ..." It should really say "17, 20, and 21" with the current sequence because those are the steps that deal with PLLs and whatnot, after step 13 became FDI RX disable. And had the step 18 FDI RX disable been removed, as I suspect it should have, the note should actually say "17, 19, and 20". So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable, as that would appear to be the correct order based on the BUN. Note that Art has since unconfused the spec, and so this patch should now match the steps listed in the spec. v2: Add a note that the spec is now correct Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Joonas Lahtinen authored
This reverts commit a7442b93. With the patch applied SNB, IVB and ILK are experiencing hard machine hangs. Original patch was to fix "just" kernel panics so it's not a good trade-off. Proper fix for the panic is on the way, lets revert until then. Fixes: a7442b93 ("drm/i915: Fix races on fbdev") Cc: Lukas Wunner <lukas@wunner.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: stable@vger.kernel.org Acked-by:
Lukas Wunner <lukas@wunner.de> Tested-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Suggested-by:
-
Jani Nikula authored
The DSI sequence blocks contain gpio index references, not actual gpio numbers. No functional changes. Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Jani Nikula authored
Make it easier to see which ports are configured for each phy. No functional changes. Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459496681-398-1-git-send-email-jani.nikula@intel.com
-
Vandana Kannan authored
According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be checked to ensure that the register is in accessible state. Also, based on a BSpec update, changing the timeout value to check iphypwrgood, from 10ms to wait for up to 100us. v2: [Ville] use wait_for_us instead of the atomic call. v3: [Jani/Imre] read register only once Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Reported-by:
Philippe Lecluse <Philippe.Lecluse@intel.com> Cc: Deak, Imre <imre.deak@intel.com> Cc: Nikula, Jani <jani.nikula@intel.com> Acked-by:
-
Shubhangi Shrivastava authored
This patch checks for changes in sink count between short pulse hpds and forces full detect when there is a change. This will allow both detection of hotplug and unplug of panels through dongles that give only short pulse for such events. v2: changed variable type from u8 to bool (Jani) return immediately if perform_full_detect is set(Siva) v3: changed method of determining full detection from using pointer to return code (Siva) v4: changed comments to indicate meaning of return value of intel_dp_short_pulse and explain the use of return value from intel_dp_get_dpcd in intel_dp_short_pulse (Ander) Tested-by:Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-5-git-send-email-shubhangi.shrivastava@intel.com
-
Shubhangi Shrivastava authored
Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd. SINK_COUNT denotes if a display is attached, while DOWNSTREAM_PORT_PRESET indicates how many ports are available in the dongle where display can be attached. so it is possible for sink count to change irrespective of value in downstream port dpcd. Here is a table of possible values and scenarios sink_count downstream_port present 0 0 no display is attached 0 1 dongle is connected without display 1 0 display connected directly 1 1 display connected through dongle v2: Storing value of intel_dp->sink_count that is ready for consumption. (Ander) Squashing two commits into one. (Ander) v3: Added comment to explain the need of early return when sink count is 0. (Ander) Tested-by: -
Shubhangi Shrivastava authored
When created originally intel_dp_check_link_status() was supposed to handle only link training for short pulse but has grown into handler for short pulse itself. This patch cleans up this function by splitting it into two halves. First intel_dp_short_pulse() is called, which will be entry point and handle all logic for short pulse handling while intel_dp_check_link_status() will retain its original purpose of only doing link status related work. intel_dp_short_pulse: All existing code other than link status read and link training upon error status. intel_dp_check_link_status: The link status should be read on short pulse irrespective of panel being enabled or not so intel_dp_get_link_status() performs dpcd read first then based on crtc active / enabled it will perform the link training. This is because short pulse is a generic interrupt which should always be handled, because it may mean: 1. Hotplug/unplug of MST panel 2. Hotplug/unplug of dongle 3. Link status change for other DP panels v2: Added WARN_ON to intel_dp_check_link_status() Removed a call to intel_dp_get_link_status() (Ander) v3: Changed commit message to explain need of link status being read before performing encoder checks (Daniel) v4: Changed commit message to explain need of reading link status on short pulse (Ander) Tested-by: -
Shubhangi Shrivastava authored
Current DP detection has DPCD operations split across intel_dp_hpd_pulse and intel_dp_detect which contains duplicates as well. Also intel_dp_detect is called during modes enumeration as well which will result in multiple dpcd operations. So this patch tries to solve both these by bringing all DPCD operations in one single function and make intel_dp_detect use existing values instead of repeating same steps. v2: Pulled in a hunk from last patch of the series to this patch. (Ander) v3: Added MST hotplug handling. (Ander) v4: Added a flag to check if detect is performed to prevent multiple detects on hotplug. (Ander) Tested-by: -
Shubhangi Shrivastava authored
intel_dp_detect() is called for not just detection but during modes enumeration as well. Repeating the whole sequence during each of these calls is wasteful and time consuming. This patch moves probing for panel, DPCD read etc done in intel_dp_detect() to a new function intel_dp_long_pulse(). Note that the behavior of intel_dp_detect() is changed to report connected or disconnected depending on whether the EDID is available or not. This change will be required by further patches in the series to avoid performing duplicated DPCD operations on hotplug. v2: Moved a hunk to next patch of the series. Moved intel_dp_unset_edid to out. (Ander) v3: Rephrased commit message and intel_dp_unset_dp() is called within intel_dp_set_dp() to free the previous EDID. (Ander) v4: Added overriding of status to disconnected for MST. (Ander) Tested-by:
-
- 31 Mar, 2016 5 commits
-
-
Joonas Lahtinen authored
Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt", "vm" or indirectly through other variables like "dev_priv->ggtt.base" to avoid confusion with the i915_ggtt object itself and PPGTT VMs. Refer to the GGTT as "ggtt" instead of indirectly through chaining. As a bonus gets rid of the long-standing i915_obj_to_ggtt vs. i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt! v2: - Added some more after grepping sources with Chris v3: - Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm (Chris) v4: - Convert all dev_priv->ggtt->foo accesses to ggtt->foo. v5: - Make patch checker happy Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Maarten Lankhorst authored
Without this a vblank may occur between updating color management and planes, which should be prevented. intel_color_set_csc was called in update pipe config because the handover from hardware may not have any csc set, which resulted in a black screen. Because of this also update color management during fastset. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Maarten Lankhorst authored
This is already tested by its callers. Signed-off-by:
-
-
Maarten Lankhorst authored
With async modesets this is no longer protected with connection_mutex, so ensure that each pll has its own lock. The pll configuration state is still protected; it's only the pll updates that need locking against concurrency. Changes since v1: - Rebased. - Fix locking to protect all accesses. (Durgadoss) Changes since v2: - Make the dpll_lock global to protect concurrent updates to the same register, for example DPLL_CTRL1 on skl. (Ander) Signed-off-by:
-
- 30 Mar, 2016 9 commits
-
-
Daniel Vetter authored
And move the comment to the right macro. This was mixed up in commit cfb23ed6 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Jul 14 12:17:40 2015 +0200 drm/i915: Allow fuzzy matching in pipe_config_compare, v2 v2: Rebase. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Stone <daniels@collabora.com> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459330476-32453-1-git-send-email-daniel.vetter@ffwll.ch
-
Rodrigo Vivi authored
We now have KBL machines running in our CI systems and with no blocking issues that could cause a full hangs or blank screens. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459349881-951-1-git-send-email-rodrigo.vivi@intel.comAcked-by:
-
Chris Wilson authored
This effectively reverts commit 8e5fd599 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Apr 9 13:28:50 2014 +0300 drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed as under continuous execlists load we can saturate the IRQ handler, destablising the tsc clock and triggering the NMI watchdog to declare a hung CPU. [ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 552.756080] clocksource: 'refined-jiffies' wd_now: 10003b480 wd_last: 10003b28c mask: ffffffff [ 552.756091] clocksource: 'tsc' cs_now: d55d31aa50 cs_last: d17446166c mask: ffffffffffffffff [ 552.756210] clocksource: Switched to clocksource refined-jiffies [ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18 [ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 575.217915] 0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000 [ 575.217935] 0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000 [ 575.217951] ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e [ 575.217967] Call Trace: [ 575.217973] <NMI> [<ffffffff81288c6d>] dump_stack+0x4f/0x72 [ 575.217994] [<ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160 [ 575.218003] [<ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0 [ 575.218016] [<ffffffff811154c4>] perf_event_overflow+0x14/0x20 [ 575.218028] [<ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460 [ 575.218042] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218052] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218064] [<ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50 [ 575.218075] [<ffffffff81007540>] nmi_handle+0x60/0x130 [ 575.218086] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218096] [<ffffffff810079c0>] do_nmi+0x140/0x470 [ 575.218108] [<ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e [ 575.218119] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218129] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218139] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218148] <<EOE>> [<ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0 [ 575.218164] [<ffffffff814a8587>] cpuidle_enter+0x17/0x20 [ 575.218175] [<ffffffff810aaa3a>] call_cpuidle+0x2a/0x40 [ 575.218185] [<ffffffff810aade3>] cpu_startup_entry+0x273/0x330 [ 575.218196] [<ffffffff81033a1e>] start_secondary+0x10e/0x130 However, not servicing all available IIR within the handler does hurt the throughput of pathological nop execbuf by about 20%, with a similar effect upon the dispatch latency of a series of execbuf. v2: use do {} while(0) for a smaller patch, and easier to revert again I have reasonable confidence that we do not miss GT interrupts (as execlists provides a stress case with a failure mechanism easily detected by igt), however I have less confidence about all the other sources of interrupts and worry that may lose a display hotplug interrupt, for example. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467 Testcase: igt/gem_exec_nop/basic # requires NMI watchdog Signed-off-by:
-
Chris Wilson authored
__force_wake_get() only acquires a temporary wakeref on forcewake that is automatically released when a timer expires. When reading the code again, I confused __intel_uncore_forcewake_get() for __force_wake_get() and to my shame thought I found a bug in unbalanced wake_count handling. I claim that if the function had been called __force_wake_auto() instead I would not have embarrassed myself. Signed-off-by:
-
Joonas Lahtinen authored
Rename and document the GGTT init functions to give a better idea of the context where they are called from. i915_gem_gtt_init => i915_ggtt_init_hw i915_gem_init_global_gtt => i915_gem_init_ggtt i915_global_gtt_cleanup => i915_ggtt_cleanup_hw Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
Lets BUG_ON and don't bother with a WARN and returning an error, so we can remove the need to pollute the code with error handling, after all it is a programmer error to provide NULL view. Also while we're here remove redundant NULL ggtt_view check. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Bjørn Mork authored
commit e2c8b870 moved modeset locking inside resume/suspend functions, but missed a code path only executed on lid close/open on older hardware. The result was a deadlock when closing and opening the lid without suspending on such hardware: ============================================= [ INFO: possible recursive locking detected ] 4.6.0-rc1 #385 Not tainted --------------------------------------------- kworker/0:3/88 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] but task is already holding lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->mode_config.mutex); lock(&dev->mode_config.mutex); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by kworker/0:3/88: #0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65 #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915] #4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] #5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm] #6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm] stack backtrace: CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 Workqueue: kacpi_notify acpi_os_execute_deferred 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 Call Trace: [<ffffffff8124af06>] dump_stack+0x67/0x90 [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71 [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4 [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm] [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915] [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65 [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16 [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button] [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button] [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64 [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20 [<ffffffff81068f17>] process_one_work+0x265/0x50b [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff8106e2d6>] kthread+0xe0/0xe8 [<ffffffff8107bc47>] ? local_clock+0x19/0x22 [<ffffffff81484f42>] ret_from_fork+0x22/0x40 [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Daniel Vetter authored
Signed-off-by: -
Lyude authored
Since we need MST devices ready before we try to resume displays, calling this after intel_display_resume() can result in some issues with various laptop docks where the monitor won't turn back on after suspending the system. This order was originally changed in commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state") In order to fix some unclaimed register errors, however the actual cause of those has since been fixed. CC: stable@vger.kernel.org Signed-off-by:
Lyude <cpaul@redhat.com> [danvet: Resolve conflicts with locking changes.] Signed-off-by:
-
