All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: airlied@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 0/4] vga: new display devices
Date: Wed, 12 Mar 2014 19:14:36 +0100	[thread overview]
Message-ID: <5320A40C.4060908@redhat.com> (raw)
In-Reply-To: <1394639220.17393.44.camel@nilsson.home.kraxel.org>

On 03/12/14 16:47, Gerd Hoffmann wrote:
>
> On Mi, 2014-03-12 at 14:55 +0100, Laszlo Ersek wrote:
>> On 03/12/14 13:55, Gerd Hoffmann wrote:
>>>   Hi,
>>>
>>> This patch series adds new display devices.
>>>
>>> Number one is secondary-vga.  That is identical to VGA (aka -vga
>>> std), except that it doesn't occupy all the legacy vga stuff
>>> (ioports, memory window @ 0xa0000), so you can have more than one of
>>> these in the system. It has one pci memory bar for the framebuffer
>>> and one mmio bar for registers.  OVMF can drive it.  Doesn't use it
>>> as console for some reason, but initializes it and the linux kernel
>>> will see it as efifb.
>>
>> My take is, due to the UEFI driver model, QemuVideoDxe is connected
>> to this secondary VGA (and so another GOP instance is created). It's
>> then probably up to GraphicsConsoleDxe to provide a SimpleTextOutput
>> on top. My guess (without looking) is that this too happens, again
>> thanks to the UEFI driver model.
>>
>> What could be amiss is likely something in ConSplitterDxe, which
>> accepts input from all consoles, and mirrors output to all of them as
>> well. Perhaps it doesn't expect multiple GOPs.
>
> Must be something else, I see this behavior with secondary-vga being
> the only display device.  It prints a single line saying something
> along the lines "display initialized", so SimpleTextOutput seems to be
> active.

OK, maybe I got some further clues; see
"OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c".

  PlatformBdsPolicyBehavior()
    PlatformBdsConnectConsole()
      DetectAndPreparePlatformPciDevicePaths()
        VisitAllPciInstances()
          VisitAllInstancesOfProtocol()
            VisitingAPciInstance()
              DetectAndPreparePlatformPciDevicePath()
    +---------->IS_PCI_VGA (Pci):
    |             "Found PCI VGA device"
    |             PreparePciVgaDevicePath()
    |               GetGopDevicePath()
    |               BdsLibUpdateConsoleVariable()
    |
The IS_PCI_VGA() macro in "MdePkg/Include/IndustryStandard/Pci22.h"
says:

> /**
>   Macro that checks whether device is a VGA-compatible controller.
>
>   @param  _p      Specified device.
>
>   @retval TRUE    Device is a VGA-compatible controller.
>   @retval FALSE   Device is not a VGA-compatible controller.
>
> **/
> #define IS_PCI_VGA(_p)                IS_CLASS3 (_p, PCI_CLASS_DISPLAY, PCI_CLASS_DISPLAY_VGA, PCI_IF_VGA_VGA)

Plus

> #define PCI_CLASS_DISPLAY             0x03
> #define   PCI_CLASS_DISPLAY_VGA         0x00
> #define     PCI_IF_VGA_VGA                0x00

In your patch 2/4 (secondary_class_init()):

> +    k->class_id = PCI_CLASS_DISPLAY_OTHER;

and from qemu's "include/hw/pci/pci_ids.h":

> #define PCI_CLASS_DISPLAY_VGA            0x0300
> #define PCI_CLASS_DISPLAY_OTHER          0x0380

I think this is the cause of the mismatch.

In vga_class_init(), PCI_CLASS_DISPLAY_VGA is used.

Note: build_pci_bus_end() [hw/i386/acpi-build.c] also seems to depend on
PCI_CLASS_DISPLAY_VGA. (Of course you could be wanting to avoid exactly
that branch, by setting the class to "other".)

In edk2, there's another relevant-looking (laxer) macro:

> /**
>   Macro that checks whether device is a display controller.
>
>   @param  _p      Specified device.
>
>   @retval TRUE    Device is a display controller.
>   @retval FALSE   Device is not a display controller.
>
> **/
> #define IS_PCI_DISPLAY(_p)            IS_CLASS1 (_p, PCI_CLASS_DISPLAY)

Does the following OVMF patch help?

> diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> index 9f953ac..33d8c5d 100644
> --- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
> @@ -593,7 +593,7 @@ DetectAndPreparePlatformPciDevicePath (
>    //
>    // Here we decide which VGA device to enable in PCI bus
>    //
> -  if (IS_PCI_VGA (Pci)) {
> +  if (IS_PCI_DISPLAY (Pci)) {
>      //
>      // Add them to ConOut.
>      //

Thanks
Laszlo

  reply	other threads:[~2014-03-12 18:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 12:55 [Qemu-devel] [PATCH 0/4] vga: new display devices Gerd Hoffmann
2014-03-12 12:55 ` [Qemu-devel] [PATCH 1/4] vga: allow non-global vmstate Gerd Hoffmann
2014-03-12 12:55 ` [Qemu-devel] [PATCH 2/4] vga: add secondary stdvga variant Gerd Hoffmann
2014-03-12 13:11   ` Eric Blake
2014-03-12 12:55 ` [Qemu-devel] [PATCH 3/4] virtio-gpu: v0.3 of the virtio based GPU code Gerd Hoffmann
2014-03-12 20:26   ` Michael S. Tsirkin
2014-03-13  9:08     ` Gerd Hoffmann
2014-03-14 11:13       ` Gerd Hoffmann
2014-03-16 12:21         ` Michael S. Tsirkin
2014-03-13 10:40     ` Paolo Bonzini
2014-03-14 11:18       ` Gerd Hoffmann
2014-03-16 12:28         ` Michael S. Tsirkin
2014-03-17  4:36       ` Dave Airlie
2014-03-17  5:21         ` Dave Airlie
2014-03-17  9:50           ` Paolo Bonzini
2014-03-17  9:27         ` Paolo Bonzini
2014-03-17 11:01         ` Michael S. Tsirkin
2014-03-12 12:55 ` [Qemu-devel] [PATCH 4/4] virtio-vga: v1 Gerd Hoffmann
2014-03-12 13:55 ` [Qemu-devel] [PATCH 0/4] vga: new display devices Laszlo Ersek
2014-03-12 15:47   ` Gerd Hoffmann
2014-03-12 18:14     ` Laszlo Ersek [this message]
2014-03-13  8:22       ` Gerd Hoffmann
2014-03-13  8:41         ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5320A40C.4060908@redhat.com \
    --to=lersek@redhat.com \
    --cc=airlied@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.