Hi Pratyush, On Wednesday 23 October 2013 10:06 AM, Pratyush Anand wrote: > Hi Kishon, > > On Tue, Oct 22, 2013 at 10:20:01PM +0800, Kishon Vijay Abraham I wrote: >> Hi Pratyush, Jingoo, >> >> On Tuesday 22 October 2013 10:46 AM, Jingoo Han wrote: >>> On Monday, October 21, 2013 10:28 PM, Kishon Vijay Abraham I wrote: >>>> >>>> Currently I see in pcie-designware.c we use only 2 ATU regions. We re-use >>>> INDEX0 for mem outbound and cfg0, and INDEX1 for cfg1 and io. So I'd like to >>>> know if in your platform, do you have only 2 address translation regions? In >>>> DRA7xx we have 16 outbound regions and 4 inbound regions. >>> >>> In Exynos, there are only 2 inbound and 2 outbound viewpoints. >>> >>>> Also the same designware IP can be used as a EP also no? Shouldn't we move it >>>> out of drivers/pci/host and allow it to be configured as EP also? >>> >>> Currently, Exynos PCIe IP does not support EP mode. >> >> Thanks for the information. I think we can do some optimization w.r.t address >> translation regions. Will post a RFC soon. >> >> One more query. >> In dw_pcie_prog_viewport_cfg0/dw_pcie_prog_viewport_cfg1 functions, the *lower >> target* is programmed to busdev. Is it for any specific reason? >> I mean doing that will leave lot of holes in the PCIe address space. >> IIUC, if we don't set that to busdev, consecutive pcie address space will be >> used for each function no? > > Yes, I think even if CX_ATU_MIN_REGION_SIZE is 64KB in any controller, > bus, dev and function number can be used to define target address. I meant for function 0 the configuration space will be from (0x0 t0 0xfff - 4KB). If we use *busdev* for programming target, for function 1 the configuration space will start at 0x10000 PCIe address which will leave a small hole from (0x1000 to 0xffff). I'm not sure if it will have a big impact though. Also till we haven't exhausted the 64KB space (minimum), we wouldn't be needing to program a new viewport. That's good enough to accommodate 18 functions for the number of devices. > > So you are trying to allocate statically a separate viewport for each > function's cfg0 transfer (whereever sufficient number of viewport is > avilable)? Actually in DRA7xx, we face a different problem in that, we can't program the translation region directly from the ranges. Because while programming the address translation window, the most significant 4 bits are not used. For example if you see, the cpu address of memory window starts @ 0x20012000 but while programming the address translation window we have to give 0x00012000. My dt data looked like this. ranges = <0x00000800 0 0x20001000 0x20001000 0 0x00001000 0x81000000 0 0 0x20002000 0 0x00010000 0x82000000 0 0x20012000 0x20012000 0 0xffee000>; translation = <(OUTBOUND | INDEX0) CFG0 0x0 0x00001000 0x0000fff 0x0 0x00001000 (OUTBOUND | INDEX1) IO 0x0 0x00002000 0x000ffff 0x0 0x00002000 (OUTBOUND | INDEX2) MEM 0x0 0x00012000 0xffee000 0x0 0x20012000 >; (btw that translation is a wip I tried to get pcie working in dra7x). Since I wanted to do the translation configuration from dt data, I was thinking whether it is necessary to program the viewport dynamically. But now I think some sort of dynamic programming would be needed, considering the limitation on few SoCs. Thanks Kishon > > If viewport is programmed dynamically at each cfg transfer, then > whether you use bus and dev only or function also, will it really make > any difference in saving of address space? > > Regards > Pratyush > >> >> Thanks >> Kishon -- 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
