Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-15 Thread Olof Johansson 
On Fri, Sep 14, 2012 at 06:39:46PM +0100, Catalin Marinas wrote:
> On Fri, Sep 14, 2012 at 06:31:59PM +0100, Arnd Bergmann wrote:
> > On Friday 14 September 2012, Catalin Marinas wrote:
> > > (revisiting unanswered emails :))
> > > 
> > > On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
> > > > On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
> > > > > +/*
> > > > > + *  I/O port access primitives.
> > > > > + */
> > > > > +#define IO_SPACE_LIMIT 0x
> > > > > +
> > > > > +/*
> > > > > + * We currently don't have any platform with PCI support, so just 
> > > > > leave this
> > > > > + * defined to 0 until needed.
> > > > > + */
> > > > > +#define PCI_IOBASE ((void __iomem *)0)
> > > > 
> > > > You could just leave out the PCI / I/O code alltogether instead.
> > > 
> > > I would leave this in as some of the first platforms to appear will have
> > > PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
> > > mapped.
> > > 
> > 
> > I guess the cleanest way would be to reserve a virtual memory region right 
> > away
> > and document it in the file where you describe the memory layout. Then you 
> > can
> > fill the value in here.
> 
> Yes, easy to do. Any access will fault until we add the PCI support.

Sounds good to me.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-15 Thread Olof Johansson 
On Fri, Sep 14, 2012 at 06:39:46PM +0100, Catalin Marinas wrote:
 On Fri, Sep 14, 2012 at 06:31:59PM +0100, Arnd Bergmann wrote:
  On Friday 14 September 2012, Catalin Marinas wrote:
   (revisiting unanswered emails :))
   
   On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
 +/*
 + *  I/O port access primitives.
 + */
 +#define IO_SPACE_LIMIT 0x
 +
 +/*
 + * We currently don't have any platform with PCI support, so just 
 leave this
 + * defined to 0 until needed.
 + */
 +#define PCI_IOBASE ((void __iomem *)0)

You could just leave out the PCI / I/O code alltogether instead.
   
   I would leave this in as some of the first platforms to appear will have
   PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
   mapped.
   
  
  I guess the cleanest way would be to reserve a virtual memory region right 
  away
  and document it in the file where you describe the memory layout. Then you 
  can
  fill the value in here.
 
 Yes, easy to do. Any access will fault until we add the PCI support.

Sounds good to me.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-14 Thread Catalin Marinas 
On Fri, Sep 14, 2012 at 06:31:59PM +0100, Arnd Bergmann wrote:
> On Friday 14 September 2012, Catalin Marinas wrote:
> > (revisiting unanswered emails :))
> > 
> > On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
> > > On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
> > > > +/*
> > > > + *  I/O port access primitives.
> > > > + */
> > > > +#define IO_SPACE_LIMIT 0x
> > > > +
> > > > +/*
> > > > + * We currently don't have any platform with PCI support, so just 
> > > > leave this
> > > > + * defined to 0 until needed.
> > > > + */
> > > > +#define PCI_IOBASE ((void __iomem *)0)
> > > 
> > > You could just leave out the PCI / I/O code alltogether instead.
> > 
> > I would leave this in as some of the first platforms to appear will have
> > PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
> > mapped.
> > 
> 
> I guess the cleanest way would be to reserve a virtual memory region right 
> away
> and document it in the file where you describe the memory layout. Then you can
> fill the value in here.

Yes, easy to do. Any access will fault until we add the PCI support.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-14 Thread Arnd Bergmann 
On Friday 14 September 2012, Catalin Marinas wrote:
> (revisiting unanswered emails :))
> 
> On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
> > On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
> > > +/*
> > > + *  I/O port access primitives.
> > > + */
> > > +#define IO_SPACE_LIMIT 0x
> > > +
> > > +/*
> > > + * We currently don't have any platform with PCI support, so just leave 
> > > this
> > > + * defined to 0 until needed.
> > > + */
> > > +#define PCI_IOBASE ((void __iomem *)0)
> > 
> > You could just leave out the PCI / I/O code alltogether instead.
> 
> I would leave this in as some of the first platforms to appear will have
> PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
> mapped.
> 

I guess the cleanest way would be to reserve a virtual memory region right away
and document it in the file where you describe the memory layout. Then you can
fill the value in here.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-14 Thread Catalin Marinas 
(revisiting unanswered emails :))

On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
> On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
> > +/*
> > + *  I/O port access primitives.
> > + */
> > +#define IO_SPACE_LIMIT 0x
> > +
> > +/*
> > + * We currently don't have any platform with PCI support, so just leave 
> > this
> > + * defined to 0 until needed.
> > + */
> > +#define PCI_IOBASE ((void __iomem *)0)
> 
> You could just leave out the PCI / I/O code alltogether instead.

I would leave this in as some of the first platforms to appear will have
PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
mapped.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-14 Thread Catalin Marinas 
(revisiting unanswered emails :))

On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
 On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
  +/*
  + *  I/O port access primitives.
  + */
  +#define IO_SPACE_LIMIT 0x
  +
  +/*
  + * We currently don't have any platform with PCI support, so just leave 
  this
  + * defined to 0 until needed.
  + */
  +#define PCI_IOBASE ((void __iomem *)0)
 
 You could just leave out the PCI / I/O code alltogether instead.

I would leave this in as some of the first platforms to appear will have
PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
mapped.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-14 Thread Arnd Bergmann 
On Friday 14 September 2012, Catalin Marinas wrote:
 (revisiting unanswered emails :))
 
 On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
  On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
   +/*
   + *  I/O port access primitives.
   + */
   +#define IO_SPACE_LIMIT 0x
   +
   +/*
   + * We currently don't have any platform with PCI support, so just leave 
   this
   + * defined to 0 until needed.
   + */
   +#define PCI_IOBASE ((void __iomem *)0)
  
  You could just leave out the PCI / I/O code alltogether instead.
 
 I would leave this in as some of the first platforms to appear will have
 PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
 mapped.
 

I guess the cleanest way would be to reserve a virtual memory region right away
and document it in the file where you describe the memory layout. Then you can
fill the value in here.

Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-09-14 Thread Catalin Marinas 
On Fri, Sep 14, 2012 at 06:31:59PM +0100, Arnd Bergmann wrote:
 On Friday 14 September 2012, Catalin Marinas wrote:
  (revisiting unanswered emails :))
  
  On Wed, Aug 15, 2012 at 01:33:55AM +0100, Olof Johansson wrote:
   On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
+/*
+ *  I/O port access primitives.
+ */
+#define IO_SPACE_LIMIT 0x
+
+/*
+ * We currently don't have any platform with PCI support, so just 
leave this
+ * defined to 0 until needed.
+ */
+#define PCI_IOBASE ((void __iomem *)0)
   
   You could just leave out the PCI / I/O code alltogether instead.
  
  I would leave this in as some of the first platforms to appear will have
  PCIe. At some point we'll add a fixed address where the PCI_IOBASE is
  mapped.
  
 
 I guess the cleanest way would be to reserve a virtual memory region right 
 away
 and document it in the file where you describe the memory layout. Then you can
 fill the value in here.

Yes, easy to do. Any access will fault until we add the PCI support.

-- 
Catalin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-08-17 Thread Tony Lindgren 
* Catalin Marinas  [120814 11:05]:
> --- /dev/null
> +++ b/arch/arm64/mm/ioremap.c
> +
> +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);

>From SoC point of view, we're probably going to need __ioremap_exec()
here too for programming clocks during runtime in SRAM etc. But that
can be added later as needed.

Acked-by: Tony Lindgren 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-08-17 Thread Tony Lindgren 
* Catalin Marinas catalin.mari...@arm.com [120814 11:05]:
 --- /dev/null
 +++ b/arch/arm64/mm/ioremap.c
 +
 +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);

From SoC point of view, we're probably going to need __ioremap_exec()
here too for programming clocks during runtime in SRAM etc. But that
can be added later as needed.

Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-08-15 Thread Arnd Bergmann 
On Tuesday 14 August 2012, Catalin Marinas wrote:
> 
> This patch adds several definitions for device communication, including
> I/O accessors and ioremap(). The __raw_* accessors are implemented as
> inline asm to avoid compiler generation of post-indexed accesses (less
> efficient to emulate in a virtualised environment).
> 
> Signed-off-by: Will Deacon 
> Signed-off-by: Catalin Marinas 


Acked-by: Arnd Bergmann 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-08-15 Thread Arnd Bergmann 
On Tuesday 14 August 2012, Catalin Marinas wrote:
 
 This patch adds several definitions for device communication, including
 I/O accessors and ioremap(). The __raw_* accessors are implemented as
 inline asm to avoid compiler generation of post-indexed accesses (less
 efficient to emulate in a virtualised environment).
 
 Signed-off-by: Will Deacon will.dea...@arm.com
 Signed-off-by: Catalin Marinas catalin.mari...@arm.com


Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-08-14 Thread Olof Johansson 
On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
> This patch adds several definitions for device communication, including
> I/O accessors and ioremap(). The __raw_* accessors are implemented as
> inline asm to avoid compiler generation of post-indexed accesses (less
> efficient to emulate in a virtualised environment).
> 
> Signed-off-by: Will Deacon 
> Signed-off-by: Catalin Marinas 
> ---
>  arch/arm64/include/asm/device.h |   26 
>  arch/arm64/include/asm/fb.h |   34 +
>  arch/arm64/include/asm/io.h |  263 
> +++
>  arch/arm64/kernel/io.c  |   64 ++
>  arch/arm64/mm/ioremap.c |   84 +
>  5 files changed, 471 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm64/include/asm/device.h
>  create mode 100644 arch/arm64/include/asm/fb.h
>  create mode 100644 arch/arm64/include/asm/io.h
>  create mode 100644 arch/arm64/kernel/io.c
>  create mode 100644 arch/arm64/mm/ioremap.c
> 
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> new file mode 100644
> index 000..48fa83f
> --- /dev/null
> +++ b/arch/arm64/include/asm/io.h

[...]

> +/*
> + *  I/O port access primitives.
> + */
> +#define IO_SPACE_LIMIT   0x
> +
> +/*
> + * We currently don't have any platform with PCI support, so just leave this
> + * defined to 0 until needed.
> + */
> +#define PCI_IOBASE   ((void __iomem *)0)

You could just leave out the PCI / I/O code alltogether instead.

> diff --git a/arch/arm64/kernel/io.c b/arch/arm64/kernel/io.c
> new file mode 100644
> index 000..7d37ead
> --- /dev/null
> +++ b/arch/arm64/kernel/io.c
> @@ -0,0 +1,64 @@
> +/*
> + * Based on arch/arm/kernel/io.c
> + *
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Copy data from IO memory space to "real" memory space.
> + */
> +void __memcpy_fromio(void *to, const volatile void __iomem *from, size_t 
> count)
> +{
> + unsigned char *t = to;
> + while (count) {
> + count--;
> + *t = readb(from);
> + t++;
> + from++;
> + }
> +}
> +EXPORT_SYMBOL(__memcpy_fromio);
> +
> +/*
> + * Copy data from "real" memory space to IO memory space.
> + */
> +void __memcpy_toio(volatile void __iomem *to, const void *from, size_t count)
> +{
> + const unsigned char *f = from;
> + while (count) {
> + count--;
> + writeb(*f, to);
> + f++;
> + to++;
> + }
> +}
> +EXPORT_SYMBOL(__memcpy_toio);
> +
> +/*
> + * "memset" on IO memory space.
> + */
> +void __memset_io(volatile void __iomem *dst, int c, size_t count)
> +{
> + while (count) {
> + count--;
> + writeb(c, dst);
> + dst++;
> + }
> +}
> +EXPORT_SYMBOL(__memset_io);

Doing all of the above a byte at a time is horribly inefficient. Feel
free to borrow the implementations from arch/powerpc/kernel/io.c instead
of from ARM.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 13/31] arm64: Device specific operations

2012-08-14 Thread Catalin Marinas 
This patch adds several definitions for device communication, including
I/O accessors and ioremap(). The __raw_* accessors are implemented as
inline asm to avoid compiler generation of post-indexed accesses (less
efficient to emulate in a virtualised environment).

Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas 
---
 arch/arm64/include/asm/device.h |   26 
 arch/arm64/include/asm/fb.h |   34 +
 arch/arm64/include/asm/io.h |  263 +++
 arch/arm64/kernel/io.c  |   64 ++
 arch/arm64/mm/ioremap.c |   84 +
 5 files changed, 471 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/include/asm/device.h
 create mode 100644 arch/arm64/include/asm/fb.h
 create mode 100644 arch/arm64/include/asm/io.h
 create mode 100644 arch/arm64/kernel/io.c
 create mode 100644 arch/arm64/mm/ioremap.c

diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
new file mode 100644
index 000..0d8453c
--- /dev/null
+++ b/arch/arm64/include/asm/device.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_DEVICE_H
+#define __ASM_DEVICE_H
+
+struct dev_archdata {
+   struct dma_map_ops *dma_ops;
+};
+
+struct pdev_archdata {
+};
+
+#endif
diff --git a/arch/arm64/include/asm/fb.h b/arch/arm64/include/asm/fb.h
new file mode 100644
index 000..adb88a6
--- /dev/null
+++ b/arch/arm64/include/asm/fb.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_FB_H_
+#define __ASM_FB_H_
+
+#include 
+#include 
+#include 
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+   unsigned long off)
+{
+   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+   return 0;
+}
+
+#endif /* __ASM_FB_H_ */
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
new file mode 100644
index 000..48fa83f
--- /dev/null
+++ b/arch/arm64/include/asm/io.h
@@ -0,0 +1,263 @@
+/*
+ * Based on arch/arm/include/asm/io.h
+ *
+ * Copyright (C) 1996-2000 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_IO_H
+#define __ASM_IO_H
+
+#ifdef __KERNEL__
+
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ * Generic IO read/write.  These perform native-endian accesses.
+ */
+static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
+{
+   asm volatile("strb %w0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline void __raw_writew(u16 val, volatile void __iomem *addr)
+{
+   asm volatile("strh %w0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+{
+   asm volatile("str %w0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+   asm volatile("str %0, [%1]" : : "r" (val), "r" (addr));
+}
+
+static inline u8 __raw_readb(const volatile void __iomem *addr)
+{
+   u8 val;
+   asm volatile("ldrb %w0, [%1]" : "=r" (val) : "r" (addr));
+   return val;
+}
+
+static inline u16 __raw_readw(const volatile void __iomem *addr)

[PATCH v2 13/31] arm64: Device specific operations

2012-08-14 Thread Catalin Marinas 
This patch adds several definitions for device communication, including
I/O accessors and ioremap(). The __raw_* accessors are implemented as
inline asm to avoid compiler generation of post-indexed accesses (less
efficient to emulate in a virtualised environment).

Signed-off-by: Will Deacon will.dea...@arm.com
Signed-off-by: Catalin Marinas catalin.mari...@arm.com
---
 arch/arm64/include/asm/device.h |   26 
 arch/arm64/include/asm/fb.h |   34 +
 arch/arm64/include/asm/io.h |  263 +++
 arch/arm64/kernel/io.c  |   64 ++
 arch/arm64/mm/ioremap.c |   84 +
 5 files changed, 471 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm64/include/asm/device.h
 create mode 100644 arch/arm64/include/asm/fb.h
 create mode 100644 arch/arm64/include/asm/io.h
 create mode 100644 arch/arm64/kernel/io.c
 create mode 100644 arch/arm64/mm/ioremap.c

diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
new file mode 100644
index 000..0d8453c
--- /dev/null
+++ b/arch/arm64/include/asm/device.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_DEVICE_H
+#define __ASM_DEVICE_H
+
+struct dev_archdata {
+   struct dma_map_ops *dma_ops;
+};
+
+struct pdev_archdata {
+};
+
+#endif
diff --git a/arch/arm64/include/asm/fb.h b/arch/arm64/include/asm/fb.h
new file mode 100644
index 000..adb88a6
--- /dev/null
+++ b/arch/arm64/include/asm/fb.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_FB_H_
+#define __ASM_FB_H_
+
+#include linux/fb.h
+#include linux/fs.h
+#include asm/page.h
+
+static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
+   unsigned long off)
+{
+   vma-vm_page_prot = pgprot_writecombine(vma-vm_page_prot);
+}
+
+static inline int fb_is_primary_device(struct fb_info *info)
+{
+   return 0;
+}
+
+#endif /* __ASM_FB_H_ */
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
new file mode 100644
index 000..48fa83f
--- /dev/null
+++ b/arch/arm64/include/asm/io.h
@@ -0,0 +1,263 @@
+/*
+ * Based on arch/arm/include/asm/io.h
+ *
+ * Copyright (C) 1996-2000 Russell King
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/.
+ */
+#ifndef __ASM_IO_H
+#define __ASM_IO_H
+
+#ifdef __KERNEL__
+
+#include linux/types.h
+
+#include asm/byteorder.h
+#include asm/barrier.h
+#include asm/pgtable.h
+
+/*
+ * Generic IO read/write.  These perform native-endian accesses.
+ */
+static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
+{
+   asm volatile(strb %w0, [%1] : : r (val), r (addr));
+}
+
+static inline void __raw_writew(u16 val, volatile void __iomem *addr)
+{
+   asm volatile(strh %w0, [%1] : : r (val), r (addr));
+}
+
+static inline void __raw_writel(u32 val, volatile void __iomem *addr)
+{
+   asm volatile(str %w0, [%1] : : r (val), r (addr));
+}
+
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+   asm volatile(str %0, [%1] : : r (val), r (addr));
+}
+
+static inline u8 __raw_readb(const volatile void __iomem *addr)
+{
+   u8 val;
+   asm volatile(ldrb %w0, [%1] : =r (val) : r (addr));
+

Re: [PATCH v2 13/31] arm64: Device specific operations

2012-08-14 Thread Olof Johansson 
On Tue, Aug 14, 2012 at 06:52:14PM +0100, Catalin Marinas wrote:
 This patch adds several definitions for device communication, including
 I/O accessors and ioremap(). The __raw_* accessors are implemented as
 inline asm to avoid compiler generation of post-indexed accesses (less
 efficient to emulate in a virtualised environment).
 
 Signed-off-by: Will Deacon will.dea...@arm.com
 Signed-off-by: Catalin Marinas catalin.mari...@arm.com
 ---
  arch/arm64/include/asm/device.h |   26 
  arch/arm64/include/asm/fb.h |   34 +
  arch/arm64/include/asm/io.h |  263 
 +++
  arch/arm64/kernel/io.c  |   64 ++
  arch/arm64/mm/ioremap.c |   84 +
  5 files changed, 471 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm64/include/asm/device.h
  create mode 100644 arch/arm64/include/asm/fb.h
  create mode 100644 arch/arm64/include/asm/io.h
  create mode 100644 arch/arm64/kernel/io.c
  create mode 100644 arch/arm64/mm/ioremap.c
 
 diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
 new file mode 100644
 index 000..48fa83f
 --- /dev/null
 +++ b/arch/arm64/include/asm/io.h

[...]

 +/*
 + *  I/O port access primitives.
 + */
 +#define IO_SPACE_LIMIT   0x
 +
 +/*
 + * We currently don't have any platform with PCI support, so just leave this
 + * defined to 0 until needed.
 + */
 +#define PCI_IOBASE   ((void __iomem *)0)

You could just leave out the PCI / I/O code alltogether instead.

 diff --git a/arch/arm64/kernel/io.c b/arch/arm64/kernel/io.c
 new file mode 100644
 index 000..7d37ead
 --- /dev/null
 +++ b/arch/arm64/kernel/io.c
 @@ -0,0 +1,64 @@
 +/*
 + * Based on arch/arm/kernel/io.c
 + *
 + * Copyright (C) 2012 ARM Ltd.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see http://www.gnu.org/licenses/.
 + */
 +
 +#include linux/export.h
 +#include linux/types.h
 +#include linux/io.h
 +
 +/*
 + * Copy data from IO memory space to real memory space.
 + */
 +void __memcpy_fromio(void *to, const volatile void __iomem *from, size_t 
 count)
 +{
 + unsigned char *t = to;
 + while (count) {
 + count--;
 + *t = readb(from);
 + t++;
 + from++;
 + }
 +}
 +EXPORT_SYMBOL(__memcpy_fromio);
 +
 +/*
 + * Copy data from real memory space to IO memory space.
 + */
 +void __memcpy_toio(volatile void __iomem *to, const void *from, size_t count)
 +{
 + const unsigned char *f = from;
 + while (count) {
 + count--;
 + writeb(*f, to);
 + f++;
 + to++;
 + }
 +}
 +EXPORT_SYMBOL(__memcpy_toio);
 +
 +/*
 + * memset on IO memory space.
 + */
 +void __memset_io(volatile void __iomem *dst, int c, size_t count)
 +{
 + while (count) {
 + count--;
 + writeb(c, dst);
 + dst++;
 + }
 +}
 +EXPORT_SYMBOL(__memset_io);

Doing all of the above a byte at a time is horribly inefficient. Feel
free to borrow the implementations from arch/powerpc/kernel/io.c instead
of from ARM.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/