* [PATCH 3/4] ARM: kirkwood: DT board setup for Network Space Lite v2
From: Simon Guinot @ 2012-10-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for the LaCie NAS Network Space Lite v2.
This board is derived from the Network Space v2 and a lot of hardware
characteristics are shared.
- CPU: Marvell 88F6192 800Mhz
- SDRAM memory: 128MB DDR2 200Mhz
- 1 SATA port: internal
- Gigabit ethernet: PHY Marvell 88E1318
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports: host and host/device
- 1 push button
- 1 SATA LED (bi-color, blue and red)
Note that the SATA LED is not compatible with the driver leds-ns2. The
LED behaviour ("on", "off" or "SATA activity blink") is controlled via
a single MPP (21).
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ns2lite.dts | 30 ++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 +++++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 +++-
arch/arm/mach-kirkwood/board-ns2.c | 3 +++
arch/arm/mach-kirkwood/common.h | 3 ++-
7 files changed, 47 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-ns2lite.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6201b6..42b3e90 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-lschlv2.dtb \
kirkwood-lsxhl.dtb \
kirkwood-ns2.dtb \
+ kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
new file mode 100644
index 0000000..b02eb4e
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Lite v2";
+ compatible = "lacie,netspace_lite_v2", "marvell,kirkwood-88f6192", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ gpios = <&gpio0 30 1>;
+ linux,default-trigger = "default-on";
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 847e0c2..83df331 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -151,6 +151,13 @@ config MACH_NETSPACE_MAX_V2_DT
Say 'Y' here if you want your kernel to support the LaCie
Network Space Max v2 NAS, using Flattened Device Tree.
+config MACH_NETSPACE_LITE_V2_DT
+ bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Lite v2 NAS, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 1f63d80..4d4b7d4 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index b3e0519..ab7595e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -98,7 +98,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("lacie,inetspace_v2") ||
of_machine_is_compatible("lacie,netspace_v2") ||
- of_machine_is_compatible("lacie,netspace_max_v2"))
+ of_machine_is_compatible("lacie,netspace_max_v2") ||
+ of_machine_is_compatible("lacie,netspace_lite_v2"))
ns2_init();
of_platform_populate(NULL, kirkwood_dt_match_table,
@@ -120,6 +121,7 @@ static const char *kirkwood_dt_board_compat[] = {
"lacie,inetspace_v2",
"lacie,netspace_max_v2",
"lacie,netspace_v2",
+ "lacie,netspace_lite_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
index b36c55c..da8c4c5 100644
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
+#include <linux/of.h>
#include "common.h"
#include "mpp.h"
@@ -73,6 +74,8 @@ void __init ns2_init(void)
kirkwood_mpp_conf(ns2_mpp_config);
kirkwood_ehci_init();
+ if (of_machine_is_compatible("lacie,netspace_lite_v2"))
+ ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&ns2_ge00_data);
if (gpio_request(NS2_GPIO_POWER_OFF, "power-off") == 0 &&
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 2f75f3f..6949d81 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -114,7 +114,8 @@ static inline void km_kirkwood_init(void) {};
#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_MAX_V2_DT)
+ defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_LITE_V2_DT)
void ns2_init(void);
#else
static inline void ns2_init(void) {};
--
1.7.10
^ permalink raw reply related
* [PATCH 2/4] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Simon Guinot @ 2012-10-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for LaCie Network Space v2 and parents,
based on the Marvell Kirkwood 6281 SoC. This includes Network Space v2
(Max) and Internet Space v2.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/kirkwood-is2.dts | 30 ++++++++++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 +++++++++++++++++++++
arch/arm/boot/dts/kirkwood-ns2.dts | 30 ++++++++++
arch/arm/boot/dts/kirkwood-ns2max.dts | 49 ++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 21 +++++++
arch/arm/mach-kirkwood/Makefile | 3 +
arch/arm/mach-kirkwood/board-dt.c | 8 +++
arch/arm/mach-kirkwood/board-ns2.c | 83 ++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 8 +++
drivers/leds/Kconfig | 4 +-
11 files changed, 301 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
create mode 100644 arch/arm/mach-kirkwood/board-ns2.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c1ce813..e6201b6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -34,9 +34,12 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-ib62x0.dtb \
kirkwood-iconnect.dtb \
kirkwood-iomega_ix2_200.dtb \
+ kirkwood-is2.dtb \
kirkwood-km_kirkwood.dtb \
kirkwood-lschlv2.dtb \
kirkwood-lsxhl.dtb \
+ kirkwood-ns2.dtb \
+ kirkwood-ns2max.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
new file mode 100644
index 0000000..7bc4677
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Internet Space v2";
+ compatible = "lacie,inetspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ ns2-leds {
+ compatible = "ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
new file mode 100644
index 0000000..9bc6785
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -0,0 +1,63 @@
+/include/ "kirkwood.dtsi"
+
+/ {
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ ocp at f1000000 {
+ serial at 12000 {
+ clock-frequency = <166666667>;
+ status = "okay";
+ };
+
+ spi at 10600 {
+ status = "okay";
+
+ flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mx25l4005a";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ mode = <0>;
+
+ partition at 0 {
+ reg = <0x0 0x80000>;
+ label = "u-boot";
+ };
+ };
+ };
+
+ i2c at 11000 {
+ status = "okay";
+
+ eeprom at 50 {
+ compatible = "at,24c04";
+ pagesize = <16>;
+ reg = <0x50>;
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ button at 1 {
+ label = "Power push button";
+ linux,code = <116>;
+ gpios = <&gpio1 0 0>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ red-fail {
+ label = "ns2:red:fail";
+ gpios = <&gpio0 12 0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
new file mode 100644
index 0000000..d018213
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space v2";
+ compatible = "lacie,netspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ ns2-leds {
+ compatible = "ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
new file mode 100644
index 0000000..82156e2
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -0,0 +1,49 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Max v2";
+ compatible = "lacie,netspace_max_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+ };
+
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio0 22 1
+ &gpio0 7 1
+ &gpio1 1 1
+ &gpio0 23 1>;
+ gpio-fan,speed-map =
+ < 0 0
+ 1500 15
+ 1700 14
+ 1800 13
+ 2100 12
+ 3100 11
+ 3300 10
+ 4300 9
+ 5500 8>;
+ alarm-gpios = <&gpio0 25 1>;
+ };
+
+ ns2-leds {
+ compatible = "ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 50bca50..847e0c2 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -130,6 +130,27 @@ config MACH_KM_KIRKWOOD_DT
Say 'Y' here if you want your kernel to support the
Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
+config MACH_INETSPACE_V2_DT
+ bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Internet Space v2 NAS, using Flattened Device Tree.
+
+config MACH_NETSPACE_V2_DT
+ bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space v2 NAS, using Flattened Device Tree.
+
+config MACH_NETSPACE_MAX_V2_DT
+ bool "LaCie Network Space Max v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Max v2 NAS, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 294779f..1f63d80 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -31,3 +31,6 @@ obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += board-iomega_ix2_200.o
obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
+obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 70c5a28..b3e0519 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("keymile,km_kirkwood"))
km_kirkwood_init();
+ if (of_machine_is_compatible("lacie,inetspace_v2") ||
+ of_machine_is_compatible("lacie,netspace_v2") ||
+ of_machine_is_compatible("lacie,netspace_max_v2"))
+ ns2_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -112,6 +117,9 @@ static const char *kirkwood_dt_board_compat[] = {
"buffalo,lsxl",
"iom,ix2-200",
"keymile,km_kirkwood",
+ "lacie,inetspace_v2",
+ "lacie,netspace_max_v2",
+ "lacie,netspace_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
new file mode 100644
index 0000000..b36c55c
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright 2012 (C), Simon Guinot <simon.guinot@sequanux.org>
+ *
+ * arch/arm/mach-kirkwood/board-ns2.c
+ *
+ * LaCie Network Space v2 board (and parents) initialization for drivers
+ * not converted to flattened device tree yet.
+ *
+ * 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/platform_device.h>
+#include <linux/mv643xx_eth.h>
+#include <linux/gpio.h>
+#include "common.h"
+#include "mpp.h"
+
+static struct mv643xx_eth_platform_data ns2_ge00_data = {
+ .phy_addr = MV643XX_ETH_PHY_ADDR(8),
+};
+
+static unsigned int ns2_mpp_config[] __initdata = {
+ MPP0_SPI_SCn,
+ MPP1_SPI_MOSI,
+ MPP2_SPI_SCK,
+ MPP3_SPI_MISO,
+ MPP4_NF_IO6,
+ MPP5_NF_IO7,
+ MPP6_SYSRST_OUTn,
+ MPP7_GPO, /* Fan speed (bit 1) */
+ MPP8_TW0_SDA,
+ MPP9_TW0_SCK,
+ MPP10_UART0_TXD,
+ MPP11_UART0_RXD,
+ MPP12_GPO, /* Red led */
+ MPP14_GPIO, /* USB fuse */
+ MPP16_GPIO, /* SATA 0 power */
+ MPP17_GPIO, /* SATA 1 power */
+ MPP18_NF_IO0,
+ MPP19_NF_IO1,
+ MPP20_SATA1_ACTn,
+ MPP21_SATA0_ACTn,
+ MPP22_GPIO, /* Fan speed (bit 0) */
+ MPP23_GPIO, /* Fan power */
+ MPP24_GPIO, /* USB mode select */
+ MPP25_GPIO, /* Fan rotation fail */
+ MPP26_GPIO, /* USB device vbus */
+ MPP28_GPIO, /* USB enable host vbus */
+ MPP29_GPIO, /* Blue led (slow register) */
+ MPP30_GPIO, /* Blue led (command register) */
+ MPP31_GPIO, /* Board power off */
+ MPP32_GPIO, /* Power button (0 = Released, 1 = Pushed) */
+ MPP33_GPO, /* Fan speed (bit 2) */
+ 0
+};
+
+#define NS2_GPIO_POWER_OFF 31
+
+static void ns2_power_off(void)
+{
+ gpio_set_value(NS2_GPIO_POWER_OFF, 1);
+}
+
+void __init ns2_init(void)
+{
+ /*
+ * Basic setup. Needs to be called early.
+ */
+ kirkwood_mpp_conf(ns2_mpp_config);
+
+ kirkwood_ehci_init();
+ kirkwood_ge00_init(&ns2_ge00_data);
+
+ if (gpio_request(NS2_GPIO_POWER_OFF, "power-off") == 0 &&
+ gpio_direction_output(NS2_GPIO_POWER_OFF, 0) == 0)
+ pm_power_off = ns2_power_off;
+ else
+ pr_err("ns2: failed to configure power-off GPIO\n");
+}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index bcffd7c..2f75f3f 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -112,6 +112,14 @@ void km_kirkwood_init(void);
static inline void km_kirkwood_init(void) {};
#endif
+#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_MAX_V2_DT)
+void ns2_init(void);
+#else
+static inline void ns2_init(void) {};
+#endif
+
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index f508def..e455c08 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -379,7 +379,9 @@ config LEDS_NS2
tristate "LED support for Network Space v2 GPIO LEDs"
depends on LEDS_CLASS
depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \
- MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2
+ MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \
+ MACH_NETSPACE_V2_DT || MACH_INETSPACE_V2_DT || \
+ MACH_NETSPACE_MAX_V2_DT
default y
help
This option enable support for the dual-GPIO LED found on the
--
1.7.10
^ permalink raw reply related
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Simon Guinot @ 2012-10-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350315295-14567-1-git-send-email-simon.guinot@sequanux.org>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
.../devicetree/bindings/gpio/leds-ns2.txt | 26 ++++++
drivers/leds/leds-ns2.c | 84 +++++++++++++++++++-
2 files changed, 107 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
new file mode 100644
index 0000000..1a84969
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
@@ -0,0 +1,26 @@
+Binding for dual-GPIO LED found on Network Space v2 (and parents).
+
+Required properties:
+- compatible: "ns2-leds".
+
+Each LED is represented as a sub-node of the ns2-leds device.
+
+Required sub-node properties:
+- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
+- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
+
+Optional sub-node properties:
+- label: Name for this LED. If omitted, the label is taken from the node name.
+- linux,default-trigger: Trigger assigned to the LED.
+
+Example:
+
+ns2-leds {
+ compatible = "ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+};
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index d176ec8..55d199b 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -30,6 +30,7 @@
#include <linux/leds.h>
#include <linux/module.h>
#include <linux/platform_data/leds-kirkwood-ns2.h>
+#include <linux/of_gpio.h>
/*
* The Network Space v2 dual-GPIO LED is wired to a CPLD and can blink in
@@ -263,6 +264,68 @@ static void delete_ns2_led(struct ns2_led_data *led_dat)
gpio_free(led_dat->slow);
}
+#ifdef CONFIG_OF_GPIO
+/*
+ * Translate OpenFirmware node properties into platform_data.
+ */
+static int __devinit
+ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *child;
+ struct ns2_led *leds;
+ int num_leds = 0;
+ int i = 0;
+
+ num_leds = of_get_child_count(np);
+ if (!num_leds)
+ return -ENODEV;
+
+ leds = devm_kzalloc(dev, num_leds * sizeof(struct ns2_led),
+ GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ for_each_child_of_node(np, child) {
+ const char *string;
+ int ret;
+
+ ret = of_get_named_gpio(child, "cmd-gpio", 0);
+ if (ret < 0)
+ return ret;
+ leds[i].cmd = ret;
+ ret = of_get_named_gpio(child, "slow-gpio", 0);
+ if (ret < 0)
+ return ret;
+ leds[i].slow = ret;
+ ret = of_property_read_string(child, "label", &string);
+ leds[i].name = (ret == 0) ? string : child->name;
+ ret = of_property_read_string(child, "linux,default-trigger",
+ &string);
+ if (ret == 0)
+ leds[i].default_trigger = string;
+
+ i++;
+ }
+
+ pdata->leds = leds;
+ pdata->num_leds = num_leds;
+
+ return 0;
+}
+
+static const struct of_device_id of_ns2_leds_match[] = {
+ { .compatible = "ns2-leds", },
+ {},
+};
+#else
+static int __devinit
+ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_OF_GPIO */
+
static int __devinit ns2_led_probe(struct platform_device *pdev)
{
struct ns2_led_platform_data *pdata = pdev->dev.platform_data;
@@ -270,11 +333,25 @@ static int __devinit ns2_led_probe(struct platform_device *pdev)
int i;
int ret;
+#ifdef CONFIG_OF_GPIO
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct ns2_led_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ ret = ns2_leds_get_of_pdata(&pdev->dev, pdata);
+ if (ret)
+ return ret;
+ }
+#else
if (!pdata)
return -EINVAL;
+#endif /* CONFIG_OF_GPIO */
leds_data = devm_kzalloc(&pdev->dev, sizeof(struct ns2_led_data) *
- pdata->num_leds, GFP_KERNEL);
+ pdata->num_leds, GFP_KERNEL);
if (!leds_data)
return -ENOMEM;
@@ -312,8 +389,9 @@ static struct platform_driver ns2_led_driver = {
.probe = ns2_led_probe,
.remove = __devexit_p(ns2_led_remove),
.driver = {
- .name = "leds-ns2",
- .owner = THIS_MODULE,
+ .name = "leds-ns2",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_ns2_leds_match),
},
};
--
1.7.10
^ permalink raw reply related
* [PATCH 0/4] Add DT support for Network Space v2 and parents
From: Simon Guinot @ 2012-10-15 15:34 UTC (permalink / raw)
To: linux-arm-kernel
This patch series provides DT support for LaCie NAS Network Space v2 and
parents. This includes the following machines:
- Internet Space v2
- Network Space v2
- Network Space Max v2
- Network Space Lite v2
- Network Space Mini v2
Note that the three first boards are already supported by the Linux
kernel via an "old-fashion" board setup. The two lasts (Lite and Mini)
are new boards.
Also note that the first patch of the series is related with the LED
subsystem. It adds device tree binding to the driver leds-ns2.
Simon Guinot (4):
leds: leds-ns2: add device tree binding
ARM: kirkwood: DT board setup for Network Space v2 and parents
ARM: kirkwood: DT board setup for Network Space Lite v2
ARM: kirkwood: DT board setup for Network Space Mini v2
.../devicetree/bindings/gpio/leds-ns2.txt | 26 ++++++
arch/arm/boot/dts/Makefile | 5 ++
arch/arm/boot/dts/kirkwood-is2.dts | 30 +++++++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 ++++++++++++++
arch/arm/boot/dts/kirkwood-ns2.dts | 30 +++++++
arch/arm/boot/dts/kirkwood-ns2lite.dts | 30 +++++++
arch/arm/boot/dts/kirkwood-ns2max.dts | 49 +++++++++++
arch/arm/boot/dts/kirkwood-ns2mini.dts | 49 +++++++++++
arch/arm/mach-kirkwood/Kconfig | 36 ++++++++
arch/arm/mach-kirkwood/Makefile | 5 ++
arch/arm/mach-kirkwood/board-dt.c | 12 +++
arch/arm/mach-kirkwood/board-ns2.c | 87 ++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 10 +++
drivers/leds/Kconfig | 4 +-
drivers/leds/leds-ns2.c | 84 ++++++++++++++++++-
15 files changed, 516 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2lite.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2mini.dts
create mode 100644 arch/arm/mach-kirkwood/board-ns2.c
--
1.7.10
^ permalink raw reply
* [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness
From: Fei Yang @ 2012-10-15 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20603.47887.262025.941051@pilspetsen.it.uu.se>
2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> Yangfei (Felix) writes:
> > Hi all,
> >
> > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> > / *
> > * here's the WFI
> > */
> > asm(".word 0xe320f003\n"
> > :
> > :
> > : "memory", "cc");
> >
> > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> >
> > Here the code should be:
> > / *
> > * here's the WFI
> > */
> > asm("WFI\n"
> > :
> > :
> > : "memory", "cc");
> >
> > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> > Can anyone tell me who owns this part? I can prepare a patch then.
> > Thanks.
>
> Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> (see the MAINTAINERS file), with an optional cc: to the regular LKML.
>
> BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> different endianess. GAS supports an ".inst" directive which is like ".word"
> except the data is assumed to be code. This matters for disassembly, and may
> also be required for BE-8.
>
> That is, just s/.word/.inst/g above and report back if that works or not.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Hi Mikael,
Thanks for the reply. I modified the code as suggested and rebuilt the
kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
platform.
Since the ARM core can be configured by system software to work in
big-endian mode, it's necessary to fix this problem. And here is a
small patch :
diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
linux/arch/arm/mach-exynos/hotplug.c
--- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
04:50:59.000000000 +0800
+++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
@@ -72,7 +72,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(".inst 0xe320f003\n"
:
:
: "memory", "cc");
diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
linux/arch/arm/mach-realview/hotplug.c
--- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
04:50:59.000000000 +0800
+++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
@@ -66,7 +66,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(".inst 0xe320f003\n"
:
:
: "memory", "cc");
diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
linux/arch/arm/mach-shmobile/hotplug.c
--- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
04:50:59.000000000 +0800
+++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
@@ -53,7 +53,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(".inst 0xe320f003\n"
:
:
: "memory", "cc");
^ permalink raw reply
* [PATCH] MMC: fix sdhci-dove removal
From: Russell King - ARM Linux @ 2012-10-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015145855.GY12801@game.jcrosoft.org>
On Mon, Oct 15, 2012 at 04:58:55PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:44 Mon 15 Oct , Russell King - ARM Linux wrote:
> > On Mon, Oct 15, 2012 at 11:37:25AM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 15, 2012 at 10:43:48AM +0100, Russell King - ARM Linux wrote:
> > > > 1. Unregister the device _BEFORE_ taking away any resources it may
> > > > be using.
> > > > 2. Don't check clks against NULL.
> > > >
> > > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > >
> > > Looking at this driver some more, who the hell came up with the sdhci
> > > registration interface? It violates one of the most fundamental
> > > principles of kernel driver programming. You do _NOT_ publish your
> > > driver interfaces _UNTIL_ you have finished setting your device up.
> > > Otherwise, in a preemptible or SMP kernel, your driver can be used
> > > before the initialization has completed.
> > >
> > > As this driver calls sdhci_pltfm_register() before it has obtained the
> > > clock for the interface, and this function does:
> > > sdhci_pltfm_init
> > > sdhci_add_host
> > > mmc_add_host
> > > mmc_start_host
> > > mmc_power_up
> > > mmc_set_ios
> > > sdhci_set_ios
> > >
> > > See, we're trying to power up and clock the card _before_ the dove
> > > sdhci driver has even claimed the clock let alone enabled it. This
> > > is total bollocks. The sdhci platform interface is total crap for
> > > creating this broken design in the first place. This is why MMC has
> > > the init + add interfaces, they're there to allow drivers to do stuff
> > > the Right(tm) way and avoid shit like the above.
> > >
> > > This should have been picked up at review time before the driver went
> > > into mainline. In any case, it needs to be fixed.
> >
> > Here's an updated patch which just about fixes the sdhci-dove driver.
> > I would not be surprised given the idiotic sdhci-pltfm API if many
> > other drivers suffered the same bug.
> >
> > 8<====
> > From: Russell King <rmk+kernel@arm.linux.org.uk>
> > Subject: [PATCH] MMC: fix sdhci-dove probe/removal
> >
> > 1. Never ever publish a device in the system before it has been setup
> > to a usable state.
> > 2. Unregister the device _BEFORE_ taking away any resources it may be
> > using.
> > 3. Don't check clks against NULL.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> > ---
> > drivers/mmc/host/sdhci-dove.c | 36 ++++++++++++++++++------------------
> > 1 files changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
> > index a6e53a1..7d3a4e4 100644
> > --- a/drivers/mmc/host/sdhci-dove.c
> > +++ b/drivers/mmc/host/sdhci-dove.c
> > @@ -83,30 +83,31 @@ static int __devinit sdhci_dove_probe(struct platform_device *pdev)
> > struct sdhci_dove_priv *priv;
> > int ret;
> >
> > - ret = sdhci_pltfm_register(pdev, &sdhci_dove_pdata);
> > - if (ret)
> > - goto sdhci_dove_register_fail;
> > -
> > priv = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_dove_priv),
> > GFP_KERNEL);
> > if (!priv) {
> > dev_err(&pdev->dev, "unable to allocate private data");
> > - ret = -ENOMEM;
> > - goto sdhci_dove_allocate_fail;
> > + return -ENOMEM;
> > }
> >
> > + priv->clk = clk_get(&pdev->dev, NULL);
> you have devm_clk_get too
>
> maybe you could use it here too
This isn't a cleanup patch, this is a patch just to fix some stupid bugs
in this code. If someone wants to convert that afterwards, it should be
an entirely separate patch.
^ permalink raw reply
* [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support"
From: Paul Walmsley @ 2012-10-15 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015071657.GA22818@arwen.pp.htv.fi>
Hi
On Mon, 15 Oct 2012, Felipe Balbi wrote:
> On Mon, Oct 15, 2012 at 01:51:08AM +0000, Paul Walmsley wrote:
> >
> > Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde ("i2c: omap: switch to
> > threaded IRQ support") causes communication with I2C devices to fail
> > after system suspend/resume on all OMAP3 devices:
> >
> > ...
> > [ 40.228576] PM: noirq resume of devices complete after 3.723 msecs
> > [ 40.233184] PM: early resume of devices complete after 3.173 msecs
> > [ 40.242736] [sched_delayed] sched: RT throttling activated
> > [ 41.235046] omap_i2c omap_i2c.1: controller timed out
>
> instead of just reverting the patch, I'd rather try to figure out why
> controller times out in that situation.
>
> It should make no difference if you're running an IRQ thread or not.
>
> Do you have any extra debugging information which might help figuring
> out what the issue really is ?
As mentioned, the problem can be easily reproduced on OMAP3 is test by
running
"echo mem > /sys/power/state"
in userspace when rootfs is on MMC. Then wake up out of suspend, for
example, by hitting ENTER on the serial console.
This needs to be part of the testing before any OMAP patches are posted to
the lists -- if for no other reason than because Android kernels enter and
exit system suspend frequently as part of their standard usage model.
> If the thread is actually at fault, then we need to add IRQF_NO_THREAD
> to the IRQ flags, otherwise same issue will appear if we boot with
> "threadirqs" kernel parameter.
...
> but it fails because I2C times out and I'd like to understand why,
> before just reverting the patch.
It doesn't matter to me how it's fixed as long as it's fixed quickly
during the early 3.7-rcs.
- Paul
^ permalink raw reply
* [PATCH v3 2/2] i2c: change id to let i2c-at91 work
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-15 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350293428-24551-3-git-send-email-voice.shen@atmel.com>
On 17:30 Mon 15 Oct , Bo Shen wrote:
> The i2c core driver will turn the platform device ID to busnum
> When using platfrom device ID as -1, it means dynamically assigned
> the busnum. When writing code, we need to make sure the busnum,
> and call i2c_register_board_info(int busnum, ...) to register device
> if using -1, we do not know the value of busnum
>
> In order to solve this issue, set the platform device ID as a fix number
> Here using 0 to match the busnum used in i2c_regsiter_board_info()
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
can you check when this append for the first time to schedule a patch for stable too
Best Regards,
J.
^ permalink raw reply
* [PATCH] MMC: fix sdhci-dove removal
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-15 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015104456.GR21164@n2100.arm.linux.org.uk>
On 11:44 Mon 15 Oct , Russell King - ARM Linux wrote:
> On Mon, Oct 15, 2012 at 11:37:25AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 15, 2012 at 10:43:48AM +0100, Russell King - ARM Linux wrote:
> > > 1. Unregister the device _BEFORE_ taking away any resources it may
> > > be using.
> > > 2. Don't check clks against NULL.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > Looking at this driver some more, who the hell came up with the sdhci
> > registration interface? It violates one of the most fundamental
> > principles of kernel driver programming. You do _NOT_ publish your
> > driver interfaces _UNTIL_ you have finished setting your device up.
> > Otherwise, in a preemptible or SMP kernel, your driver can be used
> > before the initialization has completed.
> >
> > As this driver calls sdhci_pltfm_register() before it has obtained the
> > clock for the interface, and this function does:
> > sdhci_pltfm_init
> > sdhci_add_host
> > mmc_add_host
> > mmc_start_host
> > mmc_power_up
> > mmc_set_ios
> > sdhci_set_ios
> >
> > See, we're trying to power up and clock the card _before_ the dove
> > sdhci driver has even claimed the clock let alone enabled it. This
> > is total bollocks. The sdhci platform interface is total crap for
> > creating this broken design in the first place. This is why MMC has
> > the init + add interfaces, they're there to allow drivers to do stuff
> > the Right(tm) way and avoid shit like the above.
> >
> > This should have been picked up at review time before the driver went
> > into mainline. In any case, it needs to be fixed.
>
> Here's an updated patch which just about fixes the sdhci-dove driver.
> I would not be surprised given the idiotic sdhci-pltfm API if many
> other drivers suffered the same bug.
>
> 8<====
> From: Russell King <rmk+kernel@arm.linux.org.uk>
> Subject: [PATCH] MMC: fix sdhci-dove probe/removal
>
> 1. Never ever publish a device in the system before it has been setup
> to a usable state.
> 2. Unregister the device _BEFORE_ taking away any resources it may be
> using.
> 3. Don't check clks against NULL.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/mmc/host/sdhci-dove.c | 36 ++++++++++++++++++------------------
> 1 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
> index a6e53a1..7d3a4e4 100644
> --- a/drivers/mmc/host/sdhci-dove.c
> +++ b/drivers/mmc/host/sdhci-dove.c
> @@ -83,30 +83,31 @@ static int __devinit sdhci_dove_probe(struct platform_device *pdev)
> struct sdhci_dove_priv *priv;
> int ret;
>
> - ret = sdhci_pltfm_register(pdev, &sdhci_dove_pdata);
> - if (ret)
> - goto sdhci_dove_register_fail;
> -
> priv = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_dove_priv),
> GFP_KERNEL);
> if (!priv) {
> dev_err(&pdev->dev, "unable to allocate private data");
> - ret = -ENOMEM;
> - goto sdhci_dove_allocate_fail;
> + return -ENOMEM;
> }
>
> + priv->clk = clk_get(&pdev->dev, NULL);
you have devm_clk_get too
maybe you could use it here too
Best Regards,
J.
^ permalink raw reply
* [PATCH] ARM: SAMSUNG: Add naming of s3c64xx-spi devices
From: Sylwester Nawrocki @ 2012-10-15 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210021443.54897.heiko@sntech.de>
Hi Heiko,
On 10/02/2012 02:43 PM, Heiko St?bner wrote:
> Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
> data) introduced separate device names for the different subtypes of the
> spi controller but forgot to set these in the relevant machines.
>
> To fix this introduce a s3c64xx_spi_setname function and populate all
> Samsung arches with the correct names. The function resides in a new
> header, as the s3c64xx-spi.h contains driver platform data and should
> therefore at some later point move out of the Samsung include dir.
>
> Tested on a s3c2416-based machine.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Cc: stable at vger.kernel.org
This patch looks good to me. I've tested it on Exynos4412 SoC based
board. And it fixes quite serious problem - broken SPI support on
a all Samsung machs (non-dt) except s3c64xx in mainline v3.6 kernel.
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
(mach-exynos only)
Jos? Miguel, can you confirm it solves the problem for you ?
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH 2/2] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Lee Jones @ 2012-10-15 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350307020-5910-2-git-send-email-lee.jones@linaro.org>
Author: Lee Jones <lee.jones@linaro.org>
Date: Mon Oct 15 13:12:08 2012 +0100
Documentation: Describe Device Tree bindings for GPIO Regulator driver
Here we specify all non-standard bindings which can be used when
requesting the use of an GPIO controlled regulator from Device Tree.
Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 0000000..a7cdb6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,36 @@
+GPIO controlled regulators
+
+Required properties:
+- compatible : Must be "regulator-gpio".
+
+Optional properties:
+- gpio-enable : GPIO to use to enable/disable the regulator.
+- gpios : GPIO group used to control voltage.
+- states : Selection of available voltages and GPIO configs.
+- startup-delay-us : Startup time in microseconds.
+- enable-active-high : Polarity of GPIO is active high (default is low).
+
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+
+Example:
+
+ mmciv: gpio-regulator {
+ compatible = "regulator-gpio";
+
+ regulator-name = "mmci-gpio-supply";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2600000>;
+
+ gpio-enable = <&gpio0 23 0x4
+ gpios = <&gpio0 24 0x4
+ &gpio0 25 0x4>;
+ states = <1800000 0x3
+ 2200000 0x2
+ 2600000 0x1
+ 2900000 0x0>;
+
+ startup-delay-us = <100000>;
+ enable-active-high;
+ regulator-boot-on;
+ };
^ permalink raw reply related
* [PATCH] lib: decompress_unlzo: Change include file name
From: Markus F.X.J. Oberhumer @ 2012-10-15 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350238390-1549-1-git-send-email-festevam@gmail.com>
Thanks Fabio,
that should already be fixed on the "lzo-update" branch at
git://github.com/markus-oberhumer/linux.git lzo-update
Cheers,
Markus
On 2012-10-14 20:13, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Commit 7c979cebc (lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c)
> renamed lzo1x_decompress.c file, but missed to update lib/decompress_unlzo.c,
> which breaks imx_v6_v7_defconfig build:
>
> arch/arm/boot/compressed/../../../../lib/decompress_unlzo.c:34:34: fatal error: lzo/lzo1x_decompress.c: No such file or directory
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> lib/decompress_unlzo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
> index 4531294..960183d 100644
> --- a/lib/decompress_unlzo.c
> +++ b/lib/decompress_unlzo.c
> @@ -31,7 +31,7 @@
> */
>
> #ifdef STATIC
> -#include "lzo/lzo1x_decompress.c"
> +#include "lzo/lzo1x_decompress_safe.c"
> #else
> #include <linux/decompress/unlzo.h>
> #endif
--
Markus Oberhumer, <markus@oberhumer.com>, http://www.oberhumer.com/
^ permalink raw reply
* [PATCH] ARM: dts: exynos4210-trats: Split memory into 4 sections
From: Tomasz Figa @ 2012-10-15 14:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10e301cdaadf$ef547150$cdfd53f0$%kim@samsung.com>
Hi Kgene,
On Monday 15 of October 2012 23:18:23 Kukjin Kim wrote:
> Tomasz Figa wrote:
> > Since the maximum section size on mach-exynos is set to 256MiB, boards
> > with memory configuration defined using sections bigger than 256MiB
> > will fail to boot with a kernel panic.
>
> I don't think so and it works fine in my side. Probably, the reason of
> kernel panic you said is not a maximum sections size?
I have tested on arm-soc/for-next with exynos4_defconfig on Trats with DT
and it does not work without this patch. Applying this patch makes it
work.
> > This patch modifies the dts file of Samsung Trats board to define four
> > sections of 256MiB instead of two of 512MiB to fix the boot problem.
>
> BTW, if this patch can fix the problem, OK, I will apply this for now.
Yes, please.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121015/f3c038e7/attachment-0001.html>
^ permalink raw reply
* [PATCH] ARM: dts: exynos4: Enable serial controllers on Origen and SMDKV310
From: Kukjin Kim @ 2012-10-15 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1587144.mixS1B3zoJ@amdc1227>
Tomasz Figa wrote:
>
> Hi Kgene,
>
> On Monday 08 of October 2012 15:12:48 Tomasz Figa wrote:
> > This patch adds status override of serial nodes to enable used serial
> > ports on Origen and SMDKV310 board.
> >
> > Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos4210-origen.dts | 16 ++++++++++++++++
> > arch/arm/boot/dts/exynos4210-smdkv310.dts | 16 ++++++++++++++++
> > 2 files changed, 32 insertions(+)
> >
>
> I think you missed this patch when applying Exynos dts reorganization
> patches. It is needed to enable serial ports on Origen and SMDKV310
boards.
> Could you apply it as well?
>
Oops, yeah. I will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/2] mmc: core: Support all MMC capabilities when booting from Device Tree
From: Arnd Bergmann @ 2012-10-15 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350306959-5843-1-git-send-email-lee.jones@linaro.org>
On Monday 15 October 2012, Lee Jones wrote:
> Capabilities are an important part of the MMC subsystem. Much
> supported functionality would be lost if we didn't provide the
> same level of support when booting Device Tree as we currently
> do when the subsystem is passed capabilities via platform data.
> This patch supplies this support with one simple call to a
> DT parsing function.
We already document all the commonly used properties
in Documentation/devicetree/bindings/mmc/mmc.txt
Please don't add any duplicates or those that are not used
so far.
> + if(of_property_read_bool(np, "mmc-cap-4-bit-data"))
> + *caps |= MMC_CAP_4_BIT_DATA;
see "bus-width" property.
> + if(of_property_read_bool(np, "mmc-cap-mmc-highspeed"))
> + *caps |= MMC_CAP_MMC_HIGHSPEED;
> + if(of_property_read_bool(np, "mmc-cap-sd-highspeed"))
> + *caps |= MMC_CAP_SD_HIGHSPEED;
implied by "max-frequency" property.
> + if(of_property_read_bool(np, "mmc-cap-sdio-irq"))
> + *caps |= MMC_CAP_SDIO_IRQ;
implied by presence of SDIO irq property.
> + if(of_property_read_bool(np, "mmc-cap-spi"))
> + *caps |= MMC_CAP_SPI;
Only used by the mmc_spi driver, can be hardcoded there.
> + if(of_property_read_bool(np, "mmc-cap-needs-poll"))
> + *caps |= MMC_CAP_NEEDS_POLL;
implied by absence of irqs property.
> + if(of_property_read_bool(np, "mmc-cap-8-bit-data"))
> + *caps |= MMC_CAP_8_BIT_DATA;
see "bus-width" property.
> + if(of_property_read_bool(np, "mmc-cap-nonremovable"))
> + *caps |= MMC_CAP_NONREMOVABLE;
see "non-removable property.
> + if(of_property_read_bool(np, "mmc-cap-wait-while-busy"))
> + *caps |= MMC_CAP_WAIT_WHILE_BUSY;
This seems to be a linux device driver specific quirk that doesn't
belong into a hardware description.
> + if(of_property_read_bool(np, "mmc-cap-erase"))
> + *caps |= MMC_CAP_ERASE;
driver specific.
> ...
and so on. What are you actually missing in the properties that
are already there?
Arnd
^ permalink raw reply
* [PATCH] ARM: dts: exynos4210-trats: Split memory into 4 sections
From: Kukjin Kim @ 2012-10-15 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349779199-30665-1-git-send-email-t.figa@samsung.com>
Tomasz Figa wrote:
>
> Since the maximum section size on mach-exynos is set to 256MiB, boards
> with memory configuration defined using sections bigger than 256MiB will
> fail to boot with a kernel panic.
>
I don't think so and it works fine in my side. Probably, the reason of
kernel panic you said is not a maximum sections size?
> This patch modifies the dts file of Samsung Trats board to define four
> sections of 256MiB instead of two of 512MiB to fix the boot problem.
>
BTW, if this patch can fix the problem, OK, I will apply this for now.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
> ---
> arch/arm/boot/dts/exynos4210-trats.dts | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
> b/arch/arm/boot/dts/exynos4210-trats.dts
> index 73567b8..a21511c 100644
> --- a/arch/arm/boot/dts/exynos4210-trats.dts
> +++ b/arch/arm/boot/dts/exynos4210-trats.dts
> @@ -20,8 +20,10 @@
> compatible = "samsung,trats", "samsung,exynos4210";
>
> memory {
> - reg = <0x40000000 0x20000000
> - 0x60000000 0x20000000>;
> + reg = <0x40000000 0x10000000
> + 0x50000000 0x10000000
> + 0x60000000 0x10000000
> + 0x70000000 0x10000000>;
> };
>
> chosen {
> --
> 1.7.12
^ permalink raw reply
* [PATCH 2/2] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Arnd Bergmann @ 2012-10-15 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350307020-5910-2-git-send-email-lee.jones@linaro.org>
On Monday 15 October 2012, Lee Jones wrote:
> diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> new file mode 100644
> index 0000000..5f77ee0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
> @@ -0,0 +1,25 @@
> +GPIO controlled regulators
> +
> +Required properties:
> +- compatible : Must be "regulator-gpio".
> +
> +Optional properties:
> +- gpio-enable : GPIO to use to enable/disable the regulator.
> +- startup-delay-us : Startup time in microseconds.
> +- enable-active-high : Polarity of GPIO is active high (default is low).
> +
> +Any property defined as part of the core regulator binding defined in
> +regulator.txt can also be used.
> +
> +Example:
> +
> + mmciv: gpio-regulator {
> + compatible = "regulator-gpio";
> + regulator-name = "mmci-gpio-supply";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2600000>;
> + gpio = <&gpio0 24 0x4>;
> + startup-delay-us = <100000>;
> + enable-active-high;
> + regulator-boot-on;
> + };
The example doesn't match the documentation for the name of the gpio property
("gpio" vs. "gpio-enable"). I think the convention is to use "gpios".
Shouldn't this property be mandatory? I think there is little point in
defining a gpio-regulator without a gpio line attached to it.
Finally, the "enable-active-high" looks redundant, as that is something
that is normally encoded in the "gpios" property.
Arnd
^ permalink raw reply
* [RFC 2/2] ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute
From: Marek Szyprowski @ 2012-10-15 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350309832-18461-1-git-send-email-m.szyprowski@samsung.com>
This patch adds support for DMA_ATTR_FORCE_CONTIGUOUS attribute for
dma_alloc_attrs() in IOMMU-aware implementation. For allocating physically
contiguous buffers Contiguous Memory Allocator is used.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mm/dma-mapping.c | 41 +++++++++++++++++++++++++++++++++--------
1 file changed, 33 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 477a2d2..583a302 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1036,7 +1036,8 @@ static inline void __free_iova(struct dma_iommu_mapping *mapping,
spin_unlock_irqrestore(&mapping->lock, flags);
}
-static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, gfp_t gfp)
+static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
+ gfp_t gfp, struct dma_attrs *attrs)
{
struct page **pages;
int count = size >> PAGE_SHIFT;
@@ -1050,6 +1051,23 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size, gfp_t
if (!pages)
return NULL;
+ if (dma_get_attr(DMA_ATTR_FORCE_CONTIGUOUS, attrs))
+ {
+ unsigned long order = get_order(size);
+ struct page *page;
+
+ page = dma_alloc_from_contiguous(dev, count, order);
+ if (!page)
+ goto error;
+
+ __dma_clear_buffer(page, size);
+
+ for (i = 0; i < count; i++)
+ pages[i] = page + i;
+
+ return pages;
+ }
+
while (count) {
int j, order = __fls(count);
@@ -1083,14 +1101,21 @@ error:
return NULL;
}
-static int __iommu_free_buffer(struct device *dev, struct page **pages, size_t size)
+static int __iommu_free_buffer(struct device *dev, struct page **pages,
+ size_t size, struct dma_attrs *attrs)
{
int count = size >> PAGE_SHIFT;
int array_size = count * sizeof(struct page *);
int i;
- for (i = 0; i < count; i++)
- if (pages[i])
- __free_pages(pages[i], 0);
+
+ if (dma_get_attr(DMA_ATTR_FORCE_CONTIGUOUS, attrs)) {
+ dma_release_from_contiguous(dev, pages[0], count);
+ } else {
+ for (i = 0; i < count; i++)
+ if (pages[i])
+ __free_pages(pages[i], 0);
+ }
+
if (array_size <= PAGE_SIZE)
kfree(pages);
else
@@ -1252,7 +1277,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
if (gfp & GFP_ATOMIC)
return __iommu_alloc_atomic(dev, size, handle);
- pages = __iommu_alloc_buffer(dev, size, gfp);
+ pages = __iommu_alloc_buffer(dev, size, gfp, attrs);
if (!pages)
return NULL;
@@ -1273,7 +1298,7 @@ static void *arm_iommu_alloc_attrs(struct device *dev, size_t size,
err_mapping:
__iommu_remove_mapping(dev, *handle, size);
err_buffer:
- __iommu_free_buffer(dev, pages, size);
+ __iommu_free_buffer(dev, pages, size, attrs);
return NULL;
}
@@ -1329,7 +1354,7 @@ void arm_iommu_free_attrs(struct device *dev, size_t size, void *cpu_addr,
}
__iommu_remove_mapping(dev, handle, size);
- __iommu_free_buffer(dev, pages, size);
+ __iommu_free_buffer(dev, pages, size, attrs);
}
static int arm_iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
--
1.7.9.5
^ permalink raw reply related
* [RFC 1/2] common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute
From: Marek Szyprowski @ 2012-10-15 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350309832-18461-1-git-send-email-m.szyprowski@samsung.com>
This patch adds DMA_ATTR_FORCE_CONTIGUOUS attribute to the DMA-mapping
subsystem.
By default DMA-mapping subsystem is allowed to assemble the buffer
allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifing this attribute the allocated buffer is forced to be contiguous
also in physical memory.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
Documentation/DMA-attributes.txt | 9 +++++++++
include/linux/dma-attrs.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index f503090..e59480d 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -91,3 +91,12 @@ transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!
+
+DMA_ATTR_FORCE_CONTIGUOUS
+-------------------------
+
+By default DMA-mapping subsystem is allowed to assemble the buffer
+allocated by dma_alloc_attrs() function from individual pages if it can
+be mapped as contiguous chunk into device dma address space. By
+specifing this attribute the allocated buffer is forced to be contiguous
+also in physical memory.
diff --git a/include/linux/dma-attrs.h b/include/linux/dma-attrs.h
index f83f793..c8e1831 100644
--- a/include/linux/dma-attrs.h
+++ b/include/linux/dma-attrs.h
@@ -17,6 +17,7 @@ enum dma_attr {
DMA_ATTR_NON_CONSISTENT,
DMA_ATTR_NO_KERNEL_MAPPING,
DMA_ATTR_SKIP_CPU_SYNC,
+ DMA_ATTR_FORCE_CONTIGUOUS,
DMA_ATTR_MAX,
};
--
1.7.9.5
^ permalink raw reply related
* [RFC 0/2] DMA-mapping & IOMMU - physically contiguous allocations
From: Marek Szyprowski @ 2012-10-15 14:03 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Some devices, which have IOMMU, for some use cases might require to
allocate a buffers for DMA which is contiguous in physical memory. Such
use cases appears for example in DRM subsystem when one wants to improve
performance or use secure buffer protection.
I would like to ask if adding a new attribute, as proposed in this RFC
is a good idea? I feel that it might be an attribute just for a single
driver, but I would like to know your opinion. Should we look for other
solution?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
Marek Szyprowski (2):
common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute
ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute
Documentation/DMA-attributes.txt | 9 +++++++++
arch/arm/mm/dma-mapping.c | 41 ++++++++++++++++++++++++++++++--------
include/linux/dma-attrs.h | 1 +
3 files changed, 43 insertions(+), 8 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH] ARM: s3c: mark s3c2440_clk_add as __init_refok
From: Kukjin Kim @ 2012-10-15 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210121114.52348.arnd@arndb.de>
Arnd Bergmann wrote:
>
> s3c2440_clk_add is a subsys_interface method and calls clkdev_add_table,
> which is marked as __init. The modpost script complains about this
> because we must not call an __init function from a function in the .text
> section, and we cannot reference an __init function from a
> subsys_interface
> pointer.
>
> I have verified that the only code path into s3c2440_clk_add() is
> from "int __init s3c2440_init(void)", so s3c2440_clk_add can be marked
> __init_refok instead.
>
> Without this patch, building mini2440_defconfig results in:
>
> WARNING: vmlinux.o(.text+0x9848): Section mismatch in reference from the
> function s3c2440_clk_add() to the function .init.text:clkdev_add_table()
> The function s3c2440_clk_add() references
> the function __init clkdev_add_table().
> This is often because s3c2440_clk_add lacks a __init
> annotation or the annotation of clkdev_add_table is wrong.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
>
> I'll put this into arm-soc/fixes unless I hear objections. This replaces
> the
> earlier "clk: don't mark clkdev_add_table as init" as suggested by
Russell.
>
Yeah, I read it just now and I agree with this patch.
Thanks for your fix.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v2 0/6] ARM: EXYNOS: Add secure firmware support
From: Kukjin Kim @ 2012-10-15 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010161136.GD582@quad.lixom.net>
Olof Johansson wrote:
>
> Hi,
>
> On Thu, Oct 11, 2012 at 12:35:54AM +0900, Kyungmin Park wrote:
> > Hi Arnd or Olof,
> >
> > Can you pick up for v3.7?
> >
> > To Tomasz,
> > Can you rebase it on the latest arm-soc tree?
>
> This code should have been in arm-soc by the beginning of the merge window
> (and in linux-next) to be merged for 3.7, but we will be happy to queue
> it up for 3.8 once 3.7-rc1 is out. I have one outstanding comment on
> the DT binding but the rest looks OK to me.
>
Yeah, I agree.
Olof, thanks for your review.
> Tomasz, please rebase and send this to Kukjin so he can queue it up with
> other
> Samsung code.
>
OK, let me apply this series in Samsung tree when Tomasz's rebased code
against on v3.7-rc1 is available.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [GIT PULL] OMAP-GPMC related cleanup for common zImage
From: Artem Bityutskiy @ 2012-10-15 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350304405-14762-1-git-send-email-afzal@ti.com>
On Mon, 2012-10-15 at 18:03 +0530, Afzal Mohammed wrote:
> The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/x0148406-public/linux-kernel.git tags/gpmc-czimage
FWIW, the mtd changes look OK, and this stuff is very OMAP-specific, so
merging everything through the OMAP tree makes a lot of sense. Thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121015/06e4839b/attachment.sig>
^ permalink raw reply
* [PATCH RESEND] serial/amba-pl011: use devm_* managed resources
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-15 13:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350300961-7036-1-git-send-email-linus.walleij@stericsson.com>
On 13:36 Mon 15 Oct , Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This switches a bunch of allocation and remapping to use the
> devm_* garbage collected methods and cleans up the error
> path and remove() paths consequently.
>
> devm_ioremap() is only in <linux/io.h> so fix up the
> erroneous <asm/*> include as well.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
^ permalink raw reply
* [PATCH] MTD: atmel_nand: fix compile error when use avr32-atstk1006_defconfig
From: Artem Bityutskiy @ 2012-10-15 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349678809-12092-1-git-send-email-josh.wu@atmel.com>
On Mon, 2012-10-08 at 14:46 +0800, Josh Wu wrote:
> fixed the following compile error when use avr32 config:
> drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location':
> drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed'
>
> Since in ARCH avr32, there is no macro "writel_relaxed" defined. In this patch we use macro "writel" instead.
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
Why not to provide writel_relaxed() in AVR instead?
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121015/803e0b10/attachment.sig>
^ 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