RE: linux 3.13-rc1 make dw_mmc-exynos more worse
On Mon, November 25, 2013, Olof Johansson wrote:
Hi,
On Sun, Nov 24, 2013 at 4:07 AM, randy lxr1...@hotmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After pull the merge of 3.13-rc1, the dw_mmc-exynos will make the boot
stock.In 3.13, it is just stocked udev in 3.13 and makse udev timeout
but kernel report the emmc device is found.
And in the Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I
saw that it is need to define which gpio ports that a emmc slot use,
but when I watched others dts, they use pinctrl, which is correct?
Here is the log and dts
[..]
===log begin =
[..]
[0.00] CPU EXYNOS4412 (id 0xe4412011)
[..]
[1.095000] mmc0: no vmmc regulator found
[1.13] mmc0: SDHCI controller on samsung-hsmmc
[1253.sdhci] using ADMA
[1.13] Synopsys Designware Multimedia Card Interface Driver
[1.13] Unable to handle kernel NULL pointer dereference at
virtual address 002a
[1.13] pgd = c0004000
[1.13] [002a] *pgd=
[1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[1.14] Modules linked in:
[1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.13.0-rc1-8-g584fa45-dirty #3
[1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000
[1.155000] PC is at clk_get_rate+0x18/0x5c
[1.16] LR is at clk_prepare_lock+0xc/0xd8
[1.165000] pc : [c0319400]lr : [c0318864]psr: a113
[1.165000] sp : ef0a9e20 ip : ee94eb40 fp :
[1.175000] r10: c0571510 r9 : ef0a8000 r8 : ef227a10
[1.18] r7 : c043544c r6 : fffe r5 : ee94ead0 r4 : fffe
[1.185000] r3 : ef0a4000 r2 : 0001 r1 : 02b9 r0 : 0001
[1.195000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[1.20] Control: 10c5387d Table: 4000404a DAC: 0015
[1.205000] Process swapper/0 (pid: 1, stack limit = 0xef0a8240)
[1.21] Stack: (0xef0a9e20 to 0xef0aa000)
[1.215000] 9e20: c0308474 ee9ea610 ee94ead0 c0308488 c0308474
ee9ea610 c030592c
[1.225000] 9e40: ef227a10 1000 c043544c c020a920 c0838b04
17d78400 ee9ea610 ef227a00
[1.235000] 9e60: ef227a10 c05d6b1c c05d6b1c c05890b0
ef0a8000 c0571510 c0269448
[1.24] 9e80: c0269430 ef227a10 c061291c c0268088
ef227a10 c05d6b1c ef227a44
[1.25] 9ea0: c026822c c05d6b1c c02681a0
c02668a8 ef005478 ef212740
[1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864 c0511e38
c05d6b1c 0006 c05d6b1c
[1.265000] 9ee0: 0006 c059575c c05df580 c026884c
c05a2e14 0006 c00088dc
[1.275000] 9f00: c0603f70 ef163e00 c040e334 6113 c05b5000
a113 c05b5054 c05b5050
[1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093
c0035158 c05b5054 c05a2a20
[1.29] 9f40: c050ae2c c054a438 0006 0006
c05a2e14 0006 c059575c
[1.30] 9f60: c05df580 0093 c0595768 c0571510
c0571c48 0006 0006
[1.305000] 9f80: c0571510 c003df68 c0403544
[1.315000] 9fa0: c040354c c000e738
[1.32] 9fc0:
[1.33] 9fe0: 0013
be73efa4 bffd
[1.34] [c0319400] (clk_get_rate+0x18/0x5c) from [c0308488]
(dw_mci_exynos_setup_clock+0x14/0x2c)
[1.35] [c0308488] (dw_mci_exynos_setup_clock+0x14/0x2c) from
[c030592c] (dw_mci_probe+0x15c/0xca4)
[1.36] [c030592c] (dw_mci_probe+0x15c/0xca4) from
[c0269448] (platform_drv_probe+0x18/0x48)
[1.365000] [c0269448] (platform_drv_probe+0x18/0x48) from
[c0268088] (driver_probe_device+0x100/0x218)
[1.375000] [c0268088] (driver_probe_device+0x100/0x218) from
[c026822c] (__driver_attach+0x8c/0x90)
[1.385000] [c026822c] (__driver_attach+0x8c/0x90) from
[c02668a8] (bus_for_each_dev+0x54/0x88)
[1.395000] [c02668a8] (bus_for_each_dev+0x54/0x88) from
[c0267864] (bus_add_driver+0xd4/0x1d0)
[1.405000] [c0267864] (bus_add_driver+0xd4/0x1d0) from
[c026884c] (driver_register+0x78/0xf4)
[1.415000] [c026884c] (driver_register+0x78/0xf4) from
[c00088dc] (do_one_initcall+0xec/0x148)
[1.42] [c00088dc] (do_one_initcall+0xec/0x148) from
[c0571c48] (kernel_init_freeable+0xfc/0x1c8)
[1.43] [c0571c48] (kernel_init_freeable+0xfc/0x1c8) from
[c040354c] (kernel_init+0x8/0x110)
[1.44] [c040354c] (kernel_init+0x8/0x110) from [c000e738]
(ret_from_fork+0x14/0x3c)
[1.45] Code: ebfffd18 e354 01a05004 0a08 (e594302c)
Looks like a clock issue on 4412? I only have 5250 that I boot test
on, no EXYNOS4 coverage at all (I had an
[PATCH v8] videobuf2: Add missing lock held on vb2_fop_relase
From: Ricardo Ribalda ricardo.riba...@gmail.com
vb2_fop_release does not held the lock although it is modifying the
queue-owner field.
This could lead to race conditions on the vb2_perform_io function
when multiple applications are accessing the video device via
read/write API:
[ 308.297741] BUG: unable to handle kernel NULL pointer dereference at
0260
[ 308.297759] IP: [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.297794] PGD 159719067 PUD 158119067 PMD 0
[ 308.297812] Oops: #1 SMP
[ 308.297826] Modules linked in: qt5023_video videobuf2_dma_sg
qtec_xform videobuf2_vmalloc videobuf2_memops videobuf2_core
qtec_white qtec_mem gpio_xilinx qtec_cmosis qtec_pcie fglrx(PO)
spi_xilinx spi_bitbang qt5023
[ 308.297888] CPU: 1 PID: 2189 Comm: java Tainted: P O 3.11.0-qtec-standard #1
[ 308.297919] Hardware name: QTechnology QT5022/QT5022, BIOS
PM_2.1.0.309 X64 05/23/2013
[ 308.297952] task: 8801564e1690 ti: 88014dc02000 task.ti:
88014dc02000
[ 308.297962] RIP: 0010:[a07a9fd2] [a07a9fd2]
vb2_perform_fileio+0x372/0x610 [videobuf2_core]
[ 308.297985] RSP: 0018:88014dc03df8 EFLAGS: 00010202
[ 308.297995] RAX: RBX: 880158a23000 RCX: dead00100100
[ 308.298003] RDX: RSI: dead00200200 RDI:
[ 308.298012] RBP: 88014dc03e58 R08: R09: 0001
[ 308.298020] R10: ea00051e8380 R11: 88014dc03fd8 R12: 880158a23070
[ 308.298029] R13: 8801549040b8 R14: 00198000 R15: 01887e60
[ 308.298040] FS: 7f65130d5700() GS:88015ed0()
knlGS:
[ 308.298049] CS: 0010 DS: ES: CR0: 80050033
[ 308.298057] CR2: 0260 CR3: 00015963 CR4: 07e0
[ 308.298064] Stack:
[ 308.298071] 880156416c00 00198000
88010001
[ 308.298087] 88014dc03f50 810a79ca 00020001
880154904718
[ 308.298101] 880156416c00 00198000 880154904338
88014dc03f50
[ 308.298116] Call Trace:
[ 308.298143] [a07aa3c4] vb2_read+0x14/0x20 [videobuf2_core]
[ 308.298198] [a07aa494] vb2_fop_read+0xc4/0x120 [videobuf2_core]
[ 308.298252] [8154ee9e] v4l2_read+0x7e/0xc0
[ 308.298296] [8116e639] vfs_read+0xa9/0x160
[ 308.298312] [8116e882] SyS_read+0x52/0xb0
[ 308.298328] [81784179] tracesys+0xd0/0xd5
[ 308.298335] Code: e5 d6 ff ff 83 3d be 24 00 00 04 89 c2 4c 8b 45 b0
44 8b 4d b8 0f 8f 20 02 00 00 85 d2 75 32 83 83 78 03 00 00 01 4b 8b
44 c5 48 8b 88 60 02 00 00 85 c9 0f 84 b0 00 00 00 8b 40 58 89 c2 41
89
[ 308.298487] RIP [a07a9fd2] vb2_perform_fileio+0x372/0x610
[videobuf2_core]
[ 308.298507] RSP 88014dc03df8
[ 308.298514] CR2: 0260
[ 308.298526] ---[ end trace e8f01717c96d1e41 ]---
---
v2: Comments by Sylvester Nawrocki
fimc-capture and fimc-lite where calling vb2_fop_release with the lock held.
Therefore a new __vb2_fop_release function has been created to be used by
drivers that overload the release function.
v3: Comments by Sylvester Nawrocki and Mauro Carvalho Chehab
Use vb2_fop_release_locked instead of __vb2_fop_release
v4: Comments by Sylvester Nawrocki
Rename vb2_fop_release_locked to __vb2_fop_release and fix patch format
v5: Comments by Sylvester Nawrocki and Hans Verkuil
Rename __vb2_fop_release to vb2_fop_release_unlock and rearrange
arguments
v6: Comments by Hans Verkuil
Fix typo on description
Rename vb2_fop_release_locked to vb2_fop_release_no_lock
v7: Comments by Hans Verkuil and Sylvester Nawrocki
Export _vb2_fop_release instead of using vb2_fop_release_no_lock
v8: Comments by Hans Verkuil and rebase
Missed semicolon
Signed-off-by: Ricardo Ribalda ricardo.riba...@gmail.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 15 ++-
include/media/videobuf2-core.h | 1 +
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..8a712ca 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = _vb2_fop_release(file, NULL);
if (close) {
clear_bit(ST_CAPT_BUSY, fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..d3b32b6 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7
Вы можете располагать орлиным зрением
Мы отвоевываем людям зрение http://goo.gl/2m4NKq
[PATCH 2/3] ARM: dts: Disable I2C controllers by default on Exynos5250
From: Mark Brown broo...@linaro.org
Ensure that unused I2C controllers are not activated, causing problems due
to inappropriate pinmuxing or similar, by marking the controllers as
disabled by default and requiring boards to explicitly enable those that
are in use.
Signed-off-by: Mark Brown broo...@linaro.org
Acked-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/cros5250-common.dtsi| 12
arch/arm/boot/dts/exynos5250-arndale.dts | 32 ---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 25 +---
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
4 files changed, 31 insertions(+), 48 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 0fcca2930c61..7dbba0859a1d 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -30,6 +30,7 @@
};
i2c@12C6 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
@@ -173,6 +174,7 @@
};
i2c@12C7 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
@@ -186,6 +188,7 @@
};
i2c@12C8 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
@@ -196,30 +199,31 @@
};
i2c@12C9 {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
};
i2c@12CA {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
};
i2c@12CB {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
};
- i2c@12CC {
- status = disabled;
- };
-
i2c@12CD {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
};
i2c@12CE {
+ status = okay;
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 0385b58116ec..6fbe89fd7d41 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -34,6 +34,7 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
samsung,i2c-slave-addr = 0x66;
+ status = okay;
s5m8767_pmic@66 {
compatible = samsung,s5m8767-pmic;
@@ -319,11 +320,9 @@
};
};
- i2c@12C7 {
- status = disabled;
- };
-
i2c@12C8 {
+ status = okay;
+
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
samsung,i2c-slave-addr = 0x50;
@@ -335,7 +334,10 @@
};
i2c@12C9 {
+ status = okay;
+
wm1811a@1a {
+
compatible = wlf,wm1811;
reg = 0x1a;
@@ -353,23 +355,9 @@
};
};
- i2c@12CA {
- status = disabled;
- };
-
- i2c@12CB {
- status = disabled;
- };
-
- i2c@12CC {
- status = disabled;
- };
-
- i2c@12CD {
- status = disabled;
- };
-
i2c@12CE {
+ status = okay;
+
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 66000;
samsung,i2c-slave-addr = 0x38;
@@ -380,10 +368,6 @@
};
};
- i2c@121D {
- status = disabled;
- };
-
dwmmc_0: dwmmc0@1220 {
num-slots = 1;
supports-highspeed;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 5d0395e07eee..a17b1a0a8abc 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -30,6 +30,7 @@
i2c@12C6 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
+ status = okay;
eeprom@50 {
compatible = samsung,s524ad0xd1;
@@ -64,6 +65,7 @@
i2c@12C7 {
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 2;
+ status = okay;
eeprom@51 {
compatible = samsung,s524ad0xd1;
@@ -89,6 +91,7 @@
samsung,i2c-sda-delay = 100;
[PATCH 3/3] ARM: dts: Rename Exynos5250 ChromeOS common file to have exynos prefix
From: Mark Brown broo...@linaro.org
Make it easier to notice the common file for ChromeOS devices based on
the Exynos5250 by giving it the exynos5250 prefix that the boards have.
Signed-off-by: Mark Brown broo...@linaro.org
Acked-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/{cros5250-common.dtsi = exynos5250-cros-common.dtsi} | 0
arch/arm/boot/dts/exynos5250-snow.dts | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm/boot/dts/{cros5250-common.dtsi = exynos5250-cros-common.dtsi}
(100%)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
similarity index 100%
rename from arch/arm/boot/dts/cros5250-common.dtsi
rename to arch/arm/boot/dts/exynos5250-cros-common.dtsi
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index fd711e245e8d..7e2669c6f7f5 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -10,7 +10,7 @@
/dts-v1/;
#include exynos5250.dtsi
-#include cros5250-common.dtsi
+#include exynos5250-cros-common.dtsi
/ {
model = Google Snow;
--
1.8.4.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
[PATCH 1/3] ARM: dts: Leave Exynos5250 SPI controller disabled by default
From: Mark Brown broo...@linaro.org
Rather than requiring each board to explicitly disable the SPI controllers
it is not using instead require boards to enable those that they are using.
This is less work overall since normally at most one of the controllers is
in use and avoids issues caused by inappropriate pinmuxing.
Signed-off-by: Mark Brown broo...@linaro.org
Acked-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/cros5250-common.dtsi| 9 +
arch/arm/boot/dts/exynos5250-arndale.dts | 12
arch/arm/boot/dts/exynos5250-smdk5250.dts | 6 ++
arch/arm/boot/dts/exynos5250.dtsi | 3 +++
4 files changed, 6 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index dc259e8b8a73..0fcca2930c61 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -286,19 +286,12 @@
};
};
- spi_0: spi@12d2 {
- status = disabled;
- };
-
spi_1: spi@12d3 {
+ status = okay;
samsung,spi-src-clk = 0;
num-cs = 1;
};
- spi_2: spi@12d4 {
- status = disabled;
- };
-
hdmi {
hpd-gpio = gpx3 7 0;
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 684527087aa4..0385b58116ec 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -434,18 +434,6 @@
status = okay;
};
- spi_0: spi@12d2 {
- status = disabled;
- };
-
- spi_1: spi@12d3 {
- status = disabled;
- };
-
- spi_2: spi@12d4 {
- status = disabled;
- };
-
gpio_keys {
compatible = gpio-keys;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index f86d56760a45..5d0395e07eee 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -189,6 +189,8 @@
};
spi_1: spi@12d3 {
+ status = okay;
+
w25q80bw@0 {
#address-cells = 1;
#size-cells = 1;
@@ -214,10 +216,6 @@
};
};
- spi_2: spi@12d4 {
- status = disabled;
- };
-
hdmi {
hpd-gpio = gpx3 7 0;
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 9db5047812f3..9b58532854e1 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -349,6 +349,7 @@
spi_0: spi@12d2 {
compatible = samsung,exynos4210-spi;
+ status = disabled;
reg = 0x12d2 0x100;
interrupts = 0 66 0;
dmas = pdma0 5
@@ -364,6 +365,7 @@
spi_1: spi@12d3 {
compatible = samsung,exynos4210-spi;
+ status = disabled;
reg = 0x12d3 0x100;
interrupts = 0 67 0;
dmas = pdma1 5
@@ -379,6 +381,7 @@
spi_2: spi@12d4 {
compatible = samsung,exynos4210-spi;
+ status = disabled;
reg = 0x12d4 0x100;
interrupts = 0 68 0;
dmas = pdma0 7
--
1.8.4.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: linux 3.13-rc1 make dw_mmc-exynos more worse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
于 2013年11月25日 16:33, Seungwon Jeon 写道:
On Mon, November 25, 2013, Olof Johansson wrote:
Hi,
On Sun, Nov 24, 2013 at 4:07 AM, randy lxr1...@hotmail.com
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
After pull the merge of 3.13-rc1, the dw_mmc-exynos will make
the boot stock.In 3.13, it is just stocked udev in 3.13 and
makse udev timeout but kernel report the emmc device is found.
And in the
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I saw
that it is need to define which gpio ports that a emmc slot
use, but when I watched others dts, they use pinctrl, which is
correct? Here is the log and dts
[..]
===log begin =
[..]
[0.00] CPU EXYNOS4412 (id 0xe4412011)
[..]
[1.095000] mmc0: no vmmc regulator found [1.13]
mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci] using
ADMA [1.13] Synopsys Designware Multimedia Card
Interface Driver [1.13] Unable to handle kernel NULL
pointer dereference at virtual address 002a [1.13]
pgd = c0004000 [1.13] [002a] *pgd= [
1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [
1.14] Modules linked in: [1.14] CPU: 0 PID: 1
Comm: swapper/0 Not tainted 3.13.0-rc1-8-g584fa45-dirty #3
[ 1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [
1.155000] PC is at clk_get_rate+0x18/0x5c [1.16] LR is
at clk_prepare_lock+0xc/0xd8 [1.165000] pc : [c0319400]
lr : [c0318864]psr: a113 [1.165000] sp :
ef0a9e20 ip : ee94eb40 fp : [1.175000] r10:
c0571510 r9 : ef0a8000 r8 : ef227a10 [1.18] r7 :
c043544c r6 : fffe r5 : ee94ead0 r4 : fffe [
1.185000] r3 : ef0a4000 r2 : 0001 r1 : 02b9 r0 :
0001 [ 1.195000] Flags: NzCv IRQs on FIQs on Mode SVC_32
ISA ARM Segment kernel [1.20] Control: 10c5387d
Table: 4000404a DAC: 0015 [1.205000] Process swapper/0
(pid: 1, stack limit = 0xef0a8240) [1.21] Stack:
(0xef0a9e20 to 0xef0aa000) [1.215000] 9e20: c0308474
ee9ea610 ee94ead0 c0308488 c0308474 ee9ea610 c030592c
[1.225000] 9e40: ef227a10 1000 c043544c c020a920
c0838b04 17d78400 ee9ea610 ef227a00 [1.235000] 9e60:
ef227a10 c05d6b1c c05d6b1c c05890b0 ef0a8000 c0571510
c0269448 [ 1.24] 9e80: c0269430 ef227a10 c061291c c0268088
ef227a10 c05d6b1c ef227a44 [1.25] 9ea0:
c026822c c05d6b1c c02681a0 c02668a8 ef005478
ef212740 [1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438
c0267864 c0511e38 c05d6b1c 0006 c05d6b1c [1.265000]
9ee0: 0006 c059575c c05df580 c026884c c05a2e14
0006 c00088dc [1.275000] 9f00: c0603f70 ef163e00
c040e334 6113 c05b5000 a113 c05b5054 c05b5050 [
1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093
c0035158 c05b5054 c05a2a20 [1.29] 9f40: c050ae2c
c054a438 0006 0006 c05a2e14 0006 c059575c
[ 1.30] 9f60: c05df580 0093 c0595768 c0571510
c0571c48 0006 0006 [1.305000] 9f80: c0571510
c003df68 c0403544
[1.315000] 9fa0: c040354c c000e738
[1.32] 9fc0:
[1.33] 9fe0:
0013 be73efa4 bffd [1.34]
[c0319400] (clk_get_rate+0x18/0x5c) from [c0308488]
(dw_mci_exynos_setup_clock+0x14/0x2c) [1.35]
[c0308488] (dw_mci_exynos_setup_clock+0x14/0x2c) from
[c030592c] (dw_mci_probe+0x15c/0xca4) [1.36]
[c030592c] (dw_mci_probe+0x15c/0xca4) from [c0269448]
(platform_drv_probe+0x18/0x48) [1.365000] [c0269448]
(platform_drv_probe+0x18/0x48) from [c0268088]
(driver_probe_device+0x100/0x218) [1.375000] [c0268088]
(driver_probe_device+0x100/0x218) from [c026822c]
(__driver_attach+0x8c/0x90) [1.385000] [c026822c]
(__driver_attach+0x8c/0x90) from [c02668a8]
(bus_for_each_dev+0x54/0x88) [1.395000] [c02668a8]
(bus_for_each_dev+0x54/0x88) from [c0267864]
(bus_add_driver+0xd4/0x1d0) [1.405000] [c0267864]
(bus_add_driver+0xd4/0x1d0) from [c026884c]
(driver_register+0x78/0xf4) [1.415000] [c026884c]
(driver_register+0x78/0xf4) from [c00088dc]
(do_one_initcall+0xec/0x148) [1.42] [c00088dc]
(do_one_initcall+0xec/0x148) from [c0571c48]
(kernel_init_freeable+0xfc/0x1c8) [1.43] [c0571c48]
(kernel_init_freeable+0xfc/0x1c8) from [c040354c]
(kernel_init+0x8/0x110) [1.44] [c040354c]
(kernel_init+0x8/0x110) from [c000e738]
(ret_from_fork+0x14/0x3c) [1.45] Code: ebfffd18
e354 01a05004 0a08 (e594302c)
Looks like a clock issue on 4412? I only have 5250 that I boot
test on, no EXYNOS4 coverage at all (I had
[PATCH 2/2] cpufreq: exynos: Frequency lock should be considered in hibernation also.
The Frequency lock value should be higher or same than the booting frequency,
which is set by the bootloader. To eliminate possible inconsistency
in frequency, we save and restore frequency during suspend resume
and disable CPUFREQ activity. This should be considered in hibernation also.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
---
drivers/cpufreq/exynos-cpufreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..cd05b0a 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -187,6 +187,7 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
int ret;
switch (pm_event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
mutex_lock(cpufreq_lock);
frequency_locked = true;
@@ -198,6 +199,8 @@ static int exynos_cpufreq_pm_notifier(struct notifier_block
*notifier,
break;
+ case PM_POST_HIBERNATION:
+ case PM_POST_RESTORE:
case PM_POST_SUSPEND:
mutex_lock(cpufreq_lock);
frequency_locked = false;
--
1.8.1.2
--
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 V3 1/6] cpufreq: suspend governors on system suspend/hibernate
This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors. This is required for early suspend and late
resume of governors and cpufreq core.
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 don't
allow any operation on Governors during suspend/resume now.
Reported-by: Lan Tianyu tianyu@intel.com
Reported-by: Nishanth Menon n...@ti.com
Reported-by: Jinhyuk Choi jinc...@broadcom.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/base/power/main.c | 5 +
drivers/cpufreq/cpufreq.c | 50 +++
include/linux/cpufreq.h | 3 +++
3 files changed, 58 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1b41fca..c9fbb9d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -29,6 +29,7 @@
#include linux/async.h
#include linux/suspend.h
#include trace/events/power.h
+#include linux/cpufreq.h
#include linux/cpuidle.h
#include linux/timer.h
@@ -789,6 +790,8 @@ void dpm_resume(pm_message_t state)
mutex_unlock(dpm_list_mtx);
async_synchronize_full();
dpm_show_time(starttime, state, NULL);
+
+ cpufreq_resume();
}
/**
@@ -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;
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 linux/module.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/suspend.h
#include linux/syscore_ops.h
#include linux/tick.h
#include trace/events/power.h
@@ -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-max_transition_latency
policy-cpuinfo.transition_latency
[PATCH V3 3/6] cpufreq: Implement cpufreq_generic_suspend()
Multiple platforms need to set CPU to a particular frequency before suspending
system. And so they need a common infrastructure which is provided by this
patch. Those platforms just need to initialize their -suspend() pointers with
the generic routine.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 25 +
include/linux/cpufreq.h | 3 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 026efe4a..f6da551 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1466,6 +1466,31 @@ static struct subsys_interface cpufreq_interface = {
};
/*
+ * In case platform wants some specific frequency to be configured
+ * during suspend..
+ */
+int cpufreq_generic_suspend(struct cpufreq_policy *policy)
+{
+ int ret;
+
+ if (!policy-suspend_freq) {
+ pr_err(%s: suspend_freq can't be zero\n, __func__);
+ return -EINVAL;
+ }
+
+ pr_debug(%s: Setting suspend-freq: %u\n, __func__,
+ policy-suspend_freq);
+
+ ret = __cpufreq_driver_target(policy, policy-suspend_freq,
+ CPUFREQ_RELATION_H);
+ if (ret)
+ pr_err(%s: unable to set suspend-freq: %u. err: %d\n,
+ __func__, policy-suspend_freq, ret);
+
+ return ret;
+}
+
+/*
* 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
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 6d93f91..94ccac5 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -72,6 +72,8 @@ struct cpufreq_policy {
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz, only needed if cpufreq
* governors are used */
+ unsigned intsuspend_freq; /* freq to set during suspend */
+
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
@@ -257,6 +259,7 @@ int cpufreq_unregister_driver(struct cpufreq_driver
*driver_data);
void cpufreq_suspend(void);
void cpufreq_resume(void);
+int cpufreq_generic_suspend(struct cpufreq_policy *policy);
const char *cpufreq_get_current_driver(void);
--
1.7.12.rc2.18.g61b472e
--
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 V3 6/6] cpufreq: Tegra: Use cpufreq_generic_suspend()
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 viresh.ku...@linaro.org
---
drivers/cpufreq/tegra-cpufreq.c | 54 +
1 file changed, 6 insertions(+), 48 deletions(-)
diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
index f42df7e..336368b 100644
--- a/drivers/cpufreq/tegra-cpufreq.c
+++ b/drivers/cpufreq/tegra-cpufreq.c
@@ -26,7 +26,6 @@
#include linux/err.h
#include linux/clk.h
#include linux/io.h
-#include linux/suspend.h
static struct cpufreq_frequency_table freq_table[] = {
{ .frequency = 216000 },
@@ -48,8 +47,6 @@ static struct clk *pll_p_clk;
static struct clk *emc_clk;
static unsigned long target_cpu_speed[NUM_CPUS];
-static DEFINE_MUTEX(tegra_cpu_lock);
-static bool is_suspended;
static unsigned int tegra_getspeed(unsigned int cpu)
{
@@ -137,50 +134,10 @@ static unsigned long tegra_cpu_highest_speed(void)
static int tegra_target(struct cpufreq_policy *policy, unsigned int index)
{
- unsigned int freq;
- int ret = 0;
-
- mutex_lock(tegra_cpu_lock);
-
- if (is_suspended) {
- ret = -EBUSY;
- goto out;
- }
-
- freq = freq_table[index].frequency;
-
- target_cpu_speed[policy-cpu] = freq;
-
- ret = tegra_update_cpu_speed(policy, tegra_cpu_highest_speed());
-
-out:
- mutex_unlock(tegra_cpu_lock);
- return ret;
+ target_cpu_speed[policy-cpu] = freq_table[index].frequency;
+ return tegra_update_cpu_speed(policy, tegra_cpu_highest_speed());
}
-static int tegra_pm_notify(struct notifier_block *nb, unsigned long event,
- void *dummy)
-{
- mutex_lock(tegra_cpu_lock);
- if (event == PM_SUSPEND_PREPARE) {
- struct cpufreq_policy *policy = cpufreq_cpu_get(0);
- is_suspended = true;
- pr_info(Tegra cpufreq suspend: setting frequency to %d kHz\n,
- freq_table[0].frequency);
- tegra_update_cpu_speed(policy, freq_table[0].frequency);
- cpufreq_cpu_put(policy);
- } else if (event == PM_POST_SUSPEND) {
- is_suspended = false;
- }
- mutex_unlock(tegra_cpu_lock);
-
- return NOTIFY_OK;
-}
-
-static struct notifier_block tegra_cpu_pm_notifier = {
- .notifier_call = tegra_pm_notify,
-};
-
static int tegra_cpu_init(struct cpufreq_policy *policy)
{
int ret;
@@ -192,6 +149,7 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
clk_prepare_enable(cpu_clk);
target_cpu_speed[policy-cpu] = tegra_getspeed(policy-cpu);
+ policy-suspend_freq = freq_table[0].frequency;
/* FIXME: what's the actual transition time? */
ret = cpufreq_generic_init(policy, freq_table, 300 * 1000);
@@ -201,9 +159,6 @@ static int tegra_cpu_init(struct cpufreq_policy *policy)
return ret;
}
- if (policy-cpu == 0)
- register_pm_notifier(tegra_cpu_pm_notifier);
-
return 0;
}
@@ -223,6 +178,9 @@ static struct cpufreq_driver tegra_cpufreq_driver = {
.exit = tegra_cpu_exit,
.name = tegra,
.attr = cpufreq_generic_attr,
+#ifdef CONFIG_PM
+ .suspend= cpufreq_generic_suspend,
+#endif
};
static int __init tegra_cpufreq_init(void)
--
1.7.12.rc2.18.g61b472e
--
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 V3 4/6] cpufreq: exynos: Use cpufreq_generic_suspend()
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 viresh.ku...@linaro.org
---
drivers/cpufreq/exynos-cpufreq.c | 97 +++-
1 file changed, 6 insertions(+), 91 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f3c2287..88a4e28 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -16,7 +16,6 @@
#include linux/slab.h
#include linux/regulator/consumer.h
#include linux/cpufreq.h
-#include linux/suspend.h
#include plat/cpu.h
@@ -26,10 +25,6 @@ static struct exynos_dvfs_info *exynos_info;
static struct regulator *arm_regulator;
-static unsigned int locking_frequency;
-static bool frequency_locked;
-static DEFINE_MUTEX(cpufreq_lock);
-
static unsigned int exynos_getspeed(unsigned int cpu)
{
return clk_get_rate(exynos_info-cpu_clk) / 1000;
@@ -138,82 +133,12 @@ out:
static int exynos_target(struct cpufreq_policy *policy, unsigned int index)
{
- struct cpufreq_frequency_table *freq_table = exynos_info-freq_table;
- int ret = 0;
-
- mutex_lock(cpufreq_lock);
-
- if (frequency_locked)
- goto out;
-
- ret = exynos_cpufreq_scale(freq_table[index].frequency);
-
-out:
- mutex_unlock(cpufreq_lock);
-
- return ret;
-}
-
-#ifdef CONFIG_PM
-static int exynos_cpufreq_suspend(struct cpufreq_policy *policy)
-{
- return 0;
-}
-
-static int exynos_cpufreq_resume(struct cpufreq_policy *policy)
-{
- return 0;
+ return exynos_cpufreq_scale(exynos_info-freq_table[index].frequency);
}
-#endif
-
-/**
- * exynos_cpufreq_pm_notifier - block CPUFREQ's activities in suspend-resume
- * context
- * @notifier
- * @pm_event
- * @v
- *
- * While frequency_locked == true, target() ignores every frequency but
- * locking_frequency. The locking_frequency value is the initial frequency,
- * which is set by the bootloader. In order to eliminate possible
- * inconsistency in clock values, we save and restore frequencies during
- * suspend and resume and block CPUFREQ activities. Note that the standard
- * suspend/resume cannot be used as they are too deep (syscore_ops) for
- * regulator actions.
- */
-static int exynos_cpufreq_pm_notifier(struct notifier_block *notifier,
- unsigned long pm_event, void *v)
-{
- int ret;
-
- switch (pm_event) {
- case PM_SUSPEND_PREPARE:
- mutex_lock(cpufreq_lock);
- frequency_locked = true;
- mutex_unlock(cpufreq_lock);
-
- ret = exynos_cpufreq_scale(locking_frequency);
- if (ret 0)
- return NOTIFY_BAD;
-
- break;
-
- case PM_POST_SUSPEND:
- mutex_lock(cpufreq_lock);
- frequency_locked = false;
- mutex_unlock(cpufreq_lock);
- break;
- }
-
- return NOTIFY_OK;
-}
-
-static struct notifier_block exynos_cpufreq_nb = {
- .notifier_call = exynos_cpufreq_pm_notifier,
-};
static int exynos_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
+ policy-suspend_freq = exynos_getspeed(policy-cpu);
return cpufreq_generic_init(policy, exynos_info-freq_table, 10);
}
@@ -227,8 +152,7 @@ static struct cpufreq_driver exynos_driver = {
.name = exynos_cpufreq,
.attr = cpufreq_generic_attr,
#ifdef CONFIG_PM
- .suspend= exynos_cpufreq_suspend,
- .resume = exynos_cpufreq_resume,
+ .suspend= cpufreq_generic_suspend,
#endif
};
@@ -263,19 +187,10 @@ static int __init exynos_cpufreq_init(void)
goto err_vdd_arm;
}
- locking_frequency = exynos_getspeed(0);
-
- register_pm_notifier(exynos_cpufreq_nb);
-
- if (cpufreq_register_driver(exynos_driver)) {
- pr_err(%s: failed to register cpufreq driver\n, __func__);
- goto err_cpufreq;
- }
-
- return 0;
-err_cpufreq:
- unregister_pm_notifier(exynos_cpufreq_nb);
+ if (!cpufreq_register_driver(exynos_driver))
+ return 0;
+ pr_err(%s: failed to register cpufreq driver\n, __func__);
regulator_put(arm_regulator);
err_vdd_arm:
kfree(exynos_info);
--
1.7.12.rc2.18.g61b472e
--
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 V3 2/6] cpufreq: call driver's suspend/resume for each policy
Earlier cpufreq suspend/resume callbacks into drivers were getting called only
for the boot CPU, as by the time callbacks were called non-boot CPUs were
already removed. Because we might still need driver specific actions on
suspend/resume, its better to use earlier infrastructure from the early
suspend/late resume calls.
In effect, we call suspend/resume for each policy. The resume part also takes
care of synchronising frequency for boot CPU, which might turn out be different
than what cpufreq core believes.
Hence, the earlier syscore infrastructure is getting removed now.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/cpufreq.c | 98 +--
1 file changed, 18 insertions(+), 80 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index b6c7821..026efe4a 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -27,7 +27,6 @@
#include linux/mutex.h
#include linux/slab.h
#include linux/suspend.h
-#include linux/syscore_ops.h
#include linux/tick.h
#include trace/events/power.h
@@ -1481,10 +1480,15 @@ void cpufreq_suspend(void)
pr_debug(%s: Suspending Governors\n, __func__);
- list_for_each_entry(policy, cpufreq_policy_list, policy_list)
+ 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);
+ else if (cpufreq_driver-suspend
+ cpufreq_driver-suspend(policy))
+ pr_err(%s: Failed to suspend driver: %p\n, __func__,
+ policy);
+ }
cpufreq_suspended = true;
}
@@ -1500,92 +1504,27 @@ void cpufreq_resume(void)
cpufreq_suspended = false;
- list_for_each_entry(policy, cpufreq_policy_list, policy_list)
+ 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.
- *
- * This function is only executed for the boot processor. The other CPUs
- * have been put offline by means of CPU hotplug.
- */
-static int cpufreq_bp_suspend(void)
-{
- int ret = 0;
-
- int cpu = smp_processor_id();
- struct cpufreq_policy *policy;
-
- pr_debug(suspending cpu %u\n, cpu);
-
- /* If there's no policy for the boot CPU, we have nothing to do. */
- policy = cpufreq_cpu_get(cpu);
- if (!policy)
- return 0;
-
- if (cpufreq_driver-suspend) {
- ret = cpufreq_driver-suspend(policy);
- if (ret)
- printk(KERN_ERR cpufreq: suspend failed in -suspend
- step on CPU %u\n, policy-cpu);
- }
-
- cpufreq_cpu_put(policy);
- return ret;
-}
-
-/**
- * cpufreq_bp_resume - Restore proper frequency handling of the boot CPU.
- *
- * 1.) resume CPUfreq hardware support (cpufreq_driver-resume())
- * 2.) schedule call cpufreq_update_policy() ASAP as interrupts are
- * restored. It will verify that the current freq is in sync with
- * what we believe it to be. This is a bit later than when it
- * should be, but nonethteless it's better than calling
- * cpufreq_driver-get() here which might re-enable interrupts...
- *
- * This function is only executed for the boot CPU. The other CPUs have not
- * been turned on yet.
- */
-static void cpufreq_bp_resume(void)
-{
- int ret = 0;
+ else if (cpufreq_driver-resume
+ cpufreq_driver-resume(policy))
+ pr_err(%s: Failed to resume driver: %p\n, __func__,
+ policy);
- int cpu = smp_processor_id();
- struct cpufreq_policy *policy;
-
- pr_debug(resuming cpu %u\n, cpu);
-
- /* If there's no policy for the boot CPU, we have nothing to do. */
- policy = cpufreq_cpu_get(cpu);
- if (!policy)
- return;
-
- if (cpufreq_driver-resume) {
- ret = cpufreq_driver-resume(policy);
- if (ret) {
- printk(KERN_ERR cpufreq: resume failed in -resume
- step on CPU %u\n, policy-cpu);
- goto fail;
- }
+ /*
+* schedule call cpufreq_update_policy() for boot CPU, i.e. last
+* policy in list. It will verify that the current
[PATCH V3 5/6] cpufreq: s5pv210: Use cpufreq_generic_suspend()
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 viresh.ku...@linaro.org
---
drivers/cpufreq/s5pv210-cpufreq.c | 49 +++
1 file changed, 3 insertions(+), 46 deletions(-)
diff --git a/drivers/cpufreq/s5pv210-cpufreq.c
b/drivers/cpufreq/s5pv210-cpufreq.c
index e3973da..89c052e 100644
--- a/drivers/cpufreq/s5pv210-cpufreq.c
+++ b/drivers/cpufreq/s5pv210-cpufreq.c
@@ -18,7 +18,6 @@
#include linux/cpufreq.h
#include linux/reboot.h
#include linux/regulator/consumer.h
-#include linux/suspend.h
#include mach/map.h
#include mach/regs-clock.h
@@ -444,18 +443,6 @@ exit:
return ret;
}
-#ifdef CONFIG_PM
-static int s5pv210_cpufreq_suspend(struct cpufreq_policy *policy)
-{
- return 0;
-}
-
-static int s5pv210_cpufreq_resume(struct cpufreq_policy *policy)
-{
- return 0;
-}
-#endif
-
static int check_mem_type(void __iomem *dmc_reg)
{
unsigned long val;
@@ -511,6 +498,7 @@ static int __init s5pv210_cpu_init(struct cpufreq_policy
*policy)
s5pv210_dram_conf[1].refresh = (__raw_readl(S5P_VA_DMC1 + 0x30) * 1000);
s5pv210_dram_conf[1].freq = clk_get_rate(dmc1_clk);
+ policy-suspend_freq = SLEEP_FREQ;
return cpufreq_generic_init(policy, s5pv210_freq_table, 4);
out_dmc1:
@@ -520,32 +508,6 @@ out_dmc0:
return ret;
}
-static int s5pv210_cpufreq_notifier_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- int ret;
-
- switch (event) {
- case PM_SUSPEND_PREPARE:
- ret = cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
- if (ret 0)
- return NOTIFY_BAD;
-
- /* Disable updation of cpu frequency */
- no_cpufreq_access = true;
- return NOTIFY_OK;
- case PM_POST_RESTORE:
- case PM_POST_SUSPEND:
- /* Enable updation of cpu frequency */
- no_cpufreq_access = false;
- cpufreq_driver_target(cpufreq_cpu_get(0), SLEEP_FREQ, 0);
-
- return NOTIFY_OK;
- }
-
- return NOTIFY_DONE;
-}
-
static int s5pv210_cpufreq_reboot_notifier_event(struct notifier_block *this,
unsigned long event, void *ptr)
{
@@ -567,15 +529,11 @@ static struct cpufreq_driver s5pv210_driver = {
.init = s5pv210_cpu_init,
.name = s5pv210,
#ifdef CONFIG_PM
- .suspend= s5pv210_cpufreq_suspend,
- .resume = s5pv210_cpufreq_resume,
+ .suspend= cpufreq_generic_suspend,
+ .resume = cpufreq_generic_suspend, /* We need to set SLEEP FREQ
again */
#endif
};
-static struct notifier_block s5pv210_cpufreq_notifier = {
- .notifier_call = s5pv210_cpufreq_notifier_event,
-};
-
static struct notifier_block s5pv210_cpufreq_reboot_notifier = {
.notifier_call = s5pv210_cpufreq_reboot_notifier_event,
};
@@ -595,7 +553,6 @@ static int __init s5pv210_cpufreq_init(void)
return PTR_ERR(int_regulator);
}
- register_pm_notifier(s5pv210_cpufreq_notifier);
register_reboot_notifier(s5pv210_cpufreq_reboot_notifier);
return cpufreq_register_driver(s5pv210_driver);
--
1.7.12.rc2.18.g61b472e
--
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 V3 0/6] cpufreq: suspend early/resume late
This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors and core. This is required for early suspend
and late resume of governors and cpufreq core.
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. Most of these are updated in this
patchset to use new infrastructure.
- 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 don't
allow any operation on Governors during suspend/resume now.
So to solve these issues we introduce early suspend and late resume callbacks
which would remove need of cpufreq drivers to implement PM notifiers to disable
transition after suspend and before resume.
@Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
doesn't work for you. I am sure it will not, but would be better if you confirm
that.
Viresh Kumar (6):
cpufreq: suspend governors on system suspend/hibernate
cpufreq: call driver's suspend/resume for each policy
cpufreq: Implement cpufreq_generic_suspend()
cpufreq: exynos: Use cpufreq_generic_suspend()
cpufreq: s5pv210: Use cpufreq_generic_suspend()
cpufreq: Tegra: Use cpufreq_generic_suspend()
drivers/base/power/main.c | 5 ++
drivers/cpufreq/cpufreq.c | 133 +-
drivers/cpufreq/exynos-cpufreq.c | 97 ++-
drivers/cpufreq/s5pv210-cpufreq.c | 49 +-
drivers/cpufreq/tegra-cpufreq.c | 54 ++--
include/linux/cpufreq.h | 6 ++
6 files changed, 99 insertions(+), 245 deletions(-)
--
1.7.12.rc2.18.g61b472e
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park kmp...@infradead.org wrote: On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. This is correspondant to the PIN_CONFIG_OUTPUT from include/linux/pinctrl/pinconf-generic.h I.e. driving a pin - any pin, even one that cannot do GPIO - high or low as default. One could argue that if you can drive the pin high/low using software then by definition it *is* GPIO. Even if it cannot trigger IRQs or anything. The rationale for having it in pinconf-generic is basically for use cases such that one of the the pin config states the device pass through may relate to what the documentation calls the GPIO mode fallacy - a state on the pins that is definately related to the use case of a certain device, but puts the pin in something the manual calls GPIO mode in order to save power. But from a use case point of view that is not GPIO, it is the typically the sleep state of a certain pin when used with a certain device. I'll see if I can think of some doc patch to make this more clear... Yours, Linus Walleij -- 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] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
On Wed, Nov 20, 2013 at 3:00 PM, Tomasz Figa t.f...@samsung.com wrote: Stephen: Is the lifetime of the string returned by of_property_read_string_index() really so short that you must copy the string? I'd be tempted just to store the pointer, although perhaps you need to get() the node so that's safe. Right. I have done it the copy-less way in other places, but missed this one. Thanks. So I guess I'm waiting for a new version of this patch, right? Yours, Linus Walleij -- 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] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
Hi, Could you please apply this patch? Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics On Friday, October 04, 2013 02:36:42 PM 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 b.zolnier...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- 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 -- 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] thermal: EXYNOS: always register TMU driver with core thermal framework
Hi,
Could you please also apply this patch?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
There is little sense in having separate config option for
registering EXYNOS TMU driver with the core thermal framework.
Fix it by integrating EXYNOS_THERMAL_CORE config option with
EXYNOS_THERMAL one.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/samsung/Kconfig | 14 +++---
drivers/thermal/samsung/Makefile| 2 +-
drivers/thermal/samsung/exynos_thermal_common.h | 12
3 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
index f760389..04eabee 100644
--- a/drivers/thermal/samsung/Kconfig
+++ b/drivers/thermal/samsung/Kconfig
@@ -5,14 +5,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for the TMU (Thermal Management
Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
initialises
the TMU, reports temperature and handles cooling action if defined.
- This driver uses the Exynos core thermal APIs and TMU configuration
- data from the supported SoCs.
-
-config EXYNOS_THERMAL_CORE
- bool Core thermal framework support for EXYNOS SOCs
- depends on EXYNOS_THERMAL
- help
- If you say yes here you get support for EXYNOS TMU
- (Thermal Management Unit) common registration/unregistration
- functions to the core thermal layer and also to use the generic
- CPU cooling APIs.
+ This driver uses the Exynos core thermal APIs, TMU configuration data
+ from the supported SoCs, common registration/unregistration functions
+ to the core thermal layer and also the generic CPU cooling APIs.
diff --git a/drivers/thermal/samsung/Makefile
b/drivers/thermal/samsung/Makefile
index c09d830..a829107 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_EXYNOS_THERMAL) += exynos_thermal.o
exynos_thermal-y := exynos_tmu.o
exynos_thermal-y += exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) += exynos_thermal_common.o
+exynos_thermal-y += exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..8681679 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -88,20 +88,8 @@ struct thermal_sensor_conf {
struct device *dev;
};
-/*Functions used exynos based thermal sensor driver*/
-#ifdef CONFIG_EXYNOS_THERMAL_CORE
void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
-#else
-static inline void
-exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) { return;
}
-static inline int
-exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return 0;
}
-
-static inline void
-exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return; }
-
-#endif /* CONFIG_EXYNOS_THERMAL_CORE */
#endif /* _EXYNOS_THERMAL_COMMON_H */
--
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 3/3] usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework
On Tue, Nov 05, 2013 at 05:13:21PM +0100, Kamil Debski wrote:
Change the used phy driver to the new Exynos USB phy driver that uses the
generic phy framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/usb/gadget/s3c-hsotg.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index bb31262..dc7f20c 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -31,6 +31,7 @@
#include linux/regulator/consumer.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/phy/phy.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
@@ -162,7 +163,7 @@ struct s3c_hsotg_ep {
struct s3c_hsotg {
struct device*dev;
struct usb_gadget_driver *driver;
- struct usb_phy *phy;
+ struct phy *phy;
struct s3c_hsotg_plat*plat;
spinlock_t lock;
@@ -2905,9 +2906,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg
*hsotg)
dev_dbg(hsotg-dev, pdev 0x%p\n, pdev);
if (hsotg-phy)
- usb_phy_init(hsotg-phy);
+ phy_power_on(hsotg-phy);
else if (hsotg-plat-phy_init)
hsotg-plat-phy_init(pdev, hsotg-plat-phy_type);
+
Stray whitespace
}
/**
@@ -2922,7 +2924,7 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg
*hsotg)
struct platform_device *pdev = to_platform_device(hsotg-dev);
if (hsotg-phy)
- usb_phy_shutdown(hsotg-phy);
+ phy_power_off(hsotg-phy);
else if (hsotg-plat-phy_exit)
hsotg-plat-phy_exit(pdev, hsotg-plat-phy_type);
}
@@ -3529,7 +3531,7 @@ static void s3c_hsotg_delete_debug(struct s3c_hsotg
*hsotg)
static int s3c_hsotg_probe(struct platform_device *pdev)
{
struct s3c_hsotg_plat *plat = dev_get_platdata(pdev-dev);
- struct usb_phy *phy;
+ struct phy *phy;
struct device *dev = pdev-dev;
struct s3c_hsotg_ep *eps;
struct s3c_hsotg *hsotg;
@@ -3544,7 +3546,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
return -ENOMEM;
}
- phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ phy = devm_phy_get(pdev-dev, device);
A more descriptive string would be useful here IMHO. Since this is USB
2.0 IP, perhaps usb2-phy like musb uses.
phy-names = usb2-phy;
looks far more unique than
phy-names = device;
in the dts.
Also, this has impact on the samsung-hsotg.txt binding. It should be
updated to reflect the required generic phy properties that will be
used when booting from DT:
- phys: phy provider specifier
- phy-names: shall be device
[or usb2-phy if the above suggestion is adopted]
I've rebased my BCM281xx UDC series [1] against this s3c-hsotg generic
phy support and it's working fine. I do add phy_init/phy_exit support
which is probably better coming in with my series as my phy driver
makes use of the init method.
Tested-by: Matt Porter matt.por...@linaro.org
-Matt
[1] http://www.kernelhub.org/?msg=367354p=2
--
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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On 25/11/2013 16:34, Linus Walleij wrote: On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park kmp...@infradead.org wrote: On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. This is correspondant to the PIN_CONFIG_OUTPUT from include/linux/pinctrl/pinconf-generic.h Indeed it is - I was waiting for someone to point that out. Now we've got there... I've been working on extending the shmobile PFC driver to provide gpio-mode and implement PIN_CONFIG_OUTPUT as described by Documentation/pinctrl.txt, primarily to handle sleep states, but I have begun to wonder about the initial state problem, as discussed here. As far as I can see, we can't currently specify fallback states for pins, which is one of Tomasz' key requirements. We can specify hog states, and we can specify default for a driver, but not default before/in absence of a driver or sleep in absence of a driver. Having a hog precludes any finer driver control, AFAICT. Some of our existing pre-pinconf board files have a unused pins table which is used to claim and pull GPIOs. I've converted that to hog pinconf, but that only works because the table omits all pins used by drivers. And, unsurprisingly, that's been error-prone; if those tables originally covered all unused pins, they don't any more. I'd like confidence that we can get every pin into the correct state by having a fully-populated table containing all pins, that can be used regardless of which drivers start. I think what we're lacking is a weak hog. Whatever you call that. :) That would also specify the state to fallback to when a group is released (where we currently do pinmux_disable_setting). Thoughts? Kevin -- 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 0/6] cpufreq: suspend early/resume late
On 11/25/2013 08:11 AM, Viresh Kumar wrote:
This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors and core. This is required for early
suspend
and late resume of governors and cpufreq core.
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. Most of these are updated in this
patchset to use new infrastructure.
- 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
don't
allow any operation on Governors during suspend/resume now.
So to solve these issues we introduce early suspend and late resume callbacks
which would remove need of cpufreq drivers to implement PM notifiers to
disable
transition after suspend and before resume.
@Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
doesn't work for you. I am sure it will not, but would be better if you
confirm
that.
Viresh Kumar (6):
cpufreq: suspend governors on system suspend/hibernate
cpufreq: call driver's suspend/resume for each policy
patches 1-2,
Tested-by: Nishanth Menon n...@ti.com
http://pastebin.mozilla.org/3670932
Prior to these two patches: http://pastebin.mozilla.org/3670933
cpufreq driver used: cpufreq_cpu0
--
Regards,
Nishanth Menon
--
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 V9 1/3] ARM: dts: Add pmu sysreg node to exynos5250 and exynos5420 dtsi files
Hi Leela Krishna, On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala l.kris...@samsung.com wrote: This patch adds pmusysreg node to exynos5250 and exynos5420 dtsi files to handle PMU register accesses in a centralized way using syscon driver Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- Documentation/devicetree/bindings/arm/samsung/pmu.txt | 16 arch/arm/boot/dts/exynos5250.dtsi |5 + arch/arm/boot/dts/exynos5420.dtsi |5 + 3 files changed, 26 insertions(+) Looks good to me. I've tested this applied to our local tree https://chromium-review.googlesource.com/#/c/177931/ and it's working well for me. Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org -- 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 V9 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register
Hi Leela Krishna,
On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala
l.kris...@samsung.com 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 l.kris...@samsung.com
---
.../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
https://chromium-review.googlesource.com/#/c/177935/1/drivers/watchdog/s3c2410_wdt.c,
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.
*/
+
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.
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).
+ }
+ }
+
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.
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?
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, right?
+
return 0;
err_cpufreq:
@@ -459,8 +566,15 @@ static int s3c2410wdt_probe(struct platform_device *pdev)
static int s3c2410wdt_remove(struct platform_device *dev)
{
+ int ret;
struct s3c2410_wdt *wdt = platform_get_drvdata(dev);
+ if (wdt-drv_data-quirks QUIRK_NEEDS_PMU_CONFIG) {
+ ret = s3c2410wdt_mask_and_disable_reset(wdt, true);
This function does return an error. Why not pass the error on
through? The system wouldn't be in such a stellar state, but if
regmap is failing it's probably pretty bad anyway...
Nothing here is terrible and I wouldn't be upset if you landed these
as-is, but since it seems that Guenter is requesting a spin. Perhaps
you could address my comments, too?
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
Re: [PATCH V9 3/3] ARM: dts: update watchdog device nodes for Exynos5250 and Exynos5420
Leela Krishna, On Mon, Nov 18, 2013 at 1:49 AM, Leela Krishna Amudala l.kris...@samsung.com wrote: In Exynos5 series SoCs, PMU has registers to enable/disable mask/unmask watchdog timer which is not the case with s3c series SoCs so, there is a need to have different compatible names for watchdog to handle these pmu registers access. Hence this patch removes watchdog node from Exynos5.dtsi common file and make it separate by updating existing node in Exynos5250 and adding new node to Exynos5420. This patch also makes the watchdog node enabled by default Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com Reviewed-by: Tomasz Figa t.f...@samsung.com --- arch/arm/boot/dts/exynos5.dtsi|7 --- arch/arm/boot/dts/exynos5250.dtsi |6 +- arch/arm/boot/dts/exynos5420.dtsi |9 + 3 files changed, 14 insertions(+), 8 deletions(-) I've got this locally running in our tree https://chromium-review.googlesource.com/#/c/177933/ based on your patch. Reviewed-by: Doug Anderson diand...@chromium.org Tested-by: Doug Anderson diand...@chromium.org -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 Monday, November 25, 2013 07:41:41 PM Viresh Kumar wrote:
This patch adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors. This is required for early suspend and
late resume of governors and cpufreq core.
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
don't
allow any operation on Governors during suspend/resume now.
Reported-by: Lan Tianyu tianyu@intel.com
Reported-by: Nishanth Menon n...@ti.com
Reported-by: Jinhyuk Choi jinc...@broadcom.com
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/base/power/main.c | 5 +
drivers/cpufreq/cpufreq.c | 50
+++ include/linux/cpufreq.h
| 3 +++
3 files changed, 58 insertions(+)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 1b41fca..c9fbb9d 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -29,6 +29,7 @@
#include linux/async.h
#include linux/suspend.h
#include trace/events/power.h
+#include linux/cpufreq.h
#include linux/cpuidle.h
#include linux/timer.h
@@ -789,6 +790,8 @@ void dpm_resume(pm_message_t state)
mutex_unlock(dpm_list_mtx);
async_synchronize_full();
dpm_show_time(starttime, state, NULL);
+
+ cpufreq_resume();
}
/**
@@ -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?
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 linux/module.h
#include linux/mutex.h
#include linux/slab.h
+#include linux/suspend.h
#include linux/syscore_ops.h
#include linux/tick.h
#include trace/events/power.h
@@ -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);
This appears to be racy. Is it really racy, or just seemingly?
+
+ 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,
[PATCH] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX
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 CPU_FREQ_S3C24XX 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 CPU_FREQ_S3C24XX 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 diand...@chromium.org --- drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index 7d8fd04..4980f84 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param) return IRQ_HANDLED; } -#ifdef CONFIG_CPU_FREQ +#ifdef CONFIG_CPU_FREQ_S3C24XX static int s3c2410wdt_cpufreq_transition(struct notifier_block *nb, unsigned long val, void *data) -- 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: Only register for cpufreq on CPU_FREQ_S3C24XX
On 11/25/2013 02:55 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 CPU_FREQ_S3C24XX 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 CPU_FREQ_S3C24XX 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 diand...@chromium.org --- drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index 7d8fd04..4980f84 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param) return IRQ_HANDLED; } -#ifdef CONFIG_CPU_FREQ +#ifdef CONFIG_CPU_FREQ_S3C24XX Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it in the current upstream kernel, so it appears that this depends on some out-of-tree changes. 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] watchdog: s3c2410_wdt: Only register for cpufreq on CPU_FREQ_S3C24XX
Guenter, On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck li...@roeck-us.net wrote: On 11/25/2013 02:55 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 CPU_FREQ_S3C24XX 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 CPU_FREQ_S3C24XX 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 diand...@chromium.org --- drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index 7d8fd04..4980f84 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param) return IRQ_HANDLED; } -#ifdef CONFIG_CPU_FREQ +#ifdef CONFIG_CPU_FREQ_S3C24XX Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it in the current upstream kernel, so it appears that this depends on some out-of-tree changes. Whoops! I guess I just trusted another patch and didn't dig. I was basing this on https://patchwork.kernel.org/patch/3023421/ Ah, I see that Tomasz just found the answer. I'll update my patch. -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: Only register for cpufreq on CPU_FREQ_S3C24XX
On Monday 25 of November 2013 15:23:27 Guenter Roeck wrote: On 11/25/2013 02:55 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 CPU_FREQ_S3C24XX 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 CPU_FREQ_S3C24XX 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 diand...@chromium.org --- drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index 7d8fd04..4980f84 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param) return IRQ_HANDLED; } -#ifdef CONFIG_CPU_FREQ +#ifdef CONFIG_CPU_FREQ_S3C24XX Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it in the current upstream kernel, so it appears that this depends on some out-of-tree changes. Seems like it got renamed to ARM_S3C24XX_CPUFREQ by f023f8dd59. Best regards, Tomasz -- 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] ARM: exynos_defconfig: increase CONFIG_NR_CPUS value to 8
Tomasz Figa wrote: Hi Bart, On Thursday 21 of November 2013 13:06:06 Bartlomiej Zolnierkiewicz wrote: Current CONFIG_NR_CPUS value (2) is too small for: - EXYNOS4412 (4 cores) - EXYNOS5440 (4 cores) - EXYNOS5410 (8 cores) - EXYNOS5420 (8 cores) Set CONFIG_NR_CPUS to 8 so it is correct for all currently supported SoCs. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com --- arch/arm/configs/exynos_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Definitely a change we want to have. Reviewed-by: Tomasz Figa t.f...@samsung.com Applied and you can see this in my tree in a couple of days. Thanks, Kukjin -- 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: Only register for cpufreq on CPU_FREQ_S3C24XX
On Monday 25 of November 2013 15:28:29 Doug Anderson wrote: Guenter, On Mon, Nov 25, 2013 at 3:23 PM, Guenter Roeck li...@roeck-us.net wrote: On 11/25/2013 02:55 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 CPU_FREQ_S3C24XX 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 CPU_FREQ_S3C24XX 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 diand...@chromium.org --- drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index 7d8fd04..4980f84 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param) return IRQ_HANDLED; } -#ifdef CONFIG_CPU_FREQ +#ifdef CONFIG_CPU_FREQ_S3C24XX Where is the CPU_FREQ_S3C24XX configuration option defined ? I don't see it in the current upstream kernel, so it appears that this depends on some out-of-tree changes. Whoops! I guess I just trusted another patch and didn't dig. I was basing this on https://patchwork.kernel.org/patch/3023421/ Ah, I see that Tomasz just found the answer. I'll update my patch. Seems like I originally gave you the wrong symbol name, looking at our internal 3.10 tree, where the rename is not present yet, and nobody noticed. Sorry for that. Best regards, Tomasz -- 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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
Naveen, On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based on a fixed 66 MHz peripheral clock, and therefore is completely independent of the cpu frequency. Thus, registering for a CPU freq notifier is very wasteful. This patch modifes the code such that, i2c bus registers to cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled. This change should save a bunch of cpufreq transitions calls which does not apply to exynos SoCs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Doug Anderson diand...@chromium.org --- Changes since v2: None, Rebased on for-next of linux-i2c git repo. Changes since v1: Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ !CONFIG_EXYNOS) As commented by Tomasz drivers/i2c/busses/i2c-s3c2410.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Can you please spin this with comments from https://patchwork.kernel.org/patch/3235091/? 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
[PATCH v2] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ
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 diand...@chromium.org --- Changes in v2: - Use the updated config name. drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c index 7d8fd04..c1ada33 100644 --- a/drivers/watchdog/s3c2410_wdt.c +++ b/drivers/watchdog/s3c2410_wdt.c @@ -264,7 +264,7 @@ static irqreturn_t s3c2410wdt_irq(int irqno, void *param) return IRQ_HANDLED; } -#ifdef CONFIG_CPU_FREQ +#ifdef CONFIG_ARM_S3C24XX_CPUFREQ static int s3c2410wdt_cpufreq_transition(struct notifier_block *nb, unsigned long val, void *data) -- 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 v2] watchdog: s3c2410_wdt: Only register for cpufreq on ARM_S3C24XX_CPUFREQ
On Monday 25 of November 2013 15:36:43 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 diand...@chromium.org --- Changes in v2: - Use the updated config name. drivers/watchdog/s3c2410_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Tomasz Figa t.f...@samsung.com Best regards, Tomasz -- 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 V9 2/3] watchdog: s3c2410_wdt: use syscon regmap interface to configure pmu register
On Monday 25 of November 2013 14:44:01 Doug Anderson wrote:
+
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.
That would mean adding extra tabs in lines above to align them with the
longest drv_data field.
AFAIK we're observing a trend of moving away from such field alignment,
so IMHO it would be better to keep this as is in this version and just
send a separate patch removing the alignment of remaining fields.
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;
Jumping away just to a single return statement isn't really a good idea.
If there is nothing to do, returning right away seems less confusing IMHO
(and saves you one line of code per each such error case as a side
effect).
A separate patch could be possibly made to clean-up remaining error cases
and remove the err label.
As for all the remaining points, I agree with Doug.
Best regards,
Tomasz
--
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: Only register for cpufreq on CPU_FREQ_S3C24XX
On Tuesday 26 of November 2013 00:08:31 Ben Dooks wrote: On Mon, Nov 25, 2013 at 02:55:37PM -0800, 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 CPU_FREQ_S3C24XX defined. The S3C2410 to at-least S3C2440 there is only one PLL/clock-divider set so changing any part of that can change frequency supplied to the watchdog. And so we're leaving the notifier code intact, just changing the ifdef conditionm which decides whether it should be compiled in, from a (too) generic one to an S3C24xx-specific one. Best regards, Tomasz -- 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: Only register for cpufreq on CPU_FREQ_S3C24XX
On Mon, Nov 25, 2013 at 02:55:37PM -0800, 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 CPU_FREQ_S3C24XX defined. The S3C2410 to at-least S3C2440 there is only one PLL/clock-divider set so changing any part of that can change frequency supplied to the watchdog. -- 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] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Monday 25 of November 2013 22:01:42 Kevin Bracey wrote: On 25/11/2013 16:34, Linus Walleij wrote: On Wed, Nov 20, 2013 at 1:02 AM, Kyungmin Park kmp...@infradead.org wrote: On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. This is correspondant to the PIN_CONFIG_OUTPUT from include/linux/pinctrl/pinconf-generic.h Indeed it is - I was waiting for someone to point that out. Now we've got there... I've been working on extending the shmobile PFC driver to provide gpio-mode and implement PIN_CONFIG_OUTPUT as described by Documentation/pinctrl.txt, primarily to handle sleep states, but I have begun to wonder about the initial state problem, as discussed here. As far as I can see, we can't currently specify fallback states for pins, which is one of Tomasz' key requirements. We can specify hog states, and we can specify default for a driver, but not default before/in absence of a driver or sleep in absence of a driver. Having a hog precludes any finer driver control, AFAICT. Some of our existing pre-pinconf board files have a unused pins table which is used to claim and pull GPIOs. I've converted that to hog pinconf, but that only works because the table omits all pins used by drivers. And, unsurprisingly, that's been error-prone; if those tables originally covered all unused pins, they don't any more. I'd like confidence that we can get every pin into the correct state by having a fully-populated table containing all pins, that can be used regardless of which drivers start. I think what we're lacking is a weak hog. Whatever you call that. :) That would also specify the state to fallback to when a group is released (where we currently do pinmux_disable_setting). Thoughts? I fully agree with Kevin. We're currently also using hogs for this, but as Kevin mentioned, this is error prone, as it can be used for pins that are not touched by any drivers. IMHO a way to specify a default safe state of all pins (with lowest power consumption, without possibility of glitching external devices, etc.) would be really useful for Samsung platforms (and probably Renesas ones as Kevin wrote). Best regards, Tomasz -- 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] pinctrl: samsung: Allow grouping multiple pinmux/pinconf nodes
On Monday 25 of November 2013 15:46:12 Linus Walleij wrote: On Wed, Nov 20, 2013 at 3:00 PM, Tomasz Figa t.f...@samsung.com wrote: Stephen: Is the lifetime of the string returned by of_property_read_string_index() really so short that you must copy the string? I'd be tempted just to store the pointer, although perhaps you need to get() the node so that's safe. Right. I have done it the copy-less way in other places, but missed this one. Thanks. So I guess I'm waiting for a new version of this patch, right? Right. Best regards, Tomasz -- 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: linux 3.13-rc1 make dw_mmc-exynos more worse
On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
Hi,
On Sun, Nov 24, 2013 at 4:07 AM, randy lxr1...@hotmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After pull the merge of 3.13-rc1, the dw_mmc-exynos will make the boot
stock.In 3.13, it is just stocked udev in 3.13 and makse udev timeout
but kernel report the emmc device is found.
And in the Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I
saw that it is need to define which gpio ports that a emmc slot use,
but when I watched others dts, they use pinctrl, which is correct?
Here is the log and dts
[..]
===log begin =
[..]
[0.00] CPU EXYNOS4412 (id 0xe4412011)
[..]
[1.095000] mmc0: no vmmc regulator found
[1.13] mmc0: SDHCI controller on samsung-hsmmc
[1253.sdhci] using ADMA
[1.13] Synopsys Designware Multimedia Card Interface Driver
[1.13] Unable to handle kernel NULL pointer dereference at
virtual address 002a
[1.13] pgd = c0004000
[1.13] [002a] *pgd=
[1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[1.14] Modules linked in:
[1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.13.0-rc1-8-g584fa45-dirty #3
[1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000
[1.155000] PC is at clk_get_rate+0x18/0x5c
[1.16] LR is at clk_prepare_lock+0xc/0xd8
[1.165000] pc : [c0319400]lr : [c0318864]psr: a113
[1.165000] sp : ef0a9e20 ip : ee94eb40 fp :
[1.175000] r10: c0571510 r9 : ef0a8000 r8 : ef227a10
[1.18] r7 : c043544c r6 : fffe r5 : ee94ead0 r4 : fffe
[1.185000] r3 : ef0a4000 r2 : 0001 r1 : 02b9 r0 : 0001
[1.195000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[1.20] Control: 10c5387d Table: 4000404a DAC: 0015
[1.205000] Process swapper/0 (pid: 1, stack limit = 0xef0a8240)
[1.21] Stack: (0xef0a9e20 to 0xef0aa000)
[1.215000] 9e20: c0308474 ee9ea610 ee94ead0 c0308488 c0308474
ee9ea610 c030592c
[1.225000] 9e40: ef227a10 1000 c043544c c020a920 c0838b04
17d78400 ee9ea610 ef227a00
[1.235000] 9e60: ef227a10 c05d6b1c c05d6b1c c05890b0
ef0a8000 c0571510 c0269448
[1.24] 9e80: c0269430 ef227a10 c061291c c0268088
ef227a10 c05d6b1c ef227a44
[1.25] 9ea0: c026822c c05d6b1c c02681a0
c02668a8 ef005478 ef212740
[1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864 c0511e38
c05d6b1c 0006 c05d6b1c
[1.265000] 9ee0: 0006 c059575c c05df580 c026884c
c05a2e14 0006 c00088dc
[1.275000] 9f00: c0603f70 ef163e00 c040e334 6113 c05b5000
a113 c05b5054 c05b5050
[1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4 0093
c0035158 c05b5054 c05a2a20
[1.29] 9f40: c050ae2c c054a438 0006 0006
c05a2e14 0006 c059575c
[1.30] 9f60: c05df580 0093 c0595768 c0571510
c0571c48 0006 0006
[1.305000] 9f80: c0571510 c003df68 c0403544
[1.315000] 9fa0: c040354c c000e738
[1.32] 9fc0:
[1.33] 9fe0: 0013
be73efa4 bffd
[1.34] [c0319400] (clk_get_rate+0x18/0x5c) from [c0308488]
(dw_mci_exynos_setup_clock+0x14/0x2c)
[1.35] [c0308488] (dw_mci_exynos_setup_clock+0x14/0x2c) from
[c030592c] (dw_mci_probe+0x15c/0xca4)
[1.36] [c030592c] (dw_mci_probe+0x15c/0xca4) from
[c0269448] (platform_drv_probe+0x18/0x48)
[1.365000] [c0269448] (platform_drv_probe+0x18/0x48) from
[c0268088] (driver_probe_device+0x100/0x218)
[1.375000] [c0268088] (driver_probe_device+0x100/0x218) from
[c026822c] (__driver_attach+0x8c/0x90)
[1.385000] [c026822c] (__driver_attach+0x8c/0x90) from
[c02668a8] (bus_for_each_dev+0x54/0x88)
[1.395000] [c02668a8] (bus_for_each_dev+0x54/0x88) from
[c0267864] (bus_add_driver+0xd4/0x1d0)
[1.405000] [c0267864] (bus_add_driver+0xd4/0x1d0) from
[c026884c] (driver_register+0x78/0xf4)
[1.415000] [c026884c] (driver_register+0x78/0xf4) from
[c00088dc] (do_one_initcall+0xec/0x148)
[1.42] [c00088dc] (do_one_initcall+0xec/0x148) from
[c0571c48] (kernel_init_freeable+0xfc/0x1c8)
[1.43] [c0571c48] (kernel_init_freeable+0xfc/0x1c8) from
[c040354c] (kernel_init+0x8/0x110)
[1.44] [c040354c] (kernel_init+0x8/0x110) from [c000e738]
(ret_from_fork+0x14/0x3c)
[1.45] Code: ebfffd18 e354 01a05004 0a08 (e594302c)
Looks like a clock issue on 4412? I only have 5250 that I boot test
on, no EXYNOS4 coverage at all
Re: linux 3.13-rc1 make dw_mmc-exynos more worse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
于 2013年11月26日 08:41, Tomasz Figa 写道:
On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
Hi,
On Sun, Nov 24, 2013 at 4:07 AM, randy lxr1...@hotmail.com
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
After pull the merge of 3.13-rc1, the dw_mmc-exynos will make
the boot stock.In 3.13, it is just stocked udev in 3.13 and
makse udev timeout but kernel report the emmc device is found.
And in the
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I saw
that it is need to define which gpio ports that a emmc slot
use, but when I watched others dts, they use pinctrl, which is
correct? Here is the log and dts
[..]
===log begin =
[..]
[0.00] CPU EXYNOS4412 (id 0xe4412011)
[..]
[1.095000] mmc0: no vmmc regulator found [1.13]
mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci] using
ADMA [1.13] Synopsys Designware Multimedia Card
Interface Driver [1.13] Unable to handle kernel NULL
pointer dereference at virtual address 002a [1.13]
pgd = c0004000 [1.13] [002a] *pgd= [
1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [
1.14] Modules linked in: [1.14] CPU: 0 PID: 1 Comm:
swapper/0 Not tainted 3.13.0-rc1-8-g584fa45-dirty #3 [
1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [
1.155000] PC is at clk_get_rate+0x18/0x5c [1.16] LR is
at clk_prepare_lock+0xc/0xd8 [1.165000] pc : [c0319400]
lr : [c0318864]psr: a113 [1.165000] sp : ef0a9e20
ip : ee94eb40 fp : [1.175000] r10: c0571510 r9 :
ef0a8000 r8 : ef227a10 [1.18] r7 : c043544c r6 :
fffe r5 : ee94ead0 r4 : fffe [1.185000] r3 :
ef0a4000 r2 : 0001 r1 : 02b9 r0 : 0001 [
1.195000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel [1.20] Control: 10c5387d Table:
4000404a DAC: 0015 [1.205000] Process swapper/0 (pid:
1, stack limit = 0xef0a8240) [1.21] Stack: (0xef0a9e20
to 0xef0aa000) [1.215000] 9e20: c0308474 ee9ea610 ee94ead0
c0308488 c0308474 ee9ea610 c030592c [1.225000]
9e40: ef227a10 1000 c043544c c020a920 c0838b04 17d78400
ee9ea610 ef227a00 [1.235000] 9e60: ef227a10 c05d6b1c
c05d6b1c c05890b0 ef0a8000 c0571510 c0269448 [
1.24] 9e80: c0269430 ef227a10 c061291c c0268088
ef227a10 c05d6b1c ef227a44 [1.25] 9ea0:
c026822c c05d6b1c c02681a0 c02668a8 ef005478 ef212740
[1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864
c0511e38 c05d6b1c 0006 c05d6b1c [1.265000] 9ee0:
0006 c059575c c05df580 c026884c c05a2e14 0006
c00088dc [1.275000] 9f00: c0603f70 ef163e00 c040e334
6113 c05b5000 a113 c05b5054 c05b5050 [1.28]
9f20: c05df580 c054ad68 c0839c96 c04247b4 0093 c0035158
c05b5054 c05a2a20 [1.29] 9f40: c050ae2c c054a438
0006 0006 c05a2e14 0006 c059575c [
1.30] 9f60: c05df580 0093 c0595768 c0571510
c0571c48 0006 0006 [1.305000] 9f80: c0571510
c003df68 c0403544
[1.315000] 9fa0: c040354c c000e738
[1.32] 9fc0:
[1.33] 9fe0:
0013 be73efa4 bffd [1.34]
[c0319400] (clk_get_rate+0x18/0x5c) from [c0308488]
(dw_mci_exynos_setup_clock+0x14/0x2c) [1.35]
[c0308488] (dw_mci_exynos_setup_clock+0x14/0x2c) from
[c030592c] (dw_mci_probe+0x15c/0xca4) [1.36]
[c030592c] (dw_mci_probe+0x15c/0xca4) from [c0269448]
(platform_drv_probe+0x18/0x48) [1.365000] [c0269448]
(platform_drv_probe+0x18/0x48) from [c0268088]
(driver_probe_device+0x100/0x218) [1.375000] [c0268088]
(driver_probe_device+0x100/0x218) from [c026822c]
(__driver_attach+0x8c/0x90) [1.385000] [c026822c]
(__driver_attach+0x8c/0x90) from [c02668a8]
(bus_for_each_dev+0x54/0x88) [1.395000] [c02668a8]
(bus_for_each_dev+0x54/0x88) from [c0267864]
(bus_add_driver+0xd4/0x1d0) [1.405000] [c0267864]
(bus_add_driver+0xd4/0x1d0) from [c026884c]
(driver_register+0x78/0xf4) [1.415000] [c026884c]
(driver_register+0x78/0xf4) from [c00088dc]
(do_one_initcall+0xec/0x148) [1.42] [c00088dc]
(do_one_initcall+0xec/0x148) from [c0571c48]
(kernel_init_freeable+0xfc/0x1c8) [1.43] [c0571c48]
(kernel_init_freeable+0xfc/0x1c8) from [c040354c]
(kernel_init+0x8/0x110) [1.44] [c040354c]
(kernel_init+0x8/0x110) from [c000e738]
(ret_from_fork+0x14/0x3c) [1.45] Code: ebfffd18
e354 01a05004 0a08 (e594302c)
Looks like a clock issue on 4412? I only have 5250 that I boot
test on, no EXYNOS4 coverage at all (I had an Odroid-X but it
Re: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On 26 November 2013 04:59, Rafael J. Wysocki r...@rjwysocki.net 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?
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.
--
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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
Hello Doug, On 26 November 2013 05:11, Doug Anderson diand...@chromium.org wrote: Naveen, On Mon, Nov 18, 2013 at 10:18 PM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based on a fixed 66 MHz peripheral clock, and therefore is completely independent of the cpu frequency. Thus, registering for a CPU freq notifier is very wasteful. This patch modifes the code such that, i2c bus registers to cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled. This change should save a bunch of cpufreq transitions calls which does not apply to exynos SoCs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Doug Anderson diand...@chromium.org --- Changes since v2: None, Rebased on for-next of linux-i2c git repo. Changes since v1: Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ !CONFIG_EXYNOS) As commented by Tomasz drivers/i2c/busses/i2c-s3c2410.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Can you please spin this with comments from https://patchwork.kernel.org/patch/3235091/? Thanks! Thanks for pointing out for me To summarize, Post f023f8dd59 commit we should be using ARM_S3C24XX_CPUFREQ instead of ARM_S3C24XX_CPUFREQ right. Will re-spin with this changes. -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 -- Thanks Regards, (: 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: [PATCH V3 1/6] cpufreq: suspend governors on system suspend/hibernate
On Monday 25 November 2013 07:41 PM, Viresh Kumar wrote:
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index dc196bb..6d93f91 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -255,6 +255,9 @@ struct cpufreq_driver {
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
+void cpufreq_suspend(void);
+void cpufreq_resume(void);
+
const char *cpufreq_get_current_driver(void);
static inline void cpufreq_verify_within_limits(struct cpufreq_policy
*policy,
A minor fix here to get kernel compiled without cpufreq support enabled:
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 8d8b2f4..d40809d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -259,9 +259,6 @@ struct cpufreq_driver {
int cpufreq_register_driver(struct cpufreq_driver *driver_data);
int cpufreq_unregister_driver(struct cpufreq_driver *driver_data);
-void cpufreq_suspend(void);
-void cpufreq_resume(void);
-
const char *cpufreq_get_current_driver(void);
static inline void cpufreq_verify_within_limits(struct cpufreq_policy *policy,
@@ -287,6 +284,14 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy
*policy)
policy-cpuinfo.max_freq);
}
+#ifdef CONFIG_CPU_FREQ
+void cpufreq_suspend(void);
+void cpufreq_resume(void);
+#elif
+static inline void cpufreq_suspend(void) {}
+static inline void cpufreq_resume(void) {}
+#endif
+
/*
* CPUFREQ NOTIFIER INTERFACE*
*/
--
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] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
on a fixed 66 MHz peripheral clock, and therefore is completely
independent of the cpu frequency.
Thus, registering for a CPU freq notifier is very wasteful.
This patch modifes the code such that, i2c bus registers to
cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
This change should save a bunch of cpufreq transitions calls
which does not apply to exynos SoCs.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes since v3:
As per discussion at https://patchwork.kernel.org/patch/3235091/
Post f023f8dd59 commit we should be using
ARM_S3C24XX_CPUFREQ instead of CPU_FREQ_S3C24XX
upstrea linux kernel and linuxsamsung already has the commit
f023f8dd59. Hence, rebasing the patch.
drivers/i2c/busses/i2c-s3c2410.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index bf8fb94..a77ce13 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -123,7 +123,7 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
struct pinctrl *pctrl;
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
struct notifier_block freq_transition;
#endif
};
@@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c,
unsigned int *got)
return 0;
}
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_ARM_S3C24XX_CPUFREQ)
#define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
--
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
[PATCH 1/2 v2] i2c: exynos5: add support for HSI2C on Exynos5260 SoC
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 ch.nav...@samsung.com
---
Changes since v1:
Rebasing on linux-i2c for-next
.../devicetree/bindings/i2c/i2c-exynos5.txt|6 +++-
drivers/i2c/busses/i2c-exynos5.c | 31 ++--
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
index 056732c..704ab92 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -5,7 +5,11 @@ at various speeds ranging from 100khz to 3.4Mhz.
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.
+ - 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,
+ EXYNOS_5260
};
static const struct of_device_id exynos5_i2c_match[] = {
- { .compatible = samsung,exynos5-hsi2c },
+ {
+ .compatible = samsung,exynos5-hsi2c,
+ .data = (void *)EXYNOS_5 },
+ {
+ .compatible = samsung,exynos5260-hsi2c,
+ .data = (void *)EXYNOS_5260 },
{},
};
MODULE_DEVICE_TABLE(of, exynos5_i2c_match);
+static inline unsigned int exynos5_i2c_get_version(struct platform_device
*pdev)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(exynos5_i2c_match, pdev-dev.of_node);
+ return (unsigned int)match-data;
+}
+
static void exynos5_i2c_clr_pend_irq(struct exynos5_i2c *i2c)
{
writel(readl(i2c-regs + HSI2C_INT_STATUS),
@@ -692,7 +713,13 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
- exynos5_i2c_init(i2c);
+ i2c-version = exynos5_i2c_get_version(pdev);
+
+ /* The HS-I2C core on Exynos5260 needs a reset to start with */
+ if (i2c-version == EXYNOS_5260)
+ exynos5_i2c_reset(i2c);
+ else
+ exynos5_i2c_init(i2c);
ret = i2c_add_adapter(i2c-adap);
if (ret 0) {
--
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
[PATCH 2/2 v2] i2c: exynos5: configure fifo_depth based on HSI2C module version
fifo_depth of the HSI2C is not constant
Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
Exynos5260 supports fifo_depth of 16bytes
This patch configures the fifo_depth based on HSI2C modules version.
Signed-off-by: Naveen Krishna Chatradhi ich.nav...@samsung.com
[For finding out the difference and initial contribution]
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
Changes since v1:
Added missed out Signed-off-by line for initial contribution
Also rebasing on linux-i2c for-next
drivers/i2c/busses/i2c-exynos5.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 497ff91..a3fdcd8 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -77,12 +77,6 @@
#define HSI2C_RXFIFO_TRIGGER_LEVEL(x) ((x) 4)
#define HSI2C_TXFIFO_TRIGGER_LEVEL(x) ((x) 16)
-/* As per user manual FIFO max depth is 64bytes */
-#define HSI2C_FIFO_MAX 0x40
-/* default trigger levels for Tx and Rx FIFOs */
-#define HSI2C_DEF_TXFIFO_LVL (HSI2C_FIFO_MAX - 0x30)
-#define HSI2C_DEF_RXFIFO_LVL (HSI2C_FIFO_MAX - 0x10)
-
/* I2C_TRAILING_CTL Register bits */
#define HSI2C_TRAILING_COUNT (0xf)
@@ -187,6 +181,9 @@ struct exynos5_i2c {
/* Version of HS-I2C Hardware */
unsigned intversion;
+
+ /* FIFO depth */
+ unsigned intfifo_depth;
};
enum hsi2c_version {
@@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
fifo_status = readl(i2c-regs + HSI2C_FIFO_STATUS);
fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
- len = HSI2C_FIFO_MAX - fifo_level;
+ len = i2c-fifo_depth - fifo_level;
if (len (i2c-msg-len - i2c-msg_ptr))
len = i2c-msg-len - i2c-msg_ptr;
@@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
u32 i2c_auto_conf = 0;
u32 fifo_ctl;
unsigned long flags;
+ unsigned short trig_lvl;
i2c_ctl = readl(i2c-regs + HSI2C_CTL);
i2c_ctl = ~(HSI2C_TXCHON | HSI2C_RXCHON);
@@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct exynos5_i2c
*i2c, int stop)
i2c_auto_conf = HSI2C_READ_WRITE;
- fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
+ trig_lvl = (i2c-msg-len i2c-fifo_depth) ?
+ (i2c-fifo_depth * 3/4) : i2c-msg-len;
+ fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(trig_lvl);
+
int_en |= (HSI2C_INT_RX_ALMOSTFULL_EN |
HSI2C_INT_TRAILING_EN);
} else {
i2c_ctl |= HSI2C_TXCHON;
- fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(HSI2C_DEF_RXFIFO_LVL);
+ trig_lvl = (i2c-msg-len i2c-fifo_depth) ?
+ (i2c-fifo_depth * 1/4) : i2c-msg-len;
+ fifo_ctl |= HSI2C_TXFIFO_TRIGGER_LEVEL(trig_lvl);
+
int_en |= HSI2C_INT_TX_ALMOSTEMPTY_EN;
}
@@ -716,10 +720,13 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
i2c-version = exynos5_i2c_get_version(pdev);
/* The HS-I2C core on Exynos5260 needs a reset to start with */
- if (i2c-version == EXYNOS_5260)
+ if (i2c-version == EXYNOS_5260) {
+ i2c-fifo_depth = 16;
exynos5_i2c_reset(i2c);
- else
+ } else {
+ i2c-fifo_depth = 64;
exynos5_i2c_init(i2c);
+ }
ret = i2c_add_adapter(i2c-adap);
if (ret 0) {
--
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: linux 3.13-rc1 make dw_mmc-exynos more worse
Hi, Randy,
It seems a problem that controller didn't find the clock source.
Also you can see the below message. Did you check the clock source?
[1.125000] s3c-sdhci 1255.sdhci: failed to get io clock
Actually, need to prevent the null pointer dereference for clock in dw-mmc.c
And If dw-mmc controller can be used, recommend to use it.
dw-mmc can use DDR mode, but sdhci can't.
Best Regards,
Jaehoon Chung
On 11/26/2013 10:47 AM, randy wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
于 2013年11月26日 08:41, Tomasz Figa 写道:
On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
Hi,
On Sun, Nov 24, 2013 at 4:07 AM, randy lxr1...@hotmail.com
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
After pull the merge of 3.13-rc1, the dw_mmc-exynos will make
the boot stock.In 3.13, it is just stocked udev in 3.13 and
makse udev timeout but kernel report the emmc device is found.
And in the
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt I saw
that it is need to define which gpio ports that a emmc slot
use, but when I watched others dts, they use pinctrl, which is
correct? Here is the log and dts
[..]
===log begin =
[..]
[0.00] CPU EXYNOS4412 (id 0xe4412011)
[..]
[1.095000] mmc0: no vmmc regulator found [1.13]
mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci] using
ADMA [1.13] Synopsys Designware Multimedia Card
Interface Driver [1.13] Unable to handle kernel NULL
pointer dereference at virtual address 002a [1.13]
pgd = c0004000 [1.13] [002a] *pgd= [
1.135000] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [
1.14] Modules linked in: [1.14] CPU: 0 PID: 1 Comm:
swapper/0 Not tainted 3.13.0-rc1-8-g584fa45-dirty #3 [
1.15] task: ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [
1.155000] PC is at clk_get_rate+0x18/0x5c [1.16] LR is
at clk_prepare_lock+0xc/0xd8 [1.165000] pc : [c0319400]
lr : [c0318864]psr: a113 [1.165000] sp : ef0a9e20
ip : ee94eb40 fp : [1.175000] r10: c0571510 r9 :
ef0a8000 r8 : ef227a10 [1.18] r7 : c043544c r6 :
fffe r5 : ee94ead0 r4 : fffe [1.185000] r3 :
ef0a4000 r2 : 0001 r1 : 02b9 r0 : 0001 [
1.195000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel [1.20] Control: 10c5387d Table:
4000404a DAC: 0015 [1.205000] Process swapper/0 (pid:
1, stack limit = 0xef0a8240) [1.21] Stack: (0xef0a9e20
to 0xef0aa000) [1.215000] 9e20: c0308474 ee9ea610 ee94ead0
c0308488 c0308474 ee9ea610 c030592c [1.225000]
9e40: ef227a10 1000 c043544c c020a920 c0838b04 17d78400
ee9ea610 ef227a00 [1.235000] 9e60: ef227a10 c05d6b1c
c05d6b1c c05890b0 ef0a8000 c0571510 c0269448 [
1.24] 9e80: c0269430 ef227a10 c061291c c0268088
ef227a10 c05d6b1c ef227a44 [1.25] 9ea0:
c026822c c05d6b1c c02681a0 c02668a8 ef005478 ef212740
[1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864
c0511e38 c05d6b1c 0006 c05d6b1c [1.265000] 9ee0:
0006 c059575c c05df580 c026884c c05a2e14 0006
c00088dc [1.275000] 9f00: c0603f70 ef163e00 c040e334
6113 c05b5000 a113 c05b5054 c05b5050 [1.28]
9f20: c05df580 c054ad68 c0839c96 c04247b4 0093 c0035158
c05b5054 c05a2a20 [1.29] 9f40: c050ae2c c054a438
0006 0006 c05a2e14 0006 c059575c [
1.30] 9f60: c05df580 0093 c0595768 c0571510
c0571c48 0006 0006 [1.305000] 9f80: c0571510
c003df68 c0403544
[1.315000] 9fa0: c040354c c000e738
[1.32] 9fc0:
[1.33] 9fe0:
0013 be73efa4 bffd [1.34]
[c0319400] (clk_get_rate+0x18/0x5c) from [c0308488]
(dw_mci_exynos_setup_clock+0x14/0x2c) [1.35]
[c0308488] (dw_mci_exynos_setup_clock+0x14/0x2c) from
[c030592c] (dw_mci_probe+0x15c/0xca4) [1.36]
[c030592c] (dw_mci_probe+0x15c/0xca4) from [c0269448]
(platform_drv_probe+0x18/0x48) [1.365000] [c0269448]
(platform_drv_probe+0x18/0x48) from [c0268088]
(driver_probe_device+0x100/0x218) [1.375000] [c0268088]
(driver_probe_device+0x100/0x218) from [c026822c]
(__driver_attach+0x8c/0x90) [1.385000] [c026822c]
(__driver_attach+0x8c/0x90) from [c02668a8]
(bus_for_each_dev+0x54/0x88) [1.395000] [c02668a8]
(bus_for_each_dev+0x54/0x88) from [c0267864]
(bus_add_driver+0xd4/0x1d0) [1.405000] [c0267864]
(bus_add_driver+0xd4/0x1d0) from [c026884c]
(driver_register+0x78/0xf4) [1.415000] [c026884c]
(driver_register+0x78/0xf4) from [c00088dc]
(do_one_initcall+0xec/0x148) [1.42] [c00088dc]
Re: [alsa-devel] [PATCH 1/2] ASoC: samsung: Provide helper for DMA init
Hi Mark, On Tue, Nov 12, 2013 at 7:18 PM, Mark Brown broo...@kernel.org wrote: From: Mark Brown broo...@linaro.org In preparation for using the dmaengine helpers in ASoC rather than the dmaengine wrappers for the Samsung API wrap the configuration of dma_data. The dmaengine code expects different data to that used by the legacy API. Signed-off-by: Mark Brown broo...@linaro.org --- sound/soc/samsung/ac97.c | 51 +++- sound/soc/samsung/dma.c | 8 sound/soc/samsung/dma.h | 3 +++ sound/soc/samsung/i2s.c | 2 +- sound/soc/samsung/pcm.c | 18 + 5 files changed, 38 insertions(+), 44 deletions(-) [snip] diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index a5cbdb4..67d9fa9 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -963,7 +963,7 @@ static int samsung_i2s_dai_probe(struct snd_soc_dai *dai) } clk_prepare_enable(i2s-clk); - 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. 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: [alsa-devel] [PATCH 2/2] ASoC: samsung: Use ASoC dmaengine code where possible
Hi Mark,
On Tue, Nov 12, 2013 at 7:18 PM, Mark Brown broo...@kernel.org wrote:
From: Mark Brown broo...@linaro.org
Since all Exynos platforms have been converted to dmaengine and many of
the older platforms are in the process of conversion they do not need to
use the legacy s3c-dma APIs for DMA but can instead use the standard ASoC
dmaengine helpers. This both allows them to benefit from improvements
implemented in the generic code and supports multiplatform.
Signed-off-by: Mark Brown broo...@linaro.org
---
This depends on Tomasz's s3c64xx dmaengine conversion since that is how
I've tested it - if possible I'd like to get that merged into ASoC and
SPI early after -rc1, since I maintian both trees it's possibly easiest
if I go ahead any apply it?
sound/soc/samsung/Kconfig | 13 +--
sound/soc/samsung/Makefile| 6 ++--
sound/soc/samsung/dma.h | 3 ++
sound/soc/samsung/dmaengine.c | 82
+++
4 files changed, 100 insertions(+), 4 deletions(-)
create mode 100644 sound/soc/samsung/dmaengine.c
[snip]
void samsung_asoc_init_dma_data(struct snd_soc_dai *dai,
diff --git a/sound/soc/samsung/dmaengine.c b/sound/soc/samsung/dmaengine.c
new file mode 100644
index 000..ad0a371
--- /dev/null
+++ b/sound/soc/samsung/dmaengine.c
@@ -0,0 +1,82 @@
+/*
+ * dmaengine.c - Samsung dmaengine wrapper
+ *
+ * Author: Mark Brown broo...@linaro.org
+ * Copyright 2013 Linaro
+ *
+ * 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.
+ *
+ * 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.
+ *
+ */
+
+#include linux/module.h
+#include linux/amba/pl08x.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/dmaengine_pcm.h
+#include sound/soc.h
+#include sound/soc-dai.h
+
+#include dma.h
+
+#ifdef CONFIG_ARCH_S3C64XX
+#define filter_fn pl08x_filter_id
+#else
+#define filter_fn NULL
+#endif
+
+static const struct snd_dmaengine_pcm_config samsung_dmaengine_pcm_config = {
+ .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
+ .compat_filter_fn = filter_fn,
+};
+
+void samsung_asoc_init_dma_data(struct snd_soc_dai *dai,
+ struct s3c_dma_params *playback,
+ struct s3c_dma_params *capture)
+{
+ struct snd_dmaengine_dai_dma_data *playback_data = NULL;
+ struct snd_dmaengine_dai_dma_data *capture_data = NULL;
+
+ if (playback) {
+ playback_data = playback-dma_data;
+ playback_data-filter_data = (void *)playback-channel;
+ playback_data-chan_name = playback-ch_name;
+ playback_data-addr = playback-dma_addr;
+ playback_data-addr_width = playback-dma_size;
+ }
+ if (capture) {
+ capture_data = capture-dma_data;
+ capture_data-filter_data = (void *)capture-channel;
+ capture_data-chan_name = capture-ch_name;
+ capture_data-addr = capture-dma_addr;
+ capture_data-addr_width = capture-dma_size;
+ }
+
+ snd_soc_dai_init_dma_data(dai, playback_data, capture_data);
+}
+EXPORT_SYMBOL_GPL(samsung_asoc_init_dma_data);
+
+int samsung_asoc_dma_platform_register(struct device *dev)
+{
+ return snd_dmaengine_pcm_register(dev, samsung_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_COMPAT);
also need to pass flag SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME here?
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)
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: linux 3.13-rc1 make dw_mmc-exynos more worse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks Jaehoon,
I have noticed that before it, but in dw_mmc driver, I won't meet this
problem.
As you can seen in dts, I have defined a clock source.
Or the clock source what I choose is not correct?
I don't know how to debug this, I don't know much about it.
Actually, I don't really understand the contain in chapter 7 of datasheet.
I am sorry for that.
Would you like to tell me some more about it?
于 2013年11月26日 12:32, Jaehoon Chung 写道:
Hi, Randy,
It seems a problem that controller didn't find the clock source.
Also you can see the below message. Did you check the clock
source?
[1.125000] s3c-sdhci 1255.sdhci: failed to get io clock
Actually, need to prevent the null pointer dereference for clock
in dw-mmc.c
And If dw-mmc controller can be used, recommend to use it. dw-mmc
can use DDR mode, but sdhci can't.
Best Regards, Jaehoon Chung
On 11/26/2013 10:47 AM, randy wrote: 于 2013年11月26日 08:41, Tomasz
Figa 写道:
On Sunday 24 of November 2013 22:18:46 Olof Johansson wrote:
Hi,
On Sun, Nov 24, 2013 at 4:07 AM, randy
lxr1...@hotmail.com wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
After pull the merge of 3.13-rc1, the dw_mmc-exynos will
make the boot stock.In 3.13, it is just stocked udev in
3.13 and makse udev timeout but kernel report the emmc
device is found.
And in the
Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
I saw that it is need to define which gpio ports that a
emmc slot use, but when I watched others dts, they use
pinctrl, which is correct? Here is the log and dts
[..]
===log begin
=
[..]
[0.00] CPU EXYNOS4412 (id 0xe4412011)
[..]
[1.095000] mmc0: no vmmc regulator found [ 1.13]
mmc0: SDHCI controller on samsung-hsmmc [1253.sdhci]
using ADMA [1.13] Synopsys Designware Multimedia
Card Interface Driver [ 1.13] Unable to handle kernel
NULL pointer dereference at virtual address 002a [
1.13] pgd = c0004000 [1.13] [002a]
*pgd= [ 1.135000] Internal error: Oops: 5 [#1]
PREEMPT SMP ARM [ 1.14] Modules linked in: [
1.14] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
3.13.0-rc1-8-g584fa45-dirty #3 [ 1.15] task:
ef0a4000 ti: ef0a8000 task.ti: ef0a8000 [ 1.155000] PC
is at clk_get_rate+0x18/0x5c [1.16] LR is at
clk_prepare_lock+0xc/0xd8 [1.165000] pc :
[c0319400] lr : [c0318864]psr: a113 [
1.165000] sp : ef0a9e20 ip : ee94eb40 fp : [
1.175000] r10: c0571510 r9 : ef0a8000 r8 : ef227a10 [
1.18] r7 : c043544c r6 : fffe r5 : ee94ead0
r4 : fffe [1.185000] r3 : ef0a4000 r2 :
0001 r1 : 02b9 r0 : 0001 [ 1.195000] Flags:
NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel [ 1.20] Control: 10c5387d Table: 4000404a
DAC: 0015 [1.205000] Process swapper/0 (pid: 1,
stack limit = 0xef0a8240) [1.21] Stack:
(0xef0a9e20 to 0xef0aa000) [1.215000] 9e20: c0308474
ee9ea610 ee94ead0 c0308488 c0308474 ee9ea610
c030592c [ 1.225000] 9e40: ef227a10 1000 c043544c
c020a920 c0838b04 17d78400 ee9ea610 ef227a00 [
1.235000] 9e60: ef227a10 c05d6b1c c05d6b1c
c05890b0 ef0a8000 c0571510 c0269448 [ 1.24] 9e80:
c0269430 ef227a10 c061291c c0268088 ef227a10
c05d6b1c ef227a44 [ 1.25] 9ea0: c026822c
c05d6b1c c02681a0 c02668a8 ef005478 ef212740 [
1.255000] 9ec0: c05d6b1c ef2c7900 c05cf438 c0267864
c0511e38 c05d6b1c 0006 c05d6b1c [1.265000] 9ee0:
0006 c059575c c05df580 c026884c c05a2e14
0006 c00088dc [ 1.275000] 9f00: c0603f70 ef163e00
c040e334 6113 c05b5000 a113 c05b5054 c05b5050 [
1.28] 9f20: c05df580 c054ad68 c0839c96 c04247b4
0093 c0035158 c05b5054 c05a2a20 [1.29] 9f40:
c050ae2c c054a438 0006 0006 c05a2e14
0006 c059575c [ 1.30] 9f60: c05df580 0093
c0595768 c0571510 c0571c48 0006 0006 [
1.305000] 9f80: c0571510 c003df68 c0403544
[1.315000] 9fa0:
c040354c c000e738
[ 1.32] 9fc0:
[
1.33] 9fe0:
0013 be73efa4 bffd [1.34]
[c0319400] (clk_get_rate+0x18/0x5c) from [c0308488]
(dw_mci_exynos_setup_clock+0x14/0x2c) [1.35]
[c0308488] (dw_mci_exynos_setup_clock+0x14/0x2c) from
[c030592c] (dw_mci_probe+0x15c/0xca4) [1.36]
[c030592c] (dw_mci_probe+0x15c/0xca4) from [c0269448]
(platform_drv_probe+0x18/0x48) [ 1.365000] [c0269448]
(platform_drv_probe+0x18/0x48) from [c0268088]
(driver_probe_device+0x100/0x218) [ 1.375000]
[c0268088] (driver_probe_device+0x100/0x218) from
[c026822c] (__driver_attach+0x8c/0x90) [ 1.385000]
[c026822c]
Re: [PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined
On 10/4/13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com 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 b.zolnier...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Looks good, so Acked-by: Amit Daniel Kachhap amit.dan...@samsung.com --- 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 -- 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] thermal: EXYNOS: always register TMU driver with core thermal framework
On 11/25/13, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote:
Hi,
Could you please also apply this patch?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
On Friday, October 04, 2013 02:38:25 PM Bartlomiej Zolnierkiewicz wrote:
There is little sense in having separate config option for
registering EXYNOS TMU driver with the core thermal framework.
Fix it by integrating EXYNOS_THERMAL_CORE config option with
EXYNOS_THERMAL one.
Sorry for the late reply but this patch is not needed as in my opinion
as it is just decreasing the flexibility when only sensor hardware
needs to be initialised and all cooling is hw controlled.
Thanks,
Amit D
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/thermal/samsung/Kconfig | 14 +++---
drivers/thermal/samsung/Makefile| 2 +-
drivers/thermal/samsung/exynos_thermal_common.h | 12
3 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/samsung/Kconfig
b/drivers/thermal/samsung/Kconfig
index f760389..04eabee 100644
--- a/drivers/thermal/samsung/Kconfig
+++ b/drivers/thermal/samsung/Kconfig
@@ -5,14 +5,6 @@ config EXYNOS_THERMAL
If you say yes here you get support for the TMU (Thermal Management
Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver
initialises
the TMU, reports temperature and handles cooling action if defined.
- This driver uses the Exynos core thermal APIs and TMU configuration
- data from the supported SoCs.
-
-config EXYNOS_THERMAL_CORE
-bool Core thermal framework support for EXYNOS SOCs
-depends on EXYNOS_THERMAL
-help
- If you say yes here you get support for EXYNOS TMU
- (Thermal Management Unit) common registration/unregistration
- functions to the core thermal layer and also to use the generic
- CPU cooling APIs.
+ This driver uses the Exynos core thermal APIs, TMU configuration data
+ from the supported SoCs, common registration/unregistration functions
+ to the core thermal layer and also the generic CPU cooling APIs.
diff --git a/drivers/thermal/samsung/Makefile
b/drivers/thermal/samsung/Makefile
index c09d830..a829107 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -4,4 +4,4 @@
obj-$(CONFIG_EXYNOS_THERMAL)+= exynos_thermal.o
exynos_thermal-y:= exynos_tmu.o
exynos_thermal-y+= exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)+=
exynos_thermal_common.o
+exynos_thermal-y+= exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..8681679 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -88,20 +88,8 @@ struct thermal_sensor_conf {
struct device *dev;
};
-/*Functions used exynos based thermal sensor driver*/
-#ifdef CONFIG_EXYNOS_THERMAL_CORE
void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
-#else
-static inline void
-exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) {
return; }
-static inline int
-exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return
0; }
-
-static inline void
-exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return;
}
-
-#endif /* CONFIG_EXYNOS_THERMAL_CORE */
#endif /* _EXYNOS_THERMAL_COMMON_H */
--
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
--
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 0/6] cpufreq: suspend early/resume late
On 2013年11月25日 22:11, Viresh Kumar wrote:
This patchset adds cpufreq callbacks to dpm_{suspend|resume}() for handling
suspend/resume of cpufreq governors and core. This is required for early
suspend
and late resume of governors and cpufreq core.
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. Most of these are updated in this
patchset to use new infrastructure.
- 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
don't
allow any operation on Governors during suspend/resume now.
So to solve these issues we introduce early suspend and late resume callbacks
which would remove need of cpufreq drivers to implement PM notifiers to
disable
transition after suspend and before resume.
@Nishanth: Can you please test V2 as well and confirm that suspend_noirq()
doesn't work for you. I am sure it will not, but would be better if you
confirm
that.
Viresh Kumar (6):
cpufreq: suspend governors on system suspend/hibernate
cpufreq: call driver's suspend/resume for each policy
cpufreq: Implement cpufreq_generic_suspend()
cpufreq: exynos: Use cpufreq_generic_suspend()
cpufreq: s5pv210: Use cpufreq_generic_suspend()
cpufreq: Tegra: Use cpufreq_generic_suspend()
Patch 1-2,
Tested-by: Lan Tianyu tianyu@intel.com
drivers/base/power/main.c | 5 ++
drivers/cpufreq/cpufreq.c | 133
+-
drivers/cpufreq/exynos-cpufreq.c | 97 ++-
drivers/cpufreq/s5pv210-cpufreq.c | 49 +-
drivers/cpufreq/tegra-cpufreq.c | 54 ++--
include/linux/cpufreq.h | 6 ++
6 files changed, 99 insertions(+), 245 deletions(-)
--
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
