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 6AADDC76195 for ; Mon, 27 Mar 2023 17:02:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=DxsGl0SBNN0QS/jRaauWO2BmhExLZfwMp3Uv9d1WesY=; b=WX57h3Ici783M/ 86pkIny/bWJKolAqxyB0K4PSKyZYnRd9KsKlgOHShJtgXriIECB8hPgBxheGhHirzXC1nOu2VFtd7 1MEVO9TNVyWzMfjTuvc2qnB1vHBpJyQ54pSzKYxmF+B7fJY+GeU/E7ZeQcxQ4bXsb7UPkaXbvHqBE 5Mphja4WEhofLdu9pBX6Tf9x1xDe1ppmqbl2cm9h5x6XzE5zf3sCn2Gj0ropXmQ7Y1k122i+KP/v8 VNAyViKfTnvcVWZ4nnAJC+6ZEdFsQsfqMIYzkGdu8h01lV11TE2E/xhBHZDE4Zvj0fO54FE9Lp2Ry TV8GAeR+f1l4mdThgiVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pgqET-00BoQ1-2a; Mon, 27 Mar 2023 17:02:09 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pgqEL-00BoKE-04 for linux-arm-kernel@lists.infradead.org; Mon, 27 Mar 2023 17:02:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D6142F4; Mon, 27 Mar 2023 10:02:38 -0700 (PDT) Received: from [10.57.53.238] (unknown [10.57.53.238]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 932F03F6C4; Mon, 27 Mar 2023 10:01:52 -0700 (PDT) Message-ID: <15102094-10d3-b160-59cc-d5b9b93ae1b3@arm.com> Date: Mon, 27 Mar 2023 18:01:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v4 7/8] PCI: dwc: Introduce configurable DMA mask Content-Language: en-GB To: Rob Herring , Elad Nachman Cc: thomas.petazzoni@bootlin.com, bhelgaas@google.com, lpieralisi@kernel.org, kw@linux.com, krzysztof.kozlowski+dt@linaro.org, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230313124016.17102-1-enachman@marvell.com> <20230313124016.17102-8-enachman@marvell.com> <20230317182323.GA2445959-robh@kernel.org> From: Robin Murphy In-Reply-To: <20230317182323.GA2445959-robh@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230327_100201_107508_B5D88DA7 X-CRM114-Status: GOOD ( 16.78 ) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2023-03-17 18:23, Rob Herring wrote: > +Robin > > On Mon, Mar 13, 2023 at 02:40:15PM +0200, Elad Nachman wrote: >> From: Elad Nachman >> >> Some devices, such as AC5 and AC5X have their physical DDR memory >> start at address 0x2_0000_0000. In order to have the DMA coherent >> allocation succeed later, a different DMA mask is required, as >> defined in the DT file for such SOCs, using dma-ranges. > > I'm afraid this is not right. 'dma-ranges' in the PCI host bridge node > applies to PCI devices (i.e. child node), not the host bridge itself. > It's 'dma-ranges' in the parent node of the host bridge that applies > here. The core code will set masks (ranges really now) based on bus > restrictions. The mask for the device should only be based on the > device's limits (i.e. the device is 32-bit only). > > I think you will need whatever solution comes out of this thread[1]. Right, "make the allocation succeed later" is entirely missing the point of this code. The only reason we're doing that allocation at all is to reserve a 32-bit bus address. If it fails, it means we can't reliably support endpoints with only a 32-bit MSI capability. Using a bigger mask in order to successfully reserve a >32-bit bus address basically *guarantees* that you can't support endpoints with only a 32-bit MSI capability. Thanks Rob for digging up that thread; the original idea there should still be fine, but the alternative suggestion from Serge at the end is potentially even better for this situation where it's down to the SoC's memory map rather than the kernel config. It just needs somebody with sufficient motivation and resources to write and test a patch :) Robin. > > Rob > > [1] https://lore.kernel.org/all/c014b074-6d7f-773b-533a-c0500e239ab8@arm.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel