Re: [PATCH v2] clk: exynos5420: fix cpll clock register offsets
Hi Mike,
On 22 October 2013 11:20, Chander Kashyap wrote:
> On 16 October 2013 11:10, Chander Kashyap wrote:
>> On 26 September 2013 14:36, Chander Kashyap
>> wrote:
>>> Fixes cpll control and lock register offset values for Exynos5420 SoC.
>>>
>>> Signed-off-by: Chander Kashyap
>>> Acked-by: Kukjin Kim
>>> ---
>>> Changes Since v1:
>>> - Fixed patch subject as per Kukgin suggestion.
>>>
>>> drivers/clk/samsung/clk-exynos5420.c |4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 86dfc64..892aac0 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -730,8 +730,8 @@ struct samsung_gate_clock exynos5420_gate_clks[]
>>> __initdata = {
>>> struct __initdata samsung_pll_clock exynos5420_plls[nr_plls] = {
>>> [apll] = PLL(pll_2550, fout_apll, "fout_apll", "fin_pll", APLL_LOCK,
>>> APLL_CON0, NULL),
>>> - [cpll] = PLL(pll_2550, fout_mpll, "fout_mpll", "fin_pll", MPLL_LOCK,
>>> - MPLL_CON0, NULL),
>>> + [cpll] = PLL(pll_2550, fout_cpll, "fout_cpll", "fin_pll", CPLL_LOCK,
>>> + CPLL_CON0, NULL),
>>> [dpll] = PLL(pll_2550, fout_dpll, "fout_dpll", "fin_pll", DPLL_LOCK,
>>> DPLL_CON0, NULL),
>>> [epll] = PLL(pll_2650, fout_epll, "fout_epll", "fin_pll", EPLL_LOCK,
>>> --
>>> 1.7.9.5
>>>
>>
>>
>> Mike, can you please take this patch.
>
> Can this patch be merged?
Any update on this patch ?
>
>>
>> --
>> with warm regards,
>> Chander Kashyap
>
>
>
> --
> with warm regards,
> Chander Kashyap
--
with warm regards,
Chander Kashyap
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] clk: exynos5410: register clocks using common clock framework
From: Tarek Dakhran
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
---
.../devicetree/bindings/clock/exynos5410-clock.txt | 54 +
drivers/clk/samsung/Makefile | 1 +
drivers/clk/samsung/clk-exynos5410.c | 239 +
include/dt-bindings/clock/exynos5410.h | 32 +++
4 files changed, 326 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
create mode 100644 drivers/clk/samsung/clk-exynos5410.c
create mode 100644 include/dt-bindings/clock/exynos5410.h
diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..604a75c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,54 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be "samsung,exynos5410-clock"
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+
+There is clock that is generated outside the SoC. It is expected
+that it is defined using standard clock bindings with following
+clock-output-name:
+ - "fin_pll" - PLL input clock - required.
+
+Example 1: An example of a clock controller node is listed below.
+
+ clock: clock-controller@0x1001 {
+ compatible = "samsung,exynos5410-clock";
+ reg = <0x1001 0x3>;
+ #clock-cells = <1>;
+ };
+
+Example 2: Required external clock.
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ clock-output-names = "fin_pll";
+ };
+
+Example 3: UART controller node that consumes the clock generated by the clock
+ controller. Refer to the standard clock bindings for information
+ about 'clocks' and 'clock-names' property.
+
+ serial@12C2 {
+ compatible = "samsung,exynos4210-uart";
+ reg = <0x12C0 0x100>;
+ interrupts = <0 51 0>;
+ clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
+ clock-names = "uart", "clk_uart_baud0";
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..b572dd7 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_COMMON_CLK) += clk.o clk-pll.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
+obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos5410.c
b/drivers/clk/samsung/clk-exynos5410.c
new file mode 100644
index 000..33d8c8c
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -0,0 +1,239 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran
+ *
+ * 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.
+ *
+ * Common Clock Framework support for Exynos5410 SoC.
+*/
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+#define APLL_LOCK 0x0
+#define APLL_CON0 0x100
+#define CPLL_LOCK 0x10020
+#define CPLL_CON0 0x10120
+#define MPLL_LOCK 0x4000
+#define MPLL_CON0 0x4100
+#define BPLL_LOCK 0x20010
+#define BPLL_CON0 0x20110
+#define KPLL_LOCK 0x28000
+#define KPLL_CON0 0x28100
+
+#define SRC_CPU0x200
+#define DIV_CPU0 0x500
+#define SRC_CPERI1 0x4204
+#define DIV_TOP0 0x10510
+#define DIV_TOP1 0x10514
+#define DIV_FSYS1 0x1054c
+#define DIV_FSYS2 0x10550
+#define DIV_PERIC0 0x10558
+#define SRC_TOP0 0x10210
+#define SRC_TOP1 0x10214
+#define SRC_TOP2 0x10218
+#define SRC_FSYS 0x10244
+#define SRC_PERIC0 0x10250
+#define SRC_MASK_FSYS 0x10340
+#define SRC_MASK_PERIC00x10350
+#define GATE_BUS_FSYS0
[PATCH v4 0/4] Exynos 5410 Dual cluster support
The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.13-rc1. Has been tested on Exynos 5410 reference board (exynos_defconfig). Thanks for all your comments to Tomasz Figa, Dave Martin and Nicolas Pitre. Vyacheslav. Changelog: v4: In arch/arm/mach-exynos/edcs.c 1. Renamed all exynos_ prefixes to edcs_. 2. Reworked edcs_core_power_up/down functions. 3. Removed exynos_core_power_control function. 4. Added this_core_to_pcpu function. 5. Added core_power_state function which detects if cpu is being reset. 6. Replaced cache flush sequences with v7_exit_coherency_flush(). 7. exynos_core_power_down moved to lock protected area. 8. edcs_power_down_finish implemented. In Documentation/devicetree/bindings/clock/exynos5410-clock.txt 1. External clocks documented. In arch/arm/boot/dts/exynos5410-smdk5410.dts 1. oscclk node corrected according to ePAPR recommendation. In arch/arm/boot/dts/exynos5410.dtsi 1. mct@101C node renamed to timer@101C. 2. "interrupt-controller" line removed from mct node. 3. mct_map renamed to interrupt_map. In arch/arm/mach-exynos/Kconfig 1. some cosmetic corrections. In include/dt-bindings/clock/exynos5410.h 1. Unnecessary defines removed. v3: In drivers/clk/samsung/clk-exynos5410.c 1. Fixed rate clock "samsung,clock-oscclk" removed. In arch/arm/boot/dts/exynos5410.dtsi 1. In mct node clock CLK_FIN_PLL replaced with generic fixed rate oscclk. In arch/arm/boot/dts/exynos5410-smdk5410.dts 1. Fixed rate oscclk clock added. In arch/arm/mach-exynos/edcs.c 1. Added write memory barrier in exynos_core_power_control function. 2. __raw_readl/__raw_writel replaced with readl_relaxed/writel_relaxed. 3. #define added for some magic constants. 4. Disabled the GIC CPU interface in exynos_power_down function. v2: In drivers/clk/samsung/clk-exynos5410.c 1. Clock driver converted to use preprocessor macros instead of enums. Clock IDs now defined in include/dt-bindings/clock/exynos5410.h. 2. Unused spinlock removed. 3. Function exynos5410_clk_init defined as static. Struct exynos5410_fixed_rate_ext_clks defined as static. Struct exynos5410_mux_clks defined as static. Struct exynos5410_div_clks defined as static. Struct exynos5410_gate_clks defined as static. 4. Removed aliases. 5. Pll's magic register offsets defined as preprocessor macros. 6. Redundant check of device_node pointer removed. In arch/arm/boot/dts/exynos5410.dtsi 1. dwmmcX nodes renamed to mmc. dwmmc_X renamed to mmc_X. dwmmc status="disabled" field added. fifo-depth field moved from arch/arm/boot/dts/exynos5410-smdk5410.dts 2. Blank lines added where necessary. 3. cpu@ suffixes corrected. 4. edcs node removed. 5. Hexadecimal characters case corrected. 6. Clock IDs replaced with preprocessor macros. In arch/arm/boot/dts/exynos5410-smdk5410.dts 1. status = "okay" field added to mmc nodes. In arch/arm/mach-exynos/edcs.c 1. "kfs_" prefix replaced with "edcs_" 2. EDCS_CPUS_PER_CLUSTER and EDCS_CLUSTERS defined instead of MCPM's values. 3. Cache handling sequence borrowed from arch/arm/mach-vexpress/tc2_pm.c 4. mcpm_sync_init() call added. 5. power management functions reworked. Other 1. Documentation/devicetree/bindings/clock/exynos5410-clock.txt corrected. 2. Removed smdk5410_defconfig. Instead SOC_EXYNOS5410 now selects MCPM and ARM_CCI in arch/arm/mach-exynos/Kconfig. 3. edcs_status driver removed. Tarek Dakhran (4): ARM: EXYNOS: Add support for EXYNOS5410 SoC clk: exynos5410: register clocks using common clock framework ARM: dts: Add initial device tree support for EXYNOS5410 ARM: EXYNOS: add Exynos Dual Cluster Support .../devicetree/bindings/clock/exynos5410-clock.txt | 54 arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/exynos5410-smdk5410.dts | 72 + arch/arm/boot/dts/exynos5410.dtsi | 207 ++ arch/arm/mach-exynos/Kconfig | 12 + arch/arm/mach-exynos/Makefile | 2 + arch/arm/mach-exynos/common.c | 18 ++ arch/arm/mach-exynos/edcs.c| 297 + arch/arm/mach-exynos/include/mach/map.h| 1 + arch/arm/mach-exynos/mach-exynos5-dt.c | 1 + arch/arm/plat-samsung/include/plat/cpu.h | 8 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos5410.c | 239 + include/dt-bindings/clock/exynos5410.h | 32 +++ 14 files changed, 945 insertions(+) create mode
[PATCH v4 1/4] ARM: EXYNOS: Add support for EXYNOS5410 SoC
From: Tarek Dakhran
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.
Signed-off-by: Tarek Dakhran
Reviewed-by: Tomasz Figa
Signed-off-by: Vyacheslav Tyrtov
---
arch/arm/mach-exynos/Kconfig | 12
arch/arm/mach-exynos/common.c| 18 ++
arch/arm/mach-exynos/include/mach/map.h | 1 +
arch/arm/mach-exynos/mach-exynos5-dt.c | 1 +
arch/arm/plat-samsung/include/plat/cpu.h | 8
5 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index f9d67a0..ae03ebb 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -93,6 +93,18 @@ config SOC_EXYNOS5250
help
Enable EXYNOS5250 SoC support
+config SOC_EXYNOS5410
+ bool "SAMSUNG EXYNOS5410"
+ default y
+ depends on ARCH_EXYNOS5
+ select ARM_CCI
+ select MCPM
+ select PM_GENERIC_DOMAINS if PM_RUNTIME
+ select S5P_PM if PM_SLEEP
+ select S5P_SLEEP if PM_SLEEP
+ help
+ Enable EXYNOS5410 SoC support
+
config SOC_EXYNOS5420
bool "SAMSUNG EXYNOS5420"
default y
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 61d2906..4768608 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -52,6 +52,7 @@ static const char name_exynos4210[] = "EXYNOS4210";
static const char name_exynos4212[] = "EXYNOS4212";
static const char name_exynos4412[] = "EXYNOS4412";
static const char name_exynos5250[] = "EXYNOS5250";
+static const char name_exynos5410[] = "EXYNOS5410";
static const char name_exynos5420[] = "EXYNOS5420";
static const char name_exynos5440[] = "EXYNOS5440";
@@ -85,6 +86,12 @@ static struct cpu_table cpu_ids[] __initdata = {
.init = exynos_init,
.name = name_exynos5250,
}, {
+ .idcode = EXYNOS5410_SOC_ID,
+ .idmask = EXYNOS5_SOC_MASK,
+ .map_io = exynos5_map_io,
+ .init = exynos_init,
+ .name = name_exynos5410,
+ }, {
.idcode = EXYNOS5420_SOC_ID,
.idmask = EXYNOS5_SOC_MASK,
.map_io = exynos5_map_io,
@@ -215,6 +222,15 @@ static struct map_desc exynos4x12_iodesc[] __initdata = {
},
};
+static struct map_desc exynos5410_iodesc[] __initdata = {
+ {
+ .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+ .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+ .length = SZ_4K,
+ .type = MT_DEVICE,
+ },
+};
+
static struct map_desc exynos5250_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_SYSRAM_NS,
@@ -374,6 +390,8 @@ static void __init exynos5_map_io(void)
if (soc_is_exynos5250())
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
+ if (soc_is_exynos5410())
+ iotable_init(exynos5410_iodesc, ARRAY_SIZE(exynos5410_iodesc));
}
struct bus_type exynos_subsys = {
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..894f431 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -29,6 +29,7 @@
#define EXYNOS4210_PA_SYSRAM_NS0x0203F000
#define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
#define EXYNOS5250_PA_SYSRAM_NS0x0204F000
+#define EXYNOS5410_PA_SYSRAM_NS0x02073000
#define EXYNOS_PA_CHIPID 0x1000
diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
b/arch/arm/mach-exynos/mach-exynos5-dt.c
index 1fe075a..7f78f66 100644
--- a/arch/arm/mach-exynos/mach-exynos5-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
@@ -50,6 +50,7 @@ static void __init exynos5_dt_machine_init(void)
static char const *exynos5_dt_compat[] __initdata = {
"samsung,exynos5250",
+ "samsung,exynos5410",
"samsung,exynos5420",
"samsung,exynos5440",
NULL
diff --git a/arch/arm/plat-samsung/include/plat/cpu.h
b/arch/arm/plat-samsung/include/plat/cpu.h
index 335beb3..8f09488 100644
--- a/arch/arm/plat-samsung/include/plat/cpu.h
+++ b/arch/arm/plat-samsung/include/plat/cpu.h
@@ -46,6 +46,7 @@ extern unsigned long samsung_cpu_id;
#define EXYNOS4_CPU_MASK 0xFFFE
#define EXYNOS5250_SOC_ID 0x4352
+#define EXYNOS5410_SOC_ID 0xE541
#define EXYNOS5420_SOC_ID 0xE542
#define EXYNOS5440_SOC_ID 0xE544
#define EXYNOS5_SOC_MASK 0xF000
@@ -68,6 +69,7 @@ IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID,
EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
IS_SAMSUNG_CPU(exynos525
[PATCH v4 3/4] ARM: dts: Add initial device tree support for EXYNOS5410
From: Tarek Dakhran
Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board.
Signed-off-by: Tarek Dakhran
Reviewed-by: Tomasz Figa
Signed-off-by: Vyacheslav Tyrtov
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/exynos5410-smdk5410.dts | 72 +++
arch/arm/boot/dts/exynos5410.dtsi | 207 ++
3 files changed, 280 insertions(+)
create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
create mode 100644 arch/arm/boot/dts/exynos5410.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d57c1a6..b947387 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -63,6 +63,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+ exynos5410-smdk5410.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
new file mode 100644
index 000..7ffd351
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -0,0 +1,72 @@
+/*
+ * SAMSUNG SMDK5410 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include "exynos5410.dtsi"
+/ {
+ model = "Samsung SMDK5410 board based on EXYNOS5410";
+ compatible = "samsung,smdk5410", "samsung,exynos5410";
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=ttySAC2,115200";
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fin_pll: clock-fin-pll {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ clock-output-names = "fin_pll";
+ };
+ };
+
+ mmc@1220 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ broken-cd;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <8>;
+ };
+ };
+
+ mmc@1222 {
+ status = "okay";
+ num-slots = <1>;
+ supports-highspeed;
+ card-detect-delay = <200>;
+ samsung,dw-mshc-ciu-div = <3>;
+ samsung,dw-mshc-sdr-timing = <2 3>;
+ samsung,dw-mshc-ddr-timing = <1 2>;
+
+ slot@0 {
+ reg = <0>;
+ bus-width = <4>;
+ disable-wp;
+ };
+ };
+
+};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..fce54f8
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,207 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * 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
+#include "exynos5.dtsi"
+/ {
+ compatible = "samsung,exynos5410";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ cci-control-port = <&cci_control2>;
+ clock-frequency = <16>;
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ cci-control-port = <&cci_control2>;
+ clock-frequency = <16>;
+ };
+
+ CPU2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <2>;
+
[PATCH v4 4/4] ARM: EXYNOS: add Exynos Dual Cluster Support
From: Tarek Dakhran
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
Signed-off-by: Tarek Dakhran
Signed-off-by: Vyacheslav Tyrtov
---
arch/arm/mach-exynos/Makefile | 2 +
arch/arm/mach-exynos/edcs.c | 297 ++
2 files changed, 299 insertions(+)
create mode 100644 arch/arm/mach-exynos/edcs.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 8930b66..bc1f7f9 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
obj-$(CONFIG_ARCH_EXYNOS4) += mach-exynos4-dt.o
obj-$(CONFIG_ARCH_EXYNOS5) += mach-exynos5-dt.o
+
+obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
new file mode 100644
index 000..29f0bdd
--- /dev/null
+++ b/arch/arm/mach-exynos/edcs.c
@@ -0,0 +1,297 @@
+/*
+ * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran
+ *
+ * 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.
+ *
+ * EDCS(exynos dual cluster support) for Exynos5410 SoC.
+ */
+
+#define pr_fmt(fmt)"%s: " fmt, __func__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define EDCS_CPUS_PER_CLUSTER 4
+#define EDCS_CLUSTERS 2
+
+/* Exynos5410 power management registers */
+#define EDCS_CORE_CONFIGURATION(_nr) (S5P_ARM_CORE0_CONFIGURATION\
+ + ((_nr) * 0x80))
+#define EDCS_CORE_STATUS(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x4)
+#define EDCS_CORE_OPTION(_nr) (EDCS_CORE_CONFIGURATION(_nr) + 0x8)
+
+#define REG_CPU_STATE_ADDR0(S5P_VA_SYSRAM_NS + 0x28)
+#define REG_CPU_STATE_ADDR(_nr)(REG_CPU_STATE_ADDR0 + \
+(_nr) * EDCS_CPUS_PER_CLUSTER)
+
+#define SECONDARY_RESET(1 << 1)
+#define REG_ENTRY_ADDR (S5P_VA_SYSRAM_NS + 0x1c)
+
+#define EDCS_CORE_PWR_ON 0x3
+#define EDCS_CORE_PWR_OFF 0x0
+#define CORE_PWR_STATE_MASK0x3
+
+static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
+static int core_count[EDCS_CLUSTERS];
+
+/*
+ * this_core_to_pcpu reads mpidr and defines cluster and cpu.
+ */
+static void this_core_to_pcpu(unsigned int *pcpu, unsigned int *pcluster)
+{
+ unsigned int mpidr;
+
+ mpidr = read_cpuid_mpidr();
+ *pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ *pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+}
+
+/*
+ * core_power_state is used to get core power state.
+ * returns:
+ *0x0 - powered off;
+ *0x3 - powered on;
+ *other values - in process;
+ */
+static int core_power_state(unsigned int cpu, unsigned int cluster)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ int status = readl_relaxed(EDCS_CORE_STATUS(offset));
+
+ return status & CORE_PWR_STATE_MASK;
+}
+
+static void edcs_core_power_up(unsigned int cpu, unsigned int cluster)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ if (core_power_state(cpu, cluster) == EDCS_CORE_PWR_OFF) {
+ /* boot flag should be written before powering up */
+ wmb();
+ writel_relaxed(EDCS_CORE_PWR_ON,
+EDCS_CORE_CONFIGURATION(offset));
+ }
+}
+
+static void edcs_core_power_down(unsigned int cpu, unsigned int cluster)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ if (core_power_state(cpu, cluster) == EDCS_CORE_PWR_ON)
+ writel_relaxed(EDCS_CORE_PWR_OFF,
+EDCS_CORE_CONFIGURATION(offset));
+}
+
+void set_boot_flag(unsigned int cpu, unsigned int mode)
+{
+ writel_relaxed(mode, REG_CPU_STATE_ADDR(cpu));
+}
+
+static int edcs_power_up(unsigned int cpu, unsigned int cluster)
+{
+ pr_debug("cpu %u cluster %u\n", cpu, cluster);
+ BUG_ON(cpu >= EDCS_CPUS_PER_CLUSTER || cluster >= EDCS_CLUSTERS);
+
+ local_irq_disable();
+ arch_spin_lock(&edcs_lock);
+
+ edcs_use_count[cpu][cluster]++;
+ if (edcs_use_count[cpu][cluster] == 1) {
+ ++core_count[cluster];
+ set_boot_flag(cpu, SECONDARY_RESET);
+ edcs_core_power_up(cpu, cluster);
+ } else if (edcs_use_count[cpu][cluster] != 2) {
+ /*
+* The only possible values are:
+
Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init
On Tue, Nov 26, 2013 at 10:54:57AM +0530, Padma Venkat wrote: > > - snd_soc_dai_init_dma_data(dai, &i2s->dma_playback, > > &i2s->dma_capture); > > + samsung_asoc_init_dma_data(dai, &i2s->dma_playback, > > &i2s->dma_capture); > we have to initialize the dma data for i2s secondary dai also > otherwise there is a crash in dmaengine_pcm_new during probe. This should be called when both DAIs are probed... in any case, if this is broken presumably the driver is already broken given that this is just a substitution? I've no systems capable of actually running audio with the later DAIs. signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
On Tue, Nov 26, 2013 at 10:55:17AM +0530, Padma Venkat wrote: > I tested this patch set on smdk5420 i2s. During playback audio playing > fast and there is underrun error like below. > underrun!!! (at least 0.061 ms long) > underrun!!! (at least 0.043 ms long) This sounds like it's setting the transfer width incorrectly, though I can't immediately see how that's changed unless the DMA driver is not working correctly. What exactly did you do to test? signature.asc Description: Digital signature
Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
Hi Mark, On Tue, Nov 26, 2013 at 3:53 PM, Mark Brown wrote: > On Tue, Nov 26, 2013 at 10:55:17AM +0530, Padma Venkat wrote: > >> I tested this patch set on smdk5420 i2s. During playback audio playing >> fast and there is underrun error like below. >> underrun!!! (at least 0.061 ms long) >> underrun!!! (at least 0.043 ms long) > > This sounds like it's setting the transfer width incorrectly, though I > can't immediately see how that's changed unless the DMA driver is not > working correctly. What exactly did you do to test? I tried this on linux-samsung tree by applying all the patches from you and Lars. I initialised the dma_data for secondary dai as there is a crash with out that. Then I used aplay after running the mixer settings. ./aplay /mars/share/sounds/alsa/Front_Center.wav Thanks Padma -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC
On 26 November 2013 09:56, Naveen Krishna Chatradhi
wrote:
> This patch adds new compatible to support HSI2C module on Exynos5260
> HSI2C module on Exynos5260 needs to be reset during during initialization.
>
> Signed-off-by: Naveen Krishna Chatradhi
[snip]
>
> Required properties:
>- compatible: value should be.
> - -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
> + -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available on
> + Exynos5250/5420 SoCs.
This string could be made more specific ("samsung,exynos5250-hsi2c")
now that we have variants for this.
> + -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
> + on Exynos5260 SoCs.
> +
>- reg: physical base address of the controller and length of memory mapped
> region.
>- interrupts: interrupt number to the cpu.
> diff --git a/drivers/i2c/busses/i2c-exynos5.c
> b/drivers/i2c/busses/i2c-exynos5.c
> index da39ff0..497ff91 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -184,14 +184,35 @@ struct exynos5_i2c {
> * 2. Fast speed upto 1Mbps
> */
> int speed_mode;
> +
> + /* Version of HS-I2C Hardware */
> + unsigned intversion;
> +};
> +
> +enum hsi2c_version {
> + EXYNOS_5,
ditto.
> + EXYNOS_5260
> };
>
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC
Hello Sachin,
On 26 November 2013 16:59, Sachin Kamat wrote:
> On 26 November 2013 09:56, Naveen Krishna Chatradhi
> wrote:
>> This patch adds new compatible to support HSI2C module on Exynos5260
>> HSI2C module on Exynos5260 needs to be reset during during initialization.
>>
>> Signed-off-by: Naveen Krishna Chatradhi
> [snip]
>>
>> Required properties:
>>- compatible: value should be.
>> - -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
>> + -> "samsung,exynos5-hsi2c", for i2c compatible with HSI2C available
>> on
>> + Exynos5250/5420 SoCs.
The first HSI2C module is available on Exynos5 SoCs from Samsung.
Hence, "samsung,exynos5-hsi2c"
HSI2C Module on Exynos5250 and Exynos5420 was exactly similar
HSI2C Module on Exynos5260 differs in hardware.
Hence, "samsung,exynos5260-hsi2c".
And as the new variants come we use "samsung,exynosXXX-hsi2c"
or we can go by "samsung,exynos5-hsi2c-v2"
Changing an existing compatible needs modification in the DT nodes as well.
I will change the compatible string, if anyone else also thinks its wise.
>
> This string could be made more specific ("samsung,exynos5250-hsi2c")
> now that we have variants for this.
>
>> + -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C
>> available
>> + on Exynos5260 SoCs.
>> +
>>- reg: physical base address of the controller and length of memory mapped
>> region.
>>- interrupts: interrupt number to the cpu.
>> diff --git a/drivers/i2c/busses/i2c-exynos5.c
>> b/drivers/i2c/busses/i2c-exynos5.c
>> index da39ff0..497ff91 100644
>> --- a/drivers/i2c/busses/i2c-exynos5.c
>> +++ b/drivers/i2c/busses/i2c-exynos5.c
>> @@ -184,14 +184,35 @@ struct exynos5_i2c {
>> * 2. Fast speed upto 1Mbps
>> */
>> int speed_mode;
>> +
>> + /* Version of HS-I2C Hardware */
>> + unsigned intversion;
>> +};
>> +
>> +enum hsi2c_version {
>> + EXYNOS_5,
>
> ditto.
>
>> + EXYNOS_5260
>> };
>>
>
> --
> With warm regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shine bright,
(: Nav :)
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
On Tue, Nov 26, 2013 at 04:18:41PM +0530, Padma Venkat wrote: > I tried this on linux-samsung tree by applying all the patches from > you and Lars. Can you use -next plus the posted patches please in case there's something been misplaced, it'll help if we're working from the same code base? > I initialised the dma_data for secondary dai as there is a crash with out > that. Can you please send a patch for that if you find it's needed? Like I said in reply to your earlier mail it looks like this doesn't work anyway so mainline ought to be fixed. > Then I used aplay after running the mixer settings. > ./aplay /mars/share/sounds/alsa/Front_Center.wav So this is 16 bit stereo or something, and did it work beforehand? Like I say I suspect the DMA is ending up being configured with the wrong transfer size, can you check what actually happens there please - what's different about the configuration that the DMA controller gets? I don't have any Exynos systems with mainline audio support so I can't test anything myself. signature.asc Description: Digital signature
Re: [PATCH V9 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register
Hi Doug,
Thanks for reviewing the patch series.
On Tue, Nov 26, 2013 at 4:14 AM, Doug Anderson wrote:
>
> Hi Leela Krishna,
>
> On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala
> wrote:
> > Add device tree support for exynos5250 and 5420 SoCs and use syscon regmap
> > interface
> > to configure AUTOMATIC_WDT_RESET_DISABLE and MASK_WDT_RESET_REQUEST
> > registers of PMU
> > to mask/unmask enable/disable of watchdog in probe and s2r scenarios.
> >
> > Signed-off-by: Leela Krishna Amudala
> > ---
> > .../devicetree/bindings/watchdog/samsung-wdt.txt | 21 ++-
> > drivers/watchdog/Kconfig |1 +
> > drivers/watchdog/s3c2410_wdt.c | 145
> > ++--
> > 3 files changed, 157 insertions(+), 10 deletions(-)
>
> ...
>
> > +struct s3c2410_wdt_variant {
> > + int disable_reg;
> > + int mask_reset_reg;
> > + int mask_bit;
> > + u32 quirks;
> > +};
>
> Ideally you could add descriptions. I added them in a patch based on
> yours
> ,
> but since yours hasn't landed perhaps you can do it directly?
>
> /**
> * struct s3c2410_wdt_variant - Per-variant config data
> *
> * @disable_reg: Offset in pmureg for the register that disables the watchdog
> * timer reset functionality.
> * @mask_reset_reg: Offset in pmureg for the register that masks the watchdog
> * timer reset functionality.
> * @mask_bit: Bit number for the watchdog timer in the disable register and
> the
> * mask reset register.
> * @quirks: A bitfield of quirks.
> */
>
Okay, Added the above descriptions
> > +
> > struct s3c2410_wdt {
> > struct device *dev;
> > struct clk *clock;
> > @@ -94,7 +107,49 @@ struct s3c2410_wdt {
> > unsigned long wtdat_save;
> > struct watchdog_device wdt_device;
> > struct notifier_block freq_transition;
> > + struct s3c2410_wdt_variant *drv_data;
> > + struct regmap *pmureg;
>
> Total nit, but everything else in this structure is tab aligned and
> your new elements are not.
>
Me and Tomasz had a discussion about it and he replied for this comment
> > static int s3c2410wdt_probe(struct platform_device *pdev)
> > {
> > struct device *dev;
> > @@ -354,6 +443,16 @@ static int s3c2410wdt_probe(struct platform_device
> > *pdev)
> > spin_lock_init(&wdt->lock);
> > wdt->wdt_device = s3c2410_wdd;
> >
> > + wdt->drv_data = get_wdt_drv_data(pdev);
> > + if (wdt->drv_data->quirks & QUIRK_NEEDS_PMU_CONFIG) {
> > + wdt->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
> > +
> > "samsung,syscon-phandle");
> > + if (IS_ERR(wdt->pmureg)) {
> > + dev_err(dev, "syscon regmap lookup failed.\n");
> > + return PTR_ERR(wdt->pmureg);
>
> nit: this function appears to never call "return" directly. You'll
> match other error handling better if you do:
>
> ret = PTR_ERR(wdt->pmureg);
> goto err;
>
> (if someone else has already said they don't like that, just ignore me).
>
Will consider Tomasz suggestion for this
> > + }
> > + }
> > +
> > wdt_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> > if (wdt_irq == NULL) {
> > dev_err(dev, "no irq resource specified\n");
> > @@ -444,6 +543,14 @@ static int s3c2410wdt_probe(struct platform_device
> > *pdev)
> > (wtcon & S3C2410_WTCON_RSTEN) ? "en" : "dis",
> > (wtcon & S3C2410_WTCON_INTEN) ? "en" : "dis");
> >
> > + if (wdt->drv_data->quirks & QUIRK_NEEDS_PMU_CONFIG) {
> > + ret = s3c2410wdt_mask_and_disable_reset(wdt, false);
> > + if (ret < 0) {
> > + dev_err(wdt->dev, "failed to update pmu register");
> > + goto err_cpufreq;
> > + }
> > + }
>
> There are a few minor problems here:
>
> 1. You're putting a potential failure condition _after_ printing that
> the watchdog is enabled. You should put your code above the
> "dev_info".
>
Yes moved it like below
static int s3c2410wdt_probe(struct platform_device *pdev)
{
[snip]
if (tmr_atboot && started == 0) {
dev_info(dev, "starting watchdog timer\n");
s3c2410wdt_start(&wdt->wdt_device);
}
[snip]
> 2. Error handling doesn't seem quite right. If you fail here you'll
> be returning an error but you might have started the watchdog already.
> Perhaps you should be moving the "mask_and_disable" up a little and
> then you an undo it if needed?
>
Above mentioned comment will take care of this
> 3. I think it would be fine to put the "dev_err" directly in the
> s3c2410wdt_mask_and_disable_reset() as per Guenter, but still return
> the error code. You'll still use the error code here, r
Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
On 26-11-2013 02:07, Amit Kachhap wrote: > On 10/4/13, Bartlomiej Zolnierkiewicz wrote: >> Menu for Samsung thermal support is visible on all Samsung >> platforms while thermal drivers are currently available only >> for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency >> with ARCH_EXYNOS one. >> >> Signed-off-by: Bartlomiej Zolnierkiewicz >> Signed-off-by: Kyungmin Park > Looks good, so > Acked-by: Amit Daniel Kachhap I will be queuing this one in my tree. Thanks Bartlomiej. > >> --- >> drivers/thermal/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index a709c63..05cf95c 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -198,7 +198,7 @@ source "drivers/thermal/ti-soc-thermal/Kconfig" >> endmenu >> >> menu "Samsung thermal drivers" >> -depends on PLAT_SAMSUNG >> +depends on ARCH_EXYNOS >> source "drivers/thermal/samsung/Kconfig" >> endmenu >> >> -- >> 1.8.2.3 >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin signature.asc Description: OpenPGP digital signature
Re: [PATCH] video: exynos_mipi_dsim: Remove unused variable
On 2013-11-15 04:52, Sachin Kamat wrote:
> + Tomi
>
> Hi Olof,
>
> On 15 November 2013 02:39, Olof Johansson wrote:
>> commit 7e0be9f9f7cba3356f75b86737dbe3a005da067e ('video: exynos_mipi_dsim:
>> Use the generic PHY driver') resulted in a warning about an unused
>> variable:
>>
>> drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable
>> 'pdev' [-Wunused-variable]
>>
>> It is indeed unused; remove it.
>>
>> Signed-off-by: Olof Johansson
>> Cc: Sylwester Nawrocki
>> ---
>
> I had already sent a similar patch to fix this issue [1] which is
> reviewed by Kishon.
> But the patch that caused the warning was in Greg's tree at that time
> and he wanted
> the follow up patch to go through the video tree. I have pinged Tomi yesterday
> regarding this (now that his tree as well as the original patches are merged).
>
> [1] http://www.spinics.net/lists/linux-fbdev/msg12755.html
>
The one from Olof seems to have been merged, so I'll drop the one from
Sachin in my tree.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V3 4/6] cpufreq: exynos: Use cpufreq_generic_suspend()
On 25 November 2013 19:41, Viresh Kumar wrote:
> Currently we have implemented PM notifiers to disable/enable ->target()
> routines
> functionality during suspend/resume.
>
> Now we have support present in cpufreq core, lets use it.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/exynos-cpufreq.c | 97
> +++-
> 1 file changed, 6 insertions(+), 91 deletions(-)
Jonghwan Choi reported an issue with this patch. He asked me
to look at: 6e45eb
And so following diff is updated for this patch in my repo.. Will get
that fixed in V4:
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 4b6e6a6..3f216da 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -22,8 +22,8 @@
#include "exynos-cpufreq.h"
static struct exynos_dvfs_info *exynos_info;
-
static struct regulator *arm_regulator;
+static unsigned int locking_frequency;
static int exynos_cpufreq_get_index(unsigned int freq)
{
@@ -134,7 +134,7 @@ static int exynos_target(struct cpufreq_policy
*policy, unsigned int index)
static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
policy->clk = exynos_info->cpu_clk;
- policy->suspend_freq = clk_get_rate(exynos_info->cpu_clk) / 1000;
+ policy->suspend_freq = locking_frequency;
return cpufreq_generic_init(policy, exynos_info->freq_table, 10);
}
@@ -182,6 +182,9 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
+ /* Done here as we want to capture boot frequency */
+ locking_frequency = clk_get_rate(exynos_info->cpu_clk) / 1000;
+
if (!cpufreq_register_driver(&exynos_driver))
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On Tue, Nov 26, 2013 at 12:58:08PM +0400, Vyacheslav Tyrtov wrote:
> From: Tarek Dakhran
>
> Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
> This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
>
> Signed-off-by: Tarek Dakhran
> Signed-off-by: Vyacheslav Tyrtov
> ---
> arch/arm/mach-exynos/Makefile | 2 +
> arch/arm/mach-exynos/edcs.c | 297
> ++
> 2 files changed, 299 insertions(+)
> create mode 100644 arch/arm/mach-exynos/edcs.c
>
> diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
> index 8930b66..bc1f7f9 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
>
> obj-$(CONFIG_ARCH_EXYNOS4) += mach-exynos4-dt.o
> obj-$(CONFIG_ARCH_EXYNOS5) += mach-exynos5-dt.o
> +
> +obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
> diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
> new file mode 100644
> index 000..29f0bdd
> --- /dev/null
> +++ b/arch/arm/mach-exynos/edcs.c
> @@ -0,0 +1,297 @@
> +/*
> + * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
> + *
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * Author: Tarek Dakhran
> + *
> + * 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.
> + *
> + * EDCS(exynos dual cluster support) for Exynos5410 SoC.
> + */
> +
> +#define pr_fmt(fmt) "%s: " fmt, __func__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define EDCS_CPUS_PER_CLUSTER4
> +#define EDCS_CLUSTERS2
> +
> +/* Exynos5410 power management registers */
> +#define EDCS_CORE_CONFIGURATION(_nr) (S5P_ARM_CORE0_CONFIGURATION\
> + + ((_nr) * 0x80))
> +#define EDCS_CORE_STATUS(_nr)(EDCS_CORE_CONFIGURATION(_nr) +
> 0x4)
> +#define EDCS_CORE_OPTION(_nr)(EDCS_CORE_CONFIGURATION(_nr) +
> 0x8)
> +
> +#define REG_CPU_STATE_ADDR0 (S5P_VA_SYSRAM_NS + 0x28)
> +#define REG_CPU_STATE_ADDR(_nr) (REG_CPU_STATE_ADDR0 + \
> + (_nr) * EDCS_CPUS_PER_CLUSTER)
> +
> +#define SECONDARY_RESET (1 << 1)
> +#define REG_ENTRY_ADDR (S5P_VA_SYSRAM_NS + 0x1c)
> +
> +#define EDCS_CORE_PWR_ON 0x3
> +#define EDCS_CORE_PWR_OFF0x0
> +#define CORE_PWR_STATE_MASK 0x3
> +
> +static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> +
> +static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
> +static int core_count[EDCS_CLUSTERS];
> +
> +/*
> + * this_core_to_pcpu reads mpidr and defines cluster and cpu.
> + */
> +static void this_core_to_pcpu(unsigned int *pcpu, unsigned int *pcluster)
> +{
> + unsigned int mpidr;
> +
> + mpidr = read_cpuid_mpidr();
> + *pcpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> + *pcluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
> +}
> +
> +/*
> + * core_power_state is used to get core power state.
> + * returns:
> + *0x0 - powered off;
> + *0x3 - powered on;
> + *other values - in process;
> + */
> +static int core_power_state(unsigned int cpu, unsigned int cluster)
> +{
> + unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
> + int status = readl_relaxed(EDCS_CORE_STATUS(offset));
> +
> + return status & CORE_PWR_STATE_MASK;
> +}
> +
> +static void edcs_core_power_up(unsigned int cpu, unsigned int cluster)
> +{
> + unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
> + if (core_power_state(cpu, cluster) == EDCS_CORE_PWR_OFF) {
This still looks racy.
edcs_core_power_up and edcs_core_power_down are both called with
edcs_lock held, and cluster/cpu ref counting is done before we
get here. So we know that the power state *change* is really supposed
to happen.
*If* my assumption is correct that there is a delay between requesting a
new power state, and the change being reported as completed in
EDCS_CORE_STATUS:
For edcs_core_power_up(), there may be a pending power-down
request which is not visible in the EDCS_CORE_STATUS registers yet.
I think this may mean that a power-up request will simply be missed
if the core status does not read as EDCS_CORE_PWR_OFF yet. If that
can happen, then you need to wait -- calling the power_down_finish
method may be the right thing to do.
However, we cannot sleep here because edcs_lock is held and IRQs
are masked. It may make sense to factor the status check out of
power_down_finish and make it a separate function, then make
edcs_core_power_up() return an error code to edcs_power_u
Re: [PATCH v2] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ
On 11/25/2013 03:36 PM, Doug Anderson wrote: On modern SoCs the watchdog timer is parented on a clock that doesn't change every time we have a cpufreq change. That means we don't need to constantly adjust the watchdog timer, so avoid registering for and dealing with cpufreq transitions unless we've actually got CONFIG_ARM_S3C24XX_CPUFREQ defined. Note that this is more than just an optimization. The s3c2410 watchdog driver actually pats the watchdog on every CPU frequency change. On modern systems these happen many times per second (even in a system where "nothing" is happening). That effectively makes any userspace watchdog program useless (the watchdog is constantly patted by the kernel). If we need ARM_S3C24XX_CPUFREQ defined on a multiplatform kernel we'll need to make sure that kernel supports common clock and change this to user common clock framework. Signed-off-by: Doug Anderson Reviewed-by: Guenter Roeck -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.
Specifically if you had a timeout of 32 seconds and an input clock of
, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.
Specifically DBG printouts showed:
s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656 (ff4f)
and the final timeout reported to the user was:
((count / divisor) * divisor) / freq
(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
(0xff4f * 255) / (.0 / 128) = 31.9998
By using "DIV_ROUND_UP" we can be a little more correct.
s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688 (ff50)
and the final timeout reported to the user:
(0xff50 * 255) / 520834 = 32
the technically "correct" value is:
(0xff50 * 255) / (.0 / 128) = 32.0003
We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.
Signed-off-by: Doug Anderson
---
drivers/watchdog/s3c2410_wdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..fe2322b 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct watchdog_device
*wdd, unsigned timeou
if (timeout < 1)
return -EINVAL;
- freq /= 128;
+ freq = DIV_ROUND_UP(freq, 128);
count = timeout * freq;
DBG("%s: count=%d, timeout=%d, freq=%lu\n",
@@ -201,20 +201,20 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
if (count >= 0x1) {
for (divisor = 1; divisor <= 0x100; divisor++) {
- if ((count / divisor) < 0x1)
+ if (DIV_ROUND_UP(count, divisor) < 0x1)
break;
}
- if ((count / divisor) >= 0x1) {
+ if (divisor > 0x100) {
dev_err(wdt->dev, "timeout %d too big\n", timeout);
return -EINVAL;
}
}
DBG("%s: timeout=%d, divisor=%d, count=%d (%08x)\n",
- __func__, timeout, divisor, count, count/divisor);
+ __func__, timeout, divisor, count, DIV_ROUND_UP(count, divisor));
- count /= divisor;
+ count = DIV_ROUND_UP(count, divisor);
wdt->count = count;
/* update the pre-scaler */
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
On 11/26/2013 10:30 AM, Doug Anderson wrote:
The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.
Specifically if you had a timeout of 32 seconds and an input clock of
, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.
Specifically DBG printouts showed:
s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656 (ff4f)
and the final timeout reported to the user was:
((count / divisor) * divisor) / freq
(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
(0xff4f * 255) / (.0 / 128) = 31.9998
By using "DIV_ROUND_UP" we can be a little more correct.
s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688 (ff50)
and the final timeout reported to the user:
(0xff50 * 255) / 520834 = 32
the technically "correct" value is:
(0xff50 * 255) / (.0 / 128) = 32.0003
We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.
Signed-off-by: Doug Anderson
---
drivers/watchdog/s3c2410_wdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..fe2322b 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct watchdog_device
*wdd, unsigned timeou
if (timeout < 1)
return -EINVAL;
- freq /= 128;
+ freq = DIV_ROUND_UP(freq, 128);
count = timeout * freq;
DBG("%s: count=%d, timeout=%d, freq=%lu\n",
@@ -201,20 +201,20 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
if (count >= 0x1) {
for (divisor = 1; divisor <= 0x100; divisor++) {
- if ((count / divisor) < 0x1)
+ if (DIV_ROUND_UP(count, divisor) < 0x1)
break;
}
Since you are at it,
divisor = DIV_ROUND_UP(count + 1, 0x1);
might be faster, simpler, and easier to understand than the loop.
Otherwise looks good to me.
Guenter
- if ((count / divisor) >= 0x1) {
+ if (divisor > 0x100) {
dev_err(wdt->dev, "timeout %d too big\n", timeout);
return -EINVAL;
}
}
DBG("%s: timeout=%d, divisor=%d, count=%d (%08x)\n",
- __func__, timeout, divisor, count, count/divisor);
+ __func__, timeout, divisor, count, DIV_ROUND_UP(count, divisor));
- count /= divisor;
+ count = DIV_ROUND_UP(count, divisor);
wdt->count = count;
/* update the pre-scaler */
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
> On 26 November 2013 04:59, Rafael J. Wysocki wrote:
> >> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> >>
> >> might_sleep();
> >>
> >> + cpufreq_suspend();
> >> +
> >>
> >> mutex_lock(&dpm_list_mtx);
> >> pm_transition = state;
> >> async_error = 0;
> >
> > Shouldn't it do cpufreq_resume() on errors?
>
> Yes and this is already done I believe. In case dpm_suspend() fails,
> dpm_resume() gets called. Isn't it?
OK
> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> >> +void cpufreq_suspend(void)
> >> +{
> >> + struct cpufreq_policy *policy;
> >> +
> >> + if (!has_target())
> >> + return;
> >> +
> >> + pr_debug("%s: Suspending Governors\n", __func__);
> >> +
> >> + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> >> + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> >> + pr_err("%s: Failed to stop governor for policy:
> >> %p\n",
> >> + __func__, policy);
> >
> > This appears to be racy. Is it really racy, or just seemingly?
>
> Why does it look racy to you? Userspace should be frozen by now,
> policy_list should be stable as well as nobody would touch it.
You're stopping governors while they may be in use in principle. Do we have
suitable synchronization in place for that?
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
Guenter,
On Tue, Nov 26, 2013 at 10:48 AM, Guenter Roeck wrote:
> On 11/26/2013 10:30 AM, Doug Anderson wrote:
>>
>> The existing watchdog timeout worked OK but didn't deal with
>> rounding in an ideal way when dividing out all of its clocks.
>>
>> Specifically if you had a timeout of 32 seconds and an input clock of
>> , you'd end up setting a timeout of 31.9998 seconds and
>> reporting a timeout of 31 seconds.
>>
>> Specifically DBG printouts showed:
>>s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
>>s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656
>> (ff4f)
>> and the final timeout reported to the user was:
>>((count / divisor) * divisor) / freq
>>(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
>> the technically "correct" value is:
>>(0xff4f * 255) / (.0 / 128) = 31.9998
>>
>> By using "DIV_ROUND_UP" we can be a little more correct.
>>s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
>>s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688
>> (ff50)
>> and the final timeout reported to the user:
>>(0xff50 * 255) / 520834 = 32
>> the technically "correct" value is:
>>(0xff50 * 255) / (.0 / 128) = 32.0003
>>
>> We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
>> of reporting shorter values to the user and setting the watchdog to
>> slightly longer than requested:
>> * Round input frequency up to assume watchdog is counting faster.
>> * Round divisions by divisor up to give us extra time.
>>
>> Signed-off-by: Doug Anderson
>> ---
>> drivers/watchdog/s3c2410_wdt.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/watchdog/s3c2410_wdt.c
>> b/drivers/watchdog/s3c2410_wdt.c
>> index 7d8fd04..fe2322b 100644
>> --- a/drivers/watchdog/s3c2410_wdt.c
>> +++ b/drivers/watchdog/s3c2410_wdt.c
>> @@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct
>> watchdog_device *wdd, unsigned timeou
>> if (timeout < 1)
>> return -EINVAL;
>>
>> - freq /= 128;
>> + freq = DIV_ROUND_UP(freq, 128);
>> count = timeout * freq;
>>
>> DBG("%s: count=%d, timeout=%d, freq=%lu\n",
>> @@ -201,20 +201,20 @@ static int s3c2410wdt_set_heartbeat(struct
>> watchdog_device *wdd, unsigned timeou
>>
>> if (count >= 0x1) {
>> for (divisor = 1; divisor <= 0x100; divisor++) {
>> - if ((count / divisor) < 0x1)
>> + if (DIV_ROUND_UP(count, divisor) < 0x1)
>> break;
>> }
>>
> Since you are at it,
> divisor = DIV_ROUND_UP(count + 1, 0x1);
> might be faster, simpler, and easier to understand than the loop.
Way to see the forest for the trees!
Your math ends up with a slightly different result than the old code,
though. One example is when the count is 0x1. You'll end up with
a divider of 2 and I'll end up with a divider of 3.
I think we just want:
divisor = DIV_ROUND_UP(count, 0x);
...that produces the same result as the old loop, but am curious to
know why you chose the "count + 1" and "0x1".
Thanks!
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
On 11/26/2013 01:34 PM, Doug Anderson wrote:
Guenter,
On Tue, Nov 26, 2013 at 10:48 AM, Guenter Roeck wrote:
On 11/26/2013 10:30 AM, Doug Anderson wrote:
The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.
Specifically if you had a timeout of 32 seconds and an input clock of
, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.
Specifically DBG printouts showed:
s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656
(ff4f)
and the final timeout reported to the user was:
((count / divisor) * divisor) / freq
(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
(0xff4f * 255) / (.0 / 128) = 31.9998
By using "DIV_ROUND_UP" we can be a little more correct.
s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688
(ff50)
and the final timeout reported to the user:
(0xff50 * 255) / 520834 = 32
the technically "correct" value is:
(0xff50 * 255) / (.0 / 128) = 32.0003
We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.
Signed-off-by: Doug Anderson
---
drivers/watchdog/s3c2410_wdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c
b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..fe2322b 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
if (timeout < 1)
return -EINVAL;
- freq /= 128;
+ freq = DIV_ROUND_UP(freq, 128);
count = timeout * freq;
DBG("%s: count=%d, timeout=%d, freq=%lu\n",
@@ -201,20 +201,20 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
if (count >= 0x1) {
for (divisor = 1; divisor <= 0x100; divisor++) {
- if ((count / divisor) < 0x1)
+ if (DIV_ROUND_UP(count, divisor) < 0x1)
break;
}
Since you are at it,
divisor = DIV_ROUND_UP(count + 1, 0x1);
might be faster, simpler, and easier to understand than the loop.
Way to see the forest for the trees!
Your math ends up with a slightly different result than the old code,
though. One example is when the count is 0x1. You'll end up with
a divider of 2 and I'll end up with a divider of 3.
I think we just want:
divisor = DIV_ROUND_UP(count, 0x);
...that produces the same result as the old loop, but am curious to
know why you chose the "count + 1" and "0x1".
Hi Doug,
I thought the idea was to keep (count / div) less than 0x1, which you get
by dividing through 0x1. 0x1 / 0x1 = 1, though, so I added 1
to the counter. But maybe I was thinking too much ;-).
Now, 0x1 / 2 = 0x is still lower than 0x1, which is what
I thought is the requirement. Ultimately the error is small either way,
so DIV_ROUND_UP(count, 0x) is just as good to me to avoid the loop.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
On 11/26/2013 04:57 PM, Doug Anderson wrote:
The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.
Specifically if you had a timeout of 32 seconds and an input clock of
, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.
Specifically DBG printouts showed:
s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656 (ff4f)
and the final timeout reported to the user was:
((count / divisor) * divisor) / freq
(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
(0xff4f * 255) / (.0 / 128) = 31.9998
By using "DIV_ROUND_UP" we can be a little more correct.
s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688 (ff50)
and the final timeout reported to the user:
(0xff50 * 255) / 520834 = 32
the technically "correct" value is:
(0xff50 * 255) / (.0 / 128) = 32.0003
We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.
At the same time we can avoid a for loop by just doing the right math.
Signed-off-by: Doug Anderson
Reviewed-by: Guenter Roeck
---
Changes in v2:
- Avoid a for loop as per Guenter.
drivers/watchdog/s3c2410_wdt.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..d9bcd6e 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct watchdog_device
*wdd, unsigned timeou
if (timeout < 1)
return -EINVAL;
- freq /= 128;
+ freq = DIV_ROUND_UP(freq, 128);
count = timeout * freq;
DBG("%s: count=%d, timeout=%d, freq=%lu\n",
@@ -200,21 +200,18 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
*/
if (count >= 0x1) {
- for (divisor = 1; divisor <= 0x100; divisor++) {
- if ((count / divisor) < 0x1)
- break;
- }
+ divisor = DIV_ROUND_UP(count, 0x);
- if ((count / divisor) >= 0x1) {
+ if (divisor > 0x100) {
dev_err(wdt->dev, "timeout %d too big\n", timeout);
return -EINVAL;
}
}
DBG("%s: timeout=%d, divisor=%d, count=%d (%08x)\n",
- __func__, timeout, divisor, count, count/divisor);
+ __func__, timeout, divisor, count, DIV_ROUND_UP(count, divisor));
- count /= divisor;
+ count = DIV_ROUND_UP(count, divisor);
wdt->count = count;
/* update the pre-scaler */
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On Tuesday, November 26, 2013 09:23:15 PM Rafael J. Wysocki wrote:
> On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote:
> > On 26 November 2013 04:59, Rafael J. Wysocki wrote:
> > >> @@ -1259,6 +1262,8 @@ int dpm_suspend(pm_message_t state)
> > >>
> > >> might_sleep();
> > >>
> > >> + cpufreq_suspend();
> > >> +
> > >>
> > >> mutex_lock(&dpm_list_mtx);
> > >> pm_transition = state;
> > >> async_error = 0;
> > >
> > > Shouldn't it do cpufreq_resume() on errors?
> >
> > Yes and this is already done I believe. In case dpm_suspend() fails,
> > dpm_resume() gets called. Isn't it?
>
> OK
>
> > >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > >> +void cpufreq_suspend(void)
> > >> +{
> > >> + struct cpufreq_policy *policy;
> > >> +
> > >> + if (!has_target())
> > >> + return;
> > >> +
> > >> + pr_debug("%s: Suspending Governors\n", __func__);
> > >> +
> > >> + list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
> > >> + if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
> > >> + pr_err("%s: Failed to stop governor for policy:
> > >> %p\n",
> > >> + __func__, policy);
> > >
> > > This appears to be racy. Is it really racy, or just seemingly?
> >
> > Why does it look racy to you? Userspace should be frozen by now,
> > policy_list should be stable as well as nobody would touch it.
>
> You're stopping governors while they may be in use in principle. Do we have
> suitable synchronization in place for that?
Anyway, if you did what I asked you to do and put the cpufreq suspend/resume
into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However,
since you've decided to put those things somewhere else thus making the
change much more intrusive, I can only queue it up for 3.14.
This means I'm going to take the Tianyu's patch as a stop gap for 3.13.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.
Specifically if you had a timeout of 32 seconds and an input clock of
, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.
Specifically DBG printouts showed:
s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656 (ff4f)
and the final timeout reported to the user was:
((count / divisor) * divisor) / freq
(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
(0xff4f * 255) / (.0 / 128) = 31.9998
By using "DIV_ROUND_UP" we can be a little more correct.
s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688 (ff50)
and the final timeout reported to the user:
(0xff50 * 255) / 520834 = 32
the technically "correct" value is:
(0xff50 * 255) / (.0 / 128) = 32.0003
We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.
At the same time we can avoid a for loop by just doing the right math.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Avoid a for loop as per Guenter.
drivers/watchdog/s3c2410_wdt.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..d9bcd6e 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct watchdog_device
*wdd, unsigned timeou
if (timeout < 1)
return -EINVAL;
- freq /= 128;
+ freq = DIV_ROUND_UP(freq, 128);
count = timeout * freq;
DBG("%s: count=%d, timeout=%d, freq=%lu\n",
@@ -200,21 +200,18 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
*/
if (count >= 0x1) {
- for (divisor = 1; divisor <= 0x100; divisor++) {
- if ((count / divisor) < 0x1)
- break;
- }
+ divisor = DIV_ROUND_UP(count, 0x);
- if ((count / divisor) >= 0x1) {
+ if (divisor > 0x100) {
dev_err(wdt->dev, "timeout %d too big\n", timeout);
return -EINVAL;
}
}
DBG("%s: timeout=%d, divisor=%d, count=%d (%08x)\n",
- __func__, timeout, divisor, count, count/divisor);
+ __func__, timeout, divisor, count, DIV_ROUND_UP(count, divisor));
- count /= divisor;
+ count = DIV_ROUND_UP(count, divisor);
wdt->count = count;
/* update the pre-scaler */
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] watchdog: s3c2410_wdt: Handle rounding a little better for timeout
Guenter,
On Tue, Nov 26, 2013 at 4:10 PM, Guenter Roeck wrote:
> On 11/26/2013 01:34 PM, Doug Anderson wrote:
>>
>> Guenter,
>>
>> On Tue, Nov 26, 2013 at 10:48 AM, Guenter Roeck
>> wrote:
>>>
>>> On 11/26/2013 10:30 AM, Doug Anderson wrote:
The existing watchdog timeout worked OK but didn't deal with
rounding in an ideal way when dividing out all of its clocks.
Specifically if you had a timeout of 32 seconds and an input clock of
, you'd end up setting a timeout of 31.9998 seconds and
reporting a timeout of 31 seconds.
Specifically DBG printouts showed:
s3c2410wdt_set_heartbeat: count=1656, timeout=32, freq=520833
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1656
(ff4f)
and the final timeout reported to the user was:
((count / divisor) * divisor) / freq
(0xff4f * 255) / 520833 = 31 (truncated from 31.9998)
the technically "correct" value is:
(0xff4f * 255) / (.0 / 128) = 31.9998
By using "DIV_ROUND_UP" we can be a little more correct.
s3c2410wdt_set_heartbeat: count=1688, timeout=32, freq=520834
s3c2410wdt_set_heartbeat: timeout=32, divisor=255, count=1688
(ff50)
and the final timeout reported to the user:
(0xff50 * 255) / 520834 = 32
the technically "correct" value is:
(0xff50 * 255) / (.0 / 128) = 32.0003
We'll use a DIV_ROUND_UP to solve this, generally erroring on the side
of reporting shorter values to the user and setting the watchdog to
slightly longer than requested:
* Round input frequency up to assume watchdog is counting faster.
* Round divisions by divisor up to give us extra time.
Signed-off-by: Doug Anderson
---
drivers/watchdog/s3c2410_wdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/s3c2410_wdt.c
b/drivers/watchdog/s3c2410_wdt.c
index 7d8fd04..fe2322b 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -188,7 +188,7 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
if (timeout < 1)
return -EINVAL;
- freq /= 128;
+ freq = DIV_ROUND_UP(freq, 128);
count = timeout * freq;
DBG("%s: count=%d, timeout=%d, freq=%lu\n",
@@ -201,20 +201,20 @@ static int s3c2410wdt_set_heartbeat(struct
watchdog_device *wdd, unsigned timeou
if (count >= 0x1) {
for (divisor = 1; divisor <= 0x100; divisor++) {
- if ((count / divisor) < 0x1)
+ if (DIV_ROUND_UP(count, divisor) < 0x1)
break;
}
>>> Since you are at it,
>>> divisor = DIV_ROUND_UP(count + 1, 0x1);
>>> might be faster, simpler, and easier to understand than the loop.
>>
>>
>> Way to see the forest for the trees!
>>
>> Your math ends up with a slightly different result than the old code,
>> though. One example is when the count is 0x1. You'll end up with
>> a divider of 2 and I'll end up with a divider of 3.
>>
>> I think we just want:
>>
>> divisor = DIV_ROUND_UP(count, 0x);
>>
>> ...that produces the same result as the old loop, but am curious to
>> know why you chose the "count + 1" and "0x1".
>>
>
> Hi Doug,
>
> I thought the idea was to keep (count / div) less than 0x1, which you
> get
> by dividing through 0x1. 0x1 / 0x1 = 1, though, so I added 1
> to the counter. But maybe I was thinking too much ;-).
Ah, I was trying to keep "DIV_ROUND_UP(count, divisor);" less than
0x1, which (I think) means that you need to do division by 0x.
Specifically below in my patch I use DIV_ROUND_UP() since I want to
error on the side of having a higher count (fire later). This stuff
always makes my head spin, though.
I believe that DIV_ROUND_UP(0x1, 2) = 0x1, which is greater than 0x.
> Now, 0x1 / 2 = 0x is still lower than 0x1, which is what
> I thought is the requirement. Ultimately the error is small either way,
> so DIV_ROUND_UP(count, 0x) is just as good to me to avoid the loop.
I did code up a quick test script that made sure that the result with
"DIV_ROUND_UP(count, 0x)" matched the results of the loop that I
coded up in the first version of this patchset for all reasonable
values of count, so I'm going to go with that.
Spun patch coming right up...
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On 27 November 2013 07:12, Rafael J. Wysocki wrote: > Anyway, if you did what I asked you to do and put the cpufreq suspend/resume > into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However, > since you've decided to put those things somewhere else thus making the > change much more intrusive, I can only queue it up for 3.14. > > This means I'm going to take the Tianyu's patch as a stop gap for 3.13. There were design issues with that patch actually, as I pointed out earlier (handling EXIT part in core and INIT in governors).. And so in case we need to get something for v3.13, I will send a short version of this series with callbacks from suspend_noirq. Get that one instead. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On 27 November 2013 01:53, Rafael J. Wysocki wrote: > On Tuesday, November 26, 2013 07:56:19 AM Viresh Kumar wrote: >> On 26 November 2013 04:59, Rafael J. Wysocki wrote: >> > This appears to be racy. Is it really racy, or just seemingly? >> >> Why does it look racy to you? Userspace should be frozen by now, >> policy_list should be stable as well as nobody would touch it. > > You're stopping governors while they may be in use in principle. Do we have > suitable synchronization in place for that? At what point exactly in suspend cycle do we suspend timers and workqueues. I thought userspace would be frozen by now and so would be the governors.. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4] cpufreq: suspend governors on system suspend/hibernate
This patch adds cpufreq callbacks to dpm_{suspend|resume}_noirq() for handling
suspend/resume of cpufreq governors.
There are multiple problems that are fixed by this patch:
- Nishanth Menon (TI) found an interesting problem on his platform, OMAP. His
board
wasn't working well with suspend/resume as calls for removing non-boot CPUs
was turning out into a call to drivers ->target() which then tries to play
with regulators. But regulators and their I2C bus were already suspended and
this resulted in a failure. Many platforms have such problems, samsung, tegra,
etc.. They solved it with driver specific PM notifiers where they used to
disable their driver's ->target() routine.
- Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found another issue where
tunables configuration for clusters/sockets with non-boot CPUs was getting
lost after suspend/resume, as we were notifying governors with
CPUFREQ_GOV_POLICY_EXIT on removal of the last cpu for that policy and so
deallocating memory for tunables. This is also fixed with this patch as we
don't allow any operation on Governors during suspend/resume now.
Reported-and-tested-by: Lan Tianyu
Reported-and-tested-by: Nishanth Menon
Reported-by: Jinhyuk Choi
Signed-off-by: Viresh Kumar
---
This is almost same as 1/6 of V3 version of this patchset:
https://lkml.org/lkml/2013/11/25/838
This is done to get some initial fixes for 3.13. These are already tested by
both the reporters of initial problems. Tegra/exynos/s5p will keep running their
PM notifiers until v3.14, as they are currently able to work with them..
drivers/base/power/main.c | 3 +++
drivers/cpufreq/cpufreq.c | 50 +++
include/linux/cpufreq.h | 8
3 files changed, 61 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1b41fca..e3219df 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -540,6 +541,7 @@ static void dpm_resume_noirq(pm_message_t state)
dpm_show_time(starttime, state, "noirq");
resume_device_irqs();
cpuidle_resume();
+ cpufreq_resume();
}
/**
@@ -955,6 +957,7 @@ static int dpm_suspend_noirq(pm_message_t state)
ktime_t starttime = ktime_get();
int error = 0;
+ cpufreq_suspend();
cpuidle_pause();
suspend_device_irqs();
mutex_lock(&dpm_list_mtx);
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 02d534d..b6c7821 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -47,6 +48,9 @@ static LIST_HEAD(cpufreq_policy_list);
static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
#endif
+/* Flag to suspend/resume CPUFreq governors */
+static bool cpufreq_suspended;
+
static inline bool has_target(void)
{
return cpufreq_driver->target_index || cpufreq_driver->target;
@@ -1462,6 +1466,48 @@ static struct subsys_interface cpufreq_interface = {
.remove_dev = cpufreq_remove_dev,
};
+/*
+ * Callbacks for suspending/resuming governors as some platforms can't change
+ * frequency after this point in suspend cycle. Because some of the devices
+ * (like: i2c, regulators, etc) they use for changing frequency are suspended
+ * quickly after this point.
+ */
+void cpufreq_suspend(void)
+{
+ struct cpufreq_policy *policy;
+
+ if (!has_target())
+ return;
+
+ pr_debug("%s: Suspending Governors\n", __func__);
+
+ list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
+ if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
+ pr_err("%s: Failed to stop governor for policy: %p\n",
+ __func__, policy);
+
+ cpufreq_suspended = true;
+}
+
+void cpufreq_resume(void)
+{
+ struct cpufreq_policy *policy;
+
+ if (!has_target())
+ return;
+
+ pr_debug("%s: Resuming Governors\n", __func__);
+
+ cpufreq_suspended = false;
+
+ list_for_each_entry(policy, &cpufreq_policy_list, policy_list)
+ if (__cpufreq_governor(policy, CPUFREQ_GOV_START) ||
+ __cpufreq_governor(policy,
+ CPUFREQ_GOV_LIMITS))
+ pr_err("%s: Failed to start governor for policy: %p\n",
+ __func__, policy);
+}
+
/**
* cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
*
@@ -1764,6 +1810,10 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
struct cpufreq_governor *gov = NULL;
#endif
+ /* Don't start any governor operations if we are entering suspend */
+ if (cpufreq_suspended)
+ return 0;
+
if (policy->governor->ma
[PATCH] ARM:EXYNOS:Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default
ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR is enabled by default for Exynos platforms. Introduction of this config as default will enable phy-to-virt and virt-to-phy translation function at boot and module loading time and enforce dynamic reallocation of memory. This config is mutually exclusive to XIP_KERNEL, which is used in systems with NOR flash devices Requesting Exynos maintainers to evaluate the changes on the board and comment, as I dont have the board for testing I am seeking an ACK from Exynos maintainers. Signed-off-by: panchaxari Cc: Linus Walleij Cc: Kukjin Kim Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org --- arch/arm/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 214b698..28d84f3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -807,6 +807,8 @@ config ARCH_EXYNOS select ARCH_REQUIRE_GPIOLIB select ARCH_SPARSEMEM_ENABLE select ARM_GIC + select ARM_PATCH_PHYS_VIRT + select AUTO_ZRELADDR select COMMON_CLK select CPU_V7 select GENERIC_CLOCKEVENTS -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] ARM: dts: exynos4x12: Device tree node definition for TMU on Exynos4x12
Hi Kukjin,
> Hi Kukjin,
>
> > The TMU device tree node definition for Exynos4x12 family of SoCs.
> >
> > Signed-off-by: Lukasz Majewski
> > Reviewed-by: Bartlomiej Zolnierkiewicz
> > Reviewed-by: Tomasz Figa
> >
> > ---
> > Changes for v2:
> > - None
> >
> > arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> > b/arch/arm/boot/dts/exynos4x12.dtsi index ad531fe..64c0ece 100644
> > --- a/arch/arm/boot/dts/exynos4x12.dtsi
> > +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> > @@ -176,4 +176,14 @@
> > };
> > };
> > };
> > +
> > + tmu@100C {
> > + compatible = "samsung,exynos4412-tmu";
> > + interrupt-parent = <&combiner>;
> > + interrupts = <2 4>;
> > + reg = <0x100C 0x100>;
> > + clocks = <&clock 383>;
> > + clock-names = "tmu_apbif";
> > + status = "disabled";
> > + };
> > };
>
> Can you pull this DT node definition for TMU (as a fix to v3.12)?
>
> It is crucial for Exynos4412.
>
Kukjin, could you pull this patch?
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] ARM: dts: exynos4412-trats2: Enable TMU support at Trats2
Hi Kukjin,
> Hi Kukjin,
>
> > This patch enables support for TMU at Exynos4412 based Trats2 board.
> >
> > Signed-off-by: Lukasz Majewski
> > Reviewed-by: Bartlomiej Zolnierkiewicz
> > Reviewed-by: Tomasz Figa
> >
> > ---
> > Changes for v2:
> > - None
> >
> > arch/arm/boot/dts/exynos4412-trats2.dts |5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> > b/arch/arm/boot/dts/exynos4412-trats2.dts index fb7b9ae..57136f8
> > 100644 --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> > +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> > @@ -467,6 +467,11 @@
> > status = "okay";
> > };
> >
> > + tmu@100C {
> > + vtmu-supply = <&ldo10_reg>;
> > + status = "okay";
> > + };
> > +
> > i2c_ak8975: i2c-gpio-0 {
> > compatible = "i2c-gpio";
> > gpios = <&gpy2 4 0>, <&gpy2 5 0>;
>
> Can you pull this DT node definition for TMU (as a fix to v3.12)?
>
> It is crucial for Exynos4412. Other patches from this patch set were
> already pulled as v3.12 fixes.
>
Kukjin, could you pull this patch?
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On 2013年11月27日 11:07, Viresh Kumar wrote: > On 27 November 2013 07:12, Rafael J. Wysocki wrote: >> Anyway, if you did what I asked you to do and put the cpufreq suspend/resume >> into dpm_suspend/resume_noirq(), I'd probably take this for 3.13. However, >> since you've decided to put those things somewhere else thus making the >> change much more intrusive, I can only queue it up for 3.14. >> >> This means I'm going to take the Tianyu's patch as a stop gap for 3.13. > Hi Viresh: First, I agree the new solution you are working on. :) But actually I don't totally agree my origin patch have design issue. Because I think governor should have the ability to check whether it has been EXIT when doing INIT and it should return error code at that point. The design is to make governor code stronger to deal with the case that governor is reinitialized before EXIT. Just from my view. Sorry for noise. > There were design issues with that patch actually, as I pointed out earlier > (handling EXIT part in core and INIT in governors).. And so in case we > need to get something for v3.13, I will send a short version of this series > with callbacks from suspend_noirq. > > Get that one instead. > > -- > viresh > -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On 27 November 2013 12:38, Lan Tianyu wrote:
> Hi Viresh:
Hey Lan,
> First, I agree the new solution you are working on. :)
Thanks :)
> But actually I don't totally agree my origin patch have design issue.
> Because I think governor should have the ability to check whether it has
> been EXIT when doing INIT and it should return error code at that point.
> The design is to make governor code stronger to deal with the case that
> governor is reinitialized before EXIT. Just from my view.
> Sorry for noise.
Ahh, these are useful discussions. Everyone have their own thoughts and
its upto all of us to get meaningful stuff out of it..
I agree to whatever you wrote above but this isn't exactly what's being
done in your patch. I was more concerned about this stuff:
On 22 November 2013 13:08, Lan Tianyu wrote:
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> + if (has_target() && !frozen) {
> ret = __cpufreq_governor(policy,
> CPUFREQ_GOV_POLICY_EXIT);
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> @@ -204,9 +204,20 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
>
> switch (event) {
> case CPUFREQ_GOV_POLICY_INIT:
> + /*
> +* In order to keep governor data across suspend/resume,
> +* Governor doesn't exit when suspend and will be
> +* reinitialized when resume. Here check policy governor
> +* data to determine whether the governor has been exited.
> +* If not, return EALREADY.
> +*/
> if (have_governor_per_policy()) {
> - WARN_ON(dbs_data);
> + if (dbs_data)
> + return -EALREADY;
> } else if (dbs_data) {
> + if (policy->governor_data == dbs_data)
> + return -EALREADY;
> +
> dbs_data->usage_count++;
> policy->governor_data = dbs_data;
> return 0;
Here the cpufreq core has skipped the call to governor's EXIT,
and so it shouldn't pass on the following INIT call to them..
That's a bit wrong. These two calls work in pairs and are exactly
opposite to each other. And so if some decision has to be taken
then either that should be done completely at governor level
or core level. Doing stuff partly in governor and partly in core
is like giving invitation to new bugs/problems :)
Nothing personal otherwise. Recently there were patches sent
by people, you, Nishanth, etc, which I have just overridden with
my versions.. It wasn't about getting my count higher :) but
getting the solution at right places instead of solving them at
wrong locations..
I am already having tough time upstreaming patches for cpufreq
consolidation, as the number of patches is huge. It takes time
for people to absorb/test them. Though Rafael has taken almost all
of them in v3.13 finally, but I understand its difficult for him as
well and he did his job wonderfully :)
And so I don't really want to get any new stuff in which will surely
get consolidated later. Lets do it now, we had enough of it :)
Even, related to your patch, I was already thinking of getting
rid of "frozen" variable and parameter to functions, as we already
know status from a global variable now, cpufreq_suspended. And
so we don't actually need to pass any additional parameters
to many routines, which have something like 'frozen' currently.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
