[coreboot] Help with i915

[Nico Huber]

On 12.05.2017 14:26, Joshua Pincus wrote:
> 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.

VBT was just a random guess, I wouldn't know why Intel would put some-
thing related there. But it's Intel, you never know. Now that I've
looked at some VBT binary description files, I don't see anything ei-
ther. So that might be a dead end.

Nico

> 
>>
>> 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
>>
>>
> 
> 
>