On Thu, 12 Apr 2018, Timo Aaltonen <tjaalton@xxxxxxxxxx> wrote:
> 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.
I made the backport request to v4.13+, up to stable team which kernels
they care about.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
