[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190114090456.03071201@coco.lan>
Date: Mon, 14 Jan 2019 09:04:56 -0200
From: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: Pawel Osciak <pawel@...iak.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Niklas Söderlund
<niklas.soderlund+renesas@...natech.se>,
Russell King <linux@...linux.org.uk>,
iommu@...ts.linux-foundation.org,
linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] videobuf2: replace a layering violation with
dma_map_resource
Em Mon, 14 Jan 2019 11:31:39 +0100
Christoph Hellwig <hch@....de> escreveu:
> On Fri, Jan 11, 2019 at 05:54:16PM -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 11 Jan 2019 19:17:31 +0100
> > Christoph Hellwig <hch@....de> escreveu:
> >
> > > vb2_dc_get_userptr pokes into arm direct mapping details to get the
> > > resemblance of a dma address for a a physical address that does is
> > > not backed by a page struct. Not only is this not portable to other
> > > architectures with dma direct mapping offsets, but also not to uses
> > > of IOMMUs of any kind. Switch to the proper dma_map_resource /
> > > dma_unmap_resource interface instead.
> >
> > Makes sense to me. I'm assuming that you'll be pushing it together
> > with other mm patches, so:
>
> Not really mm, but rather DMA mapping, but yes, I'd love to take it
> all together.
Ah, OK! Anyway, feel free to place it altogether.
It would be good if you could later send us a stable branch where
you merged, in order to allow us to run some tests with the new
DMA mapping patchset and be sure that it won't cause regressions
to videobuf2.
Thank you!
Mauro
Powered by blists - more mailing lists