Created attachment 130667 [details] log when HDMI and eDP are connected. HW : Intel Braswell N3000/N3710/J3710 FW : coreboot+FSP MR2 Linux drivers (latest taken from 01.org website) are not detecting connected displays correctly. The same linux with kernel option "nomodeset" boots properly... but graphics HW acceleration is not working. 1) When LFP display is connected on eDP port (port B) - all seems to work fine - display is working, graphics drive is also fine. ---> however - a second display connected on port C (HDMI) is not even detected. 2) When LFP display is not connected - HDMI is actvie at boot time, by starting from kernel driver - display is black and not active. HDMI display device is not detected. Is this a known problem ??? What's the fix ? The same HW/FW works fine with Windows 10 OS - no matter what's display configuratuion. Thanks, Marek.
(In reply to Marek Wilczewski from comment #0) > Linux drivers (latest taken from 01.org website) are not detecting connected > displays correctly. Please try a v4.11-rc kernel or drm-tip branch from https://cgit.freedesktop.org/drm/drm-tip
We already checked this source, but will also verify the latest You suggested.
We have verified suggested kernel - no change. After digging - problem is related to i915 DRM driver. This driver is using "platform default" DDC bus mappings that is valid for CRB, and unlikely usefull for many other systems. VBT configuration is not used for some reason. I've modified driver to use DDC mappings as on our platform - HDMI is detected now. Default configuration from CRB - pipe B using DDC-B will not work correctly on most systems with LFP - usually LFP will be eDP, and external display (pipe C) will be using DDC-B - such configuration is also used on another intel ref. design with Braswell. //Marek.
Hi. I am attaching patch for kernel 4.10.2 (latest on o1.org) that fixes problem on our platform. This is not a solution - rather a work-around. This information (DDC<->pipe mapping) should be taken from VBT. //Marek.
Created attachment 130895 [details] [review] patch for i915
Changing severity to normal since it is a feature with workaround now.
(In reply to Elizabeth from comment #6) > Changing severity to normal since it is a feature with workaround now. Having to patch the kernel is *not* something we should consider a workaround.
I would agree with Jani. This workaround works on our board, but it will not work on IntelCRB and likely other HW as this fix implements a HW-specific config that should be taken form VBT. As VBT is not used - also other settings present in VBT (maybe also default EDID values) may not be used.
Please attach /sys/kernel/debug/dri/0/i915_vbt
Created attachment 134524 [details] [review] drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel Please try this patch.
Presumed fixed in drm-intel-next-queued and drm-tip by commit 348e4058ebf53904e817eec7a1b25327143c2ed2 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Sep 28 11:21:57 2017 +0300 drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel It's cc: stable so it'll get backported eventually. Thanks for the report, please reopen if that doesn't help.
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.