0054-PCI-designware-Explain-why-we-don-t-program-ATU-for-.patch 1.3 KB

12345678910111213141516171819202122232425262728293031323334
  1. From 481b1bc4ce0d58107887558342e50d6323a9601d Mon Sep 17 00:00:00 2001
  2. From: Jisheng Zhang <jszhang@marvell.com>
  3. Date: Thu, 7 Jan 2016 14:12:38 +0800
  4. Subject: [PATCH 54/70] PCI: designware: Explain why we don't program ATU for
  5. some platforms
  6. Some platforms don't support ATU, e.g., pci-keystone.c. These platforms
  7. use their own address translation component rather than ATU, and they
  8. provide the rd_other_conf and wr_other_conf methods to program the
  9. translation component and perform the access.
  10. Add a comment to explain why we don't program the ATU for these platforms.
  11. [bhelgaas: changelog]
  12. Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
  13. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
  14. ---
  15. drivers/pci/host/pcie-designware.c | 5 +++++
  16. 1 file changed, 5 insertions(+)
  17. --- a/drivers/pci/host/pcie-designware.c
  18. +++ b/drivers/pci/host/pcie-designware.c
  19. @@ -517,6 +517,11 @@ int dw_pcie_host_init(struct pcie_port *
  20. if (pp->ops->host_init)
  21. pp->ops->host_init(pp);
  22. + /*
  23. + * If the platform provides ->rd_other_conf, it means the platform
  24. + * uses its own address translation component rather than ATU, so
  25. + * we should not program the ATU here.
  26. + */
  27. if (!pp->ops->rd_other_conf)
  28. dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
  29. PCIE_ATU_TYPE_MEM, pp->mem_base,