From: Christoph Hellwig <hch@infradead.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Matwey V. Kornilov" <matwey@sai.msu.ru>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Tomasz Figa <tfiga@chromium.org>,
Ezequiel Garcia <ezequiel@collabora.com>,
Hans de Goede <hdegoede@redhat.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
mingo@redhat.com, Mike Isely <isely@pobox.com>,
Bhumika Goyal <bhumirks@gmail.com>,
Colin King <colin.king@canonical.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
keiichiw@chromium.org
Subject: Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
Date: Sun, 5 Aug 2018 00:49:46 -0700 [thread overview]
Message-ID: <20180805074946.GA14119@infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1808041045060.25853-100000@netrider.rowland.org>
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.
next prev parent reply other threads:[~2018-08-05 9:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-17 14:36 [PATCH 1/2] Add TRACE_EVENTs in pwc_isoc_handler() Matwey V. Kornilov
2018-06-17 14:36 ` [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer Matwey V. Kornilov
2018-06-18 5:11 ` Ezequiel Garcia
2018-06-18 7:10 ` Matwey V. Kornilov
2018-07-17 20:10 ` Ezequiel Garcia
2018-07-17 20:51 ` Alan Stern
2018-07-20 10:55 ` Tomasz Figa
2018-07-20 11:22 ` Matwey V. Kornilov
2018-07-20 11:33 ` Tomasz Figa
2018-07-20 11:57 ` Matwey V. Kornilov
2018-07-23 17:04 ` Matwey V. Kornilov
2018-07-23 18:57 ` Alan Stern
2018-07-24 18:56 ` Matwey V. Kornilov
2018-07-24 20:55 ` Alan Stern
2018-07-25 13:46 ` Matwey V. Kornilov
2018-07-30 4:14 ` Tomasz Figa
2018-08-04 8:05 ` Matwey V. Kornilov
2018-07-30 15:35 ` Laurent Pinchart
2018-08-04 8:00 ` Matwey V. Kornilov
2018-08-04 14:46 ` Alan Stern
2018-08-05 7:49 ` Christoph Hellwig [this message]
2018-08-05 8:33 ` Matwey V. Kornilov
2018-08-05 8:41 ` Christoph Hellwig
2018-08-08 22:32 ` Laurent Pinchart
2018-08-09 2:36 ` Tomasz Figa
2018-08-09 10:28 ` Laurent Pinchart
2018-07-30 15:13 ` Laurent Pinchart
2018-07-18 12:10 ` Matwey V. Kornilov
2018-07-19 23:36 ` Ezequiel Garcia
2018-07-20 9:35 ` Matwey V. Kornilov
2018-07-30 15:42 ` Laurent Pinchart
2018-07-30 16:07 ` Mauro Carvalho Chehab
2018-07-31 6:06 ` Tomasz Figa
2018-06-18 18:58 ` [PATCH 1/2] Add TRACE_EVENTs in pwc_isoc_handler() Steven Rostedt
2018-06-19 16:23 ` Matwey V. Kornilov
2018-06-19 16:33 ` Steven Rostedt
2018-06-20 8:05 ` Matwey V. Kornilov
2018-06-20 13:09 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180805074946.GA14119@infradead.org \
--to=hch@infradead.org \
--cc=bhumirks@gmail.com \
--cc=colin.king@canonical.com \
--cc=ezequiel@collabora.com \
--cc=hdegoede@redhat.com \
--cc=hverkuil@xs4all.nl \
--cc=isely@pobox.com \
--cc=keiichiw@chromium.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=matwey@sai.msu.ru \
--cc=mchehab@kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
--cc=tfiga@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.