| Message ID | 1442296289.3146.8.camel@kernel.crashing.org |
|---|---|
| State | New |
| Headers | show |
On Di, 2015-09-15 at 15:51 +1000, Benjamin Herrenschmidt wrote:
> It works fine with the Linux driver out of the box
Do you actually want the vga compatibility bits on pseries?
There also is virtio-gpu-pci (same thing as virtio-vga but without vga
compatibility), which should already be enabled on ppc64.
The linux kvm driver certainly doesn't need vga compatibility.
For slof support it might be useful though, the vga compatibility bits
in virtio-vga are fully compatible to stdvga, so slof support should be
as simple as adding a PCI ID ...
cheers,
Gerd
On Tue, 2015-09-15 at 11:19 +0200, Gerd Hoffmann wrote: > On Di, 2015-09-15 at 15:51 +1000, Benjamin Herrenschmidt wrote: > > It works fine with the Linux driver out of the box > > Do you actually want the vga compatibility bits on pseries? Yes, our firmware SLOF uses them (via MMIO BARs) for the early boot stuff (well, it will use them when the patches I sent are merged). > There also is virtio-gpu-pci (same thing as virtio-vga but without > vga compatibility), which should already be enabled on ppc64. > > Thel inux kvm driver certainly doesn't need vga compatibility. > > For slof support it might be useful though, the vga compatibility > bits > in virtio-vga are fully compatible to stdvga, so slof support should > be > as simple as adding a PCI ID ... Right. Well, I first had to update SLOF to use the MMIO BARs rather than the legacy IO crap, but yes, that's pretty much what I did. > cheers, > Gerd >
On Mi, 2015-09-16 at 07:08 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2015-09-15 at 11:19 +0200, Gerd Hoffmann wrote: > > On Di, 2015-09-15 at 15:51 +1000, Benjamin Herrenschmidt wrote: > > > It works fine with the Linux driver out of the box > > > > Do you actually want the vga compatibility bits on pseries? > > Yes, our firmware SLOF uses them (via MMIO BARs) for the early boot > stuff (well, it will use them when the patches I sent are merged). Fine then, patch queued up. thanks, Gerd
On Wed, Sep 16, 2015 at 08:52:23AM +0200, Gerd Hoffmann wrote: > On Mi, 2015-09-16 at 07:08 +1000, Benjamin Herrenschmidt wrote: > > On Tue, 2015-09-15 at 11:19 +0200, Gerd Hoffmann wrote: > > > On Di, 2015-09-15 at 15:51 +1000, Benjamin Herrenschmidt wrote: > > > > It works fine with the Linux driver out of the box > > > > > > Do you actually want the vga compatibility bits on pseries? > > > > Yes, our firmware SLOF uses them (via MMIO BARs) for the early boot > > stuff (well, it will use them when the patches I sent are merged). > > Fine then, patch queued up. Just to clarify, Gerd, You've taken this through your tree and I don't need to stage it in spapr-next?
On Mi, 2015-09-30 at 15:42 +1000, David Gibson wrote: > On Wed, Sep 16, 2015 at 08:52:23AM +0200, Gerd Hoffmann wrote: > > On Mi, 2015-09-16 at 07:08 +1000, Benjamin Herrenschmidt wrote: > > > On Tue, 2015-09-15 at 11:19 +0200, Gerd Hoffmann wrote: > > > > On Di, 2015-09-15 at 15:51 +1000, Benjamin Herrenschmidt wrote: > > > > > It works fine with the Linux driver out of the box > > > > > > > > Do you actually want the vga compatibility bits on pseries? > > > > > > Yes, our firmware SLOF uses them (via MMIO BARs) for the early boot > > > stuff (well, it will use them when the patches I sent are merged). > > > > Fine then, patch queued up. > > Just to clarify, Gerd, > > You've taken this through your tree and I don't need to stage it in > spapr-next? If you prepare a spapr pull req anyway feel free to include it there. Otherwise it'll go in with my next vga pull request, it's sitting in the vga queue (it is the only patch there though ...) cheers, Gerd
On Wed, Sep 30, 2015 at 08:29:37AM +0200, Gerd Hoffmann wrote: > On Mi, 2015-09-30 at 15:42 +1000, David Gibson wrote: > > On Wed, Sep 16, 2015 at 08:52:23AM +0200, Gerd Hoffmann wrote: > > > On Mi, 2015-09-16 at 07:08 +1000, Benjamin Herrenschmidt wrote: > > > > On Tue, 2015-09-15 at 11:19 +0200, Gerd Hoffmann wrote: > > > > > On Di, 2015-09-15 at 15:51 +1000, Benjamin Herrenschmidt wrote: > > > > > > It works fine with the Linux driver out of the box > > > > > > > > > > Do you actually want the vga compatibility bits on pseries? > > > > > > > > Yes, our firmware SLOF uses them (via MMIO BARs) for the early boot > > > > stuff (well, it will use them when the patches I sent are merged). > > > > > > Fine then, patch queued up. > > > > Just to clarify, Gerd, > > > > You've taken this through your tree and I don't need to stage it in > > spapr-next? > > If you prepare a spapr pull req anyway feel free to include it there. > Otherwise it'll go in with my next vga pull request, it's sitting in the > vga queue (it is the only patch there though ...) Ok, I've pulled it into spapr-next. I'm not planning a new pull request in the immediate future, but if yours goes first, I dare say I'll catch it in the rebase and fix up.
diff --git a/default-configs/ppc64-softmmu.mak b/default-configs/ppc64-softmmu.mak index a11de08..ec3cd8b 100644 --- a/default-configs/ppc64-softmmu.mak +++ b/default-configs/ppc64-softmmu.mak @@ -3,6 +3,7 @@ include pci.mak include sound.mak include usb.mak +CONFIG_VIRTIO_VGA=y CONFIG_ISA_MMIO=y CONFIG_ESCC=y CONFIG_M48T59=y diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 4590c30..b47cacd 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -1072,6 +1072,7 @@ static int spapr_vga_init(PCIBus *pci_bus) case VGA_DEVICE: return true; case VGA_STD: + case VGA_VIRTIO: return pci_vga_init(pci_bus) != NULL; default: fprintf(stderr, "This vga model is not supported,"
It works fine with the Linux driver out of the box Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- default-configs/ppc64-softmmu.mak | 1 + hw/ppc/spapr.c | 1 + 2 files changed, 2 insertions(+)