Bug 108915 - [ICL] Trying to use non-existent 6th (F) DDI port
Summary: [ICL] Trying to use non-existent 6th (F) DDI port
Status: REOPENED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium normal
Assignee: Imre Deak
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-30 17:01 UTC by Imre Deak
Modified: 2019-05-29 10:34 UTC (History)
2 users (show)

See Also:
i915 platform: ICL
i915 features: display/Other


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Imre Deak 2018-11-30 17:01:46 UTC
Some ICL SKUs support only 5 DDI ports (2 combo-PHY and 3 MG PHY) instead of the maximum of 6 ICL supports. We need a way to detect these SKUs based either on VBT or the PCI ID and prevent using the non-existent port.

SKL-Y is one such system, where this problem results in the following error whenever trying to use the non-existent port F:

<7>[   10.710403] [drm:intel_power_well_enable [i915]] enabling AUX F
<4>[   10.711756] ------------[ cut here ]------------
<4>[   10.711760] WARN_ON(intel_wait_for_register(dev_priv, regs->driver, (0x1 << ((pw_idx) * 2)), (0x1 << ((pw_idx) * 2)), 1))

One example:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5234/fi-icl-y/boot0.log
Comment 1 Lakshmi 2018-12-03 09:04:04 UTC
Is this bug duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=108070 ?
Comment 2 Jani Saarinen 2018-12-03 09:14:03 UTC
T hink no, but let Imre to confirm
Comment 3 Imre Deak 2018-12-03 11:03:40 UTC
Not a duplicate, the root cause of this is described in the description of this bug, while the root cause of the other is described at
https://bugs.freedesktop.org/show_bug.cgi?id=108070#c18
Comment 4 Lakshmi 2018-12-03 17:56:05 UTC
This issue is reported to BIOS team.
Comment 5 Jani Saarinen 2018-12-07 09:38:06 UTC
No updates yet.
Comment 6 Jani Saarinen 2018-12-20 15:37:27 UTC
Ref to WA: https://patchwork.freedesktop.org/series/54341/
Comment 7 Jani Saarinen 2019-01-31 17:13:57 UTC
Was this merged today Imre?
Comment 8 Imre Deak 2019-01-31 17:42:31 UTC
(In reply to Jani Saarinen from comment #7)
> Was this merged today Imre?

Yes,

commit 2b34e562361f6e440524272187432c551b57481e
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Dec 20 17:52:11 2018 +0200

    drm/i915/icl: Work around broken VBTs for port F detection

I think we can close this now even though for a proper solution we'll want to have the VBT fixed eventually.
Comment 9 Martin Peres 2019-03-06 18:52:43 UTC
(In reply to Imre Deak from comment #8)
> (In reply to Jani Saarinen from comment #7)
> > Was this merged today Imre?
> 
> Yes,
> 
> commit 2b34e562361f6e440524272187432c551b57481e
> Author: Imre Deak <imre.deak@intel.com>
> Date:   Thu Dec 20 17:52:11 2018 +0200
> 
>     drm/i915/icl: Work around broken VBTs for port F detection
> 
> I think we can close this now even though for a proper solution we'll want
> to have the VBT fixed eventually.

Thanks!
Comment 10 CI Bug Log 2019-03-06 18:52:50 UTC
The CI Bug Log issue associated to this bug has been archived.

New failures matching the above filters will not be associated to this bug anymore.
Comment 11 Imre Deak 2019-05-14 09:35:24 UTC
Reopening this bug.

There wasn't any update on the internal bug ticket to fix this in the ICL-Y RVP VBTs as I hoped (see HSD/1306084116). We can still fix this issue by knowing the  list of PCIIDs with 5 ports (see the open ticket at BSpec/20584), with which we can limit the ports registered by the driver at least on the SoC level (the OEM could decide to limit the actually exposed ports further, that information could only come from VBT).

Let's keep this bug open until we get the full PCIID list.
Comment 12 Lakshmi 2019-05-29 10:34:38 UTC
The problem what we see right now is with our ICL-Y RVPs, the BIOS images are not correct for these RVPs. So, this bug is for resolving the problem with the RVP.


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.