1. 27 6月, 2015 2 次提交
  2. 26 6月, 2015 15 次提交
  3. 25 6月, 2015 2 次提交
  4. 24 6月, 2015 15 次提交
  5. 23 6月, 2015 6 次提交
    • A
      drm/i915: Bail out early if WA batch is not available for given Gen · 5e60d790
      Arun Siluvery 提交于
      To initialize WA batch, at the moment we first allocate batch and then check
      whether we have any WA to be initialized for the given Gen; if we don't have
      any WA then we WARN the user, destroy the batch and return but this is causing
      another WARN in cleanup code complaining about sleeping in atomic context.
      Till we understand this better and to keep things simpler, bail out early
      if we don't have WA.
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5e60d790
    • A
      drm/i915: Fix warnings reported by 0-day · 4d78c8dc
      Arun Siluvery 提交于
      Kernel 0-day framework reported warnings with WA batch patches, this patch
      fixes those warnings and an additional warning reported in intel_lrc.c file.
      Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4d78c8dc
    • J
      drm/i915: Remove the now obsolete 'i915_gem_check_olr()' · a5ac0f90
      John Harrison 提交于
      As there is no OLR to check, the check_olr() function is now a no-op and can be
      removed.
      
      For: VIZ-5115
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: NTomas Elf <tomas.elf@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a5ac0f90
    • J
      drm/i915: Update a bunch of LRC functions to take requests · ae70797d
      John Harrison 提交于
      A bunch of the low level LRC functions were passing around ringbuf and ctx
      pairs. In a few cases, they took the r/c pair and a request as well. This is all
      quite messy and unnecesary. The context_queue() call is especially bad since the
      fake request code got removed - it takes a request and three extra things that
      must be extracted from the request and then it checks them against what it finds
      in the request. Removing all the derivable data makes the code much simpler all
      round.
      
      This patch updates those functions to just take the request structure.
      
      Note that logical_ring_wait_for_space now takes a request structure but already
      had a local request pointer that it uses to scan for something to wait on. To
      avoid confusion the local variable has been renamed 'target' (it is searching
      for a target request to do something with) and the parameter has been called req
      (to guarantee anything accidentally missed gets a compiler error).
      
      v2: Updated commit message re wait_for_space (Tomas Elf review comment).
      
      For: VIZ-5115
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: NTomas Elf <tomas.elf@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ae70797d
    • J
      drm/i915: Remove 'faked' request from LRC submission · 9bb1af44
      John Harrison 提交于
      The LRC submission code requires a request for tracking purposes. It does not
      actually require that request to 'complete' it simply uses it for keeping hold
      of reference counts on contexts and such like.
      
      Previously, the fall back path of polling for space in the ring would start by
      submitting any outstanding work that was sat in the buffer. This submission was
      not done as part of the request that that work was owned by because that would
      lead to complications with the request being submitted twice. Instead, a null
      request structure was passed in to the submit call and a fake one was created.
      
      That fall back path has long since been obsoleted and has now been removed. Thus
      there is never any need to fake up a request structure. This patch removes that
      code. A couple of sanity check warnings are added as well, just in case.
      
      For: VIZ-5115
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
      Reviewed-by: NTomas Elf <tomas.elf@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9bb1af44
    • J
      drm/i915: Move the request/file and request/pid association to creation time · fcfa423c
      John Harrison 提交于
      In _i915_add_request(), the request is associated with a userland client.
      Specifically it is linked to the 'file' structure and the current user process
      is recorded. One problem here is that the current user process is not
      necessarily the same as when the request was submitted to the driver. This is
      especially true when the GPU scheduler arrives and decouples driver submission
      from hardware submission. Note also that it is only in the case where the add
      request comes from an execbuff call that there is a client to associate. Any
      other add request call is kernel only so does not need to do it.
      
      This patch moves the client association into a separate function. This is then
      called from the execbuffer code path itself at a sensible time. It also removes
      the now redundant 'file' pointer from the add request parameter list.
      
      An extra cleanup of the client association is also added to the request clean up
      code for the eventuality where the request is killed after association but
      before being submitted (e.g. due to out of memory error somewhere). Once the
      submission has happened, the request is on the request list and the regular
      request list removal will clear the association. Note that this still needs to
      happen at this point in time because the request might be kept floating around
      much longer (due to someone holding a reference count) and the client should not
      be worrying about this request after it has been retired.
      
      For: VIZ-5115
      Signed-off-by: NJohn Harrison <John.C.Harrison@Intel.com>
      Reviewed-by: NTomas Elf <tomas.elf@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fcfa423c