linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* 2.4 -> 2.6: problem probing PCI
@ 2004-11-11  8:36 Marc Leeman
  2004-11-17 15:51 ` Marc Leeman
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Leeman @ 2004-11-11  8:36 UTC (permalink / raw)
  To: Linux PPC Mailing List

Hi,

before digging into the lower ppc specific code myself, I thought to
ask and describe my problem here first. I am currently porting a 2.4
based embedded solution to a 2.6 kernel (basically for the fun of it)
and have come accross the following:

When probing the PCI bus (of an embedded solution DBG enabled; 2.6.9):

PCI: Probing PCI hardware
PCI: bridge rsrc 0..bfffff (100), parent c0172188
PCI: reparented dma1 [0..1f] under PCI host bridge
PCI: reparented pic1 [20..3f] under PCI host bridge
PCI: reparented timer [40..5f] under PCI host bridge
PCI: reparented dma page reg [80..8f] under PCI host bridge
PCI: reparented pic2 [a0..bf] under PCI host bridge
PCI: reparented dma2 [c0..df] under PCI host bridge
PCI: bridge rsrc 80000000..fcffffff (200), parent c017216c
PCI:0000:00:00.0: Resource 1: 00000000-00000fff (f=3D200)
PCI: Cannot allocate resource region 1 of device 0000:00:00.0
PCI:  parent is c01b6054: 80000000-fcffffff (f=3D200)
PCI:0000:00:10.0: Resource 0: bffff000-bfffffff (f=3D200)
PCI:0000:00:10.0: Resource 1: 00bfffc0-00bfffff (f=3D101)
PCI:0000:00:10.0: Resource 2: bffc0000-bffdffff (f=3D200)
PCI:0000:00:11.0: Resource 0: bffbf000-bffbffff (f=3D200)
PCI:0000:00:11.0: Resource 1: 00bfff80-00bfffbf (f=3D101)
PCI:0000:00:11.0: Resource 2: bff80000-bff9ffff (f=3D200)
PCI:0000:00:12.0: Resource 0: bf800000-bfbfffff (f=3D1208)
PCI:0000:00:12.0: Resource 1: bf000000-bf7fffff (f=3D200)
PCI:0000:00:12.0: Resource 2: 00bfff70-00bfff7f (f=3D101)
PCI:0000:00:13.0: Resource 0: 00bfff60-00bfff6f (f=3D101)
PCI:0000:00:13.0: Resource 1: befffff0-beffffff (f=3D200)

There is a problem with an FPGA register map (I assume) since:
ppc2fpga: BAR 0 (0xbfff60-0xbfff6f), len=3D16, flags=3D0x000101
ppc2fpga: BAR 1 (0xbefffff0-0xbeffffff), len=3D16, flags=3D0x000200
ppc2fpga: remapped 0xbfff60 with size 16 to 0xc3004f60


On a 2.4.28-rc1, this reads (same hardware):
ppc2fpga: BAR 0 (0xfebfff40-0xfebfff5f), len=3D32, flags=3D0x000101
ppc2fpga: BAR 1 (0xbefffff0-0xbeffffff), len=3D16, flags=3D0x000200
ppc2fpga: remapped 0xfebfff40 with size 32 to 0xfebfff40

This last one has the correct behaviour and is the one currently being
installed. Both the size and the address is wrong. When I read data
from the FPGA, I get 0xFF while it should be ASCII information (the
FPGA is the PPC watchdog).

My obvious question is now: any pointers in how to proceed in
debugging this or possible reasons for this change in behaviour?

--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul

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

* Re: 2.4 -> 2.6: problem probing PCI
  2004-11-11  8:36 2.4 -> 2.6: problem probing PCI Marc Leeman
@ 2004-11-17 15:51 ` Marc Leeman
  2004-11-18 13:28   ` Marc Leeman
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Leeman @ 2004-11-17 15:51 UTC (permalink / raw)
  To: Linux PPC Mailing List

I am currently comparing the 2.6.9 (failing code) PCI DBG output with
the 2.4.28-rc1 (working code) DBG output:

2.6.9:
> PCI: Probing PCI hardware
> PCI: bridge rsrc 0..bfffff (100), parent c0172188
> PCI: reparented dma1 [0..1f] under PCI host bridge
> PCI: reparented pic1 [20..3f] under PCI host bridge
> PCI: reparented timer [40..5f] under PCI host bridge
> PCI: reparented dma page reg [80..8f] under PCI host bridge
> PCI: reparented pic2 [a0..bf] under PCI host bridge
> PCI: reparented dma2 [c0..df] under PCI host bridge
> PCI: bridge rsrc 80000000..fcffffff (200), parent c017216c
> PCI:0000:00:00.0: Resource 1: 00000000-00000fff (f=3D200)
> PCI: Cannot allocate resource region 1 of device 0000:00:00.0
> PCI:  parent is c01b6054: 80000000-fcffffff (f=3D200)
> PCI:0000:00:10.0: Resource 0: bffff000-bfffffff (f=3D200)
> PCI:0000:00:10.0: Resource 1: 00bfffc0-00bfffff (f=3D101)
> PCI:0000:00:10.0: Resource 2: bffc0000-bffdffff (f=3D200)
> PCI:0000:00:11.0: Resource 0: bffbf000-bffbffff (f=3D200)
> PCI:0000:00:11.0: Resource 1: 00bfff80-00bfffbf (f=3D101)
> PCI:0000:00:11.0: Resource 2: bff80000-bff9ffff (f=3D200)
> PCI:0000:00:12.0: Resource 0: bf800000-bfbfffff (f=3D1208)
> PCI:0000:00:12.0: Resource 1: bf000000-bf7fffff (f=3D200)
> PCI:0000:00:12.0: Resource 2: 00bfff70-00bfff7f (f=3D101)
> PCI:0000:00:13.0: Resource 0: 00bfff60-00bfff6f (f=3D101)
> PCI:0000:00:13.0: Resource 1: befffff0-beffffff (f=3D200)

2.4.28-rc1
PCI: Probing PCI hardware
PCI:00:00.0 Resource 1 [00000000-00000fff] is unassigned
Fixup res 1 (101) of dev 00:10.0: bfffc0 -> febfffc0
Fixup res 1 (101) of dev 00:11.0: bfff80 -> febfff80
Fixup res 2 (101) of dev 00:12.0: bfff70 -> febfff70
Fixup res 0 (101) of dev 00:13.0: bfff60 -> febfff60
PCI: bridge rsrc fe000000..febfffff (100), parent c012aee8
PCI: bridge rsrc 80000000..fcffffff (200), parent c012aecc
PCI:00:10.0: Resource 0: bffff000-bfffffff (f=3D200)
PCI:00:10.0: Resource 1: febfffc0-febfffff (f=3D101)
PCI:00:10.0: Resource 2: bffc0000-bffdffff (f=3D200)
PCI:00:11.0: Resource 0: bffbf000-bffbffff (f=3D200)
PCI:00:11.0: Resource 1: febfff80-febfffbf (f=3D101)
PCI:00:11.0: Resource 2: bff80000-bff9ffff (f=3D200)
PCI:00:12.0: Resource 0: bf800000-bfbfffff (f=3D1208)
PCI:00:12.0: Resource 1: bf000000-bf7fffff (f=3D200)
PCI:00:12.0: Resource 2: febfff70-febfff7f (f=3D101)
PCI:00:13.0: Resource 0: febfff60-febfff6f (f=3D101)
PCI:00:13.0: Resource 1: befffff0-beffffff (f=3D200)

The first important difference is that a number of fixups are no
longer performed in the 2.6.9 kernel; which account for the
differences in the PCI address ranges.

The problem seems to be in=20
arch/ppc/kernel/pci.c

When comparing (but not yet fixed), some minor changes have been made:

line 16 changed from
   if (!res->start || res->end =3D=3D 0xffffffff) {
to
   if (res->end =3D=3D 0xffffffff) {

which disables the flow to enter the body in this case.

another relevant piece of code that gets me into troubles is the
computation of the offset
                } else if (res->flags & IORESOURCE_IO) {
                        offset =3D (unsigned long) hose->io_base_virt;
                                - isa_io_base;
                }

both values are equal to 0xfe000000, giving a final offset of 0 and no
adjustment.

I tried commenting out 'isa_io_base' but this gets me in resource
allocation conflicts later on (even though I get the ranges identical
to the ones in the 2.4.28 kernel).

Anyway, insights are welcome, I'm still investigating...

--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul

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

* Re: 2.4 -> 2.6: problem probing PCI
  2004-11-17 15:51 ` Marc Leeman
@ 2004-11-18 13:28   ` Marc Leeman
  0 siblings, 0 replies; 3+ messages in thread
From: Marc Leeman @ 2004-11-18 13:28 UTC (permalink / raw)
  To: Linux PPC Mailing List

> Anyway, insights are welcome, I'm still investigating...

Found it, I used the wrong arc/ppc/platforms file after too zealous
cleanup of the code. I need some final testing but it looks like this
will be the only file that needs update (considering the PCI mapping
and scanning).

--=20
ash nazg durbatul=FBk, ash nazg gimbatul,
ash nazg thrakatul=FBk agh burzum-ishi krimpatul

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

end of thread, other threads:[~2004-11-18 13:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-11  8:36 2.4 -> 2.6: problem probing PCI Marc Leeman
2004-11-17 15:51 ` Marc Leeman
2004-11-18 13:28   ` Marc Leeman

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