[PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems
arnd at arndb.de
Wed Feb 13 05:37:02 EST 2013
On Wednesday 13 February 2013, Thomas Petazzoni wrote:
> > > Indeed. So maybe I should mark this resource as being IORESOURCE_MEM
> > > in the DT.
> > The DT seems fine here, just the code that interprets it is a little
> > unusual. Maybe you can change the calling convention of that function
> > to pass the type of resource you want as an argument?
> Erm? The type of the resource is encoded into the DT:
> + 0x81000000 0 0 0xc0000000 0 0x00010000 /* downstream I/O */
> + 0x82000000 0 0 0xc1000000 0 0x08000000>; /* non-prefetchable memory */
> From http://devicetree.org/Device_Tree_Usage#PCI_Host_Bridge:
> phys.hi cell: npt000ss bbbbbbbb dddddfff rrrrrrrr
> phys.mid cell: hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh
> phys.low cell: llllllll llllllll llllllll llllllll
> ss: space code
> 00: configuration space
> 01: I/O space
> 10: 32 bit memory space
> 11: 64 bit memory space
> So the 0x81 at the beginning of the first line means I/O space, the
> 0x82 at the beginning of the second line means 32 bits memory space.
> The of_pci_process_ranges() function simply decodes those informations
> and fills the struct resource it returns with the appropriate resource
Yes, of course. And the ranges property tells you how to turn the first
address space into the second address space. So the above property
defines that the PCI bus I/O space range from 0 to 0x10000 gets converted
into the host MMIO range 0xc0000000 to 0xc0010000 on the host, and
the PCI bus memory space range from 0 to 0x08000000 gets converted to
the host MMIO range 0xc1000000 to 0xc9000000.
The output of your of_pci_process_ranges() function is the host MMIO
range, not the range in the bus address space, so it has to be
Note that the memory range you have given in the example is a little
unconventional. Usually we try to have an identity mapping between
PCI bus memory space addresses and host MMIO space, which would
result in a zero sys->mem_offset value in addition to the sys->io_offset
value that is already zero.
Is there a limitation with the way that your address translation
windows are set up? What I would hope you could do is a memory window
<0x82000000 0 0xc1000000 0xc1000000 0 0x08000000>; /* non-prefetchable memory */
that translates the host MMIO range 0xc1000000-0xc9000000 into bus
address 0xc1000000-0xc9000000 instead of bus address 0x00000000-0x08000000.
Would it help if you switch the addresses around, so that the physical
location of the memory space window is naturally aligned at
0xc0000000-0xc8000000 and the I/O space window is at 0xc8000000-0xc8100000?
More information about the linux-arm-kernel