Re: [PATCH v5 0/6] OMAP: McSPI: Hwmod adaptation + runtime conversion
On Tue, Jan 25, 2011 at 3:56 AM, Kevin Hilman khil...@ti.com wrote: Hi Govindraj, Govindraj.R govindraj.r...@ti.com writes: Changes invloves: 1) Addition of hwmod data for omap2/3/4. 2) McSPI driver hwmod adaptation with cleanup of base address macros and using omap-device API's. 3) Runtime Conversion of McSPI driver. I accidentally replied to the v4 series about the refresh, but this one still needs ar refresh. Specifically, this change from Gregory Clement touches some of the same code as your patch: commit 42ce7fd6319bed8ecb26d656c476365da46b29e9 Author: Gregory CLEMENT gregory.clem...@free-electrons.com Date: Wed Dec 29 11:52:53 2010 +0100 spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition Yes correct. Will rebase and repost in couple of days. -- Thanks Govindraj.R Kevin Changes from v4: --- 1) 4430 hwmod file alignment based on Benoit's comments. http://www.spinics.net/lists/arm-kernel/msg111215.html 4430 Hwmod file now aligned based on: http://gitorious.org/omap-pm/linux/blobs/pm-wip/ hwmods-omap4-full/arch/arm/mach-omap2/omap_hwmod_44xx_data.c Changes from v3: --- 1) Updated proper Author for all patches which was missed in v2. 2) Modified 4430 hwmod data file so that mcspi data gets updated in proper alphabetical order. 3) Update omap2/3 hwmod dat files with SYSS_HAS_RESET_STATUS flag. Changes from v2: --- 1) Fixing minor comments and adding ack from Grant Likely. https://patchwork.kernel.org/patch/371321/ https://patchwork.kernel.org/patch/371331/ Changes from v1: --- 1) Fixing patch 5/5 comments for hwmod+runtime Split the patch 5/5 to hwmod adaptation and then runtime conversion http://www.mail-archive.com/linux-omap@vger.kernel.org/msg33387.html Testing Updates: Was tested using data transfer test module available at: http://dev.omapzoom.org/?p=richo/device_driver_test.git;a=blob;f=mcspi/test_code/ utils/mcspi_modules/omap_mcspi_datatest.c; h=e42ec10c5c844abdde6a7175a268b379fbbdb655; hb=5d9a755d50e58de861c5e8991f2f607bc49b5dc3 This test basically involves MISO -- MOSI lines looped and data transfer test done using the above test module. System wide suspend and ret/off counts observation, ensured that no behavioral difference with and without this patch series. Benoit Cousson (1): OMAP4: hwmod data: Add McSPI Charulatha V (4): OMAP2420: hwmod data: Add McSPI OMAP2430: hwmod data: Add McSPI OMAP3: hwmod data: Add McSPI OMAP: devices: Modify McSPI device to adapt to hwmod framework Govindraj.R (1): OMAP: runtime: McSPI driver runtime conversion arch/arm/mach-omap2/devices.c | 187 --- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 156 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 219 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 267 ++ arch/arm/plat-omap/include/plat/mcspi.h | 11 + drivers/spi/omap2_mcspi.c | 224 +++--- 7 files changed, 1044 insertions(+), 300 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
In CPU low power state, local timer looses its register context. This
patch adds context save restore hooks which can be used by platforms
appropriately.
I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
timer stuff wouldn't rely on it being kept alive?
Hmm, it looks like we bypass the clockevents code by only setting the
TWD load value at initialization time, not when we switch to periodic
mode. We really ought to rewrite it whenever we switch back to periodic
mode.
I suspect fixing that means you won't need this save/restore support.
Untested, but should do what's required.
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index fd91566..60636f4 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
/* timer load already set up */
ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
| TWD_TIMER_CONTROL_PERIODIC;
+ __raw_writel(twd_timer_rate / HZ, twd_base +
TWD_TIMER_LOAD);
break;
case CLOCK_EVT_MODE_ONESHOT:
/* period set, and timer enabled in 'next_event' hook */
@@ -81,7 +82,7 @@ int twd_timer_ack(void)
static void __cpuinit twd_calibrate_rate(void)
{
- unsigned long load, count;
+ unsigned long count;
u64 waitjiffies;
/*
@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
printk(%lu.%02luMHz.\n, twd_timer_rate / 100,
(twd_timer_rate / 100) % 100);
}
-
- load = twd_timer_rate / HZ;
-
- __raw_writel(load, twd_base + TWD_TIMER_LOAD);
}
/*
This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register
gets reset by cpu idle between twd_set_mode and twd_set_next_event.
Shadowing ctrl in a percpu variable and rewriting it during every call
to twd_set_next_event does work, but that's not much different, and a
little less efficient, than just saving and restoring the control and
load registers in idle. It does have the advantage that platforms
don't need any extra calls.
The next question is can we teach the generic time infrastructure about
this so we don't have to modify every clock event driver for it? We
really need to get away from having this kind of knowledge buried down
in the lowest levels of every driver.
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP: use fncpy to copy the PM code functions to SRAM
On Mon, Jan 24, 2011 at 5:25 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Hi,
On Mon, Jan 24, 2011 at 5:11 PM, Dave Martin dave.mar...@linaro.org wrote:
Hi there, I just spotted a couple of things merging your patch...
On Tue, Jan 18, 2011 at 12:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The new fncpy API is better suited for copying some
code to SRAM at runtime. This patch changes the ad-hoc
code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
Compile tested on OMAP1/2 using omap1_defconfig.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap1/pm.h | 6 +++---
arch/arm/mach-omap1/sleep.S | 3 +++
arch/arm/mach-omap1/sram.S | 1 +
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/sleep24xx.S | 2 ++
arch/arm/mach-omap2/sleep34xx.S | 2 ++
arch/arm/mach-omap2/sram242x.S | 3 +++
arch/arm/mach-omap2/sram243x.S | 3 +++
arch/arm/mach-omap2/sram34xx.S | 1 +
arch/arm/plat-omap/include/plat/sram.h | 14 +-
arch/arm/plat-omap/sram.c | 14 +-
11 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
index 56a6479..cd926dc 100644
--- a/arch/arm/mach-omap1/pm.h
+++ b/arch/arm/mach-omap1/pm.h
@@ -123,9 +123,9 @@ extern void allow_idle_sleep(void);
extern void omap1_pm_idle(void);
extern void omap1_pm_suspend(void);
-extern void omap7xx_cpu_suspend(unsigned short, unsigned short);
-extern void omap1510_cpu_suspend(unsigned short, unsigned short);
-extern void omap1610_cpu_suspend(unsigned short, unsigned short);
+extern void omap7xx_cpu_suspend(unsigned long, unsigned long);
+extern void omap1510_cpu_suspend(unsigned long, unsigned long);
+extern void omap1610_cpu_suspend(unsigned long, unsigned long);
extern void omap7xx_idle_loop_suspend(void);
extern void omap1510_idle_loop_suspend(void);
extern void omap1610_idle_loop_suspend(void);
diff --git a/arch/arm/mach-omap1/sleep.S b/arch/arm/mach-omap1/sleep.S
index ef771ce..c875bdc 100644
--- a/arch/arm/mach-omap1/sleep.S
+++ b/arch/arm/mach-omap1/sleep.S
@@ -58,6 +58,7 @@
*/
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+ .align 3
ENTRY(omap7xx_cpu_suspend)
@ save registers on stack
@@ -137,6 +138,7 @@ ENTRY(omap7xx_cpu_suspend_sz)
#endif /* CONFIG_ARCH_OMAP730 || CONFIG_ARCH_OMAP850 */
#ifdef CONFIG_ARCH_OMAP15XX
+ .align 3
ENTRY(omap1510_cpu_suspend)
@ save registers on stack
@@ -211,6 +213,7 @@ ENTRY(omap1510_cpu_suspend_sz)
#endif /* CONFIG_ARCH_OMAP15XX */
#if defined(CONFIG_ARCH_OMAP16XX)
+ .align 3
ENTRY(omap1610_cpu_suspend)
@ save registers on stack
diff --git a/arch/arm/mach-omap1/sram.S b/arch/arm/mach-omap1/sram.S
index 7724e52..692587d 100644
--- a/arch/arm/mach-omap1/sram.S
+++ b/arch/arm/mach-omap1/sram.S
@@ -18,6 +18,7 @@
/*
* Reprograms ULPD and CKCTL.
*/
+ .align 3
ENTRY(omap1_sram_reprogram_clock)
stmfd sp!, {r0 - r12, lr} @ save registers on stack
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 1c1b0ab..39580e6 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -92,7 +92,7 @@ extern void omap24xx_idle_loop_suspend(void);
extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem
*sdrc_dlla_ctrl,
void __iomem *sdrc_power);
extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
-extern void save_secure_ram_context(u32 *addr);
+extern int save_secure_ram_context(u32 *addr);
extern void omap3_save_scratchpad_contents(void);
extern unsigned int omap24xx_idle_loop_suspend_sz;
diff --git a/arch/arm/mach-omap2/sleep24xx.S
b/arch/arm/mach-omap2/sleep24xx.S
index c7780cc..b5071a4 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -47,6 +47,7 @@
* Note: This code get's copied to internal SRAM at boot. When the OMAP
* wakes up it continues execution at the point it went to sleep.
*/
+ .align 3
ENTRY(omap24xx_idle_loop_suspend)
stmfd sp!, {r0, lr} @ save registers on stack
mov r0, #0 @ clear for mcr setup
@@ -82,6 +83,7 @@ ENTRY(omap24xx_idle_loop_suspend_sz)
* The DLL load value is not kept in RETENTION or OFF. It needs to be
restored
* at wake
*/
+ .align 3
ENTRY(omap24xx_cpu_suspend)
stmfd sp!, {r0 - r12, lr} @ save registers on stack
mov r3, #0x0 @ clear for mcr call
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index 98d8232..951a0be 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote: This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls. BTW, do you think the patch is, nevertheless, an improvement and something we should do? If so, please can I have your ack for it? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] ARM: twd: Add context save restore support
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:00 PM To: Colin Cross Cc: Santosh Shilimkar; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote: This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls. BTW, do you think the patch is, nevertheless, an improvement and something we should do? If so, please can I have your ack for it? As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it. To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code. Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ? Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Mon, Jan 24, 2011 at 02:21:18PM +0530, Santosh Shilimkar wrote:
This patch moves SCU register defines from smp_scu.c to smp_scu.h
so that its available for platforms to use
The SCU CPU power status registers is used for power management
on OMAP4.
Could we instead have an API inside smp_scu.c rather than having each
SoC implement its own SCU PM stuff?
Maybe this. Note that scu_power_mode() needs to be called from a non-
preemptible context, which is sane as we don't want to be rescheduled
onto a different CPU between scu_power_mode() and the wfi/wfe required
to enter the selected mode.
arch/arm/include/asm/smp_scu.h |5 +
arch/arm/kernel/smp_scu.c | 11 +++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
index 2376835..ec11a92 100644
--- a/arch/arm/include/asm/smp_scu.h
+++ b/arch/arm/include/asm/smp_scu.h
@@ -1,7 +1,12 @@
#ifndef __ASMARM_ARCH_SCU_H
#define __ASMARM_ARCH_SCU_H
+#defineSCU_PM_NORMAL 0
+#define SCU_PM_DORMANT 2
+#define SCU_PM_POWEROFF3
+
unsigned int scu_get_core_count(void __iomem *);
void scu_enable(void __iomem *);
+int scu_power_mode(unsigned int);
#endif
diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 9ab4149..bbb9b1c 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -50,3 +50,14 @@ void __init scu_enable(void __iomem *scu_base)
*/
flush_cache_all();
}
+
+int scu_power_mode(unsigned int mode)
+{
+ int cpu = smp_processor_id();
+
+ if (mode 3 || mode == 1 || cpu 3)
+ return -EINVAL;
+
+ __raw_writel(mode (8 * cpu), scu_base + SCU_CPU_STATUS);
+ return 0;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, Jan 25, 2011 at 05:10:37PM +0530, Santosh Shilimkar wrote: As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it. To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code. Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ? I said earlier: | The next question is can we teach the generic time infrastructure about | this so we don't have to modify every clock event driver for it? We | really need to get away from having this kind of knowledge buried down | in the lowest levels of every driver. IOW, if we go into a PM idle mode, when we come back out we need to call clockevent set_mode to ensure that the control register is properly reset. I don't think its right to have this kind of knowledge buried in each and every clockevent driver. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/5] Clockdomain split series
This patch series is an effort to split the clockdomain framework into platform independent and platform specific parts as was done for the powerdomain framework. This certainlly helps remove the various cpu_is_* checks which exist today in the framework and makes the code more maintainable and readable. The series is boot tested on OMAP2430/3430/4430SDP platforms. Also on OMAP3430SDP, OFF mode in suspend path is validated using the omap3_pm_defconfig. This series is based on mainline 2.6.38-rc2 and can be found here git://gitorious.org/omap-pm/linux.git clockdomain-split-v2-rc2 Version History --- v2 -1- removed wrongly populated sleepdep support for OMAP2 -2- Fixed error handling in apis For a wider review, posting this series with linux-arm-kernel list copied. This version has no functional diff with the earlier one posted here http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42570.html Rajendra Nayak (5): OMAP: clockdomain: Infrastructure to put arch specific code OMAP: clockdomain: Arch specific funcs to handle deps OMAP: clockdomain: Arch specific funcs for sleep/wakeup of clkdm OMAP: clockdomain: Arch specific funcs for hwsup control of clkdm OMAP: clockdomain: Arch specific funcs for clkdm_clk_enable/disable arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/clock.c |6 +- arch/arm/mach-omap2/clockdomain.c| 410 +++--- arch/arm/mach-omap2/clockdomain.h| 58 +++- arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 270 ++ arch/arm/mach-omap2/clockdomain44xx.c| 77 arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |9 +- arch/arm/mach-omap2/clockdomains44xx_data.c |2 +- arch/arm/mach-omap2/cpuidle34xx.c|4 +- arch/arm/mach-omap2/io.c |6 +- arch/arm/mach-omap2/pm.c |6 +- arch/arm/mach-omap2/pm24xx.c |8 +- arch/arm/mach-omap2/pm34xx.c |6 +- 13 files changed, 557 insertions(+), 308 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c create mode 100644 arch/arm/mach-omap2/clockdomain44xx.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/5] OMAP: clockdomain: Infrastructure to put arch specific code
Put infrastructure in place, so arch specific func pointers
can be hooked up to the platform-independent part of the
framework.
This is in preparation of splitting the clockdomain framework into
platform-independent part (for all omaps) and platform-specific
parts.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c| 10 +-
arch/arm/mach-omap2/clockdomain.h| 37 +-
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |2 +-
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
4 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index e20b986..3e40184 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -44,6 +44,7 @@ static LIST_HEAD(clkdm_list);
/* array of clockdomain deps to be added/removed when clkdm in hwsup mode */
static struct clkdm_autodep *autodeps;
+static struct clkdm_ops *arch_clkdm;
/* Private functions */
@@ -292,6 +293,7 @@ static void _disable_hwsup(struct clockdomain *clkdm)
* clkdm_init - set up the clockdomain layer
* @clkdms: optional pointer to an array of clockdomains to register
* @init_autodeps: optional pointer to an array of autodeps to register
+ * @custom_funcs: func pointers for arch specfic implementations
*
* Set up internal state. If a pointer to an array of clockdomains
* @clkdms was supplied, loop through the list of clockdomains,
@@ -300,12 +302,18 @@ static void _disable_hwsup(struct clockdomain *clkdm)
* @init_autodeps was provided, register those. No return value.
*/
void clkdm_init(struct clockdomain **clkdms,
- struct clkdm_autodep *init_autodeps)
+ struct clkdm_autodep *init_autodeps,
+ struct clkdm_ops *custom_funcs)
{
struct clockdomain **c = NULL;
struct clockdomain *clkdm;
struct clkdm_autodep *autodep = NULL;
+ if (!custom_funcs)
+ WARN(1, No custom clkdm functions registered\n);
+ else
+ arch_clkdm = custom_funcs;
+
if (clkdms)
for (c = clkdms; *c; c++)
_clkdm_register(*c);
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index 9b459c2..71ad265 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -116,7 +116,42 @@ struct clockdomain {
struct list_head node;
};
-void clkdm_init(struct clockdomain **clkdms, struct clkdm_autodep *autodeps);
+/**
+ * struct clkdm_ops - Arch specfic function implementations
+ * @clkdm_add_wkdep: Add a wakeup dependency between clk domains
+ * @clkdm_del_wkdep: Delete a wakeup dependency between clk domains
+ * @clkdm_read_wkdep: Read wakeup dependency state between clk domains
+ * @clkdm_clear_all_wkdeps: Remove all wakeup dependencies from the clk domain
+ * @clkdm_add_sleepdep: Add a sleep dependency between clk domains
+ * @clkdm_del_sleepdep: Delete a sleep dependency between clk domains
+ * @clkdm_read_sleepdep: Read sleep dependency state between clk domains
+ * @clkdm_clear_all_sleepdeps: Remove all sleep dependencies from the clk
domain
+ * @clkdm_sleep: Force a clockdomain to sleep
+ * @clkdm_wakeup: Force a clockdomain to wakeup
+ * @clkdm_allow_idle: Enable hw supervised idle transitions for clock domain
+ * @clkdm_deny_idle: Disable hw supervised idle transitions for clock domain
+ * @clkdm_clk_enable: Put the clkdm in right state for a clock enable
+ * @clkdm_clk_disable: Put the clkdm in right state for a clock disable
+ */
+struct clkdm_ops {
+ int (*clkdm_add_wkdep)(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
+ int (*clkdm_del_wkdep)(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
+ int (*clkdm_read_wkdep)(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
+ int (*clkdm_clear_all_wkdeps)(struct clockdomain *clkdm);
+ int (*clkdm_add_sleepdep)(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
+ int (*clkdm_del_sleepdep)(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
+ int (*clkdm_read_sleepdep)(struct clockdomain *clkdm1, struct
clockdomain *clkdm2);
+ int (*clkdm_clear_all_sleepdeps)(struct clockdomain *clkdm);
+ int (*clkdm_sleep)(struct clockdomain *clkdm);
+ int (*clkdm_wakeup)(struct clockdomain *clkdm);
+ void(*clkdm_allow_idle)(struct clockdomain *clkdm);
+ void(*clkdm_deny_idle)(struct clockdomain *clkdm);
+ int (*clkdm_clk_enable)(struct clockdomain *clkdm);
+ int (*clkdm_clk_disable)(struct clockdomain *clkdm);
+};
+
+void clkdm_init(struct clockdomain **clkdms, struct clkdm_autodep *autodeps,
+ struct clkdm_ops *custom_funcs);
struct clockdomain *clkdm_lookup(const char
[PATCH v2 4/5] OMAP: clockdomain: Arch specific funcs for hwsup control of clkdm
Define the following architecture specific funtions for omap2/3/4
.clkdm_allow_idle
.clkdm_deny_idle
Convert the platform-independent framework to call these functions.
Also rename the api's by removing the omap2_ preamble.
Hence call omap2_clkdm_allow_idle as clkdm_allow_idle and
omap2_clkdm_deny_idle as clkdm_deny_idle.
Make the _clkdm_add_autodeps and _clkdm_del_autodeps as non-static
so they can be accessed from OMAP2/3 platform specific code.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clockdomain.c | 49 ---
arch/arm/mach-omap2/clockdomain.h |6 ++-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 40 ++
arch/arm/mach-omap2/clockdomain44xx.c | 14
arch/arm/mach-omap2/cpuidle34xx.c |4 +-
arch/arm/mach-omap2/pm.c |2 +-
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |4 +-
8 files changed, 79 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 9beccc7..9f1f37b 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -178,7 +178,7 @@ static void _autodep_lookup(struct clkdm_autodep *autodep)
* XXX autodeps are deprecated and should be removed at the earliest
* opportunity
*/
-static void _clkdm_add_autodeps(struct clockdomain *clkdm)
+void _clkdm_add_autodeps(struct clockdomain *clkdm)
{
struct clkdm_autodep *autodep;
@@ -212,7 +212,7 @@ static void _clkdm_add_autodeps(struct clockdomain *clkdm)
* XXX autodeps are deprecated and should be removed at the earliest
* opportunity
*/
-static void _clkdm_del_autodeps(struct clockdomain *clkdm)
+void _clkdm_del_autodeps(struct clockdomain *clkdm)
{
struct clkdm_autodep *autodep;
@@ -332,7 +332,7 @@ void clkdm_init(struct clockdomain **clkdms,
if (clkdm-flags CLKDM_CAN_FORCE_WAKEUP)
clkdm_wakeup(clkdm);
else if (clkdm-flags CLKDM_CAN_DISABLE_AUTO)
- omap2_clkdm_deny_idle(clkdm);
+ clkdm_deny_idle(clkdm);
for (cd = clkdm-wkdep_srcs; cd cd-clkdm_name; cd++) {
if (!omap_chip_is(cd-omap_chip))
@@ -780,7 +780,7 @@ int clkdm_wakeup(struct clockdomain *clkdm)
}
/**
- * omap2_clkdm_allow_idle - enable hwsup idle transitions for clkdm
+ * clkdm_allow_idle - enable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
*
* Allow the hardware to automatically switch the clockdomain @clkdm into
@@ -789,7 +789,7 @@ int clkdm_wakeup(struct clockdomain *clkdm)
* framework, wkdep/sleepdep autodependencies are added; this is so
* device drivers can read and write to the device. No return value.
*/
-void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
+void clkdm_allow_idle(struct clockdomain *clkdm)
{
if (!clkdm)
return;
@@ -800,28 +800,18 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
return;
}
+ if (!arch_clkdm || !arch_clkdm-clkdm_allow_idle)
+ return;
+
pr_debug(clockdomain: enabling automatic idle transitions for %s\n,
clkdm-name);
- /*
-* XXX This should be removed once TI adds wakeup/sleep
-* dependency code and data for OMAP4.
-*/
- if (cpu_is_omap44xx()) {
- WARN_ONCE(1, clockdomain: OMAP4 wakeup/sleep dependency
- support is not yet implemented\n);
- } else {
- if (atomic_read(clkdm-usecount) 0)
- _clkdm_add_autodeps(clkdm);
- }
-
- _enable_hwsup(clkdm);
-
+ arch_clkdm-clkdm_allow_idle(clkdm);
pwrdm_clkdm_state_switch(clkdm);
}
/**
- * omap2_clkdm_deny_idle - disable hwsup idle transitions for clkdm
+ * clkdm_deny_idle - disable hwsup idle transitions for clkdm
* @clkdm: struct clockdomain *
*
* Prevent the hardware from automatically switching the clockdomain
@@ -829,7 +819,7 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
* downstream clocks enabled in the clock framework, wkdep/sleepdep
* autodependencies are removed. No return value.
*/
-void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
+void clkdm_deny_idle(struct clockdomain *clkdm)
{
if (!clkdm)
return;
@@ -840,22 +830,13 @@ void omap2_clkdm_deny_idle(struct clockdomain *clkdm)
return;
}
+ if (!arch_clkdm || !arch_clkdm-clkdm_deny_idle)
+ return;
+
pr_debug(clockdomain: disabling automatic idle transitions for %s\n,
clkdm-name);
- _disable_hwsup(clkdm);
-
- /*
-* XXX This should be removed once TI adds wakeup/sleep
-* dependency code and data for OMAP4.
-*/
[PATCH v2 5/5] OMAP: clockdomain: Arch specific funcs for clkdm_clk_enable/disable
Define the following architecture specific funtions for omap2/3/4
.clkdm_clk_enable
.clkdm_clk_disable
Convert the platform-independent framework to call these functions.
Also rename the api's by removing the omap2_ preamble.
Hence call omap2_clkdm_k_enable as clkdm_clk_enable and
omap2_clkdm_clk_disable as clkdm_clk_disable.a
Remove unused functions (_enable/_disable_hwsup) and unsed
headers from clockdomain.c file.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock.c|6 +-
arch/arm/mach-omap2/clockdomain.c | 131 +++-
arch/arm/mach-omap2/clockdomain.h |4 +-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 69 +++
arch/arm/mach-omap2/clockdomain44xx.c | 28 ++
5 files changed, 114 insertions(+), 124 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 2a2f152..e9625fc 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -264,7 +264,7 @@ void omap2_clk_disable(struct clk *clk)
clk-ops-disable(clk);
if (clk-clkdm)
- omap2_clkdm_clk_disable(clk-clkdm, clk);
+ clkdm_clk_disable(clk-clkdm, clk);
if (clk-parent)
omap2_clk_disable(clk-parent);
@@ -304,7 +304,7 @@ int omap2_clk_enable(struct clk *clk)
}
if (clk-clkdm) {
- ret = omap2_clkdm_clk_enable(clk-clkdm, clk);
+ ret = clkdm_clk_enable(clk-clkdm, clk);
if (ret) {
WARN(1, clock: %s: could not enable clockdomain %s:
%d\n, clk-name, clk-clkdm-name, ret);
@@ -322,7 +322,7 @@ int omap2_clk_enable(struct clk *clk)
oce_err3:
if (clk-clkdm)
- omap2_clkdm_clk_disable(clk-clkdm, clk);
+ clkdm_clk_disable(clk-clkdm, clk);
oce_err2:
if (clk-parent)
omap2_clk_disable(clk-parent);
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 9f1f37b..633567e 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -26,17 +26,8 @@
#include linux/bitops.h
-#include prm2xxx_3xxx.h
-#include prm-regbits-24xx.h
-#include cm2xxx_3xxx.h
-#include cm-regbits-24xx.h
-#include cminst44xx.h
-#include prcm44xx.h
-
#include plat/clock.h
-#include powerdomain.h
#include clockdomain.h
-#include plat/prcm.h
/* clkdm_list contains all registered struct clockdomains */
static LIST_HEAD(clkdm_list);
@@ -235,58 +226,6 @@ void _clkdm_del_autodeps(struct clockdomain *clkdm)
}
}
-/**
- * _enable_hwsup - place a clockdomain into hardware-supervised idle
- * @clkdm: struct clockdomain *
- *
- * Place the clockdomain into hardware-supervised idle mode. No return
- * value.
- *
- * XXX Should this return an error if the clockdomain does not support
- * hardware-supervised idle mode?
- */
-static void _enable_hwsup(struct clockdomain *clkdm)
-{
- if (cpu_is_omap24xx())
- omap2xxx_cm_clkdm_enable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
- clkdm-clktrctrl_mask);
- else if (cpu_is_omap34xx())
- omap3xxx_cm_clkdm_enable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
- clkdm-clktrctrl_mask);
- else if (cpu_is_omap44xx())
- return omap4_cminst_clkdm_enable_hwsup(clkdm-prcm_partition,
- clkdm-cm_inst,
- clkdm-clkdm_offs);
- else
- BUG();
-}
-
-/**
- * _disable_hwsup - place a clockdomain into software-supervised idle
- * @clkdm: struct clockdomain *
- *
- * Place the clockdomain @clkdm into software-supervised idle mode.
- * No return value.
- *
- * XXX Should this return an error if the clockdomain does not support
- * software-supervised idle mode?
- */
-static void _disable_hwsup(struct clockdomain *clkdm)
-{
- if (cpu_is_omap24xx())
- omap2xxx_cm_clkdm_disable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
- clkdm-clktrctrl_mask);
- else if (cpu_is_omap34xx())
- omap3xxx_cm_clkdm_disable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
- clkdm-clktrctrl_mask);
- else if (cpu_is_omap44xx())
- return omap4_cminst_clkdm_disable_hwsup(clkdm-prcm_partition,
- clkdm-cm_inst,
- clkdm-clkdm_offs);
- else
- BUG();
-}
-
/* Public functions */
/**
@@ -843,7 +782,7 @@ void clkdm_deny_idle(struct clockdomain *clkdm)
/* Clockdomain-to-clock framework interface code */
/**
- * omap2_clkdm_clk_enable - add an enabled downstream clock to this clkdm
+ *
[PATCH v2 3/5] OMAP: clockdomain: Arch specific funcs for sleep/wakeup of clkdm
Define the following architecture specific funtions for omap2/3/4
.clkdm_sleep
.clkdm_wakeup
Convert the platform-independent framework to call these functions.
Also rename the api's by removing the omap2_ preamble.
Hence call omap2_clkdm_wakeup as clkdm_wakeup and
omap2_clkdm_sleep as clkdm_sleep.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile|1 +
arch/arm/mach-omap2/clockdomain.c | 64 ++
arch/arm/mach-omap2/clockdomain.h |5 +-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 35 +++
arch/arm/mach-omap2/clockdomain44xx.c | 35 +++
arch/arm/mach-omap2/clockdomains44xx_data.c |2 +-
arch/arm/mach-omap2/pm.c|4 +-
arch/arm/mach-omap2/pm24xx.c|6 +-
arch/arm/mach-omap2/pm34xx.c|2 +-
9 files changed, 96 insertions(+), 58 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomain44xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6b2824d..72f2891 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= clockdomain.o \
clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
+ clockdomain44xx.o \
clockdomains44xx_data.o
# Clock framework
obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o \
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 1c461ed..9beccc7 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -330,7 +330,7 @@ void clkdm_init(struct clockdomain **clkdms,
*/
list_for_each_entry(clkdm, clkdm_list, node) {
if (clkdm-flags CLKDM_CAN_FORCE_WAKEUP)
- omap2_clkdm_wakeup(clkdm);
+ clkdm_wakeup(clkdm);
else if (clkdm-flags CLKDM_CAN_DISABLE_AUTO)
omap2_clkdm_deny_idle(clkdm);
@@ -724,7 +724,7 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
}
/**
- * omap2_clkdm_sleep - force clockdomain sleep transition
+ * clkdm_sleep - force clockdomain sleep transition
* @clkdm: struct clockdomain *
*
* Instruct the CM to force a sleep transition on the specified
@@ -732,7 +732,7 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm)
* clockdomain does not support software-initiated sleep; 0 upon
* success.
*/
-int omap2_clkdm_sleep(struct clockdomain *clkdm)
+int clkdm_sleep(struct clockdomain *clkdm)
{
if (!clkdm)
return -EINVAL;
@@ -743,33 +743,16 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
return -EINVAL;
}
- pr_debug(clockdomain: forcing sleep on %s\n, clkdm-name);
-
- if (cpu_is_omap24xx()) {
-
- omap2_cm_set_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
- clkdm-pwrdm.ptr-prcm_offs, OMAP2_PM_PWSTCTRL);
-
- } else if (cpu_is_omap34xx()) {
-
- omap3xxx_cm_clkdm_force_sleep(clkdm-pwrdm.ptr-prcm_offs,
- clkdm-clktrctrl_mask);
-
- } else if (cpu_is_omap44xx()) {
-
- omap4_cminst_clkdm_force_sleep(clkdm-prcm_partition,
- clkdm-cm_inst,
- clkdm-clkdm_offs);
+ if (!arch_clkdm || !arch_clkdm-clkdm_sleep)
+ return -EINVAL;
- } else {
- BUG();
- };
+ pr_debug(clockdomain: forcing sleep on %s\n, clkdm-name);
- return 0;
+ return arch_clkdm-clkdm_sleep(clkdm);
}
/**
- * omap2_clkdm_wakeup - force clockdomain wakeup transition
+ * clkdm_wakeup - force clockdomain wakeup transition
* @clkdm: struct clockdomain *
*
* Instruct the CM to force a wakeup transition on the specified
@@ -777,7 +760,7 @@ int omap2_clkdm_sleep(struct clockdomain *clkdm)
* clockdomain does not support software-controlled wakeup; 0 upon
* success.
*/
-int omap2_clkdm_wakeup(struct clockdomain *clkdm)
+int clkdm_wakeup(struct clockdomain *clkdm)
{
if (!clkdm)
return -EINVAL;
@@ -788,29 +771,12 @@ int omap2_clkdm_wakeup(struct clockdomain *clkdm)
return -EINVAL;
}
- pr_debug(clockdomain: forcing wakeup on %s\n, clkdm-name);
-
- if (cpu_is_omap24xx()) {
-
- omap2_cm_clear_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
- clkdm-pwrdm.ptr-prcm_offs, OMAP2_PM_PWSTCTRL);
-
- } else if (cpu_is_omap34xx()) {
-
-
[PATCH v2 2/5] OMAP: clockdomain: Arch specific funcs to handle deps
Define the following architecture specific funtions for omap2/3
.clkdm_add_wkdep
.clkdm_del_wkdep
.clkdm_read_wkdep
.clkdm_clear_all_wkdeps
.clkdm_add_sleepdep
.clkdm_del_sleepdep
.clkdm_read_sleepdep
.clkdm_clear_all_sleepdeps
Convert the platform-independent framework to call these functions.
With this also move the clkdm lookups for all wkdep_srcs and
sleepdep_srcs at clkdm_init.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/clockdomain.c| 160 +++---
arch/arm/mach-omap2/clockdomain.h|6 +-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 126 +
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c |9 +-
arch/arm/mach-omap2/io.c |6 +-
6 files changed, 225 insertions(+), 84 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c0c2b0..6b2824d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -102,8 +102,10 @@ obj-$(CONFIG_ARCH_OMAP4) +=
$(powerdomain-common) \
# PRCM clockdomain control
obj-$(CONFIG_ARCH_OMAP2) += clockdomain.o \
+ clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP3) += clockdomain.o \
+ clockdomain2xxx_3xxx.o \
clockdomains2xxx_3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += clockdomain.o \
clockdomains44xx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 3e40184..1c461ed 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -308,6 +308,7 @@ void clkdm_init(struct clockdomain **clkdms,
struct clockdomain **c = NULL;
struct clockdomain *clkdm;
struct clkdm_autodep *autodep = NULL;
+ struct clkdm_dep *cd;
if (!custom_funcs)
WARN(1, No custom clkdm functions registered\n);
@@ -333,7 +334,18 @@ void clkdm_init(struct clockdomain **clkdms,
else if (clkdm-flags CLKDM_CAN_DISABLE_AUTO)
omap2_clkdm_deny_idle(clkdm);
+ for (cd = clkdm-wkdep_srcs; cd cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+ }
clkdm_clear_all_wkdeps(clkdm);
+
+ for (cd = clkdm-sleepdep_srcs; cd cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+ }
clkdm_clear_all_sleepdeps(clkdm);
}
}
@@ -430,26 +442,32 @@ struct powerdomain *clkdm_get_pwrdm(struct clockdomain
*clkdm)
int clkdm_add_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2)
{
struct clkdm_dep *cd;
+ int ret = 0;
if (!clkdm1 || !clkdm2)
return -EINVAL;
cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
- if (IS_ERR(cd)) {
+ if (IS_ERR(cd))
+ ret = PTR_ERR(cd);
+
+ if (!arch_clkdm || !arch_clkdm-clkdm_add_wkdep)
+ ret = -EINVAL;
+
+ if (ret) {
pr_debug(clockdomain: hardware cannot set/clear wake up of
%s when %s wakes up\n, clkdm1-name, clkdm2-name);
- return PTR_ERR(cd);
+ return ret;
}
if (atomic_inc_return(cd-wkdep_usecount) == 1) {
pr_debug(clockdomain: hardware will wake up %s when %s wakes
up\n, clkdm1-name, clkdm2-name);
- omap2_prm_set_mod_reg_bits((1 clkdm2-dep_bit),
-clkdm1-pwrdm.ptr-prcm_offs, PM_WKDEP);
+ ret = arch_clkdm-clkdm_add_wkdep(clkdm1, clkdm2);
}
- return 0;
+ return ret;
}
/**
@@ -465,26 +483,32 @@ int clkdm_add_wkdep(struct clockdomain *clkdm1, struct
clockdomain *clkdm2)
int clkdm_del_wkdep(struct clockdomain *clkdm1, struct clockdomain *clkdm2)
{
struct clkdm_dep *cd;
+ int ret = 0;
if (!clkdm1 || !clkdm2)
return -EINVAL;
cd = _clkdm_deps_lookup(clkdm2, clkdm1-wkdep_srcs);
- if (IS_ERR(cd)) {
+ if (IS_ERR(cd))
+ ret = PTR_ERR(cd);
+
+ if (!arch_clkdm || !arch_clkdm-clkdm_del_wkdep)
+ ret = -EINVAL;
+
+ if (ret) {
pr_debug(clockdomain: hardware cannot set/clear wake up of
%s
RE: [PATCH 4/5] ARM: scu: Move register defines to header file
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:17 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com; ccr...@android.com; linus.ml.wall...@gmail.com; linux- o...@vger.kernel.org Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file On Mon, Jan 24, 2011 at 02:21:18PM +0530, Santosh Shilimkar wrote: This patch moves SCU register defines from smp_scu.c to smp_scu.h so that its available for platforms to use The SCU CPU power status registers is used for power management on OMAP4. Could we instead have an API inside smp_scu.c rather than having each SoC implement its own SCU PM stuff? I have similar patch implemented but what it does is just prepares the value to be programmed and stores it to a scratchpad. I see your point but below patch may now work well. The reason is the SCU register needs to accessed at the lowest level. May be even when stack is not available. Also this register needs to be cleared in cases where the attempted power state is failed for some reason. Also note that this register can be blocked using trust-zone which again makes it platform dependent because direct write won't be allowed in that case. Maybe this. Note that scu_power_mode() needs to be called from a non- preemptible context, which is sane as we don't want to be rescheduled onto a different CPU between scu_power_mode() and the wfi/wfe required to enter the selected mode. I would prefer the header export if there is no major objection since there is already a possibility of custom implementation with trust zone. On OMAP4, on ES1.0 we need to use a secure API to achieve this where as on ES2.0, it can be directly accessed. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] ARM: twd: Add context save restore support
Looping Thomas G -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:19 PM To: Santosh Shilimkar Cc: Colin Cross; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support On Tue, Jan 25, 2011 at 05:10:37PM +0530, Santosh Shilimkar wrote: As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it. To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code. Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ? I said earlier: | The next question is can we teach the generic time infrastructure about | this so we don't have to modify every clock event driver for it? We | really need to get away from having this kind of knowledge buried down | in the lowest levels of every driver. IOW, if we go into a PM idle mode, when we come back out we need to call clockevent set_mode to ensure that the control register is properly reset. I don't think its right to have this kind of knowledge buried in each and every clockevent driver. May be Thomas can comment on this. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Tue, Jan 25, 2011 at 05:32:57PM +0530, Santosh Shilimkar wrote: I have similar patch implemented but what it does is just prepares the value to be programmed and stores it to a scratchpad. I see your point but below patch may now work well. The reason is the SCU register needs to accessed at the lowest level. May be even when stack is not available. Also this register needs to be cleared in cases where the attempted power state is failed for some reason. From the documentation I have, the power control register has no effect until the CPU enters WFI mode - which means that provided we can guarantee no one issues a WFI instruction between setting the power mode, and executing that instruction, being woken up (or failing) and resetting the power mode back... that shouldn't require the power mode to be programmed from assembly code. In any case, we actually need the help of spinlocks to deal with concurrent access to the SCU power control register - something you can't do in assembly code. On the way down to a WFI low power mode, we can call scu_power_mode(), do the rest of the cleanup (which must not schedule) and issue WFI. On the way back up, do whatever needs to be done and call scu_power_mode() to reset back to 'normal' mode. Also note that this register can be blocked using trust-zone which again makes it platform dependent because direct write won't be allowed in that case. Yes, I did notice. What's the OMAP SMC interface for that? I would prefer the header export if there is no major objection since there is already a possibility of custom implementation with trust zone. On OMAP4, on ES1.0 we need to use a secure API to achieve this where as on ES2.0, it can be directly accessed. As I say, I'd rather not have each SoC implementing access to this as someone's bound to forget the spinlock if they're dealing with more than one CPU, which'll make stuff unreliable (just like I did on my initial version.) We could have a callback to SoC code which does the appropriate SMC call, but first I'll need to know what's required for the SMC call. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, Jan 25, 2011 at 05:38:49PM +0530, Santosh Shilimkar wrote: Looping Thomas G -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:19 PM To: Santosh Shilimkar Cc: Colin Cross; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support On Tue, Jan 25, 2011 at 05:10:37PM +0530, Santosh Shilimkar wrote: As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it. To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code. Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ? I said earlier: | The next question is can we teach the generic time infrastructure about | this so we don't have to modify every clock event driver for it? We | really need to get away from having this kind of knowledge buried down | in the lowest levels of every driver. IOW, if we go into a PM idle mode, when we come back out we need to call clockevent set_mode to ensure that the control register is properly reset. I don't think its right to have this kind of knowledge buried in each and every clockevent driver. May be Thomas can comment on this. He was already added on my previous email... we're going round in circles. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] ARM: twd: Add context save restore support
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:48 PM To: Santosh Shilimkar Cc: Thomas Gleixner; Colin Cross; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support call clockevent set_mode to ensure that the control register is properly reset. I don't think its right to have this kind of knowledge buried in each and every clockevent driver. May be Thomas can comment on this. He was already added on my previous email... we're going round in circles. Sorry about that. Didn't noticed earlier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Tue, Jan 25, 2011 at 12:16:56PM +, Russell King - ARM Linux wrote:
On Tue, Jan 25, 2011 at 05:32:57PM +0530, Santosh Shilimkar wrote:
I have similar patch implemented but what it does is just
prepares the value to be programmed and stores it to a scratchpad.
I see your point but below patch may now work well. The reason is the SCU
register needs to accessed at the lowest level. May be even when
stack is not available. Also this register needs to be cleared in cases
where the attempted power state is failed for some reason.
From the documentation I have, the power control register has no effect
until the CPU enters WFI mode - which means that provided we can
guarantee no one issues a WFI instruction between setting the power mode,
and executing that instruction, being woken up (or failing) and resetting
the power mode back... that shouldn't require the power mode to be
programmed from assembly code.
In any case, we actually need the help of spinlocks to deal with
concurrent access to the SCU power control register - something you
can't do in assembly code.
On the way down to a WFI low power mode, we can call scu_power_mode(),
do the rest of the cleanup (which must not schedule) and issue WFI. On
the way back up, do whatever needs to be done and call scu_power_mode()
to reset back to 'normal' mode.
Also note that this register can be blocked using trust-zone which
again makes it platform dependent because direct write won't be
allowed in that case.
Yes, I did notice. What's the OMAP SMC interface for that?
I would prefer the header export if there is no major
objection since there is already a possibility of custom
implementation with trust zone.
On OMAP4, on ES1.0 we need to use a secure API to achieve
this where as on ES2.0, it can be directly accessed.
As I say, I'd rather not have each SoC implementing access to this as
someone's bound to forget the spinlock if they're dealing with more than
one CPU, which'll make stuff unreliable (just like I did on my initial
version.)
We could have a callback to SoC code which does the appropriate SMC call,
but first I'll need to know what's required for the SMC call.
I did mean to include the updated patch:
arch/arm/include/asm/smp_scu.h |5 +
arch/arm/kernel/smp_scu.c | 23 +++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
index 2376835..108f31d 100644
--- a/arch/arm/include/asm/smp_scu.h
+++ b/arch/arm/include/asm/smp_scu.h
@@ -1,7 +1,12 @@
#ifndef __ASMARM_ARCH_SCU_H
#define __ASMARM_ARCH_SCU_H
+#define SCU_PM_NORMAL 0
+#define SCU_PM_DORMANT 2
+#define SCU_PM_POWEROFF3
+
unsigned int scu_get_core_count(void __iomem *);
void scu_enable(void __iomem *);
+int scu_power_mode(unsigned int);
#endif
diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 9ab4149..4c4c90d 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -10,6 +10,7 @@
*/
#include linux/init.h
#include linux/io.h
+#include linux/spinlock.h
#include asm/smp_scu.h
#include asm/cacheflush.h
@@ -20,6 +21,8 @@
#define SCU_INVALIDATE 0x0c
#define SCU_FPGA_REVISION 0x10
+static DEFINE_SPINLOCK(scu_power_lock);
+
/*
* Get the number of CPU cores from the SCU configuration
*/
@@ -50,3 +53,23 @@ void __init scu_enable(void __iomem *scu_base)
*/
flush_cache_all();
}
+
+int scu_power_mode(unsigned int mode)
+{
+ int cpu = smp_processor_id();
+ int shift;
+ u32 val;
+
+ if (mode 3 || mode == 1 || cpu 3)
+ return -EINVAL;
+
+ shift = cpu * 8;
+
+ spin_lock(scu_power_lock);
+ val = raw_readl(scu_base + SCU_CPU_STATUS) ~(0x03 shift);
+ val |= mode shift;
+ __raw_writel(val, scu_base + SCU_CPU_STATUS);
+ spin_unlock(scu_power_lock);
+
+ return 0;
+}
If we need a SMC call, that should happen within the spinlock'd region via
a function pointer which the platform can set. I can't code that into this
patch until I know what the SMC call requires as arguments (cpu number,
power state, or new register value, or mask and bits to set?)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] ARM: scu: Move register defines to header file
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:47 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com; ccr...@android.com; linus.ml.wall...@gmail.com; linux- o...@vger.kernel.org Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file On Tue, Jan 25, 2011 at 05:32:57PM +0530, Santosh Shilimkar wrote: I have similar patch implemented but what it does is just prepares the value to be programmed and stores it to a scratchpad. I see your point but below patch may now work well. The reason is the SCU register needs to accessed at the lowest level. May be even when stack is not available. Also this register needs to be cleared in cases where the attempted power state is failed for some reason. From the documentation I have, the power control register has no effect until the CPU enters WFI mode - which means that provided we can guarantee no one issues a WFI instruction between setting the power mode, and executing that instruction, being woken up (or failing) and resetting the power mode back... that shouldn't require the power mode to be programmed from assembly code. In any case, we actually need the help of spinlocks to deal with concurrent access to the SCU power control register - something you can't do in assembly code. On the way down to a WFI low power mode, we can call scu_power_mode(), do the rest of the cleanup (which must not schedule) and issue WFI. On the way back up, do whatever needs to be done and call scu_power_mode() to reset back to 'normal' mode. Ok. I missed some information my last email. The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable. I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. The programming happens from IDLE or suspend where the Also note that this register can be blocked using trust-zone which again makes it platform dependent because direct write won't be allowed in that case. Yes, I did notice. What's the OMAP SMC interface for that? I would prefer the header export if there is no major objection since there is already a possibility of custom implementation with trust zone. On OMAP4, on ES1.0 we need to use a secure API to achieve this where as on ES2.0, it can be directly accessed. As I say, I'd rather not have each SoC implementing access to this as someone's bound to forget the spinlock if they're dealing with more than one CPU, which'll make stuff unreliable (just like I did on my initial version.) We could have a callback to SoC code which does the appropriate SMC call, but first I'll need to know what's required for the SMC call. Ok. Will try to see if things can be worked out as pet your suggestion. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] ARM: scu: Move register defines to header file
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 5:59 PM To: Santosh Shilimkar Cc: catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; ccr...@android.com Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file I did mean to include the updated patch: As said in other email will work towards this. arch/arm/include/asm/smp_scu.h |5 + arch/arm/kernel/smp_scu.c | 23 +++ 2 files changed, 28 insertions(+), 0 deletions(-) [] If we need a SMC call, that should happen within the spinlock'd region via a function pointer which the platform can set. I can't code that into this patch until I know what the SMC call requires as arguments (cpu number, power state, or new register value, or mask and bits to set?) No problem. Will update SMC stuff if needed. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote: Ok. I missed some information my last email. The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable. I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. Erm, I do hope that's not the case, as that means it is unsafe for CPUs in a SMP system to write to this register without them potentially trampling over each other. If it is the case, then the solutions are either: 1. Fix the hardware so that coherency requests only yet turned off when entering the WFI state. 2. Fix the hardware such that each CPU has a separate register. I can't see a software solution to this as we can't use ldrex/strex anything but memory regions, and memory regions without coherency won't work. Maybe ARM Support can help by suggesting how a 4-CPU system is supposed to safely read/modify/write the SCU power control register... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] OMAP2PLUS: DSS: Generalize clock names
This patch series changes dss clock names to generic role names for all DSS clocks across clk APIs, hwmod data, dss driver. It also changes the enums used within DSS framework to refer to the clocks to make them generic and related to functionality than value. eg. DSS_CLK_TVFCK replaces DSS_CLK_54M, dss_tv_fck replaces dss_54m_fck This serves as the base for common hwmod DSS opt-clock roles across all OMAP platforms, and increases extendability. In addition, since ick doesn't exist on OMAP4, the last patch adds a dummy clk for the same in clock44xx_data.c. === Note: This is interim change set to enable DSS on OMAP2/3/4 platforms; there is an ongoing design discussion for de-centralizing the DSS clock framework handling in favour of using pm_runtime APIs directly in each DSS IP. Once a consensus is reached on that, much of this code will become cleaner, as each DSS IP block handles its own clocks using the common clocks framework. Patch Base: === Patch-set rebased and tested w/ Zoom3 (OMAP3630) on top of: url = git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git branch master commit e8883f8057c0f7c9950fa9f20568f37bfa62f34a Description: Add linux-next specific files for 20110115 + Patch mentioned in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init (This patch is required for OMAP bootup w/ 20110115 linux-next) + DSS hwmod patch series: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42914.html changes since v1: added dummy clk patch for OMAP4. --- Archit Taneja (2): OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c Sumit Semwal (2): OMAP2PLUS: opt-clocks: align dss clock roles and names OMAP4: DSS2: clocks: Add ick as dummy clock arch/arm/mach-omap2/clock2420_data.c | 10 ++- arch/arm/mach-omap2/clock2430_data.c | 10 ++- arch/arm/mach-omap2/clock3xxx_data.c | 22 +++-- arch/arm/mach-omap2/clock44xx_data.c |9 ++- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +- drivers/video/omap2/dss/core.c |4 +- drivers/video/omap2/dss/dispc.c| 10 +- drivers/video/omap2/dss/dpi.c | 16 ++-- drivers/video/omap2/dss/dsi.c | 18 ++-- drivers/video/omap2/dss/dss.c | 144 ++-- drivers/video/omap2/dss/dss.h | 10 +- drivers/video/omap2/dss/manager.c |4 +- drivers/video/omap2/dss/overlay.c |4 +- drivers/video/omap2/dss/rfbi.c | 10 +- drivers/video/omap2/dss/sdi.c |8 +- drivers/video/omap2/dss/venc.c |8 +- 16 files changed, 156 insertions(+), 133 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] OMAP2PLUS: opt-clocks: align dss clock roles and names
opt clocks require (NULL, act-clock-name) as entries in clock database,
so that hwmod can replace it with (dev, role) tuple during hwmod data init.
These role names are aligned to be same across OMAP2420, 2430, 3xxx, 44xx
platforms, and also with dss clk handling code, so clk_get/put/enable/disable
APIs in dss can use uniform role names.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 10 +++---
arch/arm/mach-omap2/clock2430_data.c | 10 +++---
arch/arm/mach-omap2/clock3xxx_data.c | 22 +++---
arch/arm/mach-omap2/clock44xx_data.c |7 ++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
drivers/video/omap2/dss/dss.c |8
6 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d2abc2f..72a1872 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1787,9 +1787,13 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, gfx_ick, gfx_ick, CK_242X),
/* DSS domain clocks */
CLK(omap_dss, ick, dss_ick, CK_242X),
- CLK(omap_dss, dss1_fck, dss1_fck, CK_242X),
- CLK(omap_dss, dss2_fck, dss2_fck, CK_242X),
- CLK(omap_dss, tv_fck, dss_54m_fck, CK_242X),
+ CLK(omap_dss, fck, dss1_fck, CK_242X),
+ /*
+* clocks handled via hwmod opt_clk mechanism need dev=NULL,
+* con=clock name as per actual clk structure, NOT role
+*/
+ CLK(NULL, dss2_fck, dss2_fck, CK_242X),
+ CLK(NULL, dss_54m_fck, dss_54m_fck, CK_242X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_242X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 663f298..b99f881 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1891,9 +1891,13 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, mdm_osc_ck, mdm_osc_ck,CK_243X),
/* DSS domain clocks */
CLK(omap_dss, ick, dss_ick, CK_243X),
- CLK(omap_dss, dss1_fck, dss1_fck, CK_243X),
- CLK(omap_dss, dss2_fck, dss2_fck, CK_243X),
- CLK(omap_dss, tv_fck, dss_54m_fck, CK_243X),
+ CLK(omap_dss, fck, dss1_fck, CK_243X),
+ /*
+* clocks handled via hwmod opt_clk mechanism need dev=NULL,
+* con=clock name as per actual clk structure, NOT role
+*/
+ CLK(NULL, dss2_fck, dss2_fck, CK_243X),
+ CLK(NULL, dss_54m_fck, dss_54m_fck, CK_243X),
/* L3 domain clocks */
CLK(NULL, core_l3_ck, core_l3_ck,CK_243X),
CLK(NULL, ssi_fck, ssi_ssr_sst_fck, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 5c97b93..c32df5d 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3357,13 +3357,21 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_rng, ick, rng_ick, CK_34XX | CK_36XX),
CLK(NULL, sha11_ick,sha11_ick, CK_34XX | CK_36XX),
CLK(NULL, des1_ick, des1_ick, CK_34XX | CK_36XX),
- CLK(omap_dss, dss1_fck, dss1_alwon_fck_3430es1, CK_3430ES1),
- CLK(omap_dss, dss1_fck, dss1_alwon_fck_3430es2, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
- CLK(omap_dss, tv_fck, dss_tv_fck,CK_3XXX),
- CLK(omap_dss, video_fck,dss_96m_fck, CK_3XXX),
- CLK(omap_dss, dss2_fck, dss2_alwon_fck, CK_3XXX),
- CLK(omap_dss, ick, dss_ick_3430es1, CK_3430ES1),
- CLK(omap_dss, ick, dss_ick_3430es2, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ /* DSS clocks */
+ CLK(omap_dss, fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK(omap_dss, fck, dss1_alwon_fck_3430es2, CK_3430ES2PLUS
+ | CK_AM35XX),
+ CLK(omap_dss, ick, dss_ick_3430es1, CK_3430ES1),
+ CLK(omap_dss, ick, dss_ick_3430es2, CK_3430ES2PLUS
+ | CK_AM35XX),
+ /*
+* clocks handled via hwmod opt_clk mechanism need dev=NULL,
+* con=clock name as per actual clk structure, NOT role
+*/
+ CLK(NULL, dss_tv_fck, dss_tv_fck,CK_3XXX),
+ CLK(NULL, dss_96m_fck, dss_96m_fck, CK_3XXX),
+ CLK(NULL, dss2_alwon_fck, dss2_alwon_fck, CK_3XXX),
+
CLK(NULL, cam_mclk, cam_mclk, CK_34XX | CK_36XX),
CLK(NULL, cam_ick,
[PATCH v2 2/4] OMAP2PLUS: DSS2: Generalize naming of PRCM related clock enums in DSS driver
From: Archit Taneja arc...@ti.com
enum dss_clock structure is replaced with generic names that
could be used across OMAP2420, 2430, 3xxx, 44xx platforms.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/core.c|4 +-
drivers/video/omap2/dss/dispc.c | 10 +++---
drivers/video/omap2/dss/dpi.c | 16 +-
drivers/video/omap2/dss/dsi.c | 18 +-
drivers/video/omap2/dss/dss.c | 62 ++--
drivers/video/omap2/dss/dss.h | 10 +++---
drivers/video/omap2/dss/manager.c |4 +-
drivers/video/omap2/dss/overlay.c |4 +-
drivers/video/omap2/dss/rfbi.c| 10 +++---
drivers/video/omap2/dss/sdi.c |8 ++--
drivers/video/omap2/dss/venc.c|8 ++--
11 files changed, 77 insertions(+), 77 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 85add9c..3c4ad3a 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -184,7 +184,7 @@ static int omap_dss_probe(struct platform_device *pdev)
}
/* keep clocks enabled to prevent context saves/restores during init */
- dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
r = rfbi_init_platform_driver();
if (r) {
@@ -251,7 +251,7 @@ static int omap_dss_probe(struct platform_device *pdev)
pdata-default_device = dssdev;
}
- dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
return 0;
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 381942d..cc58208 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -551,9 +551,9 @@ void dispc_restore_context(void)
static inline void enable_clocks(bool enable)
{
if (enable)
- dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
else
- dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
}
bool dispc_go_busy(enum omap_channel channel)
@@ -2311,7 +2311,7 @@ unsigned long dispc_fclk_rate(void)
unsigned long r = 0;
if (dss_get_dispc_clk_source() == DSS_SRC_DSS1_ALWON_FCLK)
- r = dss_clk_get_rate(DSS_CLK_FCK1);
+ r = dss_clk_get_rate(DSS_CLK_FCK);
else
#ifdef CONFIG_OMAP2_DSS_DSI
r = dsi_get_dsi1_pll_rate();
@@ -2439,7 +2439,7 @@ void dispc_dump_regs(struct seq_file *s)
{
#define DUMPREG(r) seq_printf(s, %-35s %08x\n, #r, dispc_read_reg(r))
- dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
DUMPREG(DISPC_REVISION);
DUMPREG(DISPC_SYSCONFIG);
@@ -2596,7 +2596,7 @@ void dispc_dump_regs(struct seq_file *s)
DUMPREG(DISPC_VID_PRELOAD(0));
DUMPREG(DISPC_VID_PRELOAD(1));
- dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
#undef DUMPREG
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 75fb0a5..746f1b6 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -107,7 +107,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
bool is_tft;
int r = 0;
- dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
dispc_set_pol_freq(dssdev-manager-id, dssdev-panel.config,
dssdev-panel.acbi, dssdev-panel.acb);
@@ -137,7 +137,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
dispc_set_lcd_timings(dssdev-manager-id, t);
err0:
- dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
return r;
}
@@ -173,14 +173,14 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err1;
}
- dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK);
r = dpi_basic_init(dssdev);
if (r)
goto err2;
#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
- dss_clk_enable(DSS_CLK_FCK2);
+ dss_clk_enable(DSS_CLK_SYSCK);
r = dsi_pll_init(dssdev, 0, 1);
if (r)
goto err3;
@@ -199,10 +199,10 @@ err4:
#ifdef CONFIG_OMAP2_DSS_USE_DSI_PLL
dsi_pll_uninit();
err3:
- dss_clk_disable(DSS_CLK_FCK2);
+ dss_clk_disable(DSS_CLK_SYSCK);
#endif
err2:
- dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1);
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
if (cpu_is_omap34xx())
regulator_disable(dpi.vdds_dsi_reg);
err1:
@@ -219,10 +219,10 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
#ifdef
[PATCH v2 3/4] OMAP2PLUS: DSS2: Generalize external clock names in struct dss of dss.c
From: Archit Taneja arc...@ti.com
The dss struct in dss.c has omap2/3 specific clock names. Making them generic,
to increase readability and extendability.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss.c | 82
1 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 2873c30..c7cdbea 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -64,10 +64,10 @@ static struct {
struct clk *dpll4_m4_ck;
struct clk *dss_ick;
- struct clk *dss1_fck;
- struct clk *dss2_fck;
- struct clk *dss_54m_fck;
- struct clk *dss_96m_fck;
+ struct clk *dss_fck;
+ struct clk *dss_sys_clk;
+ struct clk *dss_tv_fck;
+ struct clk *dss_video_fck;
unsignednum_clks_enabled;
unsigned long cache_req_pck;
@@ -749,28 +749,28 @@ static int dss_get_clocks(void)
int r;
dss.dss_ick = NULL;
- dss.dss1_fck = NULL;
- dss.dss2_fck = NULL;
- dss.dss_54m_fck = NULL;
- dss.dss_96m_fck = NULL;
+ dss.dss_fck = NULL;
+ dss.dss_sys_clk = NULL;
+ dss.dss_tv_fck = NULL;
+ dss.dss_video_fck = NULL;
r = dss_get_clock(dss.dss_ick, ick);
if (r)
goto err;
- r = dss_get_clock(dss.dss1_fck, fck);
+ r = dss_get_clock(dss.dss_fck, fck);
if (r)
goto err;
- r = dss_get_clock(dss.dss2_fck, sys_clk);
+ r = dss_get_clock(dss.dss_sys_clk, sys_clk);
if (r)
goto err;
- r = dss_get_clock(dss.dss_54m_fck, tv_clk);
+ r = dss_get_clock(dss.dss_tv_fck, tv_clk);
if (r)
goto err;
- r = dss_get_clock(dss.dss_96m_fck, video_clk);
+ r = dss_get_clock(dss.dss_video_fck, video_clk);
if (r)
goto err;
@@ -779,25 +779,25 @@ static int dss_get_clocks(void)
err:
if (dss.dss_ick)
clk_put(dss.dss_ick);
- if (dss.dss1_fck)
- clk_put(dss.dss1_fck);
- if (dss.dss2_fck)
- clk_put(dss.dss2_fck);
- if (dss.dss_54m_fck)
- clk_put(dss.dss_54m_fck);
- if (dss.dss_96m_fck)
- clk_put(dss.dss_96m_fck);
+ if (dss.dss_fck)
+ clk_put(dss.dss_fck);
+ if (dss.dss_sys_clk)
+ clk_put(dss.dss_sys_clk);
+ if (dss.dss_tv_fck)
+ clk_put(dss.dss_tv_fck);
+ if (dss.dss_video_fck)
+ clk_put(dss.dss_video_fck);
return r;
}
static void dss_put_clocks(void)
{
- if (dss.dss_96m_fck)
- clk_put(dss.dss_96m_fck);
- clk_put(dss.dss_54m_fck);
- clk_put(dss.dss1_fck);
- clk_put(dss.dss2_fck);
+ if (dss.dss_video_fck)
+ clk_put(dss.dss_video_fck);
+ clk_put(dss.dss_tv_fck);
+ clk_put(dss.dss_fck);
+ clk_put(dss.dss_sys_clk);
clk_put(dss.dss_ick);
}
@@ -807,13 +807,13 @@ unsigned long dss_clk_get_rate(enum dss_clock clk)
case DSS_CLK_ICK:
return clk_get_rate(dss.dss_ick);
case DSS_CLK_FCK:
- return clk_get_rate(dss.dss1_fck);
+ return clk_get_rate(dss.dss_fck);
case DSS_CLK_SYSCK:
- return clk_get_rate(dss.dss2_fck);
+ return clk_get_rate(dss.dss_sys_clk);
case DSS_CLK_TVFCK:
- return clk_get_rate(dss.dss_54m_fck);
+ return clk_get_rate(dss.dss_tv_fck);
case DSS_CLK_VIDFCK:
- return clk_get_rate(dss.dss_96m_fck);
+ return clk_get_rate(dss.dss_video_fck);
}
BUG();
@@ -845,13 +845,13 @@ static void dss_clk_enable_no_ctx(enum dss_clock clks)
if (clks DSS_CLK_ICK)
clk_enable(dss.dss_ick);
if (clks DSS_CLK_FCK)
- clk_enable(dss.dss1_fck);
+ clk_enable(dss.dss_fck);
if (clks DSS_CLK_SYSCK)
- clk_enable(dss.dss2_fck);
+ clk_enable(dss.dss_sys_clk);
if (clks DSS_CLK_TVFCK)
- clk_enable(dss.dss_54m_fck);
+ clk_enable(dss.dss_tv_fck);
if (clks DSS_CLK_VIDFCK)
- clk_enable(dss.dss_96m_fck);
+ clk_enable(dss.dss_video_fck);
dss.num_clks_enabled += num_clks;
}
@@ -873,13 +873,13 @@ static void dss_clk_disable_no_ctx(enum dss_clock clks)
if (clks DSS_CLK_ICK)
clk_disable(dss.dss_ick);
if (clks DSS_CLK_FCK)
- clk_disable(dss.dss1_fck);
+ clk_disable(dss.dss_fck);
if (clks DSS_CLK_SYSCK)
- clk_disable(dss.dss2_fck);
+ clk_disable(dss.dss_sys_clk);
if (clks DSS_CLK_TVFCK)
-
[PATCH v2 4/4] OMAP4: DSS2: clocks: Add ick as dummy clock
DSS code uses ick as one of the clocks in clk_get/clk_put. OMAP4 clock database
doesn't have ick for DSS, so adding ick as dummy clock.
Once pm_runtime* APIs get introduced in DSS, this will be revisited.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 74db324..8603b1f 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3109,6 +3109,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
/* dss clocks */
CLK(NULL, fck, dss_fck,
CK_443X),
+ CLK(omap_dss, ick, dummy_ck,
CK_443X),
+ /* on OMAP4, ick is a dummy clock */
/*
* clocks handled via hwmod opt_clk mechanism need dev=NULL,
* con=clock name as per actual clk structure, NOT role
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Tue, Jan 25, 2011 at 12:56:56PM +, Russell King - ARM Linux wrote: On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote: Ok. I missed some information my last email. The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable. I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. Erm, I do hope that's not the case, as that means it is unsafe for CPUs in a SMP system to write to this register without them potentially trampling over each other. If it is the case, then the solutions are either: 1. Fix the hardware so that coherency requests only yet turned off when entering the WFI state. 2. Fix the hardware such that each CPU has a separate register. Actually, we can do this safely - byte stores are permitted to SCU registers probably for this very reason. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] ARM: scu: Move register defines to header file
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 6:27 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com; ccr...@android.com; linus.ml.wall...@gmail.com; linux- o...@vger.kernel.org Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote: Ok. I missed some information my last email. The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable. I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. Erm, I do hope that's not the case, as that means it is unsafe for CPUs in a SMP system to write to this register without them potentially trampling over each other. If it is the case, then the solutions are either: 1. Fix the hardware so that coherency requests only yet turned off when entering the WFI state. 2. Fix the hardware such that each CPU has a separate register. I can't see a software solution to this as we can't use ldrex/strex anything but memory regions, and memory regions without coherency won't work. Maybe ARM Support can help by suggesting how a 4-CPU system is supposed to safely read/modify/write the SCU power control register... On system wide suspend scenario's this is already handled because CPU's are taken down always sequentially. In CPU ILDE because of some other hardware restrictions we have it sequenced in 2 CPU system. CPU1 needs to be in OFF mode before any power management can be done on system along with master core. And that's how it is working without any races on OMAP Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Tue, Jan 25, 2011 at 01:04:22PM +, Russell King - ARM Linux wrote:
Actually, we can do this safely - byte stores are permitted to SCU
registers probably for this very reason.
3rd revision of the patch:
arch/arm/include/asm/smp_scu.h |5 +
arch/arm/kernel/smp_scu.c | 16
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/smp_scu.h b/arch/arm/include/asm/smp_scu.h
index 2376835..108f31d 100644
--- a/arch/arm/include/asm/smp_scu.h
+++ b/arch/arm/include/asm/smp_scu.h
@@ -1,7 +1,12 @@
#ifndef __ASMARM_ARCH_SCU_H
#define __ASMARM_ARCH_SCU_H
+#define SCU_PM_NORMAL 0
+#define SCU_PM_DORMANT 2
+#define SCU_PM_POWEROFF3
+
unsigned int scu_get_core_count(void __iomem *);
void scu_enable(void __iomem *);
+int scu_power_mode(unsigned int);
#endif
diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index 9ab4149..c956984 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -50,3 +50,19 @@ void __init scu_enable(void __iomem *scu_base)
*/
flush_cache_all();
}
+
+int scu_power_mode(unsigned int mode)
+{
+ unsigned int val;
+ int cpu = smp_processor_id();
+ int shift;
+
+ if (mode 3 || mode == 1 || cpu 3)
+ return -EINVAL;
+
+ val = __raw_readb(scu_base + SCU_CPU_STATUS + cpu) ~0x03;
+ val |= mode;
+ __raw_writeb(val, scu_base + SCU_CPU_STATUS + cpu);
+
+ return 0;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
In CPU low power state, local timer looses its register context. This
patch adds context save restore hooks which can be used by platforms
appropriately.
I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
timer stuff wouldn't rely on it being kept alive?
Hmm, it looks like we bypass the clockevents code by only setting the
TWD load value at initialization time, not when we switch to periodic
mode. We really ought to rewrite it whenever we switch back to periodic
mode.
I suspect fixing that means you won't need this save/restore support.
Untested, but should do what's required.
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index fd91566..60636f4 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
/* timer load already set up */
ctrl = TWD_TIMER_CONTROL_ENABLE |
TWD_TIMER_CONTROL_IT_ENABLE
| TWD_TIMER_CONTROL_PERIODIC;
+ __raw_writel(twd_timer_rate / HZ, twd_base +
TWD_TIMER_LOAD);
break;
case CLOCK_EVT_MODE_ONESHOT:
/* period set, and timer enabled in 'next_event' hook */
@@ -81,7 +82,7 @@ int twd_timer_ack(void)
static void __cpuinit twd_calibrate_rate(void)
{
- unsigned long load, count;
+ unsigned long count;
u64 waitjiffies;
/*
@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
printk(%lu.%02luMHz.\n, twd_timer_rate / 100,
(twd_timer_rate / 100) % 100);
}
-
- load = twd_timer_rate / HZ;
-
- __raw_writel(load, twd_base + TWD_TIMER_LOAD);
}
/*
This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register
gets reset by cpu idle between twd_set_mode and twd_set_next_event.
Shadowing ctrl in a percpu variable and rewriting it during every call
to twd_set_next_event does work, but that's not much different, and a
little less efficient, than just saving and restoring the control and
load registers in idle. It does have the advantage that platforms
don't need any extra calls.
The next question is can we teach the generic time infrastructure about
this so we don't have to modify every clock event driver for it? We
really need to get away from having this kind of knowledge buried down
in the lowest levels of every driver.
In which way? I mean the generic code issues a call to the set_mode
function when we leave the broadcast mode. So what should the generic
code do more ?
Thanks,
tglx
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote:
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux
wrote:
On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
In CPU low power state, local timer looses its register context. This
patch adds context save restore hooks which can be used by platforms
appropriately.
I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
timer stuff wouldn't rely on it being kept alive?
Hmm, it looks like we bypass the clockevents code by only setting the
TWD load value at initialization time, not when we switch to periodic
mode. We really ought to rewrite it whenever we switch back to
periodic
mode.
I suspect fixing that means you won't need this save/restore support.
Untested, but should do what's required.
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index fd91566..60636f4 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
/* timer load already set up */
ctrl = TWD_TIMER_CONTROL_ENABLE |
TWD_TIMER_CONTROL_IT_ENABLE
| TWD_TIMER_CONTROL_PERIODIC;
+ __raw_writel(twd_timer_rate / HZ, twd_base +
TWD_TIMER_LOAD);
break;
case CLOCK_EVT_MODE_ONESHOT:
/* period set, and timer enabled in 'next_event' hook */
@@ -81,7 +82,7 @@ int twd_timer_ack(void)
static void __cpuinit twd_calibrate_rate(void)
{
- unsigned long load, count;
+ unsigned long count;
u64 waitjiffies;
/*
@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
printk(%lu.%02luMHz.\n, twd_timer_rate / 100,
(twd_timer_rate / 100) % 100);
}
-
- load = twd_timer_rate / HZ;
-
- __raw_writel(load, twd_base + TWD_TIMER_LOAD);
}
/*
This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register
gets reset by cpu idle between twd_set_mode and twd_set_next_event.
Shadowing ctrl in a percpu variable and rewriting it during every call
to twd_set_next_event does work, but that's not much different, and a
little less efficient, than just saving and restoring the control and
load registers in idle. It does have the advantage that platforms
don't need any extra calls.
The next question is can we teach the generic time infrastructure about
this so we don't have to modify every clock event driver for it? We
really need to get away from having this kind of knowledge buried down
in the lowest levels of every driver.
In which way? I mean the generic code issues a call to the set_mode
function when we leave the broadcast mode. So what should the generic
code do more ?
I can't say because these patches only add the hooks, there's no
implementation yet which uses the hooks.
Given the description about _why_ those hooks are necessary, it seems
that something is required. Either we start adding custom hacks to
each clockevent driver as is done with this patch, or we get some
generic help in place.
I'm not thrilled by the custom hack approach - and I thought the
clockevent stuff was created to stop this kind of thing happening.
I suggest we defer this until there's a visible use case available.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: scu: Move register defines to header file
On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote: Ok. I missed some information my last email. The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable. I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. The programming happens from IDLE or suspend where the BTW, presumably we should be flushing the caches/tlbs before setting the CPU power register to a non-normal setting? I'll wait until there's more information available (such as an example implementation.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] ARM: scu: Move register defines to header file
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 7:11 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; catalin.mari...@arm.com; ccr...@android.com; linus.ml.wall...@gmail.com; linux- o...@vger.kernel.org Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote: Ok. I missed some information my last email. The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable. I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. The programming happens from IDLE or suspend where the BTW, presumably we should be flushing the caches/tlbs before setting the CPU power register to a non-normal setting? Yes but only till inner shareability domain. i.e L1 L2 will be flushed after this. This is one more issue where the current L2 cache current APIs(use locks) becomes not so suitable. I'll wait until there's more information available (such as an example implementation.) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/32] arm/omap: use system_wq in mailbox
On Tue, Jan 04, 2011 at 06:24:21AM +0100, Tejun Heo wrote: Using dedicated workqueue or system_wq doesn't make any difference in terms of execution latency anymore. Sleeping work items no longer delay execution of other work items. If mailbox is very latency sensitive, it might make sense to create a HIGHPRI workqueue but that usually isn't necessary. Ping. Shall I apply the patch? Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] ARM: twd: Add context save restore support
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 7:08 PM To: Thomas Gleixner Cc: Colin Cross; Santosh Shilimkar; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote: On Tue, 25 Jan 2011, Russell King - ARM Linux wrote: [...] The next question is can we teach the generic time infrastructure about this so we don't have to modify every clock event driver for it? We really need to get away from having this kind of knowledge buried down in the lowest levels of every driver. In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ? I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks. Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place. I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening. I suggest we defer this until there's a visible use case available. Just for clarification. Without the TWD save restore patch the PM won't work. So what you mean by visible usecase. We need this to be fixed and that's what was done with the my patch. Ofcourse it's a custom hack approach but does the job. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Tue, Jan 25, 2011 at 01:57:26PM -, Will Deacon wrote: Hi Russell, Hopefully this isn't too late to be useful. On Mon, Jan 17, 2011 at 07:21:40PM +, Russell King - ARM Linux wrote: Switch the set/clear/change bitops to use the word-based exclusive operations, which are only present in a wider range of ARM architectures than the byte-based exclusive operations. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk As only one person replied to this patch with test information, I'm not happy to push this into -rc, and hence that prevents it going into -stable too. That means omap2plus_defconfig .38 mainline kernels (including -stable) will remain potentially dangerous when run on SMP capable hardware. Therefore, I see no alternative at the moment but to purposely cause builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from data corruption. Please get your tested-by's to me for at least the first three patches of this series ASAP. I've tested this on the Versatile Express (ca9x4, little endian) with a USB hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB file containing random data whilst the system was fairly loaded. File checksums all passed and the kernel didn't do anything untowards. Tested-by: Will Deacon will.dea...@arm.com I appreciate this is the same test configuration as the one Nicolas did, but it at least replicates his findings. Was this for just the first three or the complete set? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote: On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote: In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ? I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks. Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place. I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening. Yes, and it does the right thing: idle enter (where the cpu local tick device stops) tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_ENTER) clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN) tick_broadcast_set_event(dev-next_event, 1) idle exit tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_EXIT) clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT) tick_program_event(dev-next_event, 1) So the generic code has all the calls in place. If a clock chip implementation misses to set control registers in the CLOCK_EVT_MODE_ONESHOT case, then it's not a short coming of the generic code which needs magic hooks in the arch code. The same applies for the periodic mode switch, which is handled via tick_broadcast_on_off(). Am I missing something ? Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, Jan 25, 2011 at 03:12:24PM +0100, Thomas Gleixner wrote:
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote:
In which way? I mean the generic code issues a call to the set_mode
function when we leave the broadcast mode. So what should the generic
code do more ?
I can't say because these patches only add the hooks, there's no
implementation yet which uses the hooks.
Given the description about _why_ those hooks are necessary, it seems
that something is required. Either we start adding custom hacks to
each clockevent driver as is done with this patch, or we get some
generic help in place.
I'm not thrilled by the custom hack approach - and I thought the
clockevent stuff was created to stop this kind of thing happening.
Yes, and it does the right thing:
idle enter (where the cpu local tick device stops)
tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)
clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN)
tick_broadcast_set_event(dev-next_event, 1)
idle exit
tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_EXIT)
clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT)
tick_program_event(dev-next_event, 1)
So the generic code has all the calls in place. If a clock chip
implementation misses to set control registers in the
CLOCK_EVT_MODE_ONESHOT case, then it's not a short coming of the
generic code which needs magic hooks in the arch code.
The same applies for the periodic mode switch, which is handled via
tick_broadcast_on_off().
Am I missing something ?
I quote Colin:
| This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register
| gets reset by cpu idle between twd_set_mode and twd_set_next_event.
I quote the code:
static void twd_set_mode(enum clock_event_mode mode,
struct clock_event_device *clk)
{
unsigned long ctrl;
switch (mode) {
case CLOCK_EVT_MODE_PERIODIC:
/* timer load already set up */
ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE
| TWD_TIMER_CONTROL_PERIODIC;
break;
case CLOCK_EVT_MODE_ONESHOT:
/* period set, and timer enabled in 'next_event' hook */
ctrl = TWD_TIMER_CONTROL_IT_ENABLE | TWD_TIMER_CONTROL_ONESHOT;
break;
case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
default:
ctrl = 0;
}
__raw_writel(ctrl, twd_base + TWD_TIMER_CONTROL);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote: On Tue, Jan 25, 2011 at 03:12:24PM +0100, Thomas Gleixner wrote: On Tue, 25 Jan 2011, Russell King - ARM Linux wrote: On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote: In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ? I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks. Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place. I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening. Yes, and it does the right thing: idle enter (where the cpu local tick device stops) tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_ENTER) clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN) tick_broadcast_set_event(dev-next_event, 1) idle exit tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_EXIT) clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT) tick_program_event(dev-next_event, 1) So the generic code has all the calls in place. If a clock chip implementation misses to set control registers in the CLOCK_EVT_MODE_ONESHOT case, then it's not a short coming of the generic code which needs magic hooks in the arch code. The same applies for the periodic mode switch, which is handled via tick_broadcast_on_off(). Am I missing something ? I quote Colin: | This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register | gets reset by cpu idle between twd_set_mode and twd_set_next_event. And I fear that he means the twd_set_mode(ONESHOT) call which happens during boot/cpuonline. The point is that the above function needs to be called from the cpu idle code to notify the clock events layer. The correct mechanism is clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT). The existing callers are in: arch/x86/kernel/process.c drivers/acpi/acpi_pad.c drivers/acpi/processor_idle.c drivers/idle/intel_idle.c So i'm not surprised, that this wont work on ARM :) Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init
-Original Message- From: Hilman, Kevin Sent: Tuesday, January 25, 2011 2:52 AM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org; Varadarajan, Charulatha; t...@atomide.com Subject: Re: [PATCH] OMAP3EVM:FIX: Reset the SMSC911x Ethernet controller in board_init Hiremath, Vaibhav hvaib...@ti.com writes: With addition of HWMOD support to GPIO, the Ethernet controller goes undetected for OMAP35xEVM. So explicitely assert the reset signal to Ethernet controller smsc911x - - GPIO7 (=RevG version of EVM's) - GPIO64 (=RevD version of EVM's) I have tested this patch on RevG version of EVM with ES3.1 Si. This patch is based on intial version from Charulatha V. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com This didn't apply cleanly to l-o master, with or without your previous patches which touch the EVM board file. [Hiremath, Vaibhav] may be order in which you apply the patches is different, but should have been trivial to fix, right? I would suggest you to use newer version. The order of applying doesn't matter. Applying the original patch alone didn't apply, applying it after the other didn't apply. V2 doesn't apply cleanly either. [Hiremath, Vaibhav] Kevin, I just started with your note, so that this patch gets applied cleanly and I found that V2 gets applied cleanly on top of below base commit. I just did cherry-pick, and it worked for me cleanly. Other patches I will bundle into series and post it again. Thanks, Vaibhav Please be sure it applies cleanly to: commit 5b698d68c1a9ebeae76a0e4ca4dbfdb10357143d Author: Thomas Weber we...@corscience.de Date: Thu Jan 20 14:12:11 2011 + omap: omap-mcbsp: Fix building after replacement Fix building omap-mcbsp after replacing ARCH_OMAP24x0 in commit 8a9c1aa6a4caa7db1c2fca4b47168af9077e0f95. If your series of EVM patches are interdependent, I suggest sending them as a series, so it's clear that they are dependent on each other. Also, please Cc linux-arm-kernel on OMAP patches intended for upstream. This one (network GPIO) should be separated out though, and go into .38-rc (as well as -stable) since omap3evm is has not been bootable since 2.6.37. --- NOTE: I have not been able to test it on older version of EVM's. After manually applying, Tested-by: Kevin Hilman khil...@ti.com I tested on my rev D board with DHCP + nfs rootfs and it's working well. [Hiremath, Vaibhav] Thanks a lot for validating it. While testing though, I also noticed that the smsc driver is dumping some warnings (below) while trying to get the MAC address, resulting in not using the actual MAC but generating a random one. This isn't related to your patch, since it also happens with l-o master, but was wondering if you saw the same thing? [Hiremath, Vaibhav] Yes I did see this message, and this is coming from #ifdef CONFIG_DEBUG_SPINLOCK #define SMSC_ASSERT_MAC_LOCK(pdata) \ WARN_ON(!spin_is_locked(pdata-mac_lock)) And the root-cause is, in __init function we are calling smsc911x_read_mac_address-smsc911x_mac_read without holding mac_lock. I will submit the patch to net mailing list for this. Thanks, please Cc linux-omap as well. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller in board_init
With addition of hwmod support to gpio, the ethernet controller
goes undetected for OMAP35xEVM. So explicitly assert the reset signal to
ethernet controller smsc911x -
- GPIO7 (=RevG version of EVM's)
- GPIO64 (=RevD version of EVM's)
This patch is based on intial version from Charulatha V, reference
to original discussion -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35784.html
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
---
Since Kevin reported that this patch doesn't get applied cleanly,
so I am reposting it again after making sure that it gets applied cleanly.
arch/arm/mach-omap2/board-omap3evm.c | 39 +-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 323c380..97e0f65 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -58,6 +58,13 @@
#define OMAP3EVM_ETHR_ID_REV 0x50
#define OMAP3EVM_ETHR_GPIO_IRQ 176
#define OMAP3EVM_SMSC911X_CS 5
+/*
+ * Eth Reset signal
+ * 64 = Generation 1 (=RevD)
+ * 7 = Generation 2 (=RevE)
+ */
+#define OMAP3EVM_GEN1_ETHR_GPIO_RST64
+#define OMAP3EVM_GEN2_ETHR_GPIO_RST7
static u8 omap3_evm_version;
@@ -124,10 +131,15 @@ static struct platform_device omap3evm_smsc911x_device = {
static inline void __init omap3evm_init_smsc911x(void)
{
- int eth_cs;
+ int eth_cs, eth_rst;
struct clk *l3ck;
unsigned int rate;
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
+ eth_rst = OMAP3EVM_GEN1_ETHR_GPIO_RST;
+ else
+ eth_rst = OMAP3EVM_GEN2_ETHR_GPIO_RST;
+
eth_cs = OMAP3EVM_SMSC911X_CS;
l3ck = clk_get(NULL, l3_ck);
@@ -136,6 +148,27 @@ static inline void __init omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+ /* Configure ethernet controller reset gpio */
+ if (cpu_is_omap3430()) {
+ if (gpio_request(eth_rst, SMSC911x gpio) 0) {
+ pr_err(KERN_ERR Failed to request %d for smsc911x\n,
+ eth_rst);
+ return;
+ }
+
+ if (gpio_direction_output(eth_rst, 1) 0) {
+ pr_err(KERN_ERR Failed to set direction of %d for \
+smsc911x\n, eth_rst);
+ return;
+ }
+ /* reset pulse to ethernet controller*/
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 0);
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 1);
+ usleep_range(1, 2);
+ }
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, SMSC911x irq) 0) {
printk(KERN_ERR Failed to request GPIO%d for smsc911x IRQ\n,
OMAP3EVM_ETHR_GPIO_IRQ);
@@ -658,6 +691,10 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[query] smartreflex: No PMIC hook to init smartreflex
Hi, While building the kernel at 2.6.37, i see this warning for omap3evm - with omap3630: Power Management for TI OMAP3. sr_init: No PMIC hook to init smartreflex -- THIS IS THE WARNING. smartreflex smartreflex.0: omap_sr_probe: SmartReflex driver initialized smartreflex smartreflex.1: omap_sr_probe: SmartReflex driver initialized SmartReflex Class3 initialized In the code, i see this comment: /* * sr_init is a late init. If by then a pmic specific API is not * registered either there is no need for anything to be done on * the PMIC side or somebody has forgotten to register a PMIC * handler. Warn for the second condition. */ if (sr_pmic_data sr_pmic_data-sr_pmic_init) sr_pmic_data-sr_pmic_init(); else pr_warning(%s: No PMIC hook to init smartreflex\n, __func__); But, I couldn't find any place where PMIC is being registered. premi # grep register_pmic *.c omap_twl.c: omap_voltage_register_pmic(voltdm, omap4_mpu_volt_info); omap_twl.c: omap_voltage_register_pmic(voltdm, omap4_iva_volt_info); omap_twl.c: omap_voltage_register_pmic(voltdm, omap4_core_volt_info); omap_twl.c: omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info); omap_twl.c: omap_voltage_register_pmic(voltdm, omap3_core_volt_info); smartreflex.c: * omap_sr_register_pmic() - API to register pmic specific info. smartreflex.c:void omap_sr_register_pmic(struct omap_sr_pmic_data *pmic_data) voltage.c: * omap_voltage_register_pmic() - API to register PMIC specific data voltage.c:int omap_voltage_register_pmic(struct voltagedomain *voltdm, Where can I look for an example of registration? ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP3EVM:FIX: Reset the smsc911x ethernet controller in board_init
-Original Message-
From: Hiremath, Vaibhav
Sent: Tuesday, January 25, 2011 8:53 PM
To: linux-omap@vger.kernel.org
Cc: Hiremath, Vaibhav; Varadarajan, Charulatha
Subject: [PATCH-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller
in board_init
With addition of hwmod support to gpio, the ethernet controller
goes undetected for OMAP35xEVM. So explicitly assert the reset signal to
ethernet controller smsc911x -
- GPIO7 (=RevG version of EVM's)
- GPIO64 (=RevD version of EVM's)
This patch is based on intial version from Charulatha V, reference
to original discussion -
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg35784.html
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
---
Since Kevin reported that this patch doesn't get applied cleanly,
so I am reposting it again after making sure that it gets applied cleanly.
[Hiremath, Vaibhav] Oops, missed linux-arm-kernel list, adding here.
Not sure whether I need to repost keeping linux-arm-kernel?
Thanks,
Vaibhav
arch/arm/mach-omap2/board-omap3evm.c | 39
+-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index 323c380..97e0f65 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -58,6 +58,13 @@
#define OMAP3EVM_ETHR_ID_REV 0x50
#define OMAP3EVM_ETHR_GPIO_IRQ 176
#define OMAP3EVM_SMSC911X_CS 5
+/*
+ * Eth Reset signal
+ * 64 = Generation 1 (=RevD)
+ * 7 = Generation 2 (=RevE)
+ */
+#define OMAP3EVM_GEN1_ETHR_GPIO_RST 64
+#define OMAP3EVM_GEN2_ETHR_GPIO_RST 7
static u8 omap3_evm_version;
@@ -124,10 +131,15 @@ static struct platform_device
omap3evm_smsc911x_device = {
static inline void __init omap3evm_init_smsc911x(void)
{
- int eth_cs;
+ int eth_cs, eth_rst;
struct clk *l3ck;
unsigned int rate;
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
+ eth_rst = OMAP3EVM_GEN1_ETHR_GPIO_RST;
+ else
+ eth_rst = OMAP3EVM_GEN2_ETHR_GPIO_RST;
+
eth_cs = OMAP3EVM_SMSC911X_CS;
l3ck = clk_get(NULL, l3_ck);
@@ -136,6 +148,27 @@ static inline void __init
omap3evm_init_smsc911x(void)
else
rate = clk_get_rate(l3ck);
+ /* Configure ethernet controller reset gpio */
+ if (cpu_is_omap3430()) {
+ if (gpio_request(eth_rst, SMSC911x gpio) 0) {
+ pr_err(KERN_ERR Failed to request %d for smsc911x\n,
+ eth_rst);
+ return;
+ }
+
+ if (gpio_direction_output(eth_rst, 1) 0) {
+ pr_err(KERN_ERR Failed to set direction of %d for \
+ smsc911x\n, eth_rst);
+ return;
+ }
+ /* reset pulse to ethernet controller*/
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 0);
+ usleep_range(150, 220);
+ gpio_set_value(eth_rst, 1);
+ usleep_range(1, 2);
+ }
+
if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, SMSC911x irq) 0) {
printk(KERN_ERR Failed to request GPIO%d for smsc911x IRQ\n,
OMAP3EVM_ETHR_GPIO_IRQ);
@@ -658,6 +691,10 @@ static struct omap_board_mux board_mux[] __initdata =
{
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_NONE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/32] arm/omap: use system_wq in mailbox
Tejun, On Tue, Jan 25, 2011 at 5:47 AM, Tejun Heo t...@kernel.org wrote: On Tue, Jan 04, 2011 at 06:24:21AM +0100, Tejun Heo wrote: Using dedicated workqueue or system_wq doesn't make any difference in terms of execution latency anymore. Sleeping work items no longer delay execution of other work items. If mailbox is very latency sensitive, it might make sense to create a HIGHPRI workqueue but that usually isn't necessary. Ping. Shall I apply the patch? I am sorry for the delay in acking your response. Your patch looks good to me. thank you, best regards, Hari -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/32] arm/omap: use system_wq in mailbox
On Tue, Jan 25, 2011 at 07:34:08AM -0800, Hari Kanigeri wrote: Tejun, On Tue, Jan 25, 2011 at 5:47 AM, Tejun Heo t...@kernel.org wrote: On Tue, Jan 04, 2011 at 06:24:21AM +0100, Tejun Heo wrote: Using dedicated workqueue or system_wq doesn't make any difference in terms of execution latency anymore. Sleeping work items no longer delay execution of other work items. If mailbox is very latency sensitive, it might make sense to create a HIGHPRI workqueue but that usually isn't necessary. Ping. Shall I apply the patch? I am sorry for the delay in acking your response. Your patch looks good to me. Thanks. Acked-by added. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: OMAP2: use early init hook
On Tue, Jan 25, 2011 at 1:47 AM, Tony Lindgren t...@atomide.com wrote:
* Russell King - ARM Linux li...@arm.linux.org.uk [110123 09:47]:
On Sun, Jan 23, 2011 at 05:13:44PM +, Russell King - ARM Linux wrote:
Move non-mapping and non-irq initialization code out of .map_io and
.init_irq respectively into the new init_early hook.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
I think I've updated this patch correctly for the new platforms merged
into mainline.
Grr, this breaks on OMAP because some of this stuff wants to do ioremap()
and therefore wants the kmem allocators initialized. That's rather
annoying...
So far tested on zoom3 only, but the following gets it booting
on top of your patch.
Want to take this one into your series?
Meanwhile, I'll add these both into our omap-testing branch
for some more testing.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Mon, 24 Jan 2011 11:56:37 -0800
Subject: [PATCH] omap2+: Fix omap_serial_early_init to work with init_early
hook
The new init_early hook happens at the end of setup_arch,
which is too early for kzalloc. However, there's no need
to call omap_serial_early_init that early, so fix this
by setting it up as a subsys_initcall.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -400,8 +400,6 @@ void __init omap2_init_common_infrastructure(void)
void __init omap2_init_common_devices(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
- omap_serial_early_init();
-
omap_hwmod_late_init();
if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -655,7 +655,7 @@ static void serial_out_override(struct uart_port *up, int
offset, int value)
}
#endif
-void __init omap_serial_early_init(void)
+static int __init omap_serial_early_init(void)
{
int i = 0;
@@ -691,7 +691,10 @@ void __init omap_serial_early_init(void)
*/
uart-oh-flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
} while (1);
+
+ return 0;
}
+subsys_initcall(omap_serial_early_init);
/**
* omap_serial_init_port() - initialize single serial port
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -96,7 +96,6 @@
struct omap_board_data;
-extern void __init omap_serial_early_init(void);
extern void omap_serial_init(void);
extern void omap_serial_init_port(struct omap_board_data *bdata);
extern int omap_uart_can_sleep(void);
--
Just FYI, I observed similar results on OMAP4 for these patches.
For OMAP2420, OMAP2430 and OMAP3430 SDPs, you can add my boot
Tested-by: Sourav Poddarsourav.pod...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/3] OMAP3: PM: Fix CLK_SRC mask for IVA2 and MPU on 3430ES2PLUS
Rajendra Nayak rna...@ti.com writes:
Hi Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Tuesday, January 25, 2011 3:39 AM
To: Rajendra Nayak
Cc: linux-omap@vger.kernel.org; p...@pwsan.com
Subject: Re: [RFC 2/3] OMAP3: PM: Fix CLK_SRC mask for IVA2 and MPU on
3430ES2PLUS
Rajendra Nayak rna...@ti.com writes:
The IVA2_CLK_SRC and MPU_CLK_SRC for OMAP3430 ES2
and above are 3 bit fields.
Define new masks for them, and since they are used
in a couple of clock nodes, model separate clock
nodes for 3430ES1 and 3430ES2+.
This part should probably be separated out as a fix for the -rc cycle.
The reason I clubbed this fix here was because it had a dependency on the
'reference by name' approach added by the previous patch.
Else I was looking at creating too many duplicate nodes, since the clock
nodes which get added in this patch (dpll1_fck_3430es2/dpll2_fck_3430es2)
are part of dpll_data.
OK, thanks for the clarifiation. Might help to add that bit of
description in the changelog, or after the '---' for the sake of
reviewers.
Thanks,
Kevin
Kevin
Also change reference to these new clock nodes
from clk pointers to clk name and make a call
to omap_init_clk_pts to init the pointers at
run time.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 39
++--
arch/arm/mach-omap2/cm-regbits-34xx.h |2 +
2 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 9c87adb..c3a7ff5 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -53,10 +53,6 @@
* DPLL5 supplies other peripheral clocks (USBHOST, USIM).
*/
-/* Forward declarations for DPLL bypass clocks */
-static struct clk dpll1_fck;
-static struct clk dpll2_fck;
-
/* PRM CLOCKS */
/* According to timer32k.c, this is a 32768Hz clock, not a 32000Hz
clock. */
@@ -275,7 +271,7 @@ static struct dpll_data dpll1_dd = {
.mult_div1_reg = OMAP_CM_REGADDR(MPU_MOD,
OMAP3430_CM_CLKSEL1_PLL),
.mult_mask = OMAP3430_MPU_DPLL_MULT_MASK,
.div1_mask = OMAP3430_MPU_DPLL_DIV_MASK,
- .clk_bypass = dpll1_fck,
+ .clk_bypass_name= dpll1_fck,
.clk_ref= sys_ck,
.freqsel_mask = OMAP3430_MPU_DPLL_FREQSEL_MASK,
.control_reg= OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKEN_PLL),
@@ -347,7 +343,7 @@ static struct dpll_data dpll2_dd = {
.mult_div1_reg = OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
OMAP3430_CM_CLKSEL1_PLL),
.mult_mask = OMAP3430_IVA2_DPLL_MULT_MASK,
.div1_mask = OMAP3430_IVA2_DPLL_DIV_MASK,
- .clk_bypass = dpll2_fck,
+ .clk_bypass_name= dpll2_fck,
.clk_ref= sys_ck,
.freqsel_mask = OMAP3430_IVA2_DPLL_FREQSEL_MASK,
.control_reg= OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
OMAP3430_CM_CLKEN_PLL),
@@ -1077,6 +1073,17 @@ static struct clk dpll1_fck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk dpll1_fck_3430es2 = {
+ .name = dpll1_fck,
+ .ops= clkops_null,
+ .parent = core_ck,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP_CM_REGADDR(MPU_MOD,
OMAP3430_CM_CLKSEL1_PLL),
+ .clksel_mask= OMAP3430ES2_MPU_CLK_SRC_MASK,
+ .clksel = div4_core_clksel,
+ .recalc = omap2_clksel_recalc,
+};
+
static struct clk mpu_ck = {
.name = mpu_ck,
.ops= clkops_null,
@@ -1133,6 +1140,17 @@ static struct clk dpll2_fck = {
.recalc = omap2_clksel_recalc,
};
+static struct clk dpll2_fck_3430es2 = {
+ .name = dpll2_fck,
+ .ops= clkops_null,
+ .parent = core_ck,
+ .init = omap2_init_clksel_parent,
+ .clksel_reg = OMAP_CM_REGADDR(OMAP3430_IVA2_MOD,
OMAP3430_CM_CLKSEL1_PLL),
+ .clksel_mask= OMAP3430ES2_IVA2_CLK_SRC_MASK,
+ .clksel = div4_core_clksel,
+ .recalc = omap2_clksel_recalc,
+};
+
static struct clk iva2_ck = {
.name = iva2_ck,
.ops= clkops_omap2_dflt_wait,
@@ -3261,11 +3279,13 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, clkout2_src_ck, clkout2_src_ck, CK_3XXX),
CLK(NULL, sys_clkout2, sys_clkout2, CK_3XXX),
CLK(NULL, corex2_fck, corex2_fck,CK_3XXX),
- CLK(NULL, dpll1_fck,dpll1_fck, CK_3XXX),
+ CLK(NULL, dpll1_fck,dpll1_fck, CK_3430ES1),
+ CLK(NULL, dpll1_fck,dpll1_fck_3430es2,
CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
CLK(NULL, mpu_ck, mpu_ck,CK_3XXX),
CLK(NULL, arm_fck, arm_fck, CK_3XXX),
CLK(etb, emu_mpu_alwon_ck, emu_mpu_alwon_ck, CK_3XXX),
- CLK(NULL, dpll2_fck,dpll2_fck,
RE: [PATCH 3/5] ARM: twd: Add context save restore support
Russell, Thomas
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 7:08 PM
To: Thomas Gleixner
Cc: Colin Cross; Santosh Shilimkar; catalin.mari...@arm.com;
linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support
[...]
I can't say because these patches only add the hooks, there's no
implementation yet which uses the hooks.
Given the description about _why_ those hooks are necessary, it
seems
that something is required. Either we start adding custom hacks to
each clockevent driver as is done with this patch, or we get some
generic help in place.
I'm not thrilled by the custom hack approach - and I thought the
clockevent stuff was created to stop this kind of thing happening.
I suggest we defer this until there's a visible use case available.
Got some time to debug this issue. OMAP idle code already has the
broad-cast notifiers working for sometime. So I removed the existing
save restore twd code and just used the below patch which Russell
posted on this thread.
And things just work and I guess we are done with this issue !!
Timer framework is doing all right things with notifiers.
Am going to use this patch for my further work and drop the
save/restore patch. Will update you if there is any other
issue on this. I should have validated this patch on my own
earlier :(
Thanks for the discussion.
-
From 9084dd3e68a8528172d97fb49c42437ae873af43 Mon Sep 17 00:00:00 2001
From: Russell King rmk+ker...@arm.linux.org.uk
Date: Tue, 25 Jan 2011 14:26:41 +0530
Subject: [PATCH] ARM: smp_twd: Always program the loadvalue when switching
to periodic mode.
Always program the load value when switching to periodic mode so that
we don't need to save restore twd load register.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/kernel/smp_twd.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index fd91566..60636f4 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,
/* timer load already set up */
ctrl = TWD_TIMER_CONTROL_ENABLE |
TWD_TIMER_CONTROL_IT_ENABLE
| TWD_TIMER_CONTROL_PERIODIC;
+ __raw_writel(twd_timer_rate / HZ, twd_base +
TWD_TIMER_LOAD);
break;
case CLOCK_EVT_MODE_ONESHOT:
/* period set, and timer enabled in 'next_event' hook */
@@ -81,7 +82,7 @@ int twd_timer_ack(void)
static void __cpuinit twd_calibrate_rate(void)
{
- unsigned long load, count;
+ unsigned long count;
u64 waitjiffies;
/*
@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
printk(%lu.%02luMHz.\n, twd_timer_rate / 100,
(twd_timer_rate / 100) % 100);
}
-
- load = twd_timer_rate / HZ;
-
- __raw_writel(load, twd_base + TWD_TIMER_LOAD);
}
/*
--
1.6.0.4
0001-ARM-smp_twd-Always-program-the-loadvalue-when-swit.patch
Description: Binary data
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, Jan 25, 2011 at 09:34:15PM +0530, Santosh Shilimkar wrote: Russell, Thomas -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 7:08 PM To: Thomas Gleixner Cc: Colin Cross; Santosh Shilimkar; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support [...] I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks. Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place. I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening. I suggest we defer this until there's a visible use case available. Got some time to debug this issue. OMAP idle code already has the broad-cast notifiers working for sometime. So I removed the existing save restore twd code and just used the below patch which Russell posted on this thread. And things just work and I guess we are done with this issue !! Timer framework is doing all right things with notifiers. Am going to use this patch for my further work and drop the save/restore patch. Will update you if there is any other issue on this. I should have validated this patch on my own earlier :( Thanks for the discussion. Thanks - I guess that's a tested-by then? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] ARM: twd: Add context save restore support
-Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 9:43 PM To: Santosh Shilimkar Cc: Thomas Gleixner; Colin Cross; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support On Tue, Jan 25, 2011 at 09:34:15PM +0530, Santosh Shilimkar wrote: Russell, Thomas -Original Message- From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Tuesday, January 25, 2011 7:08 PM To: Thomas Gleixner Cc: Colin Cross; Santosh Shilimkar; catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-omap@vger.kernel.org; linux- arm- ker...@lists.infradead.org Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support [...] I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks. Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place. I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening. I suggest we defer this until there's a visible use case available. Got some time to debug this issue. OMAP idle code already has the broad-cast notifiers working for sometime. So I removed the existing save restore twd code and just used the below patch which Russell posted on this thread. And things just work and I guess we are done with this issue !! Timer framework is doing all right things with notifiers. Am going to use this patch for my further work and drop the save/restore patch. Will update you if there is any other issue on this. I should have validated this patch on my own earlier :( Thanks for the discussion. Thanks - I guess that's a tested-by then? Sure. Tested-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
Hi there,
On Mon, Jan 17, 2011 at 7:22 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
SMP requires at least the ARMv6K extensions to be present, so if we're
running on SMP, the WFE and SEV instructions must be available.
However, when we run on UP, the v6K extensions may not be available,
and so we don't want WFE/SEV to be in the instruction stream. Use the
SMP alternatives infrastructure to replace these instructions with NOPs
if we build for SMP but run on UP.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/include/asm/spinlock.h | 37 +
1 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/spinlock.h b/arch/arm/include/asm/spinlock.h
index 17eb355..da1af52 100644
--- a/arch/arm/include/asm/spinlock.h
+++ b/arch/arm/include/asm/spinlock.h
@@ -5,17 +5,36 @@
#error SMP not supported on pre-ARMv6 CPUs
#endif
+/*
+ * sev and wfe are ARMv6K extensions. Uniprocessor ARMv6 may not have the K
+ * extensions, so when running on UP, we have to patch these instructions
away.
+ */
+#define ALT_SMP(smp, up) \
+ 9998: smp \n \
+ .pushsection \.alt.smp.init\, \a\\n \
+ .long 9998b\n \
+ up \n \
+ .popsection\n
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define SEV ALT_SMP(sev.w, nop.w)
+#define WFE(cond) ALT_SMP(wfe cond .w, nop.w)
+#else
+#define SEV ALT_SMP(sev, nop)
+#define WFE(cond) ALT_SMP(wfe cond, nop)
+#endif
+
static inline void dsb_sev(void)
{
#if __LINUX_ARM_ARCH__ = 7
__asm__ __volatile__ (
dsb\n
- sev
+ SEV
);
-#elif defined(CONFIG_CPU_32v6K)
+#else
__asm__ __volatile__ (
mcr p15, 0, %0, c7, c10, 4\n
- sev
+ SEV
: : r (0)
);
#endif
@@ -46,9 +65,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
__asm__ __volatile__(
1: ldrex %0, [%1]\n
teq %0, #0\n
-#ifdef CONFIG_CPU_32v6K
- wfene\n
-#endif
+ WFE(ne)
strexeq %0, %2, [%1]\n
teqeq %0, #0\n
bne 1b
@@ -107,9 +124,7 @@ static inline void arch_write_lock(arch_rwlock_t *rw)
__asm__ __volatile__(
1: ldrex %0, [%1]\n
teq %0, #0\n
-#ifdef CONFIG_CPU_32v6K
- wfene\n
-#endif
+ WFE(ne)
strexeq %0, %2, [%1]\n
teq %0, #0\n
bne 1b
@@ -176,9 +191,7 @@ static inline void arch_read_lock(arch_rwlock_t *rw)
1: ldrex %0, [%2]\n
adds %0, %0, #1\n
strexpl %1, %0, [%2]\n
-#ifdef CONFIG_CPU_32v6K
- wfemi\n
-#endif
+ WFE(mi)
rsbpls %0, %1, #0\n
bmi 1b
: =r (tmp), =r (tmp2)
--
1.6.2.5
A couple of questions on this:
1) I notice these spinlock functions are generally marked inline.
Is that likely to happen in modules? If so, there would be a need to
do SMP_ON_UP fixups at module load time -- I don't think that's
currently implemented.
2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen
vmlinux link errors like this:
LD .tmp_vmlinux1
`.exit.text' referenced in section `.alt.smp.init' of
drivers/built-in.o: defined in discarded section `.exit.text' of
drivers/built-in.o
make: *** [.tmp_vmlinux1] Error 1
I don't know whether this is caused by the patch directly or as a
side-effect -- I've only noticed it in the linaro-2.6.37 tree so far.
git bisect indentified this above patch as the first one with the
error in that case.
I don't understand the section discarding logic too well, so I'm not
sure how to fix it for now...
Cheers
---Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v8 3/7] omap: gpmc: enable irq mode in gpmc
* Ghorai, Sukumar s-gho...@ti.com [110122 09:53]: I think I've commented on this before, but why don't you make gpmc_init a subsys_initcall? There should be no reason to call this earlier. If something does not work because of that, then that issue must be fixed. [Ghorai] You suggested the same in previous v5 and v6; and I mentioned the issues [1] that - nand_init()called before subsys_initcall(gpmc_init); Let me know if I am missing anything again. There should not be any need to call nand_init early either. We want to initialize as much as possible late so we have proper console error messages. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
On Tue, Jan 25, 2011 at 04:43:52PM +, Dave Martin wrote: A couple of questions on this: 1) I notice these spinlock functions are generally marked inline. Is that likely to happen in modules? If so, there would be a need to do SMP_ON_UP fixups at module load time -- I don't think that's currently implemented. No one should be using the arch_* spinlocks directly. The spinlocks are implemented in out of line code in kernel/spinlock.c 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen vmlinux link errors like this: LD .tmp_vmlinux1 `.exit.text' referenced in section `.alt.smp.init' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o make: *** [.tmp_vmlinux1] Error 1 I don't know whether this is caused by the patch directly or as a side-effect -- I've only noticed it in the linaro-2.6.37 tree so far. git bisect indentified this above patch as the first one with the error in that case. I don't understand the section discarding logic too well, so I'm not sure how to fix it for now... Hmm. I don't see how that could happen, unless some driver is going behind the spinlock APIs, or using our dsb_sev() directly. I think you need to first track down what's responsible for inserting architecture spinlock code into drivers. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 00/18] OMAP2,3: hwmod DSS Adaptation
* Kevin Hilman khil...@ti.com [110124 13:56]: Sumit Semwal sumit.sem...@ti.com writes: v10 of the patch series corrects return-error handling from platform_request_irq() based on comments from Sergei Shtylyov and Russell King. [https://patchwork.kernel.org/patch/497911/] Tony, Assuming Tomi is OK with this series, I think these are ready to go into omap-testing for some broader testing. I can merge in Tomi's branch for testing once Tomi is happy with them. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: fix fncpy API call
From: Jean Pihet j-pi...@ti.com Fix a potential problem with function types when calling the fncpy API to copy the PM code functions to SRAM. Tested on OMAP3 in low power modes (RET/OFF) using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/plat-omap/include/plat/sram.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h index d673f2c..6a2166d 100644 --- a/arch/arm/plat-omap/include/plat/sram.h +++ b/arch/arm/plat-omap/include/plat/sram.h @@ -21,7 +21,7 @@ extern void *omap_sram_push_address(unsigned long size); typeof(funcp) _res = NULL; \ void *_sram_address = omap_sram_push_address(size); \ if (_sram_address) \ - _res = fncpy(_sram_address, funcp, size); \ + _res = fncpy(_sram_address, (funcp), size);\ _res; \ }) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP: use fncpy to copy the PM code functions to SRAM
On Tue, Jan 25, 2011 at 11:33 AM, Dave Martin dave.mar...@linaro.org wrote:
On Mon, Jan 24, 2011 at 5:25 PM, Jean Pihet jean.pi...@newoldbits.com wrote:
Hi,
On Mon, Jan 24, 2011 at 5:11 PM, Dave Martin dave.mar...@linaro.org wrote:
Hi there, I just spotted a couple of things merging your patch...
On Tue, Jan 18, 2011 at 12:02 PM, jean.pi...@newoldbits.com wrote:
From: Jean Pihet j-pi...@ti.com
The new fncpy API is better suited for copying some
code to SRAM at runtime. This patch changes the ad-hoc
code to the more generic fncpy API.
Tested OK on OMAP3 in low power modes (RET/OFF)
using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
Compile tested on OMAP1/2 using omap1_defconfig.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap1/pm.h | 6 +++---
arch/arm/mach-omap1/sleep.S | 3 +++
arch/arm/mach-omap1/sram.S | 1 +
arch/arm/mach-omap2/pm.h | 2 +-
arch/arm/mach-omap2/sleep24xx.S | 2 ++
arch/arm/mach-omap2/sleep34xx.S | 2 ++
arch/arm/mach-omap2/sram242x.S | 3 +++
arch/arm/mach-omap2/sram243x.S | 3 +++
arch/arm/mach-omap2/sram34xx.S | 1 +
arch/arm/plat-omap/include/plat/sram.h | 14 +-
arch/arm/plat-omap/sram.c | 14 +-
11 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.h b/arch/arm/mach-omap1/pm.h
index 56a6479..cd926dc 100644
--- a/arch/arm/mach-omap1/pm.h
+++ b/arch/arm/mach-omap1/pm.h
@@ -123,9 +123,9 @@ extern void allow_idle_sleep(void);
extern void omap1_pm_idle(void);
extern void omap1_pm_suspend(void);
-extern void omap7xx_cpu_suspend(unsigned short, unsigned short);
-extern void omap1510_cpu_suspend(unsigned short, unsigned short);
-extern void omap1610_cpu_suspend(unsigned short, unsigned short);
+extern void omap7xx_cpu_suspend(unsigned long, unsigned long);
+extern void omap1510_cpu_suspend(unsigned long, unsigned long);
+extern void omap1610_cpu_suspend(unsigned long, unsigned long);
extern void omap7xx_idle_loop_suspend(void);
extern void omap1510_idle_loop_suspend(void);
extern void omap1610_idle_loop_suspend(void);
diff --git a/arch/arm/mach-omap1/sleep.S b/arch/arm/mach-omap1/sleep.S
index ef771ce..c875bdc 100644
--- a/arch/arm/mach-omap1/sleep.S
+++ b/arch/arm/mach-omap1/sleep.S
@@ -58,6 +58,7 @@
*/
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+ .align 3
ENTRY(omap7xx_cpu_suspend)
@ save registers on stack
@@ -137,6 +138,7 @@ ENTRY(omap7xx_cpu_suspend_sz)
#endif /* CONFIG_ARCH_OMAP730 || CONFIG_ARCH_OMAP850 */
#ifdef CONFIG_ARCH_OMAP15XX
+ .align 3
ENTRY(omap1510_cpu_suspend)
@ save registers on stack
@@ -211,6 +213,7 @@ ENTRY(omap1510_cpu_suspend_sz)
#endif /* CONFIG_ARCH_OMAP15XX */
#if defined(CONFIG_ARCH_OMAP16XX)
+ .align 3
ENTRY(omap1610_cpu_suspend)
@ save registers on stack
diff --git a/arch/arm/mach-omap1/sram.S b/arch/arm/mach-omap1/sram.S
index 7724e52..692587d 100644
--- a/arch/arm/mach-omap1/sram.S
+++ b/arch/arm/mach-omap1/sram.S
@@ -18,6 +18,7 @@
/*
* Reprograms ULPD and CKCTL.
*/
+ .align 3
ENTRY(omap1_sram_reprogram_clock)
stmfd sp!, {r0 - r12, lr} @ save registers on stack
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 1c1b0ab..39580e6 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -92,7 +92,7 @@ extern void omap24xx_idle_loop_suspend(void);
extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem
*sdrc_dlla_ctrl,
void __iomem *sdrc_power);
extern void omap34xx_cpu_suspend(u32 *addr, int save_state);
-extern void save_secure_ram_context(u32 *addr);
+extern int save_secure_ram_context(u32 *addr);
extern void omap3_save_scratchpad_contents(void);
extern unsigned int omap24xx_idle_loop_suspend_sz;
diff --git a/arch/arm/mach-omap2/sleep24xx.S
b/arch/arm/mach-omap2/sleep24xx.S
index c7780cc..b5071a4 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -47,6 +47,7 @@
* Note: This code get's copied to internal SRAM at boot. When the OMAP
* wakes up it continues execution at the point it went to sleep.
*/
+ .align 3
ENTRY(omap24xx_idle_loop_suspend)
stmfd sp!, {r0, lr} @ save registers on stack
mov r0, #0 @ clear for mcr setup
@@ -82,6 +83,7 @@ ENTRY(omap24xx_idle_loop_suspend_sz)
* The DLL load value is not kept in RETENTION or OFF. It needs to be
restored
* at wake
*/
+ .align 3
ENTRY(omap24xx_cpu_suspend)
stmfd sp!, {r0 - r12, lr} @ save registers on stack
mov r3, #0x0 @ clear for mcr call
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index 98d8232..951a0be
Re: [PATCH] OMAP: fix fncpy API call
On Tue, Jan 25, 2011 at 5:21 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Fix a potential problem with function types when calling the fncpy API to copy the PM code functions to SRAM. Tested on OMAP3 in low power modes (RET/OFF) using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/plat-omap/include/plat/sram.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h index d673f2c..6a2166d 100644 --- a/arch/arm/plat-omap/include/plat/sram.h +++ b/arch/arm/plat-omap/include/plat/sram.h @@ -21,7 +21,7 @@ extern void *omap_sram_push_address(unsigned long size); typeof(funcp) _res = NULL; \ void *_sram_address = omap_sram_push_address(size); \ if (_sram_address) \ - _res = fncpy(_sram_address, funcp, size); \ + _res = fncpy(_sram_address, (funcp), size); \ If you're doing this, you should also have typeof((funcp)) above. Cheers ---Dave _res; \ }) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jan 25, 2011 at 04:43:52PM +, Dave Martin wrote: A couple of questions on this: 1) I notice these spinlock functions are generally marked inline. Is that likely to happen in modules? If so, there would be a need to do SMP_ON_UP fixups at module load time -- I don't think that's currently implemented. No one should be using the arch_* spinlocks directly. The spinlocks are implemented in out of line code in kernel/spinlock.c OK--- do think this is something we need a sanity-check for, or does this fall into to a category of bad driver implementation which will get thrown out during peer review? 2) When building with this patch and CONFIG_SMP_ON_UP=y, I've seen vmlinux link errors like this: LD .tmp_vmlinux1 `.exit.text' referenced in section `.alt.smp.init' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o make: *** [.tmp_vmlinux1] Error 1 I don't know whether this is caused by the patch directly or as a side-effect -- I've only noticed it in the linaro-2.6.37 tree so far. git bisect indentified this above patch as the first one with the error in that case. I don't understand the section discarding logic too well, so I'm not sure how to fix it for now... Hmm. I don't see how that could happen, unless some driver is going behind the spinlock APIs, or using our dsb_sev() directly. I think you need to first track down what's responsible for inserting architecture spinlock code into drivers. OK, I'll try and do a bit more digging. I think I have a better idea of what to look for now, anyhow. Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: fix fncpy API call
On Tue, Jan 25, 2011 at 6:30 PM, Dave Martin dave.mar...@linaro.org wrote: On Tue, Jan 25, 2011 at 5:21 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com Fix a potential problem with function types when calling the fncpy API to copy the PM code functions to SRAM. Tested on OMAP3 in low power modes (RET/OFF) using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/plat-omap/include/plat/sram.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h index d673f2c..6a2166d 100644 --- a/arch/arm/plat-omap/include/plat/sram.h +++ b/arch/arm/plat-omap/include/plat/sram.h @@ -21,7 +21,7 @@ extern void *omap_sram_push_address(unsigned long size); typeof(funcp) _res = NULL; \ void *_sram_address = omap_sram_push_address(size); \ if (_sram_address) \ - _res = fncpy(_sram_address, funcp, size); \ + _res = fncpy(_sram_address, (funcp), size); \ If you're doing this, you should also have typeof((funcp)) above. Doh! :p Let me submit a new version asap. Jean Cheers ---Dave _res; \ }) -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] OMAP3EVM: Board bug fixes/enhancements
The current linux-omap/master is broken for lots of features/modules and also there are few enhancements required with addition of AM/DM37x family of devices. - Migrate TWL gpio_xxx api to gpio_xx_cansleep - TSC: Driver init fails due to missing VIO regulator - TSC: Wakeup is broken, enable the wakeup capability - DSS: Addition of Mux changes for AM/DM37x - Make Backlight gpio off in default state Note: Resetting the revision of patches since this is first bundled series. Vaibhav Hiremath (5): OMAP:board-omap3evm: Change TWL related gpio API's to gpio*_cansleep OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver AM/DM37x: DSS mux configuration for Rev-B processor cards OMAP3EVM: Made backlight GPIO default state to off OMAP3EVM: Set TSC wakeup option in pad config arch/arm/mach-omap2/board-omap3evm.c | 80 +- 1 files changed, 69 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP:board-omap3evm: Change TWL related gpio API's to gpio*_cansleep
Since TWL GPIO's can go into sleep, and using normal
gpio_get/set_value() API will lead to kernel dump (WARN_ON()).
So replacing standard gpio_get/set_value() to
gpio_get/set_value_cansleep().
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 97e0f65..8d2e413 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -268,9 +268,9 @@ static int omap3_evm_enable_lcd(struct omap_dss_device
*dssdev)
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
else
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
lcd_enabled = 1;
return 0;
@@ -281,9 +281,9 @@ static void omap3_evm_disable_lcd(struct omap_dss_device
*dssdev)
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 1);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2)
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
else
- gpio_set_value(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
lcd_enabled = 0;
}
@@ -322,7 +322,7 @@ static int omap3_evm_enable_dvi(struct omap_dss_device
*dssdev)
return -EINVAL;
}
- gpio_set_value(OMAP3EVM_DVI_PANEL_EN_GPIO, 1);
+ gpio_set_value_cansleep(OMAP3EVM_DVI_PANEL_EN_GPIO, 1);
dvi_enabled = 1;
return 0;
@@ -330,7 +330,7 @@ static int omap3_evm_enable_dvi(struct omap_dss_device
*dssdev)
static void omap3_evm_disable_dvi(struct omap_dss_device *dssdev)
{
- gpio_set_value(OMAP3EVM_DVI_PANEL_EN_GPIO, 0);
+ gpio_set_value_cansleep(OMAP3EVM_DVI_PANEL_EN_GPIO, 0);
dvi_enabled = 0;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] OMAP3EVM: Add vio regulator supply required for ads7846 TSC driver
Add vio regulator supply, needed for ads7846 touchscreen controller
driver.
Tested on OMAP3 (ES3.1 Si) RevG version of EVM.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8d2e413..dcef454 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -571,6 +571,25 @@ static struct regulator_init_data omap3_evm_vpll2 = {
.consumer_supplies = omap3_evm_vpll2_supply,
};
+/* ads7846 on SPI */
+static struct regulator_consumer_supply omap3evm_vio_supply =
+ REGULATOR_SUPPLY(vcc, spi1.0);
+
+/* VIO for ads7846 */
+static struct regulator_init_data omap3evm_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = omap3evm_vio_supply,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -583,6 +602,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
.codec = omap3evm_codec_data,
.vdac = omap3_evm_vdac,
.vpll2 = omap3_evm_vpll2,
+ .vio= omap3evm_vio,
};
static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP3EVM: Made backlight GPIO default state to off
If you choose default output to DVI, the LCD backlight used to
stay on, since panel-disable function never gets called.
So, during init put backlight GPIO to off state and the driver
code will decide which output to enable.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 0d235bc..2a2efa9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -444,6 +444,8 @@ static struct platform_device leds_gpio = {
static int omap3evm_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
/* gpio + 0 is mmc0_cd (input/IRQ) */
omap_mux_init_gpio(63, OMAP_PIN_INPUT);
mmc[0].gpio_cd = gpio + 0;
@@ -459,8 +461,12 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
*/
/* TWL4030_GPIO_MAX + 0 == ledA, LCD Backlight control */
- gpio_request(gpio + TWL4030_GPIO_MAX, EN_LCD_BKL);
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ r = gpio_request(gpio + TWL4030_GPIO_MAX, EN_LCD_BKL);
+ if (!r)
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX,
+ (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) ? 1 : 0);
+ if (r)
+ printk(KERN_ERR failed to get/set lcd_bkl gpio\n);
/* gpio + 7 == DVI Enable */
gpio_request(gpio + 7, EN_DVI);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP3EVM: Set TSC wakeup option in pad config
Set OMAP_PIN_OFF_WAKEUPENABLE to enable the wake-up
functionality from touchscreen controller.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 2a2efa9..5eddf93 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -716,7 +716,8 @@ static struct omap_board_mux omap35x_board_mux[] __initdata
= {
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
- OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
+ OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_NONE),
OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
@@ -729,7 +730,8 @@ static struct omap_board_mux omap36x_board_mux[] __initdata
= {
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
- OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
+ OMAP_PIN_OFF_WAKEUPENABLE),
/* AM/DM37x EVM: DSS data bus muxed with sys_boot */
OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] AM/DM37x: DSS mux configuration for Rev-B processor cards
To support higher resolution (e.g 720P@60), on OMAP36x (AM/DM37x)
DSS data bus has been muxed with sys_boot pins.
DSS[18-23] = DSS[0-5]
sys_boot[0,1 3-5] = DSS[18-23]
EVM revision =RevB adopt this mux changes, which is going to ship outside.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 34 --
1 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index dcef454..0d235bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -705,7 +705,7 @@ static struct ehci_hcd_omap_platform_data ehci_pdata
__initdata = {
};
#ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
+static struct omap_board_mux omap35x_board_mux[] __initdata = {
OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
@@ -717,6 +717,32 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PIN_OFF_NONE),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_board_mux omap36x_board_mux[] __initdata = {
+ OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW |
+ OMAP_PIN_OFF_WAKEUPENABLE),
+ OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
+ OMAP_PIN_OFF_INPUT_PULLUP |
OMAP_PIN_OFF_OUTPUT_LOW),
+ /* AM/DM37x EVM: DSS data bus muxed with sys_boot */
+ OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT0, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT1, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT3, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT4, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+ OMAP3_MUX(SYS_BOOT6, OMAP_MUX_MODE3 | OMAP_PIN_OFF_NONE),
+
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#else
+#define omap35x_board_mux NULL
+#define omap36x_board_mux NULL
#endif
static struct omap_musb_board_data musb_board_data = {
@@ -728,7 +754,11 @@ static struct omap_musb_board_data musb_board_data = {
static void __init omap3_evm_init(void)
{
omap3_evm_get_revision();
- omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+
+ if (cpu_is_omap3630())
+ omap3_mux_init(omap36x_board_mux, OMAP_PACKAGE_CBB);
+ else
+ omap3_mux_init(omap35x_board_mux, OMAP_PACKAGE_CBB);
omap3_evm_i2c_init();
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
On Tue, Jan 25, 2011 at 05:33:14PM +, Dave Martin wrote: On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jan 25, 2011 at 04:43:52PM +, Dave Martin wrote: A couple of questions on this: 1) I notice these spinlock functions are generally marked inline. Is that likely to happen in modules? If so, there would be a need to do SMP_ON_UP fixups at module load time -- I don't think that's currently implemented. No one should be using the arch_* spinlocks directly. The spinlocks are implemented in out of line code in kernel/spinlock.c OK--- do think this is something we need a sanity-check for, or does this fall into to a category of bad driver implementation which will get thrown out during peer review? Hmm, actually it looks like you can end up with configurations where the spinlocks are inlined. That means we'll have to get rid of the link-time discarding of the .exit sections, and discard them along with the .init sections. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP: fix fncpy API call
From: Jean Pihet j-pi...@ti.com
Fix a potential problem with function types when calling the
fncpy API to copy the PM code functions to SRAM.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/plat-omap/include/plat/sram.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/sram.h
b/arch/arm/plat-omap/include/plat/sram.h
index d673f2c..f500fc3 100644
--- a/arch/arm/plat-omap/include/plat/sram.h
+++ b/arch/arm/plat-omap/include/plat/sram.h
@@ -18,10 +18,10 @@ extern void *omap_sram_push_address(unsigned long size);
/* Macro to push a function to the internal SRAM, using the fncpy API */
#define omap_sram_push(funcp, size) ({ \
- typeof(funcp) _res = NULL; \
+ typeof((funcp)) _res = NULL; \
void *_sram_address = omap_sram_push_address(size); \
if (_sram_address) \
- _res = fncpy(_sram_address, funcp, size); \
+ _res = fncpy(_sram_address, (funcp), size);\
_res; \
})
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/5] ARM: scu: Move register defines to header file
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 6:36 PM
To: Santosh Shilimkar
Cc: catalin.mari...@arm.com; linus.ml.wall...@gmail.com; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
ccr...@android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header
file
On Tue, Jan 25, 2011 at 01:04:22PM +, Russell King - ARM Linux
wrote:
Actually, we can do this safely - byte stores are permitted to SCU
registers probably for this very reason.
3rd revision of the patch:
After fixing the 3rd version for base address break, I was able to
use this patch and test it. Seems to work. SMC related stuff can
be ignored because OMAP4 ES1.0 doesn't have functional PM hardware
support.
Here is the updated patch which will be 4th revision...
4th revision
---
arch/arm/include/asm/smp_scu.h |5 +
arch/arm/kernel/smp_scu.c | 23 +--
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/smp_scu.h
b/arch/arm/include/asm/smp_scu.h
index b6f42c9..676bc43 100644
--- a/arch/arm/include/asm/smp_scu.h
+++ b/arch/arm/include/asm/smp_scu.h
@@ -7,7 +7,12 @@
#define SCU_INVALIDATE 0x0c
#define SCU_FPGA_REVISION 0x10
+#define SCU_PM_NORMAL 0
+#define SCU_PM_DORMANT 2
+#define SCU_PM_POWEROFF3
+
unsigned int scu_get_core_count(void __iomem *);
void scu_enable(void __iomem *);
+int scu_power_mode(unsigned int);
#endif
diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
index ee7bf47..aec7c5d 100644
--- a/arch/arm/kernel/smp_scu.c
+++ b/arch/arm/kernel/smp_scu.c
@@ -14,6 +14,8 @@
#include asm/smp_scu.h
#include asm/cacheflush.h
+static void __iomem *base;
+
/*
* Get the number of CPU cores from the SCU configuration
*/
@@ -29,14 +31,15 @@ unsigned int __init scu_get_core_count(void __iomem
*scu_base)
void __init scu_enable(void __iomem *scu_base)
{
u32 scu_ctrl;
+ base = scu_base;
- scu_ctrl = __raw_readl(scu_base + SCU_CTRL);
+ scu_ctrl = __raw_readl(base + SCU_CTRL);
/* already enabled? */
if (scu_ctrl 1)
return;
scu_ctrl |= 1;
- __raw_writel(scu_ctrl, scu_base + SCU_CTRL);
+ __raw_writel(scu_ctrl, base + SCU_CTRL);
/*
* Ensure that the data accessed by CPU0 before the SCU was
@@ -44,3 +47,19 @@ void __init scu_enable(void __iomem *scu_base)
*/
flush_cache_all();
}
+
+int scu_power_mode(unsigned int mode)
+{
+ unsigned int val;
+ int cpu = smp_processor_id();
+ int shift;
+
+ if (mode 3 || mode == 1 || cpu 3)
+ return -EINVAL;
+
+ val = __raw_readb(base + SCU_CPU_STATUS + cpu) ~0x03;
+ val |= mode;
+ __raw_writeb(val, base + SCU_CPU_STATUS + cpu);
+
+ return 0;
+}
--
1.6.0.4
0001-4th-revision.patch
Description: Binary data
Re: [PATCH 3/5] ARM: twd: Add context save restore support
On Tue, Jan 25, 2011 at 3:29 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote: This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls. BTW, do you think the patch is, nevertheless, an improvement and something we should do? If so, please can I have your ack for it? This patch does work after adding the missing clockevent broadcasts to the Tegra idle driver, and allows me to remove all references to twd registers in the idle and suspend code, so: Acked-by: Colin Cross ccr...@android.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: hwmod: Populate _mpu_rt_va later on in omap_hwmod_late_init
Otherwise ioremap can fail with early_init patch unless we have
a static mapping for everything.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eacdfd3..9e89a58 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1467,12 +1467,10 @@ static int __init _register(struct omap_hwmod *oh)
return -EEXIST;
ms_id = _find_mpu_port_index(oh);
- if (!IS_ERR_VALUE(ms_id)) {
+ if (!IS_ERR_VALUE(ms_id))
oh-_mpu_port_index = ms_id;
- oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index);
- } else {
+ else
oh-_int_flags |= _HWMOD_NO_MPU_PORT;
- }
list_add_tail(oh-node, omap_hwmod_list);
@@ -1621,6 +1619,26 @@ int __init omap_hwmod_init(struct omap_hwmod **ohs)
return 0;
}
+/*
+ * _populate_mpu_rt_base - populate the virtual address for a hwmod
+ *
+ * Must be called only from omap_hwmod_late_init so ioremap works properly.
+ * Assumes the caller takes care of locking if needed.
+ *
+ */
+static int __init _populate_mpu_rt_base(struct omap_hwmod *oh, void *data)
+{
+ if (oh-_int_flags _HWMOD_NO_MPU_PORT)
+ return 0;
+
+ oh-_mpu_rt_va = _find_mpu_rt_base(oh, oh-_mpu_port_index);
+ if (!oh-_mpu_rt_va)
+ pr_warning(omap_hwmod: %s found no _mpu_rt_va for %s\n,
+ __func__, oh-name);
+
+ return 0;
+}
+
/**
* omap_hwmod_late_init - do some post-clock framework initialization
*
@@ -1632,6 +1650,8 @@ static int __init omap_hwmod_late_init(void)
{
int r;
+ r = omap_hwmod_for_each(_populate_mpu_rt_base, NULL);
+
/* XXX check return value */
r = omap_hwmod_for_each(_init_clocks, NULL);
WARN(r, omap_hwmod: omap_hwmod_late_init(): _init_clocks failed\n);
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: OMAP2: use early init hook
* Poddar, Sourav sourav.pod...@ti.com [110125 07:45]: Just FYI, I observed similar results on OMAP4 for these patches. For OMAP2420, OMAP2430 and OMAP3430 SDPs, you can add my boot Tested-by: Sourav Poddarsourav.pod...@ti.com Thanks, just posted third patch to this thread that fixes things for omap4, care to give that a try too? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: OMAP2: use early init hook
* Tony Lindgren t...@atomide.com [110124 18:20]: * Russell King - ARM Linux li...@arm.linux.org.uk [110124 13:51]: On Mon, Jan 24, 2011 at 12:26:29PM -0800, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110124 12:16]: So far tested on zoom3 only, but the following gets it booting on top of your patch. Looks like there are some other patches needed too.. At least omap4 still fails with these. From what I remember, the problem I saw on OMAP4 was hwmod related as it seemed to be using ioremap() - which with its initialization moved before memory allocators were up and running causes an oops. To me it seems _find_mpu_rt_base should be moved to omap_hwmod_late_init as we don't want to have a static mapping for everything. AFAIK the oh-_mpu_rt_va should not be needed early. Any comments on that Paul? See also the two patches I'll post as a reply to this thread make omap_hwmod_late_init a core_initcall. Posted this patch also, now also omap4 boots. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/14] ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:20]: Add additional instructions to our assembly bitops functions to ensure that they only operate on word-aligned pointers. This will be necessary when we switch these operations to use the word-based exclusive operations. If it's still not too late, we've had this in the testing branch in the linux-omap tree for about a week now. So far no problems, for me file systems tested have been ext3 and nfs. Tested-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
* Russell King - ARM Linux li...@arm.linux.org.uk [110117 11:23]: Switch the set/clear/change bitops to use the word-based exclusive operations, which are only present in a wider range of ARM architectures than the byte-based exclusive operations. This too been in use for about a week now with ext3 and nfs: Tested-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] ARM: gic: Add hooks for architecture specific extensions
On Mon, Jan 24, 2011 at 7:03 PM, Colin Cross ccr...@android.com wrote:
On Mon, Jan 24, 2011 at 12:51 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Few architectures combine the GIC with an external interrupt controller.
On such systems it may be necessary to update both the GIC registers
and the external controller's registers to control IRQ behavior.
This can be addressed in couple of possible methods.
1. Export common GIC routines along with 'struct irq_chip gic_chip'
and allow architectures to have custom function by override.
2. Provide architecture specific function pointer hooks
within GIC library and leave platforms to add the necessary
code as part of these hooks.
First one might be non-intrusive but have few shortcomings like arch needs
to have there own custom gic library. Locks used should be common since it
caters to same IRQs etc. Maintenance point of view also it leads to
multiple file fixes.
The second probably is cleaner and portable. It ensures that all the
common GIC infrastructure is not touched and also provides archs to
address their specific issue.
This method would work for most of Tegra's needs, although we would
need gic_set_type and gic_ack_irq to have arch extensions as well.
However, it does not allow for irq_retrigger, which can be implemented
on Tegra.
irq_retrigger does work with this method, the core IRQ code checks for
a return value if the retrigger was successful. Tegra works with your
patch along with these changes:
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 0b6c043..7993f07 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct irq_data *d)
static void gic_ack_irq(struct irq_data *d)
{
spin_lock(irq_controller_lock);
+ if (gic_arch_extn.irq_ack)
+ gic_arch_extn.irq_ack(d);
writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(irq_controller_lock);
}
@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
unsigned int type)
return 0;
}
+static int gic_retrigger(struct irq_data *d)
+{
+ if (gic_arch_extn.irq_retrigger)
+ return gic_arch_extn.irq_retrigger(d);
+
+ return 0;
+}
+
#ifdef CONFIG_SMP
static int
gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)
@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_set_type = gic_set_type,
+ .irq_retrigger = gic_retrigger,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h
On Tue, 25 Jan 2011, Russell King - ARM Linux wrote: On Tue, Jan 25, 2011 at 05:33:14PM +, Dave Martin wrote: On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jan 25, 2011 at 04:43:52PM +, Dave Martin wrote: A couple of questions on this: 1) I notice these spinlock functions are generally marked inline. Is that likely to happen in modules? If so, there would be a need to do SMP_ON_UP fixups at module load time -- I don't think that's currently implemented. No one should be using the arch_* spinlocks directly. The spinlocks are implemented in out of line code in kernel/spinlock.c OK--- do think this is something we need a sanity-check for, or does this fall into to a category of bad driver implementation which will get thrown out during peer review? Hmm, actually it looks like you can end up with configurations where the spinlocks are inlined. That means we'll have to get rid of the link-time discarding of the .exit sections, and discard them along with the .init sections. ... but only when CONFIG_SMP_ON_UP=y. Nicolas
RE: [PATCH v1 1/3]mmc: implemented runtime pm for mmc host
-Original Message-
From: Linus Walleij [mailto:linus.ml.wall...@gmail.com]
Sent: Monday, January 24, 2011 11:11 PM
To: Chris Ball
Cc: Tardy, Pierre; linux-...@vger.kernel.org; Ohad Ben-Cohen; linux-omap
Mailing List
Subject: Re: [PATCH v1 1/3]mmc: implemented runtime pm for mmc host
2011/1/20 Chris Ball c...@laptop.org:
On Wed, Jan 19, 2011 at 09:45:57AM +, Tardy, Pierre wrote:
Chris,
(Sorry for top posting)
Seems we have a intel intern disagreement.
Could we have maintainer opinion on this ?
Linus W and Ohad, any input here? Thanks,
What I see is orthogonal purposes altogether. Usually there is
something like two clocks and two regulators or switches
available in every sufficiently advanced system:
- One regulator to power the card
- One clock to clock the card (MCLK)
- One regulator or switch to power the MMC IP block
- One clock to clock the MMC IP block
The MMC core regulator handling and the clock gating I
implemented is about the two first things.
I think this patch is about the two *other* things, if I read it
right.
Actually in sdhci, you power off the MMC IP block, you power OFF the MCLK (at
least on our platform)
I don't know other platform where mmc clock is not controlled more or less
directlty by the sdhc IP.
Further this patch cannot be applied as-is.
It needs a clause where it will wait for the clock gating to
be sync:ed *before* calling the suspend hook.
That's the purpose of those hunks:
iff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 8c3769b..27931f6 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -20,6 +20,7 @@
#include linux/slab.h
#include linux/scatterlist.h
#include linux/regulator/consumer.h
+#include linux/pm_runtime.h
#include linux/leds.h
@@ -1221,6 +1222,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
{
struct sdhci_host *host;
unsigned long flags;
+ unsigned int lastclock;
u8 ctrl;
host = mmc_priv(mmc);
@@ -1231,6 +1233,27 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
goto out;
/*
+* get/put runtime_pm usage counter at ios-clock transitions
+* We need to do it before any other chip access, as sdhci could
+* be power gated
+*/
+ lastclock = host-iosclock;
+ host-iosclock = ios-clock;
+ if (lastclock == 0 ios-clock != 0) {
+ spin_unlock_irqrestore(host-lock, flags);
+ pm_runtime_get_sync(host-mmc-parent);
+ spin_lock_irqsave(host-lock, flags);
+ } else if (lastclock != 0 ios-clock == 0) {
+ spin_unlock_irqrestore(host-lock, flags);
+ pm_runtime_mark_last_busy(host-mmc-parent);
+ pm_runtime_put_autosuspend(host-mmc-parent);
+ spin_lock_irqsave(host-lock, flags);
+ }
+ /* no need to configure the rest.. */
+ if (host-iosclock == 0)
+ goto out;
+
+ /*
* Reset the chip on each power off.
* Should clear out any weird states.
*/
@@ -1303,6 +1326,8 @@ static int sdhci_get_ro(struct mmc_host *mmc)
I'm wondering if this code could be generic to all drivers, and if clock gating
could not be taking/releasing reference counter on the mmc_bus whenever there
is a clock gating transition?
We could condition that on some MMC_CAP_POWERGATE_WILL_CLKGATE capability flag.
Regards,
Pierre
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02/14] ARM: bitops: switch set/clear/change bitops to use ldrex/strex
On Tue, 25 Jan 2011, Will Deacon wrote: Hi Russell, Hopefully this isn't too late to be useful. On Mon, Jan 17, 2011 at 07:21:40PM +, Russell King - ARM Linux wrote: Switch the set/clear/change bitops to use the word-based exclusive operations, which are only present in a wider range of ARM architectures than the byte-based exclusive operations. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk As only one person replied to this patch with test information, I'm not happy to push this into -rc, and hence that prevents it going into -stable too. That means omap2plus_defconfig .38 mainline kernels (including -stable) will remain potentially dangerous when run on SMP capable hardware. Therefore, I see no alternative at the moment but to purposely cause builds which cover ARMv6, and ARMv6K or ARMv7 CPUs to save people from data corruption. Please get your tested-by's to me for at least the first three patches of this series ASAP. I've tested this on the Versatile Express (ca9x4, little endian) with a USB hard drive and ext3 (rw) filesystem. I did a bunch of parallel dds of a 2GB file containing random data whilst the system was fairly loaded. File checksums all passed and the kernel didn't do anything untowards. Tested-by: Will Deacon will.dea...@arm.com I appreciate this is the same test configuration as the one Nicolas did, but it at least replicates his findings. Well, I did run parallel instances of the git test suite on a Dove board using the sata_mv driver. Therefore this is still a significant difference in configuration which is good. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] Adding OMAP DMIC driver to kernel
This is a patch series to add the OMAP Digital Microphone driver for OMAP4. It includes the driver, a generic DMIC codec, platform devices, as well as HWMOD entries for OMAP44xx chipsets. Note: The DMIC codec driver was removed from this series as it was accepted for and merged for the 2.6.38 kernel. Benoit Cousson (1): OMAP4: hwmod: add entries for DMIC driver David Lambert (3): ASoC: DMIC: Adding the OMAP DMIC driver OMAP4: DMIC: initializes the DMIC driver OMAP4: DMIC: Add DMIC codec platform devices arch/arm/mach-omap2/board-4430sdp.c| 11 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 91 + arch/arm/plat-omap/devices.c | 35 ++ arch/arm/plat-omap/include/plat/dmic.h | 82 + sound/soc/omap/Kconfig |3 + sound/soc/omap/Makefile|2 + sound/soc/omap/omap-dmic.c | 534 7 files changed, 758 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/dmic.h create mode 100644 sound/soc/omap/omap-dmic.c -- To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] OMAP4: hwmod: add entries for DMIC driver
From: Benoit Cousson b-cous...@ti.com
Adds HWMOD entries for the OMAP DMIC driver and creates
a platform device. The HWMOD entires define the system
resource requirements for the drvier such as DMA addresses, channels,
and IRQ's. Placing this information in the HWMOD database allows
for more generic drivers to be written and having the specific
implementation details defined in HWMOD.
Signed-off-by: David Lambert dlamb...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 91
1 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7274db4..f9b2ad3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -383,6 +383,95 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
};
/*
+ * 'dmic' class
+ * digital microphone controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dmic_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_dmic_hwmod_class = {
+ .name = omap-dmic,
+ .sysc = omap44xx_dmic_sysc,
+};
+
+/* dmic */
+static struct omap_hwmod omap44xx_dmic_hwmod;
+static struct omap_hwmod_irq_info omap44xx_dmic_irqs[] = {
+ { .irq = 114 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_dmic_sdma_reqs[] = {
+ { .dma_req = 66 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dmic_addrs[] = {
+ {
+ .pa_start = 0x4012e000,
+ .pa_end = 0x4012e07f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - dmic */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_dmic_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_dmic_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dmic_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_dmic_dma_addrs[] = {
+ {
+ .pa_start = 0x4902e000,
+ .pa_end = 0x4902e07f,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - dmic (dma) */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic_dma = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_dmic_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_dmic_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dmic_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* dmic slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_dmic_slaves[] = {
+ omap44xx_l4_abe__dmic,
+ omap44xx_l4_abe__dmic_dma,
+};
+
+static struct omap_hwmod omap44xx_dmic_hwmod = {
+ .name = omap-dmic,
+ .class = omap44xx_dmic_hwmod_class,
+ .mpu_irqs = omap44xx_dmic_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dmic_irqs),
+ .sdma_reqs = omap44xx_dmic_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_dmic_sdma_reqs),
+ .main_clk = dmic_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM1_ABE_DMIC_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_dmic_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_dmic_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
* 'mpu_bus' class
* instance(s): mpu_private
*/
@@ -826,6 +915,8 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_l4_cfg_hwmod,
omap44xx_l4_per_hwmod,
omap44xx_l4_wkup_hwmod,
+ /* dmic class */
+ omap44xx_dmic_hwmod,
/* mpu_bus class */
omap44xx_mpu_private_hwmod,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] OMAP4: DMIC: initializes the DMIC driver
This code is used to read the HWMOD database and initialize
the DMIC driver.
Signed-off-by: David Lambert dlamb...@ti.com
---
arch/arm/plat-omap/devices.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index fc81912..b347f75 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -72,6 +72,40 @@ void omap_mcbsp_register_board_cfg(struct
omap_mcbsp_platform_data *config,
/*-*/
+#if defined(CONFIG_SND_OMAP_SOC_DMIC) || \
+ defined(CONFIG_SND_OMAP_SOC_DMIC_MODULE)
+
+static struct omap_device_pm_latency omap_dmic_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ },
+};
+
+static void omap_init_dmic(void)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+
+ oh = omap_hwmod_lookup(omap-dmic);
+ if (!oh) {
+ printk(KERN_ERR Could not look up dmic hw_mod\n);
+ return;
+ }
+
+ od = omap_device_build(omap-dmic-dai, -1, oh, NULL, 0,
+ omap_dmic_latency,
+ ARRAY_SIZE(omap_dmic_latency), 0);
+ if (IS_ERR(od))
+ printk(KERN_ERR Could not build omap_device for
omap-dmic-dai\n);
+}
+#else
+static inline void omap_init_dmic(void) {}
+#endif
+
+/*-*/
+
#if defined(CONFIG_SND_OMAP_SOC_MCPDM) || \
defined(CONFIG_SND_OMAP_SOC_MCPDM_MODULE)
@@ -328,6 +362,7 @@ static int __init omap_init_devices(void)
/* please keep these calls, and their implementations above,
* in alphabetical order so they're easier to sort through.
*/
+ omap_init_dmic();
omap_init_rng();
omap_init_mcpdm();
omap_init_uwire();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] ASoC: DMIC: Adding the OMAP DMIC driver
This patch adds support for the OMAP4 digital microphone DAI. This DAI can support support recording in 2, 4, or 6 channels When provided with a 19.2Mhz functional clock, can encode at 96Khz or 192Khz (all channels must have the same sample rate). Details of the hardware interface can be found in the OMAP4 TRM in Section 23.7 Signed-off-by: David Lambert dlamb...@ti.com --- arch/arm/plat-omap/include/plat/dmic.h | 82 + sound/soc/omap/Kconfig |3 + sound/soc/omap/Makefile|2 + sound/soc/omap/omap-dmic.c | 534 4 files changed, 621 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/dmic.h create mode 100644 sound/soc/omap/omap-dmic.c diff --git a/arch/arm/plat-omap/include/plat/dmic.h b/arch/arm/plat-omap/include/plat/dmic.h new file mode 100644 index 000..a72e080 --- /dev/null +++ b/arch/arm/plat-omap/include/plat/dmic.h @@ -0,0 +1,82 @@ +/* + * omap-dmic.h -- OMAP Digital Microphone Controller + * + * Author: Liam Girdwood l...@slimlogic.co.uk + *David Lambert dlamb...@ti.com + *Misael Lopez Cruz misael.lo...@ti.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. + */ + +#ifndef __ASM_ARCH_OMAP_DMIC_H +#define __ASM_ARCH_OMAP_DMIC_H + +#define OMAP44XX_DMIC_L3_BASE 0x4902e000 + +#define OMAP_DMIC_REVISION 0x00 +#define OMAP_DMIC_SYSCONFIG0x10 +#define OMAP_DMIC_IRQSTATUS_RAW0x24 +#define OMAP_DMIC_IRQSTATUS0x28 +#define OMAP_DMIC_IRQENABLE_SET0x2C +#define OMAP_DMIC_IRQENABLE_CLR0x30 +#define OMAP_DMIC_IRQWAKE_EN 0x34 +#define OMAP_DMIC_DMAENABLE_SET0x38 +#define OMAP_DMIC_DMAENABLE_CLR0x3C +#define OMAP_DMIC_DMAWAKEEN0x40 +#define OMAP_DMIC_CTRL 0x44 +#define OMAP_DMIC_DATA 0x48 +#define OMAP_DMIC_FIFO_CTRL0x4C +#define OMAP_DMIC_FIFO_DMIC1R_DATA 0x50 +#define OMAP_DMIC_FIFO_DMIC1L_DATA 0x54 +#define OMAP_DMIC_FIFO_DMIC2R_DATA 0x58 +#define OMAP_DMIC_FIFO_DMIC2L_DATA 0x5C +#define OMAP_DMIC_FIFO_DMIC3R_DATA 0x60 +#define OMAP_DMIC_FIFO_DMIC3L_DATA 0x64 + +/* + * DMIC_IRQ bit fields + * IRQSTATUS_RAW, IRQSTATUS, IRQENABLE_SET, IRQENABLE_CLR + */ + +#define OMAP_DMIC_IRQ (1 0) +#define OMAP_DMIC_IRQ_FULL (1 1) +#define OMAP_DMIC_IRQ_ALMST_EMPTY (1 2) +#define OMAP_DMIC_IRQ_EMPTY(1 3) +#define OMAP_DMIC_IRQ_MASK 0x07 + +/* + * DMIC_DMAENABLE bit fields + */ + +#define OMAP_DMIC_DMA_ENABLE 0x1 + +/* + * DMIC_CTRL bit fields + */ + +#define OMAP_DMIC_UP1_ENABLE 0x0001 +#define OMAP_DMIC_UP2_ENABLE 0x0002 +#define OMAP_DMIC_UP3_ENABLE 0x0004 +#define OMAP_DMIC_FORMAT 0x0008 +#define OMAP_DMIC_POLAR1 0x0010 +#define OMAP_DMIC_POLAR2 0x0020 +#define OMAP_DMIC_POLAR3 0x0040 +#define OMAP_DMIC_POLAR_MASK 0x0070 +#define OMAP_DMIC_CLK_DIV_SHIFT7 +#define OMAP_DMIC_CLK_DIV_MASK 0x0380 +#defineOMAP_DMIC_RESET 0x0400 + +#define OMAP_DMIC_ENABLE_MASK 0x007 + +#define OMAP_DMICOUTFORMAT_LJUST (0 3) +#define OMAP_DMICOUTFORMAT_RJUST (1 3) + +/* + * DMIC_FIFO_CTRL bit fields + */ + +#define OMAP_DMIC_THRES_MAX0xF + +#endif diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index a088db6..818ead3 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -9,6 +9,9 @@ config SND_OMAP_SOC_MCBSP config SND_OMAP_SOC_MCPDM tristate +config SND_OMAP_SOC_DMIC + tristate + config SND_OMAP_SOC_N810 tristate SoC Audio support for Nokia N810 depends on SND_OMAP_SOC MACH_NOKIA_N810 I2C diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index ba9fc65..6ff27f5 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -1,9 +1,11 @@ # OMAP Platform Support snd-soc-omap-objs := omap-pcm.o +snd-soc-omap-dmic-objs := omap-dmic.o snd-soc-omap-mcbsp-objs := omap-mcbsp.o snd-soc-omap-mcpdm-objs := omap-mcpdm.o mcpdm.o obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o +obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c new file mode 100644 index 000..06dbb99 --- /dev/null +++ b/sound/soc/omap/omap-dmic.c @@ -0,0 +1,534 @@ +/* + * omap-dmic.c -- OMAP ASoC DMIC DAI driver + * + * Copyright (C) 2010 Texas Instruments + * + * Author: Liam Girdwood l...@slimlogic.co.uk + *David Lambert dlamb...@ti.com + *Misael Lopez
[PATCH v3 4/4] OMAP4: DMIC: Add DMIC codec platform devices
This creates the DMIC codec platform devices.
The platform devices create an instance of the driver during boot up.
Signed-off-by: David Lambert dlamb...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index df5a425..e7745cf 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -505,6 +505,16 @@ static void __init omap_sfh7741prox_init(void)
}
}
+static struct platform_device codec_dmic0 = {
+ .name = dmic-codec,
+ .id = -1,
+};
+
+static inline void omap_dmic_init(void)
+{
+ platform_device_register(codec_dmic0);
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
@@ -528,6 +538,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_dmic_init();
}
static void __init omap_4430sdp_map_io(void)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 2/4] OMAP4: hwmod: add entries for DMIC driver
On Tue, 25 Jan 2011, David Lambert wrote: From: Benoit Cousson b-cous...@ti.com Adds HWMOD entries for the OMAP DMIC driver and creates a platform device. The HWMOD entires define the system resource requirements for the drvier such as DMA addresses, channels, and IRQ's. Placing this information in the HWMOD database allows for more generic drivers to be written and having the specific implementation details defined in HWMOD. Signed-off-by: David Lambert dlamb...@ti.com This should have Benoit's Signed-off-by: also. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP2+: PM: omap device: API's for handling mstandby mode
On Mon, Jan 24, 2011 at 03:03:49PM +0530, G, Manjunath Kondaiah wrote: Paul/Benoit, On Tue, Dec 14, 2010 at 07:18:22AM +0530, G, Manjunath Kondaiah wrote: Paul/Benoit, On Fri, Dec 03, 2010 at 01:19:06PM +0100, Cousson, Benoit wrote: On 12/3/2010 10:47 AM, G, Manjunath Kondaiah wrote: * Cousson, Benoitb-cous...@ti.com [2010-12-03 09:38:35 +0100]: [...] v7: replaced mutex lock with spin lock. Added use count for controlling access to sysconfig registers in case if overlapping request/release API's are used. I'm not sure it should be done here. I'd rather keep that code in the DMA, since this is the only user of that feature. Are you referring to spin lock or usage count? The spinlock is needed, I was referring to the usage count. That being said, the API proposed by Paul (request/release ) sound like a get/put, so maybe he had that kind of usage in mind. I'm still not convince it should be done at hwmod API level. Paul, Any thoughts on that? How do we proceed further? Gentle reminder! Can we please align on this so that DMA sysconfig patches can be upstreamed? Discussion on this topic can be accessed at: https://patchwork.kernel.org/patch/372231/ http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39728.html As there is no response from paul on this topic, I will go ahead with usage count logic proposed by Adrian Hunter adrian.hun...@nokia.com at: https://patchwork.kernel.org/patch/366831/ Above logic has got: Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com -Manjunath -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: PM: fix save secure RAM to restore MPU power state
Currently, on HS/EMU devices, MPU power state forced to on during PM
init by the save secure RAM code. Rather than forcing the state of
MPU powerdomain to on, simply read the current value and restore it
after the ROM code has run.
This only affects the !CPUidle case since when CPUidle is enabled, the
MPU power state is dynamically changed by CPUidle. In the !CPUidle
case, MPU power state is initialized once at init and never touched.
Cc: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
If no objectsions, will be queued in my pm-fixes branch for 2.6.38-rc.
arch/arm/mach-omap2/pm34xx.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8cbbead..1916038 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -168,9 +168,10 @@ static void omap3_core_restore_context(void)
* once during boot sequence, but this works as we are not using secure
* services.
*/
-static void omap3_save_secure_ram_context(u32 target_mpu_state)
+static void omap3_save_secure_ram_context(void)
{
u32 ret;
+ int mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
/*
@@ -181,7 +182,7 @@ static void omap3_save_secure_ram_context(u32
target_mpu_state)
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
ret = _omap_save_secure_sram((u32 *)
__pa(omap3_secure_ram_storage));
- pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
+ pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
/* Following is for error tracking, it should not happen */
if (ret) {
printk(KERN_ERR save_secure_sram() returns %08x\n,
@@ -1094,7 +1095,7 @@ static int __init omap3_pm_init(void)
local_fiq_disable();
omap_dma_global_context_save();
- omap3_save_secure_ram_context(PWRDM_POWER_ON);
+ omap3_save_secure_ram_context();
omap_dma_global_context_restore();
local_irq_enable();
--
1.7.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/4] Adding OMAP DMIC driver to kernel
On Tue, Jan 25, 2011 at 04:00:58PM -0600, David Lambert wrote: This is a patch series to add the OMAP Digital Microphone driver for OMAP4. It includes the driver, a generic DMIC codec, platform devices, as well as HWMOD entries for OMAP44xx chipsets. Note: The DMIC codec driver was removed from this series as it was accepted for and merged for the 2.6.38 kernel. You have not mentioned the baseline for this patch series. I tried to apply first patch of this series on linux omap master branch, patch applies cleanly but the changes are not getting compiled eventhough it is enabled in Makefile if I use omap2plus_defconfig. Am I missing anything? -Manjunath Benoit Cousson (1): OMAP4: hwmod: add entries for DMIC driver David Lambert (3): ASoC: DMIC: Adding the OMAP DMIC driver OMAP4: DMIC: initializes the DMIC driver OMAP4: DMIC: Add DMIC codec platform devices arch/arm/mach-omap2/board-4430sdp.c| 11 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 91 + arch/arm/plat-omap/devices.c | 35 ++ arch/arm/plat-omap/include/plat/dmic.h | 82 + sound/soc/omap/Kconfig |3 + sound/soc/omap/Makefile|2 + sound/soc/omap/omap-dmic.c | 534 7 files changed, 758 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/include/plat/dmic.h create mode 100644 sound/soc/omap/omap-dmic.c -- To unsubscribe from this list: send the line unsubscribe linux-omap 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] OMAP4: hwmod DSS support
This patch series enables support for OMAP4 DSS, and adds hwmod support for dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods. In OMAP4 there are severals IPs that can be reached by differents interconnect paths depending of the access initiator (MPU vs. SDMA). In the case of the DSS, both L3 direct path and L4 CFG path can be used to access all the DSS IPs. dss is also considered as an IP as dispc, rfbi, and named as dss_core. TODO: This patch doesn't handle the opt clocks via hwmod - there will be a separate patch series which will take opt clock roles from hwmod, populate them in the device structure, so that the driver can ask for relevant opt-clocks. Also TBD is the migration to pm_runtime APIs, which need to be adapted a little for handling DSS-family of clocks completely. Changes from v1: - dss_dss device is renamed as dss_core as per suggestion from Benoit Cousson. Patch Base: === Patch-set rebased and tested w/ Zoom3 (OMAP3630) on top of: url = git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git branch master commit e8883f8057c0f7c9950fa9f20568f37bfa62f34a Description: Add linux-next specific files for 20110115 + Patch mentioned in http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42384.html [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init (This patch is required for OMAP bootup w/ 20110115 linux-next) + DSS hwmod patch series: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42914.html + patch series: OMAP2PLUS: DSS: Generalize clock names (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43058.html) Benoit Cousson (1): OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC Mayuresh Janorkar (1): OMAP2PLUS: DSS2: Add OMAP4 support Sumit Semwal (1): OMAP4: DSS2: Add hwmod device names for OMAP4. arch/arm/mach-omap2/display.c | 21 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 588 drivers/video/omap2/dss/Kconfig|6 +- drivers/video/omap2/omapfb/Kconfig |6 +- 4 files changed, 608 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] OMAP2PLUS: DSS2: Add OMAP4 Kconfig support
From: Mayuresh Janorkar ma...@ti.com Enable DSS2 and OMAPFB for OMAP4 in Kconfig Signed-off-by: Mayuresh Janorkar ma...@ti.com --- drivers/video/omap2/dss/Kconfig|6 +++--- drivers/video/omap2/omapfb/Kconfig |6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig index 43b6440..0d031b2 100644 --- a/drivers/video/omap2/dss/Kconfig +++ b/drivers/video/omap2/dss/Kconfig @@ -1,8 +1,8 @@ menuconfig OMAP2_DSS -tristate OMAP2/3 Display Subsystem support (EXPERIMENTAL) -depends on ARCH_OMAP2 || ARCH_OMAP3 + tristate OMAP2+ Display Subsystem support (EXPERIMENTAL) + depends on ARCH_OMAP2PLUS help - OMAP2/3 Display Subsystem support. + OMAP2+ Display Subsystem support. if OMAP2_DSS diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig index 65149b2..1da712e 100644 --- a/drivers/video/omap2/omapfb/Kconfig +++ b/drivers/video/omap2/omapfb/Kconfig @@ -1,5 +1,5 @@ menuconfig FB_OMAP2 -tristate OMAP2/3 frame buffer support (EXPERIMENTAL) +tristate OMAP2+ frame buffer support (EXPERIMENTAL) depends on FB OMAP2_DSS select OMAP2_VRAM @@ -8,10 +8,10 @@ menuconfig FB_OMAP2 select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT help - Frame buffer driver for OMAP2/3 based boards. + Frame buffer driver for OMAP2+ based boards. config FB_OMAP2_DEBUG_SUPPORT - bool Debug support for OMAP2/3 FB + bool Debug support for OMAP2+ FB default y depends on FB_OMAP2 help -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] OMAP4: hwmod data: add DSS DISPC DSI1,2 RFBI HDMI VENC
From: Benoit Cousson b-cous...@ti.com
Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods.
In OMAP4 there are severals IPs that can be reached by differents
interconnect paths depending of the access initiator (MPU vs. SDMA).
In the case of the DSS, both L3 direct path and L4 CFG path can be
used to access all the DSS IPs. The two ocp_ip already exists to support
the two address spaces.
++-- L3_MAIN --+ MPU
IP ||
+-- L4_CFG --+
L3 main address range is specified first, since it is used by default.
dss is also considered as an IP as dispc, rfbi, and named as dss_core.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 588
1 files changed, 588 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index c2806bd..7bca77e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -43,6 +43,13 @@
static struct omap_hwmod omap44xx_dma_system_hwmod;
static struct omap_hwmod omap44xx_dmm_hwmod;
static struct omap_hwmod omap44xx_dsp_hwmod;
+static struct omap_hwmod omap44xx_dss_core_hwmod;
+static struct omap_hwmod omap44xx_dss_dispc_hwmod;
+static struct omap_hwmod omap44xx_dss_dsi1_hwmod;
+static struct omap_hwmod omap44xx_dss_dsi2_hwmod;
+static struct omap_hwmod omap44xx_dss_hdmi_hwmod;
+static struct omap_hwmod omap44xx_dss_rfbi_hwmod;
+static struct omap_hwmod omap44xx_dss_venc_hwmod;
static struct omap_hwmod omap44xx_emif_fw_hwmod;
static struct omap_hwmod omap44xx_iva_hwmod;
static struct omap_hwmod omap44xx_l3_instr_hwmod;
@@ -237,12 +244,21 @@ static struct omap_hwmod_ocp_if omap44xx_mpu__l3_main_1 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* dss - l3_main_1 */
+static struct omap_hwmod_ocp_if omap44xx_dss__l3_main_1 = {
+ .master = omap44xx_dss_core_hwmod,
+ .slave = omap44xx_l3_main_1_hwmod,
+ .clk= l3_div_ck,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 slave ports */
static struct omap_hwmod_ocp_if *omap44xx_l3_main_1_slaves[] = {
omap44xx_dsp__l3_main_1,
omap44xx_l3_main_2__l3_main_1,
omap44xx_l4_cfg__l3_main_1,
omap44xx_mpu__l3_main_1,
+ omap44xx_dss__l3_main_1,
};
static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
@@ -746,6 +762,569 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/* DSS related classes */
+ /*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = omap44xx_dispc_sysc,
+};
+
+/* dss_dispc */
+static struct omap_hwmod_irq_info omap44xx_dss_dispc_irqs[] = {
+ { .irq = 25 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_dma_info omap44xx_dss_dispc_sdma_reqs[] = {
+ { .dma_req = 5 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_dss_dispc_addrs[] = {
+ {
+ .pa_start = 0x48041000,
+ .pa_end = 0x48041fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_per - dss_dispc */
+static struct omap_hwmod_ocp_if omap44xx_l4_per__dss_dispc = {
+ .master = omap44xx_l4_per_hwmod,
+ .slave = omap44xx_dss_dispc_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_dss_dispc_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_dss_dispc_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_dss_dispc_dma_addrs[] = {
+ {
+ .pa_start = 0x58001000,
+ .pa_end = 0x58001fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l3_main_2 - dss_dispc */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__dss_dispc = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_dss_dispc_hwmod,
+ .clk= l3_div_ck,
+ .addr =
[PATCH v2 3/3] OMAP4: DSS2: Add hwmod device names for OMAP4.
Add hwmod device names for OMAP4; this enables device build for omap4 dss
hwmod IPs.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/mach-omap2/display.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5c0a78b..10d699a 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -53,20 +53,27 @@ int __init omap_display_init(struct omap_dss_board_info
/*
* omap: valid DSS hwmod names
-* omap2,3: dss_core, dss_dispc, dss_rfbi, dss_venc
-* omap3: dss_dsi1
+* omap2,3,4: dss_core, dss_dispc, dss_rfbi, dss_venc
+* omap3,4: dss_dsi1
+* omap4: dss_dsi2, dss_hdmi
*/
- char *oh_name[] = {dss_core, dss_dispc, dss_rfbi, dss_venc,
dss_dsi1};
- char *dev_name[] = { omap_dss, omap_dispc, omap_rfbi,
omap_venc, omap_dsi1 };
+ char *oh_name[] = {dss_core, dss_dispc, dss_rfbi, dss_venc,
dss_dsi1,
+ dss_dsi2, dss_hdmi};
+ char *dev_name[] = {omap_dss, omap_dispc, omap_rfbi, omap_venc,
omap_dsi1,
+ omap_dsi2, omap_hdmi};
int oh_count;
memset(pdata, 0, sizeof(pdata));
if (cpu_is_omap24xx())
- oh_count = ARRAY_SIZE(oh_name) - 1;
- /* last hwmod dev in oh_name is not available for omap2 */
- else
+ oh_count = ARRAY_SIZE(oh_name) - 3;
+ /* last 3 hwmod dev in oh_name are not available for omap2 */
+ else if (cpu_is_omap44xx())
oh_count = ARRAY_SIZE(oh_name);
+ else
+ oh_count = ARRAY_SIZE(oh_name) - 2;
+ /* last 2 hwmod dev in oh_name are not available for omap3 */
+
pdata.board_data = board_data;
pdata.board_data-get_last_off_on_transaction_id = NULL;
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
From: Sutharsan Ramamoorthy s...@cypress.com This patch fixes errors reported by checkpatch.pl in westbridge device controller driver in the staging tree. File containing EXPORT_SYMBOL() macros for all the APIs exported by the westbridge software has been removed. EXPORT_SYMBOL() macros are added after the corresponding function definitions. Signed-off-by: Sutharsan Ramamoorthy s...@cypress.com --- diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmisc.c linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmisc.c --- linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmisc.c 2010-11-29 20:42:04.0 -0800 +++ linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmisc.c 2011-01-19 11:55:07.842669281 -0800 @@ -926,6 +926,8 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_get_firmware_version); + static cy_as_return_status_t my_handle_response_read_m_c_u_register(cy_as_device *dev_p, cy_as_ll_request_response *req_p, @@ -1115,7 +1117,7 @@ destroy: return ret; } - +EXPORT_SYMBOL(cy_as_misc_read_m_c_u_register); cy_as_return_status_t cy_as_misc_write_m_c_u_register(cy_as_device_handle handle, @@ -1336,6 +1338,7 @@ cy_as_misc_reset(cy_as_device_handle han return ret; } +EXPORT_SYMBOL(cy_as_misc_reset); static cy_as_return_status_t get_unallocated_resource(cy_as_device *dev_p, cy_as_resource_type resource) @@ -1508,6 +1511,8 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_acquire_resource); + cy_as_return_status_t cy_as_misc_release_resource(cy_as_device_handle handle, cy_as_resource_type resource) @@ -1560,6 +1565,7 @@ cy_as_misc_release_resource(cy_as_device return CY_AS_ERROR_SUCCESS; } +EXPORT_SYMBOL(cy_as_misc_release_resource); cy_as_return_status_t cy_as_misc_set_trace_level(cy_as_device_handle handle, @@ -1718,6 +1724,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_heart_beat_control); static cy_as_return_status_t my_set_sd_clock_freq( @@ -1805,6 +1812,7 @@ cy_as_misc_set_low_speed_sd_freq( return my_set_sd_clock_freq(dev_p, 0, (uint8_t)setting, cb, client); } +EXPORT_SYMBOL(cy_as_misc_set_low_speed_sd_freq); cy_as_return_status_t cy_as_misc_set_high_speed_sd_freq( @@ -1830,6 +1838,7 @@ cy_as_misc_set_high_speed_sd_freq( return my_set_sd_clock_freq(dev_p, 1, (uint8_t)setting, cb, client); } +EXPORT_SYMBOL(cy_as_misc_set_high_speed_sd_freq); cy_as_return_status_t cy_as_misc_get_gpio_value(cy_as_device_handle handle, @@ -1921,7 +1930,7 @@ destroy: return ret; } - +EXPORT_SYMBOL(cy_as_misc_get_gpio_value); cy_as_return_status_t cy_as_misc_set_gpio_value(cy_as_device_handle handle, @@ -2020,6 +2029,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_set_gpio_value); static cy_as_return_status_t my_enter_standby(cy_as_device *dev_p, cy_bool pin) @@ -2213,6 +2223,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_enter_standby); cy_as_return_status_t cy_as_misc_enter_standby_e_x_u(cy_as_device_handle handle, @@ -2425,6 +2436,7 @@ try_wakeup_again: return ret; } +EXPORT_SYMBOL(cy_as_misc_leave_standby); cy_as_return_status_t cy_as_misc_register_callback( @@ -2526,7 +2538,7 @@ destroy: return ret; } - +EXPORT_SYMBOL(cy_as_misc_storage_changed); cy_as_return_status_t cy_as_misc_enter_suspend( @@ -2634,6 +2646,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_enter_suspend); cy_as_return_status_t cy_as_misc_leave_suspend( @@ -2704,6 +2717,7 @@ cy_as_misc_leave_suspend( return ret; } +EXPORT_SYMBOL(cy_as_misc_leave_suspend); cy_as_return_status_t cy_as_misc_reserve_l_n_a_boot_area(cy_as_device_handle handle, diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmtp.c linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmtp.c --- linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmtp.c 2010-11-29 20:42:04.0 -0800 +++ linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmtp.c 2011-01-14 12:04:06.786111000 -0800 @@ -402,6 +402,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_mtp_start); static cy_as_return_status_t my_handle_response_mtp_stop(cy_as_device *dev_p, @@ -744,6 +745,7 @@ cy_as_mtp_init_send_object(cy_as_device_ client, CY_RQT_INIT_SEND_OBJECT); } +EXPORT_SYMBOL(cy_as_mtp_init_send_object); cy_as_return_status_t cy_as_mtp_init_get_object(cy_as_device_handle handle, @@ -763,6 +765,7 @@ cy_as_mtp_init_get_object(cy_as_device_h transaction_id, cb, client, CY_RQT_INIT_GET_OBJECT); } +EXPORT_SYMBOL(cy_as_mtp_init_get_object); static cy_as_return_status_t my_handle_response_cancel_send_object(cy_as_device *dev_p, @@
[PATCH] Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
From: Sutharsan Ramamoorthy s...@cypress.com This patch fixes errors reported by checkpatch.pl in westbridge device controller driver in the staging tree. File containing EXPORT_SYMBOL() macros for all the APIs exported by the westbridge software has been removed. EXPORT_SYMBOL() macros are added after the corresponding function definitions. Signed-off-by: Sutharsan Ramamoorthy s...@cypress.com --- diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmisc.c linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmisc.c --- linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmisc.c 2010-11-29 20:42:04.0 -0800 +++ linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmisc.c 2011-01-19 11:55:07.842669281 -0800 @@ -926,6 +926,8 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_get_firmware_version); + static cy_as_return_status_t my_handle_response_read_m_c_u_register(cy_as_device *dev_p, cy_as_ll_request_response *req_p, @@ -1115,7 +1117,7 @@ destroy: return ret; } - +EXPORT_SYMBOL(cy_as_misc_read_m_c_u_register); cy_as_return_status_t cy_as_misc_write_m_c_u_register(cy_as_device_handle handle, @@ -1336,6 +1338,7 @@ cy_as_misc_reset(cy_as_device_handle han return ret; } +EXPORT_SYMBOL(cy_as_misc_reset); static cy_as_return_status_t get_unallocated_resource(cy_as_device *dev_p, cy_as_resource_type resource) @@ -1508,6 +1511,8 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_acquire_resource); + cy_as_return_status_t cy_as_misc_release_resource(cy_as_device_handle handle, cy_as_resource_type resource) @@ -1560,6 +1565,7 @@ cy_as_misc_release_resource(cy_as_device return CY_AS_ERROR_SUCCESS; } +EXPORT_SYMBOL(cy_as_misc_release_resource); cy_as_return_status_t cy_as_misc_set_trace_level(cy_as_device_handle handle, @@ -1718,6 +1724,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_heart_beat_control); static cy_as_return_status_t my_set_sd_clock_freq( @@ -1805,6 +1812,7 @@ cy_as_misc_set_low_speed_sd_freq( return my_set_sd_clock_freq(dev_p, 0, (uint8_t)setting, cb, client); } +EXPORT_SYMBOL(cy_as_misc_set_low_speed_sd_freq); cy_as_return_status_t cy_as_misc_set_high_speed_sd_freq( @@ -1830,6 +1838,7 @@ cy_as_misc_set_high_speed_sd_freq( return my_set_sd_clock_freq(dev_p, 1, (uint8_t)setting, cb, client); } +EXPORT_SYMBOL(cy_as_misc_set_high_speed_sd_freq); cy_as_return_status_t cy_as_misc_get_gpio_value(cy_as_device_handle handle, @@ -1921,7 +1930,7 @@ destroy: return ret; } - +EXPORT_SYMBOL(cy_as_misc_get_gpio_value); cy_as_return_status_t cy_as_misc_set_gpio_value(cy_as_device_handle handle, @@ -2020,6 +2029,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_set_gpio_value); static cy_as_return_status_t my_enter_standby(cy_as_device *dev_p, cy_bool pin) @@ -2213,6 +2223,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_enter_standby); cy_as_return_status_t cy_as_misc_enter_standby_e_x_u(cy_as_device_handle handle, @@ -2425,6 +2436,7 @@ try_wakeup_again: return ret; } +EXPORT_SYMBOL(cy_as_misc_leave_standby); cy_as_return_status_t cy_as_misc_register_callback( @@ -2526,7 +2538,7 @@ destroy: return ret; } - +EXPORT_SYMBOL(cy_as_misc_storage_changed); cy_as_return_status_t cy_as_misc_enter_suspend( @@ -2634,6 +2646,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_misc_enter_suspend); cy_as_return_status_t cy_as_misc_leave_suspend( @@ -2704,6 +2717,7 @@ cy_as_misc_leave_suspend( return ret; } +EXPORT_SYMBOL(cy_as_misc_leave_suspend); cy_as_return_status_t cy_as_misc_reserve_l_n_a_boot_area(cy_as_device_handle handle, diff -uprN -X linux-2.6.37_vanilla/Documentation/dontdiff linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmtp.c linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmtp.c --- linux-2.6.37_vanilla/drivers/staging/westbridge/astoria/api/src/cyasmtp.c 2010-11-29 20:42:04.0 -0800 +++ linux-2.6.37-wb/drivers/staging/westbridge/astoria/api/src/cyasmtp.c 2011-01-14 12:04:06.786111000 -0800 @@ -402,6 +402,7 @@ destroy: return ret; } +EXPORT_SYMBOL(cy_as_mtp_start); static cy_as_return_status_t my_handle_response_mtp_stop(cy_as_device *dev_p, @@ -744,6 +745,7 @@ cy_as_mtp_init_send_object(cy_as_device_ client, CY_RQT_INIT_SEND_OBJECT); } +EXPORT_SYMBOL(cy_as_mtp_init_send_object); cy_as_return_status_t cy_as_mtp_init_get_object(cy_as_device_handle handle, @@ -763,6 +765,7 @@ cy_as_mtp_init_get_object(cy_as_device_h transaction_id, cb, client, CY_RQT_INIT_GET_OBJECT); } +EXPORT_SYMBOL(cy_as_mtp_init_get_object); static cy_as_return_status_t my_handle_response_cancel_send_object(cy_as_device *dev_p, @@
RE: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions
-Original Message-
From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of
Colin Cross
Sent: Wednesday, January 26, 2011 2:25 AM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; linux-
o...@vger.kernel.org; catalin.mari...@arm.com;
li...@arm.linux.org.uk; linus.ml.wall...@gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
specific extensions
On Mon, Jan 24, 2011 at 7:03 PM, Colin Cross ccr...@android.com
wrote:
On Mon, Jan 24, 2011 at 12:51 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Few architectures combine the GIC with an external interrupt
controller.
On such systems it may be necessary to update both the GIC
registers
and the external controller's registers to control IRQ behavior.
This can be addressed in couple of possible methods.
1. Export common GIC routines along with 'struct irq_chip
gic_chip'
and allow architectures to have custom function by
override.
2. Provide architecture specific function pointer hooks
within GIC library and leave platforms to add the
necessary
code as part of these hooks.
First one might be non-intrusive but have few shortcomings like
arch needs
to have there own custom gic library. Locks used should be common
since it
caters to same IRQs etc. Maintenance point of view also it leads
to
multiple file fixes.
The second probably is cleaner and portable. It ensures that all
the
common GIC infrastructure is not touched and also provides archs
to
address their specific issue.
This method would work for most of Tegra's needs, although we
would
need gic_set_type and gic_ack_irq to have arch extensions as well.
However, it does not allow for irq_retrigger, which can be
implemented
on Tegra.
irq_retrigger does work with this method, the core IRQ code checks
for
a return value if the retrigger was successful. Tegra works with
your
patch along with these changes:
Great.
Can I fold below changes in my patch and add you ack and tested-by?
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 0b6c043..7993f07 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct irq_data
*d)
static void gic_ack_irq(struct irq_data *d)
{
spin_lock(irq_controller_lock);
+ if (gic_arch_extn.irq_ack)
+ gic_arch_extn.irq_ack(d);
writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(irq_controller_lock);
}
@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
unsigned int type)
return 0;
}
+static int gic_retrigger(struct irq_data *d)
+{
+ if (gic_arch_extn.irq_retrigger)
+ return gic_arch_extn.irq_retrigger(d);
+
+ return 0;
+}
+
#ifdef CONFIG_SMP
static int
gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
bool force)
@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_set_type = gic_set_type,
+ .irq_retrigger = gic_retrigger,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] ARM: gic: Add hooks for architecture specific extensions
On Tue, Jan 25, 2011 at 11:22 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of
Colin Cross
Sent: Wednesday, January 26, 2011 2:25 AM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; linux-
o...@vger.kernel.org; catalin.mari...@arm.com;
li...@arm.linux.org.uk; linus.ml.wall...@gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
specific extensions
On Mon, Jan 24, 2011 at 7:03 PM, Colin Cross ccr...@android.com
wrote:
On Mon, Jan 24, 2011 at 12:51 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
Few architectures combine the GIC with an external interrupt
controller.
On such systems it may be necessary to update both the GIC
registers
and the external controller's registers to control IRQ behavior.
This can be addressed in couple of possible methods.
1. Export common GIC routines along with 'struct irq_chip
gic_chip'
and allow architectures to have custom function by
override.
2. Provide architecture specific function pointer hooks
within GIC library and leave platforms to add the
necessary
code as part of these hooks.
First one might be non-intrusive but have few shortcomings like
arch needs
to have there own custom gic library. Locks used should be common
since it
caters to same IRQs etc. Maintenance point of view also it leads
to
multiple file fixes.
The second probably is cleaner and portable. It ensures that all
the
common GIC infrastructure is not touched and also provides archs
to
address their specific issue.
This method would work for most of Tegra's needs, although we
would
need gic_set_type and gic_ack_irq to have arch extensions as well.
However, it does not allow for irq_retrigger, which can be
implemented
on Tegra.
irq_retrigger does work with this method, the core IRQ code checks
for
a return value if the retrigger was successful. Tegra works with
your
patch along with these changes:
Great.
Can I fold below changes in my patch and add you ack and tested-by?
Sure
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 0b6c043..7993f07 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct irq_data
*d)
static void gic_ack_irq(struct irq_data *d)
{
spin_lock(irq_controller_lock);
+ if (gic_arch_extn.irq_ack)
+ gic_arch_extn.irq_ack(d);
writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(irq_controller_lock);
}
@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
unsigned int type)
return 0;
}
+static int gic_retrigger(struct irq_data *d)
+{
+ if (gic_arch_extn.irq_retrigger)
+ return gic_arch_extn.irq_retrigger(d);
+
+ return 0;
+}
+
#ifdef CONFIG_SMP
static int
gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
bool force)
@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_set_type = gic_set_type,
+ .irq_retrigger = gic_retrigger,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] ARM: gic: Add hooks for architecture specific extensions
-Original Message-
From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of
Colin Cross
Sent: Wednesday, January 26, 2011 12:54 PM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; linux-
o...@vger.kernel.org; catalin.mari...@arm.com;
li...@arm.linux.org.uk; linus.ml.wall...@gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
specific extensions
[]
Great.
Can I fold below changes in my patch and add you ack and tested-
by?
Sure
After reading your initial comment, you mentioned you need to have
'gic_set_type' as well. Is this still true. If yes then we need to
have arch_extn call for that as well.
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 0b6c043..7993f07 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct
irq_data
*d)
static void gic_ack_irq(struct irq_data *d)
{
spin_lock(irq_controller_lock);
+ if (gic_arch_extn.irq_ack)
+ gic_arch_extn.irq_ack(d);
writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(irq_controller_lock);
}
@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
unsigned int type)
return 0;
}
+static int gic_retrigger(struct irq_data *d)
+{
+ if (gic_arch_extn.irq_retrigger)
+ return gic_arch_extn.irq_retrigger(d);
+
+ return 0;
+}
+
#ifdef CONFIG_SMP
static int
gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
bool force)
@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_set_type = gic_set_type,
+ .irq_retrigger = gic_retrigger,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] ARM: gic: Add hooks for architecture specific extensions
On Tue, Jan 25, 2011 at 11:31 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original Message-
From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of
Colin Cross
Sent: Wednesday, January 26, 2011 12:54 PM
To: Santosh Shilimkar
Cc: linux-arm-ker...@lists.infradead.org; linux-
o...@vger.kernel.org; catalin.mari...@arm.com;
li...@arm.linux.org.uk; linus.ml.wall...@gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture
specific extensions
[]
Great.
Can I fold below changes in my patch and add you ack and tested-
by?
Sure
After reading your initial comment, you mentioned you need to have
'gic_set_type' as well. Is this still true. If yes then we need to
have arch_extn call for that as well.
You are right, I missed adding the extension for gic_set_type. My
testing doesn't cover that case right now, because I don't have any
drivers updated to linux-next that use a wake source that is
compatible with Tegra's lowest power suspend mode, and that is the
only time the extension to gic_set_type is necessary.
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 0b6c043..7993f07 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct
irq_data
*d)
static void gic_ack_irq(struct irq_data *d)
{
spin_lock(irq_controller_lock);
+ if (gic_arch_extn.irq_ack)
+ gic_arch_extn.irq_ack(d);
writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(irq_controller_lock);
}
@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
unsigned int type)
return 0;
}
+static int gic_retrigger(struct irq_data *d)
+{
+ if (gic_arch_extn.irq_retrigger)
+ return gic_arch_extn.irq_retrigger(d);
+
+ return 0;
+}
+
#ifdef CONFIG_SMP
static int
gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
bool force)
@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
.irq_mask = gic_mask_irq,
.irq_unmask = gic_unmask_irq,
.irq_set_type = gic_set_type,
+ .irq_retrigger = gic_retrigger,
#ifdef CONFIG_SMP
.irq_set_affinity = gic_set_cpu,
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/5] ARM: gic: Add hooks for architecture specific extensions
-Original Message- From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of Colin Cross Sent: Wednesday, January 26, 2011 1:23 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; catalin.mari...@arm.com; li...@arm.linux.org.uk; linus.ml.wall...@gmail.com; Russell King Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions On Tue, Jan 25, 2011 at 11:31 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of Colin Cross Sent: Wednesday, January 26, 2011 12:54 PM To: Santosh Shilimkar Cc: linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; catalin.mari...@arm.com; li...@arm.linux.org.uk; linus.ml.wall...@gmail.com; Russell King Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions [] Great. Can I fold below changes in my patch and add you ack and tested- by? Sure After reading your initial comment, you mentioned you need to have 'gic_set_type' as well. Is this still true. If yes then we need to have arch_extn call for that as well. You are right, I missed adding the extension for gic_set_type. My testing doesn't cover that case right now, because I don't have any drivers updated to linux-next that use a wake source that is compatible with Tegra's lowest power suspend mode, and that is the only time the extension to gic_set_type is necessary. Ok. So I will go ahead and add an extension for the same so that we have most of the usecases covered. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
