Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1360038 > unrolled thread

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

Started byLaurent Pinchart <laurent.pinchart@ideasonboard.com>
First post2016-03-17 17:50 +0100
Last post2016-03-21 16:30 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-03-17 17:50 +0100
    Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource Christoph Hellwig <hch@infradead.org> - 2016-03-21 16:30 +0100

#1360038 — Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

FromLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Date2016-03-17 17:50 +0100
SubjectRe: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource
Message-ID<rdJhy-1oX-53@gated-at.bofh.it>
Hello,

On Tuesday 15 March 2016 01:22:54 Christoph Hellwig wrote:
> On Fri, Mar 11, 2016 at 01:58:46PM +0100, Niklas S?derlund wrote:
> > Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> > the same and no special care is needed. However if you have a IOMMU you
> > need to map the DMA slave phys_addr_t to a dma_addr_t using something
> > like this. Is it not very similar to dma_map_single() where one maps
> > processor virtual memory (instead if MMIO) so that it can be used with
> > DMA slaves?
> 
> It's similar, but I don't think this actually works as a general case
> as there are quite a few places that expect to be able to have a
> struct page for a physical address.  We'd at least need a very careful
> audit for that case.

The good news is that, given that no code uses this new API at the moment, 
there isn't much to audit. The patch series implements the resource mapping 
for arch/arm only, and makes use of it in the rcar-dmac driver only. Would you 
like anything audited else than the arch/arm dma mapping implementation, the 
rcar-dmac driver and the code that then deals with the dma addresses (I'm 
thinking about the IOMMU subsystem and the ipmmu-vmsa driver in particular) ?

-- 
Regards,

Laurent Pinchart

[toc] | [next] | [standalone]


#1361937

FromChristoph Hellwig <hch@infradead.org>
Date2016-03-21 16:30 +0100
Message-ID<rf9Wj-7Az-25@gated-at.bofh.it>
In reply to#1360038
On Thu, Mar 17, 2016 at 01:33:51PM +0200, Laurent Pinchart wrote:
> The good news is that, given that no code uses this new API at the moment, 
> there isn't much to audit. The patch series implements the resource mapping 
> for arch/arm only, and makes use of it in the rcar-dmac driver only. Would you 
> like anything audited else than the arch/arm dma mapping implementation, the 
> rcar-dmac driver and the code that then deals with the dma addresses (I'm 
> thinking about the IOMMU subsystem and the ipmmu-vmsa driver in particular) ?

Yes, it would be good to do an audit of all the ARM dma_ops as well
as generic code like drivers/base/dma-*.c, lib/dma-debug.c and
include/linux/dma-*.h

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web