[coreboot] Help with i915

[Joshua Pincus]

Hi Nico,

Please see my inline response below.

On Thu, May 11, 2017 at 4:57 PM, Nico Huber <nico.h at gmx.de> wrote:

> On 11.05.2017 22:43, 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.
>
> Generally, I'd check what Linux does. Since it's open source, it's much
> easier to spot the difference between running natively and running as a
> guest. If it doesn't work in a Linux guest you can try to find the first
> thing that goes wrong in the i915 driver (booting with drm.debug=0x6
> could already give some hints in the kernel log).
>
>
[JP] Good idea.  I've looked at the FreeBSD and Linux implementations.
It's very hard to follow what's going on, but the code has given me some
hints.  Your suggestion of trying to run Linux as a VM and seeing if it
similarly barfs trying to talk to the audio device is a great idea.  As I
said, I haven't got much brain left from smacking my head, hence I would
have done that already!  The code, I think, relies very much on the
extracted EDID, whereas I'm fairly sure that Windows ignores the EDID for
the purposes of tracking audio support.


> >
> >
> >
> > 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.
>
> Probably something in the VBT (Video BIOS Table). It's a configuration
> structure for Intel video drivers used to pass information from the
> firmware to the OS. In your case the hypervisor might have to pass the
> VBT (or not hide the original). Just a guess.
>
>
[JP] That's a great idea.  I'll take a look.  Your reference to the VBT
helped me find
this: https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html.  Can you
think of any
other useful resources I should tap?


> Hope that helps,
> Nico
>
>
[JP] This definitely helps.  I really appreciate it.

JP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170511/23e92a2b/attachment.html>