An error occurred fetching the project authors.
  1. 10 Sep, 2015 1 commit
  2. 04 Sep, 2015 1 commit
  3. 02 Sep, 2015 3 commits
  4. 01 Sep, 2015 1 commit
  5. 26 Aug, 2015 6 commits
    • Ville Syrjälä's avatar
      drm/i915: Trick CL2 into life on CHV when using pipe B with port B · b0b33846
      Ville Syrjälä authored
      Normmally the common lane in a PHY channel gets powered up when some
      of the data lanes get powered up. But when we're driving port B with
      pipe B we don't want to enabled any of the data lanes, and just want
      the DPLL in the common lane to be active.
      
      To make that happens we have to temporarily enable some data lanes
      after which we can access the DPLL registers in the common lane. Once
      the pipe is up and running we can drop the power override on the data
      lanes allowing them to shut down. From this point forward the common
      lane will in fact stay powered on until the data lanes in the other
      channel get powered down.
      
      Ville's extended explanation from the review thread:
      
      On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote:
      > One Q, why only for port B? Port C is also in same common lane right?
      
      Port B is in the first PHY channel which also houses CL1. CL1 always
      powers up whenever any lanes in either PHY channel are powered up.
      CL2 only powers up if lanes in the second channel (ie. the one with
      port C) powers up.
      
      So in this scenario (pipe B->port B) we want the DPLL from CL2, but
      ideally we only want to power up the lanes for port B. Powering up
      port B lanes will only power up CL1, but as we need CL2 instead we
      need to, temporarily, power up some lanes in port C as well.
      
      Crossing the streams the other way (pipe A->port C) is not a problem
      since CL1 powers up whenever anything else powers up. So powering up
      some port C lanes is enough on its own to make the CL1 DPLL
      operational, even though CL1 and the lanes live in separate channels.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      [danvet: Amend commit message with extended explanation.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b0b33846
    • Ville Syrjälä's avatar
      drm/i915: Implement PHY lane power gating for CHV · e0fce78f
      Ville Syrjälä authored
      Powergate the PHY lanes when they're not needed. For HDMI all four lanes
      are needed always, but for DP we can enable only the needed lanes. To
      power down the unused lanes we use some power down override bits in the
      DISPLAY_PHY_CONTROL register. Without the overrides it appears that the
      hardware always powers on all the lanes. When the port is disabled the
      power down override is not needed and the lanes will shut off on their
      own. That also means the override is critical to actually be able to
      access the DPIO registers before the port is actually enabled.
      
      Additionally the common lanes will power down when not needed. CL1
      remains on as long as anything else is on, CL2 will shut down when
      all the lanes in the same channel will shut down. There is one exception
      for CL2 that will be dealt in a separate patch for clarity.
      
      With potentially some lanes powered down, the DP code now has to check
      the number of active lanes before accessing PCS/TX registers. All
      registers in powered down blocks will reads as 0xffffffff, and soe we
      would drown in warnings from vlv_dpio_read() if we allowed the code
      to access all those registers.
      
      Another important detail in the DP code is the "TX latency optimal"
      setting. Normally the second TX lane acts as some kind of reset master,
      with the other lanes as slaves. But when only a single lane is enabled,
      that single lane obviously has to be the master.
      
      A bit of extra care is needed to reconstruct the initial state of the
      DISPLAY_PHY_CONTROL register since it can't be read safely. So instead
      read the actual lane status from the DPLL/PHY_STATUS registers and
      use that to determine which lanes ought to be powergated initially.
      
      We also need to switch the PHY power modes to "deep PSR" to avoid
      a hard system hang when powering down the single channel PHY.
      
      Also sprinkle a few debug prints around so that we can monitor the
      DISPLAY_PHY_STATUS changes without having to read it and risk
      corrupting it.
      
      v2: Add locking to chv_powergate_phy_lanes()
      v3: Actually enable dynamic powerdown in the PHY and deal with the
          fallout
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e0fce78f
    • Jani Nikula's avatar
      drm/i915: move ibx_digital_port_connected to intel_dp.c · b93433cc
      Jani Nikula authored
      The function can be made static there. No functional changes.
      Reviewed-by: default avatarDurgadoss R <durgadoss.r@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b93433cc
    • Ville Syrjälä's avatar
      drm/i915: Add vlv_dport_to_phy() · 65d64cc5
      Ville Syrjälä authored
      Add vlv_dport_to_phy() and fix up the return values of
      vlv_dport_to_channel() and vlv_pipe_to_channel() to use
      the appropriate enums.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      65d64cc5
    • Ville Syrjälä's avatar
      drm/i915: Add encoder->post_pll_disable() hooks and move CHV clock buffer disables there · d6db995f
      Ville Syrjälä authored
      Move the CHV clock buffer disable from chv_disable_pll() to the new
      encoder .post_pll_disable() hook. This is more symmetric since the
      clock buffer enable happens from the .pre_pll_enable() hook.
      
      We'll have more use for the new hook soon.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDeepak S <deepak.s@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d6db995f
    • Ville Syrjälä's avatar
      drm/i915: Put back lane_count into intel_dp and add link_rate too · 901c2daf
      Ville Syrjälä authored
      With MST there won't be a crtc assigned to the main link encoder, so
      trying to dig up the pipe_config from there is a recipe for an oops.
      
      Instead store the parameters (lane_count and link_rate) in the encoder,
      and use those values during link training etc. Since those parameters
      are now assigned only when the link is actually enabled,
      .compute_config() won't clobber them as it did before.
      
      Hardware state readout is still bonkers though as we don't transfer the
      link parameters from pipe_config intel_dp. We should do that during
      encoder sanitation. But since we don't even do a proper job of reading
      out the main link encoder state for MST there's littel point in
      worrying about this now.
      
      Fixes a regression with MST caused by:
       commit 90a6b7b0
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Mon Jul 6 16:39:15 2015 +0300
      
          drm/i915: Move intel_dp->lane_count into pipe_config
      
      v2: Different apporoach that should keep intel_dp_check_mst_status()
          somewhat less oopsy
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reported-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      901c2daf
  6. 14 Aug, 2015 8 commits
  7. 11 Aug, 2015 1 commit
  8. 05 Aug, 2015 1 commit
    • Paulo Zanoni's avatar
      drm/i915: fix FBC frontbuffer tracking flushing code · 6f4551fe
      Paulo Zanoni authored
      Due to the way busy_bits was handled, we were not doing any flushes if
      we didn't previously get an invalidate. Since it's possible to get
      flushes without an invalidate first, remove the busy_bits early
      return.
      
      So now that we don't have the busy_bits guard anymore we'll need the
      origin check for the GTT tracking (we were not doing anything on GTT
      flushes due to the GTT check at invalidate()).
      
      As a last detail, since we can get multiple consecutive flushes,
      disable FBC before updating it, otherwise intel_fbc_update() will just
      keep FBC enabled instead of restarting it.
      
      Notice that this does not fix any of the current IGT tests due to the
      fact that we still have a few intel_fbc() calls at points where we
      also have the frontbuffer tracking calls: we didn't fully convert to
      frontbuffer tracking yet. Once we remove those calls and start relying
      only on the frontbuffer tracking infrastructure we'll need this patch.
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6f4551fe
  9. 27 Jul, 2015 1 commit
  10. 21 Jul, 2015 1 commit
  11. 15 Jul, 2015 3 commits
  12. 14 Jul, 2015 5 commits
  13. 09 Jul, 2015 2 commits
  14. 08 Jul, 2015 2 commits
  15. 06 Jul, 2015 2 commits
    • Paulo Zanoni's avatar
      drm/i915: add the FBC mutex · 25ad93fd
      Paulo Zanoni authored
      Make sure we're not going to have weird races in really weird cases
      where a lot of different CRTCs are doing rendering and modesets at the
      same time.
      
      With this change and the stolen_lock from the previous patch, we can
      start removing the struct_mutex locking we have around FBC in the next
      patches.
      
      v2:
       - Rebase (6 months later)
       - Also lock debugfs and stolen.
      v3:
       - Don't lock a single value read (Chris).
       - Replace lockdep assertions with WARNs (Daniel).
       - Improve commit message.
       - Don't forget intel_pre_plane_update() locking.
      v4:
       - Don't remove struct_mutex at intel_pre_plane_update() (Chris).
       - Add comment regarding locking dependencies (Chris).
       - Rebase after the stolen code rework.
       - Rebase again after drm-intel-nightly changes.
      v5:
       - Rebase after the new stolen_lock patch.
      
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      25ad93fd
    • Paulo Zanoni's avatar
      drm/i915: move FBC code out of i915_gem_stolen.c · fc786728
      Paulo Zanoni authored
      With the abstractions created by the last patch, we can move this code
      and the only thing inside intel_fbc.c that knows about dev_priv->mm is
      the code that reads stolen_base.
      
      We also had to move a call to i915_gem_stolen_cleanup_compression()
      - now called intel_fbc_cleanup_cfb() - outside i915_gem_stolen.c.
      
      v2:
        - Rebase after the remove_node() changes on the previous patch.
      Requested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      fc786728
  16. 30 Jun, 2015 2 commits