cvs commit: src/sys/dev/acpica acpi_pci.c src/sys/dev/pci pci.c pci_private.h

Mitsuru IWASAKI iwasaki at
Thu Sep 18 06:14:37 PDT 2003

Hi, John!

> On 17-Sep-2003 Doug Rabson wrote:
> > On Wed, 2003-09-17 at 15:58, John Baldwin wrote:
> >> On 17-Sep-2003 Mitsuru IWASAKI wrote:
> >> The values in memory should still be the same, so it should be sufficient
> >> simply to write back the already existent intline value back to the
> >> register.  IOW, you shouldn't hae to call PCI_ASSIGN_INTERRUPT(), but
> >> should do something more like:
> >> 
> >>         if (cfg->intpin > 0 && PCI_INTERRUPT_VALID(cfg->intline))
> >>                 pci_write_config(child, PCIR_INTLINE, cfg->intline, 1);
> >> 
> >> Eventually pci_suspend/resume should be saving and restoring all of the
> >> header registers and known capability registers for child devices.
> > 
> > How will this re-establish irq routing? The intline register is just
> > informative - don't you have to re-program the host chipset via acpi or
> > pcibios?
> For the APIC case, there is no programming, it's hardwired on the board.
> For actual link devices, I'm inclined to think that they should have their
> own suspend/resume methods at the device level for each link device.
> This means that the $PIR code would have to be smarter and use link devices
> like the ACPI code does though.

I thought that acpi_pci_link_resume() restore the PRT entries for ACPI
enabled system, but for non-ACPI system we need some sort of PCI
suspend/resume methods as John suggested.  Yes, my pci_resume code is
not smart at all :), but it's enough for my purpose as the first
implementation.  Please feel free to re-write the code if you
get chance.


More information about the cvs-src mailing list