All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Vadym Kochan <vadym.kochan@plvision.eu>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	Christoph Hellwig <hch@infradead.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	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>,
	iommu@lists.linux.dev
Subject: Re: [PATCH] mmc: sdhci-xenon: Fix 2G limitation on AC5 SoC
Date: Wed, 17 Aug 2022 14:43:46 +0100	[thread overview]
Message-ID: <94888b3b-8f54-367d-c6b4-5ebfeeafe4c4@arm.com> (raw)
In-Reply-To: <20220816205129.GA6438@plvision.eu>

On 2022-08-16 21:51, Vadym Kochan wrote:
[...]
>> The one thing to watch out for is that SWIOTLB doesn't necessarily interact
>> very well with DMA offsets. Given the intent of
>> of_dma_get_max_cpu_address(), I think it ought to work out OK now for
>> current kernels on DT systems if everything is described correctly, but
>> otherwise it's likely that you end up with ZONE_DMA either being empty or
>> containing all memory, so the SWIOTLB buffer ends up being allocated
>> anywhere such that it might not actually work as expected.
>>
>> Robin.
> 
> Hi Robin,
> 
> Thank you for the reply.
> 
> My understanding is that swiotlb is allocated (in case of arm64)
> in the following cases:
> 
>     #1 when it is forced from the kernel cmdline
> 
>     #2 when max_pfn is greater than arm64_dma_phys_limit (and this is used
>        as the end from which to allocate the swiotlb pool in the
>        top-botom direction via memblock API).
> 
>     #3 using restricted dma-pool
> 
> Of course option #3 works fine because swiotlb is kind of forced to use
> particulary this range of memory.
> 
> Both options #1 & #2 causes to use full memory mask even if to specify
> dma-ranges in the DT:
> 
>      dma-ranges = <0x0 0x0 0x2 0x0 0x0 0x80000000>;
> 
> or if to specify the opposite:
> 
>      dma-ranges = <0x2 0x0 0x0 0x0 0x0 0x80000000>;
> 
>      just to make it lower than U32 to pass
> 
>          zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits)
> 
>      condition, but then it will be re-set in max_zone_phys() by:
> 
>       
> 	if (phys_start > U32_MAX)
> 		zone_mask = PHYS_ADDR_MAX;
> 	else if (phys_start > zone_mask)
> 		zone_mask = U32_MAX;

Ah, indeed I missed that, sorry. It seems that that change to stop 
assuming an offset kind of crossed over with the introduction of 
*_dma_get_max_cpu_address(), but now that that firmware property parsing 
*is* implemented, in principle it should be equally possible to evaluate 
the actual offsets as well, and decide whether an offset ZONE_DMA is 
appropriate or not. Either way, this is definitely the area which needs 
work if we want to to able to support topologies like this properly.

> So, currently I dont see how to pin swiotlb (I see it as a main problem) to some specific range of physical
> memory (particulary to the first 2G of RAM).

Indeed, if ZONE_DMA and/or ZONE_DMA32 can't be set appropriately, then 
there's no way to guarantee correct allocation of any DMA buffers, short 
of hacking it with explicitly placed reserved-memory carveouts.

Thanks,
Robin.

  reply	other threads:[~2022-08-17 13:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26 17:07 [PATCH] mmc: sdhci-xenon: Fix 2G limitation on AC5 SoC Vadym Kochan
2022-07-26 17:37 ` Florian Fainelli
2022-07-27 16:45   ` Vadym Kochan
2022-08-01  9:30     ` Vadym Kochan
2022-08-08  9:19       ` Adrian Hunter
2022-08-08  9:52         ` Vadym Kochan
2022-08-08 10:29           ` Vadym Kochan
2022-08-08 11:40           ` Adrian Hunter
2022-08-08 12:26             ` Vadym Kochan
2022-08-08 12:58               ` Adrian Hunter
2022-08-08 14:06                 ` Robin Murphy
2022-08-16 20:51                   ` Vadym Kochan
2022-08-17 13:43                     ` Robin Murphy [this message]
2022-08-17 16:07                       ` Vadym Kochan
2022-08-17 17:23                         ` Robin Murphy
2022-08-18 12:07                           ` Vadym Kochan
2022-08-21  6:17                             ` Christoph Hellwig
2022-08-22 10:06                               ` Robin Murphy
2022-09-06  9:22                                 ` Vadym Kochan
2022-10-13  6:40                                 ` Vadym Kochan
2022-11-08 19:05                                   ` Vadym Kochan
2022-11-09  7:50                                     ` Adrian Hunter
2022-11-09  8:40                                       ` Vadym Kochan
2022-11-09  9:29                                         ` Adrian Hunter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94888b3b-8f54-367d-c6b4-5ebfeeafe4c4@arm.com \
    --to=robin.murphy@arm.com \
    --cc=adrian.hunter@intel.com \
    --cc=enachman@marvell.com \
    --cc=f.fainelli@gmail.com \
    --cc=hch@infradead.org \
    --cc=huziji@marvell.com \
    --cc=iommu@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=vadym.kochan@plvision.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.