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: Fri, 18 Apr 2008 20:29:02 +0400 [thread overview]
Message-ID: <4808CC4E.5000705@ru.mvista.com> (raw)
In-Reply-To: <48088F02.2060806@linux.vnet.ibm.com>
Christian Ehrhardt wrote:
> I tried to use a radeon r200 based graphic card on a sequoia ppc
> (440epx) board. I wondered about the initialization of radeonfb that
> failed with
> __ioremap(): phys addr 0x0 is RAM lr c029cf80
> radeonfb (0000:00:0a.0): cannot map MMIO
> radeonfb: probe of 0000:00:0a.0 failed with error -5
> I trigger a check in ioremap, because the address it wants to remap is
> 0x0 which can never work. The reason of that is that the pci ressource
> of that graphic card is not properly detected.
There might be another reason. This driver seems to be another subject to
the 440-specific PCI memory space issue beacuse it uses 'unsigned long' to
store the PCI memory physical addresses and those are 64-bit in the 440
arch/powerpc/ kernels.
> With some help I found two kernels - one that work and one that has this
> issue.
> Unfortunately they are very different:
> good => 2.6.24.2 from the linux-2.6-denx - built for arch=ppc
> bad => we have 2.6.25-rc9 (used in our kvm ppc project atm) - build
> for arch=powerpc
> I tried building the 2.6.25-rc9 with arch=ppc, but that one does not
> boot so far. Because of that I can't surely tell you if it is only that
> difference that breaks the pci detection.
> We need arch=powerpc for our kvm code anyway, so I hope there is another
> solution than to switch to arch=ppc ;-)
Yes, the driver needs fixing -- at least that.
> I just started to debug into that, but I wanted to ask here if there
> might be some known issues causing that and/or to get some hints where
> to look at.
Now you know of at least one.
> The issue is much better visible when I boot with these two kernels and
> use "lspci -vvv"
> Good kernel:
> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon
> 9200 PRO] (rev 01) (prog-if 00 [VGA])
> Subsystem: PC Partner Limited Unknown device 0250
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 128 (2000ns min)
> Interrupt: pin A routed to IRQ 67
> Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
> Region 1: I/O ports at ff00 [size=256]
> Region 2: Memory at 87ff0000 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at 80020000 [disabled] [size=128K]
Here, the PCI resources have been re-assigned by arch/ppc/ kernel, and are
confined to 4 GB due to fixup_bigphys_addr() trick used for 440...
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Bad kernel:
> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon
> 9200 PRO] (rev 01) (prog-if 00 [VGA])
> Subsystem: PC Partner Limited Unknown device 0250
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 128 (2000ns min)
> Interrupt: pin A routed to IRQ 16
> Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
That's beyond 4 GB, seems correct. That should be the address assigned by
bootloader? BTW, what's your bootloader, U-Boot?
> Region 1: I/O ports at 1000 [size=256]
> Region 2: Memory at <ignored> (32-bit, non-prefetchable)
Hm... what could this mean? Could you post the result of 'lspci -x'?
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> => Region 2 is not detected with our kernel, this later break things
> like radeonfb initialization.
Well, not only this...
WBR, Sergei
next prev parent reply other threads:[~2008-04-18 16:29 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 [this message]
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
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=4808CC4E.5000705@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