ARM_LPAE + VMSPLIT_2G cause swiotlb warning on Raspberry Pi 4

[Robin Murphy]

On 2023-05-17 11:54, Arnd Bergmann wrote:
> On Wed, May 17, 2023, at 12:34, Arnd Bergmann wrote:
>> On Wed, May 17, 2023, at 12:24, Stefan Wahren wrote:
>>> Am 17.05.23 um 12:06 schrieb Robin Murphy:
>>>> On 2023-05-17 07:23, Stefan Wahren wrote:
>>
>> I think LPAE doesn't affect it, the configurations that Stefan
>> mentioned were LPAE with VMSPLIT_2G (broken), non-LPAE with
>> VMSPLIT_3G (works) and LPAE with VMSPLIT_3G (works). I would assume
>> that non-LPAE with VMSPLIT_2G or VMSPLIT_3G_OPT is also broken.
>>
>>> This one?
>>> [    0.000000] software IO TLB: area num 4.
>>> [    0.000000] software IO TLB: mapped [mem
>>> 0x0000000069e7f000-0x000000006de7f000] (64MB)
>>
>> Indeed, that is clearly above the .dma_zone_size value from
>> the machine descriptor.
> 
> It looks like Arm does not set the ARCH_LOW_ADDRESS_LIMIT
> constant for swiotlb, so it gets the default 4GB maximum.

Ah, so memblock_alloc_low() isn't able to do the right thing, that would 
explain it indeed.

> I think this would work on arm, though it's probably not the
> correct fix in general, as I think MAX_DMA_ADDRESS is meant
> to refer to the ISA_DMA_API limit, not the ZONE_DMA limit.:
> 
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -394,7 +394,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r)
>   #define MEMBLOCK_LOW_LIMIT 0
>   
>   #ifndef ARCH_LOW_ADDRESS_LIMIT
> -#define ARCH_LOW_ADDRESS_LIMIT  0xffffffffUL
> +#define ARCH_LOW_ADDRESS_LIMIT  MAX_DMA_ADDRESS
>   #endif
>   
>   phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
> 
> Can you give this a try?

Or perhaps do something similar to arm64 and define it in terms of 
arm_dma_pfn_limit?

Cheers,
Robin.

(And to clear up my own question from earlier, of course LPAE is 
significant since it's what selects SWIOTLB at all, derp.)