1. 10 Mar, 2014 4 commits
  2. 08 Mar, 2014 5 commits
    • Jesse Barnes's avatar
      drm/i915: remove early fb allocation dependency on CONFIG_FB v2 · 484b41dd
      Jesse Barnes authored
      By stuffing the fb allocation into the crtc, we get mode set lifetime
      refcounting for free, but have to handle the initial pin & fence
      slightly differently.  It also means we can move the shared fb handling
      into the core rather than leaving it out in the fbdev code.
      
      v2: null out crtc->fb on error (Daniel)
          take fbdev fb ref and remove unused error path (Daniel)
      Requested-by: default avatarDaniel Vetter <daniel@ffwll.ch>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      484b41dd
    • Jesse Barnes's avatar
      drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12 · d978ef14
      Jesse Barnes authored
      Retrieve current framebuffer config info from the regs and create an fb
      object for the buffer the BIOS or boot loader left us.  This should
      allow for smooth transitions to userspace apps once we finish the
      initial configuration construction.
      
      v2: check for non-native modes and adjust (Jesse)
          fixup aperture and cmap frees (Imre)
          use unlocked unref if init_bios fails (Jesse)
          fix curly brace around DSPADDR check (Imre)
          comment failure path for pin_and_fence (Imre)
      v3: fixup fixup of aperture frees (Chris)
      v4: update to current bits (locking & pin_and_fence hack) (Jesse)
      v5: move fb config fetch to display code (Jesse)
          re-order hw state readout on initial load to suit fb inherit (Jesse)
          re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
      v6: rename to plane_config (Daniel)
          check for valid object when initializing BIOS fb (Jesse)
          split from plane_config readout and other display changes (Jesse)
          drop use_bios_fb option (Chris)
          update comments (Jesse)
          rework fbdev_init_bios for clarity (Jesse)
          drop fb obj ref under lock (Chris)
      v7: use fb object from plane_config instead (Ville)
          take ref on fb object (Jesse)
      v8: put under i915_fastboot option (Jesse)
          fix fb ptr checking (Jesse)
          inform drm_fb_helper if we fail to enable a connector (Jesse)
          drop unnecessary enabled[] modifications in failure cases (Chris)
          split from BIOS connector config readout (Daniel)
          don't memset the fb buffer if preallocated (Chris)
          alloc ifbdev up front and pass to init_bios (Chris)
          check for bad ifbdev in restore_mode too (Chris)
      v9: fix up !fastboot bpp setting (Jesse)
          fix up !fastboot helper alloc (Jesse)
          make sure BIOS fb is sufficient for biggest active pipe (Jesse)
      v10:fix up size calculation for proposed fbs (Chris)
          go back to two pass pipe fb assignment (Chris)
          add warning for active pipes w/o fbs (Chris)
          clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris)
          move i915.fastboot into fbdev_init (Chris)
      v11:make BIOS connector config usage unconditional (Daniel)
      v12:fix up fb vs pipe size checking (Chris)
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d978ef14
    • Jesse Barnes's avatar
      drm/i915: get_plane_config support for ILK+ v3 · 4c6baa59
      Jesse Barnes authored
      This should allow BIOS fb inheritance to work on ILK+ machines too.
      
      v2: handle tiled BIOS fbs (Kristian)
          split out common bits (Jesse)
      v3: alloc fb obj out in _init
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4c6baa59
    • Jesse Barnes's avatar
      drm/i915: get_plane_config for i9xx v13 · 1ad292b5
      Jesse Barnes authored
      Read out the current plane configuration at init time into a new
      plane_config structure.  This allows us to track any existing
      framebuffers attached to the plane and potentially re-use them in our
      fbdev code for a smooth handoff.
      
      v2: update for new pitch_for_width function (Jesse)
          comment how get_plane_config works with shared fbs (Jesse)
      v3: s/ARGB/XRGB (Ville)
          use pipesrc width/height (Ville)
          fix fourcc comment (Bob)
          use drm_format_plane_cpp (Ville)
      v4: use fb for tracking fb data object (Ville)
      v5: fix up gen2 pitch limits (Ville)
      v6: read out stride as well (Daniel)
      v7: split out init ordering changes (Daniel)
          don't fetch config if !CONFIG_FB
      v8: use proper height in get_plane_config (Chris)
      v9: fix CONFIG_FB check for modular configs (Jani)
      v10: add comment about stolen allocation stomping
      v11: drop hw state readout hunk (Daniel)
      v12: handle tiled BIOS fbs (Kristian)
           pull out common bits (Jesse)
      v13: move fb obj alloc out to _init
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1ad292b5
    • Jesse Barnes's avatar
      drm/i915: add plane_config fetching infrastructure v2 · 46f297fb
      Jesse Barnes authored
      Early at init time, we can try to read out the plane config structure
      and try to preserve it if possible.
      
      v2: alloc fb obj at init time after fetching plane config
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      46f297fb
  3. 07 Mar, 2014 24 commits
    • Chris Wilson's avatar
      drm/i915: Do not force non-caching copies for pwrite along shmem path · c2831a94
      Chris Wilson authored
      We don't always want to write into main memory with pwrite. The shmem
      fast path in particular is used for memory that is cacheable - under
      such circumstances forcing the cache eviction is undesirable. As we will
      always flush the cache when targeting incoherent buffers, we can rely on
      that second pass to apply the cache coherency rules and so benefit from
      in-cache copies otherwise.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c2831a94
    • Chris Wilson's avatar
      drm/i915: Process page flags once rather than per pwrite/pread · 17793c9a
      Chris Wilson authored
      We used to lock individual pages inside the buffer object and so needed
      to update the page flags every time. However, we now pin the pages into
      the object for the duration of the pwrite/pread (and hopefully much
      longer) and so we can forgo the flag updates until we release all the
      pages.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      17793c9a
    • Daniel Vetter's avatar
      drm/i915: Go OCD on the Makefile · 2fae6a86
      Daniel Vetter authored
      Chris suggested to split things up a bit into the different parts of
      the driver and also sort it all correctly, with the hope that we're
      trying to organize things a bit better eventually. It should also
      help newcomers to orient themselves a bit better.
      
      v2:
      - Move intel_pm.c to the core - to make things perfect we should split
        out the modeset related pm features (psr/fbc) into a separate file.
        Maybe something Rodrigo can do once the PSR patches have settled.
      
      - Split the modesetting sections into core and encoders/outputs.
        intel_ddi.c is a bit funky since it has core hsw+ support and ddi
        output support. Whatever.
      
      v3: Failed to git add ...
      
      v4: Really go ocd, i.e. spelling fix in a comment from Jani.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2fae6a86
    • Brad Volkin's avatar
      drm/i915: Implement command buffer parsing logic · 351e3db2
      Brad Volkin authored
      The command parser scans batch buffers submitted via execbuffer ioctls before
      the driver submits them to hardware. At a high level, it looks for several
      things:
      
      1) Commands which are explicitly defined as privileged or which should only be
         used by the kernel driver. The parser generally rejects such commands, with
         the provision that it may allow some from the drm master process.
      2) Commands which access registers. To support correct/enhanced userspace
         functionality, particularly certain OpenGL extensions, the parser provides a
         whitelist of registers which userspace may safely access (for both normal and
         drm master processes).
      3) Commands which access privileged memory (i.e. GGTT, HWS page, etc). The
         parser always rejects such commands.
      
      See the overview comment in the source for more details.
      
      This patch only implements the logic. Subsequent patches will build the tables
      that drive the parser.
      
      v2: Don't set the secure bit if the parser succeeds
      Fail harder during init
      Makefile cleanup
      Kerneldoc cleanup
      Clarify module param description
      Convert ints to bools in a few places
      Move client/subclient defs to i915_reg.h
      Remove the bits_count field
      
      OTC-Tracker: AXIA-4631
      Change-Id: I50b98c71c6655893291c78a2d1b8954577b37a30
      Signed-off-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      [danvet: Appease checkpatch.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      351e3db2
    • Brad Volkin's avatar
      drm/i915: Refactor shmem pread setup · 4c914c0c
      Brad Volkin authored
      The command parser is going to need the same synchronization and
      setup logic, so factor it out for reuse.
      
      v2: Add a check that the object is backed by shmem
      Signed-off-by: default avatarBrad Volkin <bradley.d.volkin@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4c914c0c
    • Ville Syrjälä's avatar
      drm/i915: Avoid div by zero when pixel clock is large · 922044c9
      Ville Syrjälä authored
      Make sure the line_time_us isn't zero in the gmch watermarks code as
      that would cause a div by zero. This can be triggered by specifying
      a very fast pixel clock for the mode.
      
      At some point we should probably just switch over to using the same
      math we use on PCH platforms which avoids such intermediate rounded
      results.
      
      Also we should verify the user provided mode much more rigorously.
      At the moment we accept pretty much anything.
      
      Note that "very fast mode" here means above 74.25 GHz.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: Add Ville's clarification of what "very fast" means.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      922044c9
    • Imre Deak's avatar
      drm/i915: power domains: add vlv power wells · 77961eb9
      Imre Deak authored
      Based on an early draft from Jesse.
      
      Add support for powering on/off the dynamic power wells on VLV by
      registering its display and dpio dynamic power wells with the power
      domain framework.
      
      For now power on all PHY TX lanes regardless of the actual lane
      configuration. Later this can be optimized when the PHY side setup
      enables only the required lanes. Atm, it enables all lanes in all
      cases.
      
      v2:
      - undef function local COND macro after its last use (Ville)
      - Take dev_priv->irq_lock around the whole sequence of
        intel_set_cpu_fifo_underrun_reporting_nolock() and
        valleyview_disable_display_irqs(). They are short and releasing
        the lock in between only makes proving correctness more difficult.
      - sanitize local var names in vlv_power_well_enabled()
      v3:
      - rebase on latest -nightly
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Resolve conflict due to my changes in the previous patch.
      Also throw in an assert_spin_locked for safety. And finally appease
      checkpatch.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      77961eb9
    • Imre Deak's avatar
      drm/i915: factor out intel_set_cpu_fifo_underrun_reporting_nolock · f88d42f1
      Imre Deak authored
      Needed by the next patch, wanting to set the underrun reporting as part
      of a bigger dev_priv->irq_lock'ed sequence.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Use more customary __ prefix instead of _nolock postfix.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f88d42f1
    • Imre Deak's avatar
      drm/i915: vlv: factor out valleyview_display_irq_install · f8b79e58
      Imre Deak authored
      We'll need to disable/re-enable the display-side IRQs when turning
      off/on the VLV display power well. Factor out the helper functions
      for this. For now keep the display IRQs enabled by default, so the
      functionality doesn't change. This will be changed to enable/disable
      the IRQs on-demand when adding support for VLV power wells in an
      upcoming patch.
      
      v2:
      - take the irq spin lock for the whole enable/disable sequence as
        these can be called with interrupts enabled
      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>
      f8b79e58
    • Imre Deak's avatar
      drm/i915: sanity check power well sw state against hw state · 25eaa003
      Imre Deak authored
      Suggested by Daniel.
      
      v2:
      - sanitize the state checking condition, the original was rather
        confusing (partly due to the unfortunate naming of
        i915.disable_power_well) (Ville)
      - simpler message+backtrace generation by using WARN instead of WARN_ON
        (Ville)
      - check if always-on power wells are truly on all the time
      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>
      25eaa003
    • Imre Deak's avatar
      drm/i915: factor out reset_vblank_counter · dd7c0b66
      Imre Deak authored
      We need to do the same for other platforms in upcoming patches.
      
      v2:
      - s/p/pipe (Ville)
      - Call the new helper with the vbl_lock already held. The part it
        protects is short, so releasing it between pipes only makes proving
        correctness more difficult.
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Resolve conflict with Damien's s/p/pipe/ change.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dd7c0b66
    • Imre Deak's avatar
      drm/i915: sanitize PUNIT register macro definitions · a30180a5
      Imre Deak authored
      In the upcoming patches we'll need to access the rest of the fields in
      the punit power gating register, so prepare for that.
      
      v2:
      - add doc reference for the power well subsystem IDs (Jesse)
      - remove IDs for non-existant DPIO_RX[23] subsystems (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>
      a30180a5
    • 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
  4. 05 Mar, 2014 7 commits