[coreboot] Help with i915

Joshua Pincus joshua.pincus at gmail.com
Fri May 12 14:26:57 CEST 2017


Hi Zoran,

Please see my inline response below.

On May 12, 2017 8:13 AM, "Zoran Stojsavljevic" <
zoran.stojsavljevic at gmail.com> wrote:
>
> Hello Joshua,
>
> You managed to confuse me, on the very high level.Why, you'll ask?
>
> [1] I have no idea if you ever were able to solve the following issue:
https://www.mail-archive.com/coreboot@coreboot.org/msg48827.html And did
you, after all (and what was the solution, if not secret)?

[JP] We did solve it.  I am sorry I did not post the solution earlier.  The
problem was that the video BIOS was not executing the initialization
routines on a guest VM reboot.  Consequently, the guest would reboot
without any of the HD graphics registers being re-initialized as they would
on a cold boot.  The solution was to extract the video BIOS from the boot
ROM and re-execute the image after the FLR.

> [2] It seems that you in your original email imply that Linux GFX driver
i915 is used in WIN10 too? Or Linux is actually host, and WIN10 is a VM on
the top of some (which one?) HYP type 2? Or maybe, HYP is type 1? Really,
what is the true OS configuration stack in your case???

[JP] Sorry.  Here is the stack: Win10 guest running Intel HD graphics Gen8
driver for video and audio on top of type 1 Hypervisor.

I am looking at the i915 drm driver for insipiration as well as the VBT
data.  So far, I am not seeing anything in the VBT that describes the audio
capabilities of the DisplayPort connected monitor.  This is all very
puzzling.

>
> Any answer would be greatly appreciated.

JP

>
>
> Thanks,
>
> ZS
>
>
> On Thu, May 11, 2017 at 10:43 PM, Joshua Pincus <joshua.pincus at gmail.com>
wrote:
>>
>> Hey Folks,
>>
>>
>> I've been smacking my head against the wall for 2 weeks.  I can't smack
it anymore.  There's not much brain left at this point.  Here's my issue:
>>
>>
>> I have a Broadwell system with HD Video/Audio support.  When Windows 10
runs native (without a Hypervisor), Windows correctly finds the DisplayPort
adapter and correctly probes whatever it is that it needs to probe to
determine that the adapter in question supports both audio and video
output.  When Windows 10 is executed as a guest on top of a Hypervisor, it
correctly finds both the video device @ 0/2/0 and the audio device @ 0/3/0
but it is unable to detect that the DisplayPort supports audio.
>>
>>
>>
>> I can confirm that both the Intel drivers for video and audio correctly
attach and seem to be running perfectly inside the guest VM.  All of the
PCI BARs associated with both devices are correctly being mapped to the
Windows 10 guest.  It is my guess that Windows is looking at something
other than the EDID extracted from the attached monitor or the MMIO BAR for
the PCI audio or video devices to determine that audio is supported by the
attached hardware.  Indeed, if I probe the EDID information from the guest,
I see that the attached monitor supports audio.
>>
>>
>>
>> My question is this: Is there something else other than the PCI BARs
associated with the onboard HD graphics and HD audio devices that are
required for a Windows or a Linux guest to detect the physical presence of
audio hardware associated with an attached monitor via HDMI or DP?  Is
there an MCH or PCH register?  My guess is that I am not mapping ALL of the
BARs or IO ports into the guest to allow Windows to probe the hardware
properly.  Something is missing.  I can’t figure out what that something is.
>>
>>
>>
>> Any help would be greatly appreciated.
>>
>>
>>
>> Thanks,
>>
>> JP
>>
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170512/5bbd56b6/attachment.html>


More information about the coreboot mailing list