From: Christoph Hellwig <hch@lst.de>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Ricardo Ribalda <ribalda@chromium.org>,
Christoph Hellwig <hch@lst.de>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,"
<iommu@lists.linux-foundation.org>,
Robin Murphy <robin.murphy@arm.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>
Subject: Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
Date: Tue, 10 Nov 2020 10:57:47 +0100 [thread overview]
Message-ID: <20201110095747.GA26574@lst.de> (raw)
In-Reply-To: <CAAFQd5CCOrp0OA_n_SHNO5RAhV-MQ2KuQJA+oWHQ76h_So=M2Q@mail.gmail.com>
On Tue, Nov 10, 2020 at 06:50:32PM +0900, Tomasz Figa wrote:
> In what terms it doesn't actually work? Last time I checked some
> platforms actually defined CONFIG_DMA_NONCOHERENT, so those would
> instead use the kmalloc() + dma_map() path. I don't have any
> background on why that was added and whether it needs to be preserved,
> though. Kieran, Laurent, do you have any insight?
CONFIG_DMA_NONCOHERENT is set on sh and mips for platforms that may
support non-coherent DMA at compile time (but at least for mips that
doesn't actually means this gets used). Using that ifdef to decide
on using usb_alloc_coherent vs letting the usb layer map the data
seems at best odd, and if we are unlucky papering over a bug somewhere.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
Joerg Roedel <joro@8bytes.org>,
" <iommu@lists.linux-foundation.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Ricardo Ribalda <ribalda@chromium.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 8/8] WIP: add a dma_alloc_contiguous API
Date: Tue, 10 Nov 2020 10:57:47 +0100 [thread overview]
Message-ID: <20201110095747.GA26574@lst.de> (raw)
In-Reply-To: <CAAFQd5CCOrp0OA_n_SHNO5RAhV-MQ2KuQJA+oWHQ76h_So=M2Q@mail.gmail.com>
On Tue, Nov 10, 2020 at 06:50:32PM +0900, Tomasz Figa wrote:
> In what terms it doesn't actually work? Last time I checked some
> platforms actually defined CONFIG_DMA_NONCOHERENT, so those would
> instead use the kmalloc() + dma_map() path. I don't have any
> background on why that was added and whether it needs to be preserved,
> though. Kieran, Laurent, do you have any insight?
CONFIG_DMA_NONCOHERENT is set on sh and mips for platforms that may
support non-coherent DMA at compile time (but at least for mips that
doesn't actually means this gets used). Using that ifdef to decide
on using usb_alloc_coherent vs letting the usb layer map the data
seems at best odd, and if we are unlucky papering over a bug somewhere.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-11-10 9:57 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 16:09 dma_alloc_pages / dma_alloc_noncoherent fixups Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 1/8] dma-mapping: remove the {alloc,free}_noncoherent methods Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 2/8] dma-mapping: document dma_{alloc,free}_pages Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 3/8] dma-direct check for highmem pages in dma_direct_alloc_pages Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 4/8] dma-direct: use __GFP_ZERO " Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-10-06 7:24 ` Hillf Danton
2020-09-30 16:09 ` [PATCH 5/8] dma-direct: factor out a dma_direct_alloc_from_pool helper Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 6/8] dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 7/8] dma-iommu: remove __iommu_dma_mmap Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-09-30 16:09 ` [PATCH 8/8] WIP: add a dma_alloc_contiguous API Christoph Hellwig
2020-09-30 16:09 ` Christoph Hellwig
2020-10-02 17:50 ` Tomasz Figa
2020-10-02 17:50 ` Tomasz Figa
2020-10-05 8:26 ` Christoph Hellwig
2020-10-05 8:26 ` Christoph Hellwig
2020-10-06 20:56 ` Tomasz Figa
2020-10-06 20:56 ` Tomasz Figa
2020-10-07 6:21 ` Christoph Hellwig
2020-10-07 6:21 ` Christoph Hellwig
2020-10-07 12:21 ` Tomasz Figa
2020-10-07 12:21 ` Tomasz Figa
2020-10-07 12:24 ` Christoph Hellwig
2020-10-07 12:24 ` Christoph Hellwig
2020-10-14 13:20 ` Tomasz Figa
2020-10-14 13:20 ` Tomasz Figa
2020-10-14 15:03 ` David Laight
2020-10-14 15:03 ` David Laight
2020-11-09 14:53 ` Ricardo Ribalda
2020-11-09 14:53 ` Ricardo Ribalda
2020-11-10 9:25 ` Christoph Hellwig
2020-11-10 9:25 ` Christoph Hellwig
2020-11-10 9:33 ` Ricardo Ribalda
2020-11-10 9:33 ` Ricardo Ribalda
2020-11-10 9:41 ` Christoph Hellwig
2020-11-10 9:41 ` Christoph Hellwig
2020-11-10 9:50 ` Tomasz Figa
2020-11-10 9:50 ` Tomasz Figa
2020-11-10 9:57 ` Christoph Hellwig [this message]
2020-11-10 9:57 ` Christoph Hellwig
2020-11-17 21:21 ` Ricardo Ribalda
2020-11-17 21:21 ` Ricardo Ribalda
2020-11-18 14:25 ` [PATCH] WIP! media: uvcvideo: Use dma_alloc_noncontiguos API Ricardo Ribalda
2020-11-18 14:25 ` Ricardo Ribalda
2020-11-24 11:35 ` Christoph Hellwig
2020-11-24 11:35 ` Christoph Hellwig
2020-11-24 12:01 ` Ricardo Ribalda
2020-11-24 12:01 ` Ricardo Ribalda
2020-11-24 13:33 ` Christoph Hellwig
2020-11-24 13:33 ` Christoph Hellwig
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=20201110095747.GA26574@lst.de \
--to=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--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=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.