cvs commit: src/sys/dev/acpica acpi_pci.c src/sys/dev/pci
pci.c pci_private.h
Mitsuru IWASAKI
iwasaki at jp.FreeBSD.org
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.
Thanks
More information about the cvs-src
mailing list