Shawn Anastasio writes:
> On 7/22/19 7:16 AM, Michael Ellerman wrote:
>> Arnd Bergmann writes:
>>> On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
> On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran
On 7/22/19 7:16 AM, Michael Ellerman wrote:
Arnd Bergmann writes:
On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
Other than m68k, mips, and
Arnd Bergmann writes:
> On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote:
>> On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
>> > On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
>> > > > Other than m68k, mips, and arm64, everybody else that doesn't
On Wed, 2019-07-17 at 23:54:37 UTC, Shawn Anastasio wrote:
> The refactor of powerpc DMA functions in commit cc17d780
> ("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
> changes the way DMA mappings are handled on powerpc.
> Since this change, all mapped pages are marked as
On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote:
>
> On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
> > On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > > > Other than m68k, mips, and arm64, everybody else that doesn't have
> > > >
On 7/19/19 2:06 AM, Christoph Hellwig wrote:
> What is inherently architecture specific here over the fact that
> the pgprot_* expand to architecture specific bits?
What I meant is that different architectures seem to have different
criteria for setting the different pgprot_ bits. i.e. ppc
On Thu, Jul 18, 2019 at 02:46:00PM -0500, Shawn Anastasio wrote:
> Personally, I'm not a huge fan of an implicit default for something
> inherently architecture-dependent like this at all.
What is inherently architecture specific here over the fact that
the pgprot_* expand to architecture
On 7/18/19 4:52 AM, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
Other than m68k, mips, and arm64, everybody else that doesn't have
ARCH_NO_COHERENT_DMA_MMAP set uses this default
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
> On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > > Other than m68k, mips, and arm64, everybody else that doesn't have
> > > ARCH_NO_COHERENT_DMA_MMAP set uses this default implementation, so
> > > I assume
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > Other than m68k, mips, and arm64, everybody else that doesn't have
> > ARCH_NO_COHERENT_DMA_MMAP set uses this default implementation, so
> > I assume this behavior is acceptable on those architectures.
>
> It might be
On Thu, Jul 18, 2019 at 1:16 PM Shawn Anastasio wrote:
>
> On 7/17/19 9:59 PM, Alexey Kardashevskiy wrote:
> >
> > On 18/07/2019 09:54, Shawn Anastasio wrote:
> >> The refactor of powerpc DMA functions in commit cc17d780
> >> ("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
> >>
On 7/17/19 9:59 PM, Alexey Kardashevskiy wrote:
On 18/07/2019 09:54, Shawn Anastasio wrote:
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this change, all
On 18/07/2019 09:54, Shawn Anastasio wrote:
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this change, all mapped pages are marked as cache-inhibited
through
The refactor of powerpc DMA functions in commit cc17d780
("powerpc/dma: remove dma_nommu_mmap_coherent") incorrectly
changes the way DMA mappings are handled on powerpc.
Since this change, all mapped pages are marked as cache-inhibited
through the default implementation of
14 matches
Mail list logo
