Messages in this thread | | | Subject | Re: [PATCH] swiotlb: Add swiotlb=off to disable SWIOTLB | From | Florian Fainelli <> | Date | Thu, 18 Mar 2021 12:43:09 -0700 |
| |
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.
> > 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@gmail.com> >> >> 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? -- Florian
| |