d0f7acf9eb
An x86-64 operating system built from xv6, now largely rewritten: SMP, a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF rasteriser, and a Linux-numbered syscall ABI. No history before this point -- the tree was never under version control. This commit exists so the rename that follows has something to undo to.
95 lines
3.4 KiB
C
95 lines
3.4 KiB
C
// Display controller -- the first driver to find its hardware by asking.
|
|
//
|
|
// It does not draw anything: kernel/dev/vga.c already owns the framebuffer,
|
|
// and it learned where that is from the bootloader's VBE call. What this adds
|
|
// is a second, independent answer to the same question, from the bus rather
|
|
// than from the BIOS -- and a complaint when the two disagree.
|
|
//
|
|
// That is worth more than it sounds. Three places in the kernel used to
|
|
// hardcode 0xfd000000 as the framebuffer address, and the only reason nobody
|
|
// noticed was that QEMU's stdvga happens to put it there. A disagreement
|
|
// between VBE and the card's own BAR is exactly the symptom that would have
|
|
// shown up first on hardware where the guess was wrong, and until now there
|
|
// was nothing in the kernel capable of noticing it.
|
|
|
|
#include "types.h"
|
|
#include "defs.h"
|
|
#include "param.h"
|
|
#include "x86.h"
|
|
#include "spinlock.h"
|
|
#include "sleeplock.h"
|
|
#include "fs.h"
|
|
#include "file.h"
|
|
#include "pci.h"
|
|
#include "display.h"
|
|
|
|
// The framebuffer lives in the first memory BAR big enough to hold a screen.
|
|
// Display controllers commonly expose two apertures -- the framebuffer and a
|
|
// much smaller register block -- and which index they land on varies, so the
|
|
// choice is made by size rather than by position.
|
|
static struct pci_bar *
|
|
framebuffer_bar(struct pci_dev *d)
|
|
{
|
|
uint64 need = vga_fb_size();
|
|
|
|
for (int i = 0; i < 6; i++) {
|
|
struct pci_bar *b = &d->bar[i];
|
|
if (b->base == 0 || b->is_io)
|
|
continue;
|
|
if (b->size >= need)
|
|
return b;
|
|
}
|
|
return 0;
|
|
}
|
|
|
|
static int
|
|
vga_pci_probe(struct pci_dev *d)
|
|
{
|
|
struct pci_bar *bar = framebuffer_bar(d);
|
|
uint64 vbe = vga_fb_phys();
|
|
|
|
// Memory decoding has to be on for the aperture to respond at all. The BIOS
|
|
// will have done this already to put up a boot splash, but a device we only
|
|
// reached through enumeration cannot be assumed to have been touched.
|
|
pci_enable(d, PCI_CMD_MEMORY);
|
|
|
|
if (bar == 0) {
|
|
cprintf("vga: display controller at %x:%x.%x has no framebuffer aperture\n",
|
|
d->bus, d->slot, d->func);
|
|
return 0; // still ours; nothing more to do
|
|
}
|
|
|
|
if (vbe != 0 && bar->base != vbe) {
|
|
// Trust VBE: it describes the mode that is actually programmed and being
|
|
// displayed, which is the thing vga.c is writing into. The BAR is the
|
|
// card's whole aperture and the mode may sit at an offset within it. Say
|
|
// so rather than silently preferring one.
|
|
cprintf("vga: framebuffer disagreement -- VBE says %x, BAR says %x\n",
|
|
(uint32)vbe, (uint32)bar->base);
|
|
}
|
|
|
|
cprintf("vga: display controller %x:%x, aperture %x (%d MB)\n",
|
|
d->vendor, d->device, (uint32)bar->base,
|
|
(uint32)(bar->size / (1024 * 1024)));
|
|
return 0;
|
|
}
|
|
|
|
// Matched by class, not by model: every VGA-compatible controller answers
|
|
// class 0x03, and this driver cares about none of the differences between
|
|
// them.
|
|
static const struct pci_match vga_pci_match[] = {
|
|
{ PCI_ANY, PCI_ANY, PCI_CLASS_DISPLAY, 0xFF },
|
|
{ 0, 0, 0, 0 },
|
|
};
|
|
|
|
// The display vtable lives in kernel/dev/vga.c, which owns the framebuffer;
|
|
// this file only finds the card on the bus. Publishing it here is what makes
|
|
// device_find_class(DEVCLASS_DISPLAY) return something a compositor can use.
|
|
extern const struct display_ops vga_display_ops;
|
|
|
|
const struct pci_driver vga_pci_driver = {
|
|
.name = "vga",
|
|
.match = vga_pci_match,
|
|
.ops = &vga_display_ops,
|
|
.probe = vga_pci_probe,
|
|
};
|