On 18.05.2023 11:39, Stephan Gerhold wrote: > While SDHCI claims to support 64-bit DMA on MSM8916 it does not seem to > be properly functional. It is not immediately obvious because SDHCI is > usually used with IOMMU bypassed on this SoC, and all physical memory > has 32-bit addresses. But when trying to enable the IOMMU it quickly > fails with an error such as the following: > > arm-smmu 1e00000.iommu: Unhandled context fault: > fsr=0x402, iova=0xfffff200, fsynr=0xe0000, cbfrsynra=0x140, cb=3 > mmc1: ADMA error: 0x02000000 > mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== > mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00002e02 > mmc1: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000000 > mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013 > mmc1: sdhci: Present: 0x03f80206 | Host ctl: 0x00000019 > mmc1: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 > mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 > mmc1: sdhci: Timeout: 0x0000000a | Int stat: 0x00000001 > mmc1: sdhci: Int enab: 0x03ff900b | Sig enab: 0x03ff100b > mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 > mmc1: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007 > mmc1: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000 > mmc1: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x5b590000 > mmc1: sdhci: Resp[2]: 0xe6487f80 | Resp[3]: 0x0a404094 > mmc1: sdhci: Host ctl2: 0x00000008 > mmc1: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x0000000ffffff224 > mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP ----------- > mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x60006400 | DLL cfg2: 0x00000000 > mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x00000000 > mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88018a8 Vndr func3: 0x00000000 > mmc1: sdhci: ============================================ > mmc1: sdhci: fffffffff200: DMA 0x0000ffffffffe100, LEN 0x0008, Attr=0x21 > mmc1: sdhci: fffffffff20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x03 > > Looking closely it's obvious that only the 32-bit part of the address > (0xfffff200) arrives at the SMMU, the higher 16-bit (0xffff...) get > lost somewhere. This might not be a limitation of the SDHCI itself but > perhaps the bus/interconnect it is connected to, or even the connection > to the SMMU. > > Work around this by setting SDHCI_QUIRK2_BROKEN_64_BIT_DMA to avoid > using 64-bit addresses. > > Signed-off-by: Stephan Gerhold <stephan@xxxxxxxxxxx> > --- Would using 64bit address translation not require you to use (dma-)ranges with a greater-than-default size, like we do on newer platforms? Did you test that by chance? Konrad > drivers/mmc/host/sdhci-msm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c > index 8ac81d57a3df..1877d583fe8c 100644 > --- a/drivers/mmc/host/sdhci-msm.c > +++ b/drivers/mmc/host/sdhci-msm.c > @@ -2479,6 +2479,9 @@ static inline void sdhci_msm_get_of_property(struct platform_device *pdev, > msm_host->ddr_config = DDR_CONFIG_POR_VAL; > > of_property_read_u32(node, "qcom,dll-config", &msm_host->dll_config); > + > + if (of_device_is_compatible(node, "qcom,msm8916-sdhci")) > + host->quirks2 |= SDHCI_QUIRK2_BROKEN_64_BIT_DMA; > } > > static int sdhci_msm_gcc_reset(struct device *dev, struct sdhci_host *host) > > --- > base-commit: d4ebc9419afbac330e9ec0d2936108742aa4d97a > change-id: 20230518-msm8916-64bit-f5bcf6af7679 > > Best regards,