From owner-cvs-all@FreeBSD.ORG Thu Sep 18 07:28:32 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9178C16A4B3 for ; Thu, 18 Sep 2003 07:28:32 -0700 (PDT) Received: from mail.speakeasy.net (mail9.speakeasy.net [216.254.0.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABA4343F85 for ; Thu, 18 Sep 2003 07:28:29 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23196 invoked from network); 18 Sep 2003 14:28:28 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 18 Sep 2003 14:28:28 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h8IESN6Y087798; Thu, 18 Sep 2003 10:28:23 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030918.221415.26537897.iwasaki@jp.FreeBSD.org> Date: Thu, 18 Sep 2003 10:28:26 -0400 (EDT) From: John Baldwin To: Mitsuru IWASAKI X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: dfr@nlsystems.com cc: cvs-all@FreeBSD.org cc: iwasaki@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/acpica acpi_pci.c src/sys/dev/pci pci.c pci_private.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2003 14:28:32 -0000 On 18-Sep-2003 Mitsuru IWASAKI wrote: > 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 It should probably stay as it is for now until $PIR gains real suspend/resume support. My real concern is that if the routing changes for some reason, then the interrupt handlers won't be pointed at the right place and your system will go haywire in that case. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/