From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> To: linux-arm-kernel@lists.infradead.org, Robin Murphy <robin.murphy@arm.com>, iommu@lists.linux-foundation.org Cc: stefan.wahren@i2se.com, f.fainelli@gmail.com, catalin.marinas@arm.com, phil@raspberrypi.org, linux-kernel@vger.kernel.org, Jisheng.Zhang@synaptics.com, mbrugger@suse.com, will@kernel.org, hch@lst.de, Nicolas Saenz Julienne <nsaenzjulienne@suse.de>, m.szyprowski@samsung.com Subject: [RFC 0/4] Raspberry Pi 4 DMA addressing support Date: Wed, 17 Jul 2019 17:31:31 +0200 Message-ID: <20190717153135.15507-1-nsaenzjulienne@suse.de> (raw) Hi all, this series attempts to address some issues we found while bringing up the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow up to this: https://www.spinics.net/lists/arm-kernel/msg740650.html The new Raspberry Pi 4 has up to 4GB of ram but most devices can only address the first GB of ram: the DMA address range is 0xc0000000-0xfc000000 which is aliased to the first GB of memory 0x00000000-0x3c000000. Note that only some devices have this limitations, the ARM cores, PCIe, GENET, and 40-bit DMA channels have a wider view of the address space. This is solved in arm32 by setting up the correct '.dma_zone_size = SZ_1G' which takes care of the allocating the coherent memory area at the right spot and also is taken into account in the arch specific 'dma_map_ops'. Unfortunately there is no such thing as '.dma_zone_size' in arm64, to make things worse it's assumed that all devices will be able to adress the first 4GB of memory. This raises two issues: the coherent memory reserves are located in an area not accessible by most devices, and DMA streaming's dma_supported(), which fails for most devices since it's min_mask isn't properly set. Note that the rest if DMA streaming works fine thanks to the help of swiotlb. On one hand I've implemented a function that parses the 'dma-range' on all interconnects and tries to select a location for the coherent memory reserves that'll fit all devices. I made the algorithm as simple as possible, based on the existing devices limitations. On the other I've added a new variable in dma-direct that allows modifying the min_mask during the init process and taken care of setting it accordingly in the arm64's init code. Regards, Nicolas --- Nicolas Saenz Julienne (4): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: mm: parse dma-ranges in order to better estimate arm64_dma_phys_limit dma-direct: add dma_direct_min_mask arm64: mm: set direct_dma_min_mask according to dma-ranges arch/arm64/mm/init.c | 69 ++++++++++++++++++++++++++++++++++++++++---- kernel/dma/direct.c | 4 ++- 2 files changed, 67 insertions(+), 6 deletions(-) -- 2.22.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-17 15:31 Nicolas Saenz Julienne [this message] 2019-07-17 15:31 ` [RFC 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() Nicolas Saenz Julienne 2019-07-17 15:31 ` [RFC 2/4] arm64: mm: parse dma-ranges in order to better estimate arm64_dma_phys_limit Nicolas Saenz Julienne 2019-07-24 13:54 ` Catalin Marinas 2019-07-17 15:31 ` [RFC 3/4] dma-direct: add dma_direct_min_mask Nicolas Saenz Julienne 2019-07-18 9:15 ` Christoph Hellwig 2019-07-18 11:18 ` Nicolas Saenz Julienne 2019-07-19 13:08 ` Nicolas Saenz Julienne 2019-07-24 13:51 ` Catalin Marinas 2019-07-24 13:56 ` Christoph Hellwig 2019-07-24 14:27 ` Nicolas Saenz Julienne 2019-07-17 15:31 ` [RFC 4/4] arm64: mm: set direct_dma_min_mask according to dma-ranges Nicolas Saenz Julienne
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190717153135.15507-1-nsaenzjulienne@suse.de \ --to=nsaenzjulienne@suse.de \ --cc=Jisheng.Zhang@synaptics.com \ --cc=catalin.marinas@arm.com \ --cc=f.fainelli@gmail.com \ --cc=hch@lst.de \ --cc=iommu@lists.linux-foundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=mbrugger@suse.com \ --cc=phil@raspberrypi.org \ --cc=robin.murphy@arm.com \ --cc=stefan.wahren@i2se.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-ARM-Kernel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \ linux-arm-kernel@lists.infradead.org public-inbox-index linux-arm-kernel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git