* [PATCH] csky: Fixup ioremap function losing
@ 2019-08-15 11:28 guoren
2019-08-16 7:03 ` Christoph Hellwig
0 siblings, 1 reply; 5+ messages in thread
From: guoren @ 2019-08-15 11:28 UTC (permalink / raw)
To: arnd
Cc: linux-kernel, linux-arch, linux-csky, zhang_jian5, Guo Ren,
Christoph Hellwig
From: Guo Ren <ren_guo@c-sky.com>
Implement the following apis to meet usage in different scenarios.
- ioremap (NonCache + StrongOrder)
- ioremap_nocache (NonCache + StrongOrder)
- ioremap_wc (NonCache + WeakOrder )
- ioremap_cache ( Cache + WeakOrder )
Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@infradead.org>
---
arch/csky/include/asm/io.h | 23 ++++++++++++-----------
arch/csky/mm/ioremap.c | 23 +++++++++++++++++------
2 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/arch/csky/include/asm/io.h b/arch/csky/include/asm/io.h
index c1dfa9c..80d071e 100644
--- a/arch/csky/include/asm/io.h
+++ b/arch/csky/include/asm/io.h
@@ -4,17 +4,10 @@
#ifndef __ASM_CSKY_IO_H
#define __ASM_CSKY_IO_H
-#include <abi/pgtable-bits.h>
+#include <asm/pgtable.h>
#include <linux/types.h>
#include <linux/version.h>
-extern void __iomem *ioremap(phys_addr_t offset, size_t size);
-
-extern void iounmap(void *addr);
-
-extern int remap_area_pages(unsigned long address, phys_addr_t phys_addr,
- size_t size, unsigned long flags);
-
/*
* I/O memory access primitives. Reads are ordered relative to any
* following Normal memory access. Writes are ordered relative to any prior
@@ -40,9 +33,17 @@ extern int remap_area_pages(unsigned long address, phys_addr_t phys_addr,
#define writel(v,c) ({ wmb(); writel_relaxed((v),(c)); mb(); })
#endif
-#define ioremap_nocache(phy, sz) ioremap(phy, sz)
-#define ioremap_wc ioremap_nocache
-#define ioremap_wt ioremap_nocache
+/*
+ * I/O memory mapping functions.
+ */
+extern void __iomem *ioremap_cache(phys_addr_t addr, size_t size);
+extern void __iomem *__ioremap(phys_addr_t addr, size_t size, pgprot_t prot);
+extern void iounmap(void *addr);
+
+#define ioremap(addr, size) __ioremap((addr), (size), pgprot_noncached(PAGE_KERNEL))
+#define ioremap_wc(addr, size) __ioremap((addr), (size), pgprot_writecombine(PAGE_KERNEL))
+#define ioremap_nocache(addr, size) ioremap((addr), (size))
+#define ioremap_cache ioremap_cache
#include <asm-generic/io.h>
diff --git a/arch/csky/mm/ioremap.c b/arch/csky/mm/ioremap.c
index 4853111..e13cd34 100644
--- a/arch/csky/mm/ioremap.c
+++ b/arch/csky/mm/ioremap.c
@@ -8,12 +8,12 @@
#include <asm/pgtable.h>
-void __iomem *ioremap(phys_addr_t addr, size_t size)
+static void __iomem *__ioremap_caller(phys_addr_t addr, size_t size,
+ pgprot_t prot, void *caller)
{
phys_addr_t last_addr;
unsigned long offset, vaddr;
struct vm_struct *area;
- pgprot_t prot;
last_addr = addr + size - 1;
if (!size || last_addr < addr)
@@ -23,14 +23,12 @@ void __iomem *ioremap(phys_addr_t addr, size_t size)
addr &= PAGE_MASK;
size = PAGE_ALIGN(size + offset);
- area = get_vm_area_caller(size, VM_ALLOC, __builtin_return_address(0));
+ area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (!area)
return NULL;
vaddr = (unsigned long)area->addr;
- prot = pgprot_noncached(PAGE_KERNEL);
-
if (ioremap_page_range(vaddr, vaddr + size, addr, prot)) {
free_vm_area(area);
return NULL;
@@ -38,7 +36,20 @@ void __iomem *ioremap(phys_addr_t addr, size_t size)
return (void __iomem *)(vaddr + offset);
}
-EXPORT_SYMBOL(ioremap);
+
+void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t prot)
+{
+ return __ioremap_caller(phys_addr, size, prot,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(__ioremap);
+
+void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
+{
+ return __ioremap_caller(phys_addr, size, PAGE_KERNEL,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(ioremap_cache);
void iounmap(void __iomem *addr)
{
--
2.7.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] csky: Fixup ioremap function losing
2019-08-15 11:28 [PATCH] csky: Fixup ioremap function losing guoren
@ 2019-08-16 7:03 ` Christoph Hellwig
2019-08-18 2:20 ` Guo Ren
0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2019-08-16 7:03 UTC (permalink / raw)
To: guoren
Cc: arnd, linux-kernel, linux-arch, linux-csky, zhang_jian5, Guo Ren,
Christoph Hellwig
On Thu, Aug 15, 2019 at 07:28:57PM +0800, guoren@kernel.org wrote:
> From: Guo Ren <ren_guo@c-sky.com>
>
> Implement the following apis to meet usage in different scenarios.
>
> - ioremap (NonCache + StrongOrder)
> - ioremap_nocache (NonCache + StrongOrder)
> - ioremap_wc (NonCache + WeakOrder )
> - ioremap_cache ( Cache + WeakOrder )
>
> Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller.
Looks generally fine, but two comments:
- do you have a need for ioremap_cache? We are generally try to
phase it out in favour of memremap, and it is generally only used
by arch specific code.
- I have a big series pending to clean up the mess with our
ioremap_* functions, including adding a generic implementation
that csky should be able to use. Unless this patch is urgent it
might make sense to rebase it on top. Here is my current tree, I
plan to post it soon:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-ioremap
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] csky: Fixup ioremap function losing
2019-08-16 7:03 ` Christoph Hellwig
@ 2019-08-18 2:20 ` Guo Ren
2019-08-18 18:21 ` Christoph Hellwig
0 siblings, 1 reply; 5+ messages in thread
From: Guo Ren @ 2019-08-18 2:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Arnd Bergmann, Linux Kernel Mailing List, linux-arch, linux-csky,
zhang_jian5, Guo Ren
Thx Christoph,
On Fri, Aug 16, 2019 at 3:03 PM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Thu, Aug 15, 2019 at 07:28:57PM +0800, guoren@kernel.org wrote:
> > From: Guo Ren <ren_guo@c-sky.com>
> >
> > Implement the following apis to meet usage in different scenarios.
> >
> > - ioremap (NonCache + StrongOrder)
> > - ioremap_nocache (NonCache + StrongOrder)
> > - ioremap_wc (NonCache + WeakOrder )
> > - ioremap_cache ( Cache + WeakOrder )
> >
> > Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller.
>
> Looks generally fine, but two comments:
>
> - do you have a need for ioremap_cache? We are generally try to
> phase it out in favour of memremap, and it is generally only used
> by arch specific code.
Yes, some drivers of our customers use ioremap_cache to map phy_addr
which isn't belong to system memory.
> - I have a big series pending to clean up the mess with our
> ioremap_* functions, including adding a generic implementation
> that csky should be able to use. Unless this patch is urgent it
> might make sense to rebase it on top. Here is my current tree, I
> plan to post it soon:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-ioremap
I agree to use GENERIC_IOREMAP, but I want to add csky support
GENERIC_IOREMAP patch by myself.
You could remove "csky: use generic ioremap" in your patchset first
and I'll add support GENERIC_IORMAP patch later.
Then we won't get confilct :)
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] csky: Fixup ioremap function losing
2019-08-18 2:20 ` Guo Ren
@ 2019-08-18 18:21 ` Christoph Hellwig
2019-08-20 8:26 ` Guo Ren
0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2019-08-18 18:21 UTC (permalink / raw)
To: Guo Ren
Cc: Christoph Hellwig, Arnd Bergmann, Linux Kernel Mailing List,
linux-arch, linux-csky, zhang_jian5, Guo Ren
On Sun, Aug 18, 2019 at 10:20:18AM +0800, Guo Ren wrote:
> > > Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller.
> >
> > Looks generally fine, but two comments:
> >
> > - do you have a need for ioremap_cache? We are generally try to
> > phase it out in favour of memremap, and it is generally only used
> > by arch specific code.
> Yes, some drivers of our customers use ioremap_cache to map phy_addr
> which isn't belong to system memory.
Which driver? We should move it over to memremap instead of adding
a new ioremap_cache.
> I agree to use GENERIC_IOREMAP, but I want to add csky support
> GENERIC_IOREMAP patch by myself.
> You could remove "csky: use generic ioremap" in your patchset first
> and I'll add support GENERIC_IORMAP patch later.
> Then we won't get confilct :)
Ok.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] csky: Fixup ioremap function losing
2019-08-18 18:21 ` Christoph Hellwig
@ 2019-08-20 8:26 ` Guo Ren
0 siblings, 0 replies; 5+ messages in thread
From: Guo Ren @ 2019-08-20 8:26 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Arnd Bergmann, Linux Kernel Mailing List, linux-arch, linux-csky,
zhang_jian5, Guo Ren
On Mon, Aug 19, 2019 at 2:21 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Sun, Aug 18, 2019 at 10:20:18AM +0800, Guo Ren wrote:
> > > > Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller.
> > >
> > > Looks generally fine, but two comments:
> > >
> > > - do you have a need for ioremap_cache? We are generally try to
> > > phase it out in favour of memremap, and it is generally only used
> > > by arch specific code.
> > Yes, some drivers of our customers use ioremap_cache to map phy_addr
> > which isn't belong to system memory.
>
> Which driver? We should move it over to memremap instead of adding
> a new ioremap_cache.
The driver hasn't been upstreamed. OK, just remove ioremap_cache and
seems it's not a big problem.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-08-20 8:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-15 11:28 [PATCH] csky: Fixup ioremap function losing guoren
2019-08-16 7:03 ` Christoph Hellwig
2019-08-18 2:20 ` Guo Ren
2019-08-18 18:21 ` Christoph Hellwig
2019-08-20 8:26 ` Guo Ren
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).