From: Geoff Levand <geoffrey.levand@am.sony.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: pci_resource_end problem revisited
Date: Tue, 09 May 2006 18:28:02 -0700 [thread overview]
Message-ID: <446141A2.9030000@am.sony.com> (raw)
Ben,
I still have this problem of OF reporting the serial port bar
size as 16 instead of 8 on my G5. Where would be a proper
place to fix this? BTW, I verified that it is OF that reports
the size as 16.
-Geoff
-------- Original Message --------
Subject: Re: pci_resource_end() changed problem with 2.6.14
Date: Fri, 04 Nov 2005 10:36:58 -0800
From: Geoff Levand <geoffrey.levand@am.sony.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc64-dev@ozlabs.org
References: <436ADBA7.7030706@am.sony.com> <1131087370.4680.238.camel@gaston>
Benjamin Herrenschmidt wrote:
> On Thu, 2005-11-03 at 19:55 -0800, Geoff Levand wrote:
>
>>I found that the serial port probe code in drivers/serial/8250_pci.c
>>no longer works properly for ppc64 in 2.6.14. It seems the value
>>returned by pci_resource_len() on ppc64 changed from 8 to 16 since
>>2.6.13. I tested on a PC and pci_resource_len() returns 8 as
>>expected.
>>
> Interesting... What does an lspci -vv shows for the BARs of the PCI
> card ? Also, what do you have in /proc/device-tree ? What is the
> machine precisely ?
>
> 2.6.14 now uses the OF device-tree to generate the linux PCI tree
> instead of going directly to PCI probing. It's possible that this is
> causing your problem if for some reason, the BAR sizing done by OF ends
> up being different than what the kernel does ...
>
Sorry, I should have mentioned it, this is on my PowerMac G5 with a
generic 8250 serial PCI card (StarTech PCI4S550N). Here's what lspci
gives me:
0001:05:03.0 Serial controller: NetMos Technology PCI 9845 Multi-I/O Controller (rev 01) (prog-if 02 [16550])
Subsystem: LSI Logic / Symbios Logic 0P4S (4 port 16550A serial card)
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-
Interrupt: pin A routed to IRQ 53
Region 0: I/O ports at f4000050 [size=16]
Region 1: I/O ports at f4000040 [size=16]
Region 2: I/O ports at f4000030 [size=16]
Region 3: I/O ports at f4000020 [size=16]
Region 4: I/O ports at f4000010 [size=16]
Region 5: I/O ports at f4000000 [size=16]
It could be the change to using the OF device-tree. What's an easy way to
see the size OF has used?
-Geoff
next reply other threads:[~2006-05-10 1:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 1:28 Geoff Levand [this message]
2006-05-10 8:04 ` pci_resource_end problem revisited Segher Boessenkool
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=446141A2.9030000@am.sony.com \
--to=geoffrey.levand@am.sony.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.