Bug 102294

Looks like

https://patchwork.freedesktop.org/series/28684/

would fix this. Waiting for Shashank to follow up to my review comments before merging it.

HI,
Shashank, Imre, how about 102295 is that dup of this?

Also seen on the new fi-cfl-s: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3001/fi-cfl-s/igt@gem_exec_suspend@basic-s4-devices.html

This error was handled in patch series https://patchwork.freedesktop.org/series/29155/

We are working with MCA to get the correct LP timings and behavior for LSPCON. Will be publishing updates soon.

Please, note

(In reply to Marta Löfstedt from comment #5)
> Please, note

that for CFL the LSPCON error messaged started when eDP was added!!! This is very odd and may indicate some firmware issue for the CFL we have in CI farm.

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3081/fi-cfl-s/igt@kms_busy@basic-flip-a.html

Those issues vanished when BIOS updated.
https://intel-gfx-ci.01.org/tree/drm-tip/fi-cfl-s.html

So CFL whitelisted.

Shashank, any updates for v4:
https://patchwork.freedesktop.org/series/31320/?

New series sent: https://patchwork.freedesktop.org/series/31639/

Probably fixed by these commits in drm-intel-next-queued:

commit f687e25a7a245952349f1f9f9cc238ac5a3be258
Author: Shashank Sharma <shashank.sharma@intel.com>
Date:   Thu Oct 12 22:10:08 2017 +0530

    drm: Add retries for lspcon mode detection

commit d18aef0f75436abb95894a230b504432df26c167
Author: Shashank Sharma <shashank.sharma@intel.com>
Date:   Tue Oct 10 15:37:43 2017 +0530

    drm/i915: Don't give up waiting on INVALID_MODE

commit a2fc4bd61e7ec3bb1f7c8b3d47272be813f88aea
Author: Shashank Sharma <shashank.sharma@intel.com>
Date:   Tue Oct 10 15:37:44 2017 +0530

    drm/i915: Add retries for LSPCON detection

Lets resolve as patches are merged.
But follow will be done and only after few runs will be verified

hello, 
as kernel 4.14.4 , always the same issues : 
( not issue with 4.9.66 )  
[   49.903181] [drm:drm_lspcon_get_mode [drm_kms_helper]] *ERROR* LSPCON read(0x80, 0x41) failed
[   49.903196] [drm:lspcon_wait_mode [i915]] *ERROR* Error reading LSPCON mode
[   49.915401] [drm:drm_lspcon_get_mode [drm_kms_helper]] *ERROR* LSPCON read(0x80, 0x41) failed
[   49.915415] [drm:lspcon_change_mode.constprop.4 [i915]] *ERROR* Error reading LSPCON mode
[   49.915426] [drm:lspcon_resume [i915]] *ERROR* LSPCON resume failed


CRTC info
---------
CRTC 36: pipe: A, active=no, (size=1920x1080), dither=no, bpp=24
        underrun reporting: cpu=yes pch=yes 
CRTC 46: pipe: B, active=no, (size=0x0), dither=no, bpp=0
        underrun reporting: cpu=yes pch=yes 
CRTC 56: pipe: C, active=no, (size=0x0), dither=no, bpp=0
        underrun reporting: cpu=yes pch=yes 

Connector info
--------------
connector 58: type DP-1, status: connected
        name: 
        physical dimensions: 480x270mm
        subpixel order: Unknown
        CEA rev: 3
        DPCD rev: 12
        audio support: no
        DP branch device present: yes
                Type: HDMI
                ID: MC2800
                HW: 2.2
                SW: 1.60
                Max TMDS clock: 600000 kHz
                Max bpc: 16
        modes:

regards

apply patch drm/i915: Add retries for LSPCON detection to 4.14.14 does not help .
regards

add patch : drm: Add retries for lspcon mode detection
LSPCON message disapear but screen is always black ( no screen ) 
xrandr -s  1920x1080
Size 1920x1080 not found in available modes
xrandr 
Screen 0: minimum 8 x 8, current 1024 x 768, maximum 32767 x 32767
DP1 connected (normal left inverted right x axis y axis)
   1920x1080     60.00 +  50.00    59.94  
   1680x1050     59.88  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

From the given logs, I can see that the LSPCON FW version is still old (1.60)
DP branch device present: yes
                Type: HDMI
                ID: MC2800
                HW: 2.2
             -> SW: 1.60
                Max TMDS clock: 600000 kHz
                Max bpc: 16

This was a problem in MCA LSPCON FW. We have worked with MCA, to get this problem fixed in, and MCA has released FW version 1.70 (which is already deployed in KBL devices in Grid, by Tomi).

We are also working on making a Linux based FW flashing tool. Once this is done, we will make the FW and tool available to end users, so that they can get rid of this issue. 

- Shashank

So was this seen only on Old FW version (1.63) and not surfaced later?

Nicolas, what HW / System you had seeing this issue?

(In reply to shashank.sharma@intel.com from comment #16)
> From the given logs, I can see that the LSPCON FW version is still old (1.60)
> DP branch device present: yes
>                 Type: HDMI
>                 ID: MC2800
>                 HW: 2.2
>              -> SW: 1.60
>                 Max TMDS clock: 600000 kHz
>                 Max bpc: 16
> 
> This was a problem in MCA LSPCON FW. We have worked with MCA, to get this
> problem fixed in, and MCA has released FW version 1.70 (which is already
> deployed in KBL devices in Grid, by Tomi).
> 
> We are also working on making a Linux based FW flashing tool. Once this is
> done, we will make the FW and tool available to end users, so that they can
> get rid of this issue. 
> 
> - Shashank

Shashank, we are still seeing the issue on KBL see bug 103313 also see the link training bugs KBL 103558, CFL bug 104056, SKL bug 101144.

(In reply to Marta Löfstedt from comment #19)
> (In reply to shashank.sharma@intel.com from comment #16)
> > From the given logs, I can see that the LSPCON FW version is still old (1.60)
> > DP branch device present: yes
> >                 Type: HDMI
> >                 ID: MC2800
> >                 HW: 2.2
> >              -> SW: 1.60
> >                 Max TMDS clock: 600000 kHz
> >                 Max bpc: 16
> > 
> > This was a problem in MCA LSPCON FW. We have worked with MCA, to get this
> > problem fixed in, and MCA has released FW version 1.70 (which is already
> > deployed in KBL devices in Grid, by Tomi).
> > 
> > We are also working on making a Linux based FW flashing tool. Once this is
> > done, we will make the FW and tool available to end users, so that they can
> > get rid of this issue. 
> > 
> > - Shashank
> 
> Shashank, we are still seeing the issue on KBL see bug 103313 also see the
> link training bugs KBL 103558, CFL bug 104056, SKL bug 101144.

Most of the *ERROR* LSPCON read(0x80, 0x41) failed issues are fixed with LSPCON FW V1.72. The issues which we see on KBL are the link training failures. These are two different issues, and we should not mix it. Probably once we are able to communicate to the external world on how to flash and upgrade LSPCON FW, some of the noise will go down, and we should be able to reach the actual issue. 

There are many variables which can affect the LSPCON issues:
- LSPCON FW version, anything below V1.70 will cause problems for sure.
- KVM device Vs Direct HDMI: Many KVM machine with old KVM FW trigger the issue of Link training more often, so we have to make sure we have the right setup. 
- Link training failures after above setup: These are the actual issues which we want to target. 

- Shashank

Hello, 
sorry for the delay, 
all my tests is on Intel Nuc serie ( skylake, kabylake , i3->i7 ) 

How can update firmware ?  kernel firmware has up to date ?
I have i915.enable_guc_loading=1 , enable_huc=1  in cmdline 

Regards, 
Nicolas

If upgrade LSPCON FW is closed to Intel, 
our company has a intel partner number , can it help ?

Regards, 
Nicolas

(In reply to prochazka.nicolas from comment #22)
> If upgrade LSPCON FW is closed to Intel, 
> our company has a intel partner number , can it help ?
> 
> Regards, 
> Nicolas
FWIW, I looked over https://downloadcenter.intel.com for the LSPCON FW for KBL. You may take a look at it.

Hello, 
we are managing 10000 intel nuc under linux, 
is a good solution to resintall all with win10 to apply firmware update, only on windows ????

Is possible to get a name of project leader of intel about this issue ?
Regards, 
Nicolas

(In reply to prochazka.nicolas from comment #24)
> Hello, 
> we are managing 10000 intel nuc under linux, 
> is a good solution to resintall all with win10 to apply firmware update,
> only on windows ????
> 
> Is possible to get a name of project leader of intel about this issue ?
> Regards, 
> Nicolas

Hello,

The right people are already monitoring this bug, so they are aware of this issue.

Right now, your safest bet is indeed to install windows for flashing the firmware. A solution for Linux is being investigated, but we have nothing official yet. We'll make sure to update the bug if anything changes.

Sorry for not being able to tell you more.
Regards,
Martin

Ok, 
if you need beta test, or other thing, we are selling a lot of intel nuc
Regards, 
Nicolas

Hello, 
any news about tools for upgrading firmware from linux host ?
Regards, 
Nicolas Prochazka

(In reply to prochazka.nicolas from comment #27)
> Hello, 
> any news about tools for upgrading firmware from linux host ?
> Regards, 
> Nicolas Prochazka

No official news yet, but things are happening!
We'll get back to you as soon as we have something more concrete.

Regards,
Martin

Hi,
This latest information:
We have received native Linux based opensource tools from both the vendors (MCA and Parade), and we are working on an integrated tool, which will auto-detect the LSPCON chip and flash the FW accordingly. This is work in progress, and will update on this soon.

We are following this bug on a weekly basis, and will provide updates at the same rate. For this reason, we will drop the priority to high.

(In reply to prochazka.nicolas from comment #27)
> Hello, 
> any news about tools for upgrading firmware from linux host ?
> Regards, 
> Nicolas Prochazka

We have been working hard on this topic. We managed to get the occurrence rate of any LSPCON bug close to 0 through multiple fixes of the firmware and improvements in i915.

However, this is pointless if we cannot share the firmwares and flashing tools. We got a Linux flashing tool from our partner and we are now in the process of adapting it be included in Linux's fwupd project.

We decided to take more control on this issue because our driver's quality depends on it. So expect updates soon! We really want to be better at this and have this sort of processes ready when the products come out.

(In reply to Martin Peres from comment #31)
> (In reply to prochazka.nicolas from comment #27)
> > Hello, 
> > any news about tools for upgrading firmware from linux host ?
> > Regards, 
> > Nicolas Prochazka
> 
> We have been working hard on this topic. We managed to get the occurrence
> rate of any LSPCON bug close to 0 through multiple fixes of the firmware and
> improvements in i915.
> 
> However, this is pointless if we cannot share the firmwares and flashing
> tools. We got a Linux flashing tool from our partner and we are now in the
> process of adapting it be included in Linux's fwupd project.
> 
> We decided to take more control on this issue because our driver's quality
> depends on it. So expect updates soon! We really want to be better at this
> and have this sort of processes ready when the products come out.

Any update on tool?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/40.