On 30.01.2018 09:38, Jani Nikula wrote:
> On Tue, 23 Jan 2018, Imre Deak <imre.deak@xxxxxxxxx> wrote:
>> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
>>> On Mon, 22 Jan 2018, Imre Deak <imre.deak@xxxxxxxxx> wrote:
>>>> On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>>>>> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>>>>>> In case of eDP because the panel has a fixed mode, the link rate
>>>>>> and lane count at which it is trained corresponds to the link BW
>>>>>> required to support the native resolution of the panel. In case of
>>>>>> panles with lower resolutions where fewer lanes are hooked up internally,
>>>>>> that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
>>>>>> So it is pointless to fallback to lower link rate/lane count in case
>>>>>> of link training failure on eDP connector since the lower link BW
>>>>>> will not support the native resolution of the panel and we cannot
>>>>>> prune the preferred mode on the eDP connector.
>>>>>>
>>>>>> In case of Link training failure on the eDP panel, something is wrong
>>>>>> in the HW internally and hence driver errors out with a loud
>>>>>> and clear DRM_ERROR message.
>>>>>>
>>>>>> v2:
>>>>>> * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>>>>>>
>>>>>> Cc: Clinton Taylor <clinton.a.taylor@xxxxxxxxx>
>>>>>> Cc: Jim Bride <jim.bride@xxxxxxxxxxxxxxx>
>>>>>> Cc: Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx>
>>>>>> Cc: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
>>>>>> Cc: Dave Airlie <airlied@xxxxxxxxxx>
>>>>>> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>>>> Signed-off-by: Manasi Navare <manasi.d.navare@xxxxxxxxx>
>>>>>> Reviewed-by: Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>
>>>>>
>>>>> This fell through the cracks, looks like it partially fixes
>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>>>>>
>>>>> Why link training fails there is not clear.
>>>>
>>>> Ok, the link training fail turned out to be a race between a modeset
>>>> link training and a link retraining called from
>>>> runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
>>>> one was fixed meanwhile by
>>>>
>>>> commit 42e5e65765265485ecf2a480c244d76c2c624449
>>>> Author: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>> AuthorDate: Mon Nov 13 17:01:40 2017 +0100
>>>> Commit: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>> CommitDate: Thu Nov 23 14:59:07 2017 +0100
>>>>
>>>> drm/i915: sync dp link status checks against atomic commmits
>>>>
>>>> I merged now this fix to address the other issue, adding the above bug
>>>> as reference. Thanks for the patch and the review.
>>>
>>> Thanks for the follow-up... but should we have added a Fixes: or cc:
>>> stable tag here?
>>
>> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
>> training failure")
>>
>> I wasn't sure about stable, since for me the link training failure
>> happened only due to the bug fixed by 42e5e65765265. In any case I can't
>> see how it could cause problems, so yes let's Cc: stable too.
>
> Rodrigo, here's another one to cherry-pick to drm-intel-next-fixes.
This patch fixes a regression with a BIOS upgrade on a Dell machine,
where the screen would stay blank after resume from suspend. So I'd like
it to find it's way to 4.15.x if that's still a thing.
--
t
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
