Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1854005imm; Thu, 9 Aug 2018 03:11:00 -0700 (PDT) X-Google-Smtp-Source: AA+uWPys5so45rAW7RPpRaOnR5fNEnSxftZyYhmImkgBMoZPImwb36WVWLnZkfWGNFZT1ZghiBit X-Received: by 2002:a62:1157:: with SMTP id z84-v6mr1729247pfi.66.1533809459985; Thu, 09 Aug 2018 03:10:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533809459; cv=none; d=google.com; s=arc-20160816; b=h4JqqYqMjWAwX+F3IE3WJYvhF+GT2LRF0+WsDxaywyS1uBX+5b8Y3UKeZeUFUCIZG/ z3gUn0RNdV2HaX2BUjU1bzPZ9j1qa03EpQy2v/Bg1WXFw7yZ69RygnyBIKmNurK37Ep1 ywCwPyy/UTND3L92NxeZDo1vFFp+s9s2y6fxbHZVihgJsx+fcYBc4LRdISkIRjXXAepJ SSxJ+LPaQkhYbYc2ECVBtKYL4LpM+Fm48VuQRv7+/PEVvKdFt4BSNZx20sT8o4g0OQ/R 1TDgYKTL8oslIr7sePFot1IYHAIN9AasKBkqu9pmI1YQOmEGwAl+kfbsf4YlRodu7z7L v0WQ== 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=xOq1l3EzOFY8iaHOqkQZ92za2Gff8OkNBVlZyyaLtOI=; b=u1FhM6wJLcWxLkPR7B7PQKThAzJIzYdwgP4fNPFDKCltkzSKxikfbL+ymoDdIRr63U z9X804/ZgjkRIjI1+d/zpLhmUi/Zjpz8u+mF7p5xXYLpWtGz7fGuGZLmIYlXM3pbCiC7 9DxjAmzjxAf/DDhwyMbncUxvFYsUgewlXMznIgTs/mAyvO16sv6yzQOm1YPXwu2nXfju lW1mzREshb7WagXAfMJ6leAmWmV3eLRSqvSMphaSV2wDxqYEaQHa2wpIGwlfie08l8fI +nCTBFdC0tLPBlWuq6KteYUlALxD4TuEJq+eCZAGHcZRhMlqMNygV9xlNnskre+YTcQ0 f8yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=nKszakGb; 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 i5-v6si6397537pgg.84.2018.08.09.03.10.45; Thu, 09 Aug 2018 03:10:59 -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=nKszakGb; 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 S1730295AbeHIMdT (ORCPT + 99 others); Thu, 9 Aug 2018 08:33:19 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:46518 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727768AbeHIMdS (ORCPT ); Thu, 9 Aug 2018 08:33:18 -0400 Received: by mail-oi0-f66.google.com with SMTP id y207-v6so8804833oie.13; Thu, 09 Aug 2018 03:09:09 -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=xOq1l3EzOFY8iaHOqkQZ92za2Gff8OkNBVlZyyaLtOI=; b=nKszakGbPGO0u2dbI0c4iK7XUSMRBIfpuRTQnG9T0cQ5nMVHlu6//E1vZI5Y8zXcqI 3tip8+TXK/Q0IZN6BAFiPl2wiLhsDebZuZ4brfLgzCoMEm6H+ookgTDx8rVT5QXTO1/K wHWK8sn4ow9Ckc2bd6n5qE3+9Zaa3Yu/OibIVX6OQHJesWIu2+nPd7vYTz0EcjFea5b4 urlbgd+eCvW4LdNGOuUXlYTQqNLCRD7buCsUws2ijnFq0PHZ83F9AiYbQTgFcbigHfbE KEFtRkSkFLasJQ1a39s/eKobf7I64pNpvsPgYm8tmE8t4o/VRF3vBJ4p5/VfTAoeGwBe jMQg== 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=xOq1l3EzOFY8iaHOqkQZ92za2Gff8OkNBVlZyyaLtOI=; b=eaKVLIooCnK+Db1jSuPsjeGTsW9T1A0/g9iTNLno/Dcp0ArBy73Mst6CiwdwUXKSYb F20GApwZ5lhr6giWS9Xls2e6PVFDCsqijfHXnwrGd9xPv/eVGe/N1+vhiua9KJwb8yG8 6mhlC0pixKQTHEUJl87yDQZf4S0scDfhD6RvA9ekfnkztLKdkzvbIeyEScsXq7j3SEd4 PYD1SuuB+w2j7FvCSjVe/qn/gVdQ7M5XEZAdFlVkqoa83Q4AN/RJPpnUFv7unAPy/OWG HS9uPGzZ+w+iynEx19xKV+N4a/QDZ3rDagthZiASkaaqMsGN/nqWPBAwQs1XyMl9TIIq HVxw== X-Gm-Message-State: AOUpUlGRwU14qQsOyjyDL3O02BUZQSagrWSD2qf82jG3vdamzobKMLpz 1u5AuG1ImkKsbFimYiGn9rmFdnrEymtA16IpAUM= X-Received: by 2002:aca:dec6:: with SMTP id v189-v6mr1536868oig.98.1533809348925; Thu, 09 Aug 2018 03:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:734:0:0:0:0:0 with HTTP; Thu, 9 Aug 2018 03:08:48 -0700 (PDT) In-Reply-To: <1999611.3qB5YXmi7D@avalon> References: <20180809093307.6001-1-matwey@sai.msu.ru> <20180809093307.6001-3-matwey@sai.msu.ru> <1999611.3qB5YXmi7D@avalon> From: "Matwey V. Kornilov" Date: Thu, 9 Aug 2018 13:08:48 +0300 X-Google-Sender-Auth: pbsr9tZGwMj3Z-qSQSmv_mfpPdI Message-ID: Subject: Re: [PATCH v3 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer To: Laurent Pinchart Cc: Linux Media Mailing List , open list , Tomasz Figa , Alan Stern , Ezequiel Garcia , Hans de Goede , Hans Verkuil , Mauro Carvalho Chehab , Steven Rostedt , mingo@redhat.com, Mike Isely , Bhumika Goyal , Colin King , 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-09 12:51 GMT+03:00 Laurent Pinchart : > Hi Matwey, > > Thank you for the patch. > > On Thursday, 9 August 2018 12:33:07 EEST Matwey V. Kornilov wrote: >> DMA cocherency slows the transfer down on systems without hardware >> coherent DMA. Instead we use noncocherent DMA memory and explicit sync at >> data receive handler. >> >> Based on previous commit the following performance benchmarks have been >> carried out. Average memcpy() data transfer rate (rate) and handler >> completion time (time) have been measured when running video stream at >> 640x480 resolution at 10fps. >> >> x86_64 based system (Intel Core i5-3470). This platform has hardware >> coherent DMA support and proposed change doesn't make big difference here. >> >> * kmalloc: rate = (2.0 +- 0.4) GBps >> time = (5.0 +- 3.0) usec >> * usb_alloc_coherent: rate = (3.4 +- 1.2) GBps >> time = (3.5 +- 3.0) usec >> >> We see that the measurements agree within error ranges in this case. >> So theoretically predicted performance downgrade cannot be reliably measured >> here. >> >> armv7l based system (TI AM335x BeagleBone Black @ 300MHz). This platform has >> no hardware coherent DMA support. DMA coherence is implemented via disabled >> page caching that slows down memcpy() due to memory controller behaviour. >> >> * kmalloc: rate = (114 +- 5) MBps >> time = (84 +- 4) usec >> * usb_alloc_coherent: rate = (28.1 +- 0.1) MBps >> time = (341 +- 2) usec >> >> Note, that quantative difference leads (this commit leads to 4 times >> acceleration) to qualitative behavior change in this case. As it was >> stated before, the video stream cannot be successfully received at AM335x >> platforms with MUSB based USB host controller due to performance issues >> [1]. >> >> [1] https://www.spinics.net/lists/linux-usb/msg165735.html >> >> Signed-off-by: Matwey V. Kornilov >> --- >> drivers/media/usb/pwc/pwc-if.c | 47 ++++++++++++++++++++++++++++----------- >> 1 file changed, 35 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c >> index 72d2897a4b9f..17f2015a75bb 100644 >> --- a/drivers/media/usb/pwc/pwc-if.c >> +++ b/drivers/media/usb/pwc/pwc-if.c >> @@ -159,6 +159,31 @@ static const struct video_device pwc_template = { >> /************************************************************************** >> */ /* Private functions */ >> >> +static void* pwc_alloc_urb_buffer(struct device *dev, size_t size, >> dma_addr_t *dma_handle) { > > There are several violations of the Linux coding style here, could you please > run your patch through checkpatch.pl to fix them ? Thanks. I'll fix them. I really need to configure git hooks with checkpatch. > >> + void* buffer = kmalloc(size, GFP_KERNEL); >> + >> + if (buffer == NULL) { >> + goto fail_kmalloc; >> + } > > No need for a goto, you can just return NULL here. > >> + *dma_handle = dma_map_single(dev, buffer, size, DMA_FROM_DEVICE); >> + if (dma_mapping_error(dev, *dma_handle)) { >> + goto fail_dma_map_single; > > And you can inline the error handling code here as it's used from a single > location. > >> + } >> + >> + return buffer; >> + >> +fail_dma_map_single: >> + kfree(buffer); >> +fail_kmalloc: >> + return NULL; >> +} >> + >> +static void pwc_free_urb_buffer(struct device *dev, size_t size, void* >> buffer, dma_addr_t dma_handle) { >> + dma_unmap_single(dev, dma_handle, size, DMA_FROM_DEVICE); >> + kfree(buffer); >> +} >> + >> static struct pwc_frame_buf *pwc_get_next_fill_buf(struct pwc_device *pdev) >> { >> unsigned long flags = 0; >> @@ -306,6 +331,8 @@ static void pwc_isoc_handler(struct urb *urb) >> /* Reset ISOC error counter. We did get here, after all. */ >> pdev->visoc_errors = 0; >> >> + dma_sync_single_for_cpu(&urb->dev->dev, urb->transfer_dma, >> urb->transfer_buffer_length, DMA_FROM_DEVICE); >> + >> /* vsync: 0 = don't copy data >> 1 = sync-hunt >> 2 = synched >> @@ -428,16 +455,13 @@ static int pwc_isoc_init(struct pwc_device *pdev) >> urb->dev = udev; >> urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint); >> urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP; >> - urb->transfer_buffer = usb_alloc_coherent(udev, >> - ISO_BUFFER_SIZE, >> - GFP_KERNEL, >> - &urb->transfer_dma); >> + urb->transfer_buffer_length = ISO_BUFFER_SIZE; >> + urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev, >> urb->transfer_buffer_length, &urb->transfer_dma); >> if (urb->transfer_buffer == NULL) { >> PWC_ERROR("Failed to allocate urb buffer %d\n", i); >> pwc_isoc_cleanup(pdev); >> return -ENOMEM; >> } >> - urb->transfer_buffer_length = ISO_BUFFER_SIZE; >> urb->complete = pwc_isoc_handler; >> urb->context = pdev; >> urb->start_frame = 0; >> @@ -488,15 +512,14 @@ static void pwc_iso_free(struct pwc_device *pdev) >> >> /* Freeing ISOC buffers one by one */ >> for (i = 0; i < MAX_ISO_BUFS; i++) { >> - if (pdev->urbs[i]) { >> + struct urb* urb = pdev->urbs[i]; >> + >> + if (urb) { >> PWC_DEBUG_MEMORY("Freeing URB\n"); >> - if (pdev->urbs[i]->transfer_buffer) { >> - usb_free_coherent(pdev->udev, >> - pdev->urbs[i]->transfer_buffer_length, >> - pdev->urbs[i]->transfer_buffer, >> - pdev->urbs[i]->transfer_dma); >> + if (urb->transfer_buffer) { >> + pwc_free_urb_buffer(&urb->dev->dev, urb->transfer_buffer_length, >> urb->transfer_buffer, urb->transfer_dma); } >> - usb_free_urb(pdev->urbs[i]); >> + usb_free_urb(urb); >> pdev->urbs[i] = NULL; >> } >> } > > -- > Regards, > > Laurent Pinchart > > > -- With best regards, Matwey V. Kornilov. Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382