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/[EMAIL PROTECTED] (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/[EMAIL PROTECTED] (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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
