Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1336881imm; Sat, 4 Aug 2018 01:07:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcFUSBeOEAIYoCT0Uwo+ptB5NE28ASCozdtkAE759FhoNT/R6S9onTu7K8FSzMxWxXKo9Ck X-Received: by 2002:a65:450a:: with SMTP id n10-v6mr6610765pgq.392.1533370034543; Sat, 04 Aug 2018 01:07:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533370034; cv=none; d=google.com; s=arc-20160816; b=ojYVquI/ZMezTIj6D+6+q4u+t+8rd5MUb7W1nIZ81bzMSpE+ezfd7mDraotrjZy53l GzRBfWCPpg9hoqPOItH24ZVQW8DgU38s4gdZ0ES6Let5mLIyoKG+FRmNeGVcgGIziiXR Cz6DE6bkW0JNYf1QI0/TgyGiMhnD/4rKErDZxb9/SqWo40EPT4Ri7A4flQ8C5gF/bM9B nEa0ccBb63zt1mPzgqa2HG5NxUpFEe2lEEIVXWtN0FNf3aoc8oNKqJHLArhadgrjsvt8 wKMf/8seWP+xYN+WIQGTwLS3AY34UuuN/pixf61jS932+/16isvgqaior4gGaqRO8eOi DoNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=/XT79+YaXF4bnqRXVByuEWWbO6TtkLHaQ65WwoEWUE0=; b=bVFLBu9Me/HAJKNVcP2fZZnfL4yYj4XnzvPRW6IEZFIQHQTiOAAjyVLVs2MJphZhAy ak+0Llbf1WpFZMldRCnKpmXj9CWEumrrc0fNJDfnIuw7J5gDsJiBjUFbLYdeFzRsMU1Z zAwnuNtOHBck/GezJ/QuCN0Xt1o4KLcmEJp6mrpsTPnfkkHfUQmtQVSmARQ+9pM2Azeo t8OAmEs+zoZfmcOeG6HrfFTNvs4Ggx1AwL4iBwjfi5/GQr20H7YivRllhCmzUTCI3ICt iQ2DfUHiT5/tXlZmg8ieese/0uYmXxsaHj/Jcb5b5xn9q5990G3Tuc2VJmgxk8+Ayxi1 Ebhg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ah3S27jk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j61-v6si5273642plb.49.2018.08.04.01.06.59; Sat, 04 Aug 2018 01:07:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ah3S27jk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726983AbeHDKF7 (ORCPT + 99 others); Sat, 4 Aug 2018 06:05:59 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:40274 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726396AbeHDKF7 (ORCPT ); Sat, 4 Aug 2018 06:05:59 -0400 Received: by mail-oi0-f66.google.com with SMTP id w126-v6so13883855oie.7; Sat, 04 Aug 2018 01:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/XT79+YaXF4bnqRXVByuEWWbO6TtkLHaQ65WwoEWUE0=; b=ah3S27jkrR3HS4aUuERSR/Dl72eJy1dFzf27HFcvVTlLddhyQng8sDP681KUuhKSDq NYG4wcASEWoUOm9wMYv5l/nIc1Kw1eh6v4ILCiwEAUVp5jvOQ804w5J0i1yfHvevmg5g IF2DvoSBx+4Pi78tyCLCbXA+YOl8llTcUMtZBjrPiDUERa9RJhMn/WfXG5rseCrTL+9x Ku4T2iJxm3V4I+MqNqRxJmbsC+ciQT8ogFPt6IT76VW/AxDTuhR7PhiHnO1MN/THlyd2 bzcTvSGT0AstqQZbCiPi/8obL2OPw4XMh2fJ3zcl822E7UOEho3MoNsOFioB4/dDu9L6 wjKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/XT79+YaXF4bnqRXVByuEWWbO6TtkLHaQ65WwoEWUE0=; b=Usr+oVxOxhBBF8Ajoaz3PpR/vaPXQC5UWgP4wMM5TnMX/TPeOAFXXXQ9phVe1US9yA wbAFDqo5yOpXCmHjsEva71SMNHW8afssDNEF5yWUF4YU/7VGP02pfh68vXodFp5Obic8 1zxioVWpW/cSDgmLtWkp9OUD7buZ8Hm70M+urYrfGUv7tsFyQ4EVzTU56U3z7i5CS105 iFU17abhkrw11NpMp12wJ03QgXTJ9pmX1+j7xdhK0p8QrUWGiheyCVUBpHHMhN0oVRAy l22Yd/whiUnjBT82I5zAmCPBtZ0n9tjCFS51SYPnGVm/BqKWlh/DDYMfPNwX7nig8upB Lutw== X-Gm-Message-State: AOUpUlECuLEb9Fr2dn6+Eezhe1AzEXncJs8+ZorYJwRoPjL9x2quoygs SzWbGG7+1GPesMXB/UhAeHclAfW9cBxh1umZwbJSVZDRaWM= X-Received: by 2002:aca:578b:: with SMTP id l133-v6mr6959476oib.329.1533369971113; Sat, 04 Aug 2018 01:06:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:734:0:0:0:0:0 with HTTP; Sat, 4 Aug 2018 01:05:50 -0700 (PDT) In-Reply-To: References: From: "Matwey V. Kornilov" Date: Sat, 4 Aug 2018 11:05:50 +0300 X-Google-Sender-Auth: cv6_B7fG9tK0kUIMNbjEoTKk6aU Message-ID: Subject: Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer To: Tomasz Figa Cc: Alan Stern , Ezequiel Garcia , Hans de Goede , Hans Verkuil , Mauro Carvalho Chehab , Laurent Pinchart , Steven Rostedt , mingo@redhat.com, Mike Isely , Bhumika Goyal , Colin King , Linux Media Mailing List , Linux Kernel Mailing List , Kieran Bingham , keiichiw@chromium.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-07-30 7:14 GMT+03:00 Tomasz Figa : > On Wed, Jul 25, 2018 at 10:47 PM Matwey V. Kornilov wrote: >> >> 2018-07-24 23:55 GMT+03:00 Alan Stern : >> > On Tue, 24 Jul 2018, Matwey V. Kornilov wrote: >> > >> >> 2018-07-23 21:57 GMT+03:00 Alan Stern : >> >> > On Mon, 23 Jul 2018, Matwey V. Kornilov wrote: >> >> > >> >> >> I've tried to strategies: >> >> >> >> >> >> 1) Use dma_unmap and dma_map inside the handler (I suppose this is >> >> >> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP) >> >> > >> >> > Yes. >> >> > >> >> >> 2) Use sync_cpu and sync_device inside the handler (and dma_map only >> >> >> once at memory allocation) >> >> >> >> >> >> It is interesting that dma_unmap/dma_map pair leads to the lower >> >> >> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform. >> >> >> At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the >> >> >> handler, and sync_cpu/sync_device - ~65 usec. >> >> >> >> >> >> However, I am not sure is it mandatory to call >> >> >> dma_sync_single_for_device for FROM_DEVICE direction? >> >> > >> >> > According to Documentation/DMA-API-HOWTO.txt, the CPU should not write >> >> > to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is >> >> > not needed. >> >> >> >> Well, I measured the following at armv7l. The handler execution time >> >> (URB_NO_TRANSFER_DMA_MAP is used for all cases): >> >> >> >> 1) coherent DMA: ~3000 usec (pwc is not functional) >> >> 2) explicit dma_unmap and dma_map in the handler: ~52 usec >> >> 3) explicit dma_sync_single_for_cpu (no dma_sync_single_for_device): ~56 usec > > That's very strange because on ARM dma_unmap_single() does exactly the > same thing as dma_sync_single_for_cpu(): > > arm_dma_map_page() > https://elixir.bootlin.com/linux/v4.18-rc7/source/arch/arm/mm/dma-mapping.c#L129 > arm_dma_unmap_page() > https://elixir.bootlin.com/linux/v4.18-rc7/source/arch/arm/mm/dma-mapping.c#L159 > > arm_dma_sync_single_for_cpu() > https://elixir.bootlin.com/linux/v4.18-rc7/source/arch/arm/mm/dma-mapping.c#L167 > > Could you post the code you used for testing of cases 2) and 3)? I remeasured the timings (see my other mail). The code you asked is here: https://github.com/matwey/linux/tree/pwc_dma_v3 but I am going to rebase this branch. > > Best regards, > Tomasz > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382