1. 02 Sep, 2015 14 commits
  2. 01 Sep, 2015 11 commits
  3. 31 Aug, 2015 6 commits
  4. 28 Aug, 2015 2 commits
  5. 26 Aug, 2015 7 commits
    • Maarten Lankhorst's avatar
      Partially revert "drm/i915: Use full atomic modeset." · c5b852f3
      Maarten Lankhorst authored
      This partially reverts commit 74c090b1.
      
      The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async
      support.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      c5b852f3
    • Paulo Zanoni's avatar
      drm/i915: gen 9 can check for unclaimed registers too · 6c908bf4
      Paulo Zanoni authored
      Dear git bisect user,
      
      Even though this is the patch that introduced the WARN() you're
      bisecting, please notice that it's very likely that the problem you're
      facing was already present before this commit. In other words: this
      commit adds code to detect errors and give WARN()s about them, but the
      errors were already there.
      
      In order to continue your debug, please use the i915.mmio_debug
      option, check the backtraces and try to discover which read or write
      operation is causing the error message. Then check if this is
      happening because the register does not exist or because its power
      well is down when the operation is being done.
      
      On my SKL machine, if I use i915.mmio_debug=999, this patch triggers
      42 WARNs just by booting. I didn't investigate them yet. Normal users
      are only going to get a single WARN due to the default i915.mmio_debug
      setting.
      
      Thank you for your comprehension,
      Paulo
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      6c908bf4
    • Ville Syrjälä's avatar
      drm/i915: Force CL2 off in CHV x1 PHY · 3e288786
      Ville Syrjälä authored
      We can choose to leave the display PHY CL2 powerdown up to some hardware
      signals, or we can force it. The BXT code forces the nonexistent CL2 in
      the x1 PHY to power down. Follow suit on CHV. Maybe it can still save
      some extra power by disabling some extra logic in CL1, or something.
      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>
      3e288786
    • Ville Syrjälä's avatar
      drm/i915: Enable DPIO SUS clock gating on CHV · ee279218
      Ville Syrjälä authored
      CHV has supports some form of automagic clock gating for the
      DPIO SUS clock. We can simply enable the magic bits and the
      hardware should take care of the rest.
      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>
      ee279218
    • Ville Syrjälä's avatar
      drm/i915: Force common lane on for the PPS kick on CHV · 0047eedc
      Ville Syrjälä authored
      With DPIO powergating active the DPLL can't be accessed unless
      something else is keeping the common lane in the channel on.
      That means the PPS kick procedure could fail to enable the PLL.
      
      Power up some data lanes to force the common lane to power up
      so that the PLL can be enabled temporarily.
      
      v2: Avoid gcc uninitilized variable warning
      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>
      0047eedc
    • 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