On 2021-03-18 19:43, Florian Fainelli wrote:
On 3/18/2021 12:34 PM, Robin Murphy wrote:
On 2021-03-18 19:22, Florian Fainelli wrote:
On 3/18/2021 12:18 PM, Florian Fainelli wrote:
It may be useful to disable the SWIOTLB completely for testing or when a
platform is known not to have any DRAM addressing limitations what so
ever.
Isn't that what "swiotlb=noforce" is for? If you're confident that we've
really ironed out *all* the awkward corners that used to blow up if
various internal bits were left uninitialised, then it would make sense
to just tweak the implementation of what we already have.
swiotlb=noforce does prevent dma_direct_map_page() from resorting to the
swiotlb, however what I am also after is reclaiming these 64MB of
default SWIOTLB bounce buffering memory because my systems run with
large amounts of reserved memory into ZONE_MOVABLE and everything in
ZONE_NORMAL is precious at that point.
It also forces io_tlb_nslabs to the minimum, so it should be claiming
considerably less than 64MB. IIRC the original proposal *did* skip
initialisation completely, but that turned up the aforementioned issues.
I wouldn't necessarily disagree with adding "off" as an additional alias
for "noforce", though, since it does come across as a bit wacky for
general use.
Signed-off-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
Christoph, in addition to this change, how would you feel if we
qualified the swiotlb_init() in arch/arm/mm/init.c with a:
if (memblock_end_of_DRAM() >= SZ_4G)
swiotlb_init(1)
Modulo "swiotlb=force", of course ;)
Indeed, we would need to handle that case as well. Does it sound
reasonable to do that to you as well?
I wouldn't like it done to me personally, but for arm64, observe what
mem_init() in arch/arm64/mm/init.c already does.
Robin.
