On Fri, Dec 27, 2013 at 9:05 AM, John Baldwin <j...@freebsd.org> wrote:
> While hacking on the power button support, I also started rototilling the DSDT
> generation code a bit. My initial goal was to enumerate the LPC serial ports
> (COM1 and COM2) properly via ACPI. I ended up doing the following:
> - Moved the info for the top-level PCI bus into the PCI emulation code and
> added ResourceProducer entries for the memory ranges decoded by the bus
> for memory BARs.
> - I added a framework to allow each PCI emulation driver to optionally write
> an entry into the DSDT under the \_SB_.PCI0 namespace. The LPC driver uses
> this to write a node for the LPC bus (\_SB_.PCI0.ISA).
> - I added a linker set to allow any LPC devices to write entries into the
> DSDT below the LPC node. I moved the existing block for the RTC out of
> acpi.c and into the RTC driver. I added DSDT nodes for the AT PIC,
> the 8254 ISA timer, and the LPC UART devices.
> - I also added a "SuperIO" device under the LPC node to claim "system
> resources" (as is done in real hardware). I added a linker set to allow
> various drivers to add IO or memory ranges that should be claimed by
> SuperIO and then added the extended RTC IO range and the registers used
> for ACPI power management as system resources.
> The end result is that for the stock VM created by vmrun.sh, the attimer0,
> uart0, and uart1 devices move from isa0 to acpi0. There is also a PIC
> device that would be claimed by 'device atpic' (but the stock amd64 kernel
> doesn't include that). The DSDT is also a bit more fleshed out, and also
> looks "nice" as devices are mostly laid out in the normal tree rather than
> using separate Scope() sections for each device.
> Note that I did add some helper routines for writing out DSDT lines and
> resource entries to try to simplify the code in the various DSDT handlers
> and make the code that generates DSDT lines a bit more readable (e.g. the
> implicit newlines make things more readable IMO).
> The patch is relative to the previous power button patch and is at
This looks great!
This is not related to your patch (it has always been there), but I
was trying to understand the significance of this entry:
pci_lpc_write_dsdt(): OperationRegion (P40C, PCI_Config, 0x60, 0x04)
Any idea on why this is needed/interesting?
> Assuming these are ok, the next thing I might work on is cleaning up
> the PCI INTx interrupts. They should really all be rounted to the I/O APIC
> intpins above 15 (and we should leave ISA IRQs 5, 10, and 11 alone in APIC
> mode and only fall back to that if we are using the 8259As and a real ELCR).
> The MP Table output would need some minor tweaking for that, and for ACPI we
> should generate a _PRT table under _SB_.PCI0 in pci_emul.c.
> John Baldwin
> email@example.com mailing list
> To unsubscribe, send any mail to
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to