Hi,
Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a regression on Linux 4.9 where the VGA output is shown all-white.
This is a regression caused by:
commit 0ce140d45a8398b501934ac289aef0eb7f47c596 Author: Ville Syrjälä ville.syrjala@linux.intel.com Date: Tue Oct 11 20:52:47 2016 +0300
drm/i915: Clean up DDI DDC/AUX CH sanitation
On these platforms, the VGA output is detected as DP (presumably theres a DP-to-VGA converter on the motherboard). The sanitization done by the code that was removed here was correctly realising that port E's DP aux channel was DP_AUX_A, so it disabled DP output on port A, also showing this message:
[drm:intel_ddi_init] VBT says port A is not DVI/HDMI/DP compatible, respect it
But after this cleanup commit, both port A and port E are activated and the screen shows all-white. Reverting the commit restores usable VGA display output.
The reason the new implementation doesn't catch the duplicate configuration is because the new code only considers ports that are present in the VBT where parse_ddi_port() has run on them (in order to set that port's info->alternate_aux_channel).
In this case, port A is not present in the VBT so it will not have info->alternate_aux_channel set, and the new sanitize_aux_ch will run on port E but will not consider any overlap with port A.
debug logs from an affected kernel: https://gist.github.com/dsd/7e56c9bca7b2345b678cfacdab30ec55
Should we modify sanitize_aux_ch to look at all aux channels, not only for the ports specified in the VBT?
Thanks Daniel
On Thu, May 04, 2017 at 02:21:26PM -0600, Daniel Drake wrote:
Hi,
Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a regression on Linux 4.9 where the VGA output is shown all-white.
This is a regression caused by:
commit 0ce140d45a8398b501934ac289aef0eb7f47c596 Author: Ville Syrjälä ville.syrjala@linux.intel.com Date: Tue Oct 11 20:52:47 2016 +0300
drm/i915: Clean up DDI DDC/AUX CH sanitationOn these platforms, the VGA output is detected as DP (presumably theres a DP-to-VGA converter on the motherboard). The sanitization done by the code that was removed here was correctly realising that port E's DP aux channel was DP_AUX_A, so it disabled DP output on port A, also showing this message:
[drm:intel_ddi_init] VBT says port A is not DVI/HDMI/DP compatible, respect it
But after this cleanup commit, both port A and port E are activated and the screen shows all-white. Reverting the commit restores usable VGA display output.
The reason the new implementation doesn't catch the duplicate configuration is because the new code only considers ports that are present in the VBT where parse_ddi_port() has run on them (in order to set that port's info->alternate_aux_channel).
In this case, port A is not present in the VBT so it will not have info->alternate_aux_channel set, and the new sanitize_aux_ch will run on port E but will not consider any overlap with port A.
debug logs from an affected kernel: https://gist.github.com/dsd/7e56c9bca7b2345b678cfacdab30ec55
Should we modify sanitize_aux_ch to look at all aux channels, not only for the ports specified in the VBT?
Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") fixes things for you.
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference when there is no VBT at all at which point we would see this message in the logs:
DRM_INFO("Failed to find VBIOS tables (VBT)\n");
but in this case we have a VBT for ports B, C and E.
[drm:intel_bios_init [i915]] Port B VBT info: DP:1 HDMI:1 DVI:1 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port B: 8 [drm:intel_bios_init [i915]] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port C: 8 [drm:intel_bios_init [i915]] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port E: 0
Let me know if I'm missing something and we will test it anyway
Thanks Daniel
On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference when there is no VBT at all at which point we would see this message in the logs:
DRM_INFO("Failed to find VBIOS tables (VBT)\n");but in this case we have a VBT for ports B, C and E.
[drm:intel_bios_init [i915]] Port B VBT info: DP:1 HDMI:1 DVI:1 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port B: 8 [drm:intel_bios_init [i915]] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port C: 8 [drm:intel_bios_init [i915]] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port E: 0
Let me know if I'm missing something and we will test it anyway
I think now without the "Split out defaults that are set when there is no VBT" patch, what happens is it enables DP on PORTA by default and then since there is a DP-VGA adapter on Port E it also enables DP on Port E and since both of these ports use the same AUX channel, it causes the AUX CH sanitization issues. Atleast that's my guess at triage.
So after the correct VBT parsing, it should actually not enable any AUX transactions on Port A and detect that no child devices connected to Port A. So the AUX CH should only be used for Port E and VGA output should work fine.
Manasi
Thanks Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference when there is no VBT at all at which point we would see this message in the logs:
DRM_INFO("Failed to find VBIOS tables (VBT)\n");
No, the patch will in fact make a difference only when there is a VBT.
but in this case we have a VBT for ports B, C and E.
[drm:intel_bios_init [i915]] Port B VBT info: DP:1 HDMI:1 DVI:1 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port B: 8 [drm:intel_bios_init [i915]] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port C: 8 [drm:intel_bios_init [i915]] Port E VBT info: DP:1 HDMI:0 DVI:0 EDP:0 CRT:0 [drm:intel_bios_init [i915]] VBT HDMI level shift for port E: 0
Let me know if I'm missing something and we will test it anyway
Please do.
On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference when there is no VBT at all at which point we would see this message in the logs:
DRM_INFO("Failed to find VBIOS tables (VBT)\n");No, the patch will in fact make a difference only when there is a VBT.
We confirmed the mentioned patch fixes the issue. Apologies for doubting you :)
Thanks! Daniel
On Wed, 24 May 2017, Daniel Drake drake@endlessm.com wrote:
On Fri, May 5, 2017 at 4:29 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Thu, May 04, 2017 at 02:52:09PM -0600, Daniel Drake wrote:
On Thu, May 4, 2017 at 2:37 PM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
Please check if commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") fixes things for you.
I think this is not going to help. This would only make a difference when there is no VBT at all at which point we would see this message in the logs:
DRM_INFO("Failed to find VBIOS tables (VBT)\n");No, the patch will in fact make a difference only when there is a VBT.
We confirmed the mentioned patch fixes the issue. Apologies for doubting you :)
Thanks for the follow-up, I made a stable backport request [1] of the relevant commits to v4.9+.
BR, Jani.
[1] http://mid.mail-archive.com/87bmqfn9sp.fsf@intel.com
On Thu, 04 May 2017, Daniel Drake drake@endlessm.com wrote:
Hi,
Numerous Asus desktops and All-in-one computers (e.g. D520MT) have a regression on Linux 4.9 where the VGA output is shown all-white.
Would you mind filing a bug over at [1], essentially with this message copy-pasted and the dmesg attached to the bug please?
Thanks, Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Int...
This is a regression caused by:
commit 0ce140d45a8398b501934ac289aef0eb7f47c596 Author: Ville Syrjälä ville.syrjala@linux.intel.com Date: Tue Oct 11 20:52:47 2016 +0300
drm/i915: Clean up DDI DDC/AUX CH sanitationOn these platforms, the VGA output is detected as DP (presumably theres a DP-to-VGA converter on the motherboard). The sanitization done by the code that was removed here was correctly realising that port E's DP aux channel was DP_AUX_A, so it disabled DP output on port A, also showing this message:
[drm:intel_ddi_init] VBT says port A is not DVI/HDMI/DP compatible, respect it
But after this cleanup commit, both port A and port E are activated and the screen shows all-white. Reverting the commit restores usable VGA display output.
The reason the new implementation doesn't catch the duplicate configuration is because the new code only considers ports that are present in the VBT where parse_ddi_port() has run on them (in order to set that port's info->alternate_aux_channel).
In this case, port A is not present in the VBT so it will not have info->alternate_aux_channel set, and the new sanitize_aux_ch will run on port E but will not consider any overlap with port A.
debug logs from an affected kernel: https://gist.github.com/dsd/7e56c9bca7b2345b678cfacdab30ec55
Should we modify sanitize_aux_ch to look at all aux channels, not only for the ports specified in the VBT?
Thanks Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Daniel Drake -
Jani Nikula -
Manasi Navare -
Ville Syrjälä