[PATCH v1 5/9] mmc: sdhci: add Black Sesame Technologies BST C1200 controller driver
Arnd Bergmann
arnd at arndb.de
Fri Jun 27 06:43:50 PDT 2025
On Fri, Jun 27, 2025, at 15:19, Adrian Hunter wrote:
> On 27/06/2025 13:22, yangzh0906 at thundersoft.com wrote:
>> Dear Mr. Hunter,
>>
>> Our platform supports 64-bit physical addressing, but the eMMC controller's SRAM-based DMA engine is constrained to a 32-bit address space.
>> When using the standard SDHCI interface, which allocates DDR-based DMA buffers with 64-bit addresses, thedma_map_single() operation fails
>> because the DMA engine cannot handle addresses beyond 32 bits.
dma_map_single() should always succeed on arm64 even if the buffer
is outside of the dma mask: On most modern SoCs there is an SMMU/IOMMU
that implements the actual mapping, and in the absence of that
there is a fallback to SWIOTLB, which is always built-in on arm64.
> SDHCI controllers can use 32-bit DMA or 64-bit DMA, however even with
> 64-bit DMA it is possible to restrict the DMA addresses to 32-bits
> by setting a 32-bit DMA mask.
>
> If the host controller capabilities indicate support for 64-bit DMA
> but you want the driver to use 32-bit DMA, set SDHCI_QUIRK2_BROKEN_64_BIT_DMA.
>
> However, if you want to use 64-bit DMA with only 32-bit DMA addresses
> you can instead implement sdhci host op ->set_dma_mask() and in that
> function dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))
I would not expect an standard SDHCI to be broken like this any more,
and if it is, I think the SDHCI_QUIRK2_BROKEN_64_BIT_DMA quirk is
more appropriate than overriding the dma_set_mask() operation.
What sometimes happens though is that the SoC integration itself is
broken, and a 64-bit capable DMA master like SDHCI is connected
to a 32-bit bus. In this case the DMA limitation should be
described in the device tree, using the "dma-ranges" property
of the broken bus node. The SDHCI code then still sets the correct
64-bit DMA mask according for the device, but the dma_map_single()
still uses an swiotlb bounce buffer or the IOMMU to work around
the bus restriction.
>> To resolve this hardware limitation, we implement a bounce buffer allocated via >> dma_alloc_coherent() to satisfy DMA addressing constraints.
>
> The bounce buffer should not be needed to satisfy DMA addressing
> constraints. It is used when SDHCI ADMA (scatter/gather) is broken.
I wonder if the actual problem here is not the addressing limit
but instead the coherency protocol. If the DMA master is cache
coherent but listed as non-coherent in DT, or vice versa, there will
be data corruption for all addresses, and using a dma_alloc_coherent()
bounce buffer may hide this.
Arnd
More information about the linux-arm-kernel
mailing list