Re: [PATCH 24/32] pci: PCIe driver for Marvell Armada 370/XP systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

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
like 

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

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux