* [PATCH v2 2/2] ARM: dts: Add intial dts file for Exynos4210 SoC, SMDKV310 and Origen board
From: Thomas Abraham @ 2011-11-01 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320109613-2811-1-git-send-email-thomas.abraham@linaro.org>
Add initial dts file for Exynos4210 SoC. This dts file describes the SoC
specific devices and properties. Along with this, add dts file for Samsung's
SMDKV310 board and Insignal's Origen board which uses the Exynos4210 dts file
and extends it to describe the board specific properties.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/arm/boot/dts/exynos4210-origen.dts | 137 ++++++++++
arch/arm/boot/dts/exynos4210-smdkv310.dts | 182 +++++++++++++
arch/arm/boot/dts/exynos4210.dtsi | 397 +++++++++++++++++++++++++++++
3 files changed, 716 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4210-origen.dts
create mode 100644 arch/arm/boot/dts/exynos4210-smdkv310.dts
create mode 100644 arch/arm/boot/dts/exynos4210.dtsi
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
new file mode 100644
index 0000000..b8c4763
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -0,0 +1,137 @@
+/*
+ * Samsung's Exynos4210 based Origen board device tree source
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * Device tree source file for Insignal's Origen board which is based on
+ * Samsung's Exynos4210 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ "exynos4210.dtsi"
+
+/ {
+ model = "Insignal Origen evaluation board based on Exynos4210";
+ compatible = "insignal,origen", "samsung,exynos4210";
+
+ memory {
+ reg = <0x40000000 0x40000000>;
+ };
+
+ chosen {
+ bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC2,115200 init=/linuxrc";
+ };
+
+ sdhci at 12530000 {
+ samsung,sdhci-bus-width = <4>;
+ linux,mmc_cap_4_bit_data;
+ samsung,sdhci-cd-internal;
+ gpio-cd = <&gpk2 2 2 3 3>;
+ gpios = <&gpk2 0 2 0 3>,
+ <&gpk2 1 2 0 3>,
+ <&gpk2 3 2 3 3>,
+ <&gpk2 4 2 3 3>,
+ <&gpk2 5 2 3 3>,
+ <&gpk2 6 2 3 3>;
+ };
+
+ sdhci at 12510000 {
+ samsung,sdhci-bus-width = <4>;
+ linux,mmc_cap_4_bit_data;
+ samsung,sdhci-cd-internal;
+ gpio-cd = <&gpk0 2 2 3 3>;
+ gpios = <&gpk0 0 2 0 3>,
+ <&gpk0 1 2 0 3>,
+ <&gpk0 3 2 3 3>,
+ <&gpk0 4 2 3 3>,
+ <&gpk0 5 2 3 3>,
+ <&gpk0 6 2 3 3>;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ up {
+ label = "Up";
+ gpios = <&gpx2 0 0 0 2>;
+ linux,code = <103>;
+ };
+
+ down {
+ label = "Down";
+ gpios = <&gpx2 1 0 0 2>;
+ linux,code = <108>;
+ };
+
+ back {
+ label = "Back";
+ gpios = <&gpx1 7 0 0 2>;
+ linux,code = <158>;
+ };
+
+ home {
+ label = "Home";
+ gpios = <&gpx1 6 0 0 2>;
+ linux,code = <102>;
+ };
+
+ menu {
+ label = "Menu";
+ gpios = <&gpx1 5 0 0 2>;
+ linux,code = <139>;
+ };
+ };
+
+ keypad at 100A0000 {
+ status = "disabled";
+ };
+
+ sdhci at 12520000 {
+ status = "disabled";
+ };
+
+ sdhci at 12540000 {
+ status = "disabled";
+ };
+
+ i2c at 13860000 {
+ status = "disabled";
+ };
+
+ i2c at 13870000 {
+ status = "disabled";
+ };
+
+ i2c at 13880000 {
+ status = "disabled";
+ };
+
+ i2c at 13890000 {
+ status = "disabled";
+ };
+
+ i2c at 138A0000 {
+ status = "disabled";
+ };
+
+ i2c at 138B0000 {
+ status = "disabled";
+ };
+
+ i2c at 138C0000 {
+ status = "disabled";
+ };
+
+ i2c at 138D0000 {
+ status = "disabled";
+ };
+};
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts b/arch/arm/boot/dts/exynos4210-smdkv310.dts
new file mode 100644
index 0000000..27afc8e
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -0,0 +1,182 @@
+/*
+ * Samsung's Exynos4210 based SMDKV310 board device tree source
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * Device tree source file for Samsung's SMDKV310 board which is based on
+ * Samsung's Exynos4210 SoC.
+ *
+ * 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.
+*/
+
+/dts-v1/;
+/include/ "exynos4210.dtsi"
+
+/ {
+ model = "Samsung smdkv310 evaluation board based on Exynos4210";
+ compatible = "samsung,smdkv310", "samsung,exynos4210";
+
+ memory {
+ reg = <0x40000000 0x80000000>;
+ };
+
+ chosen {
+ bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc";
+ };
+
+ sdhci at 12530000 {
+ samsung,sdhci-bus-width = <4>;
+ linux,mmc_cap_4_bit_data;
+ samsung,sdhci-cd-internal;
+ gpio-cd = <&gpk2 2 2 3 3>;
+ gpios = <&gpk2 0 2 0 3>,
+ <&gpk2 1 2 0 3>,
+ <&gpk2 3 2 3 3>,
+ <&gpk2 4 2 3 3>,
+ <&gpk2 5 2 3 3>,
+ <&gpk2 6 2 3 3>;
+ };
+
+ keypad at 100A0000 {
+ samsung,keypad-num-rows = <2>;
+ samsung,keypad-num-columns = <8>;
+ linux,keypad-no-autorepeat;
+ linux,keypad-wakeup;
+
+ row-gpios = <&gpx2 0 3 3 0>,
+ <&gpx2 1 3 3 0>;
+
+ col-gpios = <&gpx1 0 3 0 0>,
+ <&gpx1 1 3 0 0>,
+ <&gpx1 2 3 0 0>,
+ <&gpx1 3 3 0 0>,
+ <&gpx1 4 3 0 0>,
+ <&gpx1 5 3 0 0>,
+ <&gpx1 6 3 0 0>,
+ <&gpx1 7 3 0 0>;
+
+ key_1 {
+ keypad,row = <0>;
+ keypad,column = <3>;
+ linux,code = <2>;
+ };
+
+ key_2 {
+ keypad,row = <0>;
+ keypad,column = <4>;
+ linux,code = <3>;
+ };
+
+ key_3 {
+ keypad,row = <0>;
+ keypad,column = <5>;
+ linux,code = <4>;
+ };
+
+ key_4 {
+ keypad,row = <0>;
+ keypad,column = <6>;
+ linux,code = <5>;
+ };
+
+ key_5 {
+ keypad,row = <0>;
+ keypad,column = <7>;
+ linux,code = <6>;
+ };
+
+ key_a {
+ keypad,row = <1>;
+ keypad,column = <3>;
+ linux,code = <30>;
+ };
+
+ key_b {
+ keypad,row = <1>;
+ keypad,column = <4>;
+ linux,code = <48>;
+ };
+
+ key_c {
+ keypad,row = <1>;
+ keypad,column = <5>;
+ linux,code = <46>;
+ };
+
+ key_d {
+ keypad,row = <1>;
+ keypad,column = <6>;
+ linux,code = <32>;
+ };
+
+ key_e {
+ keypad,row = <1>;
+ keypad,column = <7>;
+ linux,code = <18>;
+ };
+ };
+
+ i2c at 13860000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <20000>;
+ gpios = <&gpd1 0 2 3 0>,
+ <&gpd1 1 2 3 0>;
+
+ eeprom at 50 {
+ compatible = "samsung,24ad0xd1";
+ reg = <0x50>;
+ };
+
+ eeprom at 52 {
+ compatible = "samsung,24ad0xd1";
+ reg = <0x52>;
+ };
+ };
+
+ sdhci at 12510000 {
+ status = "disabled";
+ };
+
+ sdhci at 12520000 {
+ status = "disabled";
+ };
+
+ sdhci at 12540000 {
+ status = "disabled";
+ };
+
+ i2c at 13870000 {
+ status = "disabled";
+ };
+
+ i2c at 13880000 {
+ status = "disabled";
+ };
+
+ i2c at 13890000 {
+ status = "disabled";
+ };
+
+ i2c at 138A0000 {
+ status = "disabled";
+ };
+
+ i2c at 138B0000 {
+ status = "disabled";
+ };
+
+ i2c at 138C0000 {
+ status = "disabled";
+ };
+
+ i2c at 138D0000 {
+ status = "disabled";
+ };
+};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
new file mode 100644
index 0000000..63d7578
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -0,0 +1,397 @@
+/*
+ * Samsung's Exynos4210 SoC device tree source
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * Samsung's Exynos4210 SoC device nodes are listed in this file. Exynos4210
+ * based board files can include this file and provide values for board specfic
+ * bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * Exynos4210 SoC. As device tree coverage for Exynos4210 increases, additional
+ * nodes can be added to this file.
+ *
+ * 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/ "skeleton.dtsi"
+
+/ {
+ compatible = "samsung,exynos4210";
+ interrupt-parent = <&gic>;
+
+ gic:interrupt-controller at 10490000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x10490000 0x1000>, <0x10480000 0x100>;
+ };
+
+ watchdog at 10060000 {
+ compatible = "samsung,s3c2410-wdt";
+ reg = <0x10060000 0x100>;
+ interrupts = <0 43 0>;
+ };
+
+ rtc at 10070000 {
+ compatible = "samsung,s3c6410-rtc";
+ reg = <0x10070000 0x100>;
+ interrupts = <0 44 0>, <0 45 0>;
+ };
+
+ keypad at 100A0000 {
+ compatible = "samsung,s5pv210-keypad";
+ reg = <0x100A0000 0x100>;
+ interrupts = <0 109 0>;
+ };
+
+ sdhci at 12510000 {
+ compatible = "samsung,exynos4210-sdhci";
+ reg = <0x12510000 0x100>;
+ interrupts = <0 73 0>;
+ };
+
+ sdhci at 12520000 {
+ compatible = "samsung,exynos4210-sdhci";
+ reg = <0x12520000 0x100>;
+ interrupts = <0 74 0>;
+ };
+
+ sdhci at 12530000 {
+ compatible = "samsung,exynos4210-sdhci";
+ reg = <0x12530000 0x100>;
+ interrupts = <0 75 0>;
+ };
+
+ sdhci at 12540000 {
+ compatible = "samsung,exynos4210-sdhci";
+ reg = <0x12540000 0x100>;
+ interrupts = <0 76 0>;
+ };
+
+ serial at 13800000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13800000 0x100>;
+ interrupts = <0 52 0>;
+ };
+
+ serial at 13810000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13810000 0x100>;
+ interrupts = <0 53 0>;
+ };
+
+ serial at 13820000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13820000 0x100>;
+ interrupts = <0 54 0>;
+ };
+
+ serial at 13830000 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x13830000 0x100>;
+ interrupts = <0 55 0>;
+ };
+
+ i2c at 13860000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x13860000 0x100>;
+ interrupts = <0 58 0>;
+ };
+
+ i2c at 13870000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x13870000 0x100>;
+ interrupts = <0 59 0>;
+ };
+
+ i2c at 13880000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x13880000 0x100>;
+ interrupts = <0 60 0>;
+ };
+
+ i2c at 13890000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x13890000 0x100>;
+ interrupts = <0 61 0>;
+ };
+
+ i2c at 138A0000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x138A0000 0x100>;
+ interrupts = <0 62 0>;
+ };
+
+ i2c at 138B0000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x138B0000 0x100>;
+ interrupts = <0 63 0>;
+ };
+
+ i2c at 138C0000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x138C0000 0x100>;
+ interrupts = <0 64 0>;
+ };
+
+ i2c at 138D0000 {
+ compatible = "samsung,s3c2440-i2c";
+ reg = <0x138D0000 0x100>;
+ interrupts = <0 65 0>;
+ };
+
+ amba {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "arm,amba-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ pdma0: pdma at 12680000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x12680000 0x1000>;
+ interrupts = <0 35 0>;
+ };
+
+ pdma1: pdma at 12690000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x12690000 0x1000>;
+ interrupts = <0 36 0>;
+ };
+ };
+
+ gpio-controllers {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ gpio-controller;
+ ranges;
+
+ gpa0: gpio-controller at 11400000 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400000 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpa1: gpio-controller at 11400020 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400020 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpb: gpio-controller at 11400040 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400040 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpc0: gpio-controller at 11400060 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400060 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpc1: gpio-controller at 11400080 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400080 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpd0: gpio-controller at 114000A0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x114000A0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpd1: gpio-controller at 114000C0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x114000C0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpe0: gpio-controller at 114000E0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x114000E0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpe1: gpio-controller at 11400100 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400100 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpe2: gpio-controller at 11400120 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400120 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpe3: gpio-controller at 11400140 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400140 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpe4: gpio-controller at 11400160 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400160 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpf0: gpio-controller at 11400180 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11400180 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpf1: gpio-controller at 114001A0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x114001A0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpf2: gpio-controller at 114001C0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x114001C0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpf3: gpio-controller at 114001E0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x114001E0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpj0: gpio-controller at 11000000 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000000 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpj1: gpio-controller at 11000020 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000020 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpk0: gpio-controller at 11000040 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000040 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpk1: gpio-controller at 11000060 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000060 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpk2: gpio-controller at 11000080 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000080 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpk3: gpio-controller at 110000A0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x110000A0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpl0: gpio-controller at 110000C0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x110000C0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpl1: gpio-controller at 110000E0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x110000E0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpl2: gpio-controller at 11000100 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000100 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy0: gpio-controller at 11000120 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000120 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy1: gpio-controller at 11000140 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000140 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy2: gpio-controller at 11000160 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000160 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy3: gpio-controller at 11000180 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000180 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy4: gpio-controller at 110001A0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x110001A0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy5: gpio-controller at 110001C0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x110001C0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpy6: gpio-controller at 110001E0 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x110001E0 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpx0: gpio-controller at 11000C00 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000C00 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpx1: gpio-controller at 11000C20 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000C20 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpx2: gpio-controller at 11000C40 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000C40 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpx3: gpio-controller at 11000C60 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x11000C60 0x20>;
+ #gpio-cells = <4>;
+ };
+
+ gpz: gpio-controller at 03860000 {
+ compatible = "samsung,exynos4-gpio";
+ reg = <0x03860000 0x20>;
+ #gpio-cells = <4>;
+ };
+ };
+};
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2 1/2] ARM: Samsung: Add Exynos4 device tree enabled board file
From: Thomas Abraham @ 2011-11-01 1:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320109613-2811-1-git-send-email-thomas.abraham@linaro.org>
Add a new Exynos4 compatible device tree enabled board file. Boards based on
the Exynos4 family of SoC's can use this as the machine/board file. When using
this machine fike, a corresponding device tree blob which describes the board's
properties should be supplied at boot time to the kernel.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
---
.../devicetree/bindings/arm/insignal-boards.txt | 8 ++
.../devicetree/bindings/arm/samsung-boards.txt | 8 ++
arch/arm/mach-exynos4/Kconfig | 14 +++
arch/arm/mach-exynos4/Makefile | 2 +
arch/arm/mach-exynos4/mach-exynos4-dt.c | 85 ++++++++++++++++++++
5 files changed, 117 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/insignal-boards.txt
create mode 100644 Documentation/devicetree/bindings/arm/samsung-boards.txt
create mode 100644 arch/arm/mach-exynos4/mach-exynos4-dt.c
diff --git a/Documentation/devicetree/bindings/arm/insignal-boards.txt b/Documentation/devicetree/bindings/arm/insignal-boards.txt
new file mode 100644
index 0000000..524c3dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/insignal-boards.txt
@@ -0,0 +1,8 @@
+* Insignal's Exynos4210 based Origen evaluation board
+
+Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
+
+Required root node properties:
+ - compatible = should be one or more of the following.
+ (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
+ (b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt
new file mode 100644
index 0000000..0bf68be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung-boards.txt
@@ -0,0 +1,8 @@
+* Samsung's Exynos4210 based SMDKV310 evaluation board
+
+SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
+
+Required root node properties:
+ - compatible = should be one or more of the following.
+ (a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
+ (b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 9eefd1e..7313500 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -306,6 +306,20 @@ config MACH_SMDK4412
help
Machine support for Samsung SMDK4412
+comment "Flattened Device Tree based board for Exynos4 based SoC"
+
+config MACH_EXYNOS4_DT
+ bool "Samsung Exynos4 Machine using device tree"
+ select CPU_EXYNOS4210
+ select USE_OF
+ select ARM_AMBA
+ select HAVE_SAMSUNG_KEYPAD if INPUT_KEYBOARD
+ help
+ Machine support for Samsung Exynos4 machine with device tree enabled.
+ Select this if a fdt blob is available for the Exynos4 SoC based board.
+ Note: This is under development and not all peripherals can be supported
+ with this machine file.
+
endmenu
comment "Configuration for HSMMC bus width"
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 2bb18f4..3ef8873 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -37,6 +37,8 @@ obj-$(CONFIG_MACH_ORIGEN) += mach-origen.o
obj-$(CONFIG_MACH_SMDK4212) += mach-smdk4x12.o
obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o
+obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
+
# device support
obj-y += dev-audio.o
diff --git a/arch/arm/mach-exynos4/mach-exynos4-dt.c b/arch/arm/mach-exynos4/mach-exynos4-dt.c
new file mode 100644
index 0000000..85fa027
--- /dev/null
+++ b/arch/arm/mach-exynos4/mach-exynos4-dt.c
@@ -0,0 +1,85 @@
+/*
+ * Samsung's Exynos4210 flattened device tree enabled machine
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2010-2011 Linaro Ltd.
+ * www.linaro.org
+ *
+ * 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/of_platform.h>
+#include <linux/serial_core.h>
+
+#include <asm/mach/arch.h>
+#include <mach/map.h>
+
+#include <plat/cpu.h>
+#include <plat/regs-serial.h>
+#include <plat/exynos4.h>
+
+/*
+ * The following lookup table is used to override device names when devices
+ * are registered from device tree. This is temporarily added to enable
+ * device tree support addition for the Exynos4 architecture.
+ *
+ * For drivers that require platform data to be provided from the machine
+ * file, a platform data pointer can also be supplied along with the
+ * devices names. Usually, the platform data elements that cannot be parsed
+ * from the device tree by the drivers (example: function pointers) are
+ * supplied. But it should be noted that this is a temporary mechanism and
+ * at some point, the drivers should be capable of parsing all the platform
+ * data from the device tree.
+ */
+static const struct of_dev_auxdata exynos4210_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA("samsung,exynos4210-uart", S5P_PA_UART0,
+ "exynos4210-uart.0", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-uart", S5P_PA_UART1,
+ "exynos4210-uart.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-uart", S5P_PA_UART2,
+ "exynos4210-uart.2", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-uart", S5P_PA_UART3,
+ "exynos4210-uart.3", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-sdhci", EXYNOS4_PA_HSMMC(0),
+ "exynos4-sdhci.0", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-sdhci", EXYNOS4_PA_HSMMC(1),
+ "exynos4-sdhci.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-sdhci", EXYNOS4_PA_HSMMC(2),
+ "exynos4-sdhci.2", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-sdhci", EXYNOS4_PA_HSMMC(3),
+ "exynos4-sdhci.3", NULL),
+ OF_DEV_AUXDATA("samsung,s3c2440-i2c", EXYNOS4_PA_IIC(0),
+ "s3c2440-i2c.0", NULL),
+ OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA0, "dma-pl330.0", NULL),
+ OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
+ {},
+};
+
+static void __init exynos4210_dt_map_io(void)
+{
+ s5p_init_io(NULL, 0, S5P_VA_CHIPID);
+ s3c24xx_init_clocks(24000000);
+}
+
+static void __init exynos4210_dt_machine_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table,
+ exynos4210_auxdata_lookup, NULL);
+}
+
+static char const *exynos4210_dt_compat[] __initdata = {
+ "samsung,exynos4210",
+ NULL
+};
+
+DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)")
+ /* Maintainer: Thomas Abraham <thomas.abraham@linaro.org> */
+ .init_irq = exynos4_init_irq,
+ .map_io = exynos4210_dt_map_io,
+ .init_machine = exynos4210_dt_machine_init,
+ .timer = &exynos4_timer,
+ .dt_compat = exynos4210_dt_compat,
+MACHINE_END
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2 0/2] ARM: Samsung: Add basic device tree support for Exynos4 boards
From: Thomas Abraham @ 2011-11-01 1:06 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v1:
- Removed unique per-controller compatible string value from gpio controller nodes
to align with the updated device tree support for exynos4 gpio controller.
- Removed the interrupt combiner controller node.
This patchset adds a new basic device tree enabled machine/board file which is
based on the Samsung's Exynos4 family of SoC's. Also included in this patchset is the
dts file for Exynos4210 SoC, Samsung's SMDKV310 board and Insignal's Origen board.
The Exynos4210 dts file includes support for IRQ, GPIO, WDT, RTC, UART, SDHCI, Keypad,
DMA and I2C controllers. As device tree coverage for Exynos4210 increases, additional
device nodes to represent the controllers should be added.
The device tree enabled machine file enables boot on two boards based on the
Exynos4210 SoC. This provides a starting point to add additional device tree support
on these boards, migrate other existing Exynos4 based boards to use device tree
and enable device tree based boot on new upcoming boards.
This patchset has been tested on the following tree:
git://git.linaro.org/git/people/arnd/arm-soc.git branch: for-next
Thomas Abraham (2):
ARM: Samsung: Add Exynos4 device tree enabled board file
ARM: dts: Add intial dts file for Exynos4210 SoC, SMDKV310 and Origen board
.../devicetree/bindings/arm/insignal-boards.txt | 8 +
.../devicetree/bindings/arm/samsung-boards.txt | 8 +
arch/arm/boot/dts/exynos4210-origen.dts | 137 +++++++
arch/arm/boot/dts/exynos4210-smdkv310.dts | 182 +++++++++
arch/arm/boot/dts/exynos4210.dtsi | 397 ++++++++++++++++++++
arch/arm/mach-exynos4/Kconfig | 14 +
arch/arm/mach-exynos4/Makefile | 2 +
arch/arm/mach-exynos4/mach-exynos4-dt.c | 85 +++++
8 files changed, 833 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/insignal-boards.txt
create mode 100644 Documentation/devicetree/bindings/arm/samsung-boards.txt
create mode 100644 arch/arm/boot/dts/exynos4210-origen.dts
create mode 100644 arch/arm/boot/dts/exynos4210-smdkv310.dts
create mode 100644 arch/arm/boot/dts/exynos4210.dtsi
create mode 100644 arch/arm/mach-exynos4/mach-exynos4-dt.c
^ permalink raw reply
* Re: HT (Hyper Threading) aware process scheduling doesn't work as it should
From: Gene Heskett @ 2011-11-01 0:58 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel
In-Reply-To: <2516934.OmMpfqGngS@quad>
On Monday, October 31, 2011, Con Kolivas wrote:
>Fortunately BFS is about optimising user visible service latency for
>normal users running normal applications on normal desktops under normal
>workloads, and not about tbench throughput.
>
>Regards,
>Con
And for that it is doing a very good job for me, thanks Con.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
Enzymes are things invented by biologists that explain things which
otherwise require harder thinking.
-- Jerome Lettvin
^ permalink raw reply
* Re: [PATCH 02/15] ATA : vortex86 : fix vortex86dx/sx hardware CRC bug.
From: Alan Cox @ 2011-11-01 1:02 UTC (permalink / raw)
To: Paul Schilling
Cc: Jeff Garzik, David S. Miller, Jesse Barnes, linux-ide,
linux-kernel, linux-pci
In-Reply-To: <CAC=G6sz=PkDoODYh4beT_eRhkm+ZhUxtLnrBXPPuFJW3n+6Vcg@mail.gmail.com>
On Mon, 31 Oct 2011 14:07:45 -0500
Paul Schilling <paul.s.schilling@gmail.com> wrote:
> Hi,
>
> When I developed this patch for the Vortex86dx. I recall trying many
> combinations of udma and mwdma. At the time I developed it, I came
> to the conclusion that both udma and mwdma both failed with CRC
> errors being reported.
MWDMA does not have a CRC so that seems unlikely. If you can re-test and
we can figure out what is going on that would be useful.
Alan
^ permalink raw reply
* [PATCH v2 3/3] ARM: Exynos4: Enable conversion of GIC dt irq specifier to linux virq
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: devicetree-discuss
Cc: linux-samsung-soc, grant.likely, rob.herring, arnd, kgene.kim,
linux-arm-kernel, Thomas Abraham
In-Reply-To: <1320109289-2730-1-git-send-email-thomas.abraham@linaro.org>
Enable conversion of device tree interrupt specifier to linux virq domain
for GIC controller.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/cpu.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 358624d..c06dd03 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,8 @@
#include <linux/sched.h>
#include <linux/sysdev.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
#include <asm/mach/map.h>
#include <asm/mach/irq.h>
@@ -229,13 +231,26 @@ static void exynos4_gic_irq_fix_base(struct irq_data *d)
(gic_bank_offset * smp_processor_id());
}
+#ifdef CONFIG_OF
+static const struct of_device_id exynos4_dt_irq_match[] = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ {},
+};
+#endif
+
void __init exynos4_init_irq(void)
{
int irq;
gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
- gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
+ if (!of_have_populated_dt())
+ gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
+#ifdef CONFIG_OF
+ else
+ of_irq_init(exynos4_dt_irq_match);
+#endif
+
gic_arch_extn.irq_eoi = exynos4_gic_irq_fix_base;
gic_arch_extn.irq_unmask = exynos4_gic_irq_fix_base;
gic_arch_extn.irq_mask = exynos4_gic_irq_fix_base;
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: Exynos4: Add ioremap interceptor for statically remapped regions
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: devicetree-discuss
Cc: linux-samsung-soc, grant.likely, rob.herring, arnd, kgene.kim,
linux-arm-kernel, Thomas Abraham
In-Reply-To: <1320109289-2730-1-git-send-email-thomas.abraham@linaro.org>
ioremap() request for statically remapped regions are intercepted and the
statically assigned virtual address is returned. For requests for which
there are no statically remapped regions, the requests are let through.
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/cpu.c | 16 ++++++++++++++++
arch/arm/mach-exynos4/include/mach/io.h | 5 +++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 5b1765b..358624d 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -137,6 +137,22 @@ static struct map_desc exynos4_iodesc1[] __initdata = {
},
};
+/*
+ * For all ioremap requests of statically mapped regions, intercept ioremap and
+ * return virtual address from the iodesc table.
+ */
+void __iomem *exynos4_ioremap(unsigned long phy, size_t size, unsigned int type)
+{
+ struct map_desc *desc = exynos4_iodesc;
+ unsigned int idx;
+
+ for (idx = 0; idx < ARRAY_SIZE(exynos4_iodesc); idx++, desc++)
+ if (desc->pfn == __phys_to_pfn(phy) && desc->type == type)
+ return (void __iomem *)desc->virtual;
+
+ return __arm_ioremap(phy, size, type);
+}
+
static void exynos4_idle(void)
{
if (!need_resched())
diff --git a/arch/arm/mach-exynos4/include/mach/io.h b/arch/arm/mach-exynos4/include/mach/io.h
index d5478d2..c1b21d5 100644
--- a/arch/arm/mach-exynos4/include/mach/io.h
+++ b/arch/arm/mach-exynos4/include/mach/io.h
@@ -22,5 +22,10 @@
#define __mem_pci(a) (a)
#define IO_SPACE_LIMIT (0xFFFFFFFF)
+#define __arch_ioremap exynos4_ioremap
+#define __arch_iounmap __iounmap
+
+void __iomem *exynos4_ioremap(unsigned long phy, size_t size,
+ unsigned int type);
#endif /* __ASM_ARM_ARCH_IO_H */
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2 1/3] ARM: Exynos4: Move timer irq numbers to end of linux irq space
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: devicetree-discuss
Cc: linux-samsung-soc, grant.likely, rob.herring, arnd, kgene.kim,
linux-arm-kernel, Thomas Abraham
In-Reply-To: <1320109289-2730-1-git-send-email-thomas.abraham@linaro.org>
The timer irqs statically mapped from linux irq numbers 11 to 15 are moved to
the end of the statically mapped linux irq space. The GIC PPI and SPI interrupts
are relocated to start from 16 and 32 of the linux irq space. This is a required
to add device tree support for GIC and Interrupt combiner for Exynos4.
A new macro 'IRQ_TIMER_BASE' specifies a platform specific base of the linux
virq number for the timer interrupts. For exynos4, this base is set to end of
the linux virq space. For the other s5p platforms, the existing base '11' is
retained.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/include/mach/entry-macro.S | 1 -
arch/arm/mach-exynos4/include/mach/irqs.h | 8 +++++---
arch/arm/mach-s5p64x0/include/mach/irqs.h | 2 ++
arch/arm/mach-s5pc100/include/mach/irqs.h | 2 ++
arch/arm/mach-s5pv210/include/mach/irqs.h | 2 ++
arch/arm/plat-samsung/include/plat/irqs.h | 3 ++-
6 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/entry-macro.S b/arch/arm/mach-exynos4/include/mach/entry-macro.S
index f5e9fd8..d7dfcd7 100644
--- a/arch/arm/mach-exynos4/include/mach/entry-macro.S
+++ b/arch/arm/mach-exynos4/include/mach/entry-macro.S
@@ -72,7 +72,6 @@
cmpcc \irqnr, \irqnr
cmpne \irqnr, \tmp
cmpcs \irqnr, \irqnr
- addne \irqnr, \irqnr, #32
.endm
diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach-exynos4/include/mach/irqs.h
index dfd4b7e..713dd52 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -17,13 +17,13 @@
/* PPI: Private Peripheral Interrupt */
-#define IRQ_PPI(x) S5P_IRQ(x+16)
+#define IRQ_PPI(x) (x+16)
#define IRQ_MCT_LOCALTIMER IRQ_PPI(12)
/* SPI: Shared Peripheral Interrupt */
-#define IRQ_SPI(x) S5P_IRQ(x+32)
+#define IRQ_SPI(x) (x+32)
#define IRQ_EINT0 IRQ_SPI(16)
#define IRQ_EINT1 IRQ_SPI(17)
@@ -163,7 +163,9 @@
#define IRQ_GPIO2_NR_GROUPS 9
#define IRQ_GPIO_END (S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)
+#define IRQ_TIMER_BASE (IRQ_GPIO_END + 64)
+
/* Set the default NR_IRQS */
-#define NR_IRQS (IRQ_GPIO_END + 64)
+#define NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
#endif /* __ASM_ARCH_IRQS_H */
diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach-s5p64x0/include/mach/irqs.h
index 53982db..5b845e8 100644
--- a/arch/arm/mach-s5p64x0/include/mach/irqs.h
+++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h
@@ -141,6 +141,8 @@
#define IRQ_EINT_GROUP(grp, x) (IRQ_EINT_GROUP##grp##_BASE + (x))
+#define IRQ_TIMER_BASE (11)
+
/* Set the default NR_IRQS */
#define NR_IRQS (IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1)
diff --git a/arch/arm/mach-s5pc100/include/mach/irqs.h b/arch/arm/mach-s5pc100/include/mach/irqs.h
index d2eb475..2870f12 100644
--- a/arch/arm/mach-s5pc100/include/mach/irqs.h
+++ b/arch/arm/mach-s5pc100/include/mach/irqs.h
@@ -97,6 +97,8 @@
#define IRQ_SDMFIQ S5P_IRQ_VIC2(31)
#define IRQ_VIC_END S5P_IRQ_VIC2(31)
+#define IRQ_TIMER_BASE (11)
+
#define S5P_EINT_BASE1 (S5P_IRQ_VIC0(0))
#define S5P_EINT_BASE2 (IRQ_VIC_END + 1)
diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach-s5pv210/include/mach/irqs.h
index 5e0de3a..e777e01 100644
--- a/arch/arm/mach-s5pv210/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv210/include/mach/irqs.h
@@ -118,6 +118,8 @@
#define IRQ_MDNIE3 S5P_IRQ_VIC3(8)
#define IRQ_VIC_END S5P_IRQ_VIC3(31)
+#define IRQ_TIMER_BASE (11)
+
#define S5P_EINT_BASE1 (S5P_IRQ_VIC0(0))
#define S5P_EINT_BASE2 (IRQ_VIC_END + 1)
diff --git a/arch/arm/plat-samsung/include/plat/irqs.h b/arch/arm/plat-samsung/include/plat/irqs.h
index 08d1a7e..df46b77 100644
--- a/arch/arm/plat-samsung/include/plat/irqs.h
+++ b/arch/arm/plat-samsung/include/plat/irqs.h
@@ -44,13 +44,14 @@
#define S5P_IRQ_VIC2(x) (S5P_VIC2_BASE + (x))
#define S5P_IRQ_VIC3(x) (S5P_VIC3_BASE + (x))
-#define S5P_TIMER_IRQ(x) (11 + (x))
+#define S5P_TIMER_IRQ(x) (IRQ_TIMER_BASE + (x))
#define IRQ_TIMER0 S5P_TIMER_IRQ(0)
#define IRQ_TIMER1 S5P_TIMER_IRQ(1)
#define IRQ_TIMER2 S5P_TIMER_IRQ(2)
#define IRQ_TIMER3 S5P_TIMER_IRQ(3)
#define IRQ_TIMER4 S5P_TIMER_IRQ(4)
+#define IRQ_TIMER_COUNT (5)
#define IRQ_EINT(x) ((x) < 16 ? ((x) + S5P_EINT_BASE1) \
: ((x) - 16 + S5P_EINT_BASE2))
--
1.7.4.4
^ permalink raw reply related
* ARM: Exynos4: Enable device tree support for GIC controller
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: devicetree-discuss
Cc: linux-samsung-soc, grant.likely, rob.herring, arnd, kgene.kim,
linux-arm-kernel
Changes since v1:
- Dropped device tree support for interrupt combiner controller from this patchset.
Some rework in the interrupt combiner controller code is required to address
the irq domain related comments from Grant Likely and hence those changes will
be in another patchset.
- As suggested by Grant Likely, linux virq number 0 is left unused.
This patchset adds device tree support for GIC controller in Exynos4 SoC.
Patch 1 moves the statically mapped timer irqs 11 to 15 to the end of the
statically mapped linux irq space for Exynos4 platforms.
For Exynos4 platforms, the five hardware timer irqs are connected to GIC
at some hardware irq number (in exynos it is GIC_ID 69 to 73 for five timers).
When any of these hardware interrupt occurs, its interrupt handler calls
generic_handle_irq() with linux irq number 11/12/13/14/15 for timer 0/1/2/3/4
as the parameter. The code that needs to be notified about the timer interrupts
would have already registered its handler for either of the interrupts 11 to 15.
Instead of using linux irq number 11 to 15 to which consumers of timer interrupt
attach their handler, this interrupt range is moved to the end of linux irq
space used. So there will be no interrupts statically mapped between 0 to 31.
The GIC hardware interrupts, which were previously statically mapped to
start from linux irq 32 are now moved to start from linux irq 0. In case of
exynos, GIC_ID[0] (which is SGI[0]) which was previously at linux irq 32, will
not be at linux irq 0. This was required to use Rob Herring's GIC OF bindings
patches for Exynos4.
Patch 2 adds a interceptor for all ioremap calls targeted towards any of the
statically remapped memory region. This was required because the GIC OF
binding's patchset ioremaps the GIC memory-mapped regions in the gic_of_init()
function. Without this patch, there would be two separate remap for GIC
controller, one statically remapped and the other dynamically remapped by the
gic_of_init() function. The patch will eventually be superseded by Nicolas
Pitre's vmalloc patch series.
Patch 3 adds device tree support for GIC controllers on Exynos4. For GIC
controller, this patch is based on Rob Herring's,
"[PATCH 0/3] GIC OF bindings" patchset.
This patchset is based on the following tree:
git://git.linaro.org/git/people/arnd/arm-soc.git branch: for-next
Thomas Abraham (3):
ARM: Exynos4: Move timer irq numbers to end of linux irq space
ARM: Exynos4: Add ioremap interceptor for statically remapped regions
ARM: Exynos4: Enable conversion of GIC dt irq specifier to linux virq
arch/arm/mach-exynos4/cpu.c | 33 +++++++++++++++++++++-
arch/arm/mach-exynos4/include/mach/entry-macro.S | 1 -
arch/arm/mach-exynos4/include/mach/io.h | 5 +++
arch/arm/mach-exynos4/include/mach/irqs.h | 8 +++--
arch/arm/mach-s5p64x0/include/mach/irqs.h | 2 +
arch/arm/mach-s5pc100/include/mach/irqs.h | 2 +
arch/arm/mach-s5pv210/include/mach/irqs.h | 2 +
arch/arm/plat-samsung/include/plat/irqs.h | 3 +-
8 files changed, 50 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH v2 3/3] ARM: Exynos4: Enable conversion of GIC dt irq specifier to linux virq
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320109289-2730-1-git-send-email-thomas.abraham@linaro.org>
Enable conversion of device tree interrupt specifier to linux virq domain
for GIC controller.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/cpu.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 358624d..c06dd03 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,8 @@
#include <linux/sched.h>
#include <linux/sysdev.h>
+#include <linux/of.h>
+#include <linux/of_irq.h>
#include <asm/mach/map.h>
#include <asm/mach/irq.h>
@@ -229,13 +231,26 @@ static void exynos4_gic_irq_fix_base(struct irq_data *d)
(gic_bank_offset * smp_processor_id());
}
+#ifdef CONFIG_OF
+static const struct of_device_id exynos4_dt_irq_match[] = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ {},
+};
+#endif
+
void __init exynos4_init_irq(void)
{
int irq;
gic_bank_offset = soc_is_exynos4412() ? 0x4000 : 0x8000;
- gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
+ if (!of_have_populated_dt())
+ gic_init(0, IRQ_PPI(0), S5P_VA_GIC_DIST, S5P_VA_GIC_CPU);
+#ifdef CONFIG_OF
+ else
+ of_irq_init(exynos4_dt_irq_match);
+#endif
+
gic_arch_extn.irq_eoi = exynos4_gic_irq_fix_base;
gic_arch_extn.irq_unmask = exynos4_gic_irq_fix_base;
gic_arch_extn.irq_mask = exynos4_gic_irq_fix_base;
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2 2/3] ARM: Exynos4: Add ioremap interceptor for statically remapped regions
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320109289-2730-1-git-send-email-thomas.abraham@linaro.org>
ioremap() request for statically remapped regions are intercepted and the
statically assigned virtual address is returned. For requests for which
there are no statically remapped regions, the requests are let through.
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/cpu.c | 16 ++++++++++++++++
arch/arm/mach-exynos4/include/mach/io.h | 5 +++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 5b1765b..358624d 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -137,6 +137,22 @@ static struct map_desc exynos4_iodesc1[] __initdata = {
},
};
+/*
+ * For all ioremap requests of statically mapped regions, intercept ioremap and
+ * return virtual address from the iodesc table.
+ */
+void __iomem *exynos4_ioremap(unsigned long phy, size_t size, unsigned int type)
+{
+ struct map_desc *desc = exynos4_iodesc;
+ unsigned int idx;
+
+ for (idx = 0; idx < ARRAY_SIZE(exynos4_iodesc); idx++, desc++)
+ if (desc->pfn == __phys_to_pfn(phy) && desc->type == type)
+ return (void __iomem *)desc->virtual;
+
+ return __arm_ioremap(phy, size, type);
+}
+
static void exynos4_idle(void)
{
if (!need_resched())
diff --git a/arch/arm/mach-exynos4/include/mach/io.h b/arch/arm/mach-exynos4/include/mach/io.h
index d5478d2..c1b21d5 100644
--- a/arch/arm/mach-exynos4/include/mach/io.h
+++ b/arch/arm/mach-exynos4/include/mach/io.h
@@ -22,5 +22,10 @@
#define __mem_pci(a) (a)
#define IO_SPACE_LIMIT (0xFFFFFFFF)
+#define __arch_ioremap exynos4_ioremap
+#define __arch_iounmap __iounmap
+
+void __iomem *exynos4_ioremap(unsigned long phy, size_t size,
+ unsigned int type);
#endif /* __ASM_ARM_ARCH_IO_H */
--
1.7.4.4
^ permalink raw reply related
* [PATCH v2 1/3] ARM: Exynos4: Move timer irq numbers to end of linux irq space
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320109289-2730-1-git-send-email-thomas.abraham@linaro.org>
The timer irqs statically mapped from linux irq numbers 11 to 15 are moved to
the end of the statically mapped linux irq space. The GIC PPI and SPI interrupts
are relocated to start from 16 and 32 of the linux irq space. This is a required
to add device tree support for GIC and Interrupt combiner for Exynos4.
A new macro 'IRQ_TIMER_BASE' specifies a platform specific base of the linux
virq number for the timer interrupts. For exynos4, this base is set to end of
the linux virq space. For the other s5p platforms, the existing base '11' is
retained.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
---
arch/arm/mach-exynos4/include/mach/entry-macro.S | 1 -
arch/arm/mach-exynos4/include/mach/irqs.h | 8 +++++---
arch/arm/mach-s5p64x0/include/mach/irqs.h | 2 ++
arch/arm/mach-s5pc100/include/mach/irqs.h | 2 ++
arch/arm/mach-s5pv210/include/mach/irqs.h | 2 ++
arch/arm/plat-samsung/include/plat/irqs.h | 3 ++-
6 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos4/include/mach/entry-macro.S b/arch/arm/mach-exynos4/include/mach/entry-macro.S
index f5e9fd8..d7dfcd7 100644
--- a/arch/arm/mach-exynos4/include/mach/entry-macro.S
+++ b/arch/arm/mach-exynos4/include/mach/entry-macro.S
@@ -72,7 +72,6 @@
cmpcc \irqnr, \irqnr
cmpne \irqnr, \tmp
cmpcs \irqnr, \irqnr
- addne \irqnr, \irqnr, #32
.endm
diff --git a/arch/arm/mach-exynos4/include/mach/irqs.h b/arch/arm/mach-exynos4/include/mach/irqs.h
index dfd4b7e..713dd52 100644
--- a/arch/arm/mach-exynos4/include/mach/irqs.h
+++ b/arch/arm/mach-exynos4/include/mach/irqs.h
@@ -17,13 +17,13 @@
/* PPI: Private Peripheral Interrupt */
-#define IRQ_PPI(x) S5P_IRQ(x+16)
+#define IRQ_PPI(x) (x+16)
#define IRQ_MCT_LOCALTIMER IRQ_PPI(12)
/* SPI: Shared Peripheral Interrupt */
-#define IRQ_SPI(x) S5P_IRQ(x+32)
+#define IRQ_SPI(x) (x+32)
#define IRQ_EINT0 IRQ_SPI(16)
#define IRQ_EINT1 IRQ_SPI(17)
@@ -163,7 +163,9 @@
#define IRQ_GPIO2_NR_GROUPS 9
#define IRQ_GPIO_END (S5P_GPIOINT_BASE + S5P_GPIOINT_COUNT)
+#define IRQ_TIMER_BASE (IRQ_GPIO_END + 64)
+
/* Set the default NR_IRQS */
-#define NR_IRQS (IRQ_GPIO_END + 64)
+#define NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT)
#endif /* __ASM_ARCH_IRQS_H */
diff --git a/arch/arm/mach-s5p64x0/include/mach/irqs.h b/arch/arm/mach-s5p64x0/include/mach/irqs.h
index 53982db..5b845e8 100644
--- a/arch/arm/mach-s5p64x0/include/mach/irqs.h
+++ b/arch/arm/mach-s5p64x0/include/mach/irqs.h
@@ -141,6 +141,8 @@
#define IRQ_EINT_GROUP(grp, x) (IRQ_EINT_GROUP##grp##_BASE + (x))
+#define IRQ_TIMER_BASE (11)
+
/* Set the default NR_IRQS */
#define NR_IRQS (IRQ_EINT_GROUP8_BASE + IRQ_EINT_GROUP8_NR + 1)
diff --git a/arch/arm/mach-s5pc100/include/mach/irqs.h b/arch/arm/mach-s5pc100/include/mach/irqs.h
index d2eb475..2870f12 100644
--- a/arch/arm/mach-s5pc100/include/mach/irqs.h
+++ b/arch/arm/mach-s5pc100/include/mach/irqs.h
@@ -97,6 +97,8 @@
#define IRQ_SDMFIQ S5P_IRQ_VIC2(31)
#define IRQ_VIC_END S5P_IRQ_VIC2(31)
+#define IRQ_TIMER_BASE (11)
+
#define S5P_EINT_BASE1 (S5P_IRQ_VIC0(0))
#define S5P_EINT_BASE2 (IRQ_VIC_END + 1)
diff --git a/arch/arm/mach-s5pv210/include/mach/irqs.h b/arch/arm/mach-s5pv210/include/mach/irqs.h
index 5e0de3a..e777e01 100644
--- a/arch/arm/mach-s5pv210/include/mach/irqs.h
+++ b/arch/arm/mach-s5pv210/include/mach/irqs.h
@@ -118,6 +118,8 @@
#define IRQ_MDNIE3 S5P_IRQ_VIC3(8)
#define IRQ_VIC_END S5P_IRQ_VIC3(31)
+#define IRQ_TIMER_BASE (11)
+
#define S5P_EINT_BASE1 (S5P_IRQ_VIC0(0))
#define S5P_EINT_BASE2 (IRQ_VIC_END + 1)
diff --git a/arch/arm/plat-samsung/include/plat/irqs.h b/arch/arm/plat-samsung/include/plat/irqs.h
index 08d1a7e..df46b77 100644
--- a/arch/arm/plat-samsung/include/plat/irqs.h
+++ b/arch/arm/plat-samsung/include/plat/irqs.h
@@ -44,13 +44,14 @@
#define S5P_IRQ_VIC2(x) (S5P_VIC2_BASE + (x))
#define S5P_IRQ_VIC3(x) (S5P_VIC3_BASE + (x))
-#define S5P_TIMER_IRQ(x) (11 + (x))
+#define S5P_TIMER_IRQ(x) (IRQ_TIMER_BASE + (x))
#define IRQ_TIMER0 S5P_TIMER_IRQ(0)
#define IRQ_TIMER1 S5P_TIMER_IRQ(1)
#define IRQ_TIMER2 S5P_TIMER_IRQ(2)
#define IRQ_TIMER3 S5P_TIMER_IRQ(3)
#define IRQ_TIMER4 S5P_TIMER_IRQ(4)
+#define IRQ_TIMER_COUNT (5)
#define IRQ_EINT(x) ((x) < 16 ? ((x) + S5P_EINT_BASE1) \
: ((x) - 16 + S5P_EINT_BASE2))
--
1.7.4.4
^ permalink raw reply related
* ARM: Exynos4: Enable device tree support for GIC controller
From: Thomas Abraham @ 2011-11-01 1:01 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v1:
- Dropped device tree support for interrupt combiner controller from this patchset.
Some rework in the interrupt combiner controller code is required to address
the irq domain related comments from Grant Likely and hence those changes will
be in another patchset.
- As suggested by Grant Likely, linux virq number 0 is left unused.
This patchset adds device tree support for GIC controller in Exynos4 SoC.
Patch 1 moves the statically mapped timer irqs 11 to 15 to the end of the
statically mapped linux irq space for Exynos4 platforms.
For Exynos4 platforms, the five hardware timer irqs are connected to GIC
at some hardware irq number (in exynos it is GIC_ID 69 to 73 for five timers).
When any of these hardware interrupt occurs, its interrupt handler calls
generic_handle_irq() with linux irq number 11/12/13/14/15 for timer 0/1/2/3/4
as the parameter. The code that needs to be notified about the timer interrupts
would have already registered its handler for either of the interrupts 11 to 15.
Instead of using linux irq number 11 to 15 to which consumers of timer interrupt
attach their handler, this interrupt range is moved to the end of linux irq
space used. So there will be no interrupts statically mapped between 0 to 31.
The GIC hardware interrupts, which were previously statically mapped to
start from linux irq 32 are now moved to start from linux irq 0. In case of
exynos, GIC_ID[0] (which is SGI[0]) which was previously at linux irq 32, will
not be at linux irq 0. This was required to use Rob Herring's GIC OF bindings
patches for Exynos4.
Patch 2 adds a interceptor for all ioremap calls targeted towards any of the
statically remapped memory region. This was required because the GIC OF
binding's patchset ioremaps the GIC memory-mapped regions in the gic_of_init()
function. Without this patch, there would be two separate remap for GIC
controller, one statically remapped and the other dynamically remapped by the
gic_of_init() function. The patch will eventually be superseded by Nicolas
Pitre's vmalloc patch series.
Patch 3 adds device tree support for GIC controllers on Exynos4. For GIC
controller, this patch is based on Rob Herring's,
"[PATCH 0/3] GIC OF bindings" patchset.
This patchset is based on the following tree:
git://git.linaro.org/git/people/arnd/arm-soc.git branch: for-next
Thomas Abraham (3):
ARM: Exynos4: Move timer irq numbers to end of linux irq space
ARM: Exynos4: Add ioremap interceptor for statically remapped regions
ARM: Exynos4: Enable conversion of GIC dt irq specifier to linux virq
arch/arm/mach-exynos4/cpu.c | 33 +++++++++++++++++++++-
arch/arm/mach-exynos4/include/mach/entry-macro.S | 1 -
arch/arm/mach-exynos4/include/mach/io.h | 5 +++
arch/arm/mach-exynos4/include/mach/irqs.h | 8 +++--
arch/arm/mach-s5p64x0/include/mach/irqs.h | 2 +
arch/arm/mach-s5pc100/include/mach/irqs.h | 2 +
arch/arm/mach-s5pv210/include/mach/irqs.h | 2 +
arch/arm/plat-samsung/include/plat/irqs.h | 3 +-
8 files changed, 50 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: bigalloc and max file size
From: Coly Li @ 2011-11-01 1:10 UTC (permalink / raw)
To: Ted Ts'o
Cc: Andreas Dilger, Andreas Dilger, linux-ext4 development,
Alex Zhuravlev, Tao Ma, hao.bigrat@gmail.com
In-Reply-To: <20111031193837.GH16825@thunk.org>
On 2011年11月01日 03:38, Ted Ts'o Wrote:
> On Tue, Nov 01, 2011 at 01:39:34AM +0800, Coly Li wrote:
>> In some application, we allocate a big file which occupies most space of a file system, while the file system built on
>> (expensive) SSD. In such configuration, we want less blocks allocated for inode table and bitmap. If the max extent
>> length could be much big, there is chance to have much less block groups, which results more blocks for regular file.
>> Current bigalloc code does well already, but there is still chance to do better. The sys-admin team believe
>> cluster-based-extent can help Ext4 to consume as less meta data memory as raw disk does, and gain as more available data
>> blocks as raw disks does, too. This is a small number on one single SSD, but in our cluster environment, this effort can
>> help to save a recognized amount of capex.
>
> OK, but you're not running into the 16TB file size limitation, are
> you?
No, we are not in this problem.
> That would be a lot of SSD's.
Yes, IMHO that's a lot of SSDs.
>I assume the issue then is you
> want to minimize the number of extents, limited by the 15-bit extent
> length field?
Not only extents, but also minimize inode table blocks, bitmap blocks.
>
> What cluster size are you thinking about?
Currently we test 1MB cluster size. The extreme ideal configuration (of one use case) is, there is only one block group
on the whole file system. (In this use case) we are willing to try biggest possible cluster size if we are able to.
And how do you plan to
> initialize it? Via fallocate, or by explicitly writing zeros to the
> whole file (so all of the blocks are marked as initialzied? Is it
> going to be sparse file?
In the above application I mentioned, the file is allocated by fallocate(2). Writing to the file is appending write with
8MB length, when writing reaches file end, it goes back to the beginning of the file and continue to write.
Thanks.
--
Coly Li
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* linux-next: build failure after merge of the crypto-current tree
From: Stephen Rothwell @ 2011-11-01 0:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
Hi Herbert,
After merging the crypto-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
GEN /scratch/sfr/x86_64_allmodconfig/Makefile
scripts/kconfig/conf --allmodconfig Kconfig
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5: symbol NET is selected by CRYPTO_USER
crypto/Kconfig:103: symbol CRYPTO_USER depends on CRYPTO
crypto/Kconfig:15: symbol CRYPTO is selected by BT
net/bluetooth/Kconfig:5: symbol BT depends on NET
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)
#
# configuration written to .config
#
WITHOUT_DISTCC:
ARCH=x86_64
CCVER=4.6
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5: symbol NET is selected by CRYPTO_USER
crypto/Kconfig:103: symbol CRYPTO_USER depends on CRYPTO
crypto/Kconfig:15: symbol CRYPTO is selected by BT
net/bluetooth/Kconfig:5: symbol BT depends on NET
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)
*
* Restart config...
*
*
* Security options
*
Enable access key retention support (KEYS) [Y/n/?] y
TRUSTED KEYS (TRUSTED_KEYS) [M/n/?] m
ENCRYPTED KEYS (ENCRYPTED_KEYS) [M/n/y/?] m
Enable the /proc/keys file by which keys may be viewed (KEYS_DEBUG_PROC_KEYS) [Y/n/?] y
Restrict unprivileged access to the kernel syslog (SECURITY_DMESG_RESTRICT) [Y/n/?] y
Enable different security models (SECURITY) [N/y/?] (NEW) aborted!
Console input/output is redirected. Run 'make oldconfig' to update configuration.
Presumbly caused by commit ea8bdfcff175 ("crypto: user - Add dependency
on NET").
I have used the crypto-current tree from next-20111025 for today (i.e. that
commit has not been added to linux-next today).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the crypto-current tree
From: Stephen Rothwell @ 2011-11-01 0:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
Hi Herbert,
After merging the crypto-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
GEN /scratch/sfr/x86_64_allmodconfig/Makefile
scripts/kconfig/conf --allmodconfig Kconfig
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5: symbol NET is selected by CRYPTO_USER
crypto/Kconfig:103: symbol CRYPTO_USER depends on CRYPTO
crypto/Kconfig:15: symbol CRYPTO is selected by BT
net/bluetooth/Kconfig:5: symbol BT depends on NET
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)
#
# configuration written to .config
#
WITHOUT_DISTCC:
ARCH=x86_64
CCVER=4.6
net/Kconfig:5:error: recursive dependency detected!
net/Kconfig:5: symbol NET is selected by CRYPTO_USER
crypto/Kconfig:103: symbol CRYPTO_USER depends on CRYPTO
crypto/Kconfig:15: symbol CRYPTO is selected by BT
net/bluetooth/Kconfig:5: symbol BT depends on NET
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET)
warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET)
*
* Restart config...
*
*
* Security options
*
Enable access key retention support (KEYS) [Y/n/?] y
TRUSTED KEYS (TRUSTED_KEYS) [M/n/?] m
ENCRYPTED KEYS (ENCRYPTED_KEYS) [M/n/y/?] m
Enable the /proc/keys file by which keys may be viewed (KEYS_DEBUG_PROC_KEYS) [Y/n/?] y
Restrict unprivileged access to the kernel syslog (SECURITY_DMESG_RESTRICT) [Y/n/?] y
Enable different security models (SECURITY) [N/y/?] (NEW) aborted!
Console input/output is redirected. Run 'make oldconfig' to update configuration.
Presumbly caused by commit ea8bdfcff175 ("crypto: user - Add dependency
on NET").
I have used the crypto-current tree from next-20111025 for today (i.e. that
commit has not been added to linux-next today).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Please pull bjdooks' for-linus/i2c-3.2 branch
From: Ben Dooks @ 2011-11-01 0:58 UTC (permalink / raw)
To: ben-elnMNo+KYs3YtjvyW6yDsg,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
The following changes since commit 1fdb24e969110fafea36d3b393bea438f702c87f:
Merge branch 'devel-stable' of http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm (2011-10-28 12:02:27 -0700)
are available in the git repository at:
git://git.fluff.org/bjdooks/linux.git for-linus/i2c-3.2
Andy Green (12):
I2C: OMAP2+: Name registers in I2C IP V2 only accordingly
I2C: OMAP: add rev to omap i2c platform data
I2C: OMAP1: set IP revision in platform data
I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus added
I2C: OMAP2+: use platform_data ip revision to select register map
I2C: OMAP2+: Solve array bounds overflow error on i2c idle
I2C: OMAP2+: address confused probed version naming
I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data
I2C: OMAP2+: Pass flags up to omap i2c platform_data as well
I2C: OMAP1: set i2c unit feature implementation flags in platform data
I2C: OMAP2+: Convert omap I2C driver to use feature implementation flags from platform data
I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in dev_info
Ben Dooks (3):
Merge branches 'for-32/i2c/omap-v4', 'for-32/i2c/imx-dt', 'for-32/i2c/eg20t-v4', 'for-32/i2c/designware-v5' and 'for-32/i2c/au1550' into for-linus/i2c-3.2
Merge branch 'for-32/i2c/irqflags' into for-linus/i2c-3.2
Merge branches 'for-32/i2c/nomadik', 'for-32/i2c/s3c2410-dt' and 'for-32/i2c/tegra-iomem' into for-linus/i2c-3.2
Dirk Brandewie (9):
i2c-designware: Move checking of IP core version to i2c_dw_init()
i2c-designware: split of i2c-designware.c into core and bus specific parts
i2c-designware: Move retriveving the clock speed out of core code.
i2c-designware: move i2c functionality bit field to be adapter specific
i2c-designware: move controller config to bus specific portion of driver
i2c-designware: Support multiple cores using same ISR
i2c-designware: Push all register reads/writes into the core code.
i2c-designware: Add support for Designware core behind PCI devices.
i2c-designware: Add runtime power management support
Jean-Hugues Deschenes (3):
i2c-designware: Use local version of readl & writel
i2c-designware: Check component type register
i2c-designware: Allow mixed endianness accesses
Jonas Aaberg (1):
i2c-nomadik: cosmetic coding style corrections
Kevin Hilman (3):
I2C: OMAP: remove unneccesary use of pdev
I2C: OMAP: remove dev->idle, use usage counting provided by runtime PM
I2C: OMAP: remove unused function pointers from pdata
Manuel Lauss (4):
i2c-au1550: remove usage of volatile keyword
i2c-au1550: remove unused ack_timeout
i2c-au1550: increase timeout waiting for master done
i2c-au1550: dev_pm_ops conversion
Octavian Purdila (1):
i2c-designware: Fix PCI core warning on suspend/resume
Olof Johansson (1):
i2c-tegra: __iomem annotation fix
Shawn Guo (2):
i2c-imx: remove init/exit hooks from platform data
i2c-imx: add device tree probe support
Shubhrajyoti D (1):
OMAP4: I2C: Enable the wakeup in I2C_WE
Thomas Abraham (2):
i2c-s3c2410: Keep a copy of platform data and use it
i2c-s3c2410: Add device tree support
Tomoya MORINAGA (7):
i2c-eg20t: Fix bus-idle waiting issue
i2c-eg20t: Modify returned value s32 to long
i2c-eg20t: Fix 10bit access issue
i2c-eg20t: Separate error processing
i2c-eg20t: add stop sequence in case wait-event timeout occurs
i2c-eg20t: Fix flag setting issue
i2c-eg20t: Add initialize processing in case i2c-error occurs
Yong Zhang (1):
i2c: irq: Remove IRQF_DISABLED
.../devicetree/bindings/i2c/fsl-imx-i2c.txt | 25 ++
.../devicetree/bindings/i2c/samsung-i2c.txt | 39 ++
arch/arm/plat-mxc/include/mach/i2c.h | 4 -
arch/arm/plat-omap/i2c.c | 27 ++
arch/mips/include/asm/mach-au1x00/au1xxx_psc.h | 13 -
drivers/i2c/busses/Kconfig | 16 +-
drivers/i2c/busses/Makefile | 5 +-
drivers/i2c/busses/i2c-au1550.c | 280 ++++++---------
drivers/i2c/busses/i2c-bfin-twi.c | 4 +-
.../{i2c-designware.c => i2c-designware-core.c} | 382 ++++++-------------
drivers/i2c/busses/i2c-designware-core.h | 105 ++++++
drivers/i2c/busses/i2c-designware-pcidrv.c | 392 ++++++++++++++++++++
drivers/i2c/busses/i2c-designware-platdrv.c | 215 +++++++++++
drivers/i2c/busses/i2c-eg20t.c | 270 ++++++++++----
drivers/i2c/busses/i2c-highlander.c | 2 +-
drivers/i2c/busses/i2c-imx.c | 46 ++--
drivers/i2c/busses/i2c-nomadik.c | 91 +++---
drivers/i2c/busses/i2c-nuc900.c | 2 +-
drivers/i2c/busses/i2c-omap.c | 164 +++++----
drivers/i2c/busses/i2c-pmcmsp.c | 2 +-
drivers/i2c/busses/i2c-s3c2410.c | 130 ++++++-
drivers/i2c/busses/i2c-sh7760.c | 2 +-
drivers/i2c/busses/i2c-sh_mobile.c | 2 +-
drivers/i2c/busses/i2c-stu300.c | 2 +-
drivers/i2c/busses/i2c-tegra.c | 2 +-
include/linux/i2c-omap.h | 5 +-
26 files changed, 1543 insertions(+), 684 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/fsl-imx-i2c.txt
create mode 100644 Documentation/devicetree/bindings/i2c/samsung-i2c.txt
rename drivers/i2c/busses/{i2c-designware.c => i2c-designware-core.c} (65%)
create mode 100644 drivers/i2c/busses/i2c-designware-core.h
create mode 100644 drivers/i2c/busses/i2c-designware-pcidrv.c
create mode 100644 drivers/i2c/busses/i2c-designware-platdrv.c
^ permalink raw reply
* Re: [PATCH] netbase: follow oe-core update to 4.46
From: Denys Dmytriyenko @ 2011-11-01 0:57 UTC (permalink / raw)
To: Andreas M??ller; +Cc: meta-ti
In-Reply-To: <1320105166-11309-1-git-send-email-schnitzeltony@gmx.de>
On Tue, Nov 01, 2011 at 12:52:46AM +0100, Andreas M??ller wrote:
>
> Signed-off-by: Andreas M??ller <schnitzeltony@gmx.de>
Thanks, applied.
> ---
> .../beagleboard/interfaces | 0
> ...netbase_4.45.bbappend => netbase_4.46.bbappend} | 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename recipes-core/netbase/{netbase-4.45 => netbase-4.46}/beagleboard/interfaces (100%)
> rename recipes-core/netbase/{netbase_4.45.bbappend => netbase_4.46.bbappend} (100%)
>
> diff --git a/recipes-core/netbase/netbase-4.45/beagleboard/interfaces b/recipes-core/netbase/netbase-4.46/beagleboard/interfaces
> similarity index 100%
> rename from recipes-core/netbase/netbase-4.45/beagleboard/interfaces
> rename to recipes-core/netbase/netbase-4.46/beagleboard/interfaces
> diff --git a/recipes-core/netbase/netbase_4.45.bbappend b/recipes-core/netbase/netbase_4.46.bbappend
> similarity index 100%
> rename from recipes-core/netbase/netbase_4.45.bbappend
> rename to recipes-core/netbase/netbase_4.46.bbappend
> --
> 1.7.4.4
>
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti
^ permalink raw reply
* Re: libfdt queries
From: David Gibson @ 2011-11-01 0:55 UTC (permalink / raw)
To: Varun Wadekar; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <4EAE8A74.9020301-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Mon, Oct 31, 2011 at 05:15:56PM +0530, Varun Wadekar wrote:
>
> > That seems a bit unlikely, but maybe. Is there any way you can dump
> > out the dtb after processing by your bootloader?
> >
>
> Found out the root cause. My bootloader was not manipulating the dtb
> blob size properly and hence the final dtb was messed up. This resulted
> in the kernel not finding proper fields inside the dtb.
Ok. You mean you were truncating the blob? Or you were manually
(without libfdt) manipulating the size property somehow and messing
that up?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC PATCH] freezer: revert 27920651fe "PM / Freezer: Make fake_signal_wake_up() wake TASK_KILLABLE tasks too"
From: Tejun Heo @ 2011-11-01 0:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Jeff Layton, Steve French, linux-kernel, Oleg Nesterov, linux-pm,
linux-cifs, J. Bruce Fields, Neil Brown
In-Reply-To: <20111031233059.GI18855@google.com>
Hey, again.
On Mon, Oct 31, 2011 at 04:30:59PM -0700, Tejun Heo wrote:
> I can't remember one off the top of my head but I'm pretty sure there
> at least are few which expect tight inter-locking between sleeps and
> wakeups. I'll look for examples and post reply. ISTR them being
> kernel threads so this might not apply directly but it's still a
> dangerous game to play.
Hmm... I couldn't find KILLABLE used like that but here are two
UNINTERRUPTIBLE sleep examples.
* kthread_start() depends on the fact that a kthread won't be woken up
from UNINTERRUPTIBLE sleep spuriously.
* jfs_flush_journal() doesn't check whether the wakeup was spurious
after waiting if !tblkGC_COMMITTED.
Maybe we can re-define KILLABLE as killable && freezable but IMHO that
requires pretty strong rationales. If at all possible, let's not
diddle with that if it can be worked around some other way.
Thank you.
--
tejun
^ permalink raw reply
* Re: [Qemu-devel] [PULL 0/3] 128-bit support for the memory API
From: David Gibson @ 2011-11-01 0:54 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Blue Swirl, Avi Kivity, qemu-devel
In-Reply-To: <4EAEC75B.6020006@codemonkey.ws>
On Mon, Oct 31, 2011 at 11:05:47AM -0500, Anthony Liguori wrote:
> On 10/30/2011 09:02 AM, Avi Kivity wrote:
> >This somewhat controversial patchset converts internal arithmetic in the
> >memory API to 128 bits.
>
> Given the level of controversy, what do you think about deferring
> this to 1.1?
If it's deferred then one of my rearrangements for the arithmetic must
go in instead. These patches fix real bugs, that bite us on pseries.
It's not the only way to fix those bugs, and probably not even my
personally preferred way to fix them, but they need to be fixed
_somehow_ for 1.0.
>
> Regards,
>
> Anthony Liguori
>
> >
> >It has been argued that with careful coding we can make 64-bit work as
> >well. I don't think this is true in general - a memory router can adjust
> >addresses either forwards or backwards, and some buses (PCIe) need the
> >full 64-bit space - though it's probably the case for all the configurations
> >we support today. Regardless, the need for careful coding means subtle bugs,
> >which I don't want in a core API that is driven by guest supplied values.
> >
> >Avi Kivity (3):
> > Add support for 128-bit arithmetic
> > memory: use 128-bit integers for sizes and intermediates
> > Adjust system and pci address spaces to full 64-bit
> >
> > exec.c | 2 +-
> > hw/pc_piix.c | 2 +-
> > hw/pci_bridge.c | 2 +-
> > int128.h | 116 ++++++++++++++++++++++++++++++++
> > memory.c | 196 ++++++++++++++++++++++++++++++++----------------------
> > memory.h | 3 +-
> > 6 files changed, 237 insertions(+), 84 deletions(-)
> > create mode 100644 int128.h
> >
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [Buildroot] [PATCH 2/2] toolchain: Add the possibility to have a mcpu option with wrapper
From: Stany MARCEL @ 2011-11-01 0:53 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1320108819-2344-1-git-send-email-stanypub@gmail.com>
Permit to define the mcpu of the external toolchain wrapper, based on
BR2_GCC_TARGET_CPU.
Signed-off-by: Stany MARCEL <stanypub@gmail.com>
---
toolchain/toolchain-external/ext-tool.mk | 6 ++++++
.../toolchain-external/ext-toolchain-wrapper.c | 3 +++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/toolchain/toolchain-external/ext-tool.mk b/toolchain/toolchain-external/ext-tool.mk
index 572917f..640db5e 100644
--- a/toolchain/toolchain-external/ext-tool.mk
+++ b/toolchain/toolchain-external/ext-tool.mk
@@ -129,6 +129,8 @@ TOOLCHAIN_EXTERNAL_WRAPPER_ARGS = \
CC_TARGET_TUNE_:=$(call qstrip,$(BR2_GCC_TARGET_TUNE))
CC_TARGET_ARCH_:=$(call qstrip,$(BR2_GCC_TARGET_ARCH))
CC_TARGET_ABI_:=$(call qstrip,$(BR2_GCC_TARGET_ABI))
+CC_TARGET_CPU_:=$(call qstrip,$(BR2_GCC_TARGET_CPU))
+
# march/mtune/floating point mode needs to be passed to the external toolchain
# to select the right multilib variant
@@ -144,6 +146,10 @@ ifneq ($(CC_TARGET_ABI_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mabi=$(CC_TARGET_ABI_)
TOOLCHAIN_EXTERNAL_WRAPPER_ARGS += -DBR_ABI='"$(CC_TARGET_ABI_)"'
endif
+ifneq ($(CC_TARGET_CPU_),)
+TOOLCHAIN_EXTERNAL_CFLAGS += -mcpu=$(CC_TARGET_CPU_)
+TOOLCHAIN_EXTERNAL_WRAPPER_ARGS += -DBR_CPU='"$(CC_TARGET_CPU_)"'
+endif
ifeq ($(BR2_SOFT_FLOAT),y)
TOOLCHAIN_EXTERNAL_CFLAGS += -msoft-float
diff --git a/toolchain/toolchain-external/ext-toolchain-wrapper.c b/toolchain/toolchain-external/ext-toolchain-wrapper.c
index 3e23061..b1a4fcb 100644
--- a/toolchain/toolchain-external/ext-toolchain-wrapper.c
+++ b/toolchain/toolchain-external/ext-toolchain-wrapper.c
@@ -31,6 +31,9 @@ static char *predef_args[] = {
#ifdef BR_ABI
"-mabi=" BR_ABI,
#endif
+#ifdef BR_CPU
+ "-mcpu=" BR_CPU,
+#endif
#ifdef BR_SOFTFLOAT
"-msoft-float",
#endif /* BR_SOFTFLOAT */
--
1.7.1
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] toolchain: Correct test for external tools symlink creation
From: Stany MARCEL @ 2011-11-01 0:53 UTC (permalink / raw)
To: buildroot
When the external tools chain is installed in a path that match one of
the first case test, all symlink are created to the external
wrapper. The proposed solution is to test only the base name not the
full path.
Signed-off-by: Stany MARCEL <stanypub@gmail.com>
---
toolchain/toolchain-external/ext-tool.mk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/toolchain/toolchain-external/ext-tool.mk b/toolchain/toolchain-external/ext-tool.mk
index 8287916..572917f 100644
--- a/toolchain/toolchain-external/ext-tool.mk
+++ b/toolchain/toolchain-external/ext-tool.mk
@@ -318,9 +318,9 @@ $(STAMP_DIR)/ext-toolchain-installed: $(TOOLCHAIN_EXTERNAL_DEPENDENCIES)
$(HOST_DIR)/usr/bin/ext-toolchain-wrapper: $(STAMP_DIR)/ext-toolchain-installed
mkdir -p $(HOST_DIR)/usr/bin; cd $(HOST_DIR)/usr/bin; \
for i in $(TOOLCHAIN_EXTERNAL_CROSS)*; do \
- case "$$i" in \
+ base=$${i##*/}; \
+ case "$$base" in \
*cc|*cc-*|*++|*++-*|*cpp) \
- base=$${i##*/}; \
ln -sf $(@F) $$base; \
;; \
*) \
--
1.7.1
^ permalink raw reply related
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: KAMEZAWA Hiroyuki @ 2011-11-01 0:50 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Linus Torvalds, linux-mm, LKML, Andrew Morton, Konrad Wilk,
Jeremy Fitzhardinge, Seth Jennings, ngupta, levinsasha928,
Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet, Neo Jia
In-Reply-To: <ef778e79-72d0-4c58-99e8-3b36d85fa30d@default>
On Mon, 31 Oct 2011 09:38:12 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@jp.fujitsu.com]
> > Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
>
> Hi Kame --
>
> Thanks for your reply and for your earlier reviews of frontswap,
> and my apologies that I accidentally left you off of the Cc list \
> for the basenote of this git-pull request.
>
> > I don't have heavy concerns to the codes itself but this process as bypassing -mm
> > or linux-next seems ugly.
>
> First, frontswap IS in linux-next and it has been since June 3
> and v11 has been in linux-next since September 23. This
> is stated in the base git-pull request.
>
Ok, I'm sorry. I found frontswap.c in my tree.
> > Why bypass -mm tree ?
> >
> > I think you planned to merge this via -mm tree and, then, posted patches
> > to linux-mm with CC -mm guys.
>
> Hmmm... the mm process is not clear or well-documented.
not complicated to me.
post -> akpm's -mm tree -> mainline.
But your tree seems to be in -mm via linux-next. Hmm, complicated ;(
I'm sorry I didn't notice frontswap.c was there....
> > I think you posted 2011/09/16 at the last time, v10. But no further submission
> > to gather acks/reviews from Mel, Johannes, Andrew, Hugh etc.. and no inclusion
> > request to -mm or -next. _AND_, IIUC, at v10, the number of posted pathces was 6.
> > Why now 8 ? Just because it's simple changes ?
>
> See https://lkml.org/lkml/2011/9/21/373. Konrad Wilk
> helped me to reorganize the patches (closer to what you
> suggested I think), but there were no code changes between
> v10 and v11, just dividing up the patches differently
> as Konrad thought there should be more smaller commits.
> So no code change between v10 and v11 but the number of
> patches went from 6 to 8.
>
> My last line in that post should also make it clear that
> I thought I was done and ready for the 3.2 window, so there
> was no evil intent on my part to subvert a process.
> It would have been nice if someone had told me there
> were uncompleted steps in the -mm process or, even better,
> pointed me to a (non-existent?) document where I could see
> for myself if I was missing steps!
>
> So... now what?
>
As far as I know, patches for memory management should go through akpm's tree.
And most of developpers in that area see that tree.
Now, your tree goes through linux-next. It complicates the problem.
When a patch goes through -mm tree, its justification is already checked by
, at least, akpm. And while in -mm tree, other developpers checks it and
some improvements are done there.
Now, you tries to push patches via linux-next and your
justification for patches is checked _now_. That's what happens.
It's not complicated. I think other linux-next patches are checked
its justification at pull request.
So, all your work will be to convice people that this feature is
necessary and not-intrusive, here.
>From my point of view,
- I have no concerns with performance cost. But, at the same time,
I want to see performance improvement numbers.
- At discussing an fujitsu user support guy (just now), he asked
'why it's not designed as device driver ?"
I couldn't answered.
So, I have small concerns with frontswap.ops ABI design.
Do we need ABI and other modules should be pluggable ?
Can frontswap be implemented as something like
# setup frontswap via device-mapper or some.
# swapon /dev/frontswap
?
It seems required hooks are just before/after read/write swap device.
other hooks can be implemented in notifier..no ?
Thanks,
-Kame
^ permalink raw reply
* Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: KAMEZAWA Hiroyuki @ 2011-11-01 0:50 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Linus Torvalds, linux-mm, LKML, Andrew Morton, Konrad Wilk,
Jeremy Fitzhardinge, Seth Jennings, ngupta, levinsasha928,
Chris Mason, JBeulich, Dave Hansen, Jonathan Corbet, Neo Jia
In-Reply-To: <ef778e79-72d0-4c58-99e8-3b36d85fa30d@default>
On Mon, 31 Oct 2011 09:38:12 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> > From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@jp.fujitsu.com]
> > Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
>
> Hi Kame --
>
> Thanks for your reply and for your earlier reviews of frontswap,
> and my apologies that I accidentally left you off of the Cc list \
> for the basenote of this git-pull request.
>
> > I don't have heavy concerns to the codes itself but this process as bypassing -mm
> > or linux-next seems ugly.
>
> First, frontswap IS in linux-next and it has been since June 3
> and v11 has been in linux-next since September 23. This
> is stated in the base git-pull request.
>
Ok, I'm sorry. I found frontswap.c in my tree.
> > Why bypass -mm tree ?
> >
> > I think you planned to merge this via -mm tree and, then, posted patches
> > to linux-mm with CC -mm guys.
>
> Hmmm... the mm process is not clear or well-documented.
not complicated to me.
post -> akpm's -mm tree -> mainline.
But your tree seems to be in -mm via linux-next. Hmm, complicated ;(
I'm sorry I didn't notice frontswap.c was there....
> > I think you posted 2011/09/16 at the last time, v10. But no further submission
> > to gather acks/reviews from Mel, Johannes, Andrew, Hugh etc.. and no inclusion
> > request to -mm or -next. _AND_, IIUC, at v10, the number of posted pathces was 6.
> > Why now 8 ? Just because it's simple changes ?
>
> See https://lkml.org/lkml/2011/9/21/373. Konrad Wilk
> helped me to reorganize the patches (closer to what you
> suggested I think), but there were no code changes between
> v10 and v11, just dividing up the patches differently
> as Konrad thought there should be more smaller commits.
> So no code change between v10 and v11 but the number of
> patches went from 6 to 8.
>
> My last line in that post should also make it clear that
> I thought I was done and ready for the 3.2 window, so there
> was no evil intent on my part to subvert a process.
> It would have been nice if someone had told me there
> were uncompleted steps in the -mm process or, even better,
> pointed me to a (non-existent?) document where I could see
> for myself if I was missing steps!
>
> So... now what?
>
As far as I know, patches for memory management should go through akpm's tree.
And most of developpers in that area see that tree.
Now, your tree goes through linux-next. It complicates the problem.
When a patch goes through -mm tree, its justification is already checked by
, at least, akpm. And while in -mm tree, other developpers checks it and
some improvements are done there.
Now, you tries to push patches via linux-next and your
justification for patches is checked _now_. That's what happens.
It's not complicated. I think other linux-next patches are checked
its justification at pull request.
So, all your work will be to convice people that this feature is
necessary and not-intrusive, here.
>From my point of view,
- I have no concerns with performance cost. But, at the same time,
I want to see performance improvement numbers.
- At discussing an fujitsu user support guy (just now), he asked
'why it's not designed as device driver ?"
I couldn't answered.
So, I have small concerns with frontswap.ops ABI design.
Do we need ABI and other modules should be pluggable ?
Can frontswap be implemented as something like
# setup frontswap via device-mapper or some.
# swapon /dev/frontswap
?
It seems required hooks are just before/after read/write swap device.
other hooks can be implemented in notifier..no ?
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.