From owner-freebsd-current@FreeBSD.ORG Wed Jun 4 03:51:28 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C85FE37B401 for ; Wed, 4 Jun 2003 03:51:28 -0700 (PDT) Received: from effinger.cisra.com.au (effinger.cisra.com.au [203.12.173.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8198243F75 for ; Wed, 4 Jun 2003 03:51:27 -0700 (PDT) (envelope-from iain.templeton@cisra.canon.com.au) Received: from ivory.research.canon.com.au (edge-aide.cisra.com.au [203.12.173.254]) by effinger.cisra.com.au (Postfix) with ESMTP id D62D45B957; Wed, 4 Jun 2003 08:54:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ivory.research.canon.com.au (Postfix) with ESMTP id B35445683; Wed, 4 Jun 2003 18:54:22 +1000 (EST) Received: from ivory.research.canon.com.au ([127.0.0.1])port 10024) with ESMTP id 52045-05; Wed, 4 Jun 2003 18:54:22 +1000 (EST) Received: from blow.research.canon.com.au (blow.research.canon.com.au [10.8.1.4]) by ivory.research.canon.com.au (Postfix) with ESMTP id 5FE7C5685; Wed, 4 Jun 2003 18:54:09 +1000 (EST) Received: from research.canon.com.au (ziloti.research.canon.com.au [10.8.1.23]) by blow.research.canon.com.au (Postfix) with SMTP id A4BE398E7E; Wed, 4 Jun 2003 04:53:48 -0400 (EDT) X-Mailer: Ishtek MeeMail 2.62 Date: Wed, 04 Jun 2003 18:53:38 +1000 From: Iain Templeton To: freebsd-current@freebsd.org, acpi-jp@jp.FreeBSD.org Message-Id: <20030604085348.A4BE398E7E@blow.research.canon.com.au> cc: "Remington L." Subject: ACPI and PCI vs interrupt routing on Sony VAIO's X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 10:51:29 -0000 Hi, I have a Sony VAIO (PCG-R505TFP) which has an interrupts related problem (this problem was previous posted elsewhere as "Weird as* sound problem"). This problem has been confirmed on at least one other Sony VAIO model (I forget which). They're both Intel i830M chipset based. Basically, the LNKB interrupt configuration register is not being initialised, so the interrupt never gets routed, and so the interrupt never gets to the CPU. Result: Sound doesn't work. A really hacky solution to this is to run the command: pciconf -w -b pci0:31:0 0x61 9 which sets the i830's PCI routing register for LNKB to IRQ 9. I did a bit of digging and found the following bits of information: 1. When the ACPI PCI bus starts up, it calls all the LNKx.CRS methods to get the current resources. LNKB (amongst others) returns 0. 2. The PCI configuration space register for IRQ contains the value 9. 3. If somebody calls the LNKB.SRS method, it would all work because that writes the PCI interrupt routing register thingy like pciconf does above. But the acpi_pcib_route_interrupt() function is not being called because in pci_alloc_resource() there is a test that checks if the PCI config space register that contains the interrupt contains a valid number (which it does - 9). So, basically I think there is something wrong here, which I think is that ACPI and the generic PCI code (in pci_alloc_resource()) don't agree when it comes to interrupt management. Other than saying "the BIOS is broken" (which it is, providing mislead information and all), is it a fair statement to say that the ACPI CRS method should be trusted more than the PCI configuration space registers? If so, then if the PCI conf space register disagrees with the ACPI result, should the PCI conf space register be updated to show what the ACPI stuff shows? I'm happy to muddle up a patch that might do this, but I was hoping for a bit of a guide as to how to do it. I thought initially that I could update the PCI config space register at the time the LNKs CRS method was called, but quickly gave up on that because I don't know which device to update... Could I instead perhaps implement the pci_alloc_resource() method in acpi_pcib_pci.c which inspects the existing PCI configuration and the ACPI LNK information and if they differ, put the ACPI value into the PCI configuration register, then call the pci_alloc_resource() function to finish off. Then pci_alloc_resource() will see a bad value for the PCI config space IRQ, and call the PCIB_ROUTE_INTERRUPT method to do the routing. Or is there a better place (or way) to do this. (Can I even legally call pci_alloc_resource() from acpi_pcib_pci_alloc_resource()?). For extra information, here is a rather verbose dmesg and AML dump: http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt http://starbug.ugh.net.au/~iaint/vaio/ruri.aml Oh yeah, not using ACPI is not an option (panics in either PCI or PnP BIOS), also I think the same problem would exist then since it would still not try to route interrupts, but I could be wrong. Iain