Re: Limiting the DMA zone in arm64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Nicolas et al.

On 11/07/2019 12:10, Nicolas Saenz Julienne wrote:
> Hi Will, thanks for your response.
> 
> [+ Matthias and Phill who might be interested ]
> 
> On Thu, 2019-07-11 at 11:17 +0100, Will Deacon wrote:
>> Hi Nicolas,
>>
>> [+Robin, Andrew and Marc since we've been playing with getting arm64 Linux
>>  up and running too]
>>
>> On Thu, Jul 11, 2019 at 11:51:57AM +0200, Nicolas Saenz Julienne wrote:
>>> I'm trying to bring up the new RPi4 on arm64, and running into issues with
>>> DMA
>>> allocations. The device has up to 4GB of ram, but AFAIK only the first GB of
>>> ram can be used for DMA: the DMA address range is 0xc0000000-0xffffffff
>>> which
>>> is aliased to the first GB of memory 0x00000000-0x40000000.
>>
>> Do you know for sure that these aliases are equivalant and so it's
>> inconsequential if we use the lower addresses for DMA?
> 
> No, they are not exactly equivalent, see the 'dma-ranges' I posted on my other
> reply. I was being overly generic to make the explanation simpler. The actual
> size of the aliasing is smaller.
> 
> That said, I don't think using the lower addresses would work for DMA. I tested
> some transfers and the offset is clearly being taken into account.
> 
>> Also, does this
>> limitation apply to all DMA-capable peripherals, or just some of them?
> 
> I infer from '.dma_zone_size = SZ_1G' and dma-ranges that it's a device wide
> limitation. Maybe Phill can contradict me.

It is a limitation for one of the internal buses used by many of the peripherals.
Newer components including the ARM cores, PCIe(*), GENET, and the 40-bit DMA
channels, have a different view of the address space where RAM starts at 0, and
peripherals etc. are positioned above 0x4_00000000.

>>> This is solved in arm32 using a board file with '.dma_zone_size = SZ_1G'.
>>> But I
>>> haven't found any similar mechanism for arm64. Any suggestions?
>>>
>>> Just it case it helps understand the issue, I managed to get things going by
>>> doing the following:
>>>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index f3c795278def..ec3cb7b76a76 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -407,7 +407,8 @@ void __init arm64_memblock_init(void)
>>>  
>>>         /* 4GB maximum for 32-bit only capable devices */
>>>         if (IS_ENABLED(CONFIG_ZONE_DMA32))
>>> -               arm64_dma_phys_limit = max_zone_dma_phys();
>>> +               arm64_dma_phys_limit = 0x40000000;
>>>         else
>>>                 arm64_dma_phys_limit = PHYS_MASK + 1;
>>
>> My superficial understanding (mainly from talking to Robin, who actually
>> knows how this works), is that we'd need to extend our support for
>> dma-ranges in order to limit ZONE_DMA32 as you're proposing above.
> 
> Noted.
> 
>> However, this may not help for streaming DMA, where we need to force
> everything
>> above 1G through a bounce buffer and likely requires something weird like
>> a 30-bit DMA mask.
>>
>> Do you know how streaming DMA is handled in the 32-bit port for rpi4?
> 
> Not really, I'll have a look and come back to you.

Phil

(*) The wrapper around the PCIe block has a bug preventing it from accessing beyond
the first 3GB of RAM.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [CentOS ARM]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]

  Powered by Linux