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@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? -- Florian
