A program that wants to make a sound opens /dev/dsp, writes PCM, and closes
it. That is what UNIX audio has always been and it now exists here:
tone 440 2
Three pieces, in the order a sample passes through them. **/dev/dsp** is a
character device where write() is audio and a handful of OSS ioctls say what
the samples are. **AudioEngine** is everything above a driver that is not
specific to a chip -- the format, whether there is room, and what a write does
when there is not. **A driver** is bound by class, exactly as a display driver
is: device_find_class(DEVCLASS_AUDIO).
OSS numbering rather than something new, because every UNIX audio program ever
written already knows it and the only thing a different set would achieve is
making ports harder. They are read/write ioctls, which is the part that
matters: a program asks for 44100, the device sets 48000 and writes 48000
back, the program resamples. One that ignores the answer plays 9% fast, and
that is its bug rather than the driver's.
**The engine is deliberately one stream.** Mixing several programs is a real
feature with a real design behind it, and building it before anything had
played a single sound would be exactly what docs/plan/1.0.md keeps a register
for: work that exists and is connected to nothing. The second program that
wants to play at the same time is what should cause it to be written.
**audio_wait() sleeps on the timer tick, not on the device.** That looks like
the lazy choice and is not: a ring that drains is a ring with room, so asking
again in ten milliseconds always makes progress, whereas sleeping on the card
makes audio depend on an interrupt arriving. On a machine whose line is
misrouted that is not a stutter, it is a writer that never wakes. The handler
still accounts for finished buffers -- deleting it would cost efficiency, not
correctness -- and it retires descriptors through the same `tail` pointer
queue() uses, so the two cannot disagree about what is in flight.
**AC'97 first because HDA is two unproven things at once.** It is the simplest
audio device that exists on real machines and in QEMU both. Intel HDA is what
the laptop actually has and is a much larger driver; writing it against an
interface nothing had ever played through would have meant debugging the
driver and the interface simultaneously. HDA arrives as a second
struct audio_ops and nothing above it changes -- which is the entire point of
the class.
Two things the wiring needed: PCI class 0x04 now maps to DEVCLASS_AUDIO (the
driver bound and /proc/devices showed it, but audio_get() found nothing,
because the class byte had never been translated), and include/x86.h grew
inw() -- AC'97's mixer is all 16-bit registers and reading one a byte at a
time returns the low half twice on some codecs.
**Tested by measuring what came out, not by not crashing.** QEMU's wav backend
writes the guest's audio to a file; `tone 440 2` produced 1.97 seconds of
44.1 kHz stereo with peak amplitude 14177 against the generator's table
maximum of 14178, and 880 zero crossings per second -- 440 Hz exactly. wav is
on every QEMU target rather than a host backend, because a build machine may
have no sound card and it is the only backend whose output can be checked.
Both supported configurations: one boot each, no traps, no panics, socktest
and memfdtest green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
123 lines
4.7 KiB
C
123 lines
4.7 KiB
C
// The driver registry.
|
|
//
|
|
// One table, one line per driver. This is the same shape as
|
|
// kernel/sys/table.inc and kernel/dev/cdev.c's devsw: a single place that
|
|
// lists what exists, so a driver cannot be half-registered.
|
|
//
|
|
// It is a plain array rather than the linker-section trick a bigger kernel
|
|
// would use (a __attribute__((section(".drivers"))) entry per driver, walked
|
|
// between __start_ and __stop_ symbols). That approach lets a driver register
|
|
// itself by existing, which is genuinely nicer -- but it also means the list
|
|
// of what is in your kernel is not written down anywhere you can read, and
|
|
// a driver silently dropped by the linker looks exactly like one that was
|
|
// never written. At this size, being able to read the list wins.
|
|
//
|
|
// To add a driver: write kernel/drivers/<name>.c exporting a struct
|
|
// pci_driver, declare it here, and add it to the array and to the Makefile's
|
|
// KERN_DRIVERS.
|
|
|
|
#include "types.h"
|
|
#include "defs.h"
|
|
#include "param.h"
|
|
#include "spinlock.h"
|
|
#include "sleeplock.h"
|
|
#include "fs.h"
|
|
#include "file.h"
|
|
#include "pci.h"
|
|
|
|
#include "usb.h"
|
|
#include "device.h"
|
|
|
|
extern const struct pci_driver vga_pci_driver;
|
|
extern const struct pci_driver xhci_driver;
|
|
extern const struct pci_driver virtio_gpu_driver;
|
|
extern const struct pci_driver e1000_driver;
|
|
extern const struct pci_driver ac97_driver;
|
|
|
|
// Order matters here in one respect: virtio-gpu is offered the bus before the
|
|
// VBE framebuffer driver, so that on a machine with both, the device with real
|
|
// mode setting and an explicit flush wins the display class. vga_pci still
|
|
// claims the stdvga card underneath, which is what the boot splash and the
|
|
// text console are drawn on.
|
|
static const struct pci_driver *drivers[] = {
|
|
&virtio_gpu_driver,
|
|
&vga_pci_driver,
|
|
&e1000_driver,
|
|
&xhci_driver,
|
|
&ac97_driver,
|
|
};
|
|
|
|
void
|
|
pci_bind_all(void)
|
|
{
|
|
for (unsigned i = 0; i < sizeof(drivers) / sizeof(drivers[0]); i++)
|
|
pci_bind(drivers[i]);
|
|
}
|
|
|
|
// USB class drivers, same arrangement and for the same reason. These are not
|
|
// found on the PCI bus -- they are offered a device by the USB core once its
|
|
// interface descriptor has been read -- but a driver you cannot find in a
|
|
// list is a driver nobody knows is there, whichever bus it sits on.
|
|
//
|
|
// To add one: write kernel/drivers/usb_<name>.c exporting a struct
|
|
// usb_driver, declare it here, add it to the array and to KERN_DRIVERS.
|
|
|
|
extern const struct usb_driver usb_hid_driver;
|
|
extern const struct usb_driver usb_storage_driver;
|
|
extern const struct usb_driver usb_hub_driver;
|
|
|
|
static const struct usb_driver *usb_drivers[] = {
|
|
&usb_hid_driver,
|
|
&usb_storage_driver,
|
|
&usb_hub_driver,
|
|
};
|
|
|
|
int usb_offer(const struct usb_driver *, struct usb_dev *);
|
|
|
|
void
|
|
usb_bind_all(struct usb_dev *dev)
|
|
{
|
|
for (unsigned i = 0; i < sizeof(usb_drivers) / sizeof(usb_drivers[0]); i++)
|
|
if (usb_offer(usb_drivers[i], dev)) {
|
|
// Same as the PCI path: publish it in the bus-agnostic list so that
|
|
// "what is attached" has one answer covering every bus. Class comes from
|
|
// the driver that claimed it rather than the USB class code, because a
|
|
// driver knows what it made of the device and the descriptor only says
|
|
// what the device claims to be.
|
|
const char *n = usb_drivers[i]->name;
|
|
struct device *d = device_add(n, DEVBUS_USB, usb_drivers[i]->devclass, n);
|
|
if (d)
|
|
device_set_desc(d, usb_drivers[i]->name);
|
|
return;
|
|
}
|
|
}
|
|
|
|
// Devices that are not enumerated by any bus -- they are simply known to be
|
|
// there on a PC, and the driver pokes fixed I/O ports to find out whether it
|
|
// is right. Listing them matters because a device manager that shows the
|
|
// graphics card but not the keyboard is not showing the machine.
|
|
//
|
|
// Registered here rather than inside each driver's init so that the whole set
|
|
// is visible in one place, which is the same reasoning as the driver arrays
|
|
// above.
|
|
void
|
|
platform_register_devices(uint64 fb_addr)
|
|
{
|
|
struct device *d;
|
|
|
|
// The framebuffer first, before anything that might want to draw. It is a
|
|
// driver call, and this file is where driver names belong -- main() used to
|
|
// call vga_init() directly, which put one display driver's name in the
|
|
// kernel's startup path and would have needed editing to boot on a machine
|
|
// whose framebuffer came from anywhere else.
|
|
vga_fb_init(fb_addr);
|
|
|
|
if ((d = device_add("kbd", DEVBUS_PLATFORM, DEVCLASS_INPUT, "ps2kbd")))
|
|
device_set_desc(d, "PS/2 keyboard");
|
|
if ((d = device_add("mouse", DEVBUS_PLATFORM, DEVCLASS_INPUT, "ps2mouse")))
|
|
device_set_desc(d, "PS/2 mouse");
|
|
if ((d = device_add("uart", DEVBUS_PLATFORM, DEVCLASS_OTHER, "uart8250")))
|
|
device_set_desc(d, "16550 serial port");
|
|
if ((d = device_add("ide", DEVBUS_PLATFORM, DEVCLASS_STORAGE, "ide")))
|
|
device_set_desc(d, "ATA disk controller");
|
|
}
|