From: Greg KH <gregkh@linuxfoundation.org>
To: jun.zhang@intel.com
Cc: devel@driverdev.osuosl.org, tkjos@android.com, Bai@osuosl.org,
Jie A <jie.a.bai@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, he@osuosl.org, arve@android.com,
bo <bo.he@intel.com>,
joel@joelfernandes.org, maco@android.com, christian@brauner.io
Subject: Re: [PATCH] ion_system_heap: support X86 archtecture
Date: Sun, 29 Sep 2019 12:12:54 +0200 [thread overview]
Message-ID: <20190929101254.GA1907778@kroah.com> (raw)
In-Reply-To: <20190929072841.14848-1-jun.zhang@intel.com>
On Sun, Sep 29, 2019 at 03:28:41PM +0800, jun.zhang@intel.com wrote:
> From: zhang jun <jun.zhang@intel.com>
>
> we see tons of warning like:
> [ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
> write-combining for [mem 0x1e7a80000-0x1e7a87fff], got write-back
> [ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
> write-combining for [mem 0x1e7a58000-0x1e7a58fff], got write-back
> [ 45.848875] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
> write-combining for [mem 0x1e7a48000-0x1e7a4ffff], got write-back
> [ 45.849403] x86/PAT: .vorbis.decoder:4088 map pfn RAM range
> req write-combining for [mem 0x1e7a70000-0x1e7a70fff], got write-back
>
> check the kernel Documentation/x86/pat.txt, it says:
> A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
> vm_insert_pfn
> Drivers wanting to export some pages to userspace do it by using
> mmap interface and a combination of
> 1) pgprot_noncached()
> 2) io_remap_pfn_range() or remap_pfn_range() or vm_insert_pfn()
> With PAT support, a new API pgprot_writecombine is being added.
> So, drivers can continue to use the above sequence, with either
> pgprot_noncached() or pgprot_writecombine() in step 1, followed by step 2.
>
> In addition, step 2 internally tracks the region as UC or WC in
> memtype list in order to ensure no conflicting mapping.
>
> Note that this set of APIs only works with IO (non RAM) regions.
> If driver ants to export a RAM region, it has to do set_memory_uc() or
> set_memory_wc() as step 0 above and also track the usage of those pages
> and use set_memory_wb() before the page is freed to free pool.
>
> the fix follow the pat document, do set_memory_wc() as step 0 and
> use the set_memory_wb() before the page is freed.
>
> Signed-off-by: he, bo <bo.he@intel.com>
> Signed-off-by: zhang jun <jun.zhang@intel.com>
> Signed-off-by: Bai, Jie A <jie.a.bai@intel.com>
> ---
> drivers/staging/android/ion/ion_system_heap.c | 28 ++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> index b83a1d16bd89..d298b8194820 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -13,6 +13,7 @@
> #include <linux/scatterlist.h>
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
> +#include <asm/set_memory.h>
>
> #include "ion.h"
>
> @@ -134,6 +135,13 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
> sg = table->sgl;
> list_for_each_entry_safe(page, tmp_page, &pages, lru) {
> sg_set_page(sg, page, page_size(page), 0);
> +
> +#ifdef CONFIG_X86
> + if (!(buffer->flags & ION_FLAG_CACHED))
> + set_memory_wc((unsigned long)page_address(sg_page(sg)),
> + PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
> +#endif
There is no way to do this without these #ifdefs? That feels odd, why
can't you just always test for this?
thanks,
greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: jun.zhang@intel.com
Cc: labbott@redhat.com, sumit.semwal@linaro.org, arve@android.com,
tkjos@android.com, maco@android.com, joel@joelfernandes.org,
christian@brauner.io, devel@driverdev.osuosl.org,
Jie A <jie.a.bai@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, he@osuosl.org, Bai@osuosl.org,
bo <bo.he@intel.com>
Subject: Re: [PATCH] ion_system_heap: support X86 archtecture
Date: Sun, 29 Sep 2019 12:12:54 +0200 [thread overview]
Message-ID: <20190929101254.GA1907778@kroah.com> (raw)
In-Reply-To: <20190929072841.14848-1-jun.zhang@intel.com>
On Sun, Sep 29, 2019 at 03:28:41PM +0800, jun.zhang@intel.com wrote:
> From: zhang jun <jun.zhang@intel.com>
>
> we see tons of warning like:
> [ 45.846872] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
> write-combining for [mem 0x1e7a80000-0x1e7a87fff], got write-back
> [ 45.848827] x86/PAT: .vorbis.decoder:4088 map pfn RAM range req
> write-combining for [mem 0x1e7a58000-0x1e7a58fff], got write-back
> [ 45.848875] x86/PAT: NDK MediaCodec_:3753 map pfn RAM range req
> write-combining for [mem 0x1e7a48000-0x1e7a4ffff], got write-back
> [ 45.849403] x86/PAT: .vorbis.decoder:4088 map pfn RAM range
> req write-combining for [mem 0x1e7a70000-0x1e7a70fff], got write-back
>
> check the kernel Documentation/x86/pat.txt, it says:
> A. Exporting pages to users with remap_pfn_range, io_remap_pfn_range,
> vm_insert_pfn
> Drivers wanting to export some pages to userspace do it by using
> mmap interface and a combination of
> 1) pgprot_noncached()
> 2) io_remap_pfn_range() or remap_pfn_range() or vm_insert_pfn()
> With PAT support, a new API pgprot_writecombine is being added.
> So, drivers can continue to use the above sequence, with either
> pgprot_noncached() or pgprot_writecombine() in step 1, followed by step 2.
>
> In addition, step 2 internally tracks the region as UC or WC in
> memtype list in order to ensure no conflicting mapping.
>
> Note that this set of APIs only works with IO (non RAM) regions.
> If driver ants to export a RAM region, it has to do set_memory_uc() or
> set_memory_wc() as step 0 above and also track the usage of those pages
> and use set_memory_wb() before the page is freed to free pool.
>
> the fix follow the pat document, do set_memory_wc() as step 0 and
> use the set_memory_wb() before the page is freed.
>
> Signed-off-by: he, bo <bo.he@intel.com>
> Signed-off-by: zhang jun <jun.zhang@intel.com>
> Signed-off-by: Bai, Jie A <jie.a.bai@intel.com>
> ---
> drivers/staging/android/ion/ion_system_heap.c | 28 ++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> index b83a1d16bd89..d298b8194820 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -13,6 +13,7 @@
> #include <linux/scatterlist.h>
> #include <linux/slab.h>
> #include <linux/vmalloc.h>
> +#include <asm/set_memory.h>
>
> #include "ion.h"
>
> @@ -134,6 +135,13 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
> sg = table->sgl;
> list_for_each_entry_safe(page, tmp_page, &pages, lru) {
> sg_set_page(sg, page, page_size(page), 0);
> +
> +#ifdef CONFIG_X86
> + if (!(buffer->flags & ION_FLAG_CACHED))
> + set_memory_wc((unsigned long)page_address(sg_page(sg)),
> + PAGE_ALIGN(sg->length) >> PAGE_SHIFT);
> +#endif
There is no way to do this without these #ifdefs? That feels odd, why
can't you just always test for this?
thanks,
greg k-h
next prev parent reply other threads:[~2019-09-29 10:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-29 7:28 [PATCH] ion_system_heap: support X86 archtecture jun.zhang
2019-09-29 10:12 ` Greg KH [this message]
2019-09-29 10:12 ` Greg KH
2019-10-01 5:28 ` Zhang, Jun
2019-10-01 5:28 ` Zhang, Jun
2019-09-29 20:57 ` Laura Abbott
2019-09-29 20:57 ` Laura Abbott
2020-02-28 11:00 ` youling257
2020-02-28 11:00 ` youling257
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=20190929101254.GA1907778@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Bai@osuosl.org \
--cc=arve@android.com \
--cc=bo.he@intel.com \
--cc=christian@brauner.io \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=he@osuosl.org \
--cc=jie.a.bai@intel.com \
--cc=joel@joelfernandes.org \
--cc=jun.zhang@intel.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=tkjos@android.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.