From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alexandre Courbot <gnurou@gmail.com>,
Thomas Hellstrom <thellstrom@vmware.com>,
Allen Martin <amartin@nvidia.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM
Date: Mon, 1 Dec 2014 11:43:09 -0500 [thread overview]
Message-ID: <20141201164309.GG3180@laptop.dumpdata.com> (raw)
In-Reply-To: <4959864.xnWcNSQnIu@wuerfel>
On Wed, Nov 12, 2014 at 06:03:49PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > dma_alloc_coherent() returns a kernel virtual address that is part of
> > > the linear range. Passing such an address to virt_to_page() is illegal
> > > on non-coherent architectures. This causes the kernel to oops on 64-bit
> > > ARM because the struct page * obtained from virt_to_page() points to
> > > unmapped memory.
> >
> > Oh! That is not good!
> >
> I think what Thierry meant is that the returned pointer is /not/ in the
> linear range.
>
> > > Until that time, this temporary fix will allow TTM to work on 32-bit
> > > and 64-bit ARM as well, provided that no IOMMU translations are enabled
> > > for the GPU.
> >
> > Is there a way to query the 'struct device' to see if the IOMMU translation
> > is enabled/disabled for said device?
?
> >
> > Now your patch looks to get the 'struct page' by doing some form of
> > translation. Could you explain to me which type of memory have a 'struct page'
> > and which ones do not ?
> >
> > It is OK if you explain this in nauseating details
>
> Basically there are two types of memory that have a struct page:
>
> - directly mapped cacheable memory, i.e. anything that can be accessed
> through a kernel pointer without having to go though ioremap/vmalloc/...
>
> - highmem pages on 32-bit system.
>
> On noncoherent ARM systems, dma_alloc_coherent will return memory that
> is was unmapped from the linear range to avoid having both cacheable and
> noncachable mappings for the same page.
>
> Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-12-01 22:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 12:39 [RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM Thierry Reding
2014-11-12 14:18 ` Konrad Rzeszutek Wilk
2014-11-12 17:03 ` Arnd Bergmann
2014-12-01 16:43 ` Konrad Rzeszutek Wilk [this message]
2014-12-08 7:14 ` Alexandre Courbot
2014-12-08 7:36 ` Alexandre Courbot
2014-12-08 8:11 ` Alexandre Courbot
2014-12-08 8:19 ` Alexandre Courbot
2014-12-15 8:04 ` Alexandre Courbot
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=20141201164309.GG3180@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=amartin@nvidia.com \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gnurou@gmail.com \
--cc=thellstrom@vmware.com \
/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.