1. 23 Jun, 2015 21 commits
    • John Harrison's avatar
      drm/i915: Add request to execbuf params and add explicit cleanup · 6a6ae79a
      John Harrison authored
      Rather than just having a local request variable in the execbuff code, the
      request pointer is now stored in the execbuff params structure. Also added
      explicit cleanup of the request (plus wiping the OLR to match) in the error
      case. This means that the execbuff code is no longer dependent upon the OLR
      keeping track of the request so as to not leak it when things do go wrong. Note
      that in the success case, the i915_add_request() at the end of the submission
      function will tidy up the request and clear the OLR.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6a6ae79a
    • John Harrison's avatar
      drm/i915: Update alloc_request to return the allocated request · 217e46b5
      John Harrison authored
      The alloc_request() function does not actually return the newly allocated
      request. Instead, it must be pulled from ring->outstanding_lazy_request. This
      patch fixes this so that code can create a request and start using it knowing
      exactly which request it actually owns.
      
      v2: Updated for new i915_gem_request_alloc() scheme.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      217e46b5
    • John Harrison's avatar
      drm/i915: Simplify i915_gem_execbuffer_retire_commands() parameters · adeca76d
      John Harrison authored
      Shrunk the parameter list of i915_gem_execbuffer_retire_commands() to a single
      structure as everything it requires is available in the execbuff_params object.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      adeca76d
    • John Harrison's avatar
      drm/i915: Merged the many do_execbuf() parameters into a structure · 5f19e2bf
      John Harrison authored
      The do_execbuf() function takes quite a few parameters. The actual set of
      parameters is going to change with the conversion to passing requests around.
      Further, it is due to grow massively with the arrival of the GPU scheduler.
      
      This patch simplifies the prototype by passing a parameter structure instead.
      Changing the parameter set in the future is then simply a matter of
      adding/removing items to the structure.
      
      Note that the structure does not contain absolutely everything that is passed
      in. This is because the intention is to use this structure more extensively
      later in this patch series and more especially in the GPU scheduler that is
      coming soon. The latter requires hanging on to the structure as the final
      hardware submission can be delayed until long after the execbuf IOCTL has
      returned to user land. Thus it is unsafe to put anything in the structure that
      is local to the IOCTL call itself - such as the 'args' parameter. All entries
      must be copies of data or pointers to structures that are reference counted in
      some way and guaranteed to exist for the duration of the batch buffer's life.
      
      v2: Rebased to newer tree and updated for changes to the command parser.
      Specifically, a code shuffle has required saving the batch start address in the
      params structure.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5f19e2bf
    • John Harrison's avatar
      drm/i915: Set context in request from creation even in legacy mode · 40e895ce
      John Harrison authored
      In execlist mode, the context object pointer is written in to the request
      structure (and reference counted) at the point of request creation. In legacy
      mode, this only happens inside i915_add_request().
      
      This patch updates the legacy code path to match the execlist version. This
      allows all the intermediate code between request creation and request submission
      to get at the context object given only a request structure. Thus negating the
      need to pass context pointers here, there and everywhere.
      
      v2: Moved the context reference so it does not need to be undone if the
      get_seqno() fails.
      
      v3: Fixed execlist mode always hitting a warning about invalid last_contexts
      (which don't exist in execlist mode).
      
      v4: Updated for new i915_gem_request_alloc() scheme.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      40e895ce
    • John Harrison's avatar
      drm/i915: Early alloc request in execbuff · 0c8dac88
      John Harrison authored
      Start of explicit request management in the execbuffer code path. This patch
      adds a call to allocate a request structure before all the actual hardware work
      is done. Thus guaranteeing that all that work is tagged by a known request. At
      present, nothing further is done with the request, the rest comes later in the
      series.
      
      The only noticable change is that failure to get a request (e.g. due to lack of
      memory) will be caught earlier in the sequence. It now occurs right at the start
      before any un-undoable work has been done.
      
      v2: Simplified the error handling path.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0c8dac88
    • John Harrison's avatar
      drm/i915: i915_add_request must not fail · bf7dc5b7
      John Harrison authored
      The i915_add_request() function is called to keep track of work that has been
      written to the ring buffer. It adds epilogue commands to track progress (seqno
      updates and such), moves the request structure onto the right list and other
      such house keeping tasks. However, the work itself has already been written to
      the ring and will get executed whether or not the add request call succeeds. So
      no matter what goes wrong, there isn't a whole lot of point in failing the call.
      
      At the moment, this is fine(ish). If the add request does bail early on and not
      do the housekeeping, the request will still float around in the
      ring->outstanding_lazy_request field and be picked up next time. It means
      multiple pieces of work will be tagged as the same request and driver can't
      actually wait for the first piece of work until something else has been
      submitted. But it all sort of hangs together.
      
      This patch series is all about removing the OLR and guaranteeing that each piece
      of work gets its own personal request. That means that there is no more
      'hoovering up of forgotten requests'. If the request does not get tracked then
      it will be leaked. Thus the add request call _must_ not fail. The previous patch
      should have already ensured that it _will_ not fail by removing the potential
      for running out of ring space. This patch enforces the rule by actually removing
      the early exit paths and the return code.
      
      Note that if something does manage to fail and the epilogue commands don't get
      written to the ring, the driver will still hang together. The request will be
      added to the tracking lists. And as in the old case, any subsequent work will
      generate a new seqno which will suffice for marking the old one as complete.
      
      v2: Improved WARNings (Tomas Elf review request).
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: default avatarTomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      bf7dc5b7
    • John Harrison's avatar
      drm/i915: Reserve ring buffer space for i915_add_request() commands · 29b1b415
      John Harrison authored
      It is a bad idea for i915_add_request() to fail. The work will already have been
      send to the ring and will be processed, but there will not be any tracking or
      management of that work.
      
      The only way the add request call can fail is if it can't write its epilogue
      commands to the ring (cache flushing, seqno updates, interrupt signalling). The
      reasons for that are mostly down to running out of ring buffer space and the
      problems associated with trying to get some more. This patch prevents that
      situation from happening in the first place.
      
      When a request is created, it marks sufficient space as reserved for the
      epilogue commands. Thus guaranteeing that by the time the epilogue is written,
      there will be plenty of space for it. Note that a ring_begin() call is required
      to actually reserve the space (and do any potential waiting). However, that is
      not currently done at request creation time. This is because the ring_begin()
      code can allocate a request. Hence calling begin() from the request allocation
      code would lead to infinite recursion! Later patches in this series remove the
      need for begin() to do the allocate. At that point, it becomes safe for the
      allocate to call begin() and really reserve the space.
      
      Until then, there is a potential for insufficient space to be available at the
      point of calling i915_add_request(). However, that would only be in the case
      where the request was created and immediately submitted without ever calling
      ring_begin() and adding any work to that request. Which should never happen. And
      even if it does, and if that request happens to fall down the tiny window of
      opportunity for failing due to being out of ring space then does it really
      matter because the request wasn't doing anything in the first place?
      
      v2: Updated the 'reserved space too small' warning to include the offending
      sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
      re-initialisation of tracking state after a buffer wrap to keep the sanity
      checks accurate.
      
      v3: Incremented the reserved size to accommodate Ironlake (after finally
      managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
      
      v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
      
      For: VIZ-5115
      CC: Tomas Elf <tomas.elf@intel.com>
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      29b1b415
    • Daniel Vetter's avatar
      Merge remote-tracking branch 'airlied/drm-next' into HEAD · 0b076ecd
      Daniel Vetter authored
      Backmerge drm-next because the conflict between Ander's atomic fixes
      for 4.2 and Maartens future work are getting to unwielding to handle.
      
      Conflicts:
      	drivers/gpu/drm/i915/intel_display.c
      	drivers/gpu/drm/i915/intel_ringbuffer.h
      
      Just always take ours, same as git merge -X ours, but done by hand
      because I didn't trust git: It's confusing that it doesn't show any
      conflicts in the merge diff at all.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      0b076ecd
    • Arun Siluvery's avatar
      drm/i915/gen8: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround · c82435bb
      Arun Siluvery authored
      In Indirect context w/a batch buffer,
      +WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
      
      v2: Add LRI commands to set/reset bit that invalidates coherent lines,
      update WA to include programming restrictions and exclude CHV as
      it is not required (Ville)
      
      v3: Avoid unnecessary read when it can be done by reading register once (Chris).
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
      Signed-off-by: default avatarArun Siluvery <arun.siluvery@linux.intel.com>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c82435bb
    • Arun Siluvery's avatar
      drm/i915/gen8: Add WaDisableCtxRestoreArbitration workaround · 7ad00d1a
      Arun Siluvery authored
      In Indirect and Per context w/a batch buffer,
      +WaDisableCtxRestoreArbitration
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
      Signed-off-by: default avatarArun Siluvery <arun.siluvery@linux.intel.com>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7ad00d1a
    • Arun Siluvery's avatar
      drm/i915/gen8: Re-order init pipe_control in lrc mode · c4db7599
      Arun Siluvery authored
      Some of the WA applied using WA batch buffers perform writes to scratch page.
      In the current flow WA are initialized before scratch obj is allocated.
      This patch reorders intel_init_pipe_control() to have a valid scratch obj
      before we initialize WA.
      
      v2: Check for valid scratch page before initializing WA as some of them
      perform writes to it.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: default avatarMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: default avatarArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c4db7599
    • Arun Siluvery's avatar
      drm/i915/gen8: Add infrastructure to initialize WA batch buffers · 17ee950d
      Arun Siluvery authored
      Some of the WA are to be applied during context save but before restore and
      some at the end of context save/restore but before executing the instructions
      in the ring, WA batch buffers are created for this purpose and these WA cannot
      be applied using normal means. Each context has two registers to load the
      offsets of these batch buffers. If they are non-zero, HW understands that it
      need to execute these batches.
      
      v1: In this version two separate ring_buffer objects were used to load WA
      instructions for indirect and per context batch buffers and they were part
      of every context.
      
      v2: Chris suggested to include additional page in context and use it to load
      these WA instead of creating separate objects. This will simplify lot of things
      as we need not explicity pin/unpin them. Thomas Daniel further pointed that GuC
      is planning to use a similar setup to share data between GuC and driver and
      WA batch buffers can probably share that page. However after discussions with
      Dave who is implementing GuC changes, he suggested to use an independent page
      for the reasons - GuC area might grow and these WA are initialized only once and
      are not changed afterwards so we can share them share across all contexts.
      
      The page is updated with WA during render ring init. This has an advantage of
      not adding more special cases to default_context.
      
      We don't know upfront the number of WA we will applying using these batch buffers.
      For this reason the size was fixed earlier but it is not a good idea. To fix this,
      the functions that load instructions are modified to report the no of commands
      inserted and the size is now calculated after the batch is updated. A macro is
      introduced to add commands to these batch buffers which also checks for overflow
      and returns error.
      We have a full page dedicated for these WA so that should be sufficient for
      good number of WA, anything more means we have major issues.
      The list for Gen8 is small, same for Gen9 also, maybe few more gets added
      going forward but not close to filling entire page. Chris suggested a two-pass
      approach but we agreed to go with single page setup as it is a one-off routine
      and simpler code wins.
      
      One additional option is offset field which is helpful if we would like to
      have multiple batches at different offsets within the page and select them
      based on some criteria. This is not a requirement at this point but could
      help in future (Dave).
      
      Chris provided some helpful macros and suggestions which further simplified
      the code, they will also help in reducing code duplication when WA for
      other Gen are added. Add detailed comments explaining restrictions.
      Use do {} while(0) for wa_ctx_emit() macro.
      
      (Many thanks to Chris, Dave and Thomas for their reviews and inputs)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Signed-off-by: default avatarRafael Barbalho <rafael.barbalho@intel.com>
      Signed-off-by: default avatarArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      17ee950d
    • Chris Wilson's avatar
      drm/i915: Report an error when i915.reset prevents a reset · b1330fbb
      Chris Wilson authored
      If the user disables the GPU reset using the i915.reset parameter and
      one occurs, report that we failed to reset the GPU. If we return early,
      as we currently do, then we leave all state intact (with a hung GPU)
      and clients block forever waiting for their requests to complete.
      
      Testcase: igt/gem_eio
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Mark i915.reset as an unsafe modoption, as discussed with
      Chris.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b1330fbb
    • Daniel Vetter's avatar
      drm/i915: Fix up KMS Kconfig removal patch · bf13af56
      Daniel Vetter authored
      The module pciid list got lost, but somehow most distros seem to
      force-load drm drivers early and no one noticed for a while.
      
      Bug introduced in
      
      commit fd930478
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jun 19 20:27:27 2015 +0100
      
          drm/i915: Remove KMS Kconfig option
      Reported-by: default avatarTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      bf13af56
    • Dave Airlie's avatar
      drm/dp/mst: take lock around looking up the branch device on hpd irq · 9eb1e57f
      Dave Airlie authored
      If we are doing an MST transaction and we've gotten HPD and we
      lookup the device from the incoming msg, we should take the mgr
      lock around it, so that mst_primary and mstb->ports are valid.
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      9eb1e57f
    • Daniel Vetter's avatar
      drm/dp/mst: make sure mst_primary mstb is valid in work function · 9254ec49
      Daniel Vetter authored
      This validates the mst_primary under the lock, and then calls
      into the check and send function. This makes the code a lot
      easier to understand the locking rules in.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      9254ec49
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-fixes-2015-06-22' of... · ce8e3942
      Dave Airlie authored
      Merge tag 'drm-intel-next-fixes-2015-06-22' of git://anongit.freedesktop.org/drm-intel into drm-next
      
      fix warning introduced in last -fixes
      * tag 'drm-intel-next-fixes-2015-06-22' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: Silence compiler warning
      ce8e3942
    • Dave Airlie's avatar
      of: add EXPORT_SYMBOL for of_graph_get_endpoint_by_regs · 8ffaa903
      Dave Airlie authored
      This symbol came via exynos-next, but modular builds are broken
      so just fix it up now.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      8ffaa903
    • Dave Airlie's avatar
      Merge branch 'exynos-drm-next' of... · 75c73861
      Dave Airlie authored
      Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
      
      Summary:
      . Add atomic feature support
        - Exynos also now supports atomic feature. However, it doesn't
          guarantee atomic operation yet, and is required for more cleanups.
          This time we just modified for Exynos drm driver to use atomic
          interfaces instead of legacy ones. Next time, we will enhance
          Exynos drm driver to support the atomic operation.
      . Add iommu support
        - This is a patch series according to below Exynos iommu integration
          work with DT and dma-mapping subsystem,
          http://lwn.net/Articles/607626/
      . Consolidate Exynos drm driver initialization.
        - This patch sereis resolves the issue that only the first compoments
          was bound when happened deferred probing for other pipelines and
          also makes the driver to be more cleanned up by moving the dispered
          codes for registering kms drivers to one place.
      . Add new MIC, DECON drivers, and MIPI-DSI support for Exynos5433.
        - Add MIC(Mobile image compressor) driver. MIC is a new IP for Exynos5433
          and later, which is used to transfer frame data to MIPI-DSI controller
          compressing the data to reduce memory bandwidth.
        - Add DECON driver for Exynos5433 SoC. This IP is a dislay controller
          similar to Exynos7's one but this controller has much different registers
          from Exynos7's ones so this driver has been implemented separately.
          We will implement a helper modules for FIMD and two DECON controllers
          to remove duplicated codes later.
        - Add Exynos5433 SoC support to MIPI-DSI driver, and device tree
          relevant patches.
      
      * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (50 commits)
        ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'
        drm/exynos: dsi: do not set TE GPIO direction by input
        drm/exynos: dsi: add support for MIC driver as a bridge
        drm/exynos: dsi: add support for Exynos5433
        drm/exynos: dsi: make use of array for clock access
        drm/exynos: dsi: make use of driver data for static values
        drm/exynos: dsi: add macros for register access
        drm/exynos: dsi: rename pll_clk to sclk_clk
        drm/exynos: mic: add MIC driver
        of: add helper for getting endpoint node of specific identifiers
        drm/exynos: add Exynos5433 decon driver
        drm/exynos: fix the input prompt of Exynos7 DECON
        drm/exynos: add drm_iommu_attach_device_if_possible()
        drm/exynos: Add the dependency for DRM_EXYNOS to DPI/DSI/DP
        drm/exynos: remove the dependency of DP driver for ARCH_EXYNOS
        drm/exynos: do not wait for vblank at atomic operation
        drm/exynos: Remove unused vma field of exynos_drm_gem_obj
        drm/exynos: fimd: fix page fault issue with iommu
        drm/exynos: iommu: improve a check for non-iommu dma_ops
        drm/exynos: iommu: detach from default dma-mapping domain on init
        ...
      75c73861
    • Dave Airlie's avatar
      Merge tag 'topic/drm-misc-2015-06-22' of git://anongit.freedesktop.org/drm-intel into drm-next · b7ddeee5
      Dave Airlie authored
      One more drm-misc pull for 4.2. The important one is the fix from Laurent
      for Daniel Stone's mode_blob work.
      
      * tag 'topic/drm-misc-2015-06-22' of git://anongit.freedesktop.org/drm-intel:
        drm/atomic: Don't set crtc_state->enable manually
        drm: prime: Document gem_prime_mmap
        drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range()
        drm/atomic: Extract needs_modeset function
        drm/cma: Fix 64-bit size_t build warnings
        Documentation/drm: Update rotation property
      b7ddeee5
  2. 22 Jun, 2015 19 commits