- 14 Nov, 2016 6 commits
-
-
Paulo Zanoni authored
We can just call it earlier, so do it. The goal of the loop is to get the plane's CRTC state, and we don't need it in order to call intel_fbc_can_choose(). Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1478883461-20201-2-git-send-email-paulo.r.zanoni@intel.com
-
Chris Wilson authored
When supplying a view to vma_compare() it is required that the supplied i915_address_space is the global GTT. I tested the VMA instead (which is the current position in the rbtree and maybe from any address space). (This reapplies commit a44342ac ("drm/i915: Fix test on inputs for vma_compare()") as it was lost in the vma split) Reported-by:
Matthew Auld <matthew.auld@intel.com> Tested-by:
-
Paulo Zanoni authored
The previous spec version said "double Ytile planes minimum lines", and I interpreted this as referring to what the spec calls "Y tile minimum", but in fact it was referring to what the spec calls "Minimum Scanlines for Y tile". I noticed that Mahesh Kumar had a different interpretation, so I sent and email to the spec authors and got clarification on the correct meaning. Also, BSpec was updated and should be clear now. Fixes: ee3d532f ("drm/i915/gen9: unconditionally apply the memory bandwidth WA") Cc: stable@vger.kernel.org Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478636531-6081-1-git-send-email-paulo.r.zanoni@intel.com
-
Ville Syrjälä authored
My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT port information apparently didn't survive the reality of buggy VBTs. In this particular case we have a machine with a natice HDMI port, but the VBT tells us it's a DP++ port based on its capabilities. The dvo_port information in VBT does claim that we're dealing with a HDMI port though, but we have other machines which do the same even when they actually have DP++ ports. So that piece of information alone isn't sufficient to tell the two apart. After staring at a bunch of VBTs from various machines, I have to conclude that the only other semi-reliable clue we can use is the presence of the AUX channel in the VBT. On this particular machine AUX channel is specified as zero, whereas on some of the other machines which listed the DP++ port as HDMI have a non-zero AUX channel. I've also seen VBTs which have dvo_port a DP but have a zero AUX channel. I believe those we need to treat as DP ports, so we'll limit the AUX channel check to just the cases where dvo_port is HDMI. If we encounter any more serious failures with this heuristic I think we'll have to have to throw it out entirely. But that could mean that there is a risk of type 1 DVI dongle users getting greeted by a black screen, so I'd rather not go there unless absolutely necessary. v2: Remove the duplicate PORT_A check (Daniel) Fix some typos in the commit message Cc: Daniel Otero <daniel.otero@outlook.com> Cc: stable@vger.kernel.org Tested-by:Daniel Otero <daniel.otero@outlook.com> Fixes: d6199256 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478884464-14251-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
The term "preliminary hardware support" has always caused confusion both among users and developers. It has always been about preliminary driver support for new hardware, and not so much about preliminary hardware. Of course, initially both the software and hardware are in early stages, but the distinction becomes more clear when the user picks up production hardware and an older kernel to go with it, with just the early support we had for the hardware at the time the kernel was released. The user has to specifically enable the alpha quality *driver* support for the hardware in that specific kernel version. Rename preliminary_hw_support to alpha_support to emphasize that the module parameter, config option, and flag are about software, not about hardware. Improve the language in help texts and debug logging as well. This appears to be a good time to do the change, as there are currently no platforms with preliminary^W alpha support. Cc: Rob Clark <robdclark@gmail.com> Cc: Dave Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477909108-18696-1-git-send-email-jani.nikula@intel.com
-
Joonas Lahtinen authored
Update i915_driver_load kerneldoc to match code. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
- 11 Nov, 2016 8 commits
-
-
Chris Wilson authored
When we release the shmem backing storage, we make sure that the pages are coherent with the cpu cache. However, our clflush routine was skipping the flush as the object had no pages at release time. Fix this by explicitly flushing the sg_table we are decoupling. Fixes: 03ac84f1 ("drm/i915: Pass around sg_table to get_pages/put_pages backend") Signed-off-by:
-
Chris Wilson authored
In order to walk the list of all timelines, we currently require the struct_mutex. We are sometimes called prior to the struct_mutex being taken by the caller (i.e !I915_WAIT_LOCKED) in which case we can only trust the global execution timelines (as these are owned by the device). This means in the unlocked phase we can only wait upon the currently executing requests and not all queued. [ 175.743243] general protection fault: 0000 [#1] SMP [ 175.743263] Modules linked in: nls_iso8859_1 intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlwifi aesni_intel aes_x86_64 lrw snd_soc_rt5640 gf128mul snd_soc_rl6231 snd_soc_core glue_helper snd_compress snd_pcm_dmaengine snd_hda_codec_hdmi ablk_helper snd_hda_codec_realtek cryptd snd_hda_codec_generic serio_raw cfg80211 snd_hda_intel snd_hda_codec ir_lirc_codec snd_hda_core lirc_dev snd_hwdep snd_pcm lpc_ich mei_me mei snd_seq_midi shpchp snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer rc_rc6_mce acpi_als nuvoton_cir kfifo_buf rc_core snd industrialio snd_soc_sst_acpi soundcore snd_soc_sst_match i2c_designware_platform 8250_dw i2c_designware_core dw_dmac spi_pxa2xx_platform mac_hid acpi_pad parport_pc ppdev lp parport [ 175.743509] autofs4 i915 e1000e psmouse ptp pps_core xhci_pci ehci_pci ahci xhci_hcd ehci_hcd libahci video sdhci_acpi sdhci i2c_hid hid [ 175.743560] CPU: 2 PID: 2386 Comm: wtdg_monitor.sh Tainted: G U 4.9.0-rc4-nightly+ #2 [ 175.743581] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0358.2016.0606.1423 06/06/2016 [ 175.743603] task: ffff88024509ba80 task.stack: ffffc9007bd18000 [ 175.743618] RIP: 0010:[<ffffffffa01af29b>] [<ffffffffa01af29b>] i915_gem_wait_for_idle+0x3b/0x140 [i915] [ 175.743660] RSP: 0000:ffffc9007bd1b9b8 EFLAGS: 00010297 [ 175.743674] RAX: ffff88024489d248 RBX: 0000000000000000 RCX: 0000000000000000 [ 175.743691] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880244898000 [ 175.743708] RBP: ffffc9007bd1b9f0 R08: 0000000000000000 R09: 0000000000000001 [ 175.743724] R10: 00000028eaf42792 R11: 0000000000000001 R12: dead000000000100 [ 175.743741] R13: dead000000000148 R14: ffffc9007bd1ba5f R15: 0000000000000005 [ 175.743758] FS: 00007f2638330700(0000) GS:ffff880256d00000(0000) knlGS:0000000000000000 [ 175.743777] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 175.743791] CR2: 00007f885c8cea40 CR3: 00000002416b5000 CR4: 00000000003406e0 [ 175.743808] Stack: [ 175.743816] ffff88024489d248 000000004509ba80 ffff880244898000 ffff88024509ba80 [ 175.743840] 00000000ffff8b69 ffffc9007bd1ba5f ffffc9007bd1ba5e ffffc9007bd1ba28 [ 175.743863] ffffffffa01b661d 00000000ffffffff 0000000000000000 ffff880244898000 [ 175.743886] Call Trace: [ 175.743906] [<ffffffffa01b661d>] i915_gem_shrinker_lock_uninterruptible.constprop.5+0x5d/0xc0 [i915] [ 175.743937] [<ffffffffa01b6cd0>] i915_gem_shrinker_oom+0x30/0x1b0 [i915] [ 175.743955] [<ffffffff8109ca79>] notifier_call_chain+0x49/0x70 [ 175.743971] [<ffffffff8109cd9d>] __blocking_notifier_call_chain+0x4d/0x70 [ 175.743988] [<ffffffff8109cdd6>] blocking_notifier_call_chain+0x16/0x20 [ 175.744005] [<ffffffff811885dc>] out_of_memory+0x22c/0x480 [ 175.744020] [<ffffffff81205542>] __alloc_pages_slowpath+0x851/0x8ec [ 175.744037] [<ffffffff8118ca51>] __alloc_pages_nodemask+0x2c1/0x310 [ 175.744054] [<ffffffff811d8ea8>] alloc_pages_current+0x88/0x120 [ 175.744070] [<ffffffff811833a4>] __page_cache_alloc+0xb4/0xc0 [ 175.744086] [<ffffffff811865ca>] filemap_fault+0x29a/0x500 [ 175.744101] [<ffffffff81299aa6>] ext4_filemap_fault+0x36/0x50 [ 175.744117] [<ffffffff811b3d4a>] __do_fault+0x6a/0xe0 [ 175.744131] [<ffffffff811b97ee>] handle_mm_fault+0xd0e/0x1330 [ 175.744147] [<ffffffff8106738c>] __do_page_fault+0x23c/0x4d0 [ 175.744162] [<ffffffff81067650>] do_page_fault+0x30/0x80 [ 175.744177] [<ffffffff817ffbe8>] page_fault+0x28/0x30 [ 175.744191] Code: 41 57 41 56 41 55 41 54 53 48 83 ec 10 4c 8b a7 48 52 00 00 89 75 d4 48 89 45 c8 49 39 c4 74 78 4d 8d 6c 24 48 41 bf 05 00 00 00 <49> 8b 5d 00 48 85 db 74 50 8b 83 20 01 00 00 85 c0 74 15 48 8b [ 175.744320] RIP [<ffffffffa01af29b>] i915_gem_wait_for_idle+0x3b/0x140 [i915] [ 175.744351] RSP <ffffc9007bd1b9b8> Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Signed-off-by:
-
Tvrtko Ursulin authored
Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
David Weinehall <david.weinehall@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478270568-7902-2-git-send-email-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
After this patch only conversion of INTEL_INFO(p)->gen to INTEL_GEN(dev_priv) remains before the __I915__ macro can be removed. v2: Tidy vlv_compute_wm. (David Weinehall) Signed-off-by:
-
Tvrtko Ursulin authored
A small selection of macros which can only accept dev_priv from now on and a resulting trickle of fixups. Signed-off-by:
-
Tvrtko Ursulin authored
A small selection of macros which can only accept dev_priv from now on and a resulting trickle of fixups. v2: Keep original order. (Ville Syrjala) Signed-off-by:
-
Tvrtko Ursulin authored
A small selection of macros which can only accept dev_priv from now on and a resulting trickle of fixups. Signed-off-by:
-
Joonas Lahtinen authored
As a side product, had to split two other files; - i915_gem_fence_reg.h - i915_gem_object.h (only parts that needed immediate untanglement) I tried to move code in as big chunks as possible, to make review easier. i915_vma_compare was moved to a header temporarily. v2: - Use i915_gem_fence_reg.{c,h} v3: - Rebased v4: - Fix building when DEBUG_GEM is enabled by reordering a bit. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
- 10 Nov, 2016 11 commits
-
-
https://github.com/01org/gvt-linuxDaniel Vetter authored
Merge tag 'gvt-next-kvmgt-framework' of https://github.com/01org/gvt-linux into drm-intel-next-queued Zhenyu Wang writes: gvt-next-kvmgt-framework This adds initial KVMGT framework based on GVT-g MPT(Mediated Passthrough) interface. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Tvrtko Ursulin authored
At the moment we allocate enough sg table entries assuming we will not be able to do any coalescing. But since in practice we most often can, and more so very effectively, this ends up wasting a lot of memory. A simple and effective way of trimming the over-allocated entries is to copy the table over to a new one allocated to the exact size. Experiments on my freshly logged and idle desktop (KDE) showed that by doing this we can save approximately 1 MiB of RAM, or when running a typical benchmark like gl_manhattan I have even seen a 6 MiB saving. More complicated techniques such as only copying the last used page and freeing the rest are left to the reader. v2: * Update commit message. * Use temporary sg_table on stack. (Chris Wilson) v3: * Commit message update. * Comment added. * Replace memcpy with copy assignment. (Chris Wilson) Signed-off-by:
-
Jike Song authored
KVMGT is the MPT implementation based on VFIO/KVM. It provides a kvmgt_mpt ops to gvt for vGPU access mediation, e.g. to mediate and emulate the MMIO accesses, to inject interrupts to vGPU user, to intercept the GTT writing and replace it with DMA-able address, to write-protect guest PPGTT table for shadowing synchronization, etc. This patch provides the MPT implementation for GVT, not yet functional due to theabsence of mdev. It's built as kvmgt.ko, depends on vfio.ko, kvm.ko and mdev.ko, and being required by i915.ko. To not introduce hard dependency in i915.ko, we used indirect symbol reference. But that means users have to include kvmgt.ko into init ramdisk if their i915.ko is included. Signed-off-by:
Kevin Tian <kevin.tian@intel.com> Signed-off-by:
Xiaoguang Chen <xiaoguang.chen@intel.com> Signed-off-by:
Jike Song <jike.song@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Jike Song authored
There are currently 4 methods in intel_gvt_io_emulation_ops to emulate CFG/MMIO reading/writing for intel vGPU. A possibly better scope is: add 3 more methods for vgpu create/destroy/reset respectively, and rename the ops to 'intel_gvt_ops', then pass it to the MPT module (say the future kvmgt) to use: they are all methods for external usage. Signed-off-by:
-
Jike Song authored
Hypervisors are different, the MPT ops is a only superset of all possibly supported hypervisors. There might be other way out of the MPT to achieve same target. e.g. vfio-based kvmgt won't provide map_gfn_to_mfn method to establish guest EPT mapping for aperture, since it will be done in QEMU/KVM, MMIO is also trapped elsewhere, etc. Signed-off-by:
-
Jike Song authored
GVT host needs init/exit hooks to do some initialization/cleanup work, e.g.: vfio mdev host device register/unregister. Signed-off-by:
-
Jike Song authored
Current GVT contains some obsolete logic originally cooked to support the old, non-vfio kvmgt, which is actually workarounds. We don't support that anymore, so it's safe to remove it and make a better framework. Signed-off-by:
-
Zhenyu Wang authored
By providing predefined vGPU types, users can choose which type a vgpu to create and use, without specifying detailed parameters. Signed-off-by:
-
Xiaoguang Chen authored
kmap_atomic doesn't allow sleep until unmapped. However, it's necessary to allow sleep during reading/writing guest memory, so use kmap instead. Signed-off-by:
Bing Niu <bing.niu@intel.com> Signed-off-by:
-
Bing Niu authored
On guest writing a PPGTT entry, if it contains value and the old entry is valid, gvt will read it and find & free the corresponding old data for it. However, with the KVM write protection provided by page_track, the guest entry will be written with new value before gvt handling. To avoid that, we should use the shadow entry instead. Signed-off-by:
-
git://git.kernel.org/pub/scm/virt/kvm/kvmDaniel Vetter authored
Paulo Bonzini writes: The three KVM patches that KVMGT needs. Signed-off-by:
-
- 09 Nov, 2016 6 commits
-
-
Chris Wilson authored
When we need to reset the global seqno on wraparound, we have to wait until the current rbtrees are drained (or otherwise the next waiter will be out of sequence). The current mechanism to kick and spin until complete, may exit too early as it would break if the target thread was currently running. Instead, we must wake up the threads, but keep spinning until the trees have been deleted. In order to appease Tvrtko, busy spin rather than yield(). Signed-off-by:
-
Maarten Lankhorst authored
This gets rid of a warning that the connectors are used without locking when doing a nonblocking modeset. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Maarten Lankhorst authored
All of this state should be updated as soon as possible. It shouldn't be done later because then future updates may not depend on it. Changes since v1: - Move the modeset update to before drm_atomic_state_get. (Ville) Signed-off-by:
-
Maarten Lankhorst authored
The only user was i915, which is now gone. Signed-off-by:
-
Maarten Lankhorst authored
drm_select_eld requires mode_config.mutex and connection_mutex because it looks at the connector list and at the legacy encoders. This is not required, because when we call audio_codec_enable we know which connector it was called for, so pass the state. This also removes having to look at crtc->config. Changes since v1: - Use intel_crtc->pipe instead of drm_crtc_index. (Ville) Signed-off-by:
-
Maarten Lankhorst authored
This is the last connector still looking at crtc->config. Fix this. Signed-off-by:
-
- 08 Nov, 2016 8 commits
-
-
Arnd Bergmann authored
The newly added assert_kernel_context_is_current introduces a warning when built with W=1: drivers/gpu/drm/i915/i915_gem.c: In function ‘assert_kernel_context_is_current’: drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty body in an ‘else’ statement [-Werror=empty-body] Changing the GEM_BUG_ON() macro from an empty definition to "do { } while (0)" makes the macro more robust to use and avoids the warning. Fixes: 3033acab ("drm/i915: Queue the idling context switch after all other timelines") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
https://github.com/01org/gvt-linuxDaniel Vetter authored
gvt-next-2016-11-07 - Fix regression from e95433c7 - Some MMIO handler fixes - Add better handling for guest reset control - stratch page table tree for shadow ppgtt Signed-off-by:
-
Ville Syrjälä authored
The code to determine the primary plane offset for gen2/3 looks different than the code for gen4+, but in fact it's doing the same thing. Let's make it uniform. Allows us to eliminate the 'obj' from the list of local variables as well. Signed-off-by:
-
Ville Syrjälä authored
intel_cursor_plane_create() and intel_sprite_plane_create() return an error pointer, so let's not mistakenly look for a NULL pointer. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
-
Ville Syrjälä authored
Use the passed in plane_state instead of plane->state in vlv_update_plane(). Currently the two are one and the same, but if we start queuing up multiple plane updates they might not be. Looks like this was rebase fail on my part. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 8d0deca8 ("drm/i915: Pass 90/270 vs. 0/180 rotation info for intel_gen4_compute_page_offset()") Signed-off-by:
-
Chris Wilson authored
We always flush the chipset prior to executing with the GPU, so we can skip the flush during ordinary domain management. This should help mitigate some of the potential performance regressions, but likely trivial, from doing the flush unconditionally before execbuf introduced in commit dcd79934 ("drm/i915: Unconditionally flush any chipset buffers before execbuf") Signed-off-by:
-
Joonas Lahtinen authored
Get rid of sloppy inline functions now that we don't have more users: i915_gem_request_get_seqno i915_gem_request_get_engine v2: - request->engine is always non-NULL (Chris) Signed-off-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 07 Nov, 2016 1 commit
-
-
Chris Wilson authored
On LLC, or even snooped, machines rendering via the GPU ends up in the CPU cache. This cacheline dirt also needs to be flushed to main memory when moving to an incoherent domain, such as the display's scanout engine. Mostly, this happens because either the object is marked as dirty from its first use or is avoided by setting the object into the display domain from the start. v2: Treat WT as not requiring a clflush prior to use on the display engine as well. Fixes: 0f71979a ("drm/i915: Performed deferred clflush inside set-cache-level") References: https://bugs.freedesktop.org/show_bug.cgi?id=95414Signed-off-by:
-
