aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2013-08-23drm/i915: Expose energy counter on SNB+ through debugfsJesse Barnes2-0/+25
On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can use to read out the amount of energy used over time. Expose this in sysfs to make it easy to do power comparisons with different configurations. If the platform supports it, the file will show up under the drm/card0/power subdirectory of the PCI device in sysfs as gt_energy_uJ. The value in the file is a running total of energy (in microjoules) consumed by the graphics device. v2: move to sysfs (Ben, Daniel) expose a simple value (Chris) drop unrelated hunk (Ben) Signed-off-by: Jesse Barnes <[email protected]> v3: by Ben Tied it into existing rc6 sysfs entries and named that a more generic "power attrs." Fixed rebase conflicts. Signed-off-by: Ben Widawsky <[email protected]> v4: Since RAPL is a real driver that already exists to serve power monitoring, place our entry in debugfs. This gives me a fallback location for systems that do not expose it otherwise. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23drm/i915: Remove I915_READ_{NOPID, SYNC_0, SYNC_1})()Damien Lespiau1-4/+0
The code directly uses the registers and ring->mmio_base. Signed-off-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23drm: Remove IS_IRONLAKE_D()Damien Lespiau1-1/+0
This define hasn't been used since: commit cfdf1fa23f4074c9f8766dc67a928bbf680b1ac9 Author: Kristian Høgsberg <[email protected]> Date: Wed Dec 16 15:16:16 2009 -0500 drm/i915: Implement IS_* macros using static tables Signed-off-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23drm/i915: Remove HAS_PIPE_CONTROL()Damien Lespiau1-2/+0
The code using this was removed in: commit 88f23b8fa3e6357c423af24ec31c661fc12f884b Author: Chris Wilson <[email protected]> Date: Sun Dec 5 15:08:31 2010 +0000 drm/i915: Avoid using PIPE_CONTROL on Ironlake Signed-off-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23drm/i915: Remove DSPARB_HWCONTROL()Damien Lespiau1-2/+0
This define hasn't been used since: commit 652c393a3368af84359da37c45afc35a91144960 Author: Jesse Barnes <[email protected]> Date: Mon Aug 17 13:31:43 2009 -0700 drm/i915: add dynamic clock frequency control Signed-off-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23drm/i915: make IVB FDI training match spec v3Jesse Barnes1-70/+72
The existing code was trying different vswing and preemphasis settings in the wrong place, and wasn't trying them enough. So add a loop to walk through them, properly disabling FDI TX and RX in between if a failure is detected. v2: remove unneeded reg writes, add delays around bit lock checks (Jesse) v3: fix TX and RX disable per spec (Paulo) fix delays per spec (Paulo) make RX symbol lock check match TX bit lock check (Paulo) Signed-off-by: Jesse Barnes <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51983 Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23drm/i915/vma: Correct use after free in evictionBen Widawsky1-2/+5
The vma will [possibly] be destroyed during unbind in eviction. Immediately after this, we try to delete the list entry. Chris and Ville did the debug on this before I woke up, I just get to take credit for the fix :p For future reference the Oops that Mika reported: [ 403.472448] BUG: unable to handle kernel paging request at 6b6b6b6b [ 403.472473] IP: [<c12c1500>] __list_del_entry+0x20/0xe0 [ 403.472514] *pdpt = 000000002e89c001 *pde = 0000000000000000 [ 403.472556] Oops: 0000 [#1] SMP [ 403.472582] Modules linked in: mxm_wmi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi psmouse snd_seq_midi_event snd_seq serio_raw snd_timer snd_seq_device snd soundcore snd_page_alloc wmi bnep rfcomm bluetooth mac_hid parport_pc ppdev lp parport usbhid dm_crypt firewire_ohci firewire_core crc_itu_t i915 drm_kms_helper e1000e ptp drm i2c_algo_bit pps_core xhci_hcd video [ 403.472895] CPU: 2 PID: 1940 Comm: Xorg Not tainted 3.11.0-rc2+ #827 [ 403.472938] Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0070.2012.0416.2117 04/16/2012 [ 403.473002] task: ec866c00 ti: ee6a2000 task.ti: ee6a2000 [ 403.473039] EIP: 0060:[<c12c1500>] EFLAGS: 00013202 CPU: 2 [ 403.473078] EIP is at __list_del_entry+0x20/0xe0 [ 403.473109] EAX: f016d9bc EBX: f016d9bc ECX: 6b6b6b6b EDX: 6b6b6b6b [ 403.473151] ESI: 00000000 EDI: ee6a3c90 EBP: ee6a3c60 ESP: ee6a3c48 [ 403.473193] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 403.473230] CR0: 80050033 CR2: 6b6b6b6b CR3: 2ec43000 CR4: 001407f0 [ 403.473271] Stack: [ 403.473285] f63b2ff0 f61f98c0 f61f8000 f016d9bc 00000000 f016d9bc ee6a3cac f8519a4a [ 403.473347] 00000000 00000000 10000000 f61f8000 0100a000 10000000 00000001 008ca000 [ 403.473410] f64ee840 f61f98c0 f016d9bc f016dcec ee6a3c98 ee6a3c98 f61f98c0 dcc58f00 [ 403.473472] Call Trace: [ 403.473509] [<f8519a4a>] i915_gem_evict_something+0x17a/0x2d0 [i915] [ 403.473567] [<f8516ed1>] i915_gem_object_pin+0x271/0x660 [i915] [ 403.473622] [<f851c740>] ? i915_ggtt_clear_range+0x20/0x20 [i915] [ 403.473676] [<f8517afa>] i915_gem_object_pin_to_display_plane+0xda/0x190 [i915] [ 403.473742] [<f852d9fa>] intel_pin_and_fence_fb_obj+0xba/0x140 [i915] [ 403.473800] [<f852db40>] intel_gen7_queue_flip+0x30/0x1c0 [i915] [ 403.473856] [<f85337b0>] intel_crtc_page_flip+0x1a0/0x320 [i915] [ 403.473911] [<f847b549>] ? drm_framebuffer_reference+0x39/0x80 [drm] [ 403.473965] [<f847f9fb>] drm_mode_page_flip_ioctl+0x28b/0x320 [drm] [ 403.474018] [<f846fec8>] drm_ioctl+0x4b8/0x560 [drm] [ 403.474064] [<f847f770>] ? drm_mode_gamma_get_ioctl+0xd0/0xd0 [drm] [ 403.474113] [<c1140f8a>] ? do_sync_read+0x6a/0xa0 [ 403.474154] [<f846fa10>] ? drm_copy_field+0x80/0x80 [drm] [ 403.474193] [<c115134c>] do_vfs_ioctl+0x7c/0x5b0 [ 403.474228] [<c1141d2f>] ? vfs_read+0xef/0x160 [ 403.474263] [<c108dcbb>] ? ktime_get_ts+0x4b/0x120 [ 403.474298] [<c1151917>] SyS_ioctl+0x97/0xa0 [ 403.474330] [<c1590bc1>] sysenter_do_call+0x12/0x22 [ 403.474364] Code: 55 f4 8b 45 f8 e9 75 ff ff ff 90 55 89 e5 53 83 ec 14 8b 08 8b 50 04 81 f9 00 01 10 00 74 24 81 fa 00 02 20 00 0f 84 8e 00 00 00 <8b> 1a 39 d8 75 62 8b 59 04 39 d8 75 35 89 51 04 89 0a 83 c4 14 [ 403.474566] EIP: [<c12c1500>] __list_del_entry+0x20/0xe0 SS:ESP 0068:ee6a3c48 [ 403.476513] CR2: 000000006b6b6b6b v2: Missed the drm_object_unreference use after free (Ville) Daniel Vetter <[email protected]> writes: Reported-by: Mika Kuoppala <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Chris Wilson <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Chris Wilson <[email protected]> [danvet: Add the Oops from Mika to the commit message.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-23Merge tag 'drm-intel-fixes-2013-08-23' of ↵Dave Airlie2-0/+14
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Just one patch that soaked for quite a bit to fix a resume issue, resulting in gpu hangs (or worse) due to tlb containing garbage. * tag 'drm-intel-fixes-2013-08-23' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Invalidate TLBs for the rings after a reset
2013-08-23i2c: move OF helpers into the coreWolfram Sang2-2/+0
I2C of helpers used to live in of_i2c.c but experience (from SPI) shows that it is much cleaner to have this in the core. This also removes a circular dependency between the helpers and the core, and so we can finally register child nodes in the core instead of doing this manually in each driver. So, fix the drivers and documentation, too. Signed-off-by: Wolfram Sang <[email protected]>
2013-08-22drm/i915: prepare bind_to_vm for preallocated vmaBen Widawsky2-6/+20
In the new execbuf code we want to track buffers using the vmas even before they're all properly mapped. Which means that bind_to_vm needs to deal with buffers which have preallocated vmas which aren't yet bound. This patch implements this prep work and adjusts our WARN/BUG checks. Signed-off-by: Ben Widawsky <[email protected]> [danvet: Split out from Ben's big execbuf patch. Also move one BUG back to its original place to deflate the diff a notch.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Switch eviction code to use vmasBen Widawsky3-17/+19
The execbuf wants to do relocations usings vmas, so we need a vma->exec_list. The eviction code also uses the old obj execbuf list for it's own book-keeping, but would really prefer to deal in vmas only. So switch it over to the new list. Again this is just a prep patch for the big execbuf vma conversion. Signed-off-by: Ben Widawsky <[email protected]> [danvet: Split out from Ben's big execbuf vma patch.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: s/obj->exec_list/obj->obj_exec_link in debugfsBen Widawsky3-6/+9
To convert the execbuf code over to use vmas natively we need to shuffle the exec_list a bit. This patch here just prepares things with the debugfs code, which also uses the old exec_list list_head, newly called obj_exec_link. Signed-off-by: Ben Widawsky <[email protected]> [danvet: Split out from Ben's big patch.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22i915: Add a Kconfig option to turn on i915.preliminary_hw_support by defaultJosh Triplett2-2/+13
When building kernels for a preliminary hardware target, having to add a kernel command-line option can prove inconvenient. Add a Kconfig option that changes the default of this option to 1. Signed-off-by: Josh Triplett <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> [danvet: Pimp the Kconfig help text a bit as suggested by Damien in his 2nd review.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: enable the power well before module unloadPaulo Zanoni1-1/+6
Our driver initialization doesn't seem to be ready to load when the power well is disabled: we hit a few "Unclaimed register" messages. So do just like we already do for the suspend/resume path: enable the power well before unloading. At some point we'll want to be able to survive suspend/resume and load/unload with the power well disabled, but for now let's just fix the regression. Regression introduced by the following commit: commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41 Author: Paulo Zanoni <[email protected]> Date: Wed Jul 3 17:12:13 2013 -0300 drm/i915: switch disable_power_well default value to 1 Bug can be reproduced by running the "module_reload" script from intel-gpu-tools. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813 Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: explicit store base gem object in dma_buf->privDaniel Vetter1-9/+12
Makes it more obviously correct what tricks we play by reusing the drm prime release helper. Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: unpin backing storage in dmabuf_unmapDaniel Vetter1-0/+8
This fixes a WARN in i915_gem_free_object when the obj->pages_pin_count isn't 0. v2: Add locking to unmap, noticed by Chris Wilson. Note that even though we call unmap with our own dev->struct_mutex held that won't result in an immediate deadlock since we never go through the dma_buf interfaces for our own, reimported buffers. But it's still easy to blow up and anger lockdep, but that's already the case with our ->map implementation. Fixing this for real will involve per dma-buf ww mutex locking by the callers. And lots of fun. So go with the duct-tape approach for now. Cc: Chris Wilson <[email protected]> Reported-by: Maarten Lankhorst <[email protected]> Cc: Maarten Lankhorst <[email protected]> Tested-by: Armin K. <[email protected]> (v1) Acked-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Only unmask required PM interruptsVinit Azad1-2/+2
Un-masking all PM interrupts causes hardware to generate interrupts regardless of whether the interrupts are enabled on the DE side. Since turbo only need up/down threshold and rc6 timeout interrupt, mask all other interrupts bits to avoid unnecessary overhead/wake up. Note that our interrupt handler isn't being fired since we do set the IER bits properly (IIR bits aren't set). The overhead isn't because our driver is reacting to these interrupts, but because hardware keeps generating internal messages when PMINTRMSK doesn't mask out the up/down EI interrupts (which happen periodically). Change-Id: I6c947df6fd5f60584d39b9e8b8c89faa51a5e827 Signed-off-by: Vinit Azad <[email protected]> [danvet: Add follow-up explanation of the precise effects from Vinit as a note to the commit message.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: clarify Haswell power well bit namesPaulo Zanoni3-9/+10
Whenever I need to work with the HSW_PWER_WELL_* register bits I have to look at the documentation to find out which bit is to request the power well and which one shows its current state. Rename the bits so I won't need to look the docs every time. Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: check the power well when redisabling VGAPaulo Zanoni1-0/+11
If the power well is disabled VGA is guaranteed to be disabled. This fixes unclaimed register messages that happen on suspend/resume. v2: Check the actual hw power well state instead of our own tracking to make sure VGA is _really_ off (in case the BIOS/KVMr has just its own request bit set). Requested by Ville. Note: Ville suggested whether it wouldn't be better to just enable the power well over a slightly longer time in our resume code, since we already do that. I tend to agree, but there's also the modeset force code in the lid notifier which _also_ eventually calls redisable_vga. We shouldn't ever need this on somewhat modern hw (everything with opregion essentially) but the code to bail out isn't there. Hence stick with this simple approach here for now. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67517 Signed-off-by: Paulo Zanoni <[email protected]> [danvet: Summarize the discussion around the resume sequence and lid notifier a bit.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Drop the overzealous warning from i915_gem_set_cache_levelChris Wilson1-1/+0
By our earlier reckoning, move from a snooped/llc setting to an uncached setting, leaves the CPU cache in a consistent state irrespective of our domain tracking - so we can forgo the warning about the lack of invalidation. Similarly for any writes posted to the snooped CPU domain, we know will be safely clflushed to the uncached PTEs after forcing the domain change. This WARN started to pop up with commit d46f1c3f1372e3a72fab97c60480aa4a1084387f Author: Chris Wilson <[email protected]> AuthorDate: Thu Aug 8 14:41:06 2013 +0100 drm/i915: Allow the GPU to cache stolen memory Ville brought up a scenario where the interaction of a set_caching ioctl call from userspace on a scanout buffer (i.e. obj->pin_display is set) resulted in the code getting confused and not properly flushing stale cpu cachelines. Luckily we already prevent this by rejecting caching changes when obj->pin_count is set. Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68040 Tested-by: cancan,feng <[email protected]> [danvet: Add buglink, bisect result and explain why Ville's scenario is already taken care of.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm: WARN when removing unallocated nodeBen Widawsky1-0/+3
The conditional is usually a recoverable driver bug, and so WARNing, and preventing the drm_mm code from doing potential damage (BUG) is desirable. This issue was hit and fixed twice while developing the i915 multiple address space code. The first fix is the patch just before this, and is hit on an not frequently occuring error path. Another was fixed during patch iteration, so it's hard to see from the patch: commit c6cfb325677ea6305fb19acf3a4d14ea267f923e Author: Ben Widawsky <[email protected]> Date: Fri Jul 5 14:41:06 2013 -0700 drm/i915: Embed drm_mm_node in i915 gem obj From the intel-gfx mailing list, we discussed this: References: <[email protected]> Cc: Dave Airlie <[email protected]> CC: <[email protected]> Acked-by: Chris Wilson <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Acked-by: Dave Airlie <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: use vma->node directly and rewrap map&fence in bindDaniel Vetter1-5/+4
Use () to make for neater alignment of the split lines, too. With this we ditch another jump through the obj_gtt_size/offset indirection maze. Cc: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: cleanup map&fence in bindBen Widawsky1-10/+9
Cleanup the map and fenceable setting during bind to make more sense, and not check i915_is_ggtt() 2 unnecessary times v2: Move the bools into the if block (Chris) - There are ways to tidy this function (fence calculations for instance) even further, but they are quite invasive, so I am punting on those unless specifically asked. v3: Add newline between variable declaration and logic (Chris) Recommended-by: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Remove node only when allocatedBen Widawsky1-0/+5
VMAs can be created and not bound. One may think of it as lazy cleanup, and safely gloss over the conditions which manufacture it. In either case, when the object backing the i915 vma is destroyed, we must cleanup the vma without stumbling into a bunch of pitfalls that assume the vma is bound. NOTE: I was pretty certain the above condition could only happen when we introduced the use of VMAs being looked up at execbuf, and already existing. Paulo has hit this though, so I must be missing something. As I believe the patch is correct anyway, therefore I won't scratch my head too hard. v2: use goto destroy as a compromise (Chris) Cc: Chris Wilson <[email protected]> Cc: Paulo Zanoni <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: clarify error paths in create_stolen_for_preallocatedDaniel Vetter1-2/+3
Use the standard inversely ordered goto label stack for everything. Spotted while reviewing place where we might need to to call vma_destroy but failed to do so. Cc: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Get VECS semaphore info on errorBen Widawsky1-0/+11
Ideally we could use for_each_ring with the ring flags as I've done a couple times (http://lists.freedesktop.org/archives/intel-gfx/2013-June/029450.html). Until Daniel merges that patch though, we can just use this. Cc: Mika Kuoppala <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Initialize seqno for VECS tooBen Widawsky1-0/+2
We require n-1 mailboxes for proper semaphore synchronization. All semaphore synchronization code relies on proper values in these mailboxes. The fact that we failed to touch the vebox ring by itself was unlikely to be an issue since the HW should be initializing the values to 0. However the error framework for testing seqno wrap introduced by Mika, in addition to the hangcheck via seqno, and i915_error_first_batchbuffer() combined caused a nice explosion. The problem is caused by seqno wrap because the wrap condition is not properly setup. The wrap code attempts to set the sync mailboxes all to 0, and then set the current seqno to one less than 0. In all cases, the vebox mailbox wasn't properly being initialized. This caused a wrap to not occur. When hangcheck kicks in with the bogus seqno values, the rest just doesn't work. It makes me wonder if we shouldn't consider a dumber version of hangcheck... How we messed this up: VECS support was written before the aforementioned other features. Upon VECS being rebased, these facts were missed. Cc: Mika Kuoppala <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198 Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: tune the RC6 threshold for stabilityStéphane Marchesin1-1/+4
It's basically the same deal as the RC6+ issues on ivy bridge except this time with RC6 on sandy bridge. Like last time the core of the issue is that the timings don't work 100% with our voltage regulator. So from time to time, the kernel will print a warning message about the GPU not getting out of RC6. In particular, I found this fairly easy to reproduce during suspend/resume. Changing the threshold to 125000 instead of 50000 seems to fix the issue. The previous patch used 150000 but as it turns out this doesn't work everywhere. After getting such a machine, I bisected the highest value which works, which is 125000, so here it is. I also measured the idle power usage before/after this patch and didn't see a difference on a sandy bridge laptop. On haswell and up, it makes a big difference, so we want to keep it at 50k there. It also seems like haswell doesn't have the RC6 issues that sandy bridge has so the 50k value is fine. Signed-off-by: Stéphane Marchesin <[email protected]> Acked-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: print a message when we detect an early Haswell SDVPaulo Zanoni2-0/+10
The machines that fall in this category are the SDVs that have a PCI ID starting with 0x0C. These are very early pre-production machines and may not fully work. Other Haswell SDVs have PCI IDs that match the real Haswell machines and we expect them to work better. Even though they have problems, they still mostly work so I don't see a reason to refuse loading our driver. But I do see a reason to reject bug reports from these machines, so the message should help the bug triagers. As far as I know, we don't implement some workarounds that are specific to these machines and suspend/resume may not work on most of them, but besides this, they may work. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508 Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Print the changes required for modesetChris Wilson1-0/+3
After computing the stage changes for the set_config, record those in the debug log. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: remove set but unused variablesPaulo Zanoni3-15/+2
Caught by "make W=1 drivers/gpu/drm/i915/". Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Allow the user to set bo into the DISPLAY cache domainChris Wilson1-0/+7
This is primarily for the benefit of the create2 ioctl so that the caller can avoid the later step of rebinding the bo with new PTE bits. After introducing WT (and possibly GFDT) cacheing for display targets, not everything in the display is earmarked as UC, and more importantly what is is controlled by the kernel. Note that set_cache_level/get_cache_level for DISPLAY is not necessarily idempotent; get_cache_level may return UC for architectures that have no special cache domain for the display engine. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Use Write-Through cacheing for the display plane on IrisChris Wilson4-4/+28
Haswell GT3e has the unique feature of supporting Write-Through cacheing of objects within the eLLC/LLC. The purpose of this is to enable the display plane to remain coherent whilst objects lie resident in the eLLC/LLC - so that we, in theory, get the best of both worlds, perfect display and fast access. However, we still need to be careful as the CPU does not see the WT when accessing the cache. In particular, this means that we need to flush the cache lines after writing to an object through the CPU, and on transitioning from a cached state to WT. v2: Actually do the clflush on transition to WT, nagging by Ville. v3: Flush the CPU cache after writes into WT objects. v4: Rease onto LLC updates and report WT as "uncached" for get_cache_level_ioctl to remain symmetric with set_cache_level_ioctl. Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: drop unnecessary local variable to suppress build warningJani Nikula1-7/+3
Although I could not reproduce this (different compiler version, perhaps), reportedly we get: drivers/gpu/drm/i915/i915_irq.c:1943:27: warning: ‘score’ may be used uninitialized in this function [-Wuninitialized] Drop the 'score' variable altogether as it's not really needed. Reported-by: Kees Cook <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: give more distinctive names to ring hangcheck action enumsJani Nikula3-13/+18
The short lowercase names are bound to collide. The default warnings don't even warn about shadowing. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: remove unused leftover variable irq_receivedJani Nikula1-2/+0
It's been there since i8xx_irq_handler() was added in commit c2798b19bac2538393fc932bfbe59807a4734b3e Author: Chris Wilson <[email protected]> Date: Sun Apr 22 21:13:57 2012 +0100 drm/i915: i8xx interrupt handler Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22i915: Fix SDVO potentially turning off randomlyGuillaume Clement1-1/+2
Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off. This could also happen to i915. Signed-off-by: Guillaume Clement <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: WARN_ON failed map_and_fenceableBen Widawsky1-0/+2
I just noticed in our code we don't really check the assertion, and given some of the code I am changing in this area, I feel a WARN is very nice to have. Signed-off-by: Ben Widawsky <[email protected]> [danvet: s/&/&&/ to fix typo on the check.] Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22drm/i915: Only do a chipset flush after a clflushChris Wilson3-12/+15
Now that we skip clflushes more often, return a boolean indicating whether the clflush was actually performed, and only if it was do the chipset flush. (Though on most of the architectures where the clflush will be skipped, the chipset flush is a no-op!) Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-08-22Merge branch 'gma500-next' of git://github.com/patjak/drm-gma500 into drm-nextDave Airlie26-2168/+1446
Here's some gma500 unifying and cleanups for drm-next. There is more stuff in the pipe for 3.12 but I'd like to get these out of the way first. * 'gma500-next' of git://github.com/patjak/drm-gma500: (35 commits) drm/gma500/cdv: Add and hook up chip op for disabling sr drm/gma500/cdv: Add and hook up chip op for watermarks drm/gma500: Rename psb_intel_encoder to gma_encoder drm/gma500: Rename psb_intel_connector to gma_connector drm/gma500: Rename psb_intel_crtc to gma_crtc drm/gma500/cdv: Convert to generic set_config() drm/gma500/psb: Convert to generic set_config() drm/gma500: Add generic set_config() function drm/gma500/cdv: Convert to generic save/restore drm/gma500/psb: Convert to generic save/restore drm/gma500: Add generic crtc save/restore funcs drm/gma500: Convert to generic encoder funcs drm/gma500: Add generic encoder functions drm/gma500/psb: Convert to generic cursor funcs drm/gma500/cdv: Convert to generic cursor funcs drm/gma500: Add generic cursor functions drm/gma500/psb: Convert to generic crtc->destroy drm/gma500/mdfld: Use identical generic crtc funcs drm/gma500/oak: Use identical generic crtc funcs drm/gma500/psb: Convert to gma_crtc_dpms() ...
2013-08-22gma500: Fix SDVO turning off randomlyGuillaume Clement1-1/+2
Some Poulsbo cards seem to incorrectly report SDVO_CMD_STATUS_TARGET_NOT_SPECIFIED instead of SDVO_CMD_STATUS_PENDING, which causes the display to be turned off. Signed-off-by: Guillaume Clement <[email protected]> Acked-by: Patrik Jakobsson <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-22Merge branch 'drm-nouveau-next' of ↵Dave Airlie15-48/+98
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes regression fixes and null derefs and oops fixes. * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nv04/disp: fix framebuffer pin refcounting drm/nouveau/mc: fix race condition between constructor and request_irq() drm/nouveau: fix reclocking on nv40 drm/nouveau/ltcg: fix allocating memory as free drm/nouveau/ltcg: fix ltcg memory initialization after suspend drm/nouveau/fb: fix null derefs in nv49 and nv4e init
2013-08-21drm/prime: Always add exported buffers to the handle cacheDaniel Vetter2-35/+52
... not only when the dma-buf is freshly created. In contrived examples someone else could have exported/imported the dma-buf already and handed us the gem object with a flink name. If such on object gets reexported as a dma_buf we won't have it in the handle cache already, which breaks the guarantee that for dma-buf imports we always hand back an existing handle if there is one. This is exercised by igt/prime_self_import/with_one_bo_two_files Now if we extend the locked sections just a notch more we can also plug th racy buf/handle cache setup in handle_to_fd: If evil userspace races a concurrent gem close against a prime export operation we can end up tearing down the gem handle before the dma buf handle cache is set up. When handle_to_fd gets around to adding the handle to the cache there will be no one left to clean it up, effectily leaking the bo (and the dma-buf, since the handle cache holds a ref on the dma-buf): Thread A Thread B handle_to_fd: lookup gem object from handle creates new dma_buf gem_close on the same handle obj->dma_buf is set, but file priv buf handle cache has no entry obj->handle_count drops to 0 drm_prime_add_buf_handle sets up the handle cache -> We have a dma-buf reference in the handle cache, but since the handle_count of the gem object already dropped to 0 no on will clean it up. When closing the drm device fd we'll hit the WARN_ON in drm_prime_destroy_file_private. The important change is to extend the critical section of the filp->prime.lock to cover the gem handle lookup. This serializes with a concurrent gem handle close. This leak is exercised by igt/prime_self_import/export-vs-gem_close-race Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/prime: make drm_prime_lookup_buf_handle staticDaniel Vetter1-14/+15
... and move it to the top of the function to avoid a forward declaration. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/prime: Simplify drm_gem_remove_prime_handlesDaniel Vetter1-5/+0
with the reworking semantics and locking of the obj->dma_buf pointer this pointer is always set as long as there's still a gem handle around and a dma_buf associated with this gem object. Also, the per file-priv lookup-cache for dma-buf importing is also unified between foreign and native objects. Hence we don't need to special case the clean any more and can simply drop the clause which only runs for foreing objects, i.e. with obj->import_attach set. Note that with this change (actually with the previous one to always set up obj->dma_buf even for foreign objects) it is no longer required to set obj->import_attach when importing a foreing object. So update comments accordingly, too. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/prime: proper locking+refcounting for obj->dma_buf linkDaniel Vetter3-18/+77
The export dma-buf cache is semantically similar to an flink name. So semantically it makes sense to treat it the same and remove the name (i.e. the dma_buf pointer) and its references when the last gem handle disappears. Again we need to be careful, but double so: Not just could someone race and export with a gem close ioctl (so we need to recheck obj->handle_count again when assigning the new name), but multiple exports can also race against each another. This is prevented by holding the dev->object_name_lock across the entire section which touches obj->dma_buf. With the new scheme we also need to reinstate the obj->dma_buf link at import time (in case the only reference userspace has held in-between was through the dma-buf fd and not through any native gem handle). For simplicity we don't check whether it's a native object but unconditionally set up that link - with the new scheme of removing the obj->dma_buf reference when the last handle disappears we can do that. To make it clear that this is not just for exported buffers anymore als rename it from export_dma_buf to dma_buf. To make sure that now one can race a fd_to_handle or handle_to_fd with gem_close we use the same tricks as in flink of extending the dev->object_name_locking critical section. With this change we finally have a guaranteed 1:1 relationship (at least for native objects) between gem objects and dma-bufs, even accounting for races (which can happen since the dma-buf itself holds a reference while in-flight). This prevent igt/prime_self_import/export-vs-gem_close-race from Oopsing the kernel. There is still a leak though since the per-file priv dma-buf/handle cache handling is racy. That will be fixed in a later patch. v2: Remove the bogus dma_buf_put from the export_and_register_object failure path if we've raced with the handle count dropping to 0. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/gem: completely close gem_open vs. gem_close racesDaniel Vetter1-11/+31
The gem flink name holds a reference onto the object itself, and this self-reference would prevent an flink'ed object from every being freed. To break that loop we remove the flink name when the last userspace handle disappears, i.e. when obj->handle_count reaches 0. Now in gem_open we drop the dev->object_name_lock between the flink name lookup and actually adding the handle. This means a concurrent gem_close of the last handle could result in the flink name getting reaped right inbetween, i.e. Thread 1 Thread 2 gem_open gem_close flink -> obj lookup handle_count drops to 0 remove flink name create_handle handle_count++ If someone now flinks this object again, we'll get a new flink name. We can close this race by removing the lock dropping and making the entire lookup+handle_create sequence atomic. Unfortunately to still be able to share the handle_create logic this requires a handle_create_tail function which drops the lock - we can't hold the object_name_lock while calling into a driver's ->gem_open callback. Note that for flink fixing this race isn't really important, since racing gem_open against gem_close is clearly a userspace bug. And no matter how the race ends, we won't leak any references. But with dma-buf where the userspace dma-buf fd itself is refcounted this is a valid sequence and hence we should fix it. Therefore this patch here is just a warm-up exercise (and for consistency between flink buffer sharing and dma-buf buffer sharing with self-imports). Also note that this extension of the critical section in gem_open protected by dev->object_name_lock only works because it's now a mutex: A spinlock would conflict with the potential memory allocation in idr_preload(). This is exercises by igt/gem_flink_race/flink_name. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/gem: switch dev->object_name_lock to a mutexDaniel Vetter2-11/+11
I want to wrap the creation of a dma-buf from a gem object in it, so that the obj->export_dma_buf cache can be atomically filled in. Instead of creating a new mutex just for that variable I've figured I can reuse the existing dev->object_name_lock, especially since the new semantics will exactly mirror the flink obj->name already protected by that lock. v2: idr_preload/idr_preload_end is now an atomic section, so need to move the mutex locking outside. [airlied: fix up conflict with patch to make debugfs use lock] Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/prime: clarify logic a bit in drm_gem_prime_fd_to_handleDaniel Vetter1-3/+1
if (!ret) implies that ret == 0, so no need to clear it again. And explicitly check for ret == 0 to indicate that we're checking an errno integer. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-08-21drm/prime: shrink critical section protected by prime lockDaniel Vetter1-2/+2
When exporting a gem object as a dma-buf the critical section for the per-fd prime lock is just the adding (and in case of errors, removing) of the handle to the per-fd lookup cache. So restrict the critical section to just that part of the function. This simplifies later reordering. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.