- 06 Sep, 2013 5 commits
-
-
Mika Kuoppala authored
Now when we have mechanism in place to track which context was guilty of hanging the gpu, it is possible to punish for bad behaviour. If context has recently submitted a faulty batchbuffers guilty of gpu hang and submits another batch which hangs gpu in quick succession, ban it permanently. If ctx is banned, no more batchbuffers will be queued for execution. There is no need for global wedge machinery anymore and it would be unwise to wedge the whole gpu if we have multiple hanging batches queued for execution. Instead just ban the guilty ones and carry on. v2: Store guilty ban status bool in gpu_error instead of pointers that might become danling before hang is declared. v3: Use return value for banned status instead of stashing state into gpu_error (Chris Wilson) v4: - rebase on top of fixed hang stats api - add define for ban period - rename commit and improve commit msg v5: - rely context banning instead of wedging the gpu - beautification and fix for ban calculation (Chris) Signed-off-by:Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
VLV has per-pipe PP registers. Set up power sequencing on mode set. The connector init time setup is problematic, since we don't have a pipe at that time. Cook up something. v2: - use vlv_power_sequencer_pipe() also in _pp_{ctrl,stat}_reg() - use PANEL_PORT_SELECT_DPC_VLV (Ville) v3: make checkpatch happier Signed-off-by:Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Make checkpatch a bit more happier still ...] Signed-off-by:
-
Jani Nikula authored
Remove duplicates, add VLV specific macros for port B and C. v2: also add PANEL_PORT_SELECT_DPC_VLV for clarity (Ville) Signed-off-by:
-
Jani Nikula authored
Follow-up to commit 5004945f Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jul 30 12:20:32 2013 +0300 drm/i915: move encoder->enable callback later in VLV crtc enable v2: Rebase on the renamed enable hooks, adding clarity (Ville) Reference: http://mid.gmane.org/CAKMK7uFs9EMvMW8BnS24e5UNm1D7JrfVg3SD5SDFtVEamGfOOg@mail.gmail.comSigned-off-by:
-
Jani Nikula authored
In line with the rest of the code base. No functional changes. v2: also s/intel_pre_enable_dp/g4x_pre_enable_dp/ for consistency (Ville) Signed-off-by:
-
- 05 Sep, 2013 4 commits
-
-
Damien Lespiau authored
It's totally unused, so remove the last mode_fixup appearance in i915. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Chon Ming Lee authored
The patch doesn't contain functional change, but is to prepare for future platform which has different DPIO phy. The additional pipe parameter will use to select which phy to target for. v2: Update the commit message and add static for the new function. (Jani/Ville) Signed-off-by:
Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by:
-
Chris Wilson authored
It is possible for us to be forced to perform an allocation for the lazy request whilst running the shrinker. This allocation may fail, leaving us unable to reclaim any memory leading to premature OOM. A neat solution to the problem is to preallocate the request at the same time as acquiring the seqno for the ring transaction. This means that we can report ENOMEM prior to touching the rings. Signed-off-by:
-
Chris Wilson authored
Prior to preallocating an request for lazy emission, rename the existing field to make way (and differentiate the seqno from the request struct). Signed-off-by:
-
- 04 Sep, 2013 31 commits
-
-
Ville Syrjälä authored
ironlake_fdi_compute_config() already checks that we have enough FDI bandwidth. And it doesn't just use a hardcoded value but takes into account factors such as the actual FDI frequency, shared FDI B/C lanes, etc. Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Chon Ming Lee authored
For DP pll settings, there is only two golden configs. Instead of running through the algorithm to determine it, hardcode the value and get it determine in intel_dp_set_clock. v2: Rework on the intel_limit compiler warning. (Jani) Signed-off-by:
-
Chon Ming Lee authored
eDP 1.4 supports 4-5 extra link rates in additional to current 2 link rate. Create a structure to store the DPLL divisor data to improve readability. v2: Fix the gen4_dpll/pch_dpll initialization to C99 designated initializers, and use a single loop for all platforms. (Jani and Daniel) Signed-off-by:
-
Jani Nikula authored
The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jani Nikula authored
Notifying the bios lets it enter power saving states. Signed-off-by:
-
Jani Nikula authored
The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out. The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference. v2: - squash notification function and callers patches together (Daniel) - move callers to haswell_crtc_{enable,disable} (Daniel) - rename notification function (Chris) v3: - separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after all v4: per Paulo's review: - drop LVDS - WARN on unsupported encoder types Signed-off-by: -
Jani Nikula authored
In preparation for followup work. Signed-off-by:
-
Jani Nikula authored
SWSCI is a driver to bios call interface. This checks for SWSCI availability and bios requested callbacks, and filters out any calls that shouldn't happen. This way the callers don't need to do the checks all over the place. v2: silence some checkpatch nagging v3: set PCI_SWSCI bit 0 to trigger interrupt (Mengdong Lin) v4: remove an extra #define (Jesse) v5: spec says s/w is responsible for clearing PCI_SWSCI bit 0 too v6: per Paulo's review and more: - fix sub-function mask - add exit parameter - add define for set panel details call - return more errors from swsci - clean up the supported/requested callbacks bit masks mess - use DSLP for timeout - fix build for CONFIG_ACPI=n v7: tiny adjustment of requested vs. supported SBCB callbacks handling (Paulo) Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Chris Wilson authored
The comments were a little out-of-sequence with the code, forcing the reader to jump around whilst reading. Whilst moving the comments around, add one to explain the context reference. Signed-off-by:
-
Chris Wilson authored
We use the request to ensure we hold a reference to the context for the duration that it remains in use by the ring. Each request only holds a reference to the current context, hence we emit a request after switching contexts with the final reference to the old context. However, the extra interrupt caused by that request is not useful (no timing critical function will wait for the context object), instead the overhead of servicing the IRQ shows up in some (lightweight) benchmarks. In order to keep the useful property of using the request to manage the context lifetime, we want to add a dummy request that is associated with the interrupt from the subsequent real request following the batch. The extra interrupt was added as a side-effect of using i915_add_request() in commit 112522f6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 2 16:48:07 2013 +0300 drm/i915: put context upon switching v2: Daniel convinced me that the request here was solely for context lifetime tracking and that we have the active ref to keep the object alive whilst the MI_SET_CONTEXT. So the only concern then is which context should get the blame for MI_SET_CONTEXT failing. The old scheme added a request for the old context so that any hang upto and including the switch away would mark the old context as guilty. Now any hang here implicates the new context. However since we have already gone through a complete flush with the last context in its last request, and all that lies in no-man's-land is an invalidate flush and the MI_SET_CONTEXT, we should be safe in not unduly placing blame on the new context. Signed-off-by:
-
Daniel Vetter authored
The saga around the breadcrumb vmas used by execbuf continues ... This time around we've managed to unconditionally move the object to the unbound list on the last vma unbind even though it might never have been on either the bound or unbound list. Hilarity ensued. Chris Wilson tracked this one down but compared to his patches I've simply opted to completely separate the unbound case for not-yet bound vmas. Otherwise we imo end up with semantically hard to parse checks around the list_move_tail(global_list, ...). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68462Reviewed-by:
-
Ben Widawsky authored
We still maintain code internally that cares about preliminary support. Leaving the check here doesn't hurt anyone, and should keep things more in line. This time around, stick the info in the intel_info structure, and also change the error from DRM_ERROR->DRM_INFO. This is a partial revert of: commit 590e4df8 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed May 8 10:45:15 2013 -0700 drm/i915: VLV support is no longer preliminary Daniel, I'll provide the fix ups for internal too if/when you merge this (if you want). Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Rodrigo Vivi authored
Batchbuffers constructed by userspace can conditionalise their URB allocations through the use of the MI_SET_PREDICATE command. This command can read the MI_PREDICATE_RESULT_2 register to see how many slices are enabled on GT3, and by virtue of the result, scale their memory allocations to fit enabled memory. Of course, this only works if the kernel sets the appropriate bit in the register first. v2: Better commit subject and message by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Credits-to: Yejun Guo <yejun.guo@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Daniel Vetter authored
This fixes a printf warn from gcc: drivers/gpu/drm/i915/intel_dsi_cmd.c: In function ‘dsi_vc_send_long’: drivers/gpu/drm/i915/intel_dsi_cmd.c:181:2: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 7 has type ‘size_t’ [-Wformat=] Suggested-by:
-
Jani Nikula authored
Signed-off-by:
-
Shobhit Kumar authored
Initial parsing of the VBT MIPI block. For now, just store the panel id if found. Note: Again there seems to be no documentation for this piece of lore. The doc situation for byt+ is just a bad joke :( Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Shobhit Kumar authored
Note: No one seems to have docs for this, so this patch here is just unreviewed black magic :( Signed-off-by:
ymohanma <yogesh.mohan.marimuthu@intel.com> Signed-off-by:
-
Jani Nikula authored
DPLL is not needed for DSI v2: Rebase due to added DSI PLL assertion patch. Signed-off-by:
-
Jani Nikula authored
For DSI, we need to be asserting DSI PLL, not DPLL. This is a somewhat stopgap implementation. It's slightly ugly to have to pass the dsi parameter to intel_enable_pipe(). Signed-off-by:
-
ymohanma authored
v2: - Grab dpio_lock mutex in vlv_enable_dsi_pll(). - Add and call vlv_disable_dsi_pll(). v3: Mostly based on Ville's review comments. - Only pipe A has DSI PLL lock bit. - Add more of CCK REG bit definitions for DSI PLL. - Make tables static. - Move clock gating out of the clock calculation functions. - DSI PLL LDO power gating. - Put alternative MNP from table calc behind #ifdef. v4: s/CKK/CLK/ in the CCK REG bit definitions (Ville). Signed-off-by:
-
Jani Nikula authored
This does not include any panel specific sub-encoders yet. v2: Fix fixed mode handling (Daniel) v3: Mostly based on Ville's review comments. - Fix MIPI_HS_TX_TIMEOUT. - DPI_ENABLE only for video mode. - Drop ULPS usage for now, use DEVICE_READY only. - Set MIPI_INIT_COUNT based on txclkesc. Signed-off-by:
-
Jani Nikula authored
v2: Rebase due to register bit definition change. v3: Mostly based on Ville's review comments. - Use size_t for length all around. - Reuse dsi_vc_send_short in dsi_vc_send_long. - Remove stale/incorrect comments. - Reverse special packet sent interrupt check. - Use DSI controller regs for reading, not adapter. Signed-off-by:
-
Jani Nikula authored
The sub-encoder model is copied from DVO. v2: Add attached_connector to struct intel_dsi. Signed-off-by:
-
Jani Nikula authored
Signed-off-by:
-
Jani Nikula authored
Add definitions for VLV MIPI DSI registers. v2: Small fixes per Ville's review comments. Signed-off-by:
-
Jani Nikula authored
v2: Add comment this is pipe A only (Ville) Signed-off-by:
-
Jani Nikula authored
For GPIO NC, CCK, CCU, and GPS CORE. Signed-off-by:
-
Shobhit Kumar authored
Signed-off-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
-
Chris Wilson authored
A follow-on to the update of the LLC coherency logic is that we can rely on the LLC being coherent with the CS for rewriting batchbuffers irrespective of their cache domain. (This should have no effect currently as all the batch buffers are expected to be I915_CACHE_LLC and so using the cpu relocation path anyway.) Signed-off-by:
-
Daniel Vetter authored
The important bugfix here is that we must not unlink the vma when we keep it around as a placeholder for the execbuf code. Since then we won't find it again when execbuf gets interrupt and restarted and create a 2nd vma. And since the code as-is isn't fit yet to deal with more than one vma, hilarity ensues. Specifically the dma map/unmap of the sg table isn't adjusted for multiple vmas yet and will blow up like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffffa008fb37>] i915_gem_gtt_finish_object+0x73/0xc8 [i915] PGD 56bb5067 PUD ad3dd067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: tcp_lp ppdev parport_pc lp parport ipv6 dm_mod dcdbas snd_hda_codec_hdmi pcspkr snd_hda_codec_realtek serio_raw i2c_i801 iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec lpc_ich snd_hwdep mfd_core snd_pcm snd_page_alloc snd_timer snd soundcore acpi_cpufreq i915 video button drm_kms_helper drm mperf freq_table CPU: 1 PID: 16650 Comm: fbo-maxsize Not tainted 3.11.0-rc4_nightlytop_d93f59_debug_20130814_+ #6957 Hardware name: Dell Inc. OptiPlex 9010/03JR84, BIOS A01 05/04/2012 task: ffff8800563b3f00 ti: ffff88004bdf4000 task.ti: ffff88004bdf4000 RIP: 0010:[<ffffffffa008fb37>] [<ffffffffa008fb37>] i915_gem_gtt_finish_object+0x73/0xc8 [i915] RSP: 0018:ffff88004bdf5958 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8801135e0000 RCX: ffff8800ad3bf8e0 RDX: ffff8800ad3bf8e0 RSI: 0000000000000000 RDI: ffff8801007ee780 RBP: ffff88004bdf5978 R08: ffff8800ad3bf8e0 R09: 0000000000000000 R10: ffffffff86ca1810 R11: ffff880036a17101 R12: ffff8801007ee780 R13: 0000000000018001 R14: ffff880118c4e000 R15: ffff8801007ee780 FS: 00007f401a0ce740(0000) GS:ffff88011e280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005635c000 CR4: 00000000001407e0 Stack: ffff8801007ee780 ffff88005c253180 0000000000018000 ffff8801135e0000 ffff88004bdf59a8 ffffffffa0088e55 0000000000000011 ffff8801007eec00 0000000000018000 ffff880036a17101 ffff88004bdf5a08 ffffffffa0089026 Call Trace: [<ffffffffa0088e55>] i915_vma_unbind+0xdf/0x1ab [i915] [<ffffffffa0089026>] __i915_gem_shrink+0x105/0x177 [i915] [<ffffffffa0089452>] i915_gem_object_get_pages_gtt+0x108/0x309 [i915] [<ffffffffa0085ba9>] i915_gem_object_get_pages+0x61/0x90 [i915] [<ffffffffa008f22b>] ? gen6_ppgtt_insert_entries+0x103/0x125 [i915] [<ffffffffa008a113>] i915_gem_object_pin+0x1fa/0x5df [i915] [<ffffffffa008cdfe>] i915_gem_execbuffer_reserve_object.isra.6+0x8d/0x1bc [i915] [<ffffffffa008d156>] i915_gem_execbuffer_reserve+0x229/0x367 [i915] [<ffffffffa008dbf6>] i915_gem_do_execbuffer.isra.12+0x4dc/0xf3a [i915] [<ffffffff810fc823>] ? might_fault+0x40/0x90 [<ffffffffa008eb89>] i915_gem_execbuffer2+0x187/0x222 [i915] [<ffffffffa000971c>] drm_ioctl+0x308/0x442 [drm] [<ffffffffa008ea02>] ? i915_gem_execbuffer+0x3ae/0x3ae [i915] [<ffffffff817db156>] ? __do_page_fault+0x3dd/0x481 [<ffffffff8112fdba>] vfs_ioctl+0x26/0x39 [<ffffffff811306a2>] do_vfs_ioctl+0x40e/0x451 [<ffffffff817deda7>] ? sysret_check+0x1b/0x56 [<ffffffff8113073c>] SyS_ioctl+0x57/0x87 [<ffffffff8135bbfe>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff817ded82>] system_call_fastpath+0x16/0x1b Code: 48 c7 c6 84 30 0e a0 31 c0 e8 d0 e9 f7 ff bf c6 a7 00 00 e8 07 af 2c e1 41 f6 84 24 03 01 00 00 10 75 44 49 8b 84 24 08 01 00 00 <8b> 50 08 48 8b 30 49 8b 86 b0 04 00 00 48 89 c7 48 81 c7 98 00 RIP [<ffffffffa008fb37>] i915_gem_gtt_finish_object+0x73/0xc8 [i915] RSP <ffff88004bdf5958> CR2: 0000000000000008 As a consequence we need to change the "only one vma for now" check in vma_unbind - since vma_destroy isn't always called the obj->vma_list might not be empty. Instead check that the vma list is singular at the beginning of vma_unbind. This is also more symmetric with bind_to_vm. This fixes the igt/gem_evict_everything|alignment testcases. v2: - Add a paranoid WARN to mark_free in the eviction code to make sure we never try to evict a vma used by the execbuf code right now. - Move the check for a temporary execbuf vma into vma_destroy - otherwise the failure path cleanup in bind_to_vm will blow up. Our first attempting at fixing this was commit 1be81a2f2cfd8789a627401d470423358fba2d76 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Aug 20 12:56:40 2013 +0100 drm/i915: Don't destroy the vma placeholder during execbuffer reservation Squash with this when merging! v3: Improvements suggested in Chris' review: - Move the WARN_ON in vma_destroy that checks for vmas with an drm_mm allocation before the early return. - Bail out if we hit the WARN in mark_free to hopefully make the kernel survive for long enough to capture it. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68298 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68171 Tested-by: lu hua <huax.lu@intel.com> (v2) Reviewed-by:
-
