From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from imap.sh.mvista.com (unknown [63.81.120.155]) by ozlabs.org (Postfix) with ESMTP id 02F3DDE164 for ; Tue, 22 Apr 2008 23:31:46 +1000 (EST) Message-ID: <480DE89B.2030402@ru.mvista.com> Date: Tue, 22 Apr 2008 17:31:07 +0400 From: Sergei Shtylyov MIME-Version: 1.0 To: Christian Ehrhardt Subject: Re: pci issue - wrong detection of pci ressources References: <48088F02.2060806@linux.vnet.ibm.com> <1208566122.6958.425.camel@pasglop> <480BA937.7050603@linux.vnet.ibm.com> <1208727408.7009.0.camel@pasglop> <480C80B6.30904@linux.vnet.ibm.com> <480C87BD.8090207@ru.mvista.com> <480C9FE2.4030601@linux.vnet.ibm.com> <480CAFD2.2050108@ru.mvista.com> <480CBEE0.9000104@ru.mvista.com> <480DDE2B.4000808@linux.vnet.ibm.com> In-Reply-To: <480DDE2B.4000808@linux.vnet.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Cc: linuxppc-dev@ozlabs.org, Detlev Zundel , Hollis Blanchard List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hello. Christian Ehrhardt wrote: >>> Ah, that's what happens -- BAR0 in functions 0/1 takes up the >>> whole 265 MiB of the PCI memory space (128+128), so no place is left >>> for other memory BARs. >> What's interesting, the Sequoia/Rainier board user manual says that >> PCI memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux >> code seem to always have assumed only 0x[1]800000000 thru >> 0x[1]8fffffff... > Thanks to all your help I saw that the detected spaces on boot are wrong > because of the dts file. > PCI host bridge /plb/pci@1ec000000 (primary) ranges: > MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000 => 256M > IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000 => 1M Yeah, I/O space should be 64K according to what arch/ppc/ had (well, I'm looking at the out-of-tree source code :-). > The Documentation of the 440EPx core lists these spaces: > PCI 1 Memory 1 8000 0000 1 BFFF FFFF 1GB > I/O 1 E800 0000 1 E800 FFFF 64KB > I/O 1 E880 0000 1 EBFF FFFF 56MB Having 2 I/O spaces looks just wrong. Actually, PCs do well with only 64K of I/O space. > I modified the dts file and now it shows this on boot which is what the > user manual lists as mem/io space: > PCI host bridge /plb/pci@1ec000000 (primary) ranges: > MEM 0x0000000180000000..0x00000001bfffffff -> 0x0000000080000000 > IO 0x00000001e8000000..0x00000001e800ffff -> 0x0000000000000000 > IO 0x00000001e8800000..0x00000001ebffffff -> 0x0000000000000000 > \--> Skipped (too many) ! > 4xx PCI DMA offset set to 0x00000000 > The detected sizes look good compared to the processor documentation. > But I never modified a dts file before and I only found a ranges > documentation speaking of three elemnts in the ranges element. > So feel free to correct the dts if I wrote something bad without knowing > it (e.g. that skipped message). > The issue that let me start debugging this was the initialization of the > radeonfb driver and with that patch it works: > radeonfb_pci_register BEGIN > radeonfb (0000:00:0a.0): Cannot match card to OF node ! > aper_base: 80000000 MC_FB_LOC to: 87ff8000, MC_AGP_LOC to: ffff9000 > radeonfb (0000:00:0a.0): Found 131072k of DDR 64 bits wide videoram > radeonfb (0000:00:0a.0): mapped 16384k videoram > radeonfb: Found Intel x86 BIOS ROM Image > radeonfb: Retrieved PLL infos from BIOS > radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, > System=200.00 MHz > radeonfb: PLL min 20000 max 40000 > 1 chips in connector info > - chip 1 has 2 connectors > * connector 0 of type 2 (CRT) : 2300 > * connector 1 of type 3 (DVI-I) : 3201 > Starting monitor auto detection... > radeonfb: I2C (port 1) ... not found > radeonfb: I2C (port 2) ... found TMDS panel > radeonfb: I2C (port 3) ... found CRT display > i2c-adapter i2c-3: unable to read EDID block. > i2c-adapter i2c-3: unable to read EDID block. > i2c-adapter i2c-3: unable to read EDID block. > radeonfb: I2C (port 4) ... not found > radeon_probe_OF_head > radeonfb: I2C (port 2) ... found TMDS panel > radeon_probe_OF_head > radeonfb: I2C (port 3) ... found CRT display > radeonfb: Monitor 1 type DFP found > radeonfb: EDID probed > radeonfb: Monitor 2 type CRT found > radeonfb: EDID probed > Parsing EDID data for panel info > Setting up default mode based on panel info > radeonfb (0000:00:0a.0): ATI Radeon Y` Hm, what's that Y`? > radeonfb_pci_register END > And btw. now we really need the change of the radeonfb.h to use the > correct resource_size_t type, otherwise it fails with: Of course. > I attached the patch I used to get it working now for further discussion > e.g. because I don't really know dts syntax ;-) > I hope both changes find their way into the kernel once you are all > agreeing with the new dts content. > I still have issues with my X11, but thats another story. > ------------------------------------------------------------------------ > > Subject: [PATCH][dts][radeonfb]: fix pci mem in dts and radeonfb resource variables > From: Christian Ehrhardt > This patch is fixing the sequoia.dts device tree file to the values defined > in the 440Epx data sheet from amcc. > That fixes an issue where my graphic card could not initialize because the pci > resource space was not big enough. > The related mail thread about the backgrounds of this has the subject "pci > issue - wrong detection of pci ressources" > After these values were fixed another modification that came up in the mail > thread was needed to prevent an error. This change fixes the type of the > resource vaiables in the radeon frame buffer driver (We might want to split > that into two patches). > Signed-off-by: Christian Ehrhardt > diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts > --- a/arch/powerpc/boot/dts/sequoia.dts > +++ b/arch/powerpc/boot/dts/sequoia.dts > @@ -344,9 +344,14 @@ > /* Outbound ranges, one memory and one IO, > * later cannot be changed. Chip supports a second > * IO range but we don't use it for now > + * From the 440EPx user manual: > + * PCI 1 Memory 1 8000 0000 1 BFFF FFFF 1GB > + * I/O 1 E800 0000 1 E800 FFFF 64KB > + * I/O 1 E880 0000 1 EBFF FFFF 56MB > */ > - ranges = <02000000 0 80000000 1 80000000 0 10000000 > - 01000000 0 00000000 1 e8000000 0 00100000>; > + ranges = <02000000 0 80000000 1 80000000 0 40000000 > + 01000000 0 00000000 1 e8000000 0 00010000 > + 01000000 0 00000000 1 e8800000 0 03800000>; I don't think 56 MiB of I/O space make sense, so might as well skip the 3rg range... > > /* Inbound 2GB range starting at 0 */ > dma-ranges = <42000000 0 0 0 0 0 80000000>; > diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h > --- a/drivers/video/aty/radeonfb.h > +++ b/drivers/video/aty/radeonfb.h > @@ -287,8 +287,8 @@ struct radeonfb_info { > > char name[DEVICE_NAME_SIZE]; > > - unsigned long mmio_base_phys; > - unsigned long fb_base_phys; > + resource_size_t mmio_base_phys; > + resource_size_t fb_base_phys; > > void __iomem *mmio_base; > void __iomem *fb_base; I think you'd better use Ben's patch that he's just posted: http://patchwork.ozlabs.org/linuxppc/patch?id=18034 WBR, Sergei