Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2326132imm; Sun, 5 Aug 2018 01:35:01 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcHnmuYzGG1H5T/nPhp2iFcXTplIt3xpk2KyUuzcah05ReazJMCMQqq3IUhVuGP0R2G4oyd X-Received: by 2002:a63:6b86:: with SMTP id g128-v6mr10471609pgc.344.1533458101800; Sun, 05 Aug 2018 01:35:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533458101; cv=none; d=google.com; s=arc-20160816; b=uYYHtVxlWIG4he5nkmOw9jARavarAVyMj6URA0MQZOCKdobgkWGeJgFwJG5AHSFU98 eeXPaZcxdGdhqEj+p4p1dmk6EJ4OdODINgurcbuKsWadZrwPmOvaS0KUXR7LtzpTnKra U2JT8NhM8d7BxikCUwGFPhGiHpGcw8MNm71Guc8ZwopNt/Rc7jnixSQg1zZX/K+y9QmC ExWcCGje9lAeWFiY31aLCVTv7uza1WJn7XgovSOJZUXyeD+JCR//C3gtb3kqTTYvQE75 1T04Cx+CnyTiEo5k5XLVzXVQaeD7D0gbqvfenRlExIW5YpOxLNgLulwmg84F0Db9m1Cm tWqA== 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=qsP+s47x++DYY+iN3K+Nt/+lBilgOjxgZUWGiMMFKhs=; b=LBecgGQpHzhaQozGr1pCm4T9Qj9Lz34RSQyJceq7Op5DRkkhKgrfi8YF9iFCr6A+Xz /obsMFXIRNtfBaECSH0V8o85M7kFcqzk/lDTLq3NXlkBO/x9+WIzSTld2DvW7czP166T aR4COm8/Y5lUIYDHfnf+Is+6jCO5Ilp2KpYc6T5jVv7+ggwuBzKa89VyOWDizvPeeLXO yyFqaMliZphxEPE5Ta7q9BNch+8FbRv8UCVh5YkPvbZqppSSK/hJJEmSoZpOptPMfe3L 5Fr62Q1ao3TQ5xZ13hTZ7CWJ9kq7tiqbxxf/NjhvWZ1Lty8cQqEsAkazWlmKiJAC/AWw 4EMw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=CgJHwsdb; 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 b74-v6si10997502pfd.273.2018.08.05.01.34.47; Sun, 05 Aug 2018 01:35:01 -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=CgJHwsdb; 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 S1726207AbeHEKhq (ORCPT + 99 others); Sun, 5 Aug 2018 06:37:46 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:46267 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726081AbeHEKhq (ORCPT ); Sun, 5 Aug 2018 06:37:46 -0400 Received: by mail-oi0-f65.google.com with SMTP id y207-v6so16992795oie.13; Sun, 05 Aug 2018 01:33:59 -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=qsP+s47x++DYY+iN3K+Nt/+lBilgOjxgZUWGiMMFKhs=; b=CgJHwsdbWIWLZTAgPa/0BJvi1nhjobB91O2fk9knapTbXcNYnqcJRdt1ft9IyOYvfI zjA7nAQYwDcv7bx9nY5Lr/WI8qecA5UoBalyWi9UYcIkJvkJp3C7Lhf7V9AzAY9EmIPu T0HDrs8CkKfpALicUFs3igRXGpAtbtt7kdu8EzNsi6AzmiXs/I71QDr5sqjZDYqGdcZM NkSOcS+QOjyIdMw5dxdFj54sNzHPeP1HmPxxvnyUUOz/MUrIvSIdPpTZwdNzrGEp6bs1 U8JpSafC1/0el0dsey3p8V5sYuxK9JSvb7qMbzGVSf1wm1TXgE4mTFDap3TNqnswDtdR 785Q== 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=qsP+s47x++DYY+iN3K+Nt/+lBilgOjxgZUWGiMMFKhs=; b=n73QH0sXjg9wir+DcGUUNsKEtBBwY23Y/77SBumdfZrS/RIL/aJZEA6Lrj9ZTYUeRx 02F8TmX+p9Pj71O2QVfw2JKws1znFr3993hAh9b8BjPVH6i/68fMVkng+a8ahAe6Bf6N OUujkMvQprIL6ZGGnXthVNelCyO8gCzkTskj5r9WCcvwKpWbY/u/xbxzaq/EgwHo8wfy o5GrecsyYJAOMpnMLcHlB/iUiGWUROKFA0HKEjBbOjr8jLBtWSiKoakRf5w78f0QsxgI pJxIGTmTq90pGr5U3twav09sbSlConZfsw3VeDsm2obtCITf7rxjzqzCiXS5TV8nd2np wxWQ== X-Gm-Message-State: AOUpUlF4uIpwJw3xSqt6PdnNapZ0s2rFCRsNhkDyY1cWgTPo7qw+iUMO g8i4cE+e0NMPGUVXvEwjHjB0nNb6aE/Q2AjkQEw= X-Received: by 2002:aca:f401:: with SMTP id s1-v6mr10786906oih.269.1533458038799; Sun, 05 Aug 2018 01:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:734:0:0:0:0:0 with HTTP; Sun, 5 Aug 2018 01:33:38 -0700 (PDT) In-Reply-To: <20180805074946.GA14119@infradead.org> References: <20180805074946.GA14119@infradead.org> From: "Matwey V. Kornilov" Date: Sun, 5 Aug 2018 11:33:38 +0300 X-Google-Sender-Auth: lgbxPGvEkrmWgv7FhhY07-uxNyM Message-ID: Subject: Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer To: Christoph Hellwig Cc: Alan Stern , Laurent Pinchart , Tomasz Figa , Ezequiel Garcia , Hans de Goede , Hans Verkuil , Mauro Carvalho Chehab , 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-08-05 10:49 GMT+03:00 Christoph Hellwig : > On Sat, Aug 04, 2018 at 10:46:35AM -0400, Alan Stern wrote: >> > 2) dma_unmap and dma_map in the handler: >> > 2A) dma_unmap_single call: 28.8 +- 1.5 usec >> > 2B) memcpy and the rest: 58 +- 6 usec >> > 2C) dma_map_single call: 22 +- 2 usec >> > Total: 110 +- 7 usec >> > >> > 3) dma_sync_single_for_cpu >> > 3A) dma_sync_single_for_cpu call: 29.4 +- 1.7 usec >> > 3B) memcpy and the rest: 59 +- 6 usec >> > 3C) noop (trace events overhead): 5 +- 2 usec >> > Total: 93 +- 7 usec >> > >> > So, now we see that 2A and 3A (as well as 2B and 3B) agree good within >> > error ranges. >> >> Taken together, those measurements look like a pretty good argument for >> always using dma_sync_single_for_cpu in the driver. Provided results >> on other platforms aren't too far out of line with these results. > > Logically speaking on no-mmio no-swiotlb platforms dma_sync_single_for_cpu > and dma_unmap should always be identical. With the migration towards > everyone using dma-direct and dma-noncoherent this is actually going to > be enforced, and I plan to move that enforcement to common code in the > next merge window or two. > I think that Alan means that using dma_sync_single_for_cpu() we save time required for subsequent dma_map() call (which is required when we do dma_unmap()). So, does everybody happy with dma_sync_single_for_cpu() for now? If so, then I'll prepare new version of the patch series. -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382