- 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:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-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 <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> 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 36 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: -
Chris Wilson authored
The execbuffer handle and exec_link were moved from the object into the vma. As the vma may be unbound and destroyed whilst attempting to reserve the execbuffer objects (either through a forced unbind to fix up a misalignment or through an evict-everything call) we need to prevent the free of the i915_vma itself. Otherwise not only is the list of objects to reserve corrupt, but we continue to reference stale vma entries. Fixes kernel crash with i-g-t/gem_evict_everything This regression has been introduced in commit 04038a515d6eda6dd0857c0ade0b3950d372f4c0 Author: Ben Widawsky <ben@bwidawsk.net> AuthorDate: Wed Aug 14 11:38:36 2013 +0200 drm/i915: Convert execbuf code to use vmas Reported-by:Dan Carpenter <dan.carpenter@oracle.com> References: http://www.spinics.net/lists/intel-gfx/msg32038.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68298Signed-off-by:
-
Daniel Vetter authored
In the execbuf code we don't clean up any vmas which ended up not getting bound for code simplicity. To make sure that we don't end up creating multiple vma for the same vm kill the somewhat dangerous vma_create function and inline it into lookup_or_create. This is just a safety measure to prevent surprises in the future. Also update the somewhat confused comment in the execbuf code and clarify what kind of magic is going on with a new one. v2: Keep the function separate as requested by Chris. But give it a __ prefix for paranoia and move it tighter together with the other vma stuff. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Acked-by:
-
Ben Widawsky authored
In order to transition more of our code over to using a VMA instead of an <OBJ, VM> pair - we must have the vma accessible at execbuf time. Up until now, we've only had a VMA when actually binding an object. The previous patch helped handle the distinction on bound vs. unbound. This patch will help us catch leaks, and other issues before we actually shuffle a bunch of stuff around. This attempts to convert all the execbuf code to speak in vmas. Since the execbuf code is very self contained it was a nice isolated conversion. The meat of the code is about turning eb_objects into eb_vma, and then wiring up the rest of the code to use vmas instead of obj, vm pairs. Unfortunately, to do this, we must move the exec_list link from the obj structure. This list is reused in the eviction code, so we must also modify the eviction code to make this work. WARNING: This patch makes an already hotly profiled path slower. The cost is unavoidable. In reply to this mail, I will attach the extra data. v2: Release table lock early, and two a 2 phase vma lookup to avoid having to use a GFP_ATOMIC. (Chris) v3: s/obj_exec_list/obj_exec_link/ Updates to address commit 6d2b8885 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 7 18:30:54 2013 +0100 drm/i915: List objects allocated from stolen memory in debugfs v4: Use obj = vma->obj for neatness in some places (Chris) need_reloc_mappable() should return false if ppgtt (Chris) Signed-off-by:
-
Daniel Vetter authored
The dpll actually runs at the port clock so we don't need to multiply it again with the pixel multiplier to get the adjusted_mode.clock. This is in contrast to the ironlake pixel clock readout code which uses the fdi dotclock: That one does _not_ run with multiplied pixels. This issue goes back to the original clock readout code added in commit f1f644dc Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 27 00:39:25 2013 +0300 drm/i915: get mode clock when reading the pipe config v9 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
The sdvo input timing needs to be the actual mode, the sdvo encoder automatically adjusts for the need of pixel doubling or quadrupling. This was lost in pipe config conversion of the pixel multiplier in commit 6cc5f341 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:53 2013 +0100 drm/i915: add pipe_config->pixel_multiplier While at it ditch the intel_ prefix from the crtc in intel_sdvo_mode_set. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
