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: 40917 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wg0-f72.google.com (mail-wg0-f72.google.com [74.125.82.72]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id E067921F5F for ; Mon, 17 Nov 2014 14:12:27 +0000 (UTC) Received: by mail-wg0-f72.google.com with SMTP id y19sf1168798wgg.3 for ; Mon, 17 Nov 2014 06:12:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:cc:subject:message-id :user-agent:mime-version:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe:content-type; bh=T7qergv54aJzo/nRmIg/n7uYurE01Pv+vy3LzLJf7Ns=; b=HcHC2tR9GiHGyHgFkkDrXIA3fgwUjTp6R3IHx7i+ncYnTidvj8feB1O5KWhkCU9piz K9QgUgdB2qJjmBK/DniRGgrCPeRS609kSRGwXmtFdIm4I6LKt6zyvKby40hy0XK/SHtK eMOKzRXT9LDT1Zo4tG2N5rNQcT2bDKL/glX9rd8oixw8AD5UcVLsvRXcWvnibW9KSvLb 9wkuzCWzM3iDWZr2CKqvMMqPmbjX6RUE/SBAmrSjcdutcBEp50sPU0I+tnZB7LpUJa6e WXSE8lOrpflWOvc596h5thqGut6eeSBmOuN+PLMTOeez+BAMsuuIFqlG5m27KvhG09fY g+hw== X-Gm-Message-State: ALoCoQnEyubA4bfUdV3My+rIpFW3qmmyXeObKnkf0L0T/I4WQTbO1/eOnYUKUvBb4YU1j04l5nbe X-Received: by 10.152.37.37 with SMTP id v5mr70311laj.9.1416233547098; Mon, 17 Nov 2014 06:12:27 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.205.10 with SMTP id lc10ls426015lac.22.gmail; Mon, 17 Nov 2014 06:12:26 -0800 (PST) X-Received: by 10.112.133.138 with SMTP id pc10mr28074138lbb.48.1416233546520; Mon, 17 Nov 2014 06:12:26 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com. [209.85.215.43]) by mx.google.com with ESMTPS id q9si51953571lag.92.2014.11.17.06.12.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 06:12:26 -0800 (PST) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; Received: by mail-la0-f43.google.com with SMTP id ge10so18649241lab.30 for ; Mon, 17 Nov 2014 06:12:26 -0800 (PST) X-Received: by 10.152.116.102 with SMTP id jv6mr14235458lab.40.1416233546239; Mon, 17 Nov 2014 06:12:26 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.184.201 with SMTP id ew9csp1158365lbc; Mon, 17 Nov 2014 06:12:25 -0800 (PST) X-Received: by 10.68.87.37 with SMTP id u5mr4464708pbz.128.1416233542652; Mon, 17 Nov 2014 06:12:22 -0800 (PST) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gx1si35183055pbd.158.2014.11.17.06.12.21 for ; Mon, 17 Nov 2014 06:12:22 -0800 (PST) Received-SPF: none (google.com: linux-kernel-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752971AbaKQOMS (ORCPT + 26 others); Mon, 17 Nov 2014 09:12:18 -0500 Received: from smtp.citrix.com ([66.165.176.89]:33751 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752408AbaKQOMQ (ORCPT ); Mon, 17 Nov 2014 09:12:16 -0500 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: CC: David Vrabel , Ian Campbell , , , , , , , Stefano Stabellini , , , , , , , , , , , , , , 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: stefano.stabellini@eu.citrix.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.43 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , 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 --- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ 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,