target/linux/layerscape/patches-4.4/0054-PCI-designware-Explain-why-we-don-t-program-ATU-for-.patch

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