1. 08 Jul, 2014 5 commits
    • Oscar Mateo's avatar
      drm/i915: Emphasize that ctx->id is merely a user handle · 821d66dd
      Oscar Mateo authored
      This is an Execlists preparatory patch, since they make context ID become an
      overloaded term:
      
      - In the software, it was used to distinguish which context userspace was
        trying to use.
      - In the BSpec, the term is used to describe the 20-bits long field the
        hardware uses to it to discriminate the contexts that are submitted to
        the ELSP and inform the driver about their current status (via Context
        Switch Interrupts and Context Status Buffers).
      
      Initially, I tried to make the different meanings converge, but it proved
      impossible:
      
      - The software ctx->id is per-filp, while the hardware one needs to be
        globally unique.
      - Also, we multiplex several backing states objects per intel_context,
        and all of them need unique HW IDs.
      - I tried adding a per-filp ID and then composing the HW context ID as:
        ctx->id + file_priv->id + ring->id, but the fact that the hardware only
        uses 20-bits means we have to artificially limit the number of filps or
        contexts the userspace can create.
      
      The ctx->user_handle renaming bits are done with this Cocci patch (plus
      manual frobbing of the struct declaration):
      
          @@
          struct intel_context c;
          @@
          - (c).id
          + c.user_handle
      
          @@
          struct intel_context *c;
          @@
          - (c)->id
          + c->user_handle
      
      Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and
      change the type to unsigned 32 bits.
      
      v2: s/handle/user_handle and change the type to uint32_t as suggested by
      Chris Wilson.
      
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
      Signed-off-by: default avatarOscar Mateo <oscar.mateo@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      821d66dd
    • Oscar Mateo's avatar
      drm/i915: Emphasize that ctx->obj & ctx->is_initialized refer to the legacy rcs ctx · ea0c76f8
      Oscar Mateo authored
      We have already advanced that Logical Ring Contexts have their own kind
      of backing objects, but everything will be better explained in the Execlists
      series. For now, suffice it to say that the current backing object is only
      ever used with the render ring, so we're making this fact more explicit
      (which is a good reason on its own).
      
      As for the is_initialized flag, we only use to signify that the render state
      has been initialized (a.k.a. golden context, a.k.a. null context). It doesn't
      mean anything for the other engines, so make that distinction obvious.
      
      Done with the following Coccinelle patch (plus manual frobbing of the struct):
      
          @@
          struct intel_context c;
          @@
          - (c).obj
          + c.legacy_hw_ctx.rcs_state
      
          @@
          struct intel_context *c;
          @@
          - (c)->obj
          + c->legacy_hw_ctx.rcs_state
      
          @@
          struct intel_context c;
          @@
          - (c).is_initialized
          + c.legacy_hw_ctx.initialized
      
          @@
          struct intel_context *c;
          @@
          - (c)->is_initialized
          + c->legacy_hw_ctx.initialized
      
      This Execlists prep-work patch has been suggested by Chris Wilson and Daniel
      Vetter separately.
      
      Initially, it was two separate patches:
      drm/i915: Rename ctx->obj to ctx->rcs_state
      drm/i915: Make it obvious that ctx->id is merely a user handle
      Signed-off-by: default avatarOscar Mateo <oscar.mateo@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: s/id/is_initialized/ to fix the subject and resolve a
      conflict in i915_gem_context_reset. Also introduce a new lctx local
      variable to avoid overtly long lines.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ea0c76f8
    • Oscar Mateo's avatar
      drm/i915: Extract context backing object allocation · aa0c13da
      Oscar Mateo authored
      This is preparatory work for Execlists: we plan to use it later to
      allocate our own context objects (since Logical Ring Contexts do
      not have the same kind of backing objects).
      
      No functional changes.
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarOscar Mateo <oscar.mateo@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      aa0c13da
    • Imre Deak's avatar
      drm/i915: make system freeze support depend on CONFIG_ACPI_SLEEP · 95fa2eee
      Imre Deak authored
      To achieve further power savings during system freeze (aka connected
      standby, or s0ix) we have to send a PCI_D1 opregion notification. As
      the information about the state we're entering (system freeze,
      suspend to ram or suspend to disk) is only available through the ACPI
      subsystem, make this support depend on the relevant kconfig option.
      Things will still work if this option isn't set, albeit with less than
      optimial power saving.
      
      This also fixes a compile breakage when the option is not set introduced
      in
      
      commit e5747e3a
      Author: Jesse Barnes <jbarnes@virtuousgeek.org>
      Date:   Thu Jun 12 08:35:47 2014 -0700
      
          drm/i915: send proper opregion notifications on suspend/resume
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      95fa2eee
    • Chris Wilson's avatar
      drm/i915: Restrict GPU boost to the RCS engine · ec5cc0f9
      Chris Wilson authored
      Make the assumption that media workloads are not as latency sensitive
      for __wait_seqno, and that upclocking the GPU does not affect the BLT
      engine. Under that assumption, we only wait to forcibly upclock the GPU
      when we are stalling for results from the render pipeline.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Deepak S<deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      ec5cc0f9
  2. 07 Jul, 2014 35 commits