Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030319AbWJSIhg (ORCPT ); Thu, 19 Oct 2006 04:37:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030322AbWJSIhf (ORCPT ); Thu, 19 Oct 2006 04:37:35 -0400 Received: from dsl027-180-168.sfo1.dsl.speakeasy.net ([216.27.180.168]:40101 "EHLO sunset.davemloft.net") by vger.kernel.org with ESMTP id S1030319AbWJSIhe (ORCPT ); Thu, 19 Oct 2006 04:37:34 -0400 Date: Thu, 19 Oct 2006 01:37:32 -0700 (PDT) Message-Id: <20061019.013732.30184567.davem@davemloft.net> To: eiichiro.oiwa.nm@hitachi.com Cc: alan@redhat.com, jesse.barnes@intel.com, greg@kroah.com, linux-kernel@vger.kernel.org Subject: Re: pci_fixup_video change blows up on sparc64 From: David Miller In-Reply-To: References: <20061018.233102.74754142.davem@davemloft.net> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 13894 Lines: 249 From: Date: Thu, 19 Oct 2006 16:54:19 +0900 > Does ATI Radeon card have an expansion ROM (video ROM)? The video card has a PCI expansion ROM. > Could you show me "lspci -vv" on sparc64? Attached below. > If an expansion ROM exists on ATI Radeon or ATY128 card, pci_map_rom returns > the expansion ROM base address instead of 0xC0000 because fixup_video checks > the VGA Enable bit in the Bridge Control register. It is not valid to expect the bridge control register to return anything meaningful on PCI "host bridge". The Radeon card here sits on the root, just under the PCI Host Controller. The code in fixup_video appears to assume that every bus up to the root from the VGA device is a PCI-PCI bridge, which is not a valid assumption. There can be a PCI host bridge at the root. Also, and more importantly, you cannot use the 0xc0000 address in a raw way like this. There are multiple PCI domains possible in a given system, and the 0xc0000 address you wish to use must be relative to that PCI domain. Therefore, in the presence of multiple PCI domains: x = ioremap(0xc0000, ...); doesn't make any sense, is extremely non-portable, and will crash on many non-x86 systems. ioremap()'s first argument is an IO address "cookie" and therefore using fixed constants for it can never work properly. It must be created by the platform specific code, and usually this occurs via PCI resource computation at PCI probe time. There are portable ways defined to do this kind of thing, for example with the pcibios_bus_to_resource() interface, used by routines such as drivers/pci/quirks.c:quirk_io_region(). All of this pci_fixup_video code was perfectly fine when it was only used on x86, where assumptions like this happened to work, but it is not possible to continue making these assumptions if this code will now run on every single architecture. Here is the lspci output: 0000:00:00.0 Host bridge: Sun Microsystems Computer Corp. Tomatillo PCI Bus Module Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 0000:00:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) Subsystem: Broadcom Corporation NetXtreme BCM5703 1000Base-T Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-