From patchwork Sat Mar 13 09:24:10 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Kettenis X-Patchwork-Id: 1452476 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DyHM12r6bz9sRR for ; Sat, 13 Mar 2021 20:24:27 +1100 (AEDT) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 87BDD80475; Sat, 13 Mar 2021 10:24:17 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id AAE4180505; Sat, 13 Mar 2021 10:24:15 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2FD8A803AB for ; Sat, 13 Mar 2021 10:24:12 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id ecafc872; Sat, 13 Mar 2021 10:24:10 +0100 (CET) Date: Sat, 13 Mar 2021 10:24:10 +0100 (CET) From: Mark Kettenis To: u-boot@lists.denx.de CC: nsaenzjulienne@suse.de, sjg@chromium.org, sr@denx.de, mbrugger@suse.com Subject: [RFC] dev_phys_to_bus() and PCI Message-ID: X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.102.4 at phobos.denx.de X-Virus-Status: Clean I'm working on support for Apple's M1 systems in U-Boot. The idea is that this can be used as a "payload" for the m1n1 bootloader that is being developed by Hector Martin for Asahi Linux in order to provide an UEFI implementation that can boot a standard arm64 OS. My current code, which can be found on the "apple-m1-m1n1" branch at: https://github.com/kettenis/u-boot/tree/apple-m1-m1n1 can already do this. I'm booting OpenBSD/arm64 this way and I've also booted into grub using a standard arm64 Debian installer. One of the big challenges I'm facing is that the integrated PCIe devices on the system sit behind an IOMMU that (as far as we can tell) doesn't support any kind of bypass mode. I don't think we want full IOMMU support in U-Boot, so the approach I'm currently taking is that I set up the IOMMU to map a chunk of memory at the "top of RAM" where U-Boot resides after relocation. But in order to use this mapping I need to do DMA address translation. Fortunately Nicolas Saenz Julienne recently introduced dev_phys_to_bus() and dev_bus_to_phys() interfaces to do this. Those interfaces make use of a dma-ranges property in the device tree which doesn't work so well for PCI devices though. However, the PCI code in U-Boot already has a way to describe DMA address translation through its regions support. Hooking this up to dev_phys_to_bus() and dev_bus_to_phys() is fairly easy as illustrated by the diff below. Would this be viable approach? This could also help adding support for PCIe devices on the Raspberry Pi CM4. commit 4f0e989c7a765291a38b7d10da562f23c5f31239 Author: Mark Kettenis Date: Fri Mar 12 20:23:11 2021 +0100 dm: Add PCI support to dev_phys_to_bus()/dev_bus_to_phys() For PCI devices, call dm_pci_phys_to_bus()/dm_pci_bus_to_phys() to do the address translation. This uses the regions set up by the PCI host controller driver to do the translation as a single translation offset may not be sufficient in this case. Signed-off-by: Mark Kettenis diff --git a/include/phys2bus.h b/include/phys2bus.h index 866b8b51a8..13d23ef4bb 100644 --- a/include/phys2bus.h +++ b/include/phys2bus.h @@ -23,14 +23,21 @@ static inline unsigned long bus_to_phys(unsigned long bus) #if CONFIG_IS_ENABLED(DM) #include +#include static inline dma_addr_t dev_phys_to_bus(struct udevice *dev, phys_addr_t phys) { + if (device_is_on_pci_bus(dev)) + return dm_pci_phys_to_bus(dev, phys, PCI_REGION_SYS_MEMORY); + return phys - dev_get_dma_offset(dev); } static inline phys_addr_t dev_bus_to_phys(struct udevice *dev, dma_addr_t bus) { + if (device_is_on_pci_bus(dev)) + return dm_pci_bus_to_phys(dev, bus, PCI_REGION_SYS_MEMORY); + return bus + dev_get_dma_offset(dev); } #else