Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying
this patch but there are some interesting side effects.
Well that's half good news.
I was looking on /proc/interrupts output. IRQ for CPU0 have MCT name
and IRQ for CPU1 has unexpectedly no name at all.
This is pretty confusing. I don't see how the patch could cause this to
happen.
After making hotplug cycle of CPU1 I've observed that IRQs attached
originally for that CPU are generating on really low count and not in
order with IRQ for CPU0.
What's more the interrupt for CPU1 is showing to me as being counted
for both CPUs, so it's probably not being attached to CPU1.
yeah. Can you give the output of /proc/timer_list in addition to
/proc/interrupts? It may give some hints on what's going on. It may also
be interesting to see if irq_force_affinity() is failing. Please check
the return value and print an error
Hi Stephen, Marcin,
can you have a look if the patch [1] fixes this issue ?
-- Daniel
[1] https://lkml.org/lkml/2015/1/30/423
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 1800053b4644..3c4538e26731 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -450,6 +450,7 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
{
struct mct_clock_event_device *mevt;
unsigned int cpu = smp_processor_id();
+ int ret;
mevt = container_of(evt, struct mct_clock_event_device, evt);
@@ -468,7 +469,9 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
enable_irq(evt-irq);
- irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+ ret = irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu],
cpumask_of(cpu));
+ if (ret)
+ pr_err(force failed %d\n, ret);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] thermal: exynos: Add TMU support for Exynos7 SoC
On Tue, Jan 27, 2015 at 11:18:22AM +0530, Abhilash Kesavan wrote:
Add registers, bit fields and compatible strings for Exynos7 TMU
(Thermal Management Unit). Following are a few of the differences
in the Exynos7 TMU from earlier SoCs:
- 8 trigger levels
- Different bit offsets and more registers for the rising
and falling thresholds.
- New power down detection bit in the TMU_CONTROL register
which does not update the CURRENT_TEMP0 when tmu power down
is detected.
- Change in bit offset for the NEXT_DATA field of EMUL_CON
register. EMUL_CON register address has also changed.
- INTSTAT and INTCLEAR registers present in earlier SoCs
have been combined into one INTPEND register. The register
address for INTCLEAR and INTPEND is also different.
- Since there are 8 rising/falling interrupts as against
at most 4 in earlier SoCs the INTEN bit offsets are different.
- Multiple probe support which is handled by a TMU_CONTROL1
register (No support for this in the current patch).
This patch adds special clock support required only for Exynos7. It
also updates the code_to_temp prototype as Exynos7 has 9 bit
code-temp mapping.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Applied to my -fixes branch. However, I had to amend it myself to make
checkpatch.pl --strict silent. In this version, it still outputs:
CHECK: Alignment should match open parenthesis
#209: FILE: drivers/thermal/samsung/exynos_tmu.c:558:
+ if (!data-temp_error1 ||
+ (pdata-min_efuse_value data-temp_error1) ||
CHECK: multiple assignments should be avoided
#366: FILE: drivers/thermal/samsung/exynos_tmu.c:882:
+ tmu_intstat = tmu_intclear = EXYNOS7_TMU_REG_INTPEND;
total: 0 errors, 0 warnings, 2 checks, 314 lines checked
next, make sure you run checkpatch.pl --strict before sending patches.
---
This patch set has been tested on linux next-20150123 with Eduardo's
thermal-next branch merged along with the arch-side exynos7 related
dts changes applied.
Changes since v3:
Addressed comments from Lukasz Majewski:
- Added more comments in the code setting the thresholds.
- Split the documentation out into another patch.
Changes since v2:
- Rebased on top of Lukasz' latest exynos tmu series (v4).
- Added new exynos7 soc_type.
Changes since v1:
- Rebased on top of Lukasz' latest exynos tmu series (v2).
- Added sclk support to patch adding Exynos7 tmu support.
Previously, it was a separate patch.
- Used the SOC type to decide if sclk is present.
drivers/thermal/samsung/exynos_tmu.c | 204
--
drivers/thermal/samsung/exynos_tmu.h |1 +
2 files changed, 197 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 852e622..660ff69 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -119,6 +119,26 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
+/* Exynos7 specific registers */
+#define EXYNOS7_THD_TEMP_RISE7_6 0x50
+#define EXYNOS7_THD_TEMP_FALL7_6 0x60
+#define EXYNOS7_TMU_REG_INTEN0x110
+#define EXYNOS7_TMU_REG_INTPEND 0x118
+#define EXYNOS7_TMU_REG_EMUL_CON 0x160
+
+#define EXYNOS7_TMU_TEMP_MASK0x1ff
+#define EXYNOS7_PD_DET_EN_SHIFT 23
+#define EXYNOS7_TMU_INTEN_RISE0_SHIFT0
+#define EXYNOS7_TMU_INTEN_RISE1_SHIFT1
+#define EXYNOS7_TMU_INTEN_RISE2_SHIFT2
+#define EXYNOS7_TMU_INTEN_RISE3_SHIFT3
+#define EXYNOS7_TMU_INTEN_RISE4_SHIFT4
+#define EXYNOS7_TMU_INTEN_RISE5_SHIFT5
+#define EXYNOS7_TMU_INTEN_RISE6_SHIFT6
+#define EXYNOS7_TMU_INTEN_RISE7_SHIFT7
+#define EXYNOS7_EMUL_DATA_SHIFT 7
+#define EXYNOS7_EMUL_DATA_MASK 0x1ff
+
#define MCELSIUS 1000
/**
* struct exynos_tmu_data : A structure to hold the private data of the TMU
@@ -133,6 +153,7 @@
* @lock: lock to implement synchronization.
* @clk: pointer to the clock structure.
* @clk_sec: pointer to the clock structure for accessing the base_second.
+ * @sclk: pointer to the clock structure for accessing the tmu special clk.
* @temp_error1: fused value of the first point trim.
* @temp_error2: fused value of the second point trim.
* @regulator: pointer to the TMU regulator structure.
@@ -152,8 +173,8 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
- struct clk *clk, *clk_sec;
- u8 temp_error1, temp_error2;
+ struct clk
[PATCHv2 1/1] cpufreq: exynos: allow modular build
From: Arnd Bergmann a...@arndb.de The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux...@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 (cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered) Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Eduardo Valentin edubez...@gmail.com --- drivers/cpufreq/Kconfig.arm | 44 ++-- drivers/cpufreq/Makefile| 9 + 2 files changed, 31 insertions(+), 22 deletions(-) --- Changes from V1: - Instead of having several modules, the driver now is constructed by several files into a single module, depending on config. - The patch does not change existing user defconfigs. If no objections, I will include this in into my -fixes branch. Cheers, Eduardo Valentin diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index 0f9a2c3..1b06fc4 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -26,13 +26,21 @@ config ARM_VEXPRESS_SPC_CPUFREQ config ARM_EXYNOS_CPUFREQ - bool + tristate SAMSUNG EXYNOS CPUfreq Driver + depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250 + depends on THERMAL + help + This adds the CPUFreq driver for Samsung EXYNOS platforms. + Supported SoC versions are: +Exynos4210, Exynos4212, Exynos4412, and Exynos5250. + + If in doubt, say N. config ARM_EXYNOS4210_CPUFREQ bool SAMSUNG EXYNOS4210 depends on CPU_EXYNOS4210 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS4210 SoC (S5PV310 or S5PC210). @@ -42,8 +50,8 @@ config ARM_EXYNOS4210_CPUFREQ config ARM_EXYNOS4X12_CPUFREQ bool SAMSUNG EXYNOS4x12 depends on SOC_EXYNOS4212 || SOC_EXYNOS4412 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS4X12 SoC (EXYNOS4212 or EXYNOS4412). @@ -53,28 +61,14 @@ config ARM_EXYNOS4X12_CPUFREQ config ARM_EXYNOS5250_CPUFREQ bool SAMSUNG EXYNOS5250 depends on SOC_EXYNOS5250 + depends on ARM_EXYNOS_CPUFREQ default y - select ARM_EXYNOS_CPUFREQ help This adds the CPUFreq driver for Samsung EXYNOS5250 SoC. If in doubt, say N. -config ARM_EXYNOS5440_CPUFREQ - bool SAMSUNG EXYNOS5440 - depends on SOC_EXYNOS5440 - depends on HAVE_CLK OF - select PM_OPP - default y - help - This adds the CPUFreq driver for Samsung EXYNOS5440 - SoC. The nature of exynos5440 clock controller is - different than previous exynos controllers so not using - the common exynos framework. - - If in doubt, say N. - config ARM_EXYNOS_CPU_FREQ_BOOST_SW bool EXYNOS Frequency Overclocking - Software depends on ARM_EXYNOS_CPUFREQ THERMAL @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW If in doubt, say N. +config ARM_EXYNOS5440_CPUFREQ + tristate SAMSUNG EXYNOS5440 + depends on SOC_EXYNOS5440 + depends on HAVE_CLK OF + select PM_OPP + default y + help + This adds the CPUFreq driver for Samsung EXYNOS5440 + SoC. The nature of exynos5440 clock controller is + different than previous exynos controllers so not using + the common exynos framework. + + If in doubt, say N. + config ARM_HIGHBANK_CPUFREQ tristate Calxeda Highbank-based
Re: [PATCH 3/3] cpufreq: exynos: allow modular build
On Friday 30 January 2015 17:51:24 Eduardo Valentin wrote: @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW If in doubt, say N. +config ARM_EXYNOS5440_CPUFREQ + bool SAMSUNG EXYNOS5440 + depends on SOC_EXYNOS5440 + depends on HAVE_CLK OF + select PM_OPP + default y + help + This adds the CPUFreq driver for Samsung EXYNOS5440 + SoC. The nature of exynos5440 clock controller is + different than previous exynos controllers so not using + the common exynos framework. + + If in doubt, say N. I believe this one also has to be tristate, for the same reason. I agree with you that it is better if we make it tristate. So, on my side, I have no concerns changing it to tristate. However, the exynos5440 cpufreq driver does not depend on of thermal as of today, and therefore, I did not touch this driver for this matter. Meaning, if it is not causing troubles, no need to mess with it. But I can add this change. No issues, on my side. Sorry, my mistake. I remembered incorrectly that the problem was in both modules, but you are right that it does not exist in the exynos5440 one. It is not a mistake to turn this into tristate, but there is no immediate neeed, so either version is fine. Arnd -- 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
