Re: [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" <
> [e-mail]> 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/[e-mail]/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
>
> 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