RE: [PATCH v2] ARM: pl330: Fix a race condition
Jassi Brar wrote: > > On 29 November 2011 15:23, Javi Merino wrote: > >> On Samsung's Exynos4 platform, while testing audio playback with > >>> i2s > >> interface, the above change causes the playback to freeze. The > >> _thrd_active(thrd) call always returns '1' and hence _start(thrd) > >>> is > >> not getting called. > > > > If _thrd_active(thrd) returns '1', that means there is an active > > transfer still running or, if it has finished, you haven't called > > pl330_update() to acknowledge that. pl330_update() calls _start() > >>> as > > soon as it can. > > > > drivers/dma/pl330.c registers the irq handler in pl330_probe(), so > > when > > the transaction finishes, pl330_update() should clear it and call > > _start(). If there is any outstanding transaction, it should start > > straight away. If there isn't, it would mark the channel as free, > >>> so > > _thrd_active() should return '0'. If _thrd_active() is still '1', > >>> then > > something has gone wrong in the way. > > > > Does this shed some light? > > > > Your patch makes the memcpy operation on dmatest.c and net DMA be > >>> frozen too > as well as Samsung audio playback. > >>> > >>> Is the IRQ correctly registered in drivers/dma/pl330.c:pl330_probe()? > >>> Do you get interrupts when the transfer finish? > >> Sure. IRQ works well. > > > > Ok, so can you check if pl330_update() is correctly marking the request > > as free? Do you know if there is another request in the queue when that > > happens? > > > > Thomas, you said in a previous email that _thrd_active() always returned > > '1'. Was that after a request in req[0] finished? > > - If so, can you check that MARK_FREE was actually called for that > > request in pl330_update()? > > - If it was after a request in req[1] finished and there was a > > request already waiting in req[0], can you debug why _start() > > didn't activate it. > > > Javi, could you please check if you too get the memcpy failure with > dmatest ? (Please adding me in this thread) Hi Javi, How was going on the test? If any update, please let us know. Vinod, I think, if the issue cannot be fixed soon, the patch should be reverted until clear the issue. Because according to Boojin Kim's test, it does not affect only Samsung stuff. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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: SAMSUNG: remove duplicated header include
Jingoo Han wrote: > > This patch removes duplicated slab header for pwm backlight. > arch/arm/plat-samsung/dev-backlight.c: slab.h is included > more than once. > > Signed-off-by: Jingoo Han > --- > arch/arm/plat-samsung/dev-backlight.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-samsung/dev-backlight.c b/arch/arm/plat- > samsung/dev-backlight.c > index e657305..a976c02 100644 > --- a/arch/arm/plat-samsung/dev-backlight.c > +++ b/arch/arm/plat-samsung/dev-backlight.c > @@ -15,7 +15,6 @@ > #include > #include > #include > -#include > > #include > #include > -- > 1.7.1 Oops, ok. Will apply. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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: S5PV210: Set 1000ns as PWM backlight period on SMDKV210
Jingoo Han wrote:
>
> The SMDK board uses LT3591 as backlight LED driver of LTE480WV LCD.
> According to the LT3591 datasheet, the switching frequency should
> be 1MHz. So, PWM period is calculated by following formula:
>
> PWM period = 1/switching frequency
> = 1/1MHz
> = 1000ns
>
> Thus, the PWM backlight period should be 1000ns.
>
> Signed-off-by: Jingoo Han
> ---
> arch/arm/mach-s5pv210/mach-smdkv210.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-
> s5pv210/mach-smdkv210.c
> index a9106c3..8662ef6 100644
> --- a/arch/arm/mach-s5pv210/mach-smdkv210.c
> +++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
> @@ -273,6 +273,7 @@ static struct samsung_bl_gpio_info
> smdkv210_bl_gpio_info = {
>
> static struct platform_pwm_backlight_data smdkv210_bl_data = {
> .pwm_id = 3,
> + .pwm_period_ns = 1000,
> };
>
> static void __init smdkv210_map_io(void)
> --
> 1.7.1
OK, will apply.
But when I'm looking at this in other case, we need to update the default
value of pwm_period_ns?
Let me check.
(Cc'ed Mark Brown)
Mark,
If switch frequency is 1kHz, the value of pwm_period_ns should be 100 at
mach-crag6410.c not 10?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 5/5] [CPUFREQ] EXYNOS: Removed useless headers and codes
From: Jaecheol Lee
This patch removes no referencing header files and cleaned up
useless code.
Signed-off-by: Jaecheol Lee
Signed-off-by: Kukjin Kim
---
drivers/cpufreq/exynos-cpufreq.c |8 +---
drivers/cpufreq/exynos4210-cpufreq.c | 14 +-
2 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 24e4dd4..5467879 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -9,7 +9,6 @@
* published by the Free Software Foundation.
*/
-#include
#include
#include
#include
@@ -18,15 +17,10 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
+#include
static struct exynos_dvfs_info *exynos_info;
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
index 6bc4ada..065da5b 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -9,25 +9,17 @@
* published by the Free Software Foundation.
*/
-#include
+#include
#include
#include
#include
#include
#include
-#include
#include
-#include
-#include
-#include
#include
-#include
#include
-#include
-#include
-
#define CPUFREQ_LEVEL_END L5
static int max_support_idx = L0;
@@ -38,10 +30,6 @@ static struct clk *moutcore;
static struct clk *mout_mpll;
static struct clk *mout_apll;
-static struct regulator *arm_regulator;
-
-static struct cpufreq_freqs freqs;
-
struct cpufreq_clkdiv {
unsigned int index;
unsigned int clkdiv;
--
1.7.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
[PATCH 4/5] [CPUFREQ] EXYNOS: Make EXYNOS common cpufreq driver
From: Jaecheol Lee
To support various EXYNOS series SoCs commonly,
added exynos common structure.
exynos-cpufreq.c => EXYNOS series common cpufreq driver
exynos4210-cpufreq.c => EXYNOS4210 support cpufreq driver
Signed-off-by: Jaecheol Lee
Signed-off-by: Kukjin Kim
---
arch/arm/mach-exynos/include/mach/cpufreq.h | 34 +++
drivers/cpufreq/Kconfig.arm | 15 +-
drivers/cpufreq/Makefile|1 +
drivers/cpufreq/exynos-cpufreq.c| 296
drivers/cpufreq/exynos4210-cpufreq.c| 385 +--
5 files changed, 414 insertions(+), 317 deletions(-)
create mode 100644 arch/arm/mach-exynos/include/mach/cpufreq.h
create mode 100644 drivers/cpufreq/exynos-cpufreq.c
diff --git a/arch/arm/mach-exynos/include/mach/cpufreq.h
b/arch/arm/mach-exynos/include/mach/cpufreq.h
new file mode 100644
index 000..3df27f2
--- /dev/null
+++ b/arch/arm/mach-exynos/include/mach/cpufreq.h
@@ -0,0 +1,34 @@
+/* linux/arch/arm/mach-exynos/include/mach/cpufreq.h
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - CPUFreq support
+ *
+ * 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.
+*/
+
+enum cpufreq_level_index {
+ L0, L1, L2, L3, L4,
+ L5, L6, L7, L8, L9,
+ L10, L11, L12, L13, L14,
+ L15, L16, L17, L18, L19,
+ L20,
+};
+
+struct exynos_dvfs_info {
+ unsigned long mpll_freq_khz;
+ unsigned intpll_safe_idx;
+ unsigned intpm_lock_idx;
+ unsigned intmax_support_idx;
+ unsigned intmin_support_idx;
+ struct clk *cpu_clk;
+ unsigned int*volt_table;
+ struct cpufreq_frequency_table *freq_table;
+ void (*set_freq)(unsigned int, unsigned int);
+ bool (*need_apll_change)(unsigned int, unsigned int);
+};
+
+extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 72a0044..e0664fe 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -21,12 +21,19 @@ config ARM_S5PV210_CPUFREQ
If in doubt, say N.
+config ARM_EXYNOS_CPUFREQ
+ bool "SAMSUNG EXYNOS SoCs"
+ depends on ARCH_EXYNOS
+ select ARM_EXYNOS4210_CPUFREQ if CPU_EXYNOS4210
+ default y
+ help
+ This adds the CPUFreq driver common part for Samsung
+ EXYNOS SoCs.
+
+ If in doubt, say N.
+
config ARM_EXYNOS4210_CPUFREQ
bool "Samsung EXYNOS4210"
- depends on CPU_EXYNOS4210
- default y
help
This adds the CPUFreq driver for Samsung EXYNOS4210
SoC (S5PV310 or S5PC210).
-
- If in doubt, say N.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index a48bc02..48cfff7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o
obj-$(CONFIG_UX500_SOC_DB8500) += db8500-cpufreq.o
obj-$(CONFIG_ARM_S3C64XX_CPUFREQ) += s3c64xx-cpufreq.o
obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS_CPUFREQ) += exynos-cpufreq.o
obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ) += exynos4210-cpufreq.o
##
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
new file mode 100644
index 000..24e4dd4
--- /dev/null
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -0,0 +1,296 @@
+/*
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * EXYNOS - CPU frequency scaling support for EXYNOS series
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct exynos_dvfs_info *exynos_info;
+
+static struct regulator *arm_regulator;
+static struct cpufreq_freqs freqs;
+
+static unsigned int locking_frequency;
+static bool frequency_locked;
+static DEFINE_MUTEX(cpufreq_lock);
+
+int exynos_verify_speed(struct cpufreq_policy *policy)
+{
+ return cpufreq_frequency_table_verify(policy,
+ exynos_info->freq_table);
+}
+
+unsigned int exynos_getspeed(unsigned int cpu)
+{
+ return clk_get_rate(exynos_info->cpu_clk) / 1000;
+}
+
+static int exynos_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ unsigned int index, old_index;
[PATCH 3/5] [CPUFREQ] EXYNOS4210: cpufreq code is changed for stable working
From: Jaecheol Lee
This patch is modify code for stable working
1. Remove unused register access code
2. Change sequence for frequency changing
Signed-off-by: Jaecheol Lee
Signed-off-by: Jonghwan Choi
Signed-off-by: Jongpill Lee
Signed-off-by: Kukjin Kim
---
drivers/cpufreq/exynos4210-cpufreq.c | 101 ++
1 files changed, 65 insertions(+), 36 deletions(-)
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
index ba579e0..a0af2d4 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -36,6 +36,10 @@ static struct regulator *arm_regulator;
static struct cpufreq_freqs freqs;
+struct cpufreq_clkdiv {
+ unsigned int clkdiv;
+};
+
static unsigned int locking_frequency;
static bool frequency_locked;
static DEFINE_MUTEX(cpufreq_lock);
@@ -44,6 +48,8 @@ enum cpufreq_level_index {
L0, L1, L2, L3, L4, CPUFREQ_LEVEL_END,
};
+static struct cpufreq_clkdiv exynos4_clkdiv_table[CPUFREQ_LEVEL_END];
+
static struct cpufreq_frequency_table exynos4_freq_table[] = {
{L0, 1200*1000},
{L1, 1000*1000},
@@ -155,20 +161,7 @@ static void exynos4_set_clkdiv(unsigned int div_index)
/* Change Divider - CPU0 */
- tmp = __raw_readl(S5P_CLKDIV_CPU);
-
- tmp &= ~(S5P_CLKDIV_CPU0_CORE_MASK | S5P_CLKDIV_CPU0_COREM0_MASK |
- S5P_CLKDIV_CPU0_COREM1_MASK | S5P_CLKDIV_CPU0_PERIPH_MASK |
- S5P_CLKDIV_CPU0_ATB_MASK | S5P_CLKDIV_CPU0_PCLKDBG_MASK |
- S5P_CLKDIV_CPU0_APLL_MASK);
-
- tmp |= ((clkdiv_cpu0[div_index][0] << S5P_CLKDIV_CPU0_CORE_SHIFT) |
- (clkdiv_cpu0[div_index][1] << S5P_CLKDIV_CPU0_COREM0_SHIFT) |
- (clkdiv_cpu0[div_index][2] << S5P_CLKDIV_CPU0_COREM1_SHIFT) |
- (clkdiv_cpu0[div_index][3] << S5P_CLKDIV_CPU0_PERIPH_SHIFT) |
- (clkdiv_cpu0[div_index][4] << S5P_CLKDIV_CPU0_ATB_SHIFT) |
- (clkdiv_cpu0[div_index][5] << S5P_CLKDIV_CPU0_PCLKDBG_SHIFT) |
- (clkdiv_cpu0[div_index][6] << S5P_CLKDIV_CPU0_APLL_SHIFT));
+ tmp = exynos4_clkdiv_table[div_index].clkdiv;
__raw_writel(tmp, S5P_CLKDIV_CPU);
@@ -233,14 +226,12 @@ static void exynos4_set_frequency(unsigned int old_index,
unsigned int new_index
unsigned int tmp;
if (old_index > new_index) {
- /* The frequency changing to L0 needs to change apll */
- if (freqs.new == exynos4_freq_table[L0].frequency) {
- /* 1. Change the system clock divider values */
- exynos4_set_clkdiv(new_index);
-
- /* 2. Change the apll m,p,s value */
- exynos4_set_apll(new_index);
- } else {
+ /*
+* L1/L3, L2/L4 Level change require
+* to only change s divider value
+*/
+ if (((old_index == L3) && (new_index == L1)) ||
+ ((old_index == L4) && (new_index == L2))) {
/* 1. Change the system clock divider values */
exynos4_set_clkdiv(new_index);
@@ -249,18 +240,20 @@ static void exynos4_set_frequency(unsigned int old_index,
unsigned int new_index
tmp &= ~(0x7 << 0);
tmp |= (exynos4_apll_pms_table[new_index] & 0x7);
__raw_writel(tmp, S5P_APLL_CON0);
- }
- }
-
- else if (old_index < new_index) {
- /* The frequency changing from L0 needs to change apll */
- if (freqs.old == exynos4_freq_table[L0].frequency) {
- /* 1. Change the apll m,p,s value */
- exynos4_set_apll(new_index);
-
- /* 2. Change the system clock divider values */
- exynos4_set_clkdiv(new_index);
} else {
+ /* Clock Configuration Procedure */
+ /* 1. Change the system clock divider values */
+ exynos4_set_clkdiv(new_index);
+ /* 2. Change the apll m,p,s value */
+ exynos4_set_apll(new_index);
+ }
+ } else if (old_index < new_index) {
+ /*
+* L1/L3, L2/L4 Level change require
+* to only change s divider value
+*/
+ if (((old_index == L1) && (new_index == L3)) ||
+ ((old_index == L2) && (new_index == L4))) {
/* 1. Change just s value in apll m,p,s value */
tmp = __raw_readl(S5P_APLL_CON0);
tmp &= ~(0x7 << 0);
@@ -269,6 +262,12 @@ static void exynos4_set_frequency(unsigned int old_index,
unsigned int new_index
/* 2. Change the system clock divider values */
[PATCH 1/5] [CPUFREQ] EXYNOS4210: Remove code about bus on cpufreq
From: Jaecheol Lee
This patch removes code for bus on cpufreq because the code
for bus frequency changing moves to busfreq driver.
So code about bus on cpufreq is not necessary.
Signed-off-by: Jaecheol Lee
Signed-off-by: Jongpill Lee
Signed-off-by: Kukjin Kim
---
drivers/cpufreq/exynos4210-cpufreq.c | 174 +-
1 files changed, 1 insertions(+), 173 deletions(-)
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
index ab9741f..578956c 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -33,21 +33,13 @@ static struct clk *mout_mpll;
static struct clk *mout_apll;
static struct regulator *arm_regulator;
-static struct regulator *int_regulator;
static struct cpufreq_freqs freqs;
-static unsigned int memtype;
static unsigned int locking_frequency;
static bool frequency_locked;
static DEFINE_MUTEX(cpufreq_lock);
-enum exynos4_memory_type {
- DDR2 = 4,
- LPDDR2,
- DDR3,
-};
-
enum cpufreq_level_index {
L0, L1, L2, L3, CPUFREQ_LEVEL_END,
};
@@ -99,87 +91,24 @@ static unsigned int clkdiv_cpu1[CPUFREQ_LEVEL_END][2] = {
{ 3, 0 },
};
-static unsigned int clkdiv_dmc0[CPUFREQ_LEVEL_END][8] = {
- /*
-* Clock divider value for following
-* { DIVACP, DIVACP_PCLK, DIVDPHY, DIVDMC, DIVDMCD
-* DIVDMCP, DIVCOPY2, DIVCORE_TIMERS }
-*/
-
- /* DMC L0: 400MHz */
- { 3, 1, 1, 1, 1, 1, 3, 1 },
-
- /* DMC L1: 400MHz */
- { 3, 1, 1, 1, 1, 1, 3, 1 },
-
- /* DMC L2: 266.7MHz */
- { 7, 1, 1, 2, 1, 1, 3, 1 },
-
- /* DMC L3: 200MHz */
- { 7, 1, 1, 3, 1, 1, 3, 1 },
-};
-
-static unsigned int clkdiv_top[CPUFREQ_LEVEL_END][5] = {
- /*
-* Clock divider value for following
-* { DIVACLK200, DIVACLK100, DIVACLK160, DIVACLK133, DIVONENAND }
-*/
-
- /* ACLK200 L0: 200MHz */
- { 3, 7, 4, 5, 1 },
-
- /* ACLK200 L1: 200MHz */
- { 3, 7, 4, 5, 1 },
-
- /* ACLK200 L2: 160MHz */
- { 4, 7, 5, 7, 1 },
-
- /* ACLK200 L3: 133.3MHz */
- { 5, 7, 7, 7, 1 },
-};
-
-static unsigned int clkdiv_lr_bus[CPUFREQ_LEVEL_END][2] = {
- /*
-* Clock divider value for following
-* { DIVGDL/R, DIVGPL/R }
-*/
-
- /* ACLK_GDL/R L0: 200MHz */
- { 3, 1 },
-
- /* ACLK_GDL/R L1: 200MHz */
- { 3, 1 },
-
- /* ACLK_GDL/R L2: 160MHz */
- { 4, 1 },
-
- /* ACLK_GDL/R L3: 133.3MHz */
- { 5, 1 },
-};
-
struct cpufreq_voltage_table {
unsigned intindex; /* any */
unsigned intarm_volt; /* uV */
- unsigned intint_volt;
};
static struct cpufreq_voltage_table exynos4_volt_table[CPUFREQ_LEVEL_END] = {
{
.index = L0,
.arm_volt = 120,
- .int_volt = 110,
}, {
.index = L1,
.arm_volt = 110,
- .int_volt = 110,
}, {
.index = L2,
.arm_volt = 100,
- .int_volt = 100,
}, {
.index = L3,
.arm_volt = 90,
- .int_volt = 100,
},
};
@@ -248,80 +177,6 @@ static void exynos4_set_clkdiv(unsigned int div_index)
do {
tmp = __raw_readl(S5P_CLKDIV_STATCPU1);
} while (tmp & 0x11);
-
- /* Change Divider - DMC0 */
-
- tmp = __raw_readl(S5P_CLKDIV_DMC0);
-
- tmp &= ~(S5P_CLKDIV_DMC0_ACP_MASK | S5P_CLKDIV_DMC0_ACPPCLK_MASK |
- S5P_CLKDIV_DMC0_DPHY_MASK | S5P_CLKDIV_DMC0_DMC_MASK |
- S5P_CLKDIV_DMC0_DMCD_MASK | S5P_CLKDIV_DMC0_DMCP_MASK |
- S5P_CLKDIV_DMC0_COPY2_MASK | S5P_CLKDIV_DMC0_CORETI_MASK);
-
- tmp |= ((clkdiv_dmc0[div_index][0] << S5P_CLKDIV_DMC0_ACP_SHIFT) |
- (clkdiv_dmc0[div_index][1] << S5P_CLKDIV_DMC0_ACPPCLK_SHIFT) |
- (clkdiv_dmc0[div_index][2] << S5P_CLKDIV_DMC0_DPHY_SHIFT) |
- (clkdiv_dmc0[div_index][3] << S5P_CLKDIV_DMC0_DMC_SHIFT) |
- (clkdiv_dmc0[div_index][4] << S5P_CLKDIV_DMC0_DMCD_SHIFT) |
- (clkdiv_dmc0[div_index][5] << S5P_CLKDIV_DMC0_DMCP_SHIFT) |
- (clkdiv_dmc0[div_index][6] << S5P_CLKDIV_DMC0_COPY2_SHIFT) |
- (clkdiv_dmc0[div_index][7] << S5P_CLKDIV_DMC0_CORETI_SHIFT));
-
- __raw_writel(tmp, S5P_CLKDIV_DMC0);
-
- do {
- tmp = __raw_readl(S5P_CLKDIV_STAT_DMC0);
- } while (tmp & 0x);
-
- /* Change Divider - TOP */
-
- tmp = __raw_readl(S5P_CLKDIV_TOP);
-
- tmp &= ~(S5P_CLKDIV_TOP_ACLK200_MASK | S5P_CLKDIV_TOP_ACLK100_MASK |
- S5P_CLKDIV_TOP_ACLK160_MASK | S5P_CLKDIV_TOP_ACLK133_MASK |
- S5P_CLKDIV_TOP_ONENAND_MASK)
[PATCH 2/5] [CPUFREQ] EXYNOS4210: Update frequency table for cpu divider
From: Jaecheol Lee
This patch is changes frequency table for cpu divider for stable frequency.
Signed-off-by: Jaecheol Lee
Signed-off-by: Jongpill Lee
Signed-off-by: Kukjin Kim
---
drivers/cpufreq/exynos4210-cpufreq.c | 69 --
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c
b/drivers/cpufreq/exynos4210-cpufreq.c
index 578956c..ba579e0 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -41,14 +41,15 @@ static bool frequency_locked;
static DEFINE_MUTEX(cpufreq_lock);
enum cpufreq_level_index {
- L0, L1, L2, L3, CPUFREQ_LEVEL_END,
+ L0, L1, L2, L3, L4, CPUFREQ_LEVEL_END,
};
static struct cpufreq_frequency_table exynos4_freq_table[] = {
- {L0, 1000*1000},
- {L1, 800*1000},
- {L2, 400*1000},
- {L3, 100*1000},
+ {L0, 1200*1000},
+ {L1, 1000*1000},
+ {L2, 800*1000},
+ {L3, 500*1000},
+ {L4, 200*1000},
{0, CPUFREQ_TABLE_END},
};
@@ -59,17 +60,20 @@ static unsigned int clkdiv_cpu0[CPUFREQ_LEVEL_END][7] = {
* DIVATB, DIVPCLK_DBG, DIVAPLL }
*/
- /* ARM L0: 1000MHz */
- { 0, 3, 7, 3, 3, 0, 1 },
+ /* ARM L0: 1200MHz */
+ { 0, 3, 7, 3, 4, 1, 7 },
- /* ARM L1: 800MHz */
- { 0, 3, 7, 3, 3, 0, 1 },
+ /* ARM L1: 1000MHz */
+ { 0, 3, 7, 3, 4, 1, 7 },
- /* ARM L2: 400MHz */
- { 0, 1, 3, 1, 3, 0, 1 },
+ /* ARM L2: 800MHz */
+ { 0, 3, 7, 3, 3, 1, 7 },
- /* ARM L3: 100MHz */
- { 0, 0, 1, 0, 3, 1, 1 },
+ /* ARM L3: 500MHz */
+ { 0, 3, 7, 3, 3, 1, 7 },
+
+ /* ARM L4: 200MHz */
+ { 0, 1, 3, 1, 3, 1, 0 },
};
static unsigned int clkdiv_cpu1[CPUFREQ_LEVEL_END][2] = {
@@ -78,16 +82,19 @@ static unsigned int clkdiv_cpu1[CPUFREQ_LEVEL_END][2] = {
* { DIVCOPY, DIVHPM }
*/
-/* ARM L0: 1000MHz */
- { 3, 0 },
+ /* ARM L0: 1200MHz */
+ { 5, 0 },
+
+ /* ARM L1: 1000MHz */
+ { 4, 0 },
- /* ARM L1: 800MHz */
+ /* ARM L2: 800MHz */
{ 3, 0 },
- /* ARM L2: 400MHz */
+ /* ARM L3: 500MHz */
{ 3, 0 },
- /* ARM L3: 100MHz */
+ /* ARM L4: 200MHz */
{ 3, 0 },
};
@@ -99,31 +106,37 @@ struct cpufreq_voltage_table {
static struct cpufreq_voltage_table exynos4_volt_table[CPUFREQ_LEVEL_END] = {
{
.index = L0,
- .arm_volt = 120,
+ .arm_volt = 135,
}, {
.index = L1,
- .arm_volt = 110,
+ .arm_volt = 130,
}, {
.index = L2,
- .arm_volt = 100,
+ .arm_volt = 120,
}, {
.index = L3,
- .arm_volt = 90,
+ .arm_volt = 110,
+ }, {
+ .index = L4,
+ .arm_volt = 105,
},
};
static unsigned int exynos4_apll_pms_table[CPUFREQ_LEVEL_END] = {
- /* APLL FOUT L0: 1000MHz */
+ /* APLL FOUT L0: 1200MHz */
+ ((150 << 16) | (3 << 8) | 1),
+
+ /* APLL FOUT L1: 1000MHz */
((250 << 16) | (6 << 8) | 1),
- /* APLL FOUT L1: 800MHz */
+ /* APLL FOUT L2: 800MHz */
((200 << 16) | (6 << 8) | 1),
- /* APLL FOUT L2 : 400MHz */
- ((200 << 16) | (6 << 8) | 2),
+ /* APLL FOUT L3: 500MHz */
+ ((250 << 16) | (6 << 8) | 2),
- /* APLL FOUT L3: 100MHz */
- ((200 << 16) | (6 << 8) | 4),
+ /* APLL FOUT L4: 200MHz */
+ ((200 << 16) | (6 << 8) | 3),
};
static int exynos4_verify_speed(struct cpufreq_policy *policy)
--
1.7.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
[PATCH v2] s3c24xx: cpufreq: Fix compilation error when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS selected.
Fix compilation error when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS selected.
Signed-off-by: Denis Kuzmenko
---
Patch is against 3.2-rc4.
CONFIG_S3C2410_IOTIMING is not selected for MACH_MINI2440. Because of this the
file s3c2410-iotiming.c is not ever compiled and enabling
CONFIG_CPU_FREQ_S3C24XX_DEBUGFS option caused undefined reference to function
s3c2410_iotiming_debugfs defined in that file. s3c2410_iotiming_debugfs defined
as NULL for this case.
Changelog:
v1 -> v2
New CONFIG_ symbols S3C241{0,2}_IOTIMING were removed as It was observed that
they already present but hidden from user.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e084b7e..133d005 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2118,7 +2118,7 @@ config CPU_FREQ_S3C24XX_DEBUG
config CPU_FREQ_S3C24XX_IODEBUG
bool "Debug CPUfreq Samsung driver IO timing"
- depends on CPU_FREQ_S3C24XX
+ depends on CPU_FREQ_S3C24XX && (S3C2410_IOTIMING || S3C2412_IOTIMING)
help
Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
diff --git a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
index dac4760..c465252 100644
--- a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
+++ b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h
@@ -202,13 +202,23 @@ extern int s3c_plltab_register(struct
cpufreq_frequency_table *plls,
extern struct s3c_cpufreq_config *s3c_cpufreq_getconfig(void);
extern struct s3c_iotimings *s3c_cpufreq_getiotimings(void);
-extern void s3c2410_iotiming_debugfs(struct seq_file *seq,
-struct s3c_cpufreq_config *cfg,
-union s3c_iobank *iob);
-
-extern void s3c2412_iotiming_debugfs(struct seq_file *seq,
-struct s3c_cpufreq_config *cfg,
-union s3c_iobank *iob);
+#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
+ #ifdef CONFIG_S3C2410_IOTIMING
+ extern void s3c2410_iotiming_debugfs(struct seq_file *seq,
+struct s3c_cpufreq_config *cfg,
+union s3c_iobank *iob);
+ #else
+ #define s3c2410_iotiming_debugfsNULL
+ #endif
+
+ #ifdef CONFIG_S3C2412_IOTIMING
+ extern void s3c2412_iotiming_debugfs(struct seq_file *seq,
+struct s3c_cpufreq_config *cfg,
+union s3c_iobank *iob);
+ #else
+ #define s3c2412_iotiming_debugfsNULL
+ #endif
+#endif
#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUGFS
#define s3c_cpufreq_debugfs_call(x) x
@@ -241,10 +251,7 @@ extern void s3c2410_iotiming_set(struct s3c_cpufreq_config
*cfg,
#endif /* CONFIG_S3C2410_IOTIMING */
/* S3C2412 compatible routines */
-
-extern int s3c2412_iotiming_get(struct s3c_cpufreq_config *cfg,
- struct s3c_iotimings *timings);
-
+#ifdef CONFIG_S3C2412_IOTIMING
extern int s3c2412_iotiming_get(struct s3c_cpufreq_config *cfg,
struct s3c_iotimings *timings);
@@ -253,6 +260,11 @@ extern int s3c2412_iotiming_calc(struct s3c_cpufreq_config
*cfg,
extern void s3c2412_iotiming_set(struct s3c_cpufreq_config *cfg,
struct s3c_iotimings *iot);
+#else
+#define s3c2412_iotiming_calc NULL
+#define s3c2412_iotiming_get NULL
+#define s3c2412_iotiming_set NULL
+#endif
#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUG
#define s3c_freq_dbg(x...) printk(KERN_INFO x)
--
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 resend2] s3c24xx: cpufreq: Fix compilation error when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS selected.
On 12/06/2011 01:31 PM, Kukjin Kim wrote: > Denis Kuzmenko wrote: >> >> Fix compilation error when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS selected. >> >> Signed-off-by: Denis Kuzmenko >> --- >> >> Patch is against 3.2-rc3. >> CONFIG_S3C2410_IOTIMING wasn't present in Kconfig but was referenced by >> Makefile. Because of this the file s3c2410-iotiming.c was not ever >> compiled > > Well, there is 'S3C2410_IOTIMING' at arch/arm/plat-s3c24xx/Kconfig and it > had dependency of 'CONFIG_CPU_FREQ_S3C24XX'... > Yeah, I've missed that, thank you. I'll make a new version. -- Best regards, Denis Kuzmenko. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM: Provide an always on power domain governor
On Tuesday, December 06, 2011, Kukjin Kim wrote: > Mark Brown wrote: > > > > On Mon, Dec 05, 2011 at 01:15:18AM +0100, Rafael J. Wysocki wrote: > > > On Monday, December 05, 2011, Mark Brown wrote: > > > > > > It might make sense for it to go via the Samsung tree - the third > > patch > > > > depends on it and there's some other stuff going on with the s3c64xx > > > > power management - so let's see what Kukjin thinks is best. > > > > > OTOH, it will conflict with some patches I have in the works. > > > > Ah, OK - in that case I guess it's sensible if you apply it. Ideally it > > could be on a separate branch so it could be cross-merged with other > > trees if there's a need later. > > Hi Mark and Rafael, > > Looks ok to me on this series and would be nice to me if Rafael could create > topic branch in his tree and apply this series with my ack for Samsung > stuff. > > Rafael, please let me know the branch when you create it so that I can merge > it into Samsung tree to avoid other conflicts. I need an ack from Magnus or Paul on the shmobile patch. When I get one, I'll put patches [1/3] and [2/3] (new version) into my linux-next branch and then (after a few days spent in linux-next) to the pm-domains branch. I'll let you know when that happens. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Mon, Dec 05, 2011 at 04:47:15PM +0100, Joerg Roedel wrote: > Okay, I merged it into arm/exynos, but it is not pushed yet. Actually > there were conflicts while merging, which I resolved. What I failed > to find is a config for Exynos that actually builds for upstream Linux. > Probably I havn't tried hard enough to find one... Can you provide a > kernel config that I can use for my testing and that builds a current > 3.2-rc4 kernel for Exynos? Okay, since there are new objections and since I can't even reliably build test the driver I unmerged it again. Please fix the outstanding issues and rebase it against a recent upstream kernel so that the result can be compiled to a kernel-image. Thanks, Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] PM: Provide an always on power domain governor
On Tue, Dec 06, 2011 at 01:04:53PM +0100, Marek Szyprowski wrote: Please fix your mailer to word wrap at less than 80 columns, I've reflowed your text for legibility. > What about similar patches for S5PV210/S5PC110 series and Exynos4? I don't really have access to these systems (well, I have a Nexus S I can use but that doesn't boot mainline) and I don't have datasheets so it's hard for me to actively work on them myself. > gen_pd based power domain code for Exynos4 have been rejected in favor > of custom platform-device based power domain drivers. It would be much Oh, that's very surprising to me - looking at the code it appeared that it just predated gen_pd, I didn't see anything in there that suggested an active decision to avoid using it. What was then thinking there? Is this something we can fix by enhancing gen_pd? > easier to have only one type of the drivers across different Samsung > SoCs. This will also help to hide some differences between the series > from the device drivers (clock gating, power management). When I looked at the code I'd expected the other SoCs to also transition over to gen_pd and then start pulling things out from there. Looking at what you can do on s3c64xx the power domain code looked very small once you use the gen_pd stuff (which is very nice to use, it really makes the whole thing very easy) so I'm not sure how much win it is immediately. How much win it is long term will depend on where things get implemented - a lot of the stuff I could tink of doing seemed like it might be more of a fit for the opp or PM QoS stuff than for the power domains, with the power domains staying pretty thin and just providing inputs but perhaps that's not a sensible approach. The main trick is going to be actually putting the devices into the power domains which is entertaining as currently every board directly registers platform devices so it's hard for core code to work out what Linux knows about. In terms of the drivers I wasn't expecting to see much impact as the power domain and runtime PM APIs provide a pretty good abstraction already - the actual implementation of things is totally transparent to them. The only device actively able to use the power domains on the S3C6410 is the framebuffer and the driver there just worked with the existing runtime PM code. -- 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 v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
Hello,
On Tuesday, December 06, 2011 1:21 PM KyongHo Cho wrote:
> On Tue, Dec 6, 2011 at 8:48 PM, Marek Szyprowski
> wrote:
> > Hello,
> >
> > I'm trying to integrate your SYSMMU driver with my DMA-mapping & IOMMU
> > API integration patches. I've noticed some issues, please see my comments
> > below.
> >
> Thank you!
>
> > On Friday, November 18, 2011 10:48 AM KyongHo Cho wrote:
> >
> >> +
> >> +static int exynos_sysmmu_probe(struct platform_device *pdev)
> >> +{
> >> + struct resource *res, *ioarea;
> >> + int ret;
> >> + int irq;
> >> + struct device *dev;
> >> + void *sfr;
> >> + struct sysmmu_drvdata *data;
> >> + char *emsg;
> >> +
> >> + dev = &pdev->dev;
> >> +
> >> + if (dev_get_platdata(dev) == NULL) {
> >> + pr_debug("%s: No System MMU is assigned for %s.%d.\n",
> >> __func__,
> >> + pdev->name, pdev->id);
> >> + return -ENODEV;
> >> + }
> >> +
> >> + data = kzalloc(sizeof(*data), GFP_KERNEL);
> >> + if (!data) {
> >> + emsg = "Not enough memory";
> >> + ret = -ENOMEM;
> >> + goto err_alloc;
> >> + }
> >> +
> >> + data->owner = dev_get_platdata(dev);
> >> +
> >> + ret = dev_set_drvdata(dev, data);
> >> + if (ret) {
> >> + emsg = "Unable to set driver data.";
> >> + goto err_init;
> >> + }
> >> +
> >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> + if (!res) {
> >> + emsg = "Failed probing system MMU: failed to get resource.";
> >> + goto err_init;
> >> + }
> >> +
> >> + ioarea = request_mem_region(res->start, resource_size(res),
> >> +
> >> dev_name(dev));
> >> + if (ioarea == NULL) {
> >> + emsg = "failed to request memory region.";
> >> + ret = -ENOMEM;
> >> + goto err_init;
> >> + }
> >> +
> >> + sfr = ioremap(res->start, resource_size(res));
> >> + if (!sfr) {
> >> + emsg = "failed to call ioremap().";
> >> + ret = -ENOENT;
> >> + goto err_ioremap;
> >> + }
> >> +
> >> + irq = platform_get_irq(pdev, 0);
> >> + if (irq <= 0) {
> >> + emsg = "failed to get irq resource.";
> >> + ret = irq;
> >> + goto err_irq;
> >> + }
> >> +
> >> + ret = request_irq(irq, exynos_sysmmu_irq, 0, dev_name(dev), data);
> >> + if (ret) {
> >> + emsg = "failed to request irq.";
> >> + goto err_irq;
> >> + }
> >> +
> >> + data->clk = clk_get(dev, "sysmmu");
> >> + if (IS_ERR(data->clk)) {
> >> + emsg = "failed to get clock descriptor";
> >> + ret = PTR_ERR(data->clk);
> >> + goto err_clk;
> >> + }
> >> +
> >> + data->dev = dev;
> >> + data->sfrbase = sfr;
> >> + __set_fault_handler(data, &default_fault_handler);
> >> + rwlock_init(&data->lock);
> >
> > Here is a serious problem: __set_fault_handler takes data->lock which is
> > initialized after
> calling
> > this function.
> >
>
> Yeah, you're right. Thank you. I didn't notice it.
> I will fix it.
>
> >> +
> >> +static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long
> >> iova,
> >> + short *pgcounter)
> >> +{
> >> + if (lv1ent_fault(sent)) {
> >> + unsigned long *pent;
> >> +
> >> + pent = kzalloc(1024, GFP_KERNEL);
> >
> > I would use GFP_ATOMIC here. iommu_map() function might be called in atomic
> > context, and
> > GFP_KERNEL here causes kernel ops/warning.
>
> I wanted to avoid to allocate memory from emergency pool.
> Do you think that it needs to allocate memory with GFP_ATOMIC flag?
Otherwise it will very hard to get it integrated with DMA mapping framework.
GFP_ATOMIC
memory is allocated straight from system free lists, which are refilled on the
next
non-atomic allocation if the watermark level is low enough.
It will be best if iommu_map() can be extended with allocation flags argument,
so the
caller can decide if iommu driver can use GFP_ATOMIC or GFP_KERNEL depending on
the context.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] spi/s3c64xx: Implement runtime PM support
On Tue, Dec 6, 2011 at 12:16 AM, Mark Brown wrote: > I do also think that if we do decide to move more platforms to central > management it's going to be easier to first transition all their drivers > to a repetitive style of clock management and then do a big factor out > once the pattern is clearly visible. I agree with this. I will go forward in the same manner with Ux500 for the time being. Thanks, 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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Tue, Dec 06, 2011 at 09:13:18PM +0900, KyongHo Cho wrote: > > BTW, how do you test it at mainline kernel? > > > I merged IOMMU mainline branch to our kernel branch and tested it with > our FIMC, MFC, JPEG, 2D. This is not sufficient. Please do it the other way around, merge your outstanding changes into the mainline kernel (or for iommu topics my next branch) and test against that. This way it is easier to catch bugs in mainline. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- 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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Tue, Dec 6, 2011 at 9:13 PM, KyongHo Cho wrote: > On Tue, Dec 6, 2011 at 8:24 AM, Kyungmin Park wrote: >> On 12/6/11, Joerg Roedel wrote: >>> On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: Patch Summary: [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms >>> >>> Okay, I merged it into arm/exynos, but it is not pushed yet. Actually >>> there were conflicts while merging, which I resolved. What I failed >>> to find is a config for Exynos that actually builds for upstream Linux. >>> Probably I havn't tried hard enough to find one... Can you provide a >>> kernel config that I can use for my testing and that builds a current >>> 3.2-rc4 kernel for Exynos? >> and I hope to see the real example how to use it with exynos platform. >> >> Now I can't find the interface between exynos platform and generic exynos >> iommu. > In "[PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device > definitions" patch, > you can find sysmmu_init(). > It stores associations between a system MMU and a peripheral device in > platform data of platform device descriptor. > If Exynos IOMMU driver finds the association while probing, then the > driver can control the system MMU. Maybe it's still call the function directly instead of using struct dev field as OMAP did. Even though generic DMA mapping IOMMU doesn't used, you can connect the iommu field at arch/arm/include/asm/device.h BR, Kyungmin Park > >> BTW, how do you test it at mainline kernel? >> > I merged IOMMU mainline branch to our kernel branch and tested it with > our FIMC, MFC, JPEG, 2D. -- 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 v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
On Tue, Dec 6, 2011 at 8:48 PM, Marek Szyprowski
wrote:
> Hello,
>
> I'm trying to integrate your SYSMMU driver with my DMA-mapping & IOMMU
> API integration patches. I've noticed some issues, please see my comments
> below.
>
Thank you!
> On Friday, November 18, 2011 10:48 AM KyongHo Cho wrote:
>
>> +
>> +static int exynos_sysmmu_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res, *ioarea;
>> + int ret;
>> + int irq;
>> + struct device *dev;
>> + void *sfr;
>> + struct sysmmu_drvdata *data;
>> + char *emsg;
>> +
>> + dev = &pdev->dev;
>> +
>> + if (dev_get_platdata(dev) == NULL) {
>> + pr_debug("%s: No System MMU is assigned for %s.%d.\n",
>> __func__,
>> + pdev->name, pdev->id);
>> + return -ENODEV;
>> + }
>> +
>> + data = kzalloc(sizeof(*data), GFP_KERNEL);
>> + if (!data) {
>> + emsg = "Not enough memory";
>> + ret = -ENOMEM;
>> + goto err_alloc;
>> + }
>> +
>> + data->owner = dev_get_platdata(dev);
>> +
>> + ret = dev_set_drvdata(dev, data);
>> + if (ret) {
>> + emsg = "Unable to set driver data.";
>> + goto err_init;
>> + }
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + emsg = "Failed probing system MMU: failed to get resource.";
>> + goto err_init;
>> + }
>> +
>> + ioarea = request_mem_region(res->start, resource_size(res),
>> + dev_name(dev));
>> + if (ioarea == NULL) {
>> + emsg = "failed to request memory region.";
>> + ret = -ENOMEM;
>> + goto err_init;
>> + }
>> +
>> + sfr = ioremap(res->start, resource_size(res));
>> + if (!sfr) {
>> + emsg = "failed to call ioremap().";
>> + ret = -ENOENT;
>> + goto err_ioremap;
>> + }
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq <= 0) {
>> + emsg = "failed to get irq resource.";
>> + ret = irq;
>> + goto err_irq;
>> + }
>> +
>> + ret = request_irq(irq, exynos_sysmmu_irq, 0, dev_name(dev), data);
>> + if (ret) {
>> + emsg = "failed to request irq.";
>> + goto err_irq;
>> + }
>> +
>> + data->clk = clk_get(dev, "sysmmu");
>> + if (IS_ERR(data->clk)) {
>> + emsg = "failed to get clock descriptor";
>> + ret = PTR_ERR(data->clk);
>> + goto err_clk;
>> + }
>> +
>> + data->dev = dev;
>> + data->sfrbase = sfr;
>> + __set_fault_handler(data, &default_fault_handler);
>> + rwlock_init(&data->lock);
>
> Here is a serious problem: __set_fault_handler takes data->lock which is
> initialized after calling
> this function.
>
Yeah, you're right. Thank you. I didn't notice it.
I will fix it.
>> +
>> +static unsigned long *alloc_lv2entry(unsigned long *sent, unsigned long
>> iova,
>> + short *pgcounter)
>> +{
>> + if (lv1ent_fault(sent)) {
>> + unsigned long *pent;
>> +
>> + pent = kzalloc(1024, GFP_KERNEL);
>
> I would use GFP_ATOMIC here. iommu_map() function might be called in atomic
> context, and
> GFP_KERNEL here causes kernel ops/warning.
>
I wanted to avoid to allocate memory from emergency pool.
Do you think that it needs to allocate memory with GFP_ATOMIC flag?
Thanks.
KyongHo.
--
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 v7 0/2] iommu/exynos: Add IOMMU/System MMU driver for Samsung Exynos
On Tue, Dec 6, 2011 at 8:24 AM, Kyungmin Park wrote: > On 12/6/11, Joerg Roedel wrote: >> On Fri, Nov 18, 2011 at 06:47:28PM +0900, KyongHo Cho wrote: >>> Patch Summary: >>> [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions >>> [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms >> >> Okay, I merged it into arm/exynos, but it is not pushed yet. Actually >> there were conflicts while merging, which I resolved. What I failed >> to find is a config for Exynos that actually builds for upstream Linux. >> Probably I havn't tried hard enough to find one... Can you provide a >> kernel config that I can use for my testing and that builds a current >> 3.2-rc4 kernel for Exynos? > and I hope to see the real example how to use it with exynos platform. > > Now I can't find the interface between exynos platform and generic exynos > iommu. In "[PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions" patch, you can find sysmmu_init(). It stores associations between a system MMU and a peripheral device in platform data of platform device descriptor. If Exynos IOMMU driver finds the association while probing, then the driver can control the system MMU. > BTW, how do you test it at mainline kernel? > I merged IOMMU mainline branch to our kernel branch and tested it with our FIMC, MFC, JPEG, 2D. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] PM: Provide an always on power domain governor
Hello, On Tuesday, December 06, 2011 11:20 AM Kukjin Kim wrote: > Mark Brown wrote: > > > > On Mon, Dec 05, 2011 at 01:15:18AM +0100, Rafael J. Wysocki wrote: > > > On Monday, December 05, 2011, Mark Brown wrote: > > > > > > It might make sense for it to go via the Samsung tree - the third > > patch > > > > depends on it and there's some other stuff going on with the s3c64xx > > > > power management - so let's see what Kukjin thinks is best. > > > > > OTOH, it will conflict with some patches I have in the works. > > > > Ah, OK - in that case I guess it's sensible if you apply it. Ideally it > > could be on a separate branch so it could be cross-merged with other > > trees if there's a need later. > > Hi Mark and Rafael, > > Looks ok to me on this series and would be nice to me if Rafael could create > topic branch in his tree and apply this series with my ack for Samsung > stuff. > > Rafael, please let me know the branch when you create it so that I can merge > it into Samsung tree to avoid other conflicts. What about similar patches for S5PV210/S5PC110 series and Exynos4? gen_pd based power domain code for Exynos4 have been rejected in favor of custom platform-device based power domain drivers. It would be much easier to have only one type of the drivers across different Samsung SoCs. This will also help to hide some differences between the series from the device drivers (clock gating, power management). Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 1/2] ARM: EXYNOS: Change System MMU platform device definitions
Hello, On Friday, November 18, 2011 10:47 AM KyongHo Cho wrote: > Handling System MMUs with an identifier is not flexible to manage > System MMU platform devices because of the following reasons: > 1. A device driver which needs to handle System MMU must know the ID. > 2. A System MMU may not present in some implementations of Exynos family. > 3. Handling System MMU with IOMMU API does not require an ID. > > This patch is the result of removing ID of System MMUs. > Instead, a device driver that needs to handle its System MMU must > use IOMMU API while its descriptor of platform device is given. > > This patch also includes the following enhanclements: > - A System MMU device becomes a child if its power domain device. > - clkdev > > Signed-off-by: KyongHo Cho > --- > arch/arm/mach-exynos/Kconfig |2 + > arch/arm/mach-exynos/clock-exynos4210.c | 16 ++ > arch/arm/mach-exynos/clock.c | 55 ++-- > arch/arm/mach-exynos/dev-sysmmu.c | 272 > + > arch/arm/mach-exynos/include/mach/dev-sysmmu.h| 61 + > arch/arm/mach-exynos/include/mach/exynos4-clock.h |1 + > arch/arm/mach-exynos/include/mach/map.h |3 +- > arch/arm/mach-exynos/include/mach/regs-sysmmu.h | 26 +- > arch/arm/mach-exynos/include/mach/sysmmu.h| 46 > arch/arm/mach-exynos/mach-armlex4210.c|1 - > arch/arm/mach-exynos/mach-nuri.c | 40 +++ > arch/arm/mach-exynos/mach-origen.c| 42 > arch/arm/mach-exynos/mach-smdk4x12.c |9 + > arch/arm/mach-exynos/mach-smdkv310.c | 43 - > arch/arm/mach-exynos/mach-universal_c210.c| 42 > arch/arm/plat-samsung/include/plat/devs.h |1 - > 16 files changed, 356 insertions(+), 304 deletions(-) > create mode 100644 arch/arm/mach-exynos/include/mach/dev-sysmmu.h > delete mode 100644 arch/arm/mach-exynos/include/mach/sysmmu.h > > diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig > index 0afcc3b..67769fb 100644 > --- a/arch/arm/mach-exynos/Kconfig > +++ b/arch/arm/mach-exynos/Kconfig > @@ -272,6 +272,7 @@ config MACH_NURI > select EXYNOS4_SETUP_I2C5 > select EXYNOS4_SETUP_SDHCI > select EXYNOS4_SETUP_USB_PHY > + select EXYNOS4_DEV_SYSMMU > select S5P_SETUP_MIPIPHY > select SAMSUNG_DEV_PWM > select SAMSUNG_DEV_ADC > @@ -301,6 +302,7 @@ config MACH_ORIGEN > select EXYNOS4_SETUP_FIMD0 > select EXYNOS4_SETUP_SDHCI > select EXYNOS4_SETUP_USB_PHY > + select EXYNOS4_DEV_SYSMMU The "select EXYNOS4_DEV_SYSMMU" statement is missing for UniversalC210 and SMDK boards what causes compilation issues if only these boards are selected. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v7 2/2] iommu/exynos: Add iommu driver for Exynos Platforms
Hello,
I'm trying to integrate your SYSMMU driver with my DMA-mapping & IOMMU
API integration patches. I've noticed some issues, please see my comments below.
On Friday, November 18, 2011 10:48 AM KyongHo Cho wrote:
> This is the System MMU driver and IOMMU API implementation for
> Exynos SOC platforms. Exynos platforms has more than 10 System
> MMUs dedicated for each multimedia accellerators.
>
> The System MMU driver is already in arc/arm/plat-s5p but it is
> moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU drivers
> there
>
> This patch also includes fault handling feature in IOMMU driver
> suggested by Ohad.
> Users of IOMMU API can register its own fault handler with
> iommu_set_fault_handler() and the handler is called by IRQ handler
> of System MMU.
> If no user installs fault handler, IOMMU driver prints debugging
> message and generates kernel oops.
>
> This IOMMU driver calls bus_set_iommu() instead of register_iommu()
> since Joerg suggested that installing iommu_ops in bus_type.
>
> Cc: Joerg Roedel
> Cc: Ohad Ben-Cohen
> Cc: Sylwester Nawrocki
> Cc: Russell King
> Signed-off-by: KyongHo Cho
> ---
> arch/arm/plat-s5p/Kconfig |8 -
> arch/arm/plat-s5p/Makefile |1 -
> arch/arm/plat-s5p/sysmmu.c | 312 -
> arch/arm/plat-samsung/include/plat/sysmmu.h | 95 ---
> drivers/iommu/Kconfig | 12 +
> drivers/iommu/Makefile |1 +
> drivers/iommu/exynos-iommu.c| 958
> +++
> 7 files changed, 971 insertions(+), 416 deletions(-)
> delete mode 100644 arch/arm/plat-s5p/sysmmu.c
> delete mode 100644 arch/arm/plat-samsung/include/plat/sysmmu.h
> create mode 100644 drivers/iommu/exynos-iommu.c
>
> diff --git a/arch/arm/plat-s5p/Kconfig b/arch/arm/plat-s5p/Kconfig
> index 9b9968f..805b979 100644
> --- a/arch/arm/plat-s5p/Kconfig
> +++ b/arch/arm/plat-s5p/Kconfig
> @@ -45,14 +45,6 @@ config S5P_PM
> Common code for power management support on S5P and newer SoCs
> Note: Do not select this for S5P6440 and S5P6450.
>
> -comment "System MMU"
> -
> -config S5P_SYSTEM_MMU
> - bool "S5P SYSTEM MMU"
> - depends on ARCH_EXYNOS4
> - help
> - Say Y here if you want to enable System MMU
> -
> config S5P_SLEEP
> bool
> help
> diff --git a/arch/arm/plat-s5p/Makefile b/arch/arm/plat-s5p/Makefile
> index 8763440..0757ce0 100644
> --- a/arch/arm/plat-s5p/Makefile
> +++ b/arch/arm/plat-s5p/Makefile
> @@ -18,7 +18,6 @@ obj-y += clock.o
> obj-y+= irq.o
> obj-$(CONFIG_S5P_EXT_INT)+= irq-eint.o
> obj-$(CONFIG_S5P_GPIO_INT) += irq-gpioint.o
> -obj-$(CONFIG_S5P_SYSTEM_MMU) += sysmmu.o
> obj-$(CONFIG_S5P_PM) += pm.o irq-pm.o
> obj-$(CONFIG_S5P_SLEEP) += sleep.o
> obj-$(CONFIG_S5P_HRT)+= s5p-time.o
> diff --git a/arch/arm/plat-s5p/sysmmu.c b/arch/arm/plat-s5p/sysmmu.c
> deleted file mode 100644
> index e1cbc72..000
> --- a/arch/arm/plat-s5p/sysmmu.c
> +++ /dev/null
> @@ -1,312 +0,0 @@
> -/* linux/arch/arm/plat-s5p/sysmmu.c
> - *
> - * Copyright (c) 2010 Samsung Electronics Co., Ltd.
> - * http://www.samsung.com
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#include
> -#include
> -#include
> -
> -#define CTRL_ENABLE 0x5
> -#define CTRL_BLOCK 0x7
> -#define CTRL_DISABLE 0x0
> -
> -static struct device *dev;
> -
> -static unsigned short fault_reg_offset[SYSMMU_FAULTS_NUM] = {
> - S5P_PAGE_FAULT_ADDR,
> - S5P_AR_FAULT_ADDR,
> - S5P_AW_FAULT_ADDR,
> - S5P_DEFAULT_SLAVE_ADDR,
> - S5P_AR_FAULT_ADDR,
> - S5P_AR_FAULT_ADDR,
> - S5P_AW_FAULT_ADDR,
> - S5P_AW_FAULT_ADDR
> -};
> -
> -static char *sysmmu_fault_name[SYSMMU_FAULTS_NUM] = {
> - "PAGE FAULT",
> - "AR MULTI-HIT FAULT",
> - "AW MULTI-HIT FAULT",
> - "BUS ERROR",
> - "AR SECURITY PROTECTION FAULT",
> - "AR ACCESS PROTECTION FAULT",
> - "AW SECURITY PROTECTION FAULT",
> - "AW ACCESS PROTECTION FAULT"
> -};
> -
> -static int (*fault_handlers[S5P_SYSMMU_TOTAL_IPNUM])(
> - enum S5P_SYSMMU_INTERRUPT_TYPE itype,
> - unsigned long pgtable_base,
> - unsigned long fault_addr);
> -
> -/*
> - * If adjacent 2 bits are true, the system MMU is enabled.
> - * The system MMU is disabled, otherwise.
> - */
> -static unsigned long sysmmu_states;
> -
> -static inline void set_sysmmu_active(sysmmu_ips ips)
> -{
> - sysmmu_states |= 3 << (ips * 2);
> -}
> -
> -static inline void set_sysmmu_inactive(sysmmu_ips ips)
> -{
> - sysmmu_states &= ~(3 << (ips * 2));
> -}
> -
> -static inline int is_sysmmu_active(sysmmu_ips ips
RE: [PATCH resend3] arm: s3c24xx: Add new LCD (W35i) support for Mini2440 board
Denis Kuzmenko wrote:
>
> Add new LCD (W35i) support for Mini2440 board
>
> Signed-off-by: Denis Kuzmenko
> ---
>
> diff --git a/arch/arm/mach-s3c2440/mach-mini2440.c
> b/arch/arm/mach-s3c2440/mach-mini2440.c
> index fc2dc0b..951eadd 100644
> --- a/arch/arm/mach-s3c2440/mach-mini2440.c
> +++ b/arch/arm/mach-s3c2440/mach-mini2440.c
> @@ -167,6 +167,24 @@ static struct s3c2410fb_display mini2440_lcd_cfg[]
> __initdata = {
> .lcdcon5= (S3C2410_LCDCON5_FRM565 |
> S3C2410_LCDCON5_HWSWP),
> },
> + /* mini2440 + 3.5" TFT (LCD-W35i, LQ035Q1DG06 type) + touchscreen*/
> + [3] = {
> + _LCD_DECLARE(
> + /* clock */
> + 7,
> + /* xres, margin_right, margin_left, hsync */
> + 320, 68, 66, 4,
> + /* yres, margin_top, margin_bottom, vsync */
> + 240, 4, 4, 9,
> + /* refresh rate */
> + 60),
> + .lcdcon5= (S3C2410_LCDCON5_FRM565 |
> +S3C2410_LCDCON5_INVVDEN |
> +S3C2410_LCDCON5_INVVFRAME |
> +S3C2410_LCDCON5_INVVLINE |
> +S3C2410_LCDCON5_INVVCLK |
> +S3C2410_LCDCON5_HWSWP),
> + },
> };
> /* todo - put into gpio header */
Looks ok, will apply.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 resend2] s3c24xx: cpufreq: Fix compilation error when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS selected.
Denis Kuzmenko wrote: > > Fix compilation error when CONFIG_CPU_FREQ_S3C24XX_DEBUGFS selected. > > Signed-off-by: Denis Kuzmenko > --- > > Patch is against 3.2-rc3. > CONFIG_S3C2410_IOTIMING wasn't present in Kconfig but was referenced by > Makefile. Because of this the file s3c2410-iotiming.c was not ever > compiled Well, there is 'S3C2410_IOTIMING' at arch/arm/plat-s3c24xx/Kconfig and it had dependency of 'CONFIG_CPU_FREQ_S3C24XX'... Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > and enabling CONFIG_CPU_FREQ_S3C24XX_DEBUGFS option caused undefined > reference to function s3c2410_iotiming_debugfs defined in that file. > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 44789ef..81d7025 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -2104,9 +2104,31 @@ config CPU_FREQ_S3C24XX_DEBUG > help > Enable s3c_freq_dbg for the Samsung S3C CPUfreq core > +config S3C2410_IOTIMING > + bool "CPUfreq iotiming for Samsung S3C2410 series CPUs" > + depends on ARCH_S3C2410 && CPU_FREQ && CPU_FREQ_S3C24XX && > EXPERIMENTAL > + help > + This enables the CPUfreq driver for the Samsung S3C24XX to change > + IO timing according to the CPU frequency. > + > + For details, take a look at . > + > + If in doubt, say Y. > + > +config S3C2412_IOTIMING > + bool "CPUfreq iotiming for Samsung S3C2412 series CPUs" > + depends on ARCH_S3C2412 && CPU_FREQ && CPU_FREQ_S3C24XX && > EXPERIMENTAL > + help > + This enables the CPUfreq driver for the Samsung S3C2412 to change > + IO timing according to the CPU frequency. > + > + For details, take a look at . > + > + If in doubt, say Y. > + > config CPU_FREQ_S3C24XX_IODEBUG > bool "Debug CPUfreq Samsung driver IO timing" > - depends on CPU_FREQ_S3C24XX > + depends on CPU_FREQ_S3C24XX && (S3C2410_IOTIMING || > S3C2412_IOTIMING) > help > Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core > diff --git a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h > b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h > index dac4760..c465252 100644 > --- a/arch/arm/plat-samsung/include/plat/cpu-freq-core.h > +++ b/arch/arm/plat-samsung/include/plat/cpu-freq-core.h > @@ -202,13 +202,23 @@ extern int s3c_plltab_register(struct > cpufreq_frequency_table *plls, > extern struct s3c_cpufreq_config *s3c_cpufreq_getconfig(void); > extern struct s3c_iotimings *s3c_cpufreq_getiotimings(void); > -extern void s3c2410_iotiming_debugfs(struct seq_file *seq, > - struct s3c_cpufreq_config *cfg, > - union s3c_iobank *iob); > - > -extern void s3c2412_iotiming_debugfs(struct seq_file *seq, > - struct s3c_cpufreq_config *cfg, > - union s3c_iobank *iob); > +#ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUGFS > + #ifdef CONFIG_S3C2410_IOTIMING > + extern void s3c2410_iotiming_debugfs(struct seq_file *seq, > + struct s3c_cpufreq_config *cfg, > + union s3c_iobank *iob); > + #else > + #define s3c2410_iotiming_debugfsNULL > + #endif > + > + #ifdef CONFIG_S3C2412_IOTIMING > + extern void s3c2412_iotiming_debugfs(struct seq_file *seq, > + struct s3c_cpufreq_config *cfg, > + union s3c_iobank *iob); > + #else > + #define s3c2412_iotiming_debugfsNULL > + #endif > +#endif > #ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUGFS > #define s3c_cpufreq_debugfs_call(x) x > @@ -241,10 +251,7 @@ extern void s3c2410_iotiming_set(struct > s3c_cpufreq_config *cfg, > #endif /* CONFIG_S3C2410_IOTIMING */ > /* S3C2412 compatible routines */ > - > -extern int s3c2412_iotiming_get(struct s3c_cpufreq_config *cfg, > - struct s3c_iotimings *timings); > - > +#ifdef CONFIG_S3C2412_IOTIMING > extern int s3c2412_iotiming_get(struct s3c_cpufreq_config *cfg, > struct s3c_iotimings *timings); > @@ -253,6 +260,11 @@ extern int s3c2412_iotiming_calc(struct > s3c_cpufreq_config *cfg, > extern void s3c2412_iotiming_set(struct s3c_cpufreq_config *cfg, >struct s3c_iotimings *iot); > +#else > +#define s3c2412_iotiming_calc NULL > +#define s3c2412_iotiming_get NULL > +#define s3c2412_iotiming_set NULL > +#endif > #ifdef CONFIG_CPU_FREQ_S3C24XX_DEBUG > #define s3c_freq_dbg(x...) printk(KERN_INFO x) -- 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] ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1
Amba core assumes the pclk to be named as apb_pclk. During device probe,
it tries to get that clock and enable that. When PM_RUNTIME is enabled,
dma clock is not explicitly enabled in pl330_probe, which causes device
probe to fail. Adding a clkdev entry for apb_pclk for mdma1 fixes the
problem.
This patch fixes following runtime error.
dma-pl330 dma-pl330.2: PERIPH_ID 0x0, PCELL_ID 0x0 !
dma-pl330: probe of dma-pl330.2 failed with error -22
Signed-off-by: Tushar Behera
---
arch/arm/mach-exynos/clock.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 28e2842..eb33a7a 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -1326,6 +1326,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT("s3c-sdhci.3", "mmc_busclk.2", &clk_sclk_mmc3.clk),
CLKDEV_INIT("dma-pl330.0", "apb_pclk", &clk_pdma0),
CLKDEV_INIT("dma-pl330.1", "apb_pclk", &clk_pdma1),
+ CLKDEV_INIT("dma-pl330.2", "apb_pclk", &clk_mdma1),
};
static int xtal_rate;
--
1.7.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
[PATCH 1/2] DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove
amba_probe() now calls pm_runtime_get_noresume() and pm_runtime_enable()
for the devices before the device probe is called. Hence we don't need
to call pm_runtime_get_xxx and pm_runtime_enable() in device probe again.
In the same way, since amba_remove() calls the respective pm_runtime
functions, those functions need not be called from device remove.
This patch fixes following run time error with pl330 driver.
dma-pl330 dma-pl330.0: Unbalanced pm_runtime_enable!
dma-pl330 dma-pl330.0: failed to get runtime pm
Signed-off-by: Giridhar Maruthy
Signed-off-by: Tushar Behera
---
drivers/dma/pl330.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a626e15..cd07121 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -834,17 +834,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id
*id)
amba_set_drvdata(adev, pdmac);
-#ifdef CONFIG_PM_RUNTIME
- /* to use the runtime PM helper functions */
- pm_runtime_enable(&adev->dev);
-
- /* enable the power domain */
- if (pm_runtime_get_sync(&adev->dev)) {
- dev_err(&adev->dev, "failed to get runtime pm\n");
- ret = -ENODEV;
- goto probe_err1;
- }
-#else
+#ifndef CONFIG_PM_RUNTIME
/* enable dma clk */
clk_enable(pdmac->clk);
#endif
@@ -977,10 +967,7 @@ static int __devexit pl330_remove(struct amba_device *adev)
res = &adev->res;
release_mem_region(res->start, resource_size(res));
-#ifdef CONFIG_PM_RUNTIME
- pm_runtime_put(&adev->dev);
- pm_runtime_disable(&adev->dev);
-#else
+#ifndef CONFIG_PM_RUNTIME
clk_disable(pdmac->clk);
#endif
--
1.7.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
[PATCH 0/2] Add PM_RUNTIME related fixes for PL330
Hi, When PM_RUNTIME is enabled, PL330 probe fails because of some mismatch in pm_runtime calls. This patchset fixes those issues. This patch is based on Kukjin's for-next branch and tested on EXYNOS4 based Origen board. d3d936c "Merge branch 'samsung-fixes-2' into for-next" Tushar Behera (2): To Vinod Koul : DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove To Kukjin Kim : ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1 arch/arm/mach-exynos/clock.c |1 + drivers/dma/pl330.c | 17 ++--- 2 files changed, 3 insertions(+), 15 deletions(-) -- 1.7.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 0/6] SPI platform device consolidation
Padmavathi Venna wrote: > > SPI platform devices are defined in respective machine folder of > Samsung S3C64XX and S5P series SoCs.This patchset moves S3C64XX > and S5P series of SPI platform devices to a common place plat-samsung. > This patchset also creates SPI setup files for GPIO configurations and > platform data initialization. > > V2 Changes: > Platform data initialized in a centralized setup file as suggested-by > Mark Brown > SPI Controller number is added in SPI controller defining structure. > > Padmavathi Venna (6): > ARM: SAMSUNG: Consolidation of SPI platform devices to plat-samsung > ARM: S3C64XX: Modified files for SPI consolidation work > ARM: S5PC100: Modified files for SPI consolidation work. > ARM: S5P64X0: Modified files for SPI consolidation work > ARM: S5PV210: Modified files for SPI consolidation work > > The following patch make the corresponding SPI changes required for > Wolfson Cragganmore S3C6410 variant. This patch is only build tested. > > ARM: S3C64XX: Modified according to SPI consolidation work. > > arch/arm/mach-s3c64xx/Kconfig|8 +- > arch/arm/mach-s3c64xx/Makefile |2 +- > arch/arm/mach-s3c64xx/dev-spi.c | 172 - > arch/arm/mach-s3c64xx/include/mach/map.h |2 + > arch/arm/mach-s3c64xx/setup-spi.c| 47 + > arch/arm/mach-s5p64x0/Kconfig|7 +- > arch/arm/mach-s5p64x0/Makefile |2 +- > arch/arm/mach-s5p64x0/dev-spi.c | 218 - > arch/arm/mach-s5p64x0/include/mach/map.h |3 + > arch/arm/mach-s5p64x0/setup-spi.c| 57 ++ > arch/arm/mach-s5pc100/Kconfig|5 + > arch/arm/mach-s5pc100/Makefile |2 +- > arch/arm/mach-s5pc100/dev-spi.c | 220 -- > arch/arm/mach-s5pc100/include/mach/map.h |3 + > arch/arm/mach-s5pc100/setup-spi.c| 68 +++ > arch/arm/mach-s5pv210/Kconfig|5 + > arch/arm/mach-s5pv210/Makefile |2 +- > arch/arm/mach-s5pv210/dev-spi.c | 169 - > arch/arm/mach-s5pv210/include/mach/map.h |2 + > arch/arm/mach-s5pv210/setup-spi.c| 53 + > arch/arm/plat-samsung/Kconfig| 14 ++- > arch/arm/plat-samsung/devs.c | 106 +++ > arch/arm/plat-samsung/include/plat/devs.h|8 +- > arch/arm/plat-samsung/include/plat/s3c64xx-spi.h | 20 ++- > 24 files changed, 395 insertions(+), 800 deletions(-) > delete mode 100644 arch/arm/mach-s3c64xx/dev-spi.c > create mode 100644 arch/arm/mach-s3c64xx/setup-spi.c > delete mode 100644 arch/arm/mach-s5p64x0/dev-spi.c > create mode 100644 arch/arm/mach-s5p64x0/setup-spi.c > delete mode 100644 arch/arm/mach-s5pc100/dev-spi.c > create mode 100644 arch/arm/mach-s5pc100/setup-spi.c > delete mode 100644 arch/arm/mach-s5pv210/dev-spi.c > create mode 100644 arch/arm/mach-s5pv210/setup-spi.c Hi Padma, Sorry for late response. Basically, looks good to me, but need to re-submit because of following. You need to just move 'resource's and 'platform_device's from each dev-spi.c file into plat-samsung/devs.c in your 1st patch then move 'gpio setup' to each setup-spi.c files in other patches. I think, above ensures bisect of your patches :) Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] PM: Provide an always on power domain governor
Mark Brown wrote: > > On Mon, Dec 05, 2011 at 01:15:18AM +0100, Rafael J. Wysocki wrote: > > On Monday, December 05, 2011, Mark Brown wrote: > > > > It might make sense for it to go via the Samsung tree - the third > patch > > > depends on it and there's some other stuff going on with the s3c64xx > > > power management - so let's see what Kukjin thinks is best. > > > OTOH, it will conflict with some patches I have in the works. > > Ah, OK - in that case I guess it's sensible if you apply it. Ideally it > could be on a separate branch so it could be cross-merged with other > trees if there's a need later. Hi Mark and Rafael, Looks ok to me on this series and would be nice to me if Rafael could create topic branch in his tree and apply this series with my ack for Samsung stuff. Rafael, please let me know the branch when you create it so that I can merge it into Samsung tree to avoid other conflicts. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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 1/3] ARM: EXYNOS: Add USB OHCI device
Tushar Behera wrote: > Subject: Re: [PATCH v2 1/3] ARM: EXYNOS: Add USB OHCI device > > On Tuesday 06 December 2011 12:01 PM, Jingoo Han wrote: > > This patch adds USB ohci device definition for Exynos SoCs. > > > > Signed-off-by: Jingoo Han > > --- > > arch/arm/mach-exynos/Kconfig |5 +++ > > arch/arm/mach-exynos/Makefile |1 + > > arch/arm/mach-exynos/dev-ohci.c | 52 > > + > > arch/arm/mach-exynos/include/mach/map.h |1 + > > arch/arm/mach-exynos/include/mach/ohci.h | 21 +++ > > In the earlier patchset, platform_device struct for ohci was defined > within plat-samsung, and ohci.h was located in > plat-samsung/include/plat. These are still the locations where ehci > related definitions are located. > > What is the reason for movement of ohci related definitions to mach folder? I changed the ohci name from ohci-s5p to ohci-exynos, because the ohci-exynos is used for exynos series such as Exynos4210 & Exynos4x12. Therefore, it should be located within mach-exynos/include/mach. Also, If this patchset is accepted, I will move Samsung ehci definitions to mach-exynos due to the same reason. Thanks. > > -- > Tushar Behera -- 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 1/3] ARM: EXYNOS: Add USB OHCI device
On Tuesday 06 December 2011 12:01 PM, Jingoo Han wrote: This patch adds USB ohci device definition for Exynos SoCs. Signed-off-by: Jingoo Han --- arch/arm/mach-exynos/Kconfig |5 +++ arch/arm/mach-exynos/Makefile |1 + arch/arm/mach-exynos/dev-ohci.c | 52 + arch/arm/mach-exynos/include/mach/map.h |1 + arch/arm/mach-exynos/include/mach/ohci.h | 21 +++ In the earlier patchset, platform_device struct for ohci was defined within plat-samsung, and ohci.h was located in plat-samsung/include/plat. These are still the locations where ehci related definitions are located. What is the reason for movement of ohci related definitions to mach folder? -- Tushar Behera -- 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
