Re: [PATCH v1 5/9] mmc: sdhci: add Black Sesame Technologies BST C1200 controller driver

[Arnd Bergmann]

On Wed, Jul 2, 2025, at 10:57, yangzh0906@xxxxxxxxxxxxxxx wrote:
>>On Fri, Jun 27, 2025, at 15:19, Adrian Hunter wrote:
>>> On 27/06/2025 13:22, yangzh0906@xxxxxxxxxxxxxxx wrote:
>> 
>>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.
>
> I add SDHCI_QUIRK2_BROKEN_64_BIT_DMA in quirks2
>  static const struct sdhci_pltfm_data sdhci_dwcmshc_pdata = {
> .ops = &sdhci_dwcmshc_ops,
> .quirks = SDHCI_QUIRK_DELAY_AFTER_POWER |
>   SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN |
>   SDHCI_QUIRK_INVERTED_WRITE_PROTECT,
> .quirks2 = SDHCI_QUIRK2_BROKEN_64_BIT_DMA |
>    SDHCI_QUIRK2_BROKEN_DDR50 |
>    SDHCI_QUIRK2_TUNING_WORK_AROUND |
>    SDHCI_QUIRK2_ACMD23_BROKEN,
> };

>>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.
>
> add the dma-ranges in dts node as below
> mmc0: mmc@22200000 {
> compatible = "bst,c1200-dwcmshc-sdhci";
> reg = <0x0 0x22200000 0x0 0x1000>,
>       <0x0 0x23006000 0x0 0x1000>;
> interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clk_mmc>;
> clock-names = "core";
> max-frequency = <200000000>;
> bus-width = <8>;
> non-removable;
> dma-coherent;
> dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x0>;
> };

The dma-ranges property makes no sense as part of the device.
It describes how DMA addresses are translated by a bus, so
it has to be part of the parent node.

As I tried to explain, you should only need to either set
the SDHCI device to 'SDHCI_QUIRK2_BROKEN_64_BIT_DMA' /or/
describe the bus translation, but not both.

Try to find out what the limitation is. If you have a datasheet
for the chip, it should either describe an erratum if the
sdhci device is known to be defective, or list the address
width of the internal link.

The 'dma-coherent' flag in the bst,c1200-dwcmshc-sdhci node is
suspicious as well: unless all DMA masters on this SoC are
cache-coherent, the mmc host is likely not the first thing
that the hardware designers used a coherent port for.

If you bounce all the transfers through an SRAM, it probably
still works correctly regardless of the dma-coherent flag,
but if you manage to configure ZONE_DMA32 RAM for SWIOTLB,
then the 'dma-coherent' flag must only be if the DMA master
is actually coherent with the CPU caches.

>>>>  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.
>
> Finally, the kernel will raise swiotlb_map error. 
> I put the corresponding kernel log and driver files into it, 
> https://drive.google.com/file/d/10HQE6lr3W-XyqoI7OUBjQzJxwPCaEkpz/view?usp=sharing, 
> https://drive.google.com/file/d/1F8Hn2a7kPjZfSWiX525iSk634UHMo0Ph/view?usp=sharing

I see that there is no 32-bit addressable RAM in the system at
all, the lowest bit of system memory starts at 0x800254000 (32GB)

[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000800254000-0x0000000800254fff]
[    0.000000]   node   0: [mem 0x0000000810000000-0x000000083fffffff]
[    0.000000]   node   0: [mem 0x00000008c0000000-0x00000009bfffffff]
[    0.000000]   node   0: [mem 0x0000000c00000000-0x0000000c3fffffff]

Maybe this is something that can be set up differently by the boot
loader, otherwise this won't be the only last problem with 32-bit
DMA you see on this chip.

Try to configure it so that there is at least 1GB of RAM in ZONE_DMA32,
or in the ideal case move all of the MMIO out of the way so all of
RAM can stay contiguous starting at a low address.

      Arnd