1. 15 3月, 2018 1 次提交
    • F
      drm/i915/gvt: Correct the privilege shadow batch buffer address · ef75c685
      fred gao 提交于
      Once the ring buffer is copied to ring_scan_buffer and scanned,
      the shadow batch buffer start address is only updated into
      ring_scan_buffer, not the real ring address allocated through
      intel_ring_begin in later copy_workload_to_ring_buffer.
      
      This patch is only to set the right shadow batch buffer address
      from Ring buffer, not include the shadow_wa_ctx.
      
      v2:
      - refine some comments. (Zhenyu)
      v3:
      - fix typo in title. (Zhenyu)
      v4:
      - remove the unnecessary comments. (Zhenyu)
      - add comments in bb_start_cmd_va update. (Zhenyu)
      
      Fixes: 0a53bc07 ("drm/i915/gvt: Separate cmd scan from request allocation")
      Cc: stable@vger.kernel.org  # v4.15
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Yulei Zhang <yulei.zhang@intel.com>
      Signed-off-by: Nfred gao <fred.gao@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      ef75c685
  2. 09 3月, 2018 2 次提交
    • M
      drm/i915/gvt: keep oa config in shadow ctx · fa3dd623
      Min He 提交于
      When populating shadow ctx from guest, we should handle oa related
      registers in hw ctx, so that they will not be overlapped by guest oa
      configs. This patch made it possible to capture oa data from host for
      both host and guests.
      Signed-off-by: NMin He <min.he@intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      fa3dd623
    • X
      drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio · b24881e0
      Xiong Zhang 提交于
      If user continuously create vgpu, boot guest, shoutdown guest and destroy
      vgpu from remote, the following calltrace exists in dmesg sometimes:
      [ 6412.954721] RPM wakelock ref not held during HW access
      [ 6412.954795] WARNING: CPU: 7 PID: 11941 at
      linux/drivers/gpu/drm/i915/intel_drv.h:1800
      intel_uncore_forcewake_get.part.7+0x96/0xa0 [i915]
      [ 6412.954915] Call Trace:
      [ 6412.954951] intel_uncore_forcewake_get+0x18/0x20 [i915]
      [ 6412.954989] intel_gvt_switch_mmio+0x8e/0x770 [i915]
      [ 6412.954996] ? __slab_free+0x14d/0x2c0
      [ 6412.955001] ? __slab_free+0x14d/0x2c0
      [ 6412.955006] ? __slab_free+0x14d/0x2c0
      [ 6412.955041] intel_vgpu_stop_schedule+0x92/0xd0 [i915]
      [ 6412.955073] intel_gvt_deactivate_vgpu+0x48/0x60 [i915]
      [ 6412.955078] __intel_vgpu_release+0x55/0x260 [kvmgt]
      
      when this happens, gvt_switch_mmio is called at vgpu destroy, host i915 is
      idle and doesn't hold RPM wakelock, igd is in powersave mode, but
      gvt_switch_mmio require igd power on to access register, so
      intel_runtime_pm_get should be added to make sure igd power on before
      gvt_switch_mmio.
      
      v2: Move runtime_pm_get/put into gvt_switch_mmio.(Zhenyu)
      Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      b24881e0
  3. 06 3月, 2018 2 次提交
    • C
      drm/i915: Suspend submission tasklets around wedging · 88d3dfb6
      Chris Wilson 提交于
      After staring hard at sequences like
      
      [   28.199013]  systemd-1       2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
      [   28.199095]  systemd-1       2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1
      [   28.199177]  systemd-1       2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
      [   28.199258]  systemd-1       2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0
      [   28.199340]  gem_eio-829     1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]:  ctx=1.1, seqno=1, prio=0
      [   28.199421]   <idle>-0       2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
      [   28.199503]   <idle>-0       2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1
      [   28.199585]  gem_eio-829     1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]:  ctx=3.1, seqno=2, prio=0
      [   28.199667]  gem_eio-829     1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]:  ctx=1.2, seqno=1, prio=0
      [   28.199749]   <idle>-0       2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
      [   28.199830]   <idle>-0       2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1
      [   28.199912]   <idle>-0       2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
      [   28.199994]  gem_eio-829     2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
      [   28.200096]  gem_eio-829     2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5
      [   28.200178]  gem_eio-829     2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
      [   28.200260]  gem_eio-829     2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
      
      the conclusion is that the only place where the ports are reset to zero,
      is from engine->cancel_requests called during i915_gem_set_wedged().
      
      The race is horrible as it results from calling set-wedged on active HW
      (the GPU reset failed) and as such we need to be careful as the HW state
      changes beneath us. Fortunately, it's the same scary conditions as
      affect normal reset, so we can reuse the same machinery to disable state
      tracking as we clobber it.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Michel Thierry <michel.thierry@intel.com>
      Fixes: af7a8ffa ("drm/i915: Use rcu instead of stop_machine in set_wedged")
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-chris@chris-wilson.co.uk
      (cherry picked from commit 963ddd63)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      88d3dfb6
    • L
      drm/i915/perf: fix perf stream opening lock · f616f283
      Lionel Landwerlin 提交于
      We're seeing on CI that some contexts don't have the programmed OA
      period timer that directs the OA unit on how often to write reports.
      
      The issue is that we're not holding the drm lock from when we edit the
      context images down to when we set the exclusive_stream variable. This
      leaves a window for the deferred context allocation to call
      i915_oa_init_reg_state() that will not program the expected OA timer
      value, because we haven't set the exclusive_stream yet.
      
      v2: Drop need_lock from gen8_configure_all_contexts() (Matt)
      Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Fixes: 701f8231 ("drm/i915/perf: prune OA configs")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
      Link: https://patchwork.freedesktop.org/patch/msgid/20180301110613.1737-1-lionel.g.landwerlin@intel.com
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: <stable@vger.kernel.org> # v4.14+
      (cherry picked from commit 41d3fdcd)
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      f616f283
  4. 01 3月, 2018 14 次提交
  5. 27 2月, 2018 1 次提交
  6. 26 2月, 2018 2 次提交
  7. 23 2月, 2018 2 次提交
  8. 22 2月, 2018 1 次提交
    • I
      treewide/trivial: Remove ';;$' typo noise · ed7158ba
      Ingo Molnar 提交于
      On lkml suggestions were made to split up such trivial typo fixes into per subsystem
      patches:
      
        --- a/arch/x86/boot/compressed/eboot.c
        +++ b/arch/x86/boot/compressed/eboot.c
        @@ -439,7 +439,7 @@ setup_uga32(void **uga_handle, unsigned long size, u32 *width, u32 *height)
                struct efi_uga_draw_protocol *uga = NULL, *first_uga;
                efi_guid_t uga_proto = EFI_UGA_PROTOCOL_GUID;
                unsigned long nr_ugas;
        -       u32 *handles = (u32 *)uga_handle;;
        +       u32 *handles = (u32 *)uga_handle;
                efi_status_t status = EFI_INVALID_PARAMETER;
                int i;
      
      This patch is the result of the following script:
      
        $ sed -i 's/;;$/;/g' $(git grep -E ';;$'  | grep "\.[ch]:"  | grep -vwE 'for|ia64' | cut -d: -f1 | sort | uniq)
      
      ... followed by manual review to make sure it's all good.
      
      Splitting this up is just crazy talk, let's get over with this and just do it.
      Reported-by: NPavel Machek <pavel@ucw.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ed7158ba
  9. 21 2月, 2018 9 次提交
  10. 20 2月, 2018 6 次提交
    • N
      drm/meson: fix vsync buffer update · e88230a3
      Neil Armstrong 提交于
      The plane buffer address/stride/height was incorrectly updated in the
      plane_atomic_update operation instead of the vsync irq.
      This patch delays this operation in the vsync irq along with the
      other plane delayed setup.
      
      This issue was masked using legacy framebuffer and X11 modesetting, but
      is clearly visible using gbm rendering when buffer is submitted late after
      vblank, like using software decoding and OpenGL rendering in Kodi.
      With this patch, tearing and other artifacts disappears completely.
      
      Cc: Michal Lazo <michal.lazo@gmail.com>
      Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1518689976-23292-1-git-send-email-narmstrong@baylibre.com
      e88230a3
    • C
      drm: Handle unexpected holes in color-eviction · b8ff1802
      Chris Wilson 提交于
      During eviction, the driver may free more than one hole in the drm_mm
      due to the side-effects in evicting the scanned nodes. However,
      drm_mm_scan_color_evict() expects that the scan result is the first
      available hole (in the mru freed hole_stack list):
      
        kernel BUG at drivers/gpu/drm/drm_mm.c:844!
        invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
        Dumping ftrace buffer:
           (ftrace buffer empty)
        Modules linked in: i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core lpc_ich snd_pcm e1000e mei_me prime_numbers mei
        CPU: 1 PID: 1490 Comm: gem_userptr_bli Tainted: G     U           4.16.0-rc1-g740f57c54ecf-kasan_6+ #1
        Hardware name: Dell Inc. OptiPlex 755                 /0PU052, BIOS A08 02/19/2008
        RIP: 0010:drm_mm_scan_color_evict+0x2b8/0x3d0
        RSP: 0018:ffff880057a573f8 EFLAGS: 00010287
        RAX: ffff8800611f5980 RBX: ffff880057a575d0 RCX: dffffc0000000000
        RDX: 00000000029d5000 RSI: 1ffff1000af4aec1 RDI: ffff8800611f5a10
        RBP: ffff88005ab884d0 R08: ffff880057a57600 R09: 000000000afff000
        R10: 1ffff1000b5710b5 R11: 0000000000001000 R12: 1ffff1000af4ae82
        R13: ffff8800611f59b0 R14: ffff8800611f5980 R15: ffff880057a57608
        FS:  00007f2de0c2e8c0(0000) GS:ffff88006ac40000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007f2ddde1e000 CR3: 00000000609b2000 CR4: 00000000000006e0
        Call Trace:
         ? drm_mm_scan_remove_block+0x330/0x330
         ? drm_mm_scan_remove_block+0x151/0x330
         i915_gem_evict_something+0x711/0xbd0 [i915]
         ? igt_evict_contexts+0x50/0x50 [i915]
         ? nop_clear_range+0x10/0x10 [i915]
         ? igt_evict_something+0x90/0x90 [i915]
         ? i915_gem_gtt_reserve+0x1a1/0x320 [i915]
         i915_gem_gtt_insert+0x237/0x400 [i915]
         __i915_vma_do_pin+0xc25/0x1a20 [i915]
         eb_lookup_vmas+0x1c63/0x3790 [i915]
         ? i915_gem_check_execbuffer+0x250/0x250 [i915]
         ? trace_hardirqs_on_caller+0x33f/0x590
         ? _raw_spin_unlock_irqrestore+0x39/0x60
         ? __pm_runtime_resume+0x7d/0xf0
         i915_gem_do_execbuffer+0x86a/0x2ff0 [i915]
         ? __kmalloc+0x132/0x340
         ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915]
         ? drm_ioctl_kernel+0x12e/0x1c0
         ? drm_ioctl+0x662/0x980
         ? eb_relocate_slow+0xa90/0xa90 [i915]
         ? i915_gem_execbuffer2_ioctl+0x10f/0x760 [i915]
         ? __might_fault+0xea/0x1a0
         i915_gem_execbuffer2_ioctl+0x3cc/0x760 [i915]
         ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915]
         ? lock_acquire+0x3c0/0x3c0
         ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915]
         drm_ioctl_kernel+0x12e/0x1c0
         drm_ioctl+0x662/0x980
         ? i915_gem_execbuffer_ioctl+0xba0/0xba0 [i915]
         ? drm_getstats+0x20/0x20
         ? debug_check_no_obj_freed+0x2a6/0x8c0
         do_vfs_ioctl+0x170/0xe70
         ? ioctl_preallocate+0x170/0x170
         ? task_work_run+0xbe/0x160
         ? lock_acquire+0x3c0/0x3c0
         ? trace_hardirqs_on_caller+0x33f/0x590
         ? _raw_spin_unlock_irq+0x2f/0x50
         SyS_ioctl+0x36/0x70
         ? do_vfs_ioctl+0xe70/0xe70
         do_syscall_64+0x18c/0x5d0
         entry_SYSCALL_64_after_hwframe+0x26/0x9b
        RIP: 0033:0x7f2ddf13b587
        RSP: 002b:00007fff15c4f9d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
        RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f2ddf13b587
        RDX: 00007fff15c4fa20 RSI: 0000000040406469 RDI: 0000000000000003
        RBP: 00007fff15c4fa20 R08: 0000000000000000 R09: 00007f2ddf3fe120
        R10: 0000000000000073 R11: 0000000000000246 R12: 0000000040406469
        R13: 0000000000000003 R14: 00007fff15c4fa20 R15: 00000000000000c7
        Code: 00 00 00 4a c7 44 22 08 00 00 00 00 42 c7 44 22 10 00 00 00 00 48 81 c4 b8 00 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f 0b 0f 0b <0f> 0b 31 c0 eb c0 4c 89 ef e8 9a 09 41 ff e9 1e fe ff ff 4c 89
        RIP: drm_mm_scan_color_evict+0x2b8/0x3d0 RSP: ffff880057a573f8
      
      We can trivially relax this assumption by searching the hole_stack for
      the scan result and warn instead if the driver called us without any
      result.
      
      Fixes: 3fa489da ("drm: Apply tight eviction scanning to color_adjust")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v4.11+
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180219113543.8010-1-chris@chris-wilson.co.uk
      b8ff1802
    • S
      drm: exynos: Use proper macro definition for HDMI_I2S_PIN_SEL_1 · c84b66f8
      Sylwester Nawrocki 提交于
      Bit field [2:0] of HDMI_I2S_PIN_SEL_1 corresponds to SDATA_0,
      not SDATA_2. This patch removes redefinition of HDMI_I2S_SEL_DATA2
      constant and adds missing HDMI_I2S_SEL_DATA0.
      The value of bit field selecting SDATA_1 (pin_sel_3) is also changed,
      so it is 3 as suggested in the Exynos TRMs.
      Signed-off-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      c84b66f8
    • C
      drm/exynos: remove exynos_drm_rotator.h · b701a143
      Corentin Labbe 提交于
      Since its inclusion in 2012 via commit bea8a429 ("drm/exynos: add rotator ipp driver")
      this header is not used by any source files and is empty.
      Lets just remove it.
      Signed-off-by: NCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      b701a143
    • M
      drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions · 6f0a6029
      Markus Elfring 提交于
      Omit an extra message for a memory allocation failure in these functions.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      6f0a6029
    • W
      drm/exynos: fix comparison to bitshift when dealing with a mask · 1293b619
      Wolfram Sang 提交于
      Due to a typo, the mask was destroyed by a comparison instead of a bit
      shift.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      1293b619