From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 000FCC54FC6 for ; Tue, 3 Sep 2024 01:50:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=X9iG98dEvq04AGEMutnpDlFoqVd/WwSRtuicsdL3LGI=; b=G/CbccyyuUjF9H jIEAmt03/M/n3tktT+SHw+hgxoSdlIOBUOV3eGP7im1f/OhATLgkRUzQfwu5E22JqRa4YvJRCHinv okofYRwYkc9sO/DsrKbTlzwBPsz5982XUmqNN3Q43fA7RmE7NJKqgffUCz3q7asamk2doZlekaihO 4tR0YivKRdG5PJUOycxD2b1LBcOgoCi6NzifOR/ZeCCqSbUmeR04n1FWPMtS1veb/+Ec9XmTYKBiU yl6U4kqB8n82+HeIuIAgWNjY0pqxbTqBYyWvbr9u2dAoNSZNUrdaVFZ/znxtn730QXFvBu3/j2JRP g0FqUjmzE2LJEPla5UQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1slIgd-0000000Fz9y-3AMa; Tue, 03 Sep 2024 01:50:27 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1slIfj-0000000FyzR-3Njc for linux-arm-kernel@lists.infradead.org; Tue, 03 Sep 2024 01:49:33 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A62C55C58CD; Tue, 3 Sep 2024 01:49:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FF07C4CEC2; Tue, 3 Sep 2024 01:49:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725328169; bh=MYd+BDZHjT4A49/uPMG3JKdeSg29HklOPqAeNtZYWOQ=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=U+QeXC2X1xudw533PDy63Jd71UFCyOegTYWfMWdJdl3xMIYgieBBJ57QEvO6Nuiju ziBP/E56LLdhirSIbhjy6x8sI34F8nBb45hV5jKNdTLAXJbkMwucnaexUitgrIYxxx eTtBCzAXlxQ2SUJPDMXoKkV79upiyjETusnKFJJMF/oa5meQdZusy5ltBUMmusM8d1 ymNSYkz94NenKd1w/Ilg0MKS5kNr+lt5tLnXLPvVCc29bzwaY1pZtvgAxvsZytlsAT m/Ng3cEBcXjRjxAROcOECAXlXd2LxDMc/Fmtw48XMcjld5OPjdSWg1GgKdwiiCnokn o+iSZYY52Z6CQ== Date: Mon, 2 Sep 2024 20:49:27 -0500 From: Bjorn Helgaas To: Frank Li Cc: Richard Zhu , Lucas Stach , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rob Herring , Bjorn Helgaas , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Philipp Zabel , Liam Girdwood , Mark Brown , Manivannan Sadhasivam , Krzysztof Kozlowski , Conor Dooley , linux-pci@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH v8 11/11] PCI: imx6: Add i.MX8Q PCIe root complex (RC) support Message-ID: <20240903014927.GA230795@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240729-pci2_upstream-v8-11-b68ee5ef2b4d@nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240902_184931_937547_E44E7181 X-CRM114-Status: GOOD ( 16.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jul 29, 2024 at 04:18:18PM -0400, Frank Li wrote: > From: Richard Zhu > > Implement i.MX8Q (i.MX8QM, i.MX8QXP, and i.MX8DXL) PCIe RC support. While > the controller resembles that of iMX8MP, the PHY differs significantly. > Notably, there's a distinction between PCI bus addresses and CPU addresses. This bus/CPU address distinction is unrelated to the PHY despite the fact that this phrasing suggests they might be related. > Introduce IMX_PCIE_FLAG_CPU_ADDR_FIXUP in drvdata::flags to indicate driver > need the cpu_addr_fixup() callback to facilitate CPU address to PCI bus > address conversion according to "ranges" property. I actually don't understand why the .cpu_addr_fixup() callback exists at all. I guess this is my lack of understanding here, but on the ACPI side, if CPU addresses and PCI bus addresses are different, ACPI tells us how to convert them. It seems like it should be analogous for DT. > +static u64 imx_pcie_cpu_addr_fixup(struct dw_pcie *pcie, u64 cpu_addr) > +{ > + struct imx_pcie *imx_pcie = to_imx_pcie(pcie); > + struct dw_pcie_rp *pp = &pcie->pp; > + struct resource_entry *entry; > + unsigned int offset; > + > + if (!(imx_pcie->drvdata->flags & IMX_PCIE_FLAG_CPU_ADDR_FIXUP)) > + return cpu_addr; > + > + entry = resource_list_first_type(&pp->bridge->windows, IORESOURCE_MEM); > + offset = entry->offset; I would have assumed that if the DT is correct, "offset" will be zero for platforms where PCI bus addresses are identical to CPU addresses, so we could (and *should*) do this for all platforms, not just IMX8Q. But I must be missing something? > + return (cpu_addr - offset); > +}