* [PATCH v3 1/6] ARM: Add interface for registering and calling firmware-specific operations
From: Tomasz Figa @ 2012-10-25 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351178560-19188-1-git-send-email-t.figa@samsung.com>
Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized.
This patch adds an interface for platforms to specify available firmware
operations and call them.
A wrapper macro, call_firmware_op(), checks if the operation is provided
and calls it if so, otherwise returns -ENOSYS to allow fallback to
legacy operation..
By default no operations are provided.
Example of use:
In code using firmware ops:
__raw_writel(virt_to_phys(exynos4_secondary_startup),
CPU1_BOOT_REG);
/* Call Exynos specific smc call */
if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
cpu_boot_legacy(...); /* Try legacy way */
gic_raise_softirq(cpumask_of(cpu), 1);
In board-/platform-specific code:
static int platformX_do_idle(void)
{
/* tell platformX firmware to enter idle */
return 0;
}
static int platformX_cpu_boot(int i)
{
/* tell platformX firmware to boot CPU i */
return 0;
}
static const struct firmware_ops platformX_firmware_ops = {
.do_idle = exynos_do_idle,
.cpu_boot = exynos_cpu_boot,
/* other operations not available on platformX */
};
static void __init board_init_early(void)
{
????????register_firmware_ops(&platformX_firmware_ops);
}
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
---
arch/arm/common/Makefile | 2 ++
arch/arm/common/firmware.c | 18 ++++++++++++++++++
arch/arm/include/asm/firmware.h | 31 +++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)
create mode 100644 arch/arm/common/firmware.c
create mode 100644 arch/arm/include/asm/firmware.h
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..55d4182 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -2,6 +2,8 @@
# Makefile for the linux kernel.
#
+obj-y += firmware.o
+
obj-$(CONFIG_ARM_GIC) += gic.o
obj-$(CONFIG_ARM_VIC) += vic.o
obj-$(CONFIG_ICST) += icst.o
diff --git a/arch/arm/common/firmware.c b/arch/arm/common/firmware.c
new file mode 100644
index 0000000..27ddccb
--- /dev/null
+++ b/arch/arm/common/firmware.c
@@ -0,0 +1,18 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park <kyungmin.park@samsung.com>
+ * Tomasz Figa <t.figa@samsung.com>
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/suspend.h>
+
+#include <asm/firmware.h>
+
+static const struct firmware_ops default_firmware_ops;
+
+const struct firmware_ops *firmware_ops = &default_firmware_ops;
diff --git a/arch/arm/include/asm/firmware.h b/arch/arm/include/asm/firmware.h
new file mode 100644
index 0000000..5d87d8e
--- /dev/null
+++ b/arch/arm/include/asm/firmware.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics.
+ * Kyungmin Park <kyungmin.park@samsung.com>
+ * Tomasz Figa <t.figa@samsung.com>
+ *
+ * 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.
+ */
+
+#ifndef __ASM_ARM_FIRMWARE_H
+#define __ASM_ARM_FIRMWARE_H
+
+struct firmware_ops {
+ int (*do_idle)(void);
+ int (*cpu_boot)(int cpu);
+ int (*cpu_boot_reg)(int cpu, void __iomem **ptr);
+ int (*l2x0_init)(void);
+};
+
+extern const struct firmware_ops *firmware_ops;
+
+#define call_firmware_op(op, ...) \
+ ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
+
+static inline void register_firmware_ops(const struct firmware_ops *ops)
+{
+ firmware_ops = ops;
+}
+
+#endif
--
1.7.12
^ permalink raw reply related
* [PATCH v3 0/6] ARM: EXYNOS: Add secure firmware support
From: Tomasz Figa @ 2012-10-25 15:22 UTC (permalink / raw)
To: linux-arm-kernel
Some Exynos-based boards are running with secure firmware running in
TrustZone secure world, which changes the way some things have to be
initialized.
This series adds support for specifying firmware operations, implements
some firmware operations for Exynos secure firmware and adds a method of
enabling secure firmware operations on Exynos-based boards through board
file and device tree.
Changes since v2
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/12848 )
- Made Exynos firmware binding require address
- Minor style fixes
Changes since v1
( http://thread.gmane.org/gmane.linux.kernel.samsung-soc/12583/focus=12820 )
- Changed return types of all operations to int
- Defined all operations to return 0 on success, -ENOSYS when not
implemented or appropriate error code on error
Tomasz Figa (6):
ARM: Add interface for registering and calling firmware-specific
operations
ARM: EXYNOS: Add support for secure monitor calls
ARM: EXYNOS: Add IO mapping for non-secure SYSRAM.
ARM: EXYNOS: Add support for Exynos secure firmware
ARM: EXYNOS: Add support for secondary CPU bring-up on Exynos4412
ARM: EXYNOS: Add secure firmware support to secondary CPU bring-up
.../devicetree/bindings/arm/samsung-boards.txt | 10 ++++
arch/arm/common/Makefile | 2 +
arch/arm/common/firmware.c | 18 ++++++
arch/arm/include/asm/firmware.h | 31 ++++++++++
arch/arm/mach-exynos/Makefile | 6 ++
arch/arm/mach-exynos/common.c | 35 +++++++++++
arch/arm/mach-exynos/common.h | 2 +
arch/arm/mach-exynos/exynos-smc.S | 22 +++++++
arch/arm/mach-exynos/firmware.c | 67 ++++++++++++++++++++++
arch/arm/mach-exynos/include/mach/map.h | 3 +
arch/arm/mach-exynos/mach-exynos4-dt.c | 1 +
arch/arm/mach-exynos/platsmp.c | 37 ++++++++++--
arch/arm/mach-exynos/smc.h | 31 ++++++++++
arch/arm/plat-samsung/include/plat/map-s5p.h | 1 +
14 files changed, 260 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/common/firmware.c
create mode 100644 arch/arm/include/asm/firmware.h
create mode 100644 arch/arm/mach-exynos/exynos-smc.S
create mode 100644 arch/arm/mach-exynos/firmware.c
create mode 100644 arch/arm/mach-exynos/smc.h
--
1.7.12
^ permalink raw reply
* [GIT PULL] first set of ux500 for ARM SoC for v3.8
From: Arnd Bergmann @ 2012-10-25 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ9fUUugHAPGw8kEZDFnDWyyZ-b2iUdfCu2Hhhg4swaPQ@mail.gmail.com>
On Thursday 25 October 2012, Linus Walleij wrote:
> On Thu, Oct 25, 2012 at 3:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > Please remember to write the pull request in a way that lets us reuse some
> > of the text for the merge changeset comment. Ideally in a signed tag
> > so git puts it in there automatically.
>
> So what was wrong with this signed tag, looking like that?
>
> ----------------------------------------------------------------
> A first set of Ux500 core patches for v3.8:
> - Support the HREF520 board
> - Add the device serial number to the entropy pool
>
> ----------------------------------------------------------------
>
> I guess what I'm after is what makes it reusable if this one
> isn't.
The tag looks great, but you were sending the pull request for
the branch "ux500-core", not for the tag "ux500-core-for-arm-soc".
This has happened to me a few times before, especially when pushing
the tag just before sending the pull request. In that case,
git-request-pull cannot find the tag on the server because it has
not been mirrored back from the git+ssh server to the publically
accessible one that it reads the tags from.
Arnd
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Johannes Stezenbach @ 2012-10-25 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50894BC2.5050706@gmail.com>
On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
> On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
> > On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
> >> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
> >>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> >>>
> >>>> While v6 can support unaligned accesses, it is optional and current
> >>>> compilers won't emit unaligned accesses. So we don't clear the A bit for
> >>>> v6.
> >>>
> >>> not true according to the gcc changes page
> >>
> >> What are you going to believe: documentation or what the compiler
> >> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
> >> support backported and 4.7.2, unaligned accesses are emitted for v7
> >> only. I guess default here means it is the default unless you change the
> >> default in your build of gcc.
> >
> > Since ARMv6 can handle unaligned access in the same way as ARMv7
> > it seems a clear bug in gcc which might hopefully get fixed.
> > Thus in this case I think it is reasonable to follow the
> > gcc documentation, otherwise the code would break for ARMv6
> > when gcc gets fixed.
>
> But the compiler can't assume the state of the U bit. I think it is
> still legal on v6 to not support unaligned accesses, but on v7 it is
> required. All the standard v6 ARM cores support it, but I'm not sure
> about custom cores or if there are SOCs with buses that don't support
> unaligned accesses properly.
Well, I read the "...since Linux version 2.6.28" comment
in the gcc changes page in the way that they assume the
U-bit is set. (Although I'm not sure it really is???)
Looking at it from another side, if using the hw unaligned
access capability gives a performance benefit then it
would be useful to support it even if gcc doesn't
behave as documented. One could still use a special
unaligned.h for ARMv6 to get the performance benefit.
(If it doesn't give performance benfit, then why
bother, let's just use -mno-unaligned-access for v7, too.)
In the ARMv6 ARM unaligned support and the U-bit is
not optional, so you could use the same SoC bus argument
for some hypothetical v7 SoCs.
Johannes
^ permalink raw reply
* [GIT PULL] vexpress: fixes for v3.8
From: Arnd Bergmann @ 2012-10-25 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350580125.4984.23.camel@hornet>
On Thursday 18 October 2012, Pawel Moll wrote:
> Hi Arnd, Olof,
>
> Could you, please, pull this small Versatile Express fix for 3.8?
>
Applied to next/fixes-non-critical
Arnd
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Nicolas Pitre @ 2012-10-25 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50894BC2.5050706@gmail.com>
On Thu, 25 Oct 2012, Rob Herring wrote:
> On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
> > On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
> >> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
> >>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> >>>
> >>>> While v6 can support unaligned accesses, it is optional and current
> >>>> compilers won't emit unaligned accesses. So we don't clear the A bit for
> >>>> v6.
> >>>
> >>> not true according to the gcc changes page
> >>
> >> What are you going to believe: documentation or what the compiler
> >> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
> >> support backported and 4.7.2, unaligned accesses are emitted for v7
> >> only. I guess default here means it is the default unless you change the
> >> default in your build of gcc.
> >
> > Since ARMv6 can handle unaligned access in the same way as ARMv7
> > it seems a clear bug in gcc which might hopefully get fixed.
> > Thus in this case I think it is reasonable to follow the
> > gcc documentation, otherwise the code would break for ARMv6
> > when gcc gets fixed.
>
> But the compiler can't assume the state of the U bit. I think it is
> still legal on v6 to not support unaligned accesses, but on v7 it is
> required. All the standard v6 ARM cores support it, but I'm not sure
> about custom cores or if there are SOCs with buses that don't support
> unaligned accesses properly.
The fact is that gcc assumes the A bit is cleared when generating code
for ARMv7, period. We need to conform our environment to gcc
expectations, or always compile the decompressor using a lower
architecture level than ARMv7. My preference is the former.
Nicolas
^ permalink raw reply
* [PATCH] ARM i.MX: fix error-valued pointer dereference in clk_register_gate2()
From: Wei Yongjun @ 2012-10-25 15:02 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
The error-valued pointer clk is used for the arg of kfree, it should be
kfree(gate) if clk_register() return ERR_PTR().
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
arch/arm/mach-imx/clk-gate2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-gate2.c b/arch/arm/mach-imx/clk-gate2.c
index 3c1b8ff..cc49c7a 100644
--- a/arch/arm/mach-imx/clk-gate2.c
+++ b/arch/arm/mach-imx/clk-gate2.c
@@ -112,7 +112,7 @@ struct clk *clk_register_gate2(struct device *dev, const char *name,
clk = clk_register(dev, &gate->hw);
if (IS_ERR(clk))
- kfree(clk);
+ kfree(gate);
return clk;
}
^ permalink raw reply related
* [PATCH] arm: kirkwood: add support for ZyXEL NSA310
From: Tero Jaasko @ 2012-10-25 15:01 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
following patch adds support for the ZyXEL NSA310 NAS box. It has been
tested and developed in a linux-stable/linux-3.6.y tree, up to 3.6.2.
As mentioned in commit, the code is derived from the openwrt.org's
repository. I have only done the device tree conversion.
I have tested and used it on my NAS without trouble for a while.
Testing of nand and adt7476 was limited to verifying that they are
probed as I have no use for them.
In order to use the kernel with stock uBoot, one needs to build with
"make zImage modules dtbs",
"cat arch/arm/boot/kirkwood-nsa310.dtb >> arch/arm/boot/zImage"
"make uImage"
sequence.
---
>From f31af66eadc0df17bb75c8e5607d56ce6e2ef899 Mon Sep 17 00:00:00 2001
From: Tero Jaasko <tero.jaasko@mail.suomi.net>
Date: Mon, 22 Oct 2012 22:43:37 +0300
Subject: [PATCH] arm: kirkwood: add support for ZyXEL NSA310
Bring in the support for ZyXEL NSA310 NAS box. Code is mostly imported
from the openwrt.org, (https://dev.openwrt.org/browser/trunk/target/
linux/kirkwood/patches-3.3/202-zyxel-nsa-310.patch?rev=31673).
Original code is converted to use flattened device tree descriptions
for the support for serial uart, sata, gpio keys and gpio leds.
Signed-off-by: Tero Jaasko <tero.jaasko@mail.suomi.net>
---
arch/arm/boot/dts/kirkwood-nsa310.dts | 96 ++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 9 ++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/Makefile.boot | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 +
arch/arm/mach-kirkwood/board-nsa310.c | 166 ++++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 6 ++
7 files changed, 283 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-nsa310.dts
create mode 100644 arch/arm/mach-kirkwood/board-nsa310.c
diff --git a/arch/arm/boot/dts/kirkwood-nsa310.dts b/arch/arm/boot/dts/kirkwood-nsa310.dts
new file mode 100644
index 0000000..554d81a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-nsa310.dts
@@ -0,0 +1,96 @@
+/dts-v1/;
+
+/include/ "kirkwood.dtsi"
+
+/ {
+ model = "ZyXEL NSA310";
+ compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ ocp at f1000000 {
+ serial at 12000 {
+ clock-frequency = <200000000>;
+ status = "ok";
+ };
+
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ button at 1 {
+ label = "Power Button";
+ linux,code = <116>;
+ gpios = <&gpio1 14 0>;
+ };
+ button at 2 {
+ label = "Copy Button";
+ linux,code = <133>;
+ gpios = <&gpio1 5 1>;
+ };
+ button at 3 {
+ label = "Reset Button";
+ linux,code = <0x198>;
+ gpios = <&gpio1 4 1>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ green-sys {
+ label = "nsa310:green:sys";
+ gpios = <&gpio0 28 0>;
+ };
+ red-sys {
+ label = "nsa310:red:sys";
+ gpios = <&gpio0 29 0>;
+ };
+ green-hdd {
+ label = "nsa310:green:hdd";
+ gpios = <&gpio1 9 0>;
+ };
+ red-hdd {
+ label = "nsa310:red:hdd";
+ gpios = <&gpio1 10 0>;
+ };
+ green-esata {
+ label = "nsa310:green:esata";
+ gpios = <&gpio0 12 0>;
+ };
+ red-esata {
+ label = "nsa310:red:esata";
+ gpios = <&gpio0 13 0>;
+ };
+ green-usb {
+ label = "nsa310:green:usb";
+ gpios = <&gpio0 15 0>;
+ };
+ red-usb {
+ label = "nsa310:red:usb";
+ gpios = <&gpio0 16 0>;
+ };
+ green-copy {
+ label = "nsa310:green:copy";
+ gpios = <&gpio1 7 0>;
+ };
+ red-copy {
+ label = "nsa310:red:copy";
+ gpios = <&gpio1 8 0>;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index ca5c15a..1172a2a 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -195,6 +195,15 @@ config MACH_T5325
Say 'Y' here if you want your kernel to support the
HP t5325 Thin Client.
+config MACH_NSA310_DT
+ bool "ZyXEL NSA-310 (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ select ARM_APPENDED_DTB
+ select ARM_ATAG_DTB_COMPAT
+ help
+ Say 'Y' here if you want your kernel to support the
+ ZyXEL NSA-310 board (Flattened Device Tree).
+
endmenu
endif
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 055c85a..b2663e2 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_MACH_IB62X0_DT) += board-ib62x0.o
obj-$(CONFIG_MACH_TS219_DT) += board-ts219.o tsx1x-common.o
obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
+obj-$(CONFIG_MACH_NSA310_DT) += board-nsa310.o
diff --git a/arch/arm/mach-kirkwood/Makefile.boot b/arch/arm/mach-kirkwood/Makefile.boot
index a13299d..67d8666 100644
--- a/arch/arm/mach-kirkwood/Makefile.boot
+++ b/arch/arm/mach-kirkwood/Makefile.boot
@@ -12,3 +12,4 @@ dtb-$(CONFIG_MACH_TS219_DT) += kirkwood-ts219-6282.dtb
dtb-$(CONFIG_MACH_GOFLEXNET_DT) += kirkwood-goflexnet.dtb
dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lschlv2.dtb
dtb-$(CONFIG_MACH_LSXL_DT) += kirkwood-lsxhl.dtb
+dtb-$(CONFIG_MACH_NSA310_DT) += kirkwood-nsa310.dtb
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index e4eb450..2a005a7 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -87,6 +87,9 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("buffalo,lsxl"))
lsxl_init();
+ if (of_machine_is_compatible("zyxel,nsa310"))
+ nsa310_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -100,6 +103,7 @@ static const char *kirkwood_dt_board_compat[] = {
"qnap,ts219",
"seagate,goflexnet",
"buffalo,lsxl",
+ "zyxel,nsa310",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
new file mode 100644
index 0000000..4d20841
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-nsa310.c
@@ -0,0 +1,166 @@
+/*
+ * arch/arm/mach-kirkwood/board-nsa310.c
+ *
+ * ZyXEL NSA-310 Setup
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/i2c.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/partitions.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <mach/kirkwood.h>
+#include "common.h"
+#include "mpp.h"
+
+#define NSA310_GPIO_LED_ESATA_GREEN 12
+#define NSA310_GPIO_LED_ESATA_RED 13
+#define NSA310_GPIO_LED_USB_GREEN 15
+#define NSA310_GPIO_LED_USB_RED 16
+#define NSA310_GPIO_USB_POWER_OFF 21
+#define NSA310_GPIO_LED_SYS_GREEN 28
+#define NSA310_GPIO_LED_SYS_RED 29
+#define NSA310_GPIO_KEY_RESTART 36
+#define NSA310_GPIO_KEY_COPY 37
+#define NSA310_GPIO_LED_COPY_GREEN 39
+#define NSA310_GPIO_LED_COPY_RED 40
+#define NSA310_GPIO_LED_HDD_GREEN 41
+#define NSA310_GPIO_LED_HDD_RED 42
+#define NSA310_GPIO_BUZZER 44
+#define NSA310_GPIO_KEY_POWER 46
+#define NSA310_GPIO_POWER_OFF 48
+
+
+static unsigned int nsa310_mpp_config[] __initdata = {
+ MPP12_GPIO, /* led esata green */
+ MPP13_GPIO, /* led esata red */
+ MPP15_GPIO, /* led usb green */
+ MPP16_GPIO, /* led usb red */
+ MPP21_GPIO, /* control usb power off */
+ MPP28_GPIO, /* led sys green */
+ MPP29_GPIO, /* led sys red */
+ MPP36_GPIO, /* key reset */
+ MPP37_GPIO, /* key copy */
+ MPP39_GPIO, /* led copy green */
+ MPP40_GPIO, /* led copy red */
+ MPP41_GPIO, /* led hdd green */
+ MPP42_GPIO, /* led hdd red */
+ MPP44_GPIO, /* ?? */
+ MPP46_GPIO, /* key power */
+ MPP48_GPIO, /* control power off */
+ 0
+};
+
+static struct mtd_partition nsa310_mtd_parts[] = {
+ {
+ .name = "uboot",
+ .offset = 0,
+ .size = 0x100000,
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = "uboot_env",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0x80000,
+ }, {
+ .name = "key_store",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0x80000,
+ }, {
+ .name = "info",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0x80000,
+ }, {
+ .name = "etc",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0xa00000,
+ }, {
+ .name = "kernel_1",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0xa00000,
+ }, {
+ .name = "rootfs1",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0x2fc0000,
+ }, {
+ .name = "kernel_2",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0xa00000,
+ }, {
+ .name = "rootfs2",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = 0x2fc0000,
+ },
+};
+
+static struct i2c_board_info __initdata nsa310_i2c_info[] = {
+ { I2C_BOARD_INFO("adt7476", 0x2e) },
+};
+
+static void nsa310_power_off(void)
+{
+ gpio_set_value(NSA310_GPIO_POWER_OFF, 1);
+}
+
+static int __init nsa310_gpio_request(unsigned int gpio, unsigned long flags,
+ const char *label)
+{
+ int err;
+
+ err = gpio_request_one(gpio, flags, label);
+ if (err)
+ pr_err("NSA-310: can't setup GPIO%u (%s), err=%d\n",
+ gpio, label, err);
+
+ return err;
+}
+
+static void __init nsa310_gpio_init(void)
+{
+ int err;
+
+ err = nsa310_gpio_request(NSA310_GPIO_POWER_OFF, GPIOF_OUT_INIT_LOW,
+ "Power Off");
+ if (!err)
+ pm_power_off = nsa310_power_off;
+
+ nsa310_gpio_request(NSA310_GPIO_USB_POWER_OFF, GPIOF_OUT_INIT_LOW,
+ "USB Power Off");
+}
+
+void __init nsa310_init(void)
+{
+ u32 dev, rev;
+
+ kirkwood_mpp_conf(nsa310_mpp_config);
+
+ nsa310_gpio_init();
+
+ kirkwood_nand_init(ARRAY_AND_SIZE(nsa310_mtd_parts), 35);
+
+ /* this can be removed once the mainline kirkwood.dtsi gets
+ * the ehci configuration by default */
+ kirkwood_ehci_init();
+
+ kirkwood_pcie_id(&dev, &rev);
+
+ i2c_register_board_info(0, ARRAY_AND_SIZE(nsa310_i2c_info));
+ kirkwood_i2c_init();
+}
+
+static int __init nsa310_pci_init(void)
+{
+ if (of_machine_is_compatible("zyxel,nsa310"))
+ kirkwood_pcie_init(KW_PCIE0);
+
+ return 0;
+}
+
+subsys_initcall(nsa310_pci_init);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 304dd1a..a9256d7 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -94,6 +94,12 @@ void lsxl_init(void);
static inline void lsxl_init(void) {};
#endif
+#ifdef CONFIG_MACH_NSA310_DT
+void nsa310_init(void);
+#else
+static inline void nsa310_init(void) {};
+#endif
+
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
--
1.7.12.3
^ permalink raw reply related
* [PATCH] Fix socfpga compilation with early_printk() enabled
From: Arnd Bergmann @ 2012-10-25 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017181648.GA12120@elf.ucw.cz>
On Wednesday 17 October 2012, Pavel Machek wrote:
> Hi!
>
> This fixes early_printk() compilation for
> socfpga. (senduart/busyuart/waituart were missing). It does that by
> making Picochip code generic.
>
> Signed-off-by: Pavel Machek <pavel@denx.de>
> Acked-by: Dinh Nguyen <dinguyen@altera.com>
> Acked-by: Jamie Iles <jamie@jamieiles.com
Applied to fixes branch of arm-soc, but please be more explicit about
what you want to happen with patches in the future. Ideally we would
get pull requests for patches on each platform from only one person,
so please coordinate with Dinh Nguyen who that should be.
Some minor things:
* If you include something in the email that should not be part of
the git changelog (e.g. "Hi!"), then please put it below the "---"
line under the Signed-off list.
* you are missing a '>' after Jamies email address
* When you submit a patch for inclusion, please always take both
Olof and me on Cc on the email, since we are doing this work together
and take turns, so you might not always know which one will take
the patch. We have an alias "arm at kernel.org" that you can also
use.
I fixed all of the above now and applied the patch.
Arnd
^ permalink raw reply
* [PATCH 6/9] uprobes: flush cache after xol write
From: Oleg Nesterov @ 2012-10-25 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH+eYFAv=UTZ1gQ5jXq8_ziNy1i3BL9y1bOUWMdTow=i3N0n+g@mail.gmail.com>
On 10/16, Rabin Vincent wrote:
>
> 2012/10/15 Oleg Nesterov <oleg@redhat.com>:
> > On 10/14, Rabin Vincent wrote:
> >> Flush the cache so that the instructions written to the XOL area are
> >> visible.
> >>
> >> Signed-off-by: Rabin Vincent <rabin@rab.in>
> >> ---
> >> kernel/events/uprobes.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> >> index ca000a9..8c52f93 100644
> >> --- a/kernel/events/uprobes.c
> >> +++ b/kernel/events/uprobes.c
> >> @@ -1246,6 +1246,7 @@ static unsigned long xol_get_insn_slot(struct uprobe *uprobe, unsigned long slot
> >> offset = current->utask->xol_vaddr & ~PAGE_MASK;
> >> vaddr = kmap_atomic(area->page);
> >> arch_uprobe_xol_copy(&uprobe->arch, vaddr + offset);
> >> + flush_dcache_page(area->page);
> >> kunmap_atomic(vaddr);
> >
> > I agree... but why under kmap_atomic?
>
> No real reason; I'll move it to after the unmap.
OK. I assume you will send v2.
But this patch looks like a bugfix, flush_dcache_page() is not a nop
on powerpc. So perhaps we should apply this fix right now?
OTOH, I do not understand this stuff, everything is nop on x86. And
when I look into Documentation/cachetlb.txt I am starting to think
that may be this needs flush_icache_user_range instead?
Rabin, Ananth could you clarify this?
Oleg.
^ permalink raw reply
* [PATCH 1/7] ARM: hw_breakpoint: only clear OS lock when implemented on v7
From: Will Deacon @ 2012-10-25 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50887169.4060209@codeaurora.org>
On Wed, Oct 24, 2012 at 11:53:29PM +0100, Stephen Boyd wrote:
> On 10/17/12 08:31, Will Deacon wrote:
> > The OS save and restore register are optional in debug architecture v7,
> > so check the status register before attempting to clear the OS lock.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Tested-by: Stephen Boyd <sboyd@codeaurora.org>
>
> > ---
> > arch/arm/kernel/hw_breakpoint.c | 10 +++++++++-
> > 1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> > index 281bf33..ec16ada 100644
> > --- a/arch/arm/kernel/hw_breakpoint.c
> > +++ b/arch/arm/kernel/hw_breakpoint.c
> > @@ -929,6 +929,13 @@ static void reset_ctrl_regs(void *unused)
> > asm volatile("mrc p14, 0, %0, c1, c5, 4" : "=r" (dbg_power));
> > if ((dbg_power & 0x1) == 0)
> > err = -EPERM;
> > +
> > + /*
> > + * Check whether we implement OS save and restore.
> > + */
> > + asm volatile("mrc p14, 0, %0, c1, c1, 4" : "=r" (dbg_power));
>
> minor nit for this series. dbg_power has become a catch-all variable in
> this code. It would be nice if we named the variables used to hold the
> read register the same as the register or if we made the name of the
> variable generic like 'val'.
Thanks for your feedback and tested-bys on this series Stephen, I really
appreciate it.
I'll send out a v2 and update the branch I'm sending to -next.
Cheers,
Will
^ permalink raw reply
* [PATCHv4 2/2] i2c: omap: make reset a seperate function
From: Shubhrajyoti D @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351176199-6479-1-git-send-email-shubhrajyoti@ti.com>
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
some of the errors may not need a reset.
will check and post separate patch.
drivers/i2c/busses/i2c-omap.c | 25 ++++++++++++++++---------
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 38acf1a..a25b7b0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -309,15 +309,9 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 12000000;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -363,6 +357,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev->westate = OMAP_I2C_WE_ALL;
}
}
+ return 0;
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 12000000;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -595,7 +600,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (timeout == 0) {
dev_err(dev->dev, "controller timed out\n");
ret = -ETIMEDOUT;
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
goto out;
}
@@ -606,7 +612,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev->cmd_err & (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
ret = -EIO;
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
goto out;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCHv4 1/2] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti D @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351176199-6479-1-git-send-email-shubhrajyoti@ti.com>
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74 +++++++++++++++++++---------------------
1 files changed, 35 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index be329e9..38acf1a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,34 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
}
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
+ if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev->iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 12000000;
unsigned long timeout;
@@ -337,11 +361,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev->westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev->westate);
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +447,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
- if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev->pscstate = psc;
- dev->scllstate = scll;
- dev->sclhstate = sclh;
- dev->bufstate = buf;
- }
+
+ dev->pscstate = psc;
+ dev->scllstate = scll;
+ dev->sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1267,23 +1278,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (_dev->iestate)
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
+ if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
+ __omap_i2c_init(_dev);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCHv4 0/2] i2c: omap: cleanups
From: Shubhrajyoti D @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-arm-kernel
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Todo: all the error cases may not need a reset.
Shubhrajyoti D (2):
i2c: omap: re-factor omap_i2c_init function
i2c: omap: make reset a seperate function
drivers/i2c/busses/i2c-omap.c | 97 +++++++++++++++++++++--------------------
1 files changed, 50 insertions(+), 47 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [GIT PULL] ux500 fixes due for v3.7 RCs
From: Linus Walleij @ 2012-10-25 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210251352.31364.arnd@arndb.de>
On Thu, Oct 25, 2012 at 3:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Since we're now getting pull requests from both of you, Lee and Linus,
> I'd like to understand how you are organized.
>
> Lee, are you just sending bug fixes directly and send future work through
> Linus, or are you acting as backup maintainer when he is busy otherwise
> in general?
Let us say that Lee is pushing stuff that is DT-related, e.g. fixes that
only manifest in DT environments and I'm pushing most other stuff.
I'm happy that Lee is doing some nice offloading as pinctrl and gpio is
currently quite busy.
One day Srinidhi may also send pull requests, as co-maintainer.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 3/5] ARM: EXYNOS: Enable PMUs for exynos4
From: Will Deacon @ 2012-10-25 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005801cdb251$e52f7480$af8e5d80$@samsung.com>
On Thu, Oct 25, 2012 at 02:41:46AM +0100, Chanho Park wrote:
> > On Tue, Oct 23, 2012 at 10:34 PM, Chanho Park
> > <chanho61.park@samsung.com> wrote:
> > > This patch defines irq numbers of ARM performance monitoring unit for
> > exynos4.
> > > Firs of all, we need to fix IRQ_PMU correctly and to split pmu
> > > initialization of exynos from plat-samsung for easily defining it.
> > >
> > > The number of CPU cores and PMU irq numbers are vary according to soc
> > types.
> > > So, we need to identify each soc type using soc_is_xxx function and to
> > > define the pmu irqs dynamically. For example, the exynos4412 has 4 cpu
> > cores and pmus.
> >
> > I wonder if it's worth doing this complexity on the non-DT case for exynos4?
> >
> > I wish there was more focus on the Samsung platforms for getting the DT
> > support up to par with non-DT so you can avoid having to add new platform
> > devices like these in the first place.
>
> The DT support of exynos4 is under development.
It seems to have been under development for a while now and changes like
this don't exactly encourage people to chip-in with that effort. Would it
not be better to spend time helping to complete the DT support instead of
retro-fitting static platform devices into the code?
> And many of exynos4 developers still use non-dt boot-up method.
That's not surprising if the DT code is still under development -- it's a
chicken-and-egg problem.
> By this time arm-pmu of exynos did not work. IMO we should fix and support it
> for non-dt users.
I agree that we definitely want to support the PMU on Exynos4, but I'm
tempted to postpone adding that code until DT support is available.
Will
^ permalink raw reply
* [PATCHv4 2/2] i2c: omap: make reset a seperate function
From: Shubhrajyoti D @ 2012-10-25 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351175989-6401-1-git-send-email-shubhrajyoti@ti.com>
Implement reset as a separate function.
This will enable us to make sure that we don't do the
calculation again on every transfer.
Also at probe the reset is not added as the hwmod is doing that
for us.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
some of the errors may not need a reset.
will check and post separate patch.
drivers/i2c/busses/i2c-omap.c | 25 ++++++++++++++++---------
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 38acf1a..a25b7b0 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -309,15 +309,9 @@ static void __omap_i2c_init(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
}
-static int omap_i2c_init(struct omap_i2c_dev *dev)
+static int omap_i2c_reset(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0;
- u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
- unsigned long fclk_rate = 12000000;
unsigned long timeout;
- unsigned long internal_clk = 0;
- struct clk *fclk;
-
if (dev->rev >= OMAP_I2C_OMAP1_REV_2) {
/* Disable I2C controller before soft reset */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
@@ -363,6 +357,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev->westate = OMAP_I2C_WE_ALL;
}
}
+ return 0;
+}
+
+static int omap_i2c_init(struct omap_i2c_dev *dev)
+{
+ u16 psc = 0, scll = 0, sclh = 0;
+ u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
+ unsigned long fclk_rate = 12000000;
+ unsigned long internal_clk = 0;
+ struct clk *fclk;
+
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -595,7 +600,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (timeout == 0) {
dev_err(dev->dev, "controller timed out\n");
ret = -ETIMEDOUT;
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
goto out;
}
@@ -606,7 +612,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
if (dev->cmd_err & (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
ret = -EIO;
- omap_i2c_init(dev);
+ omap_i2c_reset(dev);
+ __omap_i2c_init(dev);
goto out;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCHv4 1/2] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti D @ 2012-10-25 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351175989-6401-1-git-send-email-shubhrajyoti@ti.com>
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
v4: add spaces for readability
drivers/i2c/busses/i2c-omap.c | 74 +++++++++++++++++++---------------------
1 files changed, 35 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index be329e9..38acf1a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,34 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev *i2c_dev, int reg)
}
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
+ if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev->iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 12000000;
unsigned long timeout;
@@ -337,11 +361,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev->westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev->westate);
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +447,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
- if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev->pscstate = psc;
- dev->scllstate = scll;
- dev->sclhstate = sclh;
- dev->bufstate = buf;
- }
+
+ dev->pscstate = psc;
+ dev->scllstate = scll;
+ dev->sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1267,23 +1278,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (_dev->iestate)
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
+ if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE)
+ __omap_i2c_init(_dev);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCHv4 0/2] i2c: omap: cleanups
From: Shubhrajyoti D @ 2012-10-25 14:39 UTC (permalink / raw)
To: linux-arm-kernel
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3630 beagle both idle and suspend.
Functional testing on omap4sdp.
Todo: all the error cases may not need a reset.
Shubhrajyoti D (2):
i2c: omap: re-factor omap_i2c_init function
i2c: omap: make reset a seperate function
drivers/i2c/busses/i2c-omap.c | 97 +++++++++++++++++++++--------------------
1 files changed, 50 insertions(+), 47 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [GIT PULL] first set of ux500 for ARM SoC for v3.8
From: Linus Walleij @ 2012-10-25 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210251344.44546.arnd@arndb.de>
On Thu, Oct 25, 2012 at 3:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> Please remember to write the pull request in a way that lets us reuse some
> of the text for the merge changeset comment. Ideally in a signed tag
> so git puts it in there automatically.
So what was wrong with this signed tag, looking like that?
----------------------------------------------------------------
A first set of Ux500 core patches for v3.8:
- Support the HREF520 board
- Add the device serial number to the entropy pool
----------------------------------------------------------------
I guess what I'm after is what makes it reusable if this one
isn't.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Alan Stern @ 2012-10-25 14:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025102301.GA3469@breakpoint.cc>
On Thu, 25 Oct 2012, Sebastian Andrzej Siewior wrote:
> On Wed, Oct 24, 2012 at 08:55:27AM -1000, Mitch Bradley wrote:
> > >> So by listing "usb-ehci" in its device ID table, a driver would
> > >> essentially be saying that it can handle _all_ USB EHCI controllers.
> >
> >
> > Actually, it means that the driver can handle at least USB EHCI
> > controllers that are 100% compatible with the EHCI spec (requiring
> > nothing extra). The driver might be able to handle almost-compatible
> > controllers, possibly with the help of additional properties.
> >
> > If a DT node lists "usb-ehci" as a "fallback", it's not guaranteed that
> > a given version of that driver will work, but it's worth a try in the
> > event that no more-specific driver is matched.
>
> Not sure fallback is a good term here. The of parses the compatible from left
> to right. If the device specific entry is not found (in the driver) then end
> up with usb-ehci. If we need a quirk later on we add the device specific entry
> to the driver (which will match before usb-ehci is found) and we could use
> this entry to apply the quirk. That way you can apply quirks without touch the
> firmware / device tree.
What happens if the drivers get probed in the wrong order? That is, if
ehci-platform gets probed before ehci-spear (or whatever)?
Alan Stern
^ permalink raw reply
* [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update
From: Rob Herring @ 2012-10-25 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508948A5.3020005@free-electrons.com>
On 10/25/2012 09:11 AM, Gregory CLEMENT wrote:
> On 10/25/2012 03:53 PM, Rob Herring wrote:
>> On 10/25/2012 08:18 AM, Jason Cooper wrote:
>>> On Wed, Oct 24, 2012 at 04:05:45PM +0200, Gregory CLEMENT wrote:
>>>> On 10/24/2012 04:01 PM, Thomas Petazzoni wrote:
>>>>> Hello,
>>>>>
>>>>> Shouldn't you split into one commit adding the SATA definition in
>>>>> the .dtsi + doing the defconfig change (the "SoC" level modifications),
>>>>> and then another commit for the .dts change? I don't really care
>>>>> personally, it's really up to Jason/Andrew on this.
>>>>>
>>>>> Another comment below, though.
>>>>>
>>>>> On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:
>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
>>>>>> index 94b4b9e..3f08233 100644
>>>>>> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
>>>>>> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
>>>>>> @@ -69,6 +69,16 @@
>>>>>> compatible = "marvell,armada-addr-decoding-controller";
>>>>>> reg = <0xd0020000 0x258>;
>>>>>> };
>>>>>> +
>>>>>> + sata at d00a0000 {
>>>>>> + compatible = "marvell,orion-sata";
>>>>>> + reg = <0xd00a0000 0x2400>;
>>>>>> + interrupts = <55>;
>>>>>> + nr-ports = <2>;
>>>>>> + clocks = <&coreclk 0>;//, <&coreclk 0>;
>>>>>
>>>>> Alignment problem + remainings of tests or something like that.
>>>>
>>>> True I missed this one.
>>>>
>>>> Jason, Andrew, do you want I split this patch as suggested by Thomas or
>>>> are you fine with having one single patch?
>>>
>>> Yes, please make the defconfig changes a separate patch. Also, please
>>> make sure only the minimum is enabled (eq RAID... isn't needed).
>>
>> What about updating multi_v7_defconfig instead?
>
> About the _instead_, when I proposed to removed mvebu_defconfig Thomas
> argued that it was more convenient to build a mvebu-only kernel when
> doing kernel development, and Andrew also pointed that this defconfig
> should be useful for kisskb.
Okay, missed that discussion.
> And about updated both mvebu_defconfig and multi_v7_defconfig, I'm
> fine with it.
Yes, then please update both.
Rob
^ permalink raw reply
* [GIT PULL] omap fixes for v3.7-rc2
From: Arnd Bergmann @ 2012-10-25 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024184959.GI5605@atomide.com>
On Wednesday 24 October 2012, Tony Lindgren wrote:
>
> The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
>
> Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc2/fixes-signed
>
> for you to fetch changes up to 12ac7f9e117facfe128d6e569953fa73d2d676b3:
>
> ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500 (2012-10-23 18:58:21 -0700)
>
> ----------------------------------------------------------------
> Timer fix for am33xx, runtime PM fix for UART, audio McBSP fixes,
> mux and pinctrl fixes, and Beagle OPP fix.
>
Applied to fixes branch, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Rob Herring @ 2012-10-25 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025141645.GA16962@sig21.net>
On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
> On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
>> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
>>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
>>>
>>>> While v6 can support unaligned accesses, it is optional and current
>>>> compilers won't emit unaligned accesses. So we don't clear the A bit for
>>>> v6.
>>>
>>> not true according to the gcc changes page
>>
>> What are you going to believe: documentation or what the compiler
>> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access
>> support backported and 4.7.2, unaligned accesses are emitted for v7
>> only. I guess default here means it is the default unless you change the
>> default in your build of gcc.
>
> Since ARMv6 can handle unaligned access in the same way as ARMv7
> it seems a clear bug in gcc which might hopefully get fixed.
> Thus in this case I think it is reasonable to follow the
> gcc documentation, otherwise the code would break for ARMv6
> when gcc gets fixed.
But the compiler can't assume the state of the U bit. I think it is
still legal on v6 to not support unaligned accesses, but on v7 it is
required. All the standard v6 ARM cores support it, but I'm not sure
about custom cores or if there are SOCs with buses that don't support
unaligned accesses properly.
Rob
^ permalink raw reply
* [PATCH] MAINTAINERS: Add arm-soc tree entry
From: Arnd Bergmann @ 2012-10-25 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351101629-11826-1-git-send-email-sboyd@codeaurora.org>
On Wednesday 24 October 2012, Stephen Boyd wrote:
> Document the arm-soc tree in the maintainers file so that
> developers know how arm SoC development is structured.
>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Applied to fixes branch, I think it's reasonable to not have
to wait for 3.8.
Thanks!
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox