From: Daniel Vetter <daniel@ffwll.ch>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: rip out edp special case from dp_link_down
Date: Fri, 14 Sep 2012 18:33:50 +0200 [thread overview]
Message-ID: <20120914163350.GD5799@phenom.ffwll.local> (raw)
In-Reply-To: <CA+gsUGTgT+uXgVda0xhqJc_Y0=N9KhkrO9i0c-NyCHx4pguhJw@mail.gmail.com>
On Thu, Sep 13, 2012 at 07:17:55PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/9/9 Daniel Vetter <daniel.vetter@ffwll.ch>:
> > This has been tons of fun to figure out with git blame. The first
> > notion of this code block goes back to the original cpu edp enabling
> > for ilk in
> >
> > commit 32f9d658aee5be09ebdd28fc730630e61d0b46db
> > Author: Zhenyu Wang <zhenyuw@linux.intel.com>
> > Date: Fri Jul 24 01:00:32 2009 +0800
> >
> > drm/i915: Add eDP support on IGDNG mobile chip
> >
> > Two things are notable in this commit wrt to the this edp special
> > case:
> > - The IS_eDP check _only_ fires for DP A, i.e. cpu edp ports.
> > - The cpu edp port is disabled at the top of the dp_link_down function.
> >
> > My theory is that these hacks was added to work around the completely
> > different modeset sequence for cpu edp ports compared to pch edp
> > ports. With the cpu edp confusion on ilk (and snb/ivb) now fixed up,
> > this shouldn't be required any more.
> >
> > The really interesting question is how this special cases survived
> > this long in the code. The first step is declaring the pch port D as
> > eDP if it's used for an internal panel:
> >
> > commit b329530ca7cdf6bf014f2124efd983e01265d623
> > Author: Adam Jackson <ajax@redhat.com>
> > Date: Fri Jul 16 14:46:28 2010 -0400
> >
> > drm/i915/dp: Correctly report eDP in the core connector type
> >
> > This commit unfortunately failed to notice that not all edp ports are
> > created equal. Then follow a flurry of refactorings, culminating in a
> > patch from Keith Packard which resulted in the current logic (by
> > making it "correct" for all platforms that have edp):
> >
> > commit 417e822deee1d2bcd8a8a60660c40a0903713f2b
> > Author: Keith Packard <keithp@keithp.com>
> > Date: Tue Nov 1 19:54:11 2011 -0700
> >
> > drm/i915: Treat PCH eDP like DP in most places
> >
> > None of these cleanups or refactorings supply any reason why we need
> > this code, they've simply carried it on as-is.
> >
> > Hence presume it might be harmful with the current code and rip it
> > out. We do rewrite the link training bits completely anyway when
> > re-training the link.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> After looking for a long time I could not find a reason why we should
> set the pattern to "train off" while disabling the eDP port. Notice
> that "train off" means "send normal pixels" (see BSpec). All the docs
> say is that when _enabling_ the port we need to set training pattern
> 1, which we should already be doing. After your patch, when we disable
> the port we will disable it with training pattern already set to 1
> (instead of "send normal pixels/ train off"), but there's nothing
> saying we shouldn't do this. So yeah, your patch looks fine. If we
> ever revert this patch, let's make sure we add a big comment
> explaining it.
Yeah, I if this blows up we can add a fun story to our code in a comment
;-)
> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Thanks for the review, patch is queued for -next.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2012-09-14 16:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-09 17:58 [PATCH] drm/i915: rip out edp special case from dp_link_down Daniel Vetter
2012-09-10 16:15 ` Adam Jackson
2012-09-13 22:17 ` Paulo Zanoni
2012-09-14 16:33 ` Daniel Vetter [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=20120914163350.GD5799@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=przanoni@gmail.com \
/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.