1. 23 Jun, 2015 32 commits
    • John Harrison's avatar
      drm/i915: Update i915_switch_context() to take a request structure · ba01cc93
      John Harrison authored
      Now that the request is guaranteed to specify the context, it is possible to
      update the context switch code to use requests rather than ring and context
      pairs. This patch updates i915_switch_context() accordingly.
      
      Also removed the warning that the request's context must match the last context
      switch's context. As the context switch now gets the context object from the
      request structure, there is no longer any scope for the two to become out of
      step.
      
      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>
      ba01cc93
    • John Harrison's avatar
      drm/i915: Update ppgtt_init_ring() & context_enable() to take requests · b3dd6b96
      John Harrison authored
      The final step in removing the OLR from i915_gem_init_hw() is to pass the newly
      allocated request structure in to each step rather than passing a ring
      structure. This patch updates both i915_ppgtt_init_ring() and
      i915_gem_context_enable() to take request pointers.
      
      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>
      b3dd6b96
    • John Harrison's avatar
      drm/i915: Add explicit request management to i915_gem_init_hw() · dc4be607
      John Harrison authored
      Now that a single per ring loop is being done for all the different
      intialisation steps in i915_gem_init_hw(), it is possible to add proper request
      management as well. The last remaining issue is that the context enable call
      eventually ends up within *_render_state_init() and this does its own private
      _i915_add_request() call.
      
      This patch adds explicit request creation and submission to the top level loop
      and removes the add_request() from deep within the sub-functions.
      
      v2: Updated for removal of batch_obj from add_request call in previous patch.
      
      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>
      dc4be607
    • John Harrison's avatar
      drm/i915: Don't tag kernel batches as user batches · a3fbe05a
      John Harrison authored
      The render state initialisation code does an explicit i915_add_request() call to
      commit the init commands. It was passing in the initialisation batch buffer to
      add_request() as the batch object parameter. However, the batch object entry in
      the request structure (which is all that parameter is used for) is meant for
      keeping track of user generated batch buffers for blame tagging during GPU
      hangs.
      
      This patch clears the batch object parameter so that kernel generated batch
      buffers are not tagged as being user generated.
      
      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>
      a3fbe05a
    • John Harrison's avatar
      drm/i915: Moved the for_each_ring loop outside of i915_gem_context_enable() · 90638cc1
      John Harrison authored
      The start of day context initialisation code in i915_gem_context_enable() loops
      over each ring and calls the legacy switch context or the execlist init context
      code as appropriate.
      
      This patch moves the ring looping out of that function in to the top level
      caller i915_gem_init_hw(). This means the a single pass can be made over all
      rings doing the PPGTT, L3 remap and context initialisation of each ring
      altogether.
      
      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>
      90638cc1
    • John Harrison's avatar
      drm/i915: Split i915_ppgtt_init_hw() in half - generic and per ring · 4ad2fd88
      John Harrison authored
      The i915_gem_init_hw() function calls a bunch of smaller initialisation
      functions. Multiple of which have generic sections and per ring sections. This
      means multiple passes are done over the rings. Each pass writes data to the ring
      which floats around in that ring's OLR until some random point in the future
      when an add_request() is done by some random other piece of code.
      
      This patch breaks i915_ppgtt_init_hw() in two with the per ring initialisation
      now being done in i915_ppgtt_init_ring(). The ring looping is now done at the
      top level in i915_gem_init_hw().
      
      v2: Fix dumb loop variable re-use.
      
      For: VIZ-5115
      Signed-off-by: default avatarJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: Tomas Elf <tomas.elf@intel.com> (v1)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4ad2fd88
    • John Harrison's avatar
      drm/i915: Update i915_gpu_idle() to manage its own request · 73cfa865
      John Harrison authored
      Added explicit request creation and submission to the GPU idle code 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>
      73cfa865
    • John Harrison's avatar
      drm/i915: Add flag to i915_add_request() to skip the cache flush · 5b4a60c2
      John Harrison authored
      In order to explcitly track all GPU work (and completely remove the outstanding
      lazy request), it is necessary to add extra i915_add_request() calls to various
      places. Some of these do not need the implicit cache flush done as part of the
      standard batch buffer submission process.
      
      This patch adds a flag to _add_request() to specify whether the flush is
      required or not.
      
      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>
      5b4a60c2
    • John Harrison's avatar
      drm/i915: Update execbuffer_move_to_active() to take a request structure · 8a8edb59
      John Harrison authored
      The plan is to pass requests around as the basic submission tracking structure
      rather than rings and contexts. This patch updates the
      execbuffer_move_to_active() code 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>
      8a8edb59
    • John Harrison's avatar
      drm/i915: Update move_to_gpu() to take a request structure · 535fbe82
      John Harrison authored
      The plan is to pass requests around as the basic submission tracking structure
      rather than rings and contexts. This patch updates the move_to_gpu() code paths.
      
      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>
      535fbe82
    • John Harrison's avatar
      drm/i915: Update the dispatch tracepoint to use params->request · 95c24161
      John Harrison authored
      Updated a couple of trace points to use the now cached request pointer rather
      than extracting it from the ring.
      
      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>
      95c24161
    • 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 8 commits