1. 15 8月, 2016 29 次提交
  2. 12 8月, 2016 8 次提交
  3. 11 8月, 2016 3 次提交
    • G
      nvme: Suspend all queues before deletion · c21377f8
      Gabriel Krisman Bertazi 提交于
      When nvme_delete_queue fails in the first pass of the
      nvme_disable_io_queues() loop, we return early, failing to suspend all
      of the IO queues.  Later, on the nvme_pci_disable path, this causes us
      to disable MSI without actually having freed all the IRQs, which
      triggers the BUG_ON in free_msi_irqs(), as show below.
      
      This patch refactors nvme_disable_io_queues to suspend all queues before
      start submitting delete queue commands.  This way, we ensure that we
      have at least returned every IRQ before continuing with the removal
      path.
      
      [  487.529200] kernel BUG at ../drivers/pci/msi.c:368!
      cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650]
          pc: c000000000627a50: free_msi_irqs+0x90/0x200
          lr: c000000000627a40: free_msi_irqs+0x80/0x200
          sp: c0000078c5b838d0
         msr: 9000000100029033
        current = 0xc0000078c5b40000
        paca    = 0xc000000002bd7600   softe: 0        irq_happened: 0x01
          pid   = 1376, comm = kworker/70:1H
      kernel BUG at ../drivers/pci/msi.c:368!
      Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413
      (Ubuntu/IBM 5.3.1-14ubuntu2.1) ) #104 SMP Fri Jul 29 09:20:17 CDT 2016
      enter ? for help
      [c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme]
      [c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme]
      [c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110
      [c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170
      [c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110
      [c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0
      [c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590
      [c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660
      [c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130
      [c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c
      Signed-off-by: NGabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
      Cc: Brian King <brking@linux.vnet.ibm.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: linux-nvme@lists.infradead.org
      Signed-off-by: NJens Axboe <axboe@fb.com>
      c21377f8
    • V
      drm/i915: Deal with NV12 CbCr plane AUX surface on SKL+ · 8d970654
      Ville Syrjälä 提交于
      With NV12 we have two color planes to deal with so we must compute the
      surface and x/y offsets for the second plane as well.
      
      What makes this a bit nasty is that the hardware expects the surface
      offset to be specified as a distance from the main surface offset.
      What's worse, the distance must be non-negative (no neat wraparound or
      anything). So we must make sure that the main surface offset is always
      less or equal to the AUX surface offset. We do that by computing the AUX
      offset first and the main surface offset second. If the main surface
      offset ends up being above the AUX offset, we just push it down as far
      as is required while still maintaining the required alignment etc.
      
      Fortunately the AUX offset only reuqires 4K alignment, so we don't need
      to do any of the backwards searching for an acceptable offset that we
      must do for the main surface. And X tiled + NV12 isn't a supported
      combination anyway.
      
      Note that this just computes aux surface offsets, we do not yet program
      them into the actual hardware registers, and hence we can't yet expose
      NV12.
      
      v2: Rebase due to drm_plane_state src/dst rects
          s/TODO.../something else/ in the commit message/ (Daniel)
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1470821001-25272-12-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8d970654
    • V
      drm/i915: Compute display surface offset in the plane check hook for SKL+ · b63a16f6
      Ville Syrjälä 提交于
      SKL has nasty limitations with the display surface offsets:
      * source x offset + width must be less than the stride for X tiled
        surfaces or the display engine falls over
      * the surface offset requires lots of alignment (256K or 1M)
      
      These facts mean that we can't just pick any suitably aligned tile
      boundary as the offset and expect the resulting x offset to be useable.
      The solution is to start with the closest boundary as before, but then
      keep searching backwards until we find one that works, or don't. This
      means we must be prepared to fail, hence the whole surface offset
      calculation needs to be moved to the .check_plane() hook from the
      .update_plane() hook.
      
      While at it we can check that the source width/height don't exceed
      maximum plane size limits.
      
      We'll store the results of the computation in the plane state to make
      it easy for the .update_plane() hook to do its thing.
      
      v2: Replace for+break loop with while loop
          Rebase due to drm_plane_state src/dst rects
          Rebase due to plane_check_state()
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1470821001-25272-11-git-send-email-ville.syrjala@linux.intel.com
      b63a16f6