From: Jani Nikula <jani.nikula@linux.intel.com>
To: Damien Lespiau <damien.lespiau@intel.com>, ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV
Date: Thu, 16 Oct 2014 15:09:08 +0300 [thread overview]
Message-ID: <87vbnkcj2z.fsf@intel.com> (raw)
In-Reply-To: <20141013180351.GA10112@strange.ger.corp.intel.com>
On Mon, 13 Oct 2014, Damien Lespiau <damien.lespiau@intel.com> wrote:
> On Thu, Oct 09, 2014 at 07:37:15PM +0300, ville.syrjala@linux.intel.com wrote:
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>
>> On CHV the display DDC pins may be muxed to an alternate function if
>> there's no need for DDC on a specific port, which is the case for eDP
>> ports since there's no way to plug in a DP++ HDMI dongle.
>>
>> This causes problems when trying to determine if the port is present
>> since the the DP_DETECTED bit is the latched state of the DDC SDA pin
>> at boot. If the DDC pins are muxed to an alternate function the bit
>> may indicate that the port isn't present.
>>
>> To work around this look at the VBT as well as the DP_DETECTED bit
>> to determine if we should attempt registering an eDP port. Do this
>> only for ports B and C since port D doesn't support eDP (no PPS/BLC).
>>
>> In theory someone could also wire up a normal DP port w/o DDC lines.
>> That would just mean that simple DP++ HDMI dongles wouldn't work
>> on such a port. With this change we would still fail to register
>> such DP ports. But let's hope no one wires their board in such a way,
>> and if they do we can extend the VBT checks to cover normal DP ports
>> as well.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84265
>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Pushed to drm-intel-next-fixes, thanks for the patch and review.
BR,
Jani.
>
> --
> Damien
>
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 33 +++++++++++++++++++++------------
>> 1 file changed, 21 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index b5476dc..d6fc469 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12280,27 +12280,36 @@ static void intel_setup_outputs(struct drm_device *dev)
>> if (I915_READ(PCH_DP_D) & DP_DETECTED)
>> intel_dp_init(dev, PCH_DP_D, PORT_D);
>> } else if (IS_VALLEYVIEW(dev)) {
>> - if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB) & SDVO_DETECTED) {
>> + /*
>> + * The DP_DETECTED bit is the latched state of the DDC
>> + * SDA pin at boot. However since eDP doesn't require DDC
>> + * (no way to plug in a DP->HDMI dongle) the DDC pins for
>> + * eDP ports may have been muxed to an alternate function.
>> + * Thus we can't rely on the DP_DETECTED bit alone to detect
>> + * eDP ports. Consult the VBT as well as DP_DETECTED to
>> + * detect eDP ports.
>> + */
>> + if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIB) & SDVO_DETECTED)
>> intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIB,
>> PORT_B);
>> - if (I915_READ(VLV_DISPLAY_BASE + DP_B) & DP_DETECTED)
>> - intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B, PORT_B);
>> - }
>> + if (I915_READ(VLV_DISPLAY_BASE + DP_B) & DP_DETECTED ||
>> + intel_dp_is_edp(dev, PORT_B))
>> + intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B, PORT_B);
>>
>> - if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIC) & SDVO_DETECTED) {
>> + if (I915_READ(VLV_DISPLAY_BASE + GEN4_HDMIC) & SDVO_DETECTED)
>> intel_hdmi_init(dev, VLV_DISPLAY_BASE + GEN4_HDMIC,
>> PORT_C);
>> - if (I915_READ(VLV_DISPLAY_BASE + DP_C) & DP_DETECTED)
>> - intel_dp_init(dev, VLV_DISPLAY_BASE + DP_C, PORT_C);
>> - }
>> + if (I915_READ(VLV_DISPLAY_BASE + DP_C) & DP_DETECTED ||
>> + intel_dp_is_edp(dev, PORT_C))
>> + intel_dp_init(dev, VLV_DISPLAY_BASE + DP_C, PORT_C);
>>
>> if (IS_CHERRYVIEW(dev)) {
>> - if (I915_READ(VLV_DISPLAY_BASE + CHV_HDMID) & SDVO_DETECTED) {
>> + if (I915_READ(VLV_DISPLAY_BASE + CHV_HDMID) & SDVO_DETECTED)
>> intel_hdmi_init(dev, VLV_DISPLAY_BASE + CHV_HDMID,
>> PORT_D);
>> - if (I915_READ(VLV_DISPLAY_BASE + DP_D) & DP_DETECTED)
>> - intel_dp_init(dev, VLV_DISPLAY_BASE + DP_D, PORT_D);
>> - }
>> + /* eDP not supported on port D, so don't check VBT */
>> + if (I915_READ(VLV_DISPLAY_BASE + DP_D) & DP_DETECTED)
>> + intel_dp_init(dev, VLV_DISPLAY_BASE + DP_D, PORT_D);
>> }
>>
>> intel_dsi_init(dev);
>> --
>> 2.0.4
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2014-10-16 12:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 16:37 [PATCH] drm/i915: Don't trust the DP_DETECT bit for eDP ports on CHV ville.syrjala
2014-10-13 18:03 ` Damien Lespiau
2014-10-16 12:09 ` Jani Nikula [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=87vbnkcj2z.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=damien.lespiau@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.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.