Message-Id: <05e13ba9-c1fe-450a-a159-9693edce0a23@app.fastmail.com>
Date: Fri, 11 Jul 2025 08:55:45 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "yangzh0906@...ndersoft.com" <yangzh0906@...ndersoft.com>
Cc: "Adrian Hunter" <adrian.hunter@...el.com>,
 "Ulf Hansson" <ulf.hansson@...aro.org>, "gordon.ge" <gordon.ge@....ai>,
 "linux-mmc @ vger . kernel . org" <linux-mmc@...r.kernel.org>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 5/8] mmc: sdhci: add Black Sesame Technologies BST C1200
 controller driver

On Fri, Jul 11, 2025, at 07:55, Albert Yang wrote:
> On Wed, Jul 2, 2025, at 11:44, Arnd Bergmann wrote:
> Regarding these last two suggestions, I'm not very familiar with the 
> implementation 
> details. Could you provide more guidance on:
>
> 1. **dma-ranges approach**: We tried adding these properties to the 
> device tree:
>    ```
>    dma-ranges = <0x00000000 0x00000000 0x100000000>;
>    dma-mask = <0xffffffff>;
>    ```
>    However, we still encounter DMA addressing issues. Are there 
> specific 
>    examples in other drivers we could reference for similar hardware 
> constraints?

The way that 'dma-ranges' is supposed to work is that it accurately
describes in the bus node how a child device accesses the parent
view of the physical address space.

The 'dma-mask' property above is not a regular property, but the
dma-ranges you have looks similar to what you have for a 1:1
mapping of the first 4GB, matching what you describe is the
actual hardware mistake, but you are using the wrong address/size
cells for this bus:

+	soc: soc@0 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges = <0x0 0x0 0x0 0x0 0xffffffff 0xffffffff>;

What your dts file describes is that there is a single 64-bit
bus named 'soc@0' that contains the entire 64-bit address
space. You have given an explicit 'ranges' property that
maps everything except for the final byte in the downstream
direction, which is equivalent to having an empty 'ranges'
property. You have left out the upstream 'dma-ranges'
translation, which I think means you just get the default
that matches 'ranges'.

Presumably neither of them are correct. In most SoCs there
is more than one bus, and you have already said above that
the actual bus that the sdhci device is on only uses 32-bit
addressing, which for a 1:1 translation would look like

+	soc: soc@0 {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges = <0x0 0x0 0x0 0x0 0x1 0x00000000>;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x00000000>;

meaning that doing an mmio access on the first 4GB of
CPU address space gets routed to this bus at the same
address, and that any device trying to do a DMA only
works on the first 4GB as well, which then correspond
to the bus itself, not to RAM. If that is your setup,
that would explain how the SRAM and SDHCI devices are
both on the same bus and the SDHCI can do DMA internally
on the bus, but cannot actually reach RAM.

A more sensible setup would be to have the DMA access
routed to the memory controller. Since memory on your
system appears to start at 0x8.00000000, that would look
like

        dma-ranges = <0x0 0x0  0x08 0x00000000  0x1 0x00000000>;

which means that a DMA to the first 4GB of the bus
address space gets routed outside of the bus into the
first 4GB of physical memory. Obviously you cannot just
change the dts to pretend this is the correct mapping, you
have to also program the bus controller to use it.

The datasheet for the chip should tell you specifically
what type of bus this is (AXI, AHB, OPB or something else),
and what registers are used to program this mapping. It
is possible that this cannot be reprogrammed, but more likely
there is a hidden register that is made available to the boot
loader but is not intended to be reconfigured by the OS.

> 2. **Moving RAM start position**: Which component would control this 
> configuration? 
>    Would this require bootloader parameter changes or SoC-level 
> configuration?

This would be in the early stages of the boot loader that set up
the memory controller, as it is hard to reconfigure the RAM
location after you are already running from DRAM.

> The v3 patch addresses all your code structure and documentation concerns 
> while providing a clear explanation of why this approach is necessary for 
> our platform. I have also fixed compilation warnings about unused variables 
> that resulted from the refactoring.
>
> **Current DMA Issues**: Despite setting DMA32_ZONE, we still encounter DMA 
> addressing warnings. Key error messages include:
> ```
> DMA addr 0x00000008113e2200+512 overflow (mask ffffffff, bus limit 0)
> software IO TLB: swiotlb_memblock_alloc: Failed to allocate [various sizes]
> ```
>
> This confirms our hardware limitation where the eMMC controller cannot access 
> memory above 32-bit boundaries, even with ZONE_DMA32 configured.

All that this confirms is that Linux observes an impossible configuration
where RAM starts above the DMA32 zone.

       Arnd

Powered by blists - more mailing lists