Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9a248303-7a27-e90e-76b3-c01a00be4e3d@intel.com>
Date:   Mon, 8 Aug 2022 12:19:10 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.11.0
Subject: Re: [PATCH] mmc: sdhci-xenon: Fix 2G limitation on AC5 SoC
Content-Language: en-US
To:     Vadym Kochan <vadym.kochan@plvision.eu>,
        Florian Fainelli <f.fainelli@gmail.com>
Cc:     Hu Ziji <huziji@marvell.com>, Ulf Hansson <ulf.hansson@linaro.org>,
        linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Elad Nachman <enachman@marvell.com>
References: <20220726170711.30324-1-vadym.kochan@plvision.eu>
 <139317dc-15e2-ac63-0e04-295e715a7747@gmail.com>
 <20220727164532.GA19351@plvision.eu> <20220801093044.GA22721@plvision.eu>
From:   Adrian Hunter <adrian.hunter@intel.com>
Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki,
 Business Identity Code: 0357606 - 4, Domiciled in Helsinki
In-Reply-To: <20220801093044.GA22721@plvision.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 1/08/22 12:30, Vadym Kochan wrote:
> Hi Florian,
> 
> On Wed, Jul 27, 2022 at 07:45:32PM +0300, Vadym Kochan wrote:
>> Hi Florian,
>>
>> On Tue, Jul 26, 2022 at 10:37:46AM -0700, Florian Fainelli wrote:
>>> On 7/26/22 10:07, Vadym Kochan wrote:
>>>> From: Elad Nachman <enachman@marvell.com>
>>>>
>>>> There is a limitation on AC5 SoC that mmc controller
>>>> can't have DMA access over 2G memory.
>>>>
>>>> Signed-off-by: Elad Nachman <enachman@marvell.com>
>>>> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu>
>>>> ---
>>>>  drivers/mmc/host/sdhci-xenon.c | 13 +++++++++++++
>>>>  1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
>>>> index 08e838400b52..666d06b58564 100644
>>>> --- a/drivers/mmc/host/sdhci-xenon.c
>>>> +++ b/drivers/mmc/host/sdhci-xenon.c
>>>> @@ -18,6 +18,7 @@
>>>>  #include <linux/of.h>
>>>>  #include <linux/pm.h>
>>>>  #include <linux/pm_runtime.h>
>>>> +#include <linux/mm.h>
>>>>  
>>>>  #include "sdhci-pltfm.h"
>>>>  #include "sdhci-xenon.h"
>>>> @@ -422,6 +423,8 @@ static int xenon_probe_params(struct platform_device *pdev)
>>>>  	struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>>  	u32 sdhc_id, nr_sdhc;
>>>>  	u32 tuning_count;
>>>> +	struct device_node *np = pdev->dev.of_node;
>>>> +	struct sysinfo si;
>>>>  
>>>>  	/* Disable HS200 on Armada AP806 */
>>>>  	if (priv->hw_version == XENON_AP806)
>>>> @@ -450,6 +453,15 @@ static int xenon_probe_params(struct platform_device *pdev)
>>>>  	}
>>>>  	priv->tuning_count = tuning_count;
>>>>  
>>>> +	si_meminfo(&si);
>>>> +
>>>> +	if (of_device_is_compatible(np, "marvell,ac5-sdhci") &&
>>>> +	    ((si.totalram * si.mem_unit) > 0x80000000 /*2G*/)) {
>>>
>>> Why not limit the DMA mask of the device and ensure, that bounce buffers get used so you can still do DMA?
>>>
>>> Also, you ought to be able to describe that limitation using Device Tree (assuming this is an option) and declaring a dedicated bus node for the SDHCI controller and providing a suitable dma-ranges property, see: arch/arm/boot/dts/bcm2711.dtsi and the 'soc' node for such examples.
>>>
>>>
>>
> 
> I could use DMA only in 2 ways:
> 
> #1 Use sdhci bounce buffer with SDMA mode
> 
>     But there was the issue that SDMA requires that SDHCI v4 mode should
>     be enabled, and when I enable it via sdhci_enable_v4_mode(host)
>     then I got error that EXT_CSD can't be recognized.
> 
>     But if I comment this line in sdhci.c:
>     
>     int sdhci_setup_host(struct sdhci_host *host)
>     {
>         ...
> 
> 	/* SDMA does not support 64-bit DMA if v4 mode not set */
> 	if ((host->flags & SDHCI_USE_64_BIT_DMA) && !host->v4_mode) {
> 		pr_info("XXX SDMA does not support 64-bit DMA if v4 mode not set\n");
> 		host->flags &= ~SDHCI_USE_SDMA;
> 	}
> 
>        ...
>     }
> 
>     then everything is OK.
> 
> #2 Use restricted-dma-pool in device-tree
> 
>    But I am not sure if it is good solution compared to #1.
> 
> Setting only DMA mask did not help because after some time I got
> "DMA overflow address" error stack-traces.

AFAICT using a DMA mask is the correct way to solve this.  If that
reveals another issue then that must be resolved also. Can you show
the stack traces and what kernel they are from?

> 
>> Do I understand correctly that the swiotlb will be used in case DMA
>> engine could not map the page in the specified range (limited by dma-ranges or
>> dma-mask) ?
>>
>>>
>>>> +		host->quirks |= SDHCI_QUIRK_BROKEN_DMA;
>>>> +		host->quirks |= SDHCI_QUIRK_BROKEN_ADMA;
>>>> +		dev_info(mmc_dev(mmc), "Disabling DMA because of 2GB DMA access limit.\n");
>>>> +	}
>>>> +
>>>>  	return xenon_phy_parse_params(dev, host);
>>>>  }
>>>>  
>>>> @@ -682,6 +694,7 @@ static const struct of_device_id sdhci_xenon_dt_ids[] = {
>>>>  	{ .compatible = "marvell,armada-ap807-sdhci", .data = (void *)XENON_AP807},
>>>>  	{ .compatible = "marvell,armada-cp110-sdhci", .data =  (void *)XENON_CP110},
>>>>  	{ .compatible = "marvell,armada-3700-sdhci", .data =  (void *)XENON_A3700},
>>>> +	{ .compatible = "marvell,ac5-sdhci", .data = (void *)XENON_AP806},
>>>>  	{}
>>>>  };
>>>>  MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
>>>
>>>
>>> -- 
>>> Florian
>>
>> Thanks,
>>
> 
> Regards,