* [PATCH 0/4] ARM: dts: OMAP3630+: Add ABB device nodes
From: Nishanth Menon @ 2014-01-29 23:46 UTC (permalink / raw)
To: linux-arm-kernel
Now that clock nodes have been merged to master,
refresh of the series meant for all TI platforms using ABB.
Originally posted [1], I will restart with v1.
dt bindings and driver is already in upstream, and only the dt node is missing.
NOTE: dra7 support depends on [2] - but dt can get sequenced as needed.
This series is based on:
master 0e47c96 Merge tag 'for-linus-20140127' of git://git.infradead.org/linux-mtd
Testing was performed on next-20140123[3]
Andrii.Tseglytskyi (3):
ARM: dts: OMAP36xx: Add device node for ABB
ARM: dts: OMAP4: Add device nodes for ABB
ARM: dts: OMAP5: Add device nodes for ABB
Nishanth Menon (1):
ARM: dts: DRA7: Add device nodes for ABB
arch/arm/boot/dts/dra7.dtsi | 132 +++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap36xx.dtsi | 20 ++++++
arch/arm/boot/dts/omap4.dtsi | 26 ++++++++
arch/arm/boot/dts/omap443x.dtsi | 26 ++++++++
arch/arm/boot/dts/omap4460.dtsi | 37 +++++++++++
arch/arm/boot/dts/omap5.dtsi | 63 +++++++++++++++++++
6 files changed, 304 insertions(+)
[1] http://marc.info/?l=linux-omap&m=136751535923806&w=2
[2] https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=topic/ti-abb
[3] https://patchwork.kernel.org/patch/3530111/
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/4] ARM: dts: OMAP36xx: Add device node for ABB
From: Nishanth Menon @ 2014-01-29 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391039177-25284-1-git-send-email-nm@ti.com>
From: "Andrii.Tseglytskyi" <andrii.tseglytskyi@ti.com>
Add ABB device node for OMAP36xx family of devices. Data is based on
OMAP36XX Technical Reference Manual revision AB (Dec 2012).
[nm at ti.com: co-developer]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
---
arch/arm/boot/dts/omap36xx.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 7e8dee9..ba077cd 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -39,6 +39,26 @@
clock-frequency = <48000000>;
};
+ abb_mpu_iva: regulator-abb-mpu {
+ compatible = "ti,abb-v1";
+ regulator-name = "abb_mpu_iva";
+ #address-cell = <0>;
+ #size-cells = <0>;
+ reg = <0x483072f0 0x8>, <0x48306818 0x4>;
+ reg-names = "base-address", "int-address";
+ ti,tranxdone-status-mask = <0x4000000>;
+ clocks = <&sys_ck>;
+ ti,settling-time = <30>;
+ ti,clock-cycles = <8>;
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1012500 0 0 0 0 0
+ 1200000 0 0 0 0 0
+ 1325000 0 0 0 0 0
+ 1375000 1 0 0 0 0
+ >;
+ };
+
omap3_pmx_core2: pinmux at 480025a0 {
compatible = "ti,omap3-padconf", "pinctrl-single";
reg = <0x480025a0 0x5c>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: OMAP4: Add device nodes for ABB
From: Nishanth Menon @ 2014-01-29 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391039177-25284-1-git-send-email-nm@ti.com>
From: "Andrii.Tseglytskyi" <andrii.tseglytskyi@ti.com>
Add ABB device nodes for OMAP443x family of devices. abb_iva is
populated, but disabled as it is not used on current OMAP443x family,
but the node is used on OMAP446x family. Data is based on OMAP443x
Technical Reference Manual revision AN (April 2013).
ABB device nodes for OMAP4460 device Data is based on OMAP4460
Technical Reference Manual revision Z (April 2013)
[nm at ti.com: co-developer]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/omap443x.dtsi | 26 ++++++++++++++++++++++++++
arch/arm/boot/dts/omap4460.dtsi | 37 +++++++++++++++++++++++++++++++++++++
3 files changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..72e6bd7 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -757,6 +757,32 @@
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_mpu";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ ti,tranxdone-status-mask = <0x80>;
+ clocks = <&sys_clkin_ck>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ status = "disabled";
+ };
+
+ abb_iva: regulator-abb-iva {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_iva";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ ti,tranxdone-status-mask = <0x80000000>;
+ clocks = <&sys_clkin_ck>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index 8c1cfad..0adfa1d 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -43,6 +43,32 @@
#thermal-sensor-cells = <0>;
};
};
+
+ ocp {
+ abb_mpu: regulator-abb-mpu {
+ status = "okay";
+
+ reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>;
+ reg-names = "base-address", "int-address";
+
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0 0 0 0
+ 1200000 0 0 0 0 0
+ 1313000 0 0 0 0 0
+ 1375000 1 0 0 0 0
+ 1389000 1 0 0 0 0
+ >;
+ };
+
+ /* Default unused, just provide register info for record */
+ abb_iva: regulator-abb-iva {
+ reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>;
+ reg-names = "base-address", "int-address";
+ };
+
+ };
+
};
/include/ "omap443x-clocks.dtsi"
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index 6b32f52..194f9ef 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -50,7 +50,44 @@
#thermal-sensor-cells = <0>;
};
+
+ abb_mpu: regulator-abb-mpu {
+ status = "okay";
+
+ reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>,
+ <0x4A002268 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address";
+
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1025000 0 0 0 0 0
+ 1200000 0 0 0 0 0
+ 1313000 0 0 0x100000 0x40000 0
+ 1375000 1 0 0 0 0
+ 1389000 1 0 0 0 0
+ >;
+ };
+
+ abb_iva: regulator-abb-iva {
+ status = "okay";
+
+ reg = <0x4a307bd8 0x8>, <0x4a306010 0x4>,
+ <0x4A002268 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address";
+
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 950000 0 0 0 0 0
+ 1140000 0 0 0 0 0
+ 1291000 0 0 0x200000 0 0
+ 1375000 1 0 0 0 0
+ 1376000 1 0 0 0 0
+ >;
+ };
};
+
};
/include/ "omap446x-clocks.dtsi"
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: OMAP5: Add device nodes for ABB
From: Nishanth Menon @ 2014-01-29 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391039177-25284-1-git-send-email-nm@ti.com>
From: "Andrii.Tseglytskyi" <andrii.tseglytskyi@ti.com>
Add ABB device nodes for OMAP5 family of devices. Data is based on
OMAP543x Technical Reference Manual revision U (April 2013).
NOTE: clock node has been disabled in this patch due to the lack of
OMAP5 clock data.
[nm at ti.com: co-developer]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Andrii.Tseglytskyi <andrii.tseglytskyi@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 63 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..6159f20 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -801,6 +801,69 @@
#thermal-sensor-cells = <1>;
};
+
+ abb_mpu: regulator-abb-mpu {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_mpu";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07cdc 0x8>, <0x4ae06014 0x4>,
+ <0x4a0021ac 0x18>, <0x4ae0C318 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address", "ldo-address";
+ ti,tranxdone-status-mask = <0x80>;
+ /* LDOVBBMPU_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBMPU_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 880000 0 0x4 0 0x20000000 0x1F000000
+ 1060000 0 0x8 0 0x20000000 0x1F000000
+ 1250000 0 0x10 0 0x20000000 0x1F000000
+ 1260000 1 0x14 0 0x20000000 0x1F000000
+ >;
+ };
+
+ abb_mm: regulator-abb-mm {
+ compatible = "ti,abb-v2";
+ regulator-name = "abb_mm";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>,
+ <0x4a002194 0x14>, <0x4ae0C314 0x4>;
+ reg-names = "base-address", "int-address",
+ "efuse-address", "ldo-address";
+ ti,tranxdone-status-mask = <0x80000000>;
+ /* LDOVBBMM_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBMM_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 880000 0 0x4 0 0x20000000 0x1F000000
+ 1025000 0 0x8 0 0x20000000 0x1F000000
+ 1120000 1 0x10 0 0x20000000 0x1F000000
+ >;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: DRA7: Add device nodes for ABB
From: Nishanth Menon @ 2014-01-29 23:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391039177-25284-1-git-send-email-nm@ti.com>
Add ABB device nodes for DRA7 family of devices. Data is based on
DRA7 Technical Reference Manual revision I (Sept 2013)
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Depends on https://patchwork.kernel.org/patch/3530111/
arch/arm/boot/dts/dra7.dtsi | 132 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1fd75aa..23a2a11 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -559,6 +559,138 @@
status = "disabled";
};
+ abb_mpu: regulator-abb-mpu {
+ compatible = "ti,abb-v3";
+ regulator-name = "abb_mpu";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin1>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07ddc 0x4>, <0x4ae07de0 0x4>,
+ <0x4ae06014 0x4>, <0x4a003b20 0x8>,
+ <0x4ae0c158 0x4>;
+ reg-names = "setup-address", "control-address",
+ "int-address", "efuse-address",
+ "ldo-address";
+ ti,tranxdone-status-mask = <0x80>;
+ /* LDOVBBMPU_FBB_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBMPU_FBB_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1060000 0 0x0 0 0x02000000 0x01F00000
+ 1160000 0 0x4 0 0x02000000 0x01F00000
+ 1210000 0 0x8 0 0x02000000 0x01F00000
+ >;
+ };
+
+ abb_ivahd: regulator-abb-ivahd {
+ compatible = "ti,abb-v3";
+ regulator-name = "abb_ivahd";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin1>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07e34 0x4>, <0x4ae07e24 0x4>,
+ <0x4ae06010 0x4>, <0x4a0025cc 0x8>,
+ <0x4a002470 0x4>;
+ reg-names = "setup-address", "control-address",
+ "int-address", "efuse-address",
+ "ldo-address";
+ ti,tranxdone-status-mask = <0x40000000>;
+ /* LDOVBBIVA_FBB_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBIVA_FBB_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1055000 0 0x0 0 0x02000000 0x01F00000
+ 1150000 0 0x4 0 0x02000000 0x01F00000
+ 1250000 0 0x8 0 0x02000000 0x01F00000
+ >;
+ };
+
+ abb_dspeve: regulator-abb-dspeve {
+ compatible = "ti,abb-v3";
+ regulator-name = "abb_dspeve";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin1>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07e30 0x4>, <0x4ae07e20 0x4>,
+ <0x4ae06010 0x4>, <0x4a0025e0 0x8>,
+ <0x4a00246c 0x4>;
+ reg-names = "setup-address", "control-address",
+ "int-address", "efuse-address",
+ "ldo-address";
+ ti,tranxdone-status-mask = <0x20000000>;
+ /* LDOVBBDSPEVE_FBB_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBDSPEVE_FBB_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1055000 0 0x0 0 0x02000000 0x01F00000
+ 1150000 0 0x4 0 0x02000000 0x01F00000
+ 1250000 0 0x8 0 0x02000000 0x01F00000
+ >;
+ };
+
+ abb_gpu: regulator-abb-gpu {
+ compatible = "ti,abb-v3";
+ regulator-name = "abb_gpu";
+ #address-cells = <0>;
+ #size-cells = <0>;
+ clocks = <&sys_clkin1>;
+ ti,settling-time = <50>;
+ ti,clock-cycles = <16>;
+
+ reg = <0x4ae07de4 0x4>, <0x4ae07de8 0x4>,
+ <0x4ae06010 0x4>, <0x4a003b08 0x8>,
+ <0x4ae0c154 0x4>;
+ reg-names = "setup-address", "control-address",
+ "int-address", "efuse-address",
+ "ldo-address";
+ ti,tranxdone-status-mask = <0x10000000>;
+ /* LDOVBBGPU_FBB_MUX_CTRL */
+ ti,ldovbb-override-mask = <0x400>;
+ /* LDOVBBGPU_FBB_VSET_OUT */
+ ti,ldovbb-vset-mask = <0x1F>;
+
+ /*
+ * NOTE: only FBB mode used but actual vset will
+ * determine final biasing
+ */
+ ti,abb_info = <
+ /*uV ABB efuse rbb_m fbb_m vset_m*/
+ 1090000 0 0x0 0 0x02000000 0x01F00000
+ 1210000 0 0x4 0 0x02000000 0x01F00000
+ 1280000 0 0x8 0 0x02000000 0x01F00000
+ >;
+ };
+
mcspi1: spi at 48098000 {
compatible = "ti,omap4-mcspi";
reg = <0x48098000 0x200>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V5 0/5] Add X-Gene platform reboot mechanism
From: Feng Kan @ 2014-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
Enable reboot driver for the X-Gene platform. Add generic syscon reboot
driver.
V5 Change:
- Documentation update, endian and access size.
V4 Change:
- Remove old X-Gene reboot driver
- Add generic syscon reboot driver
- Add DTS and Kconfig for X-Gene reboot using syscon method
V3 Change:
- Remove the reboot driver's use of acpi resource patch.
- Change the reboot driver to use syscon to parse out
system clock register. Remove the old method of getting
register from the reboot driver directly.
- Remove documentation since its now simple.
V2 Change:
- Add support for using ACPI resource.
Feng Kan (5):
power: reset: Add generic SYSCON register mapped reset
power: reset: Remove X-Gene reboot driver
arm64: dts: Add X-Gene reboot driver dts node
arm64: Select reboot driver for X-Gene platform
Documentation: power: reset: Add documentation for generic SYSCON
reboot driver
.../bindings/power/reset/syscon-reboot.txt | 23 +++++
arch/arm64/Kconfig | 2 +
arch/arm64/boot/dts/apm-storm.dtsi | 13 +++
drivers/power/reset/Kconfig | 8 +-
drivers/power/reset/Makefile | 2 +-
drivers/power/reset/syscon-reboot.c | 100 +++++++++++++++++++
drivers/power/reset/xgene-reboot.c | 103 --------------------
7 files changed, 143 insertions(+), 108 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
create mode 100644 drivers/power/reset/syscon-reboot.c
delete mode 100644 drivers/power/reset/xgene-reboot.c
--
1.7.6.1
^ permalink raw reply
* [PATCH V5 1/5] power: reset: Add generic SYSCON register mapped reset
From: Feng Kan @ 2014-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391040198-14185-1-git-send-email-fkan@apm.com>
Add a generic SYSCON register mapped reset mechanism.
Signed-off-by: Feng Kan <fkan@apm.com>
---
drivers/power/reset/Kconfig | 7 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/syscon-reboot.c | 100 +++++++++++++++++++++++++++++++++++
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/reset/syscon-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 9b3ea53..4501c02 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -51,3 +51,10 @@ config POWER_RESET_XGENE
depends on POWER_RESET
help
Reboot support for the APM SoC X-Gene Eval boards.
+
+config POWER_RESET_SYSCON
+ bool "Generic SYSCON regmap reset driver"
+ depends on MFD_SYSCON
+ depends on POWER_RESET
+ help
+ Reboot support for generic SYSCON mapped register reset.
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 3e6ed88..f2c0327 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/syscon-reboot.c b/drivers/power/reset/syscon-reboot.c
new file mode 100644
index 0000000..29ed908
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot.c
@@ -0,0 +1,100 @@
+/*
+ * Generic Syscon Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan <fkan@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This driver provides system reboot functionality for APM X-Gene SoC.
+ * For system shutdown, this is board specify. If a board designer
+ * implements GPIO shutdown, use the gpio-poweroff.c driver.
+ */
+#include <linux/io.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/reboot.h>
+#include <asm/system_misc.h>
+
+struct syscon_reboot_context {
+ struct regmap *map;
+ u32 offset;
+ u32 mask;
+};
+
+static struct syscon_reboot_context *syscon_reboot_ctx;
+
+static void syscon_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ struct syscon_reboot_context *ctx = syscon_reboot_ctx;
+ unsigned long timeout;
+
+ /* Issue the reboot */
+ if (ctx->map)
+ regmap_write(ctx->map, ctx->offset, ctx->mask);
+
+ timeout = jiffies + HZ;
+ while (time_before(jiffies, timeout))
+ cpu_relax();
+
+ pr_emerg("Unable to restart system\n");
+}
+
+static int syscon_reboot_probe(struct platform_device *pdev)
+{
+ struct syscon_reboot_context *ctx;
+ struct device *dev = &pdev->dev;
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx) {
+ dev_err(&pdev->dev, "out of memory for context\n");
+ return -ENOMEM;
+ }
+
+ ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
+ if (IS_ERR(ctx->map))
+ return PTR_ERR(ctx->map);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", &ctx->offset))
+ return -EINVAL;
+
+ if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
+ return -EINVAL;
+
+ arm_pm_restart = syscon_restart;
+ syscon_reboot_ctx = ctx;
+
+ return 0;
+}
+
+static struct of_device_id syscon_reboot_of_match[] = {
+ { .compatible = "syscon-reboot" },
+ {}
+};
+
+static struct platform_driver syscon_reboot_driver = {
+ .probe = syscon_reboot_probe,
+ .driver = {
+ .name = "syscon-reboot",
+ .of_match_table = syscon_reboot_of_match,
+ },
+};
+module_platform_driver(syscon_reboot_driver);
--
1.7.6.1
^ permalink raw reply related
* [PATCH V5 2/5] power: reset: Remove X-Gene reboot driver
From: Feng Kan @ 2014-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391040198-14185-1-git-send-email-fkan@apm.com>
Remove X-Gene reboot driver.
Signed-off-by: Feng Kan <fkan@apm.com>
---
drivers/power/reset/Kconfig | 7 ---
drivers/power/reset/Makefile | 1 -
drivers/power/reset/xgene-reboot.c | 103 ------------------------------------
3 files changed, 0 insertions(+), 111 deletions(-)
delete mode 100644 drivers/power/reset/xgene-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4501c02..13a5191 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -45,13 +45,6 @@ config POWER_RESET_VEXPRESS
Power off and reset support for the ARM Ltd. Versatile
Express boards.
-config POWER_RESET_XGENE
- bool "APM SoC X-Gene reset driver"
- depends on ARM64
- depends on POWER_RESET
- help
- Reboot support for the APM SoC X-Gene Eval boards.
-
config POWER_RESET_SYSCON
bool "Generic SYSCON regmap reset driver"
depends on MFD_SYSCON
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index f2c0327..a3137ff 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -3,5 +3,4 @@ obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
-obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/xgene-reboot.c b/drivers/power/reset/xgene-reboot.c
deleted file mode 100644
index ecd55f8..0000000
--- a/drivers/power/reset/xgene-reboot.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * AppliedMicro X-Gene SoC Reboot Driver
- *
- * Copyright (c) 2013, Applied Micro Circuits Corporation
- * Author: Feng Kan <fkan@apm.com>
- * Author: Loc Ho <lho@apm.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- * This driver provides system reboot functionality for APM X-Gene SoC.
- * For system shutdown, this is board specify. If a board designer
- * implements GPIO shutdown, use the gpio-poweroff.c driver.
- */
-#include <linux/io.h>
-#include <linux/of_device.h>
-#include <linux/of_address.h>
-#include <linux/platform_device.h>
-#include <linux/stat.h>
-#include <linux/slab.h>
-#include <asm/system_misc.h>
-
-struct xgene_reboot_context {
- struct platform_device *pdev;
- void *csr;
- u32 mask;
-};
-
-static struct xgene_reboot_context *xgene_restart_ctx;
-
-static void xgene_restart(char str, const char *cmd)
-{
- struct xgene_reboot_context *ctx = xgene_restart_ctx;
- unsigned long timeout;
-
- /* Issue the reboot */
- if (ctx)
- writel(ctx->mask, ctx->csr);
-
- timeout = jiffies + HZ;
- while (time_before(jiffies, timeout))
- cpu_relax();
-
- dev_emerg(&ctx->pdev->dev, "Unable to restart system\n");
-}
-
-static int xgene_reboot_probe(struct platform_device *pdev)
-{
- struct xgene_reboot_context *ctx;
-
- ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
- if (!ctx) {
- dev_err(&pdev->dev, "out of memory for context\n");
- return -ENODEV;
- }
-
- ctx->csr = of_iomap(pdev->dev.of_node, 0);
- if (!ctx->csr) {
- devm_kfree(&pdev->dev, ctx);
- dev_err(&pdev->dev, "can not map resource\n");
- return -ENODEV;
- }
-
- if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
- ctx->mask = 0xFFFFFFFF;
-
- ctx->pdev = pdev;
- arm_pm_restart = xgene_restart;
- xgene_restart_ctx = ctx;
-
- return 0;
-}
-
-static struct of_device_id xgene_reboot_of_match[] = {
- { .compatible = "apm,xgene-reboot" },
- {}
-};
-
-static struct platform_driver xgene_reboot_driver = {
- .probe = xgene_reboot_probe,
- .driver = {
- .name = "xgene-reboot",
- .of_match_table = xgene_reboot_of_match,
- },
-};
-
-static int __init xgene_reboot_init(void)
-{
- return platform_driver_register(&xgene_reboot_driver);
-}
-device_initcall(xgene_reboot_init);
--
1.7.6.1
^ permalink raw reply related
* [PATCH V5 3/5] arm64: dts: Add X-Gene reboot driver dts node
From: Feng Kan @ 2014-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391040198-14185-1-git-send-email-fkan@apm.com>
Add X-Gene platform reboot driver dts node.
Signed-off-by: Feng Kan <fkan@apm.com>
---
arch/arm64/boot/dts/apm-storm.dtsi | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..4ef9d26 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
+ scu: system-clk-controller at 17000000 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x17000000 0x0 0x400>;
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -187,5 +192,13 @@
interrupt-parent = <&gic>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ reboot at 17000014 {
+ compatible = "syscon-reboot";
+ regmap = <&scu>;
+ offset = <0x14>;
+ mask = <0x1>;
+ };
+
};
};
--
1.7.6.1
^ permalink raw reply related
* [PATCH V5 4/5] arm64: Select reboot driver for X-Gene platform
From: Feng Kan @ 2014-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391040198-14185-1-git-send-email-fkan@apm.com>
Select reboot driver for X-Gene platform.
Signed-off-by: Feng Kan <fkan@apm.com>
---
arch/arm64/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dd4327f..f43820f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -123,6 +123,8 @@ config ARCH_VEXPRESS
config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+ select MFD_SYSCON
+ select POWER_RESET_SYSCON
help
This enables support for AppliedMicro X-Gene SOC Family
--
1.7.6.1
^ permalink raw reply related
* [PATCH V5 5/5] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
From: Feng Kan @ 2014-01-30 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391040198-14185-1-git-send-email-fkan@apm.com>
Add documentation for generic SYSCON reboot driver.
Signed-off-by: Feng Kan <fkan@apm.com>
---
.../bindings/power/reset/syscon-reboot.txt | 23 ++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
new file mode 100644
index 0000000..963f3c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
@@ -0,0 +1,23 @@
+Generic SYSCON mapped register reset driver
+
+This is a generic reset driver using syscon to map the reset register.
+The reset is generally performed with a write to the reset register
+defined by the register map pointed by syscon reference plus the offset
+with the mask defined in the reboot node.
+
+Required properties:
+- compatible: should contain "syscon-reboot"
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register (in bytes)
+- mask: the reset value written to the reboot register (32 bit access)
+
+Default will be little endian mode, 32 bit access only.
+
+Examples:
+
+ reboot {
+ compatible = "syscon-reboot";
+ regmap = <®mapnode>;
+ offset = <0x0>;
+ mask = <0x1>;
+ };
--
1.7.6.1
^ permalink raw reply related
* [RFC PATCH V3 0/4] APM X-Gene PCIe controller
From: Bjorn Helgaas @ 2014-01-30 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALdTtnsEo74UeYgoQ0DF7=LN074b_0bL0vg6Bxs02B9nDkRTNA@mail.gmail.com>
On Sat, Jan 25, 2014 at 9:09 AM, Dann Frazier
<dann.frazier@canonical.com> wrote:
> On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
>> cards.
>>
>> X-Gene PCIe controller driver has depedency on the pcie arch support for
>> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
>> and approach for arch support is under discussion with arm64 maintainers.
>> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244
>
> The reference patch looks corrupted (pcibios.c has no includes, etc),
> would you mind reposting?
When you repost, please make sure you fix whatever problem is
preventing your email from appearing on the vger mailing lists. I
won't apply things that haven't appeared on the linux-pci list,
because that list is the opportunity for other people to review them.
Bjorn
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with Linus' tree
From: Stephen Rothwell @ 2014-01-30 0:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
clock framework support") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc drivers/clk/Makefile
index a367a9831717,7c7f40e9ba05..000000000000
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@@ -9,44 -9,44 +9,45 @@@ obj-$(CONFIG_COMMON_CLK) += clk-gate.
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
-# SoCs specific
-obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
-obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
-obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
-obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
-obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
-obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
-obj-$(CONFIG_ARCH_MXS) += mxs/
-obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
-obj-$(CONFIG_PLAT_SPEAR) += spear/
-obj-$(CONFIG_ARCH_U300) += clk-u300.o
-obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
-obj-$(CONFIG_ARCH_SIRF) += clk-prima2.o
-obj-$(CONFIG_PLAT_ORION) += mvebu/
+# hardware specific clock types
+# please keep this section sorted lexicographically by file/directory path name
++obj-$(CONFIG_ARCH_BCM) += bcm/
+obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
+obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
+obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
+obj-$(CONFIG_ARCH_HIGHBANK) += clk-highbank.o
+obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
+obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
+obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
+obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
+obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
+obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
+obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
+obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
+obj-$(CONFIG_ARCH_U300) += clk-u300.o
+obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
+obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
+obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
+obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/
+obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
ifeq ($(CONFIG_COMMON_CLK), y)
-obj-$(CONFIG_ARCH_MMP) += mmp/
+obj-$(CONFIG_ARCH_MMP) += mmp/
endif
-obj-$(CONFIG_MACH_LOONGSON1) += clk-ls1x.o
-obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
-obj-$(CONFIG_ARCH_SUNXI) += sunxi/
-obj-$(CONFIG_ARCH_U8500) += ux500/
-obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
-obj-$(CONFIG_ARCH_ZYNQ) += zynq/
-obj-$(CONFIG_ARCH_TEGRA) += tegra/
-obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
-obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
-obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
-obj-$(CONFIG_COMMON_CLK_AT91) += at91/
+obj-$(CONFIG_PLAT_ORION) += mvebu/
+obj-$(CONFIG_ARCH_MXS) += mxs/
+obj-$(CONFIG_COMMON_CLK_QCOM) += qcom/
+obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
+obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/
-
-obj-$(CONFIG_X86) += x86/
-obj-$(CONFIG_ARCH_BCM) += bcm/
-
-# Chip specific
-obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
-obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
-obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
-obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
-obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
-obj-$(CONFIG_CLK_TWL6040) += clk-twl6040.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_ARCH_SIRF) += sirf/
+obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
+obj-$(CONFIG_PLAT_SPEAR) += spear/
+obj-$(CONFIG_ARCH_SUNXI) += sunxi/
+obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-$(CONFIG_ARCH_OMAP2PLUS) += ti/
+obj-$(CONFIG_ARCH_U8500) += ux500/
+obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
+obj-$(CONFIG_X86) += x86/
+obj-$(CONFIG_ARCH_ZYNQ) += zynq/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140130/7fbd45c9/attachment.sig>
^ permalink raw reply
* [RFC PATCH V3 0/4] APM X-Gene PCIe controller
From: Tanmay Inamdar @ 2014-01-30 0:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7Dfd4NJBEDuVe1VCvZObFq1YvV2x77S60Z4-CZq89QJw@mail.gmail.com>
On Wed, Jan 29, 2014 at 4:18 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Sat, Jan 25, 2014 at 9:09 AM, Dann Frazier
> <dann.frazier@canonical.com> wrote:
>> On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
>>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
>>> cards.
>>>
>>> X-Gene PCIe controller driver has depedency on the pcie arch support for
>>> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
>>> and approach for arch support is under discussion with arm64 maintainers.
>>> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244
>>
>> The reference patch looks corrupted (pcibios.c has no includes, etc),
>> would you mind reposting?
>
> When you repost, please make sure you fix whatever problem is
> preventing your email from appearing on the vger mailing lists. I
> won't apply things that haven't appeared on the linux-pci list,
> because that list is the opportunity for other people to review them.
>
You are absolutely right. If the patches are not reaching mailing
list, they should not appear on archive list as well. However I am
seeing my patches recorded on archives. So I am not sure if they are
actually getting dropped on linux-pci or any other mailing list.
http://www.spinics.net/lists/linux-pci/msg28198.html
http://article.gmane.org/gmane.linux.kernel.pci/28442/match=tanmay+inamdar
> Bjorn
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Emilio López @ 2014-01-30 1:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390993850-9054-4-git-send-email-maxime.ripard@free-electrons.com>
Hi Maxime,
El 29/01/14 08:10, Maxime Ripard escribi?:
> The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
> SoCs.
>
> It supports DMA, but the driver only does PIO for now, and DMA will be
> supported eventually.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
(snip)
> + struct sun6i_spi *sspi = spi_master_get_devdata(master);
> + int ret;
> +
> + ret = clk_prepare_enable(sspi->hclk);
> + if (ret) {
> + dev_err(dev, "Couldn't enable clock 'ahb spi'\n");
> + goto out;
> + }
> +
> + ret = clk_prepare_enable(sspi->mclk);
> + if (ret) {
> + dev_err(dev, "Couldn't enable clock 'ahb spi'\n");
A different message would be nice :)
Cheers,
Emilio
^ permalink raw reply
* [PATCH] of: add vendor prefix for Allwinner Technology
From: Emilio López @ 2014-01-30 1:36 UTC (permalink / raw)
To: linux-arm-kernel
We have been using the "allwinner" prefix for everything so far; let's
document it here.
Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index edbb8d8..5a2904b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -7,6 +7,7 @@ ad Avionic Design GmbH
adi Analog Devices, Inc.
aeroflexgaisler Aeroflex Gaisler AB
ak Asahi Kasei Corp.
+allwinner Allwinner Technology Co., Ltd.
altr Altera Corp.
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Preeti U Murthy @ 2014-01-30 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401291526320.1652@knanqh.ubzr>
Hi Nicolas,
On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
> On Wed, 29 Jan 2014, Nicolas Pitre wrote:
>
>> In order to integrate cpuidle with the scheduler, we must have a better
>> proximity in the core code with what cpuidle is doing and not delegate
>> such interaction to arch code.
>>
>> Architectures implementing arch_cpu_idle() should simply enter
>> a cheap idle mode in the absence of a proper cpuidle driver.
>>
>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>
> As mentioned in my reply to Olof's comment on patch #5/6, here's a new
> version of this patch adding the safety local_irq_enable() to the core
> code.
>
> ----- >8
>
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> Subject: idle: move the cpuidle entry point to the generic idle loop
>
> In order to integrate cpuidle with the scheduler, we must have a better
> proximity in the core code with what cpuidle is doing and not delegate
> such interaction to arch code.
>
> Architectures implementing arch_cpu_idle() should simply enter
> a cheap idle mode in the absence of a proper cpuidle driver.
>
> In both cases i.e. whether it is a cpuidle driver or the default
> arch_cpu_idle(), the calling convention expects IRQs to be disabled
> on entry and enabled on exit. There is a warning in place already but
> let's add a forced IRQ enable here as well. This will allow for
> removing the forced IRQ enable some implementations do locally and
Why would this patch allow for removing the forced IRQ enable that are
being done on some archs in arch_cpu_idle()? Isn't this patch expecting
the default arch_cpu_idle() to have re-enabled the interrupts after
exiting from the default idle state? Its supposed to only catch faulty
cpuidle drivers that haven't enabled IRQs on exit from idle state but
are expected to have done so, isn't it?
Thanks
Regards
Preeti U Murthy
> allowing for the warning to trig.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>
> diff --git a/kernel/cpu/idle.c b/kernel/cpu/idle.c
> index 988573a9a3..14ca43430a 100644
> --- a/kernel/cpu/idle.c
> +++ b/kernel/cpu/idle.c
> @@ -3,6 +3,7 @@
> */
> #include <linux/sched.h>
> #include <linux/cpu.h>
> +#include <linux/cpuidle.h>
> #include <linux/tick.h>
> #include <linux/mm.h>
> #include <linux/stackprotector.h>
> @@ -95,8 +96,10 @@ static void cpu_idle_loop(void)
> if (!current_clr_polling_and_test()) {
> stop_critical_timings();
> rcu_idle_enter();
> - arch_cpu_idle();
> - WARN_ON_ONCE(irqs_disabled());
> + if (cpuidle_idle_call())
> + arch_cpu_idle();
> + if (WARN_ON_ONCE(irqs_disabled()))
> + local_irq_enable();
> rcu_idle_exit();
> start_critical_timings();
> } else {
>
^ permalink raw reply
* [RFC PATCH 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-01-30 4:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129155005.GC3570@cbox>
On Wed, Jan 29, 2014 at 9:20 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Wed, Jan 29, 2014 at 10:22:47AM +0530, Anup Patel wrote:
>> On Wed, Jan 29, 2014 at 2:34 AM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Tue, Jan 21, 2014 at 06:31:40PM +0530, Anup Patel wrote:
>
> [...]
>
>> >
>> > Which tree does this patch apply to? It looks like you'll get a
>> > conflict with:
>> > 478a823 arm: KVM: Don't return PSCI_INVAL if waitqueue is inactive
>>
>> This patchset applies on v3.13 tag of Torvalds tree.
>
> That would not contain anything in kvm/next or kvm-arm-next.
>
>>
>> I generally base my patches on latest stable/rc tag of Torvalds tree
>> so that I can provide KVM patches to folks interested in trying KVM
>> on X-Gene with latest Linux stable/rc.
>
> If you want to make it slightly easier for me or Marc to apply your
> patches in general I would recommend basing them off kvm/next or
> kvm-arm-next, but it's no big deal.
>
> In this case all you need to consider is already in linus/master.
>
>>
>> I will make sure that revised patchset applies on top of
>> 478a823 arm: KVM: Don't return PSCI_INVAL if waitqueue is inactive
>>
>> >
>> >> }
>> >>
>> >> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
>> >> index 0881bf1..ee044a3 100644
>> >> --- a/arch/arm/kvm/psci.c
>> >> +++ b/arch/arm/kvm/psci.c
>> >> @@ -55,13 +55,13 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>> >> }
>> >>
>> >> if (!vcpu)
>> >> - return KVM_PSCI_RET_INVAL;
>> >> + return KVM_PSCI_RET_INVALID_PARAMS;
>> >>
>> >> target_pc = *vcpu_reg(source_vcpu, 2);
>> >>
>> >> wq = kvm_arch_vcpu_wq(vcpu);
>> >> if (!waitqueue_active(wq))
>> >> - return KVM_PSCI_RET_INVAL;
>> >> + return KVM_PSCI_RET_INVALID_PARAMS;
>> >>
>> >> kvm_reset_vcpu(vcpu);
>> >>
>> >> @@ -84,17 +84,49 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>> >> return KVM_PSCI_RET_SUCCESS;
>> >> }
>> >>
>> >> -/**
>> >> - * kvm_psci_call - handle PSCI call if r0 value is in range
>> >> - * @vcpu: Pointer to the VCPU struct
>> >> - *
>> >> - * Handle PSCI calls from guests through traps from HVC instructions.
>> >> - * The calling convention is similar to SMC calls to the secure world where
>> >> - * the function number is placed in r0 and this function returns true if the
>> >> - * function number specified in r0 is withing the PSCI range, and false
>> >> - * otherwise.
>> >> - */
>> >> -bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> >> +static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
>> >> +{
>> >> + unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>> >> + unsigned long val;
>> >> +
>> >> + switch (psci_fn) {
>> >> + case KVM_PSCI_0_2_FN_PSCI_VERSION:
>> >> + /*
>> >> + * Bits[31:16] = Major Version = 0
>> >> + * Bits[15:0] = Minor Version = 2
>> >> + */
>> >> + val = 2;
>> >> + break;
>> >> + case KVM_PSCI_0_2_FN_CPU_OFF:
>> >> + kvm_psci_vcpu_off(vcpu);
>> >> + val = KVM_PSCI_RET_SUCCESS;
>> >> + break;
>> >> + case KVM_PSCI_0_2_FN_CPU_ON:
>> >> + case KVM_PSCI_0_2_FN64_CPU_ON:
>> >> + val = kvm_psci_vcpu_on(vcpu);
>> >> + break;
>> >> + case KVM_PSCI_0_2_FN_CPU_SUSPEND:
>> >> + case KVM_PSCI_0_2_FN_AFFINITY_INFO:
>> >> + case KVM_PSCI_0_2_FN_MIGRATE:
>> >> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
>> >> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
>> >> + case KVM_PSCI_0_2_FN_SYSTEM_OFF:
>> >> + case KVM_PSCI_0_2_FN_SYSTEM_RESET:
>> >> + case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
>> >> + case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
>> >> + case KVM_PSCI_0_2_FN64_MIGRATE:
>> >> + case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
>> >> + val = KVM_PSCI_RET_NOT_SUPPORTED;
>> >> + break;
>> >> + default:
>> >> + return false;
>> >> + }
>> >> +
>> >> + *vcpu_reg(vcpu, 0) = val;
>> >> + return true;
>> >> +}
>> >> +
>> >> +static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
>> >> {
>> >> unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>> >> unsigned long val;
>> >> @@ -109,9 +141,8 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> >> break;
>> >> case KVM_PSCI_FN_CPU_SUSPEND:
>> >> case KVM_PSCI_FN_MIGRATE:
>> >> - val = KVM_PSCI_RET_NI;
>> >> + val = KVM_PSCI_RET_NOT_SUPPORTED;
>> >> break;
>> >> -
>> >> default:
>> >> return false;
>> >> }
>> >> @@ -119,3 +150,21 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> >> *vcpu_reg(vcpu, 0) = val;
>> >> return true;
>> >> }
>> >> +
>> >> +/**
>> >> + * kvm_psci_call - handle PSCI call if r0 value is in range
>> >> + * @vcpu: Pointer to the VCPU struct
>> >> + *
>> >> + * Handle PSCI calls from guests through traps from HVC instructions.
>> >> + * The calling convention is similar to SMC calls to the secure world where
>> >> + * the function number is placed in r0 and this function returns true if the
>> >> + * function number specified in r0 is withing the PSCI range, and false
>> >> + * otherwise.
>> >> + */
>> >> +bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> >> +{
>> >> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
>> >> + return kvm_psci_0_2_call(vcpu);
>> >> +
>> >> + return kvm_psci_0_1_call(vcpu);
>> >> +}
>> >
>> > Why don't we just try one after the other? Do they conflict in some
>> > way?
>>
>> Atleast the functions IDs are totally different in v0.2 and v0.1
>>
>> Also, in v0.2 we have separate function IDs for 32bit and 64bit
>> VCPU calling same PSCI function.
>>
>
> So we could just do:
>
> {
> ret = kvm_psci_0_2_call(vcpu);
> if (ret)
> return ret;
>
> ret = kvm_psci_0_1_call(vcpu);
> if (ret)
> return ret;
>
> return false;
> }
>
> and be rid of the vcpu feature, or? I thought this was Marc's point in
> the last KVM/ARM call?
OK, I will update kvm_psci_call() as per this.
>
>> >
>> > I assume PSCI calls are never going to be in the critical path and calls
>> > into PSCI are pretty much expected to be slow as a dog anyhow, so if we
>> > could avoid the extra churn in user space code and potential user
>> > confusion (providing PSCI 0.2 kernel but too old user space tool for
>> > example), I think that would be preferred.
>>
>> Yes, PSCI calls will not be in critical path except few functions such as
>> PSCI CPU_SUSPEND and CPU_ON.
>>
>> For example,
>> On real HW, people are very much interested in time taken to resume a
>> HW CPU from suspended state because this affects responsiveness of
>> a system.
>>
>
> In which case time taken to wake up from suspended state in a VM will
> for sure not be dominated by an extra call to a psci function id
> checking function.
>
> Thanks,
> -Christoffer
--
Anup
^ permalink raw reply
* [PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Sekhar Nori @ 2014-01-30 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E91C54.9090302@ti.com>
On Wednesday 29 January 2014 08:50 PM, Ivan Khoronzhuk wrote:
> Hi Sekhar,
>
> Do you want me to correct it?
Yes, please!
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] clk: Correct handling of NULL clk in __clk_{get, put}
From: Sachin Kamat @ 2014-01-30 4:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CFC5C9.4000006@samsung.com>
On 10 January 2014 15:34, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
> On 08/01/14 05:44, Sachin Kamat wrote:
>> Hi Sylwester,
>>
>> On 7 January 2014 17:33, Sylwester Nawrocki <s.nawrocki@samsung.com> wrote:
>>> Ensure clk->kref is dereferenced only when clk is not NULL.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>> ---
>>> Hi Sachin,
>>>
>>> please try if this patch fixes the exyno5420 boot crash.
>>
>> Confirmed that this patch works fine on 5420 as well as already
>> working 4210 and 5250 boards.
>> Thanks for the quick fix.
>>
>> Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
>
> Thanks Sachin. Mike, it seems we need this patch on top of
> my clk-unregister branch. Sorry for overlooking this issue.
> Could you add the $subject patch to your clk-next tree ?
Gentle ping Mike. Hope we can have this patch in rc-2.
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Nicolas Pitre @ 2014-01-30 5:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E9C946.50704@linux.vnet.ibm.com>
On Thu, 30 Jan 2014, Preeti U Murthy wrote:
> Hi Nicolas,
>
> On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
> > On Wed, 29 Jan 2014, Nicolas Pitre wrote:
> >
> >> In order to integrate cpuidle with the scheduler, we must have a better
> >> proximity in the core code with what cpuidle is doing and not delegate
> >> such interaction to arch code.
> >>
> >> Architectures implementing arch_cpu_idle() should simply enter
> >> a cheap idle mode in the absence of a proper cpuidle driver.
> >>
> >> Signed-off-by: Nicolas Pitre <nico@linaro.org>
> >> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >
> > As mentioned in my reply to Olof's comment on patch #5/6, here's a new
> > version of this patch adding the safety local_irq_enable() to the core
> > code.
> >
> > ----- >8
> >
> > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> > Subject: idle: move the cpuidle entry point to the generic idle loop
> >
> > In order to integrate cpuidle with the scheduler, we must have a better
> > proximity in the core code with what cpuidle is doing and not delegate
> > such interaction to arch code.
> >
> > Architectures implementing arch_cpu_idle() should simply enter
> > a cheap idle mode in the absence of a proper cpuidle driver.
> >
> > In both cases i.e. whether it is a cpuidle driver or the default
> > arch_cpu_idle(), the calling convention expects IRQs to be disabled
> > on entry and enabled on exit. There is a warning in place already but
> > let's add a forced IRQ enable here as well. This will allow for
> > removing the forced IRQ enable some implementations do locally and
>
> Why would this patch allow for removing the forced IRQ enable that are
> being done on some archs in arch_cpu_idle()? Isn't this patch expecting
> the default arch_cpu_idle() to have re-enabled the interrupts after
> exiting from the default idle state? Its supposed to only catch faulty
> cpuidle drivers that haven't enabled IRQs on exit from idle state but
> are expected to have done so, isn't it?
Exact. However x86 currently does this:
if (cpuidle_idle_call())
x86_idle();
else
local_irq_enable();
So whenever cpuidle_idle_call() is successful then IRQs are
unconditionally enabled whether or not the underlying cpuidle driver has
properly done it or not. And the reason is that some of the x86 cpuidle
do fail to enable IRQs before returning.
So the idea is to get rid of this unconditional IRQ enabling and let the
core issue a warning instead (as well as enabling IRQs to allow the
system to run).
Nicolas
^ permalink raw reply
* [RFC PATCH 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-01-30 5:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128210410.GA26671@cbox>
Hi Christoffer,
On Wed, Jan 29, 2014 at 2:34 AM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Tue, Jan 21, 2014 at 06:31:40PM +0530, Anup Patel wrote:
>> Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
>> VCPUs. This patch extends current in-kernel PSCI emulation to provide
>> PSCI v0.2 interface to VCPUs.
>>
>> By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
>> keeping the ABI backward-compatible.
>>
>> To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
>> KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
>> init using KVM_ARM_VCPU_INIT ioctl.
>>
>> Signed-off-by: Anup Patel <anup.patel@linaro.org>
>> Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
>> ---
>> arch/arm/include/asm/kvm_host.h | 2 +-
>> arch/arm/include/uapi/asm/kvm.h | 39 ++++++++++++++++--
>> arch/arm/kvm/arm.c | 6 ++-
>> arch/arm/kvm/psci.c | 79 ++++++++++++++++++++++++++++++-------
>> arch/arm64/include/asm/kvm_host.h | 2 +-
>> arch/arm64/include/uapi/asm/kvm.h | 39 ++++++++++++++++--
>> 6 files changed, 143 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
>> index 8a6f6db..0239ac5 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -36,7 +36,7 @@
>> #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>> #define KVM_HAVE_ONE_REG
>>
>> -#define KVM_VCPU_MAX_FEATURES 1
>> +#define KVM_VCPU_MAX_FEATURES 2
>>
>> #include <kvm/arm_vgic.h>
>>
>> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
>> index c498b60..d9eb74c 100644
>> --- a/arch/arm/include/uapi/asm/kvm.h
>> +++ b/arch/arm/include/uapi/asm/kvm.h
>> @@ -83,6 +83,7 @@ struct kvm_regs {
>> #define KVM_VGIC_V2_CPU_SIZE 0x2000
>>
>> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
>> +#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
>>
>> struct kvm_vcpu_init {
>> __u32 target;
>> @@ -164,7 +165,7 @@ struct kvm_arch_memory_slot {
>> /* Highest supported SPI, from VGIC_NR_IRQS */
>> #define KVM_ARM_IRQ_GIC_MAX 127
>>
>> -/* PSCI interface */
>> +/* PSCI v0.1 interface */
>> #define KVM_PSCI_FN_BASE 0x95c1ba5e
>> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>>
>> @@ -173,9 +174,41 @@ struct kvm_arch_memory_slot {
>> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
>> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>>
>> +/* PSCI v0.2 interface */
>> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
>> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
>> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
>> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
>> +
>> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
>> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
>> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
>> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
>> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
>> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
>> + KVM_PSCI_0_2_FN(6)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN(7)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
>> +
>> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
>> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
>> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN64(7)
>> +
>> +/* PSCI return values */
>> #define KVM_PSCI_RET_SUCCESS 0
>> -#define KVM_PSCI_RET_NI ((unsigned long)-1)
>> -#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
>> +#define KVM_PSCI_RET_NOT_SUPPORTED ((unsigned long)-1)
>> +#define KVM_PSCI_RET_INVALID_PARAMS ((unsigned long)-2)
>> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
>> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
>> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
>> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
>> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
>> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>>
>> #endif /* __ARM_KVM_H__ */
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 2a700e0..0b7817a 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -193,6 +193,7 @@ int kvm_dev_ioctl_check_extension(long ext)
>> case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
>> case KVM_CAP_ONE_REG:
>> case KVM_CAP_ARM_PSCI:
>> + case KVM_CAP_ARM_PSCI_0_2:
>> r = 1;
>> break;
>> case KVM_CAP_COALESCED_MMIO:
>> @@ -483,7 +484,10 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
>> * PSCI code.
>> */
>> if (test_and_clear_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features)) {
>> - *vcpu_reg(vcpu, 0) = KVM_PSCI_FN_CPU_OFF;
>> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
>> + *vcpu_reg(vcpu, 0) = KVM_PSCI_0_2_FN_CPU_OFF;
>> + else
>> + *vcpu_reg(vcpu, 0) = KVM_PSCI_FN_CPU_OFF;
>> kvm_psci_call(vcpu);
>
> Which tree does this patch apply to? It looks like you'll get a
> conflict with:
> 478a823 arm: KVM: Don't return PSCI_INVAL if waitqueue is inactive
>
>> }
>>
>> diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
>> index 0881bf1..ee044a3 100644
>> --- a/arch/arm/kvm/psci.c
>> +++ b/arch/arm/kvm/psci.c
>> @@ -55,13 +55,13 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>> }
>>
>> if (!vcpu)
>> - return KVM_PSCI_RET_INVAL;
>> + return KVM_PSCI_RET_INVALID_PARAMS;
>>
>> target_pc = *vcpu_reg(source_vcpu, 2);
>>
>> wq = kvm_arch_vcpu_wq(vcpu);
>> if (!waitqueue_active(wq))
>> - return KVM_PSCI_RET_INVAL;
>> + return KVM_PSCI_RET_INVALID_PARAMS;
>>
>> kvm_reset_vcpu(vcpu);
>>
>> @@ -84,17 +84,49 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
>> return KVM_PSCI_RET_SUCCESS;
>> }
>>
>> -/**
>> - * kvm_psci_call - handle PSCI call if r0 value is in range
>> - * @vcpu: Pointer to the VCPU struct
>> - *
>> - * Handle PSCI calls from guests through traps from HVC instructions.
>> - * The calling convention is similar to SMC calls to the secure world where
>> - * the function number is placed in r0 and this function returns true if the
>> - * function number specified in r0 is withing the PSCI range, and false
>> - * otherwise.
>> - */
>> -bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> +static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
>> +{
>> + unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>> + unsigned long val;
>> +
>> + switch (psci_fn) {
>> + case KVM_PSCI_0_2_FN_PSCI_VERSION:
>> + /*
>> + * Bits[31:16] = Major Version = 0
>> + * Bits[15:0] = Minor Version = 2
>> + */
>> + val = 2;
>> + break;
>> + case KVM_PSCI_0_2_FN_CPU_OFF:
>> + kvm_psci_vcpu_off(vcpu);
>> + val = KVM_PSCI_RET_SUCCESS;
>> + break;
>> + case KVM_PSCI_0_2_FN_CPU_ON:
>> + case KVM_PSCI_0_2_FN64_CPU_ON:
>> + val = kvm_psci_vcpu_on(vcpu);
>> + break;
>> + case KVM_PSCI_0_2_FN_CPU_SUSPEND:
>> + case KVM_PSCI_0_2_FN_AFFINITY_INFO:
>> + case KVM_PSCI_0_2_FN_MIGRATE:
>> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
>> + case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
>> + case KVM_PSCI_0_2_FN_SYSTEM_OFF:
>> + case KVM_PSCI_0_2_FN_SYSTEM_RESET:
>> + case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
>> + case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
>> + case KVM_PSCI_0_2_FN64_MIGRATE:
>> + case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
>> + val = KVM_PSCI_RET_NOT_SUPPORTED;
>> + break;
>> + default:
>> + return false;
>> + }
>> +
>> + *vcpu_reg(vcpu, 0) = val;
>> + return true;
>> +}
>> +
>> +static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
>> {
>> unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
>> unsigned long val;
>> @@ -109,9 +141,8 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> break;
>> case KVM_PSCI_FN_CPU_SUSPEND:
>> case KVM_PSCI_FN_MIGRATE:
>> - val = KVM_PSCI_RET_NI;
>> + val = KVM_PSCI_RET_NOT_SUPPORTED;
>> break;
>> -
>> default:
>> return false;
>> }
>> @@ -119,3 +150,21 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> *vcpu_reg(vcpu, 0) = val;
>> return true;
>> }
>> +
>> +/**
>> + * kvm_psci_call - handle PSCI call if r0 value is in range
>> + * @vcpu: Pointer to the VCPU struct
>> + *
>> + * Handle PSCI calls from guests through traps from HVC instructions.
>> + * The calling convention is similar to SMC calls to the secure world where
>> + * the function number is placed in r0 and this function returns true if the
>> + * function number specified in r0 is withing the PSCI range, and false
>> + * otherwise.
>> + */
>> +bool kvm_psci_call(struct kvm_vcpu *vcpu)
>> +{
>> + if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
>> + return kvm_psci_0_2_call(vcpu);
>> +
>> + return kvm_psci_0_1_call(vcpu);
>> +}
>
> Why don't we just try one after the other? Do they conflict in some
> way?
>
> I assume PSCI calls are never going to be in the critical path and calls
> into PSCI are pretty much expected to be slow as a dog anyhow, so if we
> could avoid the extra churn in user space code and potential user
> confusion (providing PSCI 0.2 kernel but too old user space tool for
> example), I think that would be preferred.
I gave more thought to this.
Currently, there is no conflict of function IDs between PSCI v0.1 and v0.2
but what if in future some new PSCI vX.Y comes-up with function IDs which
conflict with existing PSCI vA.B.
I think it is very likely that we will have more versions of PSCI and each
subsequent of version of PSCI will generally extend functions IDs defined
by PSCI v0.2
I will keep the KVM_ARM_VCPU_PSCI_0_2 feature for v2 patchset and
wait for more comments on this.
Regards,
Anup
>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 0a1d697..92242ce 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -39,7 +39,7 @@
>> #include <kvm/arm_vgic.h>
>> #include <kvm/arm_arch_timer.h>
>>
>> -#define KVM_VCPU_MAX_FEATURES 2
>> +#define KVM_VCPU_MAX_FEATURES 3
>>
>> struct kvm_vcpu;
>> int kvm_target_cpu(void);
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> index d9f026b..0eb254d 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -77,6 +77,7 @@ struct kvm_regs {
>>
>> #define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
>> #define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
>> +#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
>>
>> struct kvm_vcpu_init {
>> __u32 target;
>> @@ -150,7 +151,7 @@ struct kvm_arch_memory_slot {
>> /* Highest supported SPI, from VGIC_NR_IRQS */
>> #define KVM_ARM_IRQ_GIC_MAX 127
>>
>> -/* PSCI interface */
>> +/* PSCI v0.1 interface */
>> #define KVM_PSCI_FN_BASE 0x95c1ba5e
>> #define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
>>
>> @@ -159,10 +160,42 @@ struct kvm_arch_memory_slot {
>> #define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
>> #define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
>>
>> +/* PSCI v0.2 interface */
>> +#define KVM_PSCI_0_2_FN_BASE 0x84000000
>> +#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
>> +#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
>> +#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
>> +
>> +#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
>> +#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
>> +#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
>> +#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
>> +#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
>> +#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
>> + KVM_PSCI_0_2_FN(6)
>> +#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN(7)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
>> +#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
>> +
>> +#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
>> +#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
>> +#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
>> +#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
>> + KVM_PSCI_0_2_FN64(7)
>> +
>> +/* PSCI return values */
>> #define KVM_PSCI_RET_SUCCESS 0
>> -#define KVM_PSCI_RET_NI ((unsigned long)-1)
>> -#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
>> +#define KVM_PSCI_RET_NOT_SUPPORTED ((unsigned long)-1)
>> +#define KVM_PSCI_RET_INVALID_PARAMS ((unsigned long)-2)
>> #define KVM_PSCI_RET_DENIED ((unsigned long)-3)
>> +#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
>> +#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
>> +#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
>> +#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
>> +#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
>>
>> #endif
>>
>> --
>> 1.7.9.5
>>
>
> Thanks,
> --
> Christoffer
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with Linus' tree
From: Kevin Hilman @ 2014-01-30 5:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130111919.afc7f4e5b58e409aaabf7550@canb.auug.org.au>
On Wed, Jan 29, 2014 at 4:19 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> drivers/clk/Makefile between commit fd3fdaf09f26 ("clk: sort Makefile")
> from Linus' tree and commit 7ee2c5117483 ("clk: bcm281xx: add initial
> clock framework support") from the arm-soc tree.
Ugh. Looks like some last minute cleanup stuff went into clk-next
that didn't spend time in linux-next, and now causes conflicts with
some clk stuff we still have queued in arm-soc (ack'd by Mike.)
Now, based on the Hulk's response to Mike's pull request, if we submit
this, introducing yet more conflicts in the Makefile, it will surely
be Hulk angry, Hulk smash.
Kevin
^ permalink raw reply
* [PATCH v2 0/2] drivers/media: Add controls for Horizontal and Vertical MV Search Range
From: Amit Grover @ 2014-01-30 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0ED10.2020901@samsung.com>
Based on 'master' branch of Linux-next.
This is v2 version for the patch:
s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
(https://lkml.org/lkml/2013/12/30/83)
Changes from v1:
1) Splitted the patch into v4l2 and mfc driver patches.
2) Incorporated review comments of v1
Amit Grover (2):
drivers/media: v4l2: Add settings for Horizontal and Vertical MV
Search Range
drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range
Documentation/DocBook/media/v4l/controls.xml | 20 +++++++++++++++++++
drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 1 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++++++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 ++------
drivers/media/v4l2-core/v4l2-ctrls.c | 14 +++++++++++++
include/uapi/linux/v4l2-controls.h | 2 ++
7 files changed, 65 insertions(+), 6 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/2] drivers/media: v4l2: Add settings for Horizontal and Vertical MV Search Range
From: Amit Grover @ 2014-01-30 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391060563-27015-1-git-send-email-amit.grover@samsung.com>
Adding V4L2 controls for horizontal and vertical search range in pixels
for motion estimation module in video encoder.
Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
Signed-off-by: Amit Grover <amit.grover@samsung.com>
---
Documentation/DocBook/media/v4l/controls.xml | 20 ++++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 14 ++++++++++++++
include/uapi/linux/v4l2-controls.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..be04d18 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
VBV buffer control.</entry>
</row>
+ <row><entry></entry></row>
+ <row id=""v4l2-mpeg-video-hor-search-range">
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry>
+ <entry>integer</entry>
+ </row>
+ <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+horizontal search range for motion estimation module in video encoder.</entry>
+ </row>
+
+ <row><entry></entry></row>
+ <row id="v4l2-mpeg-video-vert-search-range">
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry>
+ <entry>integer</entry>
+ </row>
+ <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+vertical search range for motion estimation module in video encoder.</entry>
+ </row>
+
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index fb46790..e775388 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV Control";
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: return "Horizontal MV Search Range";
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return "Vertical MV Search Range";
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence Header";
/* VPX controls */
@@ -905,6 +907,18 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
*min = 0;
*max = *step = 1;
break;
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *min = 16;
+ *max = 128;
+ *step = 16;
+ break;
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *min = 16;
+ *max = 128;
+ *step = 16;
+ break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
case V4L2_CID_FLASH_STROBE:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 1666aab..80e1def 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -372,6 +372,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
#define V4L2_CID_MPEG_VIDEO_DEC_FRAME (V4L2_CID_MPEG_BASE+224)
#define V4L2_CID_MPEG_VIDEO_VBV_DELAY (V4L2_CID_MPEG_BASE+225)
#define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (V4L2_CID_MPEG_BASE+226)
+#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
+#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
#define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP (V4L2_CID_MPEG_BASE+300)
#define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP (V4L2_CID_MPEG_BASE+301)
--
1.7.9.5
^ permalink raw reply related
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