FS#69487 - [linux] Skip vswing programming for TBT

Attached to Project: Arch Linux
Opened by François Guerraz (kubrick) - Sunday, 31 January 2021, 12:31 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 30 March 2021, 12:20 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

PCI Bus reset on display power event when Thunderbolt plugged in

The device, a Dell XPS 9300, works fine with external displays attached to the usb-c docking stations.

The Caldigit TS3 Plus docking station also works fine on its own as long as no external display is attached.

Now if I connect an external display while the Caldigit TS3 Plus docking station is connected, either via the docking station itself or another adapter, every time a "power event" happens on the external monitor (such as connecting, disconnecting, rearranging the displays on Gnome), the entire PCI bus seems to disappear with these messages in the logs:

Jan 24 22:20:07 XPS-20 kernel: pcieport 0000:00:07.0: pciehp: Slot(0): Link Down
Jan 24 22:20:07 XPS-20 kernel: pcieport 0000:00:07.0: pciehp: Slot(0): Card not present
Jan 24 22:20:07 XPS-20 kernel: pcieport 0000:02:04.0: can't change power state from D3cold to D0 (config space inaccessible)
Jan 24 22:20:07 XPS-20 kernel: igb 0000:06:00.0: removed PHC on eth0
Jan 24 22:20:07 XPS-20 kernel: igb 0000:06:00.0 eth0: PCIe link lost
Jan 24 22:20:07 XPS-20 kernel: i2c_hid i2c-WCOM4941:00: supply vdd not found, using dummy regulator
Jan 24 22:20:07 XPS-20 kernel: i2c_hid i2c-WCOM4941:00: supply vddl not found, using dummy regulator

See upstream bug for more details: https://gitlab.freedesktop.org/drm/intel/-/issues/2999

I backported this patch to 5.10.12 : https://patchwork.freedesktop.org/patch/416445/?series=86402&rev=2

And it fixes the issue. Please consider backporting it to the arch kernel. LTS is also affected.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 30 March 2021, 12:20 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed: 5.10.16.arch1-1
Comment by loqs (loqs) - Monday, 01 February 2021, 23:19 GMT
I am not seeing it in drm-intel-fixes [1] or drm-next [2] only in drm-intel-next [3].

Hopefully it will make it into drm-intel-fixes so it can make it into 5.11, if not then it will be delayed until 5.12 assuming drm-next pulls from drm-intel-next before being merged into 5.12 or intel adds it to the fixes branch for 5.12, otherwise it could be delayed until 5.13.

[1] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-fixes
[2] https://cgit.freedesktop.org/drm/drm/
[3] https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=f8c6b615b921d8a1bcd74870f9105e62b0bceff3
Comment by Mark Blakeney (bulletmark) - Tuesday, 02 February 2021, 22:42 GMT
This patch is now in drm-intel-fixes so, according to loqs, should be in 5.11.
Comment by loqs (loqs) - Tuesday, 02 February 2021, 22:52 GMT
Its next stop should be drm-fixes [1] and from there to mainline hopefully in time for 5.11.

[1] https://cgit.freedesktop.org/drm/drm/log/?h=drm-fixes
Edit:
Pull request [2]. Now pulled [3]. Should be pulled to mainline for 5.11-rc7, pull request [4].

[2] https://lore.kernel.org/dri-devel/87bld0f36b.fsf%40intel.com/
[3] https://cgit.freedesktop.org/drm/drm/commit/?h=drm-fixes&id=59854811c08cfbdf52d79231666e7c07c46ff338
[4] https://lore.kernel.org/lkml/CAPM=9twvv9LRSTW4t_Q=OLfei1DsXn-fsjO8ad3cSsZ3KeDNhQ%40mail.gmail.com/
Comment by loqs (loqs) - Saturday, 06 February 2021, 19:58 GMT Comment by Mark Blakeney (bulletmark) - Saturday, 06 February 2021, 23:32 GMT
The next 2 patches after those 7 from drm-intel-fixes are essential also (https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes&id=83404d581471775f37f85e5261ec0d09407d8bed and https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-fixes&id=882554042d138dbc6fb1a43017d0b9c3b38ee5f5. They are really the one patch and are to fix an issue with MST and the WD19TB dock which I own. I have been posting about an MST issue with this dock for months. Those are trivial patches in the same dir so I am surprised they were not included above. I applied all 9 of those yesterday morning to Arch 5.10.13 and have been running with that but it takes a few days to prove fixes with these issues.

PS, the 9 patches (actually 8 because those last 2 are combined) that I refer to are all queued for 5.11-rc7 as loqs says in link [4] above.
Comment by loqs (loqs) - Sunday, 07 February 2021, 00:05 GMT Comment by Mark Blakeney (bulletmark) - Sunday, 07 February 2021, 00:43 GMT
I actually still get issues using all those patches on 5.10.13. E.g both my displays usually fail to turn back on after power blanking. I have to disconnect/reconnect the dock to get them to recover (or sometimes reboot). I see drm link training failures in my journal and I note that very next 2 drm-intel-fixes seem to be addressing that issue as well. I tried to apply those but they require an earlier API change (from Oct 2020 but not in mainline) so I decided it was TFH. I will go back to disabling DP_MST and place my second screen on the TBT daisy chain port and I will look at this again once 5.11 comes along which should only be 2 or 3 weeks away.
Comment by loqs (loqs) - Saturday, 13 February 2021, 19:21 GMT
The TBT patch was added to 5.10.16. @kubrick is the issue resolved for you using 5.10.16?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=4e78c33874e541979383a761cf9e3de0a24c710c
Comment by François Guerraz (kubrick) - Monday, 15 February 2021, 11:56 GMT
I confirmed this is fixed in 5.10.16

Loading...