All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: PCH eDP fixes
Date: Fri, 8 Oct 2010 09:24:55 -0700	[thread overview]
Message-ID: <20101008092455.07dc638b@jbarnes-desktop> (raw)
In-Reply-To: <89k77n$p5t8bi@fmsmga001.fm.intel.com>

On Fri, 08 Oct 2010 11:00:11 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Thu,  7 Oct 2010 16:01:05 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > Here's the set of PCH eDP fixes I came up with once I received my Sony
> > Vaio.  I found a few, non-PCH issues in the process, and took the
> > opportunity to enhance our eDP support to avoid most of the DP training
> > if the VBIOS gives us good data.
> 
> I didn't see how you confirmed that it was good data rather than just
> conservative, power hungry values ;-) Nevertheless, getting eDP to light
> up is a massive step forward on those machines.

I saw you added a new 'valid' bit of some kind for the VBT provided eDP
data; we should check for that in the DP init function if needed.

As for power, the preemphasis and voltage swing levels are just for
training.  Using the VBT values is supposedly ideal from the panel and
board's perspective (i.e. the link will be most stable with the
provided values), so we really need to use them even if they cost
slightly more power than a different training scheme.  On my test
machine, these values are actually lower than the values arrived at via
full training, so hopefully they're better, power-wise, anyway.

The number of lanes definitely affects power though, but the VBT should
have the minimum number of lanes required to drive the panel at its
native mode (and in fact, some systems may be missing wires for lanes
above this number), so again it should be good from a power perspective.

> Thanks Jesse, and to everyone who tested the various hacks, maybe there is
> some light at the end of the eDP tunnel!

I hope so, sounds like there are still some suspend/resume issues, I'll
take a look at those.

-- 
Jesse Barnes, Intel Open Source Technology Center

      reply	other threads:[~2010-10-08 16:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-07 23:01 PCH eDP fixes Jesse Barnes
2010-10-07 23:01 ` [PATCH 01/20] drm/i915/dp: convert eDP checks to functions and document Jesse Barnes
2010-10-07 23:01 ` [PATCH 02/20] drm/i915/dp: remove redundant is_pch_edp checks Jesse Barnes
2010-10-07 23:01 ` [PATCH 03/20] drm/i915/dp: correct eDP lane count and bpp Jesse Barnes
2010-10-07 23:01 ` [PATCH 04/20] drm/i915: add eDP checking functions for the display code Jesse Barnes
2010-10-07 23:01 ` [PATCH 05/20] drm/i915: remove broken intel_pch_has_edp function Jesse Barnes
2010-10-07 23:01 ` [PATCH 06/20] drm/i915: fix CPU vs PCH eDP confusion Jesse Barnes
2010-10-07 23:01 ` [PATCH 07/20] drm/i915/dp: eDP power sequencing fixes Jesse Barnes
2010-10-07 23:01 ` [PATCH 08/20] drm/i915: add _DSM support Jesse Barnes
2010-10-07 23:01 ` [PATCH 09/20] drm/i915: fetch eDP configuration data from the VBT Jesse Barnes
2010-10-07 23:01 ` [PATCH 10/20] drm/i915: add Ironlake clock gating workaround for FDI link training Jesse Barnes
2010-10-07 23:01 ` [PATCH 11/20] drm/i915: fix PCH eDP SSC support Jesse Barnes
2010-10-07 23:01 ` [PATCH 12/20] drm/i915: use 120MHz refclk in PCH eDP case too Jesse Barnes
2010-10-07 23:01 ` [PATCH 13/20] drm/i915: use DPLL_DVO_HIGH_SPEED for PCH eDP Jesse Barnes
2010-10-07 23:01 ` [PATCH 14/20] drm/i915: fix ironlake CRTC enable/disable Jesse Barnes
2010-10-07 23:01 ` [PATCH 15/20] drm/i915: don't program FDI RX/TX in mode_set Jesse Barnes
2010-10-07 23:01 ` [PATCH 16/20] drm/i915/dp: cache eDP DPCD data Jesse Barnes
2010-10-07 23:01 ` [PATCH 17/20] drm/i915/dp: use VBT provided eDP params if available Jesse Barnes
2010-10-07 23:01 ` [PATCH 18/20] drm/i915/dp: don't bother with DP PLL for PCH attached eDP Jesse Barnes
2010-10-07 23:01 ` [PATCH 19/20] drm/i915/dp: make eDP PLL functions work as advertised Jesse Barnes
2010-10-07 23:01 ` [PATCH 20/20] drm/i915: diasable clock gating for the panel power sequencer Jesse Barnes
2010-10-08  9:50 ` PCH eDP fixes Jim Gettys
2010-10-08 10:00 ` Chris Wilson
2010-10-08 16:24   ` Jesse Barnes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101008092455.07dc638b@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.