On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote: > On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires > <benjamin.tissoires@xxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
