Hi Arnd, Thanks a lot for detailed explanation. On Fri, Dec 06, 2013 at 05:33:12AM +0800, Arnd Bergmann wrote: > On Thursday 05 December 2013, Pratyush Anand wrote: > > Hi Arnd / Jingoo, > > > > Sorry for not able to follow earlier discussion you had on this > > topic while initial reviews of patches from Jingoo. > > > > I have few doubts that how will it actually work. > > > > As per my understanding under current implementation: > > > > 1. Physical IO addresses are in the range of 0x1000 to 0xfffff. > > 2. They are mapped to fixed virtual address 0xFEE00000 using > > pci_ioremap_io. > > 3. IO resource addresses to any PCIe device will be allocated in above > > range. > > 4. Driver for that PCIe device will write in the above range only for > > IO transaction to the device. > > 5. As per current IO translation programming, its one to one > > translation. It means PCIe translation unit will have both input and > > output address in the range of 0x1000 to 0xfffff. > > > > Did I miss something, or if above statements are correct, then what I > > do not understand is how can designware PCIe translation unit accept > > input address in the range of 0x1000 to 0xfffff? > > Hi Pratyush, > > I think the part that you are missing is that there are four, not two > address spaces involved: > > 1. The "bus" I/O port address, in the range between 0x1000 and 0xffff > (65535). This is the address used in data frames in the actual bus > transaction going over the PCIe wires. If you have more than one PCIe > host bridge, each of them can normally have a range of up to 65536 > addresses. The bus addresses get written into BAR registers of the > device. Correct. Got this point. So this address should be output of designware outbound address translation unit. > > 2. The Linux I/O port numbers, between 0x00000 and 0xfffff (1048575). > This is a logical number space that aggregates all bus I/O port numbers. > The first 4096 ports are normally reserved for ISA devices and are > not available for PCIe resources. Each PCI or PCIe host bridge can have > a 0x10000 byte naturally aligned range in here. The common case is that > you have only one host bridge using the range 0x1000-0xffff. If you have > more than one, there may be an offset between them, e.g. the second PCIe > host may have io_offset set to 0x10000, which means that its bus range > 0x1000-0xffff gets translated to Linux port number 0x11000-0x1ffff. > Linux port numbers are visible e.g. in /proc/ioport and /dev/port Ok, got it. To know more, which binding function maps this logical number space to address space in 4? > > 3. The CPU physical address space: Each PCIe host normally has its > bus I/O port space mapped into PCU visible addresses, either hardwired > or (in case of dw_pcie) set up using an outbound translation window. > These addresses are what get passed to pci_ioremap_io. OK. > > 4. The CPU virtual address space: This is an implementation detail > of the kernel, which results in the Linux I/O port numbers 0x0-0xfffff > to be mapped at 0xfee00000-0xfeefffff. > > > For example in SPEAr1340, physically RAM is mapped on above addresses. > > PCIe address translation unit can accept address only in the range of > > core addresses which are assigned to PCIe RC ie 0x80000000-0x8FFFFFFF. > > Since this is a physical address, it corresponds to address space 3 in > my list above, and the address you pick here is what you pass to > pci_ioremap_io. This is what I was expecting. But currently designware driver does not pass this address to pci_ioremap_io. OK.. We will fix it and will send patch. Regards Pratyush > > 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
