All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laura Abbott <labbott@redhat.com>
To: "Sumit Semwal" <sumit.semwal@linaro.org>,
	"John Stultz" <john.stultz@linaro.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>
Cc: Laura Abbott <labbott@redhat.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	linaro-mm-sig@lists.linaro.org, devel@driverdev.osuosl.org,
	Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Eun Taik Lee <eun.taik.lee@samsung.com>,
	Rohit kumar <rohit.kr@samsung.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>, Jon Medhurst <tixy@linaro.org>,
	Jeremy Gebben <jgebben@codeaurora.org>,
	Bryan Huntsman <bryanh@codeaurora.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Android Kernel Team <kernel-team@android.com>,
	Arnd Bergmann <arnd@arndb.de>
Subject: [RFCv3][PATCH 1/5] Documentation: Introduce kernel_force_cache_* APIs
Date: Mon, 12 Sep 2016 14:32:54 -0700	[thread overview]
Message-ID: <1473715978-11633-2-git-send-email-labbott@redhat.com> (raw)
In-Reply-To: <1473715978-11633-1-git-send-email-labbott@redhat.com>


Some frameworks (e.g. Ion) may need to do explicit cache management
to meet performance/correctness requirements. Rather than piggy-back
on another API and hope the semantics don't change, introduce a
set of APIs to force a page to be cleaned/invalidated in the cache.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 Documentation/cachetlb.txt | 18 +++++++++++++++++-
 include/linux/cacheflush.h | 11 +++++++++++
 2 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/cacheflush.h

diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 3f9f808..18eec7c 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -378,7 +378,7 @@ maps this page at its virtual address.
 	flush_dcache_page and update_mmu_cache. In the future, the hope
 	is to remove this interface completely.
 
-The final category of APIs is for I/O to deliberately aliased address
+Another set of APIs is for I/O to deliberately aliased address
 ranges inside the kernel.  Such aliases are set up by use of the
 vmap/vmalloc API.  Since kernel I/O goes via physical pages, the I/O
 subsystem assumes that the user mapping and kernel offset mapping are
@@ -401,3 +401,19 @@ I/O and invalidating it after the I/O returns.
        speculatively reading data while the I/O was occurring to the
        physical pages.  This is only necessary for data reads into the
        vmap area.
+
+Nearly all drivers can handle cache management using the existing DMA model.
+There may be limited circumstances when a driver or framework needs to
+explicitly manage the cache; trying to force cache management into the DMA
+framework may lead to performance loss or unnecessary work. These APIs may
+be used to provide explicit coherency for memory that does not fall into
+any of the above categories. Implementers of this API must assume the
+address can be aliased. Any cache operations shall not be delayed and must
+be completed by the time the call returns.
+
+   void kernel_force_cache_clean(struct page *page, size_t size);
+	Ensures that any data in the cache by the page is written back
+        and visible across all aliases.
+
+   void kernel_force_cache_invalidate(struct page *page, size_t size);
+	Invalidates the cache for the given page.
diff --git a/include/linux/cacheflush.h b/include/linux/cacheflush.h
new file mode 100644
index 0000000..4388846
--- /dev/null
+++ b/include/linux/cacheflush.h
@@ -0,0 +1,11 @@
+#ifndef CACHEFLUSH_H
+#define CACHEFLUSH_H
+
+#include <asm/cacheflush.h>
+
+#ifndef ARCH_HAS_FORCE_CACHE
+static inline void kernel_force_cache_clean(struct page *page, size_t size) { }
+static inline void kernel_force_cache_invalidate(struct page *page, size_t size) { }
+#endif
+
+#endif
-- 
2.7.4

WARNING: multiple messages have this Message-ID (diff)
From: labbott@redhat.com (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFCv3][PATCH 1/5] Documentation: Introduce kernel_force_cache_* APIs
Date: Mon, 12 Sep 2016 14:32:54 -0700	[thread overview]
Message-ID: <1473715978-11633-2-git-send-email-labbott@redhat.com> (raw)
In-Reply-To: <1473715978-11633-1-git-send-email-labbott@redhat.com>


Some frameworks (e.g. Ion) may need to do explicit cache management
to meet performance/correctness requirements. Rather than piggy-back
on another API and hope the semantics don't change, introduce a
set of APIs to force a page to be cleaned/invalidated in the cache.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 Documentation/cachetlb.txt | 18 +++++++++++++++++-
 include/linux/cacheflush.h | 11 +++++++++++
 2 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/cacheflush.h

diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 3f9f808..18eec7c 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -378,7 +378,7 @@ maps this page at its virtual address.
 	flush_dcache_page and update_mmu_cache. In the future, the hope
 	is to remove this interface completely.
 
-The final category of APIs is for I/O to deliberately aliased address
+Another set of APIs is for I/O to deliberately aliased address
 ranges inside the kernel.  Such aliases are set up by use of the
 vmap/vmalloc API.  Since kernel I/O goes via physical pages, the I/O
 subsystem assumes that the user mapping and kernel offset mapping are
@@ -401,3 +401,19 @@ I/O and invalidating it after the I/O returns.
        speculatively reading data while the I/O was occurring to the
        physical pages.  This is only necessary for data reads into the
        vmap area.
+
+Nearly all drivers can handle cache management using the existing DMA model.
+There may be limited circumstances when a driver or framework needs to
+explicitly manage the cache; trying to force cache management into the DMA
+framework may lead to performance loss or unnecessary work. These APIs may
+be used to provide explicit coherency for memory that does not fall into
+any of the above categories. Implementers of this API must assume the
+address can be aliased. Any cache operations shall not be delayed and must
+be completed by the time the call returns.
+
+   void kernel_force_cache_clean(struct page *page, size_t size);
+	Ensures that any data in the cache by the page is written back
+        and visible across all aliases.
+
+   void kernel_force_cache_invalidate(struct page *page, size_t size);
+	Invalidates the cache for the given page.
diff --git a/include/linux/cacheflush.h b/include/linux/cacheflush.h
new file mode 100644
index 0000000..4388846
--- /dev/null
+++ b/include/linux/cacheflush.h
@@ -0,0 +1,11 @@
+#ifndef CACHEFLUSH_H
+#define CACHEFLUSH_H
+
+#include <asm/cacheflush.h>
+
+#ifndef ARCH_HAS_FORCE_CACHE
+static inline void kernel_force_cache_clean(struct page *page, size_t size) { }
+static inline void kernel_force_cache_invalidate(struct page *page, size_t size) { }
+#endif
+
+#endif
-- 
2.7.4

  reply	other threads:[~2016-09-12 21:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-12 21:32 [RFCv3][PATCH 0/5] Cleanup Ion mapping/caching Laura Abbott
2016-09-12 21:32 ` Laura Abbott
2016-09-12 21:32 ` Laura Abbott [this message]
2016-09-12 21:32   ` [RFCv3][PATCH 1/5] Documentation: Introduce kernel_force_cache_* APIs Laura Abbott
2016-09-12 21:32 ` [RFCv3][PATCH 2/5] arm: Impelment ARCH_HAS_FORCE_CACHE Laura Abbott
2016-09-12 21:32   ` Laura Abbott
2016-09-12 21:32 ` [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE Laura Abbott
2016-09-12 21:32   ` Laura Abbott
2016-09-13  9:19   ` Will Deacon
2016-09-13  9:19     ` Will Deacon
2016-09-13 15:02     ` Laura Abbott
2016-09-13 15:02       ` Laura Abbott
2016-09-13 15:14       ` Will Deacon
2016-09-13 15:14         ` Will Deacon
2016-09-13 18:41         ` Laura Abbott
2016-09-13 18:41           ` Laura Abbott
2017-02-21  6:05           ` [Linaro-mm-sig] " Chen Feng
2017-02-21  6:05             ` Chen Feng
2017-02-21 19:29             ` Laura Abbott
2017-02-21 19:29               ` Laura Abbott
2017-02-23  1:01               ` Chen Feng
2017-02-23  1:01                 ` Chen Feng
2017-02-23 16:03                 ` Laura Abbott
2017-02-23 16:03                   ` Laura Abbott
2016-09-12 21:32 ` [RFCv3][PATCH 4/5] staging: android: ion: Convert to the kernel_force_cache APIs Laura Abbott
2016-09-12 21:32   ` Laura Abbott
2016-09-12 21:32 ` [RFCv3][PATCH 5/5] staging: ion: Add support for syncing with DMA_BUF_IOCTL_SYNC Laura Abbott
2016-09-12 21:32   ` Laura Abbott

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=1473715978-11633-2-git-send-email-labbott@redhat.com \
    --to=labbott@redhat.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=arnd@arndb.de \
    --cc=arve@android.com \
    --cc=bryanh@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=devel@driverdev.osuosl.org \
    --cc=eun.taik.lee@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgebben@codeaurora.org \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=riandrews@android.com \
    --cc=rohit.kr@samsung.com \
    --cc=sumit.semwal@linaro.org \
    --cc=tixy@linaro.org \
    --cc=will.deacon@arm.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.