Date: Mon, 17 Aug 2015 16:06:53 -0400
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
To: =?utf-8?B?U3TDqXBoYW5l?= Marchesin <marcheu@chromium.org>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>,
        Daniel Vetter <daniel.vetter@intel.com>,
        intel-gfx <intel-gfx@lists.freedesktop.org>,
        Todd Broch <tbroch@chromium.org>, linux-kernel@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for
 DP
Message-ID: <20150817200653.GB14631@mail.corp.redhat.com>
References: <1438099409-25456-1-git-send-email-benjamin.tissoires@redhat.com>
 <1438099409-25456-4-git-send-email-benjamin.tissoires@redhat.com>
 <55B88E25.6000006@intel.com>
 <20150729152240.GD2743@mail.corp.redhat.com>
 <55B9A471.2070107@intel.com>
 <20150805193427.GA6097@mail.corp.redhat.com>
 <CADMs+9Zvh0+8Q2tpK_yfLRXV0v=DJkXcUUEFG6+pg5LQ1i9Qxw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADMs+9Zvh0+8Q2tpK_yfLRXV0v=DJkXcUUEFG6+pg5LQ1i9Qxw@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3492
Lines: 82

On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
> On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> > On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>
> >>
> >> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >> >>identify both lane count and reversal state without touching anything in the
> >> >>link training code. i am yet to upstream my changes for CHT that i can share
> >> >>if required that does the same in intel_dp_detect without touching any line
> >> >>in link training path.
> >> >With my current limited knowledge of the dp hotplug (and i915 driver) I
> >> >am not sure we could detect the reversed state without trying to train 1
> >> >lane only. I'd be glad to look at your changes and test them on my
> >> >system if you think that could help having a cleaner solution.
> >> >
> >> >Cheers,
> >> >Benjamin
> >> No, what i recommended was to do link training but in intel_dp_detect. Since
> >> USB Type C cable
> >> also has its own lane count restriction (it can have different lane count
> >> than the one supported
> >> by panel) you might have to figure that out as well. so both reversal and
> >> lane count detection
> >> can be done outside the modeset path and keep the code free of type C
> >> changes outside
> >> detection path.
> >>
> >> Please find below the code to do the same. Do not waste time trying to apply
> >> this directly on
> >> nightly since this is based on a local tree and because this is pre- atomic
> >> changes code, so you
> >> might have to modify chv_upfront_link_train to work on top of the latest
> >> nightly code. we
> >> are supposed to upstream this and is in my todo list.
> >>
> >
> > [original patch snipped...]
> >
> > Hi Sivakumar,
> >
> > So I managed to manually re-apply your patch on top of
> > drm-intel-nightly, and tried to port it to make Broadwell working too.
> > It works OK if the system is already boot without any external DP used.
> > In this case, the detection works and I can see my external monitor
> > working properly.
> >
> > However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
> > understand why. I think I enabled all that is mentioned in the PRM to be
> > able to train the DP link, but I am obviously missing something else.
> > Can you have a look?
> >
> 
> Hi Benjamin,
> 
> I would recommend against this approach. Some adapters will claim that
> they recovered a clock even when it isn't on the lanes you enabled,
> which means that the reversal detection doesn't always work. The only
> reliable way to do this is to go talk to the Chrome OS EC (you can
> find these patches later in the Chrome OS tree). It's not as generic,
> but we might be able to abstract that logic, maybe.
> 

Hi Stéphane,

This is a very good news. I was afraid we would not have access to the
hardware controller because the Intel controller hub spec was not
public.

I will try to have a look at it, but the latest chromeos branch (3.18)
seems to differ quite a lot from the upstream one. Anyway, fingers
crossed.

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/