1. 07 Mar, 2014 12 commits
    • Imre Deak's avatar
      drm/i915: vlv: keep first level vblank IRQs masked · 7f9e192f
      Imre Deak authored
      This is a left-over from
      
      commit b7e634cc
      Author: Imre Deak <imre.deak@intel.com>
      Date:   Tue Feb 4 21:35:45 2014 +0200
      
      drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt
      
      where we stopped unmasking the vblank IRQs, but left them enabled in the
      IER register. Disable them in IER too.
      
      v2:
      - remove comment becoming stale after this change (Ville)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7f9e192f
    • Imre Deak's avatar
      drm/i915: check pipe power domain when reading its hw state · b5482bd0
      Imre Deak authored
      We can read out the pipe HW state only if the required power domain is
      on. If not we consider the pipe to be off.
      
      v2:
      - no change
      v3:
      - push down the power domain checks into the specific crtc
        get_pipe_config handlers (Daniel)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Appease checkpatch.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b5482bd0
    • Imre Deak's avatar
      drm/i915: check port power domain when reading the encoder hw state · 6d129bea
      Imre Deak authored
      Since the encoder is tied to its port, we need to make sure the power
      domain for that port is on before reading out the encoder HW state.
      
      Note that this also covers also all connector get_hw_state handlers,
      since all those just call the corresponding encoder get_hw_state
      handler, which checks - after this change - for all power domains
      the connector needs.
      
      v2:
      - no change
      v3:
      - push down the power domain checks into the specific encoder
        get_hw_state handlers (Daniel)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6d129bea
    • Imre Deak's avatar
      drm/i915: get port power domain in connector detect handlers · 671dedd2
      Imre Deak authored
      The connector detect and get_mode handlers need to access the port
      specific HW blocks to read the EDID etc. Get/put the port power domains
      around these handlers.
      
      v2:
      - get port power domain for HDMI too (Ville)
      - get port power domain for the DP,HDMI audio detect handlers (Jesse)
      - Leave the intel_runtime_pm_get/put in the DP detect function in place.
        Instead of just removing them, these should be moved to the appropriate
        power_well enable/disable handlers. We can do this after Paulo's
        'Merge PC8 with runtime PM, v2' patchset.
      v3:
      - rebased on latest -nightly
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      671dedd2
    • Imre Deak's avatar
      drm/i915: add port power domains · 319be8ae
      Imre Deak authored
      Parts that poke port specific HW blocks like the encoder HW state
      readout or connector hotplug detect code need a way to check whether
      required power domains are on or enable/disable these. For this purpose
      add a set of power domains that refer to the port HW blocks. Get the
      proper port power domains during modeset.
      
      For now when requesting the power domain for a DDI port get it for a 4
      lane configuration. This can be optimized later to request only the 2
      lane power domain, when proper support is added on the VLV PHY side for
      this. Atm, the PHY setup code assumes a 4 lane config in all cases.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      319be8ae
    • Imre Deak's avatar
      drm/i915: add noop power well handlers instead of NULL checking them · a45f4466
      Imre Deak authored
      Reading code free of special cases wins over the small overhead of
      calling a noop handler. Suggested by Jesse.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a45f4466
    • Imre Deak's avatar
      drm/i915: split power well 'set' handler to separate enable/disable/sync_hw · c6cb582e
      Imre Deak authored
      Split the 'set' power well handler into an 'enable', 'disable' and
      'sync_hw' handler. This maps more conveniently to higher level
      operations, for example it allows us to push the hsw package c8 handling
      into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS
      hand-over setting into the hsw/bdw sync_hw handler.
      
      No functional change.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Appease checkpatch's whitespace complaints.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c6cb582e
    • Imre Deak's avatar
      drm/i915: add init power domain to always-on power wells · f5938f36
      Imre Deak authored
      Whenever we request a power domain it has to guarantee that all HW
      resources are enabled that are needed to access a HW register associated
      with that power domain. In case a register is on an always-on power well
      this won't result in turning on a power well, but it may require
      enabling some other HW resource. One such resource is the HSW/BDW device
      D0 state that is required for all register accesses and thus for all
      power wells/power domains.
      
      So far the init power domain (guaranteeing access to all HW registers)
      was part of the default i9xx always-on power well, but not the HSW/BDW
      always-on power wells. Add the domain to the latter power wells too.
      
      Atm, all the always-on power wells have noop handlers, so this doesn't
      change the functionality.
      
      v2:
      - clarify semantics of always-on power wells (Paulo)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f5938f36
    • Imre Deak's avatar
      drm/i915: move power domain macros to intel_pm.c · efcad917
      Imre Deak authored
      These macros are used only locally, so move them to the .c file.
      
      No functional change.
      
      v2:
      - add init power domain to always-on power wells in the following
        - separate - patch (Paulo)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      efcad917
    • Daniel Vetter's avatar
      drm/i915: Disable full ppgtt by default · 93a25a9e
      Daniel Vetter authored
      There are too many oustanding issues:
      
      - Fence handling in the current code is broken. There's a patch series
        from me, but it's blocked on and extended review (which includes
        writing the testcases).
      
      - IOMMU mapping handling is broken, we need to properly refcount it -
        currently it gets destroyed when the first vma is unbound, so way
        too early.
      
      - There's a pending reset issue on snb. Since Mika's reset work and
        full ppgtt have been pulled in in separate branches and ended up
        intermittingly breaking each another it's unclear who's the exact
        culprit here.
      
      - We still have persistent evidince of crazy recursion bugs through
        vma_unbind and ppgtt_relase, e.g.
      
        https://bugs.freedesktop.org/show_bug.cgi?id=73383
      
        This issue (and a few others meanwhile resolved) have blocked our
        performance measuring/tuning group since 3 months.
      
      - Secure batch dispatching is broken. This is blocking Brad Volkin's
        command checker work since 3 months.
      
      All these issues are confirmed to only happen when full ppgtt is
      enabled, falling back to aliasing ppgtt resolves them. But even
      aliasing ppgtt itself still has a regression:
      
      - We currently unconditionally bind objects into the aliasing ppgtt,
        which means all priviledged objects like ringbuffers are visible to
        unpriviledged access again. On top of that this also breaks the
        command checker for aliasing ppgtt, since it can't hide the
        validated batch any more.
      
      Furthermore topic/full-ppgtt has never been reviewed:
      
      - Lifetime rules around vma unbinding/release are unclear, resulting
        into this awesome hack called ppgtt_release. Which seems to take the
        blame for most of the recursion fallout.
      
      - Context/ring init works different on gpu reset than anywhere else.
        Such differeneces have in the past always lead to really hard to
        track down bugs.
      
      - Aliasing ppgtt is treated in a bunch of places as a real address
        space, but it isn't - the real address space is always the global
        gtt in that case. This results in a bit a mess between contexts and
        ppgtt object, further complication the context/ppgtt/vma lifetime
        rules.
      
      - We don't have any docs describing the overall concepts introduced
        with full ppgtt. A short, concise overview describing vmas and some
        of the strange bits around them (like the unbound vmas used by
        execbuf, or the new binding rules) really is needed.
      
      Note that a lot of the post topic/full-ppgtt merge fallout has already
      been addressed, this entire list here of 10 issues really only contains
      the still outstanding issues.
      
      Finally the 3.15 merge window is approaching and I think we need to
      use the remaining time to ensure that our fallback option of using
      aliasing ppgtt is in solid shape. Hence I think it's time to throw the
      switch. While at it demote the helper from static inline status
      because really.
      
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Cc: Dave Airlie <airlied@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      93a25a9e
    • Imre Deak's avatar
      drm/i915: move modeset_update_power_wells earlier · 77d22dca
      Imre Deak authored
      These functions will be needed by the valleyview specific power well
      update functionality added in an upcoming patch, so move them earlier.
      
      No functional change.
      
      v2:
      - no change
      v3:
      - rebase on latest -nightly
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      77d22dca
    • Imre Deak's avatar
      drm/i915: fold in __intel_power_well_get/put functions · 70bf407c
      Imre Deak authored
      These functions are used only by a single call site and are simple
      enough to just fold them in.
      
      Note that in later patches the parts folded in here are further
      simplified as we'll remove hsw_{disable,enable}_package_c8 and the NULL
      check of the power well enable/disable handlers. All this means that at
      the end intel_display_power_get/put() becomes more understandable as we
      don't need to jump between two functions when reading the code.
      
      No functional change.
      
      v2:
      - clarify the rational for the change (Chris)
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      70bf407c
  2. 05 Mar, 2014 28 commits