From: Arnd Bergmann <arnd@arndb.de>
To: James Hogan <james.hogan@imgtec.com>
Cc: linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [RFC PATCH v1 00/40] Meta Linux Kernel Port
Date: Fri, 9 Nov 2012 15:06:14 +0000 [thread overview]
Message-ID: <201211091506.14940.arnd@arndb.de> (raw)
In-Reply-To: <5091513C.9040901@imgtec.com>
On Wednesday 31 October 2012, James Hogan wrote:
> Apologies. It appears the following two patches were too large and got
> blocked. I'll split them up. In the mean time, here are github links:
> > metag: Memory management
>
> https://github.com/jahogan/metag-linux/commit/34c0fe0d6ab61f83a56f9e9d3ea04adddaa7a1d4
>
pasting my comments here:
>diff --git a/arch/metag/include/asm/io.h b/arch/metag/include/asm/io.h
>new file mode 100644
>index 0000000..d67adb3
>--- /dev/null
>+++ b/arch/metag/include/asm/io.h
>@@ -0,0 +1,96 @@
>+#ifndef _ASM_METAG_IO_H
>+#define _ASM_METAG_IO_H
>+
>+#ifdef __KERNEL__
>+
>+#define IO_SPACE_LIMIT 0xFFFFFFFF
You should make this one 0 if you have no PCI I/O space. If you have it, it
should be the actual size of the window.
>+#define virt_to_bus virt_to_phys
>+#define bus_to_virt phys_to_virt
As mentioned in another patch, I would recommend removing these and defining
ARCH_NO_VIRT_TO_BUS in Kconfig.
>+ * Despite being a 32bit architecture, Meta can do 64bit memory accesses
>+ * (assuming the bus supports it).
>+ */
>+
>+static inline u64 __raw_readq(const volatile void __iomem *addr)
>+{
>+ return *(const volatile u64 __force *) addr;
>+}
>+#define readq(addr) __raw_readq(addr)
>+
>+static inline void __raw_writeq(u64 b, volatile void __iomem *addr)
>+{
>+ *(volatile u64 __force *) addr = b;
>+}
>+#define writeq(b, addr) __raw_writeq(b, addr)
These should be using an inline assembly to guarantee that it gets
turned into an atomic access, at least of the architecture has
an atomic 64-bit load/store from memory operation.
>+/*
>+ * A load of the architecture code uses read/write functions with raw physical
>+ * address numbers rather than __iomem pointers. Until these are fixed, do the
>+ * cast here to hide the warnings.
>+ */
>+
>+#undef readb
>+#undef readw
>+#undef readl
>+#undef readq
>+#define readb(addr) __raw_readb((volatile void __iomem *)(addr))
>+#define readw(addr) __raw_readw((volatile void __iomem *)(addr))
>+#define readl(addr) __raw_readl((volatile void __iomem *)(addr))
>+#define readq(addr) __raw_readq((volatile void __iomem *)(addr))
No, fix the drivers instead. We finally did the same thing on ARM,
so all common upstream drivers should be clean now. As for atomic accesses,
the same comment as above applies, so use inline assembly here.
You can of course keep an out-of-tree patch that puts the type casts
back here to help migrating any out-of-tree device drivers, just make
sure that whatever you merge upstream does it right.
>diff --git a/arch/metag/mm/mmu-meta1.c b/arch/metag/mm/mmu-meta1.c
>new file mode 100644
>index 0000000..5e1f7d8
>--- /dev/null
>+++ b/arch/metag/mm/mmu-meta1.c
>@@ -0,0 +1,157 @@
>+/*
>+ * Copyright (C) 2005,2006,2007,2008,2009 Imagination Technologies
>+ *
>+ * Meta 1 MMU handling code.
>+ *
>+ */
>+
>+#include <linux/sched.h>
>+#include <linux/mm.h>
>+#include <linux/io.h>
>+
>+#include <asm/mmu.h>
>+
>+#define DM3_BASE (LINSYSDIRECT_BASE + (MMCU_DIRECTMAPn_ADDR_SCALE * 3))
Again, don't hardcode MMIO addresses like this, but instead get them
from the device tree to make the code more portable to future systems.
Arnd
next prev parent reply other threads:[~2012-11-09 15:06 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 16:13 [RFC PATCH v1 00/40] Meta Linux Kernel Port James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 01/40] asm-generic/io.h: remove asm/cacheflush.h include James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 02/40] asm-generic/unistd.h: handle symbol prefixes in cond_syscall James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 03/40] Add CONFIG_HAVE_64BIT_ALIGNED_STRUCT for taskstats James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 04/40] trace/ring_buffer: handle 64bit aligned structs James Hogan
2012-10-31 17:59 ` Steven Rostedt
2012-10-31 18:19 ` James Hogan
2012-11-01 17:32 ` Will Newton
2012-11-01 19:30 ` Steven Rostedt
2012-10-31 16:13 ` [RFC PATCH v1 05/40] Revert some of "binfmt_elf: cleanups" James Hogan
2012-11-01 13:25 ` Mikael Pettersson
2012-11-01 13:25 ` Mikael Pettersson
2012-11-01 13:52 ` James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 06/40] of/vendor-prefixes: add Imagination Technologies James Hogan
2012-11-01 1:38 ` Rob Herring
2012-11-01 9:20 ` James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 07/40] metag: Add MAINTAINERS entry James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 08/40] metag: Boot James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 11/40] metag: Signal handling James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 12/40] metag: Build infrastructure James Hogan
2012-10-31 19:35 ` Sam Ravnborg
2012-10-31 21:34 ` James Hogan
2012-11-02 9:40 ` James Hogan
2012-11-02 17:01 ` Sam Ravnborg
2012-11-09 14:46 ` Arnd Bergmann
2012-11-09 14:55 ` James Hogan
2012-11-20 15:06 ` James Hogan
2012-11-20 15:43 ` Arnd Bergmann
2012-11-20 16:01 ` James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 13/40] metag: Device tree James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 14/40] metag: Ptrace James Hogan
2012-11-08 7:17 ` Jonas Bonn
2012-11-09 9:26 ` James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 15/40] metag: Time keeping James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 16/40] metag: Traps James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 17/40] metag: IRQ handling James Hogan
2012-11-09 14:12 ` Arnd Bergmann
2012-11-20 16:08 ` James Hogan
2012-11-20 16:15 ` Arnd Bergmann
2012-12-18 13:25 ` James Hogan
2012-12-19 15:58 ` Arnd Bergmann
2012-12-20 10:14 ` James Hogan
2012-10-31 16:13 ` [RFC PATCH v1 18/40] metag: System Calls James Hogan
2012-11-09 14:20 ` Arnd Bergmann
2012-11-22 12:01 ` James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 19/40] metag: Scheduling/Process management James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 20/40] metag: Module support James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 21/40] metag: Atomics, locks and bitops James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 22/40] metag: Basic documentation James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 23/40] metag: SMP support James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 24/40] metag: DMA James Hogan
2012-11-09 14:25 ` Arnd Bergmann
2012-11-23 15:53 ` James Hogan
2012-11-23 16:20 ` James Hogan
2012-11-23 16:47 ` Arnd Bergmann
2013-01-09 16:04 ` James Hogan
2013-01-09 16:04 ` James Hogan
2013-01-09 16:08 ` Arnd Bergmann
2012-11-23 16:47 ` Arnd Bergmann
2012-10-31 16:14 ` [RFC PATCH v1 25/40] metag: optimised library functions James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 26/40] metag: Stack unwinding James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 27/40] metag: various other headers James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 28/40] metag: Perf James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 29/40] metag: ftrace support James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 30/40] scripts/checkstack.pl: Add metag support James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 31/40] char: don't build rtc or genrtc on METAG James Hogan
2012-11-01 15:39 ` Greg KH
2012-11-01 17:33 ` James Hogan
2012-11-09 14:38 ` Arnd Bergmann
2012-10-31 16:14 ` [RFC PATCH v1 32/40] i8042: don't build " James Hogan
2012-11-09 14:28 ` Arnd Bergmann
2012-11-16 11:06 ` James Hogan
2012-11-16 15:20 ` Arnd Bergmann
2012-11-16 16:19 ` Geert Uytterhoeven
2012-11-16 16:43 ` Arnd Bergmann
2012-11-16 16:50 ` James Hogan
2012-11-16 17:20 ` Arnd Bergmann
2012-10-31 16:14 ` [RFC PATCH v1 33/40] parport: " James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 34/40] musb: don't redefine {read,write}s{l,w,b} on metag James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 35/40] vga console: don't build on METAG James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 36/40] metag: OProfile James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 37/40] metag: Various sysfs drivers James Hogan
2012-10-31 19:30 ` Greg KH
2012-10-31 19:41 ` James Hogan
2012-11-09 14:32 ` Arnd Bergmann
2012-11-09 14:35 ` James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 38/40] metag: add JTAG Debug Adapter (DA) support James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 39/40] tty/metag_da: add metag DA TTY driver James Hogan
2012-10-31 16:14 ` [RFC PATCH v1 40/40] fs: dafs: Add DAFS filesystem for metag James Hogan
2012-10-31 16:42 ` Al Viro
2012-10-31 19:39 ` James Hogan
2012-10-31 19:39 ` James Hogan
2012-10-31 19:55 ` Myklebust, Trond
2012-10-31 19:55 ` Myklebust, Trond
2012-10-31 21:39 ` James Hogan
2012-10-31 21:39 ` James Hogan
2012-11-02 9:33 ` James Hogan
2012-11-02 9:33 ` James Hogan
2012-10-31 16:26 ` [RFC PATCH v1 00/40] Meta Linux Kernel Port James Hogan
2012-11-09 15:06 ` Arnd Bergmann [this message]
2012-11-09 15:21 ` James Hogan
2012-11-09 15:58 ` Arnd Bergmann
2012-11-09 16:20 ` James Hogan
2012-11-09 21:55 ` Arnd Bergmann
2012-11-09 23:28 ` James Hogan
2012-11-12 16:59 ` James Hogan
2012-11-12 19:10 ` Arnd Bergmann
2012-11-13 9:43 ` James Hogan
2012-11-13 9:55 ` Arnd Bergmann
2012-10-31 22:33 ` Tony Breeds
2012-11-01 11:42 ` James Hogan
2012-11-01 23:28 ` Tony Breeds
2012-11-09 16:52 ` James Hogan
2012-11-09 15:16 ` Arnd Bergmann
2012-11-09 16:06 ` James Hogan
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=201211091506.14940.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=james.hogan@imgtec.com \
--cc=linux-arch@vger.kernel.org \
/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 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).