1. 08 12月, 2015 5 次提交
  2. 24 11月, 2015 2 次提交
  3. 16 10月, 2015 4 次提交
  4. 07 10月, 2015 1 次提交
  5. 30 9月, 2015 2 次提交
    • D
      drm/drm_ioctl.c: kerneldoc · 0aaf20cf
      Daniel Vetter 提交于
      As usual pull it into the drm docbook template, too. And again as
      usual I've decided to only document stuff exported to drivers, so all
      the old leftover markup from the shared drm repo days lost the magic
      ** signature.
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      0aaf20cf
    • D
      drm/doc: Update docs about device instance setup · 6e3f797c
      Daniel Vetter 提交于
      ->load is deprecated, bus functions are deprecated and everyone
      should use drm_dev_alloc&register.
      
      So update the .tmpl (and pull a bunch of the overview docs into the
      sourcecode to increase chances that it'll stay in sync in the future)
      and add notes to functions which are deprecated. I didn't bother to
      clean up and document the unload sequence similarly since that one is
      still a bit a mess: drm_dev_unregister does way too much,
      drm_unplug_dev does what _unregister should be doing but then has the
      complication of promising something it doesn't actually do (it doesn't
      unplug existing open fds for instance, only prevents new ones).
      
      Motivated since I don't want to hunt every new driver for usage of
      drm_platform_init any more ;-)
      
      v2: Reword the deprecation note for ->load a bit, using Laurent's
      suggestion as an example (but making the wording a bit stronger even).
      Fix spelling in commit message.
      
      v3: More spelling fixes from Laurent.
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Acked-by: David Herrmann <dh.herrmann@gmail.com> (v2)
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6e3f797c
  6. 25 9月, 2015 1 次提交
  7. 25 8月, 2015 1 次提交
  8. 15 8月, 2015 1 次提交
    • A
      drm/i915: Integrate GuC-based command submission · d1675198
      Alex Dai 提交于
      GuC-based submission is mostly the same as execlist mode, up to
      intel_logical_ring_advance_and_submit(), where the context being
      dispatched would be added to the execlist queue; at this point
      we submit the context to the GuC backend instead.
      
      There are, however, a few other changes also required, notably:
      1.  Contexts must be pinned at GGTT addresses accessible by the GuC
          i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
          PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
      
      2.  The GuC's TLB must be invalidated after a context is pinned at
          a new GGTT address.
      
      3.  GuC firmware uses the one page before Ring Context as shared data.
          Therefore, whenever driver wants to get base address of LRC, we
          will offset one page for it. LRC_PPHWSP_PN is defined as the page
          number of LRCA.
      
      4.  In the work queue used to pass requests to the GuC, the GuC
          firmware requires the ring-tail-offset to be represented as an
          11-bit value, expressed in QWords. Therefore, the ringbuffer
          size must be reduced to the representable range (4 pages).
      
      v2:
          Defer adding #defines until needed [Chris Wilson]
          Rationalise type declarations [Chris Wilson]
      
      v4:
          Squashed kerneldoc patch into here [Daniel Vetter]
      
      v5:
          Update request->tail in code common to both GuC and execlist modes.
          Add a private version of lr_context_update(), as sharing the
              execlist version leads to race conditions when the CPU and
              the GuC both update TAIL in the context image.
          Conversion of error-captured HWS page to string must account
              for offset from start of object to actual HWS (LRC_PPHWSP_PN).
      
      Issue: VIZ-4884
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d1675198
  9. 27 7月, 2015 3 次提交
  10. 10 7月, 2015 1 次提交
  11. 08 7月, 2015 1 次提交
  12. 06 7月, 2015 1 次提交
  13. 15 6月, 2015 1 次提交
  14. 21 5月, 2015 1 次提交
  15. 20 5月, 2015 1 次提交
  16. 16 4月, 2015 1 次提交
  17. 20 3月, 2015 2 次提交
  18. 24 2月, 2015 1 次提交
  19. 14 2月, 2015 1 次提交
    • Y
      drm/i915: Introduce a PV INFO page structure for Intel GVT-g. · cf9d2890
      Yu Zhang 提交于
      Introduce a PV INFO structure, to facilitate the Intel GVT-g
      technology, which is a GPU virtualization solution with mediated
      pass-through. This page contains the shared information between
      i915 driver and the host emulator. For now, this structure utilizes
      an area of 4K bytes on HSW GPU's unused MMIO space. Future hardware
      will have the reserved window architecturally defined, and layout
      of the page will be added in future BSpec.
      
      The i915 driver load routine detects if it is running in a VM by
      reading the contents of this PV INFO page. Thereafter a flag,
      vgpu.active is set, and intel_vgpu_active() is used by checking
      this flag to conclude if GPU is virtualized with Intel GVT-g. By
      now, intel_vgpu_active() will return true, only when the driver
      is running as a guest in the Intel GVT-g enhanced environment on
      HSW platform.
      
      v2:
      take Chris' comments:
              - call the i915_check_vgpu() in intel_uncore_init()
              - sanitize i915_check_vgpu() by adding BUILD_BUG_ON() and debug info
      take Daniel's comments:
              - put the definition of PV INFO into a new header - i915_vgt_if.h
      other changes:
              - access mmio regs by readq/readw in i915_check_vgpu()
      
      v3:
      take Daniel's comments:
              - move the i915/vgt interfaces into a new i915_vgpu.c
              - update makefile
              - add kerneldoc to functions which are non-static
              - add a DOC: section describing some of the high-level design
              - update drm docbook
      other changes:
              - rename i915_vgt_if.h to i915_vgpu.h
      
      v4:
      take Tvrtko's comments:
              - fix a typo in commit message
              - add debug message when vgt version mismatches
              - rename low_gmadr/high_gmadr to mappable/non-mappable in PV INFO
                structure
      Signed-off-by: NYu Zhang <yu.c.zhang@linux.intel.com>
      Signed-off-by: NJike Song <jike.song@intel.com>
      Signed-off-by: NEddie Dong <eddie.dong@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      cf9d2890
  20. 30 1月, 2015 1 次提交
  21. 13 1月, 2015 1 次提交
    • M
      drm/i915: Move to atomic plane helpers (v9) · ea2c67bb
      Matt Roper 提交于
      Switch plane handling to use the atomic plane helpers.  This means that
      rather than provide our own implementations of .update_plane() and
      .disable_plane(), we expose the lower-level check/prepare/commit/cleanup
      entrypoints and let the DRM core implement update/disable for us using
      those entrypoints.
      
      The other main change that falls out of this patch is that our
      drm_plane's will now always have a valid plane->state that contains the
      relevant plane state (initial state is allocated at plane creation).
      The base drm_plane_state pointed to holds the requested source/dest
      coordinates, and the subclassed intel_plane_state holds the adjusted
      values that our driver actually uses.
      
      v2:
       - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel)
       - Fix a copy/paste comment mistake (Bob)
      
      v3:
       - Use prepare/cleanup functions that we've already factored out
       - Use newly refactored pre_commit/commit/post_commit to avoid sleeping
         during vblank evasion
      
      v4:
       - Rebase to latest di-nightly requires adding an 'old_state' parameter
         to atomic_update;
      
      v5:
       - Must have botched a rebase somewhere and lost some work.  Restore
         state 'dirty' flag to let begin/end code know which planes to
         run the pre_commit/post_commit hooks for.  This would have actually
         shown up as broken in the next commit rather than this one.
      
      v6:
       - Squash kerneldoc patch into this one.
       - Previous patches have now already taken care of most of the
         infrastructure that used to be in this patch.  All we're adding here
         now is some thin wrappers.
      
      v7:
       - Check return of intel_plane_duplicate_state() for allocation
         failures.
      
      v8:
       - Drop unused drm_plane_state -> intel_plane_state cast.  (Ander)
       - Squash in actual transition to plane helpers.  Significant
         refactoring earlier in the patchset has made the combined
         prep+transition much easier to swallow than it was in earlier
         iterations. (Ander)
      
      v9:
       - s/track_fbs/disabled_planes/ in the atomic crtc flags.  The only fb's
         we need to update frontbuffer tracking for are those on a plane about
         to be disabled (since the atomic helpers never call prepare_fb() when
         disabling a plane), so the new name more accurately describes what
         we're actually tracking.
      
      Testcase: igt/kms_plane
      Testcase: igt/kms_universal_plane
      Testcase: igt/kms_cursor_crc
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ea2c67bb
  22. 06 1月, 2015 1 次提交
  23. 05 1月, 2015 3 次提交
  24. 18 12月, 2014 1 次提交
  25. 17 12月, 2014 1 次提交
  26. 16 12月, 2014 1 次提交
    • B
      drm/i915: Implement a framework for batch buffer pools · 493018dc
      Brad Volkin 提交于
      This adds a small module for managing a pool of batch buffers.
      The only current use case is for the command parser, as described
      in the kerneldoc in the patch. The code is simple, but separating
      it out makes it easier to change the underlying algorithms and to
      extend to future use cases should they arise.
      
      The interface is simple: init to create an empty pool, fini to
      clean it up, get to obtain a new buffer. Note that all buffers are
      expected to be inactive before cleaning up the pool.
      
      Locking is currently based on the caller holding the struct_mutex.
      We already do that in the places where we will use the batch pool
      for the command parser.
      
      v2:
      - s/BUG_ON/WARN_ON/ for locking assertions
      - Remove the cap on pool size
      - Switch from alloc/free to init/fini
      
      v3:
      - Idiomatic looping structure in _fini
      - Correct handling of purged objects
      - Don't return a buffer that's too much larger than needed
      
      v4:
      - Rebased to latest -nightly
      
      v5:
      - Remove _put() function and clean up comments to match
      
      v6:
      - Move purged check inside the loop (danvet, from v4 1/7 feedback)
      
      v7:
      - Use single list instead of two. (Chris W)
      - s/active_list/cache_list
      - Squashed in debug patches (Chris W)
        drm/i915: Add a batch pool debugfs file
      
        It provides some useful information about the buffers in
        the global command parser batch pool.
      
        v2: rebase on global pool instead of per-ring pools
        v3: rebase
      
        drm/i915: Add batch pool details to i915_gem_objects debugfs
      
        To better account for the potentially large memory consumption
        of the batch pool.
      
      v8:
      - Keep cache in LRU order (danvet, from v6 1/5 feedback)
      
      Issue: VIZ-4719
      Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-By: NJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      493018dc