Re: [PATCH] mmc: sdhci-xenon: Fix 2G limitation on AC5 SoC

[Vadym Kochan]

Hi Adrian,

On Wed, 9 Nov 2022 09:50:06 +0200, Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote:
> On 8/11/22 21:05, Vadym Kochan wrote:
> > Hi Adrian,
> > 
> > On Thu, 13 Oct 2022 09:40:00 +0300, Vadym Kochan <vadym.kochan@xxxxxxxxxxx> wrote:
> >> Hi Robin,
> >>
> >> On Mon, 22 Aug 2022 11:06:43 +0100, Robin Murphy <robin.murphy@xxxxxxx> wrote:
> >>> On 2022-08-21 07:17, Christoph Hellwig wrote:
> >>>> On Thu, Aug 18, 2022 at 03:07:40PM +0300, Vadym Kochan wrote:
> >>>>> It works with the following changes:
> >>>>>
> >>>>>      #1 dma-ranges = <0x0 0x0 0x2 0x0 0x0 0x80000000>;
> >>>>>
> >>>>>      #3 swiotlb="force"
> >>>>>
> >>>>> Is it OK to force the memory allocation from the start for the swiotlb ?
> >>>>
> >>>> It should be ok, but isn't really optimal.
> >>>>
> >>>> I wonder if we should just allow DT to specify the swiotlb buffer
> >>>> location.  Basically have yet another RESERVEDMEM_OF_DECLARE variant
> >>>> for it, which shouldn't be all that much work except for figuring
> >>>> out the interaction with the various kernel command line options.
> >>>
> >>> We already have all the information we need in the DT (and ACPI), the 
> >>> arm64 init code just needs to do a better job of interpreting it 
> >>> properly. I'll see what I can come up with once I've finished what I'm 
> >>> currently tied up in.
> >>>
> >>> Thanks,
> >>> Robin.
> >>
> >> Sorry to disturb you, I just 'd like to know if you have
> >> some ideas to share or patches to test ?
> >>
> >> Thank you!
> >>
> > 
> > Since AC5X eMMC controller can fail to work on boards with >2GB memory,
> > and considering that the best fix may not be easy (as it requires arm64 infra changes),
> > so would it be OK to use PIO mode as temporary solution ?
> > 
> > I understand that arm64 changes might not be trivial and it might take significant
> > amount of time to implement considering this unusual case, I just think that better
> > to make eMMC working even if it will be slow.
> 
> You can disable DMA if you wish:
> 	SDHCI_QUIRK_BROKEN_DMA | SDHCI_QUIRK_BROKEN_ADMA
> however did you consider SDMA:
> 	SDHCI_QUIRK_BROKEN_ADMA
> which uses a bounce buffer allocated by SDHCI?
> 
> In any case, you need to add comments to the code
> and commit message explaining the swiotlb issue.
> 

There is a snip from my earlier reply:

[snip]

> 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.

[snip]

Regards,
Vadym