Hi, On Thu, Jan 7, 2016 at 12:41 PM, Minghuan Lian <minghuan.lian@xxxxxxx> wrote: > Hi Bjorn, > > We need at least four kinds of PCIe transactions: CFG0, CFG1, IO, MEM. > The best solution is to assign 4 iATU to support them separately for example: ATU0- CFG0, ATU1-CFG1, ATU2-IO ATU3-MEM. > So, for IO and MEM, we don't need to update iATU and for CFG, we only need to update a register to update BUS device and function number. > Moreover, this can avoid any conflict. > > But There are some SOCs that only provides two iATUs. Yes, as far as I know there are two SOCs Marvell Berlin and SPEAr1340 which have only two iATUs. > So the latest driver provides a solution: ATU0 is shared by CFG0 CFG1 and IO, ATU1 is dedicated to MEM. > The driver should first set ATU0 as IO and ATU1 as MEM. When accessing CFG0 or CFG1, ATU0 will be changed to CFG0/CFG1, then back to IO setting. > CFG0 CFG1 can sequenced by pci_lock. But CFG IO and MEM(may be generated by PCIe device's DMA) are completely independent. > > Because most PCIe device do not need IO transaction and in general CFG0 CFG1 and IO transaction is generated by PCIe device driver and rarely occurred simultaneously. > So the current solution can minimize conflict. > In fact, for the current pcie-designware driver, there is no way to avoid IO and CFG conflict. Right, and frankly I do not see any way to rule out even by changing something in pci core layer. So, IMHO since there are only few SOCs with 2 ATUs, lets implement one time ATU programming for 4 ATUs in pcie-designware.c and SOCs having less than 4 ATUs should implement their own rd/wr_other_conf(). With this approach we can minimized its ill effect. ~Pratyush -- 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
