1. 14 10月, 2016 11 次提交
    • Z
      drm/i915/gvt: vGPU display virtualization · 04d348ae
      Zhi Wang 提交于
      This patch introduces the GVT-g display virtualization.
      
      It consists a collection of display MMIO handlers, like power well register
      handler, pipe register handler, plane register handler, which will emulate
      all display MMIOs behavior to support virtual mode setting sequence for
      guest.
      Signed-off-by: NBing Niu <bing.niu@intel.com>
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      04d348ae
    • Z
      drm/i915/gvt: vGPU MMIO virtualization · e39c5add
      Zhi Wang 提交于
      This patch introduces the generic vGPU MMIO emulation intercept
      framework.  The MPT modules will request GVT-g core logic to
      emulate MMIO read/write through IO emulation operations
      callback when hypervisor trapped a guest GTTMMIO read/write.
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      e39c5add
    • Z
      drm/i915/gvt: vGPU PCI configuration space virtualization · 4d60c5fd
      Zhi Wang 提交于
      This patch introduces vGPU PCI configuration space virtualization.
      
      - Adjust the trapped GPFN(Guest Page Frame Number) window of virtual GEN
      PCI BAR 0 when guest initializes PCI BAR 0 address.
      
      - Emulate OpRegion when guest touches OpRegion.
      
      - Pass-through a part of aperture to guest when guest initializes
      aperture BAR.
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      4d60c5fd
    • Z
      drm/i915/gvt: vGPU graphics memory virtualization · 2707e444
      Zhi Wang 提交于
      The vGPU graphics memory emulation framework is responsible for graphics
      memory table virtualization. Under virtualization environment, a VM will
      populate the page table entry with guest page frame number(GPFN/GFN), while
      HW needs a page table filled with MFN(Machine frame number). The
      relationship between GFN and MFN(Machine frame number) is managed by
      hypervisor, while GEN HW doesn't have such knowledge to translate a GFN.
      
      To solve this gap, shadow GGTT/PPGTT page table is introdcued.
      
      For GGTT, the GFN inside the guest GGTT page table entry will be translated
      into MFN and written into physical GTT MMIO registers when guest write
      virtual GTT MMIO registers.
      
      For PPGTT, a shadow PPGTT page table will be created and write-protected
      translated from guest PPGTT page table.  And the shadow page table root
      pointers will be written into the shadow context after a guest workload
      is shadowed.
      
      vGPU graphics memory emulation framework consists:
      
      - Per-GEN HW platform page table entry bits extract/de-extract routines.
      - GTT MMIO register emulation handlers, which will call hypercall to do
      GFN->MFN translation when guest write GTT MMIO register
      - PPGTT shadow page table routines, e.g. shadow create/destroy/out-of-sync
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      2707e444
    • Z
      drm/i915/gvt: vGPU interrupt virtualization. · c8fe6a68
      Zhi Wang 提交于
      This patch introduces vGPU interrupt emulation framework.
      
      The vGPU intrerrupt emulation framework is an event-based interrupt
      emulation framework. It's responsible for emulating GEN hardware interrupts
      during emulating other HW behaviour.
      
      It consists several components:
      
      - Descriptions of interrupt register bit
      - Upper level <-> lower level interrupt mapping
      - GEN HW IER/IMR/IIR register emulation routines
      - Event-based interrupt propagation interface
      
      When a GVT-g component wants to inject an interrupt to a VM during a
      emulation, first it should specify the event needs to be emulated and the
      framework will deal with the rest of emulation:
      
      - Generating related virtual IIR bit according to virtual IER and IMRs,
      - Generate related virtual upper level virtual IIR bit accodring to the
      per-platform interrupt mapping
      - Injecting a MSI to VM
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      c8fe6a68
    • Z
      drm/i915/gvt: trace stub · 3f728236
      Zhi Wang 提交于
      v2:
      - Make checkpatch.pl happy(Joonas)
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      3f728236
    • Z
      drm/i915/gvt: Introduce basic vGPU life cycle management · 82d375d1
      Zhi Wang 提交于
      A vGPU represents a virtual Intel GEN hardware, which consists following
      virtual resources:
      
      - Configuration space (virtualized)
      - HW registers (virtualized)
      - GGTT memory space (partitioned)
      - GPU page table (shadowed)
      - Fence registers (partitioned)
      
      * virtualized: fully emulated by GVT-g.
      * partitioned: Only a part of the HW resource is allowed to be accessed
      by VM.
      * shadowed: Resource needs to be translated and shadowed before getting
      applied into HW.
      
      This patch introduces vGPU life cycle management framework, which is
      responsible for creating/destroying a vGPU and preparing/free resources
      related to a vGPU.
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      82d375d1
    • Z
      drm/i915/gvt: golden virtual HW state management · 579cea5f
      Zhi Wang 提交于
      Each vGPU expects a golden virtual HW state, which is just the state after
      system is freshly powered on. GVT-g will try to load the golden virtual HW
      state via kernel firmware interface.
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      579cea5f
    • Z
      drm/i915/gvt: Introduce a framework for tracking HW registers. · 12d14cc4
      Zhi Wang 提交于
      This patch introduces a framework for tracking HW registers on different
      GEN platforms.
      
      Accesses to GEN HW registers from VMs will be trapped by hypervisor. It
      will forward these emulation requests to GVT-g device model, which
      requires this framework to search for related register descriptions.
      
      Each MMIO entry in this framework describes a GEN HW registers, e.g.
      offset, length, whether it contains RO bits, whether it can be accessed by
      LRIs...and also emulation handlers for emulating register reading and
      writing.
      
      - Use i915 MMIO register definition & statement.(Joonas)
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      12d14cc4
    • Z
      drm/i915/gvt: vGPU HW resource management · 28a60dee
      Zhi Wang 提交于
      This patch introduces the GVT-g vGPU HW resource management. Under
      GVT-g virtualizaion environment, each vGPU requires portions HW
      resources, including aperture, hidden GM space, and fence registers.
      
      When creating a vGPU, GVT-g will request these HW resources from host,
      and return them to host after a vGPU is destroyed.
      Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
      Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
      28a60dee
    • C
      drm/i915: Merge duplicate gen4 and vlv/chv enable vblank callbacks · 86e83e35
      Chris Wilson 提交于
      gen4/vlv/chv all use the same bits in pipestat to enable the vblank
      interrupt, so they can share the same callbacks to enable/disable.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161007194953.15616-1-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      86e83e35
  2. 13 10月, 2016 10 次提交
  3. 12 10月, 2016 13 次提交
    • C
      drm/i915: Update debugfs describe_obj() to show fault-mappable · 8baa1f04
      Chris Wilson 提交于
      The current meaning of whether an object has a GGTT vma is very
      ill-defined (and note we don't check for any partials either), it just
      means that at some point it was in the GGTT but it may not be now. The
      information we really care about here is whether it is taking up
      precious mappable aperture space. This is the obj->fault_mappable flag.
      We have a redundant long form reprinting of this information, so remove
      that in favour of the compact flag.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012114827.17031-2-chris@chris-wilson.co.uk
      8baa1f04
    • C
      drm/i915: Use fence_write() from rpm resume · 4676dc83
      Chris Wilson 提交于
      During rpm resume we restore the fences, but we do not have the
      protection of struct_mutex. This rules out updating the activity
      tracking on the fences, and requires us to rely on the rpm as the
      serialisation barrier instead.
      
      [  350.298052] [drm:intel_runtime_resume [i915]] Resuming device
      [  350.308606]
      [  350.310520] ===============================
      [  350.315560] [ INFO: suspicious RCU usage. ]
      [  350.320554] 4.8.0-rc8-bsw-rapl+ #3133 Tainted: G     U  W
      [  350.327208] -------------------------------
      [  350.331977] ../drivers/gpu/drm/i915/i915_gem_request.h:371 suspicious rcu_dereference_protected() usage!
      [  350.342619]
      [  350.342619] other info that might help us debug this:
      [  350.342619]
      [  350.351593]
      [  350.351593] rcu_scheduler_active = 1, debug_locks = 0
      [  350.358952] 3 locks held by Xorg/320:
      [  350.363077]  #0:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa030589c>] drm_modeset_lock_all+0x3c/0xd0 [drm]
      [  350.375162]  #1:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa03058a6>] drm_modeset_lock_all+0x46/0xd0 [drm]
      [  350.387022]  #2:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa0305056>] drm_modeset_lock+0x36/0x110 [drm]
      [  350.398236]
      [  350.398236] stack backtrace:
      [  350.403196] CPU: 1 PID: 320 Comm: Xorg Tainted: G     U  W       4.8.0-rc8-bsw-rapl+ #3133
      [  350.412457] Hardware name: Intel Corporation CHERRYVIEW C0 PLATFORM/Braswell CRB, BIOS BRAS.X64.X088.R00.1510270350 10/27/2015
      [  350.425212]  0000000000000000 ffff8801680a78c8 ffffffff81332187 ffff88016c5c5000
      [  350.433611]  0000000000000001 ffff8801680a78f8 ffffffff810ca6da ffff88016cc8b0f0
      [  350.442012]  ffff88016cc80000 ffff88016cc80000 ffff880177ad0000 ffff8801680a7948
      [  350.450409] Call Trace:
      [  350.453165]  [<ffffffff81332187>] dump_stack+0x67/0x90
      [  350.458931]  [<ffffffff810ca6da>] lockdep_rcu_suspicious+0xea/0x120
      [  350.466002]  [<ffffffffa039e8dd>] fence_update+0xbd/0x670 [i915]
      [  350.472766]  [<ffffffffa039efe2>] i915_gem_restore_fences+0x52/0x70 [i915]
      [  350.480496]  [<ffffffffa0368f42>] vlv_resume_prepare+0x72/0x570 [i915]
      [  350.487839]  [<ffffffffa0369802>] intel_runtime_resume+0x102/0x210 [i915]
      [  350.495442]  [<ffffffff8137f26f>] pci_pm_runtime_resume+0x7f/0xb0
      [  350.502274]  [<ffffffff8137f1f0>] ? pci_restore_standard_config+0x40/0x40
      [  350.509883]  [<ffffffff814401c5>] __rpm_callback+0x35/0x70
      [  350.516037]  [<ffffffff8137f1f0>] ? pci_restore_standard_config+0x40/0x40
      [  350.523646]  [<ffffffff81440224>] rpm_callback+0x24/0x80
      [  350.529604]  [<ffffffff8137f1f0>] ? pci_restore_standard_config+0x40/0x40
      [  350.537212]  [<ffffffff814417bd>] rpm_resume+0x4ad/0x740
      [  350.543161]  [<ffffffff81441aa1>] __pm_runtime_resume+0x51/0x80
      [  350.549824]  [<ffffffffa03889c8>] intel_runtime_pm_get+0x28/0x90 [i915]
      [  350.557265]  [<ffffffffa0388a53>] intel_display_power_get+0x23/0x50 [i915]
      [  350.565001]  [<ffffffffa03ef23d>] intel_atomic_commit_tail+0xdfd/0x10b0 [i915]
      [  350.573106]  [<ffffffffa034b2e9>] ? drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper]
      [  350.582659]  [<ffffffff81615091>] ? _raw_spin_unlock+0x31/0x50
      [  350.589205]  [<ffffffffa034b2e9>] ? drm_atomic_helper_swap_state+0x159/0x300 [drm_kms_helper]
      [  350.598787]  [<ffffffffa03ef8a5>] intel_atomic_commit+0x3b5/0x500 [i915]
      [  350.606319]  [<ffffffffa03061dc>] ? drm_atomic_set_crtc_for_connector+0xcc/0x100 [drm]
      [  350.615209]  [<ffffffffa0306b49>] drm_atomic_commit+0x49/0x50 [drm]
      [  350.622242]  [<ffffffffa034dee8>] drm_atomic_helper_set_config+0x88/0xc0 [drm_kms_helper]
      [  350.631419]  [<ffffffffa02f94ac>] drm_mode_set_config_internal+0x6c/0x120 [drm]
      [  350.639623]  [<ffffffffa02fa94c>] drm_mode_setcrtc+0x22c/0x4d0 [drm]
      [  350.646760]  [<ffffffffa02f0f19>] drm_ioctl+0x209/0x460 [drm]
      [  350.653217]  [<ffffffffa02fa720>] ? drm_mode_getcrtc+0x150/0x150 [drm]
      [  350.660536]  [<ffffffff810c984a>] ? __lock_is_held+0x4a/0x70
      [  350.666885]  [<ffffffff81202303>] do_vfs_ioctl+0x93/0x6b0
      [  350.672939]  [<ffffffff8120f843>] ? __fget+0x113/0x200
      [  350.678797]  [<ffffffff8120f735>] ? __fget+0x5/0x200
      [  350.684361]  [<ffffffff81202964>] SyS_ioctl+0x44/0x80
      [  350.690030]  [<ffffffff81001deb>] do_syscall_64+0x5b/0x120
      [  350.696184]  [<ffffffff81615ada>] entry_SYSCALL64_slow_path+0x25/0x25
      
      Note we also have to remember the lesson from commit 4fc788f5
      ("drm/i915: Flush delayed fence releases after reset") where we have to
      flush any changes to the fence on restore.
      
      v2: Replace call to release user mmaps with an assertion that they have
      already been zapped.
      
      Fixes: 49ef5294 ("drm/i915: Move fence tracking from object to vma")
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012114827.17031-1-chris@chris-wilson.co.uk
      4676dc83
    • C
      drm/i915: Compress GPU objects in error state · 0a97015d
      Chris Wilson 提交于
      Our error states are quickly growing, pinning kernel memory with them.
      The majority of the space is taken up by the error objects. These
      compress well using zlib and without decode are mostly meaningless, so
      encoding them does not hinder quickly parsing the error state for
      familiarity.
      
      v2: Make the zlib dependency optional
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-6-chris@chris-wilson.co.uk
      0a97015d
    • C
      drm/i915: Consolidate error object printing · fc4c79c3
      Chris Wilson 提交于
      Leave all the pretty printing to userspace and simplify the error
      capture to only have a single common object printer. It makes the kernel
      code more compact, and the refactoring allows us to apply more complex
      transformations like compressing the output.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-5-chris@chris-wilson.co.uk
      fc4c79c3
    • C
      drm/i915: Always use the GTT for error capture · 95374d75
      Chris Wilson 提交于
      Since the GTT provides universal access to any GPU page, we can use it
      to reduce our plethora of read methods to just one. It also has the
      important characteristic of being exactly what the GPU sees - if there
      are incoherency problems, seeing the batch as executed (rather than as
      trapped inside the cpu cache) is important.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-4-chris@chris-wilson.co.uk
      95374d75
    • C
      drm/i915: Stop the machine whilst capturing the GPU crash dump · 9f267eb8
      Chris Wilson 提交于
      The error state is purposefully racy as we expect it to be called at any
      time and so have avoided any locking whilst capturing the crash dump.
      However, with multi-engine GPUs and multiple CPUs, those races can
      manifest into OOPSes as we attempt to chase dangling pointers freed on
      other CPUs. Under discussion are lots of ways to slow down normal
      operation in order to protect the post-mortem error capture, but what it
      we take the opposite approach and freeze the machine whilst the error
      capture runs (note the GPU may still running, but as long as we don't
      process any of the results the driver's bookkeeping will be static).
      
      Note that by of itself, this is not a complete fix. It also depends on
      the compiler barriers in list_add/list_del to prevent traversing the
      lists into the void. We also depend that we only require state from
      carefully controlled sources - i.e. all the state we require for
      post-mortem debugging should be reachable from the request itself so
      that we only have to worry about retrieving the request carefully. Once
      we have the request, we know that all pointers from it are intact.
      
      v2: Avoid drm_clflush_pages() inside stop_machine() as it may use
      stop_machine() itself for its wbinvd fallback.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-3-chris@chris-wilson.co.uk
      9f267eb8
    • C
      drm/i915: Allow disabling error capture · 98a2f411
      Chris Wilson 提交于
      We currently capture the GPU state after we detect a hang. This is vital
      for us to both triage and debug hangs in the wild (post-mortem
      debugging). However, it comes at the cost of running some potentially
      dangerous code (since it has to make very few assumption about the state
      of the driver) that is quite resource intensive.
      
      This patch introduces both a method to disable error capture at runtime
      (for users who hit bugs at runtime and need a workaround) and to disable
      error capture at compiletime (for realtime users who want to minimise
      any possible latency, and never require error capture, saving ~30k of
      code). The cost is that we now have to be wary of (and test!) a kconfig
      flag and a module parameter. The effect of the module parameter is easy
      to verify through code inspection and runtime testing, but a kconfig flag
      needs regular compile checking.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-2-chris@chris-wilson.co.uk
      98a2f411
    • C
      drm/i915: Move common code out of i915_gpu_error.c · 0e704476
      Chris Wilson 提交于
      In the next patch, I want to conditionally compile i915_gpu_error.c and
      that requires moving the functions used by debug out of
      i915_gpu_error.c!
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-1-chris@chris-wilson.co.uk
      0e704476
    • J
      drm/i915: Remove unused BSM_MASK causing warning · 40006c43
      Joonas Lahtinen 提交于
      Remove never used BSM{,_MASK}. BSM_MASK #define also causes a warning.
      
      include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
      requires 37 bits to represent, but ‘int’ only has 32 bits
      [-Wshiftoverflow=]
         #define   INTEL_BSM_MASK (0xFFFF << 20)
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1476256734-6457-1-git-send-email-joonas.lahtinen@linux.intel.com
      40006c43
    • D
      Merge tag 'drm-for-v4.9' into drm-intel-next-queued · c0c8b9ed
      Daniel Vetter 提交于
      It's been over two months, git definitely lost it's marbles. Conflicts
      resolved by picking our version, plus manually checking the diff with
      the parent in drm-intel-next-queued to make sure git didn't do
      anything stupid. It did, so I removed 2 occasions where it
      double-inserted a bit of code. The diff is now just
      - kernel-doc changes
      - drm format/name changes
      - display-info changes
      so looks all reasonable.
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      c0c8b9ed
    • D
      Merge tag 'topic/drm-misc-2016-10-11' of git://anongit.freedesktop.org/drm-intel into drm-next · 69405d3d
      Dave Airlie 提交于
      Just flushing out my -misc queue. Slightly important are the prime
      refcount/unload fixes from Chris.
      
      There's also the reservation stuff from Chris still pending, and Sumits
      hasn't landed that yet. Might get another pull for that, but pls don't
      hold up the main pull for it ;-)
      
      * tag 'topic/drm-misc-2016-10-11' of git://anongit.freedesktop.org/drm-intel:
        drm/crtc: constify drm_crtc_index parameter
        drm: use the right function name in documentation
        drm: Release resources with a safer function
        drm: Fix up kerneldoc for new drm_gem_dmabuf_export()
        drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup directly
        drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS
        drm/bridge: Add RGB to VGA bridge support
        drm/prime: Take a ref on the drm_dev when exporting a dma_buf
        drm/prime: Pass the right module owner through to dma_buf_export()
        drm/bridge: Call drm_connector_cleanup directly
        drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks
        drm: Release resources with a safer function
      69405d3d
    • D
      Merge tag 'drm-intel-next-fixes-2016-10-11' of... · 28da9ed6
      Dave Airlie 提交于
      Merge tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel into drm-next
      
      A big bunch of i915 fixes for drm-next / v4.9 merge window, with more
      than half of them also cc: stable. We also continue to have more Fixes:
      annotations for our fixes, which should help the backporters and
      archeologists.
      
      * tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel: (27 commits)
        drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next
        drm/i915/guc: Unwind GuC workqueue reservation if request construction fails
        drm/i915: Reset the breadcrumbs IRQ more carefully
        drm/i915: Force relocations via cpu if we run out of idle aperture
        drm/i915: Distinguish last emitted request from last submitted request
        drm/i915: Allow DP to work w/o EDID
        drm/i915: Move long hpd handling into the hotplug work
        drm/i915/execlists: Reinitialise context image after GPU hang
        drm/i915: Use correct index for backtracking HUNG semaphores
        drm/i915: Unalias obj->phys_handle and obj->userptr
        drm/i915: Just clear the mmiodebug before a register access
        drm/i915/gen9: only add the planes actually affected by ddb changes
        drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
        drm/i915/bxt: Fix HDMI DPLL configuration
        drm/i915/gen9: fix the watermark res_blocks value
        drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
        drm/i915/gen9: minimum scanlines for Y tile is not always 4
        drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
        drm/i915/kbl: KBL also needs to run the SAGV code
        drm/i915: introduce intel_has_sagv()
        ...
      28da9ed6
    • P
      drm/i915/gen9: fix DDB partitioning for multi-screen cases · 5a920b85
      Paulo Zanoni 提交于
      With the previous code we were only recomputing the DDB partitioning
      for the CRTCs included in the atomic commit, so any other active CRTCs
      would end up having their DDB registers zeroed. In this patch we make
      sure that the computed state starts as a copy of the current
      partitioning, and then we only zero the DDBs that we're actually
      going to recompute.
      
      How to reproduce the bug:
        1 - Enable the primary plane on pipe A
        2 - Enable the primary plane on pipe B
        3 - Enable the cursor or sprite plane on pipe A
      
      Step 3 will zero the DDB partitioning for pipe B since it's not
      included in the commit that enabled the cursor or sprite for pipe A.
      
      I expect this to fix many FIFO underrun problems on gen9+.
      
      v2:
        - Mention the cursor on the steps to reproduce the problem (Paulo).
        - Add Testcase tag provided by Maarten (Maarten).
      
      Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97596
      Bugzilla: https://www.phoronix.com/scan.php?page=news_item&px=Intel-Skylake-Multi-Screen-Woes
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NLyude <cpaul@redhat.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1475602652-17326-1-git-send-email-paulo.r.zanoni@intel.com
      5a920b85
  4. 11 10月, 2016 6 次提交