<div dir="ltr">Hello Joshua,<div><br></div><div>Now, I am confused even more... Since you gave me the precise answers, which I (by experience) assumed. And [1] was a lacmus. I wanted to test and see, what the proper solution will be for [1]. And... After reading your answers, I had a vision (I am very proud of this, UN-mistakable 6th sense, and sometimes I see beyond Reality/see dead people, God's Gift). So, suddenly in my brain, the dead lock was created about this particular topic.</div><div><br></div><div>So I engaged my personal intel(ligence) to find more about you, to unlock this virtual dead lock. I'll apologise in advance to reveal these data, but, in my defence, I should say that these all data about you are (after all) public.</div><div><br></div><div>So I found the following about you:</div><div><a href="https://www.linkedin.com/in/joshua-pincus-077a07">https://www.linkedin.com/in/joshua-pincus-077a07</a><br></div><div><br></div><div>It it very well done description of yourself. And, YES, it solves some mysteries, but creates some more (very deep problems inside business hierarchy). And here we are! ;-)</div><div><br></div><div>[A] You are employed by Wind River. Good. Isn't it that INTEL (in Y2012, if I am not mistaken) purchased Wind River? Isn't it that Wind River is 100% owned by INTEL???</div><div>[B] If is it so, WHY you contacted this Open Source list, in the first place, about problem [1], since you are (by all means) INTEL insider??? You are using BDW INTEL Core 5 CPU, so you are (after all) INTEL, so you should internally submit ticket to INTEL VPG?</div><div>[C] INTEL VPG (GFX) Group had this problem with HSW (do NOT ask how do I know, this is an aksioma at this point), exact the same, HYP 1 problem... So asking internally them, they'll reveal to you immediately the correct solution?</div><div><br></div><div>What is going on here??? Some weird, completely out of control, beyond any logical reality stuff??? Are you, Wind River, at all cooperating with your mother company called INTEL?! Don't you??? :bang:</div><div><br></div><div>Zoran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 12, 2017 at 2:26 PM, Joshua Pincus <span dir="ltr"><<a href="mailto:joshua.pincus@gmail.com" target="_blank">joshua.pincus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Zoran,</p><span class="">
<p dir="ltr">Please see my inline response below.</p>
</span><span class=""><p dir="ltr">On May 12, 2017 8:13 AM, "Zoran Stojsavljevic" <<a href="mailto:zoran.stojsavljevic@gmail.com" target="_blank">zoran.stojsavljevic@gmail.com</a><wbr>> wrote:<br>
><br>
> Hello Joshua,<br>
><br>
> You managed to confuse me, on the very high level.Why, you'll ask?<br>
><br>
> [1] I have no idea if you ever were able to solve the following issue: <a href="https://www.mail-archive.com/coreboot@coreboot.org/msg48827.html" target="_blank">https://www.mail-<wbr>archive.com/coreboot@coreboot.<wbr>org/msg48827.html</a> And did you, after all (and what was the solution, if not secret)?</p>
</span><p dir="ltr">[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.</p><span class="">
<p dir="ltr">> [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???</p>
</span><p dir="ltr">[JP] Sorry.  Here is the stack: Win10 guest running Intel HD graphics Gen8 driver for video and audio on top of type 1 Hypervisor.  </p>
<p dir="ltr">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.</p><span class="im HOEnZb">
<p dir="ltr">><br>
> Any answer would be greatly appreciated.  </p>
</span><span class="HOEnZb"><font color="#888888"><p dir="ltr">JP</p></font></span><div class="HOEnZb"><div class="h5">
<p dir="ltr">>  <br>
><br>
> Thanks,<br>
><br>
> ZS<br>
><br>
><br>
> On Thu, May 11, 2017 at 10:43 PM, Joshua Pincus <<a href="mailto:joshua.pincus@gmail.com" target="_blank">joshua.pincus@gmail.com</a>> wrote:<br>
>><br>
>> Hey Folks,<br>
>><br>
>><br>
>> 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:<br>
>><br>
>><br>
>> 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. <br>
>><br>
>>  <br>
>><br>
>> 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. <br>
>><br>
>>  <br>
>><br>
>> 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.<br>
>><br>
>>  <br>
>><br>
>> Any help would be greatly appreciated.  <br>
>><br>
>>  <br>
>><br>
>> Thanks,<br>
>><br>
>> JP<br>
>><br>
>><br>
>> --<br>
>> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
>> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
><br>
><br>
</p>
</div></div></blockquote></div><br></div>