From: Sergei Shtylyov <sshtylyov@ru•mvista.com>
To: Christian Ehrhardt <ehrhardt@linux•vnet.ibm.com>
Cc: linuxppc-dev@ozlabs•org, Detlev Zundel <dzu@denx•de>,
Hollis Blanchard <hollisb@us•ibm.com>
Subject: Re: pci issue - wrong detection of pci ressources
Date: Tue, 22 Apr 2008 17:31:07 +0400 [thread overview]
Message-ID: <480DE89B.2030402@ru.mvista.com> (raw)
In-Reply-To: <480DDE2B.4000808@linux.vnet.ibm.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
next prev parent reply other threads:[~2008-04-22 13:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 12:07 pci issue - wrong detection of pci ressources Christian Ehrhardt
2008-04-18 14:23 ` Johan Borkhuis
2008-04-18 16:29 ` Sergei Shtylyov
2008-04-19 0:48 ` Benjamin Herrenschmidt
2008-04-19 0:51 ` Benjamin Herrenschmidt
2008-04-20 20:36 ` Christian Ehrhardt
2008-04-20 21:36 ` Benjamin Herrenschmidt
2008-04-21 11:55 ` Christian Ehrhardt
2008-04-21 12:25 ` Sergei Shtylyov
2008-04-21 14:08 ` Christian Ehrhardt
2008-04-21 15:16 ` Sergei Shtylyov
2008-04-21 16:20 ` Sergei Shtylyov
2008-04-22 12:46 ` Christian Ehrhardt
2008-04-22 13:31 ` Sergei Shtylyov [this message]
2008-04-22 14:21 ` Christian Ehrhardt
2008-04-22 14:27 ` Michel Dänzer
2008-04-22 22:18 ` Benjamin Herrenschmidt
2008-04-21 21:13 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=480DE89B.2030402@ru.mvista.com \
--to=sshtylyov@ru$(echo .)mvista.com \
--cc=dzu@denx$(echo .)de \
--cc=ehrhardt@linux$(echo .)vnet.ibm.com \
--cc=hollisb@us$(echo .)ibm.com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox