On 11.03.25 12:24, Mykyta Poturai wrote:
From: Volodymyr Babchuk <volodymyr_babc...@epam.com>
There are high chances that there will be a number of a consecutive
accesses to configuration space of one device. To speed things up,
we can program ATU only during first access.
This is mostly beneficial taking into account the previous patch that
adds 1ms delay after ATU reprogramming.
Signed-off-by: Volodymyr Babchuk <volodymyr_babc...@epam.com>
Signed-off-by: Mykyta Poturai <mykyta_potu...@epam.com>
---
v1->v2:
* rebased
---
xen/arch/arm/pci/pci-designware.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/xen/arch/arm/pci/pci-designware.c
b/xen/arch/arm/pci/pci-designware.c
index def2c12d63..cec52cf81a 100644
--- a/xen/arch/arm/pci/pci-designware.c
+++ b/xen/arch/arm/pci/pci-designware.c
@@ -272,6 +272,14 @@ static void dw_pcie_prog_outbound_atu(struct
pci_host_bridge *pci, int index,
int type, uint64_t cpu_addr,
uint64_t pci_addr, uint64_t size)
{
First, using (hiding) static var inside the function deserve big, fat comment
on why and what.
+ static uint64_t prev_addr = ~0;
Second, from an experience, static vars in functions is source of potential
problems,
it's kinda land mines in code. For example, lets assume there are two
pci_host_bridge
instances in Xen and they are accessed concurrently.
Best to get rid of static var here - may be move in pci_host_bridge, like
cached_pci_addr? not sure
+
+ /* Simple optimization to not-program ATU for every transaction */
+ if (prev_addr == pci_addr)
+ return;
+
+ prev_addr = pci_addr;
+
__dw_pcie_prog_outbound_atu(pci, 0, index, type,
cpu_addr, pci_addr, size);
}
BR,
-grygorii
