[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190430211105.ielntedm46uqamca@pburton-laptop>
Date: Tue, 30 Apr 2019 21:11:07 +0000
From: Paul Burton <paul.burton@...s.com>
To: Christoph Hellwig <hch@....de>
CC: Ralf Baechle <ralf@...ux-mips.org>,
James Hogan <jhogan@...nel.org>,
Ley Foon Tan <lftan@...era.com>,
Michal Simek <monstr@...str.eu>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH 5/7] MIPS: use the generic uncached segment support in
dma-direct
Hi Christoph,
On Tue, Apr 30, 2019 at 10:29:47PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 30, 2019 at 08:10:43PM +0000, Paul Burton wrote:
> > This series looks like a nice cleanup to me - the one thing that puzzles
> > me is the !PageHighMem check above.
> >
> > As far as I can see arch_dma_prep_coherent() should never be called with
> > a highmem page, so would it make more sense to either drop this check or
> > perhaps wrap it in a WARN_ON()?
>
> dma_alloc_from_contigous can return highmem pages depending on where
> the CMA area is located. But given that these pages don't have a
> direct kernel mapping we also shouldn't have to flush the caches
> for them.
Right but dma_direct_alloc_pages() already checks for the PageHighMem
case & returns before ever calling arch_dma_prep_coherent(), no?
Thanks,
Paul
Powered by blists - more mailing lists