linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* pci_resource_end problem revisited
@ 2006-05-10  1:28 Geoff Levand
  2006-05-10  8:04 ` Segher Boessenkool
  0 siblings, 1 reply; 2+ messages in thread
From: Geoff Levand @ 2006-05-10  1:28 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: pci_resource_end problem revisited
  2006-05-10  1:28 pci_resource_end problem revisited Geoff Levand
@ 2006-05-10  8:04 ` Segher Boessenkool
  0 siblings, 0 replies; 2+ messages in thread
From: Segher Boessenkool @ 2006-05-10  8:04 UTC (permalink / raw)
  To: Geoff Levand; +Cc: linuxppc-dev

> 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.

Make fixup_device_tree() fix the dev tree itself?

> 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]

Also note that the last BAR is at legacy I/O address 0, various things
will break due to bogus assumptions... this BAR is not needed for the
UARTs though :-)


Segher

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-05-10  8:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-10  1:28 pci_resource_end problem revisited Geoff Levand
2006-05-10  8:04 ` Segher Boessenkool

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).