aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/layerscape/patches-4.4/0054-PCI-designware-Explain-why-we-don-t-program-ATU-for-.patch
blob: f48150dab2e1f3df81352178efc6443fe14792c7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
From 481b1bc4ce0d58107887558342e50d6323a9601d Mon Sep 17 00:00:00 2001
From: Jisheng Zhang <jszhang@marvell.com>
Date: Thu, 7 Jan 2016 14:12:38 +0800
Subject: [PATCH 54/70] PCI: designware: Explain why we don't program ATU for
 some platforms

Some platforms don't support ATU, e.g., pci-keystone.c.  These platforms
use their own address translation component rather than ATU, and they
provide the rd_other_conf and wr_other_conf methods to program the
translation component and perform the access.

Add a comment to explain why we don't program the ATU for these platforms.

[bhelgaas: changelog]
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 drivers/pci/host/pcie-designware.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -517,6 +517,11 @@ int dw_pcie_host_init(struct pcie_port *
 	if (pp->ops->host_init)
 		pp->ops->host_init(pp);
 
+	/*
+	 * If the platform provides ->rd_other_conf, it means the platform
+	 * uses its own address translation component rather than ATU, so
+	 * we should not program the ATU here.
+	 */
 	if (!pp->ops->rd_other_conf)
 		dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1,
 					  PCIE_ATU_TYPE_MEM, pp->mem_base,