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
