From patchwork Mon Nov 17 14:11:51 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 5321721 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id C8450C11AC for ; Mon, 17 Nov 2014 14:41:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F057D2012F for ; Mon, 17 Nov 2014 14:41:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E18002011B for ; Mon, 17 Nov 2014 14:41:24 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XqNRv-00066D-Cu; Mon, 17 Nov 2014 14:38:39 +0000 Received: from smtp.citrix.com ([66.165.176.89]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XqN2l-00065z-PK for linux-arm-kernel@lists.infradead.org; Mon, 17 Nov 2014 14:12:41 +0000 X-IronPort-AV: E=Sophos;i="5.07,403,1413244800"; d="scan'208";a="192046949" Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.3.181.6; Mon, 17 Nov 2014 09:12:12 -0500 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1XqN2I-000508-7z; Mon, 17 Nov 2014 14:12:10 +0000 Date: Mon, 17 Nov 2014 14:11:51 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Subject: [RFC] add a struct page* parameter to dma_map_ops.unmap_page Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141117_061240_147607_25578424 X-CRM114-Status: GOOD ( 12.14 ) X-Spam-Score: -5.0 (-----) Cc: linux-mips@linux-mips.org, airlied@linux.ie, dri-devel@lists.freedesktop.org, xen-devel@lists.xensource.com, linux@arm.linux.org.uk, vinod.koul@intel.com, deller@gmx.de, Stefano Stabellini , jejb@parisc-linux.org, Ian Campbell , konrad.wilk@oracle.com, alexander.deucher@amd.com, bhelgaas@google.com, linux-arm-kernel@lists.infradead.org, linux-parisc@vger.kernel.org, dwmw2@infradead.org, linux-kernel@vger.kernel.org, ralf@linux-mips.org, iommu@lists.linux-foundation.org, David Vrabel , dmaengine@vger.kernel.org, torvalds@linux-foundation.org, christian.koenig@amd.com X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, I am writing this email to ask for your advice. On architectures where dma addresses are different from physical addresses, it can be difficult to retrieve the physical address of a page from its dma address. Specifically this is the case for Xen on arm and arm64 but I think that other architectures might have the same issue. Knowing the physical address is necessary to be able to issue any required cache maintenance operations when unmap_page, sync_single_for_cpu and sync_single_for_device are called. Adding a struct page* parameter to unmap_page, sync_single_for_cpu and sync_single_for_device would make Linux dma handling on Xen on arm and arm64 much easier and quicker. I think that other drivers have similar problems, such as the Intel IOMMU driver having to call find_iova and walking down an rbtree to get the physical address in its implementation of unmap_page. Callers have the struct page* in their hands already from the previous map_page call so it shouldn't be an issue for them. A problem does exist however: there are about 280 callers of dma_unmap_page and pci_unmap_page. We have even more callers of the dma_sync_single_for_* functions. Is such a change even conceivable? How would one go about it? I think that Xen would not be the only one to gain from it, but I would like to have a confirmation from others: given the magnitude of the changes involved I would actually prefer to avoid them unless multiple drivers/archs/subsystems could really benefit from them. Cheers, Stefano diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index d5d3881..158a765 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -31,8 +31,9 @@ struct dma_map_ops { unsigned long offset, size_t size, enum dma_data_direction dir, struct dma_attrs *attrs); - void (*unmap_page)(struct device *dev, dma_addr_t dma_handle, - size_t size, enum dma_data_direction dir, + void (*unmap_page)(struct device *dev, struct page *page, + dma_addr_t dma_handle, size_t size, + enum dma_data_direction dir, struct dma_attrs *attrs); int (*map_sg)(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir, @@ -41,10 +42,10 @@ struct dma_map_ops { struct scatterlist *sg, int nents, enum dma_data_direction dir, struct dma_attrs *attrs); - void (*sync_single_for_cpu)(struct device *dev, + void (*sync_single_for_cpu)(struct device *dev, struct page *page, dma_addr_t dma_handle, size_t size, enum dma_data_direction dir); - void (*sync_single_for_device)(struct device *dev, + void (*sync_single_for_device)(struct device *dev, struct page *page, dma_addr_t dma_handle, size_t size, enum dma_data_direction dir); void (*sync_sg_for_cpu)(struct device *dev,