Re: pci issue - wrong detection of pci ressources

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

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 <ehrhardt@linux.vnet.ibm.com>

> 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 <ehrhardt@linux.vnet.ibm.com>

> 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