From: Christoph Hellwig <hch@lst.de>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Christoph Hellwig <hch@lst.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Tomasz Figa <tfiga@chromium.org>,
Sergey Senozhatsky <senozhatsky@google.com>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,"
<iommu@lists.linux-foundation.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>
Subject: Re: [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos API
Date: Mon, 1 Feb 2021 17:37:26 +0100 [thread overview]
Message-ID: <20210201163726.GA8279@lst.de> (raw)
In-Reply-To: <CANiDSCtV8eiH7r6-mX3QhsYvJapqRfYufu4-iqmeiy6GiwwE_A@mail.gmail.com>
On Thu, Jan 28, 2021 at 06:00:57PM +0100, Ricardo Ribalda wrote:
> > Given that we vmap the addresses this also needs
> > flush_kernel_vmap_range / invalidate_kernel_vmap_range calls for
> > VIVT architectures.
>
> We only read from the device to the cpu. Then can we run only
> invalidate_kernel_vmap_range() ?
>
> something like ?
> else {
> dma_sync_sgtable_for_cpu(dma_dev, uvc_urb->sgt, DMA_FROM_DEVICE);
> invalidate_kernel_vmap_range(uvc_urb->buffer,
> uvc_urb->stream->urb_size );
> }
Yes. Right now we don't have a proper state machine for the
*_kernel_vmap_range, but we should probably add one once usage of this
grows. Until then I need to respin my API patch to document how callers
need to use *_kernel_vmap_range, as well as adding the so far missing
dma-debug support.
As we're getting toward the end of the merge window I'll try to get this
done ASAP.
How should we plan to merge this code? Do you have a tree you'd like
to pick up the whole thing for? Or should I create a dma-mapping
tree branch that can be pulled in?
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Sergey Senozhatsky <senozhatsky@google.com>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
" <iommu@lists.linux-foundation.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos API
Date: Mon, 1 Feb 2021 17:37:26 +0100 [thread overview]
Message-ID: <20210201163726.GA8279@lst.de> (raw)
In-Reply-To: <CANiDSCtV8eiH7r6-mX3QhsYvJapqRfYufu4-iqmeiy6GiwwE_A@mail.gmail.com>
On Thu, Jan 28, 2021 at 06:00:57PM +0100, Ricardo Ribalda wrote:
> > Given that we vmap the addresses this also needs
> > flush_kernel_vmap_range / invalidate_kernel_vmap_range calls for
> > VIVT architectures.
>
> We only read from the device to the cpu. Then can we run only
> invalidate_kernel_vmap_range() ?
>
> something like ?
> else {
> dma_sync_sgtable_for_cpu(dma_dev, uvc_urb->sgt, DMA_FROM_DEVICE);
> invalidate_kernel_vmap_range(uvc_urb->buffer,
> uvc_urb->stream->urb_size );
> }
Yes. Right now we don't have a proper state machine for the
*_kernel_vmap_range, but we should probably add one once usage of this
grows. Until then I need to respin my API patch to document how callers
need to use *_kernel_vmap_range, as well as adding the so far missing
dma-debug support.
As we're getting toward the end of the merge window I'll try to get this
done ASAP.
How should we plan to merge this code? Do you have a tree you'd like
to pick up the whole thing for? Or should I create a dma-mapping
tree branch that can be pulled in?
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-02-01 16:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 14:58 add a new dma_alloc_noncontiguous API Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 14:58 ` [PATCH 1/6] dma-mapping: remove the {alloc,free}_noncoherent methods Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 14:58 ` [PATCH 2/6] dma-mapping: add a dma_mmap_pages helper Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 15:41 ` David Laight
2021-01-28 15:41 ` David Laight
2021-01-28 14:58 ` [PATCH 3/6] dma-mapping: add a dma_alloc_noncontiguous API Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 14:58 ` [PATCH 4/6] dma-iommu: refactor iommu_dma_alloc_remap Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 14:58 ` [PATCH 5/6] dma-iommu: implement ->alloc_noncontiguous Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 14:58 ` [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos API Christoph Hellwig
2021-01-28 14:58 ` Christoph Hellwig
2021-01-28 15:09 ` Christoph Hellwig
2021-01-28 15:09 ` Christoph Hellwig
2021-01-28 17:00 ` Ricardo Ribalda
2021-01-28 17:00 ` Ricardo Ribalda
2021-02-01 16:37 ` Christoph Hellwig [this message]
2021-02-01 16:37 ` Christoph Hellwig
2021-01-28 16:43 ` Ricardo Ribalda
2021-01-28 16:43 ` Ricardo Ribalda
-- strict thread matches above, loose matches on Subject: below --
2021-03-01 8:52 add a new dma_alloc_noncontiguous API v3 Christoph Hellwig
2021-03-01 8:52 ` [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos API Christoph Hellwig
2021-03-01 8:52 ` Christoph Hellwig
2021-03-12 1:42 ` Laurent Pinchart
2021-03-12 1:42 ` Laurent Pinchart
2021-03-12 1:43 ` Laurent Pinchart
2021-03-12 1:43 ` Laurent Pinchart
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=20210201163726.GA8279@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
--cc=robin.murphy@arm.com \
--cc=senozhatsky@google.com \
--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.