On 12.03.25 12:12, Grygorii Strashko wrote: > > > On 11.03.25 12:24, Mykyta Poturai wrote: >> From: Volodymyr Babchuk <[email protected]> >> >> For some reason, we need a delay before accessing ATU region after >> we programmed it. Otherwise, we'll get erroneous TLP. >> >> There is a code below, which should do this in proper way, by polling >> CTRL2 register, but according to documentation, hardware does not >> change this ATU_ENABLE bit at all. >> >> Signed-off-by: Volodymyr Babchuk <[email protected]> >> Signed-off-by: Mykyta Poturai <[email protected]> >> --- >> v1->v2: >> * rebased >> --- >> xen/arch/arm/pci/pci-designware.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/xen/arch/arm/pci/pci-designware.c >> b/xen/arch/arm/pci/pci-designware.c >> index 6ab03cf9b0..def2c12d63 100644 >> --- a/xen/arch/arm/pci/pci-designware.c >> +++ b/xen/arch/arm/pci/pci-designware.c >> @@ -194,6 +194,11 @@ static void >> dw_pcie_prog_outbound_atu_unroll(struct pci_host_bridge *pci, >> dw_pcie_writel_ob_unroll(pci, index, PCIE_ATU_UNR_REGION_CTRL2, >> PCIE_ATU_ENABLE); >> + /* >> + * HACK: We need to delay there, because the next code does not >> + * work as expected on S4 >> + */ >> + mdelay(1); > > It seems like a HACK to WA some platform issue, but in its current form it > will affect all DW PCI compatible platforms. > > So, it is required a proper solution for the affected platform to be > found, or > some sort of DW PCI "quirk"s processing code be introduced. > > I'd recommend to drop this patch for now from this series. > >> /* >> * Make sure ATU enable takes effect before any subsequent config >> * and I/O accesses. > > BR, > -grygorii
Hi Grygorii After some further investigations I have retested this on V4H, and it seems to work fine without delays. Considering this and the issue with static variables and multiple PCI hosts I think I will drop ATU related workarounds until some proper quirks handling system is established. -- Mykyta
