From patchwork Mon Oct 17 15:26:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Punit Agrawal X-Patchwork-Id: 9379631 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B7D6E6086B for ; Mon, 17 Oct 2016 15:29:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A823E2921C for ; Mon, 17 Oct 2016 15:29:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9CA8A2924A; Mon, 17 Oct 2016 15:29:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9C7142921C for ; Mon, 17 Oct 2016 15:29:04 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bw9pE-0003R7-Gn; Mon, 17 Oct 2016 15:27:40 +0000 Received: from fw-tnat.cambridge.arm.com ([217.140.96.140] helo=cam-smtp0.cambridge.arm.com) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bw9pA-0003MT-7Y for linux-arm-kernel@lists.infradead.org; Mon, 17 Oct 2016 15:27:37 +0000 Received: from e105922-lin.cambridge.arm.com (e105922-lin.cambridge.arm.com [10.1.195.25]) by cam-smtp0.cambridge.arm.com (8.13.8/8.13.8) with SMTP id u9HFQa63018404; Mon, 17 Oct 2016 16:26:36 +0100 Received: by e105922-lin.cambridge.arm.com (sSMTP sendmail emulation); Mon, 17 Oct 2016 16:26:36 +0100 From: Punit Agrawal To: linux-doc@vger.kernel.org Subject: [PATCH] Documentation: DMA-API: Clarify semantics of dma_set_mask_and_coherent Date: Mon, 17 Oct 2016 16:26:23 +0100 Message-Id: <20161017152623.7649-1-punit.agrawal@arm.com> X-Mailer: git-send-email 2.9.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161017_082736_647090_203BA357 X-CRM114-Status: GOOD ( 16.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: arnd@arndb.de, Jonathan Corbet , dwmw2@infradead.org, joro@8bytes.org, Punit Agrawal , will.deacon@arm.com, linux-kernel@vger.kernel.org, robin.murphy@arm.com, linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP The dma mapping api howto gives the impression that using the dma_set_mask_and_coherent (and related DMA APIs) will cause the kernel to check all the components in the path from the device to memory for addressing restrictions. In systems with address translations between the device and memory (e.g., when using IOMMU), this implies that a successful call to set set dma mask has checked the addressing constraints of the intermediaries as well. For the IOMMU drivers in the tree, the check is actually performed while allocating the DMA buffer rather than when the DMA mask is configured. For MMUs that do not support the full device addressing capability, the allocations are made from a reduced address space. Update the documentation to clarify that even though the call to dma_set_mask_and_coherent succeeds, it may not be possible to use the full addressing capability of the device. Signed-off-by: Punit Agrawal Cc: Jonathan Corbet --- Documentation/DMA-API-HOWTO.txt | 39 +++++++++++++++++++++++---------------- 1 file changed, 23 insertions(+), 16 deletions(-) diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 979228b..240d1ee 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -159,39 +159,46 @@ support 64-bit addressing (DAC) for all transactions. And at least one platform (SGI SN2) requires 64-bit consistent allocations to operate correctly when the IO bus is in PCI-X mode. -For correct operation, you must interrogate the kernel in your device -probe routine to see if the DMA controller on the machine can properly -support the DMA addressing limitation your device has. It is good +For correct operation, you must inform the kernel in your device probe +routine to see if the DMA controller on the machine can properly +support the DMA addressing capabilities your device has. It is good style to do this even if your device holds the default setting, because this shows that you did think about these issues wrt. your device. -The query is performed via a call to dma_set_mask_and_coherent(): +The call to inform the kernel is performed via a call to +dma_set_mask_and_coherent(): int dma_set_mask_and_coherent(struct device *dev, u64 mask); -which will query the mask for both streaming and coherent APIs together. -If you have some special requirements, then the following two separate -queries can be used instead: +which will set the mask for both streaming and coherent APIs together. +If there are some special requirements, then the following two +separate functions can be used instead: - The query for streaming mappings is performed via a call to - dma_set_mask(): + The configuration for streaming mappings is performed via a + call to dma_set_mask(): int dma_set_mask(struct device *dev, u64 mask); - The query for consistent allocations is performed via a call - to dma_set_coherent_mask(): + The configuration for consistent allocations is performed via + a call to dma_set_coherent_mask(): int dma_set_coherent_mask(struct device *dev, u64 mask); Here, dev is a pointer to the device struct of your device, and mask is a bit mask describing which bits of an address your device supports. It returns zero if your card can perform DMA properly on -the machine given the address mask you provided. In general, the -device struct of your device is embedded in the bus-specific device -struct of your device. For example, &pdev->dev is a pointer to the -device struct of a PCI device (pdev is a pointer to the PCI device -struct of your device). +the machine given the address mask you provided. Subsequent to +calling the above apis, DMA allocations will be made from address +space that conforms to the mask. The DMA allocation space maybe +further restricted if devices along the patch to memory have stricter +addressing requirements than the device performing the DMA, e.g., +IOMMU. + +In general, the device struct of your device is embedded in the +bus-specific device struct of your device. For example, &pdev->dev is +a pointer to the device struct of a PCI device (pdev is a pointer to +the PCI device struct of your device). If it returns non-zero, your device cannot perform DMA properly on this platform, and attempting to do so will result in undefined