Bug 109112 - "*ERROR* Failed to probe lspcon" when HDMI isn't plugged before boot
Summary: "*ERROR* Failed to probe lspcon" when HDMI isn't plugged before boot
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: high normal
Assignee: Swati Sharma
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-20 07:25 UTC by Kai-Heng Feng
Modified: 2019-07-23 15:00 UTC (History)
3 users (show)

See Also:
i915 platform: CFL
i915 features: display/LSPCON


Attachments
HDMI cable plugged before boot, LSPCON works (157.15 KB, text/plain)
2018-12-20 07:26 UTC, Kai-Heng Feng
no flags Details
HDMI cable _not_ plugged before boot, LSPCON doesn't work (126.18 KB, text/plain)
2018-12-20 07:27 UTC, Kai-Heng Feng
no flags Details
i915_display_info, HDMI cable plugged before boot (5.63 KB, text/plain)
2019-01-04 03:54 UTC, Kai-Heng Feng
no flags Details
i915_display_info, HDMI cable plugged after boot (579 bytes, text/plain)
2019-01-04 03:54 UTC, Kai-Heng Feng
no flags Details
VBT info (6.00 KB, application/octet-stream)
2019-01-04 03:55 UTC, Kai-Heng Feng
no flags Details
Dmesg from drm-tip 2019-03-26 (59.05 KB, text/plain)
2019-03-27 06:24 UTC, Kai-Heng Feng
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai-Heng Feng 2018-12-20 07:25:58 UTC
Kernel vision: drm-intel-nightly, cod/tip/drm-tip/2018-12-19.

When booting the system without HDMI cable plugged, the system can never detect HDMI cable afterward.

This issue is not observed when HDMI cable is plugged before boot, LSPCON gets probed successfully in this case. HDMI hotplug also works in this case.

I tried to increase both retry count and sleep time in lspcon_probe(), but it doesn't make any difference.
Comment 1 Kai-Heng Feng 2018-12-20 07:26:59 UTC
Created attachment 142857 [details]
HDMI cable plugged before boot, LSPCON works
Comment 2 Kai-Heng Feng 2018-12-20 07:27:38 UTC
Created attachment 142858 [details]
HDMI cable _not_ plugged before boot, LSPCON doesn't work
Comment 3 Kai-Heng Feng 2018-12-20 07:29:53 UTC
I also tested Windows 10. HDMI still works when the cable wasn't plugged before boot.
Comment 4 Lakshmi 2018-12-20 20:10:53 UTC
Swati, any comments here?
Comment 5 Swati Sharma 2018-12-21 13:14:09 UTC
Hi Kai-Heng-Feng,

To re-create same test scenario can be please elaborate how you are testing?
   1. Booting with which connector attached (if not HDMI)?
   2. After booting, are you doing hot-unplug of previous connector attached and 
      hot-plug of HDMI connector?
   3. After hot-plug of HDMI cable, are you seeing any blank screen/no signal?
   4. Are you executing any test?
Comment 6 Hugh Chao 2018-12-25 03:46:35 UTC
Hi, Swati,

1. No any connector attached.
2. If HDMI cable is plugged before boot, it will always have signal no matter how you hot-unplug and hot-plug HDMI.
3. If HDMI cable isn't connected before boot, It's always blank screen when we hot-plug the cable.
4. No, just normal boot up.
Comment 7 Swati Sharma 2018-12-26 12:06:55 UTC
Thanks Hugh Chao for the info. Seeing the logs where the LSP-Con works, LSP-Con chip being used is from Parade Tech. Can you please confirm whether you are seeing this issue in MCA LSP-Con chips as-well?
Comment 8 Kai-Heng Feng 2018-12-29 16:49:34 UTC
(In reply to Swati Sharma from comment #7)
> Thanks Hugh Chao for the info. Seeing the logs where the LSP-Con works,
> LSP-Con chip being used is from Parade Tech. Can you please confirm whether
> you are seeing this issue in MCA LSP-Con chips as-well?

Is LSPCON chip swappable? The platform in question is already on the market so I am not sure it's feasible to test different LSPCON chips.
Comment 9 Swati Sharma 2019-01-02 13:39:20 UTC
It's ok. There are 2 vendors of lspcon chip-Parade and MCA.
Can you please provide following info:
1. cat /sys/kernel/debug/dri/0/i915_display_info
2. attach /sys/kernel/debug/dri/0/i915_vbt
3. are you using any external dongle/cable?
Comment 10 Kai-Heng Feng 2019-01-04 03:54:19 UTC
Created attachment 142971 [details]
i915_display_info, HDMI cable plugged before boot
Comment 11 Kai-Heng Feng 2019-01-04 03:54:50 UTC
Created attachment 142972 [details]
i915_display_info, HDMI cable plugged after boot
Comment 12 Kai-Heng Feng 2019-01-04 03:55:05 UTC
Created attachment 142973 [details]
VBT info
Comment 13 Kai-Heng Feng 2019-01-04 03:56:30 UTC
(In reply to Swati Sharma from comment #9)
> 3. are you using any external dongle/cable?
Yes, it's a mini desktop so HDMI cable is required for this setup.
Comment 14 Anthony Wong 2019-01-14 02:32:04 UTC
Any update?
Comment 15 Swati Sharma 2019-01-14 09:17:01 UTC
Hi Wong,

I tried replicating issue locally on kabylake gen9 platform, however couldn't succeed. No lspcon probe issue is observed.

Configuration provided by you and mine is:
<Swati>
connector 83: type DP-1, status: connected
DP branch device present: yes
                Type: HDMI
                ID: 175IB0
                HW: 1.2
                SW: 8.41
                Max TMDS clock: 600000 kHz
                Max bpc: 12
<Kai-Heng Feng>
connector 109: type DP-3, status: connected
	DP branch device present: yes
		Type: HDMI
		ID: 175IB0
		HW: 1.0
		SW: 7.35
		Max TMDS clock: 600000 kHz
		Max bpc: 12
Here the difference is in HW and SW f/w. I will recommend you to please update to the latest sw f/w and test again.
Since Linux F/W Flash Tool is not ready yet to update the f/w, you can update f/w by booting with windows first and using their AuxUpdate tool.

In the logs of the failed case we can see "Native AUX CH down" and after that probe issue comes.
May be in the latest s/w f/w issue would have been resolved from the parade, if this needs a h/w update (which hopefully shouldn't be the case) then nothing can be done.

So, first update the s/w f/w, test and share your observation; only then we can take further steps.
Comment 16 Lakshmi 2019-02-13 11:26:18 UTC
Kai, have you verified the issue by updating fw? Any updates here?
Comment 17 Kai-Heng Feng 2019-02-20 11:11:45 UTC
(In reply to Lakshmi from comment #16)
> Kai, have you verified the issue by updating fw? Any updates here?

The system was sent to HP and I don't know the follow-up.
Maybe Hugh can answer your question...
Comment 18 Hugh Chao 2019-02-20 11:21:43 UTC
HP is still working on it, I'll feedback if I got any news
Comment 19 Kai-Heng Feng 2019-03-27 06:22:43 UTC
Same issue happens after the LSPCON FW update.
Seems like the HW and SW info also get cleared out:
connector 111: type DP-3, status: connected
        name: 
        physical dimensions: 510x290mm
        subpixel order: Unknown
        CEA rev: 3
        DPCD rev: 12
        audio support: yes
        DP branch device present: yes
                Type: HDMI
                ID: 
                HW: 0.0
                SW: 0.0
                Max TMDS clock: 600000 kHz
                Max bpc: 12
Comment 20 Kai-Heng Feng 2019-03-27 06:24:24 UTC
Created attachment 143785 [details]
Dmesg from drm-tip 2019-03-26

Same message:
[    2.267472] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[    2.267499] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Comment 21 Kai-Heng Feng 2019-05-17 05:10:42 UTC
Any update?
Comment 22 Lakshmi 2019-05-20 07:04:05 UTC
(In reply to Kai-Heng Feng from comment #20)
> Created attachment 143785 [details]
> Dmesg from drm-tip 2019-03-26
> 
> Same message:
> [    2.267472] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> [    2.267499] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on
> port D

What is the FW version here?
Comment 23 Kai-Heng Feng 2019-05-20 07:08:06 UTC
(In reply to Lakshmi from comment #22)
> (In reply to Kai-Heng Feng from comment #20)
> > Created attachment 143785 [details]
> > Dmesg from drm-tip 2019-03-26
> > 
> > Same message:
> > [    2.267472] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> > [    2.267499] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on
> > port D
> 
> What is the FW version here?

Please refer to comment #19.
Comment 24 Kai-Heng Feng 2019-05-23 08:04:16 UTC
FWIW I don't think the lspcon firmware matters here - as Windows doesn't have this issue on the old firmware.
Comment 25 Swati Sharma 2019-05-24 06:19:50 UTC
(In reply to Hugh Chao from comment #18)
> HP is still working on it, I'll feedback if I got any news

Hi Hugh,
Can you please elaborate what HP guys did to the system? What kind of changes they made?
Comment 26 Swati Sharma 2019-05-24 06:22:36 UTC
(In reply to Kai-Heng Feng from comment #24)
> FWIW I don't think the lspcon firmware matters here - as Windows doesn't
> have this issue on the old firmware.

Correct. Give me some time to debug. Will update.
Comment 27 Hugh Chao 2019-05-24 06:53:32 UTC
(In reply to Swati Sharma from comment #25)
> (In reply to Hugh Chao from comment #18)
> > HP is still working on it, I'll feedback if I got any news
> 
> Hi Hugh,
> Can you please elaborate what HP guys did to the system? What kind of
> changes they made?

Hi Swati,

The new FW which provided by HP is not working either. But our QA leader judged that video failed after booting by hot-plug is not a blocking issue, so we lower the priority of this issue. Thanks.
Comment 28 Swati Sharma 2019-05-24 08:28:04 UTC
(In reply to Kai-Heng Feng from comment #3)
> I also tested Windows 10. HDMI still works when the cable wasn't plugged
> before boot.

Hi Kai-Heng Feng,

If we go by theory, there is no 1:1 mapping of Windows and Linux driver architecture. Design for lsp-con is different in both. In Windows, you are able to probe lsp-con because during hotplug windows drivers reinitialize all the connectors whereas in linux, connectors are initialized only once. It means during boot time, if lspcon is not probbed..we won't be able to probe it during hotplug.

Since I am not having the same setup, I can't reproduce the issue. Give me some time so that I can arrange for the setup and get back to you.
Comment 29 Swati Sharma 2019-05-24 08:29:25 UTC
(In reply to Hugh Chao from comment #27)
> (In reply to Swati Sharma from comment #25)
> > (In reply to Hugh Chao from comment #18)
> > > HP is still working on it, I'll feedback if I got any news
> > 
> > Hi Hugh,
> > Can you please elaborate what HP guys did to the system? What kind of
> > changes they made?
> 
> Hi Swati,
> 
> The new FW which provided by HP is not working either. But our QA leader
> judged that video failed after booting by hot-plug is not a blocking issue,
> so we lower the priority of this issue. Thanks.

Sure.
Comment 30 Kai-Heng Feng 2019-05-24 08:41:49 UTC
(In reply to Swati Sharma from comment #28)
> (In reply to Kai-Heng Feng from comment #3)
> > I also tested Windows 10. HDMI still works when the cable wasn't plugged
> > before boot.
> 
> Hi Kai-Heng Feng,
> 
> If we go by theory, there is no 1:1 mapping of Windows and Linux driver
> architecture. Design for lsp-con is different in both. In Windows, you are
> able to probe lsp-con because during hotplug windows drivers reinitialize
> all the connectors whereas in linux, connectors are initialized only once.
> It means during boot time, if lspcon is not probbed..we won't be able to
> probe it during hotplug.

I understand Linux and Windows driver are quite different.
My point was, whether lspcon firmware has a bug or not is moot - software alone can make it work, or at least workaround it.

> 
> Since I am not having the same setup, I can't reproduce the issue. Give me
> some time so that I can arrange for the setup and get back to you.

Sure, thanks for your effort.
Comment 31 Ville Syrjala 2019-05-24 15:20:20 UTC
I can't reproduce on a Gigabyte nuc like machine with Parade LSPCON.
OUI 00-1c-f8 dev-ID 175IB0 HW-rev 1.0 SW-rev 7.32

So probably either a firmware difference or the chip is wired up differently on the boards causing it to not respond for you until HPD gets asserted. We should probably change the lspcon code to behave more dynamically and not insist on being able to probe the chip at driver load time.
Comment 32 Kai-Heng Feng 2019-05-27 05:55:41 UTC
(In reply to Ville Syrjala from comment #31)
> I can't reproduce on a Gigabyte nuc like machine with Parade LSPCON.
> OUI 00-1c-f8 dev-ID 175IB0 HW-rev 1.0 SW-rev 7.32

AFAIK this bug doesn't happen on other desktop systems.

> 
> So probably either a firmware difference or the chip is wired up differently
> on the boards causing it to not respond for you until HPD gets asserted. We
> should probably change the lspcon code to behave more dynamically and not
> insist on being able to probe the chip at driver load time.

Ok, please just let me know when there's a patch to test.
Comment 33 Lakshmi 2019-07-19 12:07:42 UTC
@Swati, any updates here? What are the next steps?
Comment 34 shashank.sharma@intel.com 2019-07-23 12:07:20 UTC
In the motherboard down mode, LSPCON is supposed to be powered on with the power supply from the board, and hence, it was supposed to be powered-on during the driver probe time. So if it's not getting powered on during probe, this seems like a board design error, and not a SW issue. (This is probably expecting LSPCON to work in dongle mode, which we do not support in driver). That also explains why we are not able to reproduce this issue with other parade based devices.

In order to work around this issue, we can add LSPCON probing in the hot-plug sequence, but that might come up with its own hotplug stability issues, like if the I2C over Aux bus is not stable yet, that might delay the hotplug handling path by adding some retries.

Also, this is only possible when the display master IRQ is getting the HPD interrupt, but it's getting missed due to unavailability on the connector on port. But as the IRQ signal is also coming via LSPCON, which is not powered-on until hotplug, there is also a possibility of missing the hotplug all-together, in which case, moving the probe is not going to help at all.
 
- Shashank
Comment 35 Kai-Heng Feng 2019-07-23 15:00:06 UTC
(In reply to shashank.sharma@intel.com from comment #34)
> In the motherboard down mode, LSPCON is supposed to be powered on with the
> power supply from the board, and hence, it was supposed to be powered-on
> during the driver probe time. So if it's not getting powered on during
> probe, this seems like a board design error, and not a SW issue. (This is
> probably expecting LSPCON to work in dongle mode, which we do not support in
> driver). That also explains why we are not able to reproduce this issue with
> other parade based devices.

Ok we'll let vendor know about this.

> 
> In order to work around this issue, we can add LSPCON probing in the
> hot-plug sequence, but that might come up with its own hotplug stability
> issues, like if the I2C over Aux bus is not stable yet, that might delay the
> hotplug handling path by adding some retries.

We can use a DMI based quirk so other platforms won't be penalized.

> 
> Also, this is only possible when the display master IRQ is getting the HPD
> interrupt, but it's getting missed due to unavailability on the connector on
> port. But as the IRQ signal is also coming via LSPCON, which is not
> powered-on until hotplug, there is also a possibility of missing the hotplug
> all-together, in which case, moving the probe is not going to help at all.

This doesn't explain why Windows doesn't have this issue, it can reliably detect hot plugging event everytime.

>  
> - Shashank


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.