From patchwork Wed Mar 26 18:49:57 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 27158 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pa0-f71.google.com (mail-pa0-f71.google.com [209.85.220.71]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 1D2B620062 for ; Wed, 26 Mar 2014 18:52:25 +0000 (UTC) Received: by mail-pa0-f71.google.com with SMTP id kq14sf5719094pab.6 for ; Wed, 26 Mar 2014 11:52:25 -0700 (PDT) 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:in-reply-to:message-id :references:user-agent:mime-version:cc:subject:precedence:list-id :list-unsubscribe:list-post:list-help:list-subscribe:sender :errors-to:x-original-sender:x-original-authentication-results :mailing-list:list-archive:content-type:content-transfer-encoding; bh=g6GBdMnAQDl/9OGPH0A2SiAnqsnhS/1iQw2toSEUZSs=; b=ZXHaWmqbYlQ5OlqD68FPoGFIzdqNO30eZYqBR7XL5Ow6IhAIIwzaDQVW8Ur3OIMXyR Afv4TzvwT0lZaaCnbF11192+hIjj1tPFpjjGalDk7Hu8WmiDtYLgNGNB6RFAa3g7gJEM VTBN/Cw2yxEmH3vSAiphxnhzaIzpPqIkhRlrghJd9fqNYU2Miw7qHsIY8+tpYN5yz12L 2bPCJzUy4T2DI5MXaFvcFJr5I0BQHFcfPb75NOjurf2uaQ4dX40dDV9cTVFWm0/rFyaL knyUjfDJY7xZY7g8mFIQHxSTlz+gLae46E/S2fLJbnjawTR3RsSGXLVVIoUdg18UPaQF sjpQ== X-Gm-Message-State: ALoCoQn5lZUWHYjQuI3IylesVEWKESGok6mXZaMvw21fjH3MTdqXFq6MaCv/YD2taxDgPchqKJ+X X-Received: by 10.68.253.66 with SMTP id zy2mr31979663pbc.1.1395859945155; Wed, 26 Mar 2014 11:52:25 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.94.78 with SMTP id f72ls854082qge.86.gmail; Wed, 26 Mar 2014 11:52:25 -0700 (PDT) X-Received: by 10.58.179.115 with SMTP id df19mr57831vec.41.1395859945017; Wed, 26 Mar 2014 11:52:25 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx.google.com with ESMTPS id jl10si4734269veb.177.2014.03.26.11.52.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 11:52:25 -0700 (PDT) Received-SPF: neutral (google.com: 209.85.220.175 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.220.175; Received: by mail-vc0-f175.google.com with SMTP id lh14so2919627vcb.20 for ; Wed, 26 Mar 2014 11:52:24 -0700 (PDT) X-Received: by 10.58.37.232 with SMTP id b8mr2064775vek.27.1395859944917; Wed, 26 Mar 2014 11:52:24 -0700 (PDT) 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.220.78.9 with SMTP id i9csp69665vck; Wed, 26 Mar 2014 11:52:24 -0700 (PDT) X-Received: by 10.50.116.206 with SMTP id jy14mr652503igb.10.1395859944158; Wed, 26 Mar 2014 11:52:24 -0700 (PDT) Received: from lists.xen.org (lists.xen.org. [50.57.142.19]) by mx.google.com with ESMTPS id ml3si3872319igb.3.2014.03.26.11.52.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 26 Mar 2014 11:52:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of xen-devel-bounces@lists.xen.org designates 50.57.142.19 as permitted sender) client-ip=50.57.142.19; Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WSsuH-0007Vd-Pq; Wed, 26 Mar 2014 18:50:33 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WSsuF-0007VK-Ud for xen-devel@lists.xenproject.org; Wed, 26 Mar 2014 18:50:32 +0000 Received: from [85.158.137.68:19501] by server-3.bemta-3.messagelabs.com id 86/F0-05289-77123335; Wed, 26 Mar 2014 18:50:31 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1395859829!1680561!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18202 invoked from network); 26 Mar 2014 18:50:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 26 Mar 2014 18:50:30 -0000 X-IronPort-AV: E=Sophos;i="4.97,737,1389744000"; d="scan'208";a="115186436" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 26 Mar 2014 18:50:29 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Wed, 26 Mar 2014 14:50:27 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WSsuB-0004I6-Rs; Wed, 26 Mar 2014 18:50:27 +0000 Date: Wed, 26 Mar 2014 18:49:57 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Oleksandr Dmytryshyn In-Reply-To: Message-ID: References: <20140326144657.GC18387@phenom.dumpdata.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-devel@lists.xenproject.org Subject: Re: [Xen-devel] swiotlb-xen question X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Post: , List-Help: , List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.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=neutral (google.com: 209.85.220.175 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) 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-Archive: On Wed, 26 Mar 2014, Oleksandr Dmytryshyn wrote: > On Wed, Mar 26, 2014 at 4:46 PM, Konrad Rzeszutek Wilk > wrote: > > On Wed, Mar 26, 2014 at 12:35:12PM +0200, Oleksandr Dmytryshyn wrote: > >> Hi to all. > >> > >> Currently I'm using hypervisor on ARM Cortex A15 processor (DRA7xx > >> Jacinto 6 processor). I'm using mainline xen 4.4 with some patches on > >> top plus dom0 and domU linux kernel 3.8. > >> > >> I've written a hack to make a camera working on my board in dom0 > >> (drivers for camera and display system are in dom0). An user-space > >> application in dom0 is used to test camera (it reads camera captured > >> data and sends it to the framebuffer). In the kernel code I've implemented > >> .mmap callback function in the swiotlb-xen.c file (like xen_swiotlb_mmap()) > >> and copied to this new callback all content from the original function > >> 'arm_dma_mmap()' from the kernel. This function creates userspace > >> mapping for the DMA-coherent memory. With this hack camera is working > >> (I can see captured video on display). > > > > Why can't you use the v4l API? Won't that work? > > > Currently we are using v4l api. swiotlb-xen doesnt have mmap callback > implemented, > so kernel use standard function dma_common_mmap() to map memory. But this > function doesn't work correctly. We've also tried to use arm_dma_mmap() function > instead of the dma_common_mmap() (HACK in the file > include/asm-generic/dma-mapping-common.h only for dom0) and all is working > in this case. This is not a Xen specific issue. In fact unless some of the dma pages involved could be foreign guest pages (for example because you have a PV framebuffer frontend in a guest sharing pages with a framebuffer backend in Dom0, and these pages are used directly in your camera driver), swiotlb-xen shouldn't even be involved. The problem is that on ARM, when you call virt_to_phys on a virtual address returned by dma_alloc_from_coherent, it doesn't return the right physical address. For example: virt_address = dma_alloc_from_coherent(dev, size, dma_addr, &ret); virt_to_phys(virt_address) != dma_addr The issue is not that bus addresses are different from physical addresses. The problem is that the virtual address is an ioremap address therefore virt_to_phys and virt_to_page don't work as expected. To fix your problem you can simply: however that would cause problems on architectures for which bus addresses are different from physical addresses. Alternatively you could: + unsigned long pfn = bus_to_phys(dma_addr) >> PAGE_SHIFT; however bus_to_phys is not defined on all architectures. I am not sure what is the best way to fix this in common code such us drivers/base/dma-mapping.c. diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c index 0ce39a3..052a5ed 100644 --- a/drivers/base/dma-mapping.c +++ b/drivers/base/dma-mapping.c @@ -248,7 +248,7 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma, #ifdef CONFIG_MMU unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT; - unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr)); + unsigned long pfn = dma_addr >> PAGE_SHIFT; unsigned long off = vma->vm_pgoff; vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);