There is a reproducible PCIe/ASPM problem on the CIX Sky1/Radxa Orion O6 under ACPI with the PCIe SMMU enabled (firmware 1.2.4).
With ASPM enabled, Samsung NVMe 144d:a809 and Realtek RTL8126 10ec:8126 traffic has produced repeatable Arm SMMUv3 F_TRANSLATION faults apparently targeting IOVA 0. Driver diagnostics showed that Linux submitted non-zero DMA addresses, so this did not look like the NVMe or Ethernet driver deliberately mapping address zero.
Using global pcie_aspm=off stopped the faults. I implemented a narrower workaround which removes ASPM capability from those endpoints and explicitly clears PCI_EXP_LNKCTL_ASPMC and all L1SS enable bits on both endpoint and upstream root port (affected endpoints now show LnkCtl=0x0000), which has allowed the rest of the system to retain ASPM support (relevant root ports can still show LnkCtl=0x0002 (L1 enabled)).
The CIX P1 TRM PCIe power chapter associates A4 with L1.1/L1.2 and says these states need additional control sequencing. Is there a Sky1 erratum or required programming sequence involving the psc_a0_preg through psc_a4_preg controls, PHY/refclock/CLKREQ, PCIe TBU, or NI-700 which the patches in this repo currently lack?
Separately, CIX DT kernels describe the PCIe SMMU using arm,boot-active-sids and cix,pcie-ats-override, but ACPI/IORT does not provide equivalent behaviour. Additionally, is it correct that the CIX PCIe DTI ATS master sends translated TLPs even when an endpoint does not itself advertise ATS?
Could CIX confirm:
- Which ASPM states are safe on each Sky1 root port?
- Whether root-port L1 enabled while endpoint ASPM is disabled is a state expected by the firmware?
- The required L1/L1SS entry and exit register sequence;
- Whether the PCIe TBU/SMMU or ATS state must be invalidated or restored during link wake;
- Whether the IOVA-zero faults match a known CIX erratum;
- Whether CIX can publish either a sequencing fix or an official Sky1 root-port ASPM quirk (whilst retaining PCIe SMMU support)?
There is a reproducible PCIe/ASPM problem on the CIX Sky1/Radxa Orion O6 under ACPI with the PCIe SMMU enabled (firmware 1.2.4).
With ASPM enabled, Samsung NVMe
144d:a809and Realtek RTL812610ec:8126traffic has produced repeatable Arm SMMUv3F_TRANSLATIONfaults apparently targeting IOVA0. Driver diagnostics showed that Linux submitted non-zero DMA addresses, so this did not look like the NVMe or Ethernet driver deliberately mapping address zero.Using global
pcie_aspm=offstopped the faults. I implemented a narrower workaround which removes ASPM capability from those endpoints and explicitly clearsPCI_EXP_LNKCTL_ASPMCand all L1SS enable bits on both endpoint and upstream root port (affected endpoints now showLnkCtl=0x0000), which has allowed the rest of the system to retain ASPM support (relevant root ports can still showLnkCtl=0x0002(L1 enabled)).The CIX P1 TRM PCIe power chapter associates A4 with L1.1/L1.2 and says these states need additional control sequencing. Is there a Sky1 erratum or required programming sequence involving the
psc_a0_pregthroughpsc_a4_pregcontrols, PHY/refclock/CLKREQ, PCIe TBU, or NI-700 which the patches in this repo currently lack?Separately, CIX DT kernels describe the PCIe SMMU using
arm,boot-active-sidsandcix,pcie-ats-override, but ACPI/IORT does not provide equivalent behaviour. Additionally, is it correct that the CIX PCIe DTI ATS master sends translated TLPs even when an endpoint does not itself advertise ATS?Could CIX confirm: