Skip to content

L
linux
Switch branch/tag
  1. 02 Sep, 2015 14 commits
  3. 01 Sep, 2015 11 commits
  5. 31 Aug, 2015 6 commits
  7. 28 Aug, 2015 2 commits
  9. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7