Change ARM core rate.
Hello. I have Davinci DM365 board, but I can't find more suitable mail-listing to ask my qustion. I have written Linux kernel module. Main purpose: change ARM core rate. Davinci DM365 has two PLL: PLL1 and PLL2. ARM core can be feed by: * PLLC1SYSCLK1 - fixed all time, equal to 243000 kHz. * PLLC2SYSCLK2 - that one I can change. Lower borde ARM core freq == 121500 kHz (must be pll1_sysclk4 CFG/DMA bus). Higher borde ARM core freq == 30 kHz. To change ARM core freq I do next steps: 1. switch ARM core to PLLC2SYSCLK2 2. reset configure PLL2. 3. switch back to PLLC2SYSCLK2. 4. call adjust_jiffies() ( snatch from cpufreq.c) Now I come to standstill. I got several working configurations, and several not working. I can't undestand why some of them works, and some not. Stable work. Switch between next rates work all times: 272000 (kHz), mul=17, div=2 204000 (kHz), mul=17, div=3 252000 (kHz), mul=21, div=3 201600 (kHz), mul=21, div=4 20 (kHz), mul=25, div=5 249600 (kHz), mul=26, div=4 259200 (kHz), mul=27, div=4 268800 (kHz), mul=28, div=4 278400 (kHz), mul=29, div=4 232000 (kHz), mul=29, div=5 205714 (kHz), mul=30, div=6 297600 (kHz), mul=31, div=4 248000 (kHz), mul=31, div=5 212571 (kHz), mul=31, div=6 186000 (kHz), mul=31, div=7 Don't work - (completely instantaneously hang system): 144000 (kHz), mul=3, div=0 18 (kHz), mul=15, div=3 136000 (kHz), mul=17, div=5 126000 (kHz), mul=21, div=7 157714 (kHz), mul=23, div=6 171428 (kHz), mul=25, div=6 13 (kHz), mul=25, div=8 178285 (kHz), mul=26, div=6 162000 (kHz), mul=27, div=7 174000 (kHz), mul=29, div=7 165333 (kHz), mul=31, div=8 158400 (kHz), mul=33, div=9 296000 (kHz), mul=37, div=5 203076 (kHz), mul=55, div=12 299076 (kHz), mul=81, div=12 Can anybody comment this behaviour? If frequency == 222 000 kHz than system behave quite unstable. And give next messages: Backtrace: Г„c0074c9cГњ (add_to_page_cache_lru+0x0/0xac) from Г„c0074dbcГњ (grab_cache_page_write_begin+0x74/0x9c) r5:c46d4268 r4:c03dc480 Г„c0074d48Гњ (grab_cache_page_write_begin+0x0/0x9c) from Г„c00f35b8Гњ (ext3_write_begin+0x80/0x240) Г„c00f3538Гњ (ext3_write_begin+0x0/0x240) from Г„c0073d10Гњ (generic_file_buffered_write+0xf0/0x258) Г„c0073c20Гњ (generic_file_buffered_write+0x0/0x258) from Г„c0075e64Гњ (__generic_file_aio_write+0x4a8/0x4f8) Г„c00759bcГњ (__generic_file_aio_write+0x0/0x4f8) from Г„c0075f28Гњ (generic_file_aio_write+0x74/0xdc) Г„c0075eb4Гњ (generic_file_aio_write+0x0/0xdc) from Г„c009dc1cГњ (do_sync_readv_writev+0x98/0xe4) Г„c009db84Гњ (do_sync_readv_writev+0x0/0xe4) from Г„c009e2e4Гњ (do_readv_writev+0xb4/0x190) Г„c009e230Гњ (do_readv_writev+0x0/0x190) from Г„c009e42cГњ (vfs_writev+0x6c/0x7c) Г„c009e3c0Гњ (vfs_writev+0x0/0x7c) from Г„c009e510Гњ (sys_writev+0x44/0x70) r5: r4:0030063f Г„c009e4ccГњ (sys_writev+0x0/0x70) from Г„c0028f60Гњ (ret_fast_syscall+0x0/0x2c) Backtrace: Г„c002c2a4Гњ (dump_backtrace+0x0/0x10c) from Г„c029d478Гњ (dump_stack+0x18/0x1c) r7: r6:c3446738 r5:00017000 r4: Г„c029d460Гњ (dump_stack+0x0/0x1c) from Г„c0036c74Гњ (__schedule_bug+0x54/0x60) Г„c0036c20Гњ (__schedule_bug+0x0/0x60) from Г„c029d6ecГњ (schedule+0x68/0x3c4) r4:c34bed4c Г„c029d684Гњ (schedule+0x0/0x3c4) from Г„c00370b8Гњ (__cond_resched+0x18/0x24) Г„c00370a0Гњ (__cond_resched+0x0/0x24) from Г„c029db58Гњ (_cond_resched+0x30/0x40) Г„c029db28Гњ (_cond_resched+0x0/0x40) from Г„c008b0ecГњ (unmap_vmas+0x5d8/0x6a0) Г„c008ab14Гњ (unmap_vmas+0x0/0x6a0) from Г„c008dd68Гњ (exit_mmap+0xd4/0x208) Г„c008dc94Гњ (exit_mmap+0x0/0x208) from Г„c003be60Гњ (mmput+0x40/0xf0) r8: r7:c34bec34 r6:c3442320 r5: r4:c34bec00 Г„c003be20Гњ (mmput+0x0/0xf0) from Г„c0040144Гњ (exit_mm+0x124/0x130) r5:c34bec00 r4: Г„c0040020Гњ (exit_mm+0x0/0x130) from Г„c0041becГњ (do_exit+0x190/0x65c) r7:c49c3bd8 r6:c3442320 r5:c3442320 r4:000b Г„c0041a5cГњ (do_exit+0x0/0x65c) from Г„c002c7e0Гњ (die+0x1c4/0x1f4) Г„c002c61cГњ (die+0x0/0x1f4) from Г„c002c858Гњ (bad_mode+0x48/0x70) Г„c002c810Гњ (bad_mode+0x0/0x70) from Г„c00744f8Гњ (find_get_page+0x30/0xb0) r4:c03dc480 BUG: scheduling while atomic: syslogd/1411/0x4002 Main question is: Why some frequencies are stable, and other does not? -- 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 v4 0/4] Introduce hardware spinlock framework
OMAP4 introduces a Hardware Spinlock device, which provides hardware assistance for synchronization and mutual exclusion between heterogeneous processors and those not operating under a single, shared operating system (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP). The intention of this hardware device is to allow remote processors, that have no alternative mechanism to accomplish synchronization and mutual exclusion operations, to share resources (such as memory and/or any other hardware resource). This patch set adds hwspinlock framework that makes it possible for drivers to use those hwspinlock devices and stay platform-independent. Currently there are two use cases for this hwspinlock interface: 1. Inter-processor communications: on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the remote M3 and/or C64x+ slave processors. To achieve fast message-based communications, a minimal kernel support is needed to deliver messages arriving from a remote processor to the appropriate user process. This communication is based on a simple data structure that is shared between the remote processors, and access to it is synchronized using the hwspinlock module (remote processor directly places new messages in this shared data structure). 2. On some OMAP4 boards, the I2C bus is shared between the A9 and the M3, and the hwspinlock is used to synchronize access to it. While (2) can get away with an omap-specific hwspinlock implementation, (1) is by no means omap-specific, and a common hwspinlock interface is needed to keep it generic, in hopes that it will be useful for other platforms as well. Additional users, besides OMAP4: * Davinci Netra (DM8168) has the same hwspinlock device, and will probably use the same host implementation (this is untested since hardware is not available yet, but the specs looks identical). * Platforms (such as omap3530 and omapl1xx) that have no such hardware support, but would still need to achieve multi-core synchronization (to communicate with their DSP). The only way to achieve mutual exclusion on those platforms is by using a shared-memory synchronization algorithm such as Peterson's Algorithm. We would still need the same hwspinlock framework for that - the busy looping, the timeout, the various locking schemes, the lock resource allocation - are all still valid. The only difference would be the actual lock implementation, therefore we will add another host implementation for these platforms. * The C6474, a multi-core DSP device, have Linux running on one of its cores, and hardware support for synchronization (the C6474 has a richer hardware module that would need more than the hwspinlock framework offer today - it also supports queuing, owner semantics and interrupt notification to let a processor know when it acquires a lock, so it wouldn't have to spin..). Disclaimer: it will probably take some time until c6x support is merged upstream, but this is something that is being actively worked on. For additional information, see http://focus.ti.com/docs/prod/folders/print/tms320c6474.html and http://www.linux-c6x.org/wiki/index.php/Main_Page v3-v4: - Rebased to 2.6.38-rc2 - Added Tony's Acked-by - Use hweight (akpm) v2-v3: - Remove the timeout-less _lock API variant (Tony) - s/state-io_base/io_base/ (Ionut) - Remove the generic wording (David) - s/hwspinlock_/hwspin_lock_/ (Mugdha) - Use MAX_SCHEDULE_TIMEOUT to indicate no timeout (Mugdha) - Be more verbose on egregious API misuse (Olof) - locking API misuse is BUG_ON material (Russell) Note: Russell also suggested compiling out NULL checks on ARM. I've posted an initial proposal for this (see https://lkml.org/lkml/2010/11/29/96), which I'm going to resubmit separately. If accepted, I'll adopt hwspinlocks to use it. v1-v2: - Convert to a generic interface (Tony) - API should silently succeed if framework isn't built (Greg) - Don't use ERR_PTR pattern (Grant) - Use tristate, fix and extend commentary (Kevin) - Provide API flexibility regarding irq handling (Arnd, Grant) Note: after reviewing OMAP's L4 access times, and comparing them with external memory latencies, I can say that there is no notable difference. Because of that, we can safely treat the hwspinlock like we do with regular spinlocks: preemption should be disabled, but whether to disable interrupts or not is up to the caller. So despite the TRM's recommendation to always disable local interrupts when taking an OMAP Hardware Spinlock, I have decided to allow callers not to do that (by providing the full extent of hwspin_lock(), hwspin_lock_irq() and hwspin_lock_irqsave() API). Just like regular spinlocks, it's up to the callers to decide whether interrupts should be disabled or not. Sleeping, btw, is still prohibited of course. Contributions: Previous versions of an omap-specific hwspinlock driver circulated in linux-omap several times, and received substantial attention and
[PATCH v4 1/4] drivers: hwspinlock: add framework
Add a platform-independent hwspinlock framework. Hardware spinlock devices are needed, e.g., in order to access data that is shared between remote processors, that otherwise have no alternative mechanism to accomplish synchronization and mutual exclusion operations. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: Hari Kanigeri h-kanige...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Arnd Bergmann a...@arndb.de Cc: Paul Walmsley p...@pwsan.com Acked-by: Tony Lindgren t...@atomide.com --- Documentation/hwspinlock.txt | 299 ++ drivers/Kconfig |2 + drivers/Makefile |2 + drivers/hwspinlock/Kconfig | 13 + drivers/hwspinlock/Makefile |5 + drivers/hwspinlock/hwspinlock.h | 61 drivers/hwspinlock/hwspinlock_core.c | 557 ++ include/linux/hwspinlock.h | 298 ++ 8 files changed, 1237 insertions(+), 0 deletions(-) create mode 100644 Documentation/hwspinlock.txt create mode 100644 drivers/hwspinlock/Kconfig create mode 100644 drivers/hwspinlock/Makefile create mode 100644 drivers/hwspinlock/hwspinlock.h create mode 100644 drivers/hwspinlock/hwspinlock_core.c create mode 100644 include/linux/hwspinlock.h diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt new file mode 100644 index 000..65324ce --- /dev/null +++ b/Documentation/hwspinlock.txt @@ -0,0 +1,299 @@ +Hardware Spinlock Framework + +1. Introduction + +Hardware spinlock modules provide hardware assistance for synchronization +and mutual exclusion between heterogeneous processors and those not operating +under a single, shared operating system. + +For example, OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP, +each of which is running a different Operating System (the master, A9, +is usually running Linux and the slave processors, the M3 and the DSP, +are running some flavor of RTOS). + +A generic hwspinlock framework allows platform-independent drivers to use +the hwspinlock device in order to access data structures that are shared +between remote processors, that otherwise have no alternative mechanism +to accomplish synchronization and mutual exclusion operations. + +This is necessary, for example, for Inter-processor communications: +on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the +remote M3 and/or C64x+ slave processors (by an IPC subsystem called Syslink). + +To achieve fast message-based communications, a minimal kernel support +is needed to deliver messages arriving from a remote processor to the +appropriate user process. + +This communication is based on simple data structures that is shared between +the remote processors, and access to it is synchronized using the hwspinlock +module (remote processor directly places new messages in this shared data +structure). + +A common hwspinlock interface makes it possible to have generic, platform- +independent, drivers. + +2. User API + + struct hwspinlock *hwspin_lock_request(void); + - dynamically assign an hwspinlock and return its address, or NULL + in case an unused hwspinlock isn't available. Users of this + API will usually want to communicate the lock's id to the remote core + before it can be used to achieve synchronization. + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + struct hwspinlock *hwspin_lock_request_specific(unsigned int id); + - assign a specific hwspinlock id and return its address, or NULL + if that hwspinlock is already in use. Usually board code will + be calling this function in order to reserve specific hwspinlock + ids for predefined purposes. + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + int hwspin_lock_free(struct hwspinlock *hwlock); + - free a previously-assigned hwspinlock; returns 0 on success, or an + appropriate error code on failure (e.g. -EINVAL if the hwspinlock + is already free). + Can be called from an atomic context (this function will not sleep) but + not from within interrupt context. + + int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned long timeout); + - lock a previously-assigned hwspinlock with a timeout limit (specified in + jiffies). If the hwspinlock is already taken, the function will busy loop + waiting for it to be released, but give up when the timeout meets jiffies. + If timeout is 0, the function will never give up (therefore if a faulty + remote core never releases the hwspinlock, it will deadlock). + Upon a successful return from this function, preemption is disabled so + the caller must not sleep, and is advised to release the hwspinlock as + soon as possible, in order to minimize remote cores
[PATCH v4 2/4] drivers: hwspinlock: add OMAP implementation
From: Simon Que s...@ti.com
Add hwspinlock support for the OMAP4 Hardware Spinlock device.
The Hardware Spinlock device on OMAP4 provides hardware assistance
for synchronization between the multiple processors in the system
(dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
[o...@wizery.com: adapt to hwspinlock framework, tidy up]
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Krishnamoorthy, Balaji T balaj...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Arnd Bergmann a...@arndb.de
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/hwspinlock/Kconfig |9 ++
drivers/hwspinlock/Makefile |1 +
drivers/hwspinlock/omap_hwspinlock.c | 231 ++
3 files changed, 241 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwspinlock/omap_hwspinlock.c
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 9dd8db4..eb4af28 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -11,3 +11,12 @@ config HWSPINLOCK
coprocessors).
If unsure, say N.
+
+config HWSPINLOCK_OMAP
+ tristate OMAP Hardware Spinlock device
+ depends on HWSPINLOCK ARCH_OMAP4
+ help
+ Say y here to support the OMAP Hardware Spinlock device (firstly
+ introduced in OMAP4).
+
+ If unsure, say N.
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index b9d2b9f..5729a3f 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_HWSPINLOCK) += hwspinlock_core.o
+obj-$(CONFIG_HWSPINLOCK_OMAP) += omap_hwspinlock.o
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
new file mode 100644
index 000..03e1d60
--- /dev/null
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -0,0 +1,231 @@
+/*
+ * OMAP hardware spinlock driver
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Contact: Simon Que s...@ti.com
+ * Hari Kanigeri h-kanige...@ti.com
+ * Ohad Ben-Cohen o...@wizery.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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/bitops.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/hwspinlock.h
+#include linux/platform_device.h
+
+#include hwspinlock.h
+
+/* Spinlock register offsets */
+#define SYSSTATUS_OFFSET 0x0014
+#define LOCK_BASE_OFFSET 0x0800
+
+#define SPINLOCK_NUMLOCKS_BIT_OFFSET (24)
+
+/* Possible values of SPINLOCK_LOCK_REG */
+#define SPINLOCK_NOTTAKEN (0) /* free */
+#define SPINLOCK_TAKEN (1) /* locked */
+
+#define to_omap_hwspinlock(lock) \
+ container_of(lock, struct omap_hwspinlock, lock)
+
+struct omap_hwspinlock {
+ struct hwspinlock lock;
+ void __iomem *addr;
+};
+
+struct omap_hwspinlock_state {
+ int num_locks; /* Total number of locks in system */
+ void __iomem *io_base; /* Mapped base address */
+};
+
+static int omap_hwspinlock_trylock(struct hwspinlock *lock)
+{
+ struct omap_hwspinlock *omap_lock = to_omap_hwspinlock(lock);
+
+ /* attempt to acquire the lock by reading its value */
+ return (SPINLOCK_NOTTAKEN == readl(omap_lock-addr));
+}
+
+static void omap_hwspinlock_unlock(struct hwspinlock *lock)
+{
+ struct omap_hwspinlock *omap_lock = to_omap_hwspinlock(lock);
+
+ /* release the lock by writing 0 to it */
+ writel(SPINLOCK_NOTTAKEN, omap_lock-addr);
+}
+
+/*
+ * relax the OMAP interconnect while spinning on it.
+ *
+ * The specs recommended that the retry delay time will be
+ * just over half of the time that a requester would be
+ * expected to hold the lock.
+ *
+ * The number below is taken from an hardware specs example,
+ * obviously it is somewhat arbitrary.
+ */
+static void omap_hwspinlock_relax(struct hwspinlock *lock)
+{
+ ndelay(50);
+}
+
+static const struct hwspinlock_ops omap_hwspinlock_ops = {
+ .trylock = omap_hwspinlock_trylock,
+ .unlock = omap_hwspinlock_unlock,
+ .relax = omap_hwspinlock_relax,
+};
+
+static int __devinit omap_hwspinlock_probe(struct platform_device *pdev)
+{
+
[PATCH v4 3/4] OMAP4: hwmod data: Add hwspinlock
From: Benoit Cousson b-cous...@ti.com
Add hwspinlock hwmod data for OMAP4 chip
Signed-off-by: Cousson, Benoit b-cous...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 63
1 files changed, 63 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..e1c8e6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2001,6 +2001,66 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'spinlock' class
+ * spinlock provides hardware assistance for synchronizing the processes
+ * running on multiple processors
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_spinlock_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_spinlock_hwmod_class = {
+ .name = spinlock,
+ .sysc = omap44xx_spinlock_sysc,
+};
+
+/* spinlock */
+static struct omap_hwmod omap44xx_spinlock_hwmod;
+static struct omap_hwmod_addr_space omap44xx_spinlock_addrs[] = {
+ {
+ .pa_start = 0x4a0f6000,
+ .pa_end = 0x4a0f6fff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_cfg - spinlock */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__spinlock = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_spinlock_hwmod,
+ .clk= l4_div_ck,
+ .addr = omap44xx_spinlock_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_spinlock_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* spinlock slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_spinlock_slaves[] = {
+ omap44xx_l4_cfg__spinlock,
+};
+
+static struct omap_hwmod omap44xx_spinlock_hwmod = {
+ .name = spinlock,
+ .class = omap44xx_spinlock_hwmod_class,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM_L4CFG_HW_SEM_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_spinlock_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_spinlock_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
/* dmm class */
@@ -2068,6 +2128,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_wd_timer2_hwmod,
omap44xx_wd_timer3_hwmod,
+
+ /* spinlock class */
+ omap44xx_spinlock_hwmod,
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
[PATCH v4 4/4] omap: add hwspinlock device
From: Simon Que s...@ti.com
Build and register an hwspinlock platform device.
Although only OMAP4 supports the hardware spinlock module (for now),
it is still safe to run this initcall on all omaps, because hwmod lookup
will simply fail on hwspinlock-less platforms.
Signed-off-by: Simon Que s...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/hwspinlock.c | 63 ++
2 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c0c2b0..7b9abe1 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -242,3 +242,4 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
+obj-$(CONFIG_ARCH_OMAP4) += hwspinlock.o
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
new file mode 100644
index 000..06d4a80
--- /dev/null
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -0,0 +1,63 @@
+/*
+ * OMAP hardware spinlock device initialization
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Contact: Simon Que s...@ti.com
+ * Hari Kanigeri h-kanige...@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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/err.h
+
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+
+struct omap_device_pm_latency omap_spinlock_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+int __init hwspinlocks_init(void)
+{
+ int retval = 0;
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ const char *oh_name = spinlock;
+ const char *dev_name = omap_hwspinlock;
+
+ /*
+* Hwmod lookup will fail in case our platform doesn't support the
+* hardware spinlock module, so it is safe to run this initcall
+* on all omaps
+*/
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh == NULL)
+ return -EINVAL;
+
+ od = omap_device_build(dev_name, 0, oh, NULL, 0,
+ omap_spinlock_latency,
+ ARRAY_SIZE(omap_spinlock_latency), false);
+ if (IS_ERR(od)) {
+ pr_err(Can't build omap_device for %s:%s\n, dev_name,
+ oh_name);
+ retval = PTR_ERR(od);
+ }
+
+ return retval;
+}
+/* early board code might need to reserve specific hwspinlock instances */
+postcore_initcall(hwspinlocks_init);
--
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: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR
Hi Santosh, On Sun, Jan 30, 2011 at 6:57 AM, Santosh Shilimkar santosh.shilim...@ti.com wrote: -Original Message- From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com] Sent: Saturday, January 29, 2011 10:45 PM To: jean.pi...@newoldbits.com; linux-omap@vger.kernel.org Cc: Jean Pihet-XID Subject: RE: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR Jean, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of jean.pi...@newoldbits.com Sent: Thursday, January 13, 2011 9:49 PM To: linux-omap@vger.kernel.org Cc: Jean Pihet Subject: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR From: Jean Pihet j-pi...@ti.com Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S) is copied to internal SRAM and run from there. However only a small part of the code really needs to run from internal SRAM. This fix lets most of the ASM idle code run from the DDR in order to minimize the SRAM usage. No performance loss or gain can be measured with a 32KHz clock period. The only pieces of code that are mandatory in SRAM are: - the i443 erratum WA, - the i581 erratum WA, - the security extension code. SRAM usage: - original code: . 560 bytes for omap3_sram_configure_core_dpll (used by DVFS), . 1368 bytes for omap_sram_idle (used by suspend/resume in RETention), . 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x), . 108 bytes for save_secure_ram_context (used on HS parts). With this fix the usage for suspend/resume in RETention goes down 312 bytes, so the gain in SRAM usage for suspend/resume is 1KB. Tested on OMAP3EVM, Beagleboard (ES2.x) and N900 (ES3.1) in idle with full RET and OFF modes. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/pm.h | 19 ++- arch/arm/mach-omap2/pm34xx.c | 19 ++- arch/arm/mach-omap2/sleep34xx.S | 299 +++--- -- --- 3 files changed, 200 insertions(+), 137 deletions(-) [...] diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach- omap2/sleep34xx.S index 98d8232..ced85b5 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -163,8 +163,10 @@ ENTRY(save_secure_ram_context_sz) * * * Notes: - * - this code gets copied to internal SRAM at boot and after wake- up - * from OFF mode. The execution pointer in SRAM is _omap_sram_idle. + * - only the minimum set of functions gets copied to internal SRAM at boot + * and after wake-up from OFF mode, cf. omap_push_sram_idle. The function + * pointers in SDRAM or SRAM are called depending on the desired low power + * target state. * - when the OMAP wakes up it continues at different execution points * depending on the low power mode (non-OFF vs OFF modes), * cf. 'Resume path for xxx mode' comments. @@ -181,9 +183,15 @@ ENTRY(omap34xx_cpu_suspend) * 3 - Both L1 and L2 lost */ - /* Directly jump to WFI is the context save is not required */ - cmp r1, #0x0 - beq omap3_do_wfi + /* + * For OFF mode: save context and jump to WFI in SDRAM (omap3_do_wfi) + * For non-OFF modes: jump to the WFI code in SRAM (omap3_do_wfi_sram) Why is this distinction? For non-low power modes it should be even safer to issue WFI from DDR itself. Do I miss any errata here ? For non-OFF modes the erratum ID i581 WA forces us to restore the SDRC state before accessing the SDRAM, cf. wait_sdrc_ok that implements that. Given that the non-OFF mode triggering WFI needs to be run from SRAM. Looking further into code, I also noticed that the DDR self refresh is attempted for every WFI. This certainly isn't correct and should be attempted only if core OFF or RET is attempted. Putting DDR to self refresh comes with latency cost and you certainly don't want to incur that for lower C states where may be just MPU hits lower states. The DDR self refresh is enabled at each WFI but not necessarily hit. It is actually triggered by the CORE idle request which depends on the settings, the dependencies, the HW states... For example the CORE state depends on the MPU state so if the MPU stays ON running instructions the CORE will stay ON as well. Also the code in wait_sdrc_ok will exit quicker if the CORE DPLL is already locked, e.g. if the CORE did not hit a low power state. Since the actual CORE hit state is unknow after wake-up from WFI the wait_sdrc_ok code always run at wake-up from MPU RET. Does that makes sense? Regards, Santosh Thanks, Jean -- 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: [lm-sensors] [PATCH v3] hwmon: twl4030: Driver for twl4030 madc module
Hi Keerthy, On Sat, Jan 22, 2011 at 10:19:33PM +0530, J, KEERTHY wrote: On Fri, Jan 7, 2011 at 5:42 PM, J, KEERTHY j-keer...@ti.com wrote: On Fri, Jan 7, 2011 at 3:25 AM, Guenter Roeck guenter.ro...@ericsson.com wrote: On Thu, 2011-01-06 at 15:21 -0500, Mark Brown wrote: On Thu, Jan 06, 2011 at 07:04:30AM -0800, Guenter Roeck wrote: On Thu, Jan 06, 2011 at 07:07:13AM -0500, Mark Brown wrote: Why? It's not like hwmon has an unreasonably large core or similar. Because it creates an unnecessary dependency, and because it is not hwmon's responsibility to provide infrastructure for other subsystems or drivers. hwmon isn't really doing anything, though. The *driver* is doing something but it doesn't really impact the core that much. Not that I'm particularly sold on putting the ADC core in here, but total NACK based on that alone seems rather harsh. Possibly. However, I had suggested the following earlier (to the 1st version of the patch): I commented on this a couple of times below - the driver mixes generic ADC reading functions with hwmon functionality. Generic ADC reading functionality should be moved into another driver, possibly to mfd. Obviously that was ignored. Maybe someone is willing to listen this time around. I am sorry for not responding on the generic ADC handling part. Since many other ADC drivers are part of hwmon i thought hwmon was the appropriate place. However I can surely split the generic ADC handling part in mfd and only hardware monitoring part in hwmon as suggested. I won't let people break modularity just for convenience in a subsystem I am responsible for. And forcing the hwmon subsystem, and with it a specific hwmon driver, to exist just because the adc functionality it provides is needed by some other (most likely unrelated) subsystem / driver _does_ break modularity. Worse, it is completely unnecessary to do so. Other twl4030 functionality was extracted into generic code. twl-core.c, twl4030-codec.c, twl4030-irq.c, twl4030-power.c are all in mfd. I fail to see the problem with mfd/twl4030-adc.c. Guenter Hello Samuel, Is it ok to have the generic ADC functionality in mfd as a separate file? Regards, Keerthy Hello Samuel, We need your valuable inputs. Can generic ADC functionality can be in mfd as a separate file? If it's really generic and doesn't mix hwmon stuff in the middle, then yes. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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/PATCH] OMAP3: run the ASM sleep code from DDR
-Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Monday, January 31, 2011 4:07 PM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; Jean Pihet-XID Subject: Re: [RFC/PATCH] OMAP3: run the ASM sleep code from DDR Hi Santosh, [.] + * For OFF mode: save context and jump to WFI in SDRAM (omap3_do_wfi) + * For non-OFF modes: jump to the WFI code in SRAM (omap3_do_wfi_sram) Why is this distinction? For non-low power modes it should be even safer to issue WFI from DDR itself. Do I miss any errata here ? For non-OFF modes the erratum ID i581 WA forces us to restore the SDRC state before accessing the SDRAM, cf. wait_sdrc_ok that implements that. Given that the non-OFF mode triggering WFI needs to be run from SRAM. The errata is applicable when CORE hits low power states and DPLL can autoidle. Not sure how are linking this with all non-OFF modes. Looking further into code, I also noticed that the DDR self refresh is attempted for every WFI. This certainly isn't correct and should be attempted only if core OFF or RET is attempted. Putting DDR to self refresh comes with latency cost and you certainly don't want to incur that for lower C states where may be just MPU hits lower states. The DDR self refresh is enabled at each WFI but not necessarily hit. It is actually triggered by the CORE idle request which depends on the settings, the dependencies, the HW states... For example the CORE state depends on the MPU state so if the MPU stays ON running instructions the CORE will stay ON as well. Also the code in wait_sdrc_ok will exit quicker if the CORE DPLL is already locked, e.g. if the CORE did not hit a low power state. Since the actual CORE hit state is unknow after wake-up from WFI the wait_sdrc_ok code always run at wake-up from MPU RET. Does that makes sense? Actually not. Rather I will separate only the scenario's where CORE low power targets are attempted and only have that code run from SRAM. There are scenario's where CORE can be active because MODEM, DSP and MPU can still hit RET, OFF. And here, the errata isn't applicable. Unless I missed something here, I think in the code we check the the CORE attempted state and based on that we can do a normal WFI from DDR (no self rfersh) or WFI from SRAM with self refresh enabled. 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] i2c: OMAP: fix static suspend vs. runtime suspend
Hi Kevin,
-Original Message-
From: Kevin Hilman [mailto:khil...@ti.com]
Sent: Friday, January 28, 2011 5:49 AM
To: Ben Dooks; Rajendra Nayak; linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; linux...@lists.linux-foundation.org;
linux-arm-ker...@lists.infradead.org
Subject: [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
When runtime PM is enabled, each OMAP i2c device is suspended after
each i2c xfer. However, there are two cases when the static suspend
methods must be used to ensure the devices are suspended:
1) runtime PM is disabled, either at compile time or dynamically
via /sys/devices/.../power/control.
2) an i2c client driver uses i2c during it's suspend callback, thus
leaving the i2c driver active (NOTE: runtime suspend transitions are
disabled during system suspend, so i2c activity during system
suspend will runtime resume the device, but not runtime (re)suspend
it.)
Since the actual work to suspend the device is handled by the
subsytem, call the bus methods to take care of it.
The patch looks good to me. Thanks for the fix.
Validated suspend on OMAP4sdp with the patch.
Can you elaborate a bit more on how/why runtime PM transitions
are disabled during system suspend, and how is it taken care
of that a runtime resume of a device works however a subsequent
runtime (re)suspend does not?
Regards,
Rajendra
NOTE: This takes care of a known suspend problem on OMAP3 where the
TWL RTC driver does i2c xfers during its suspend path leaving the i2c
driver in an active state (since runtime suspend transistions are
disabled.)
Signed-off-by: Kevin Hilman khil...@ti.com
---
Ben, this is a regression in 2.6.38 so hopefully this can be queued
in the 2.6.38-rc cycle. Thanks.
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
b/drivers/i2c/busses/i2c-omap.c
index b605ff3..0541df9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1137,12 +1137,40 @@ omap_i2c_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_SUSPEND
+static int omap_i2c_suspend(struct device *dev)
+{
+ if (!pm_runtime_suspended(dev))
+ if (dev-bus dev-bus-pm
dev-bus-pm-runtime_suspend)
+ dev-bus-pm-runtime_suspend(dev);
+
+ return 0;
+}
+
+static int omap_i2c_resume(struct device *dev)
+{
+ if (!pm_runtime_suspended(dev))
+ if (dev-bus dev-bus-pm
dev-bus-pm-runtime_resume)
+ dev-bus-pm-runtime_resume(dev);
+
+ return 0;
+}
+
+static struct dev_pm_ops omap_i2c_pm_ops = {
+ .suspend = omap_i2c_suspend,
+ .resume = omap_i2c_resume,
+};
+#else
+#define omap_i2c_pm_ops NULL
+#endif
+
static struct platform_driver omap_i2c_driver = {
.probe = omap_i2c_probe,
.remove = omap_i2c_remove,
.driver = {
.name = omap_i2c,
.owner = THIS_MODULE,
+ .pm = omap_i2c_pm_ops,
},
};
--
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
[PATCH] video: omap24xxcam: Fix compilation
Add linux/sched.h because of missing declaration of TASK_NORMAL. This patch fixes the following error: drivers/media/video/omap24xxcam.c: In function 'omap24xxcam_vbq_complete': drivers/media/video/omap24xxcam.c:415: error: 'TASK_NORMAL' undeclared (first use in this function) drivers/media/video/omap24xxcam.c:415: error: (Each undeclared identifier is reported only once drivers/media/video/omap24xxcam.c:415: error: for each function it appears in.) Signed-off-by: Thomas Weber we...@corscience.de --- drivers/media/video/omap24xxcam.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap24xxcam.c b/drivers/media/video/omap24xxcam.c index 0175527..f6626e8 100644 --- a/drivers/media/video/omap24xxcam.c +++ b/drivers/media/video/omap24xxcam.c @@ -36,6 +36,7 @@ #include linux/clk.h #include linux/io.h #include linux/slab.h +#include linux/sched.h #include media/v4l2-common.h #include media/v4l2-ioctl.h -- 1.7.4.rc3 -- 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/2] OMAP: omap_device: API to modify SYSCONFIG register
Certain peripherals require autoidle bits to be disabled before performing some operations. This patch series provides APIs in omap_device layer to modify the SYSCONFIG register. Since current implementation of PM run time framework does not support changing sysconfig settings during middle of the on going operation, these APIs will support the same. For e.g McBSP 2 and 3 in OMAP3 has sidetone feature which requires autoidle to be disabled before starting the sidetone. McBSP also requires the SYSCONFIG to be in NOIDLE when ELEMENTSYNCH mode is selected for DMA operation. Created on top of linux OMAP master (linux-omap-2.6 :master) Tested on OMAP4430, OMAP3430 and OMAP2430 SDP boards. Verified that this patch series does not break the OMAP1 build. V2: Mutex is replaced with spinlock. V1: * Creates 3 separate API's to change the idle mode to NOIDLE, SMARTIDLE and FORCEIDLE and one more API to change the idlemode to default value based on the hwmod flag. This change is done to align with the discussion on [3] * Added hwmod mutex in omap hwmod APIs that modifies SYSCONFIG register. * omap_hwmod_set_slave_idlemode() is not modified to take true/false kind-of argument since 3 states are associated with SIDLE bits (force, no and smart). These changes were made to align with Benoit's and Paul's comments for a similar patch written by Manjunath [1] for changing MSTANDBY bits. The discussions that happened for the RFC patch can be found at [2] [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39647.html [2]: https://patchwork.kernel.org/patch/134371/ [3]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39615.html Kishon Vijay Abraham I (2): OMAP: hwmod: API to handle autoidle mode OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits arch/arm/mach-omap2/omap_hwmod.c | 36 + arch/arm/plat-omap/include/plat/omap_device.h |6 + arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + arch/arm/plat-omap/omap_device.c | 176 + 4 files changed, 219 insertions(+), 0 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/2] OMAP: hwmod: API to handle autoidle mode
Create a new API that forms a wrapper to _set_module_autoidle()
to modify the AUTOIDLE bit.
This API is intended to be used by drivers that requires direct
manipulation of the AUTOIDLE bits in SYSCONFIG register.
McBSP driver requires autoidle bit to be enabled/disabled while
using sidetone feature.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 36 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e282e35..709543a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1288,6 +1288,42 @@ static int _idle(struct omap_hwmod *oh)
}
/**
+ * omap_hwmod_set_slave_autoidle - set the hwmod's OCP slave autoidle
+ * @oh: struct omap_hwmod *
+ * @autoidle: desired AUTOIDLE bitfield value (0 or 1)
+ *
+ * Sets the IP block's OCP slave autoidle in hardware, and updates our
+ * local copy. Intended to be used by drivers that requires
+ * direct manipulation of the AUTOIDLE bits.
+ * Returns -EINVAL if @oh is null, or passes along the return value
+ * from _set_module_autoidle().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_slave_autoidle(struct omap_hwmod *oh, u8 autoidle)
+{
+ u32 v;
+ int retval = 0;
+ unsigned int long flags;
+
+ if (!oh)
+ return -EINVAL;
+
+ spin_lock_irqsave(oh-_lock, flags);
+
+ v = oh-_sysc_cache;
+
+ retval = _set_module_autoidle(oh, autoidle, v);
+
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ spin_unlock_irqrestore(oh-_lock, flags);
+
+ return retval;
+}
+
+/**
* _shutdown - shutdown an omap_hwmod
* @oh: struct omap_hwmod *
*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1eee85a..76f0274 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -555,6 +555,7 @@ int omap_hwmod_enable_clocks(struct omap_hwmod *oh);
int omap_hwmod_disable_clocks(struct omap_hwmod *oh);
int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh, u8 idlemode);
+int omap_hwmod_set_slave_autoidle(struct omap_hwmod *oh, u8 autoidle);
int omap_hwmod_reset(struct omap_hwmod *oh);
void omap_hwmod_ocp_barrier(struct omap_hwmod *oh);
--
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 v2 2/2] OMAP: omap_device: API to modify AUTOIDLE and SMARTIDLE bits
Provide APIs to be used by the driver in order to modify AUTOIDLE
and SIDLE bits. These APIs in turn call hwmod APIs to modify the
SYSCONFIG register.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/plat-omap/include/plat/omap_device.h |6 +
arch/arm/plat-omap/omap_device.c | 176 +
2 files changed, 182 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index e4c349f..47ad0ab 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -110,6 +110,12 @@ struct powerdomain *omap_device_get_pwrdm(struct
omap_device *od);
u32 omap_device_get_context_loss_count(struct platform_device *pdev);
/* Other */
+int omap_device_noidle(struct omap_device *od);
+int omap_device_smartidle(struct omap_device *od);
+int omap_device_forceidle(struct omap_device *od);
+int omap_device_default_idle(struct omap_device *od);
+int omap_device_enable_autoidle(struct omap_device *od);
+int omap_device_disable_autoidle(struct omap_device *od);
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 57adb27..da8609a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -726,6 +726,182 @@ void __iomem *omap_device_get_rt_va(struct omap_device
*od)
return omap_hwmod_get_mpu_rt_va(od-hwmods[0]);
}
+/**
+ * omap_device_noidle - set the device's slave idlemode to no idle
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to no idle.
+ * Intended to be used by drivers that have some erratum that requires direct
+ * manipulation of the SIDLEMODE bits. Returns -EINVAL if @od is in invalid
+ * state, or passes along the return value from
+ * omap_hwmod_set_slave_idlemode().
+ */
+int omap_device_noidle(struct omap_device *od)
+{
+ int retval = 0, i;
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED) {
+ WARN(1, omap_device: %s.%d: %s() called from invalid state
+ %d\n, od-pdev.name, od-pdev.id, __func__,
+ od-_state);
+ return -EINVAL;
+ }
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ retval |= omap_hwmod_set_slave_idlemode(od-hwmods[i],
+ HWMOD_IDLEMODE_NO);
+
+ return retval;
+}
+
+
+/**
+ * omap_device_smartidle - set the device's slave idlemode to smart idle
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to smart idle.
+ * Intended to be used by drivers that have some erratum that requires direct
+ * manipulation of the SIDLEMODE bits. Returns -EINVAL if @od is in invalid
+ * state, or passes along the return value from
+ * omap_hwmod_set_slave_idlemode().
+ */
+int omap_device_smartidle(struct omap_device *od)
+{
+ int retval = 0, i;
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED) {
+ WARN(1, omap_device: %s.%d: %s() called from invalid state
+ %d\n, od-pdev.name, od-pdev.id, __func__,
+ od-_state);
+ return -EINVAL;
+ }
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ retval |= omap_hwmod_set_slave_idlemode(od-hwmods[i],
+ HWMOD_IDLEMODE_SMART);
+
+ return retval;
+}
+
+
+/**
+ * omap_device_forceidle - set the device's slave idlemode to force idle
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to force idle.
+ * Intended to be used by drivers that have some erratum that requires direct
+ * manipulation of the SIDLEMODE bits. Returns -EINVAL if @od is in invalid
+ * state, or passes along the return value from
+ * omap_hwmod_set_slave_idlemode().
+ */
+int omap_device_forceidle(struct omap_device *od)
+{
+ int retval = 0, i;
+
+ if (od-_state != OMAP_DEVICE_STATE_ENABLED) {
+ WARN(1, omap_device: %s.%d: %s() called from invalid state
+ %d\n, od-pdev.name, od-pdev.id, __func__,
+ od-_state);
+ return -EINVAL;
+ }
+
+ for (i = 0; i od-hwmods_cnt; i++)
+ retval |= omap_hwmod_set_slave_idlemode(od-hwmods[i],
+ HWMOD_IDLEMODE_FORCE);
+
+ return retval;
+}
+
+/**
+ * omap_device_default_idle - set the device's slave idlemode to no idle or
+ * smart idle based on the hwmod flag
+ * @od: struct omap_device *
+ *
+ * Sets the IP block's OCP slave idlemode in hardware to no idle or smart idle
+ * depending on status of the flag HWMOD_SWSUP_SIDLE.
+ * Intended to be used by drivers that have some erratum that
[PATCH v2] OMAP3630: PM: don't warn the user with a trace in case of PM34XX_ERRATUM
In case in user has a OMAP3630 ES1.2 the kernel should warn the user
about the ERRATUM, but using pr_warn instead of WARN_ON is already
enough, as there is nothing else the user can do besides changing the
board.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@canonical.com
---
v1-v2:
* Use pr_warn instead of printk (Kevin Hilman)
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f7b22a1..876eeca 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -464,7 +464,7 @@ void omap_init_power_states(void)
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
omap3_power_states[OMAP3_STATE_C7].valid = 0;
cpuidle_params_table[OMAP3_STATE_C7].valid = 0;
- WARN_ONCE(1, %s: core off state C7 disabled due to i583\n,
+ pr_warn(%s: core off state C7 disabled due to i583\n,
__func__);
}
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a4aa192..88f09da 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -927,8 +927,7 @@ void omap3_pm_off_mode_enable(int enable)
pwrst-pwrdm == core_pwrdm
state == PWRDM_POWER_OFF) {
pwrst-next_state = PWRDM_POWER_RET;
- WARN_ONCE(1,
- %s: Core OFF disabled due to errata i583\n,
+ pr_warn(%s: Core OFF disabled due to errata i583\n,
__func__);
} else {
pwrst-next_state = state;
--
1.7.2.3
--
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] OMAP3: PM: Set/reset T2 bit for Smartreflex on TWL.
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
Sent: Monday, January 24, 2011 11:07 AM
To: linux-omap@vger.kernel.org
Cc: Gopinath, Thara; Gulati, Shweta
Subject: [PATCH V2] OMAP3: PM: Set/reset T2 bit for Smartreflex on TWL.
From: Thara Gopinath th...@ti.com
The smartreflex bit on twl4030 needs to be enabled by default irrespective
of whether smartreflex module is enabled on the OMAP side or not.
This is because without this bit enabled the voltage scaling through
vp forceupdate does not function properly on OMAP3.API added
'omap3_twl_set_sr_bit' with parameter to set/clear SR bit. It is cleared
for platforms where voltage is not scaled using vpforceupdate
or vc_bypass Method. In those cases 'omap3_twl_set_sr_bit' is called
from board file, to make sure this bit is not overwritten in
'omap3_twl_init', a flag 'twl_sr_enable'
is added.
This patch is based on LO PM Branch and Smartreflex has been
tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
OMAP2430 SDP.
The function twl4030_vsel_to_uv (where you have added a call to
omap3_twl_set_sr_bit) method is getting invoked only from vp_volt_debug_get
(which is for debugfs) and omap_vp_get_curr_volt (which no one seems to be
calling). Due to this I was not able to get cpufreq to work.
(I finally got it working by calling omap3_twl_set_sr_bit from omap3_twl_init
instead).
It looks like I'm missing something, maybe an intermediate patch? (I'd applied
your patch manually on 2.6.37).
-Abhilash
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 62
arch/arm/mach-omap2/pm.h |1 +
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 00e1d2b..871a349 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -59,8 +59,15 @@
static bool is_offset_valid;
static u8 smps_offset;
+/*
+ * Flag to ensure Smartreflex bit in TWL
+ * being cleared in board file is not overwritten.
+ */
+static bool twl_sr_enable = true;
+#define TWL4030_DCDC_GLOBAL_CFG0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -269,6 +276,16 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
+ /*
+ * The smartreflex bit on twl4030 needs to be enabled by
+ * default irrespective of whether smartreflex module is
+ * enabled on the OMAP side or not. This is because without
+ * this bit enabled the voltage scaling through
+ * vp forceupdate does not function properly on OMAP3.
+ */
+ if (twl_sr_enable)
+ omap3_twl_set_sr_bit(1);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
@@ -277,3 +294,48 @@ int __init omap3_twl_init(void)
return 0;
}
+
+/**
+ * omap3_twl_set_sr_bit() - API to Set/Clear SR bit on TWL
+ * @flag: Flag to Set/Clear SR bit
+ *
+ * If flag is non zero, enables Smartreflex bit on TWL 4030
+ * to make sure voltage scaling through Vp forceupdate works.
+ * Else, the smartreflex bit on twl4030 is
+ * cleared as there are platforms which use
+ * OMAP3 and T2 but use Synchronized Scaling Hardware
+ * Strategy (ENABLE_VMODE=1) and Direct Strategy Software
+ * Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
+ * in those scenarios this bit is to be cleared.
+ * API returns 0 on sucess, error is returned
+ * if I2C read/write fails.
+ */
+
+int omap3_twl_set_sr_bit(u8 flag)
+{
+ u8 temp;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (flag) {
+ temp |= SMARTREFLEX_ENABLE;
+ twl_sr_enable = true;
+ } else {
+ temp = ~SMARTREFLEX_ENABLE;
+ twl_sr_enable = false;
+ }
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret) {
+err:
+ pr_err(%s: Unable to Read/Write to TWL4030 through I2C bus
+ \n, __func__);
+ return -EINVAL;
+ }
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 704766b..c98be66 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -127,6 +127,7 @@ static inline void
omap_enable_smartreflex_on_init(void) {}
#ifdef CONFIG_TWL4030_CORE
extern int omap3_twl_init(void);
extern int omap4_twl_init(void);
+extern int omap3_twl_set_sr_bit(u8
handling clock nodes with both parent and divider selection
Hi Paul, On OMAP4, some aux clk nodes (part of SCRM) have control for both parent and divider selection. Is there a way in the current clock framework for OMAP's to handle this? Regards, Rajendra -- 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] omap2+: mux: Seperate the pads of a hwmod as static and dynamic.
-Original Message- From: Anand Gadiyar [mailto:gadi...@ti.com] Sent: Saturday, January 29, 2011 2:19 AM To: Sricharan R; linux-omap@vger.kernel.org Cc: Santosh Shilimkar; t...@atomide.com; p...@pwsan.com Subject: RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic. sricharan wrote: 1) All the pads of a hwmod for the device are classified as static/dynamic. If a pad requires remuxing during the device transitions between enable/idle transitions then it is added to the dynamic list, static otherwise. 2) Both the static/dynamic pads of a hwmod are initialised when the device gets enabled. When the device transitions between enable/idle the dynamic pads are remuxed and static pads are skipped. 3) When the driver gets removed both the static and the dynamic pads are muxed to safe mode as default. I haven't taken a look at the code. I do have a few concerns (which may really be non-issues, but I'm pointing them out anyway): - Not all pads have a safe mode. --- And why would you want statically muxed pads to be remuxed into safe mode anyway? What is the advantage of such a change, as against leaving them in a functional mode? There is an option to mux the pads to different mode than safe mode when the driver is removed. Those which do not specify are put to safe mode. With safe mode, the pins becomes a input with no functional interface connected to it. This avoids the either omap or outside device seeing any false logic from the pin. - Many signals are muxed on more than one pad. - Many peripherals need pads to be configured in different mux modes depending on the way a board is wired up. With this, moving pad info to hwmod databases does not sound useful to me. Maybe I do not understand the need for this change, in place of what we have today. The structure for containing the mux data is part of hwmod for the device. The hwmod is not static and it is dynamically populated during the device init, with the data being passed from board files if it is different across boards. The device state transitions (enable/idle) passes the through the hwmod layer, which takes caring of muxing the pins right way for each transition. This helps to mux correctly the 1) shared pins 2) Initialsing the pads 3) Remux only pads that require change during enable/idle transitions. 4) Put the pads to safemode( default) when the driver is unplugged. - Anand -- 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] omap4: board-omap4panda: Initialise the serial pads
-Original Message-
From: Anand Gadiyar [mailto:gadi...@ti.com]
Sent: Saturday, January 29, 2011 2:23 AM
To: Sricharan R; linux-omap@vger.kernel.org
Cc: Santosh Shilimkar; t...@atomide.com; p...@pwsan.com
Subject: RE: [PATCH 4/5] omap4: board-omap4panda: Initialise the serial
pads
Sricharan wrote:
Use the mux framework to initialise the serial pads.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 72
+++-
1 files changed, 71 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b43e3ff..9688ea9 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -370,13 +370,83 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+{ .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ .flags = OMAP_DEVICE_PAD_REMUX_IDLE,
+ .idle = OMAP_MUX_MODE7,
+},
+{ .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart2_rx.uart2_rx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_device_pad serial3_pads[] __initdata = {
+{ .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+},
+{ .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_device_pad serial4_pads[] __initdata = {
+{ .name = uart4_rx.uart4_rx,
+.enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+},
+{ .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+},
+};
+
+static struct omap_board_data serial2_data = {
+.id = 1,
+.pads = serial2_pads,
+.pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static struct omap_board_data serial3_data = {
+.id = 2,
+.pads = serial3_pads,
+.pads_cnt = ARRAY_SIZE(serial3_pads),
+};
+
+static struct omap_board_data serial4_data = {
+.id = 3,
+.pads = serial4_pads,
+.pads_cnt = ARRAY_SIZE(serial4_pads),
+};
+
+static inline void board_serial_init(void)
+{
+omap_serial_init_port(serial2_data);
+omap_serial_init_port(serial3_data);
+omap_serial_init_port(serial4_data);
+}
#else
#define board_mux NULL
+
+static inline void board_serial_init(void)
+{
+omap_serial_init();
+}
#endif
static void __init omap4_panda_init(void)
You are changing the behavior with this patch.
Original code configured all 4 UARTs, while it
appears that your patch changes this to skip UART1.
This is not explained in the changelog. Is this
a deliberate change? Why would you want to do this?
I see that UART1 is not muxed out and all uart1 pads
are all used for alternate functionalities.
So I did not initialize UART1.
However, there was a mistake with serial2 mux
which I have corrected in version2.
- Anand
--
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 3/5] omap3: board-3430sdp: Initialise the serial pads.
Corrected a checkpatch warning.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 86 ++-
1 files changed, 85 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 3b39ef1..896fcde 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -663,6 +663,90 @@ static const struct ehci_hcd_omap_platform_data ehci_pdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial1_pads[] __initdata = {
+ { .name = uart1_cts.uart1_cts,
+ .enable = OMAP_PIN_INPUT|
+ OMAP_PIN_OFF_INPUT_PULLDOWN |
+ OMAP_MUX_MODE0,
+ },
+ { .name = uart1_rts.uart1_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart1_rx.uart1_rx,
+ .enable = OMAP_PIN_INPUT | OMAP_PIN_OFF_INPUT_PULLDOWN |
+ OMAP_MUX_MODE0,
+ },
+ { .name = uart1_tx.uart1_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ { .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_INPUT_PULLDOWN |
+ OMAP_MUX_MODE0,
+ },
+ { .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart2_rx.uart2_rx,
+ .enable = OMAP_PIN_INPUT | OMAP_PIN_OFF_INPUT_PULLDOWN |
+ OMAP_MUX_MODE0,
+ },
+ { .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad serial3_pads[] __initdata = {
+ { .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLDOWN |
+ OMAP_PIN_OFF_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_rx_irrx.uart3_rx_irrx,
+ .enable = OMAP_PIN_INPUT | OMAP_PIN_OFF_INPUT_PULLDOWN |
+ OMAP_MUX_MODE0,
+ },
+ { .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_board_data serial1_data = {
+ .id = 0,
+ .pads = serial1_pads,
+ .pads_cnt = ARRAY_SIZE(serial1_pads),
+};
+
+static struct omap_board_data serial2_data = {
+ .id = 1,
+ .pads = serial2_pads,
+ .pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static struct omap_board_data serial3_data = {
+ .id = 2,
+ .pads = serial3_pads,
+ .pads_cnt = ARRAY_SIZE(serial3_pads),
+};
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init_port(serial1_data);
+ omap_serial_init_port(serial2_data);
+ omap_serial_init_port(serial3_data);
+}
+#else
+#define board_mux NULL
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
#endif
/*
@@ -804,7 +888,7 @@ static void __init omap_3430sdp_init(void)
spi_register_board_info(sdp3430_spi_board_info,
ARRAY_SIZE(sdp3430_spi_board_info));
ads7846_dev_init();
- omap_serial_init();
+ board_serial_init();
usb_musb_init(musb_board_data);
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430);
--
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 v2 4/5] omap4: board-omap4panda: Initialise the serial pads
Removed the remux flags for serial2 cts which was
kept for testing. Passed the serial data to serial
init.
Tested this on omap4panda.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 72 +++-
1 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index b43e3ff..1c65420 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -370,13 +370,81 @@ static int __init omap4_panda_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
-
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+ { .name = uart2_cts.uart2_cts,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ { .name = uart2_rts.uart2_rts,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart2_rx.uart2_rx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ { .name = uart2_tx.uart2_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad serial3_pads[] __initdata = {
+ { .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_rx_irrx.uart3_rx_irrx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_device_pad serial4_pads[] __initdata = {
+ { .name = uart4_rx.uart4_rx,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+ { .name = uart4_tx.uart4_tx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static struct omap_board_data serial2_data = {
+ .id = 1,
+ .pads = serial2_pads,
+ .pads_cnt = ARRAY_SIZE(serial2_pads),
+};
+
+static struct omap_board_data serial3_data = {
+ .id = 2,
+ .pads = serial3_pads,
+ .pads_cnt = ARRAY_SIZE(serial3_pads),
+};
+
+static struct omap_board_data serial4_data = {
+ .id = 3,
+ .pads = serial4_pads,
+ .pads_cnt = ARRAY_SIZE(serial4_pads),
+};
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init_port(serial2_data);
+ omap_serial_init_port(serial3_data);
+ omap_serial_init_port(serial4_data);
+}
#else
#define board_mux NULL
+
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
#endif
static void __init omap4_panda_init(void)
@@ -389,7 +457,7 @@ static void __init omap4_panda_init(void)
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
- omap_serial_init();
+ board_serial_init();
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
--
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 v2 00/13] OMAP: McBSP: hwmod adaptation and runtime conversion
Modify OMAP McBSP driver to use omap hwmod framework and pm runtime APIs. Created on top of linux OMAP master (linux-omap-2.6 :master) Did digital loopback testing on OMAP4430, OMAP3430 and OMAP2430 SDP boards. Verified that this patch series does not break the OMAP1 build. Patch series modifies audio layer and hence would appreciate the help of some audio guy to test this series. Patch series requires the following patch to be present http://permalink.gmane.org/gmane.linux.ports.arm.omap/51132 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51133 http://permalink.gmane.org/gmane.linux.ports.arm.omap/51134 V2: * Added omap_hwmod_lookup() in the callback to omap_hwmod_for_each_by_class() to obtain hwmod data for sidetone. Previously this nesting of hwmod APIs was prevented by the use of mutex. * Added a revision member in hwmod database inorder to facilitate the driver to differentiate between different OMAP. * Created APIs to pass DMA params from McBSP driver to client drivers * Cleaned up sound soc by removing the use of macros to obtain base address and DMA channel number and instead use APIs exposed by the driver. * Removed macros defined in mcbsp driver for data that is obtained from hwmod database V1: * McBSP is designed to use multiple hwmods for a single device when the McBSP device has sidetone feature. * To avoid funcionality break of OMAP1 McBSP in between the series and to keep the patches readable, implementation was done in two steps: - First modify mcbsp driver to use platform_get* APIs - then convert it to use hwmod framework for OMAP2+. * API's like omap_device_noidle() and omap_device_default_idle() is used to change the SYCONFIG register bits. This change is done to align with the discussion on [2] * Use '.rev' of omap_hwmod class to identify OMAP3 specific settings * Use *ST_* macros for idlest_idle bit * Incorporate other general review comments provided for hwmod adpatation of other OMAP driver's (eg., do pdata free after a omap_device_build()) * Retain fclk even after pm_runtime adaptation to facilitate switching of functional clock from one source to another * Add member 'name' to omap_hwmod_addr_space struct so that the driver need not rely on the order to get the proper resource [3]. Discussions related to the first RFC patch can be found at [1] [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg36743.html [2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39615.html [3]: https://patchwork.kernel.org/patch/233211/ Benoit Cousson (1): OMAP4: hwmod data: Add McBSP Charulatha V (3): OMAP2420: hwmod data: Add McBSP OMAP2430: hwmod data: Add McBSP OMAP3: hwmod data: Add McBSP Kishon Vijay Abraham I (9): OMAP: hwmod: Add member 'name' to omap_hwmod_addr_space struct OMAP: McBSP: Convert McBSP to platform device model OMAP3: hwmod: add dev_attr for McBSP sidetone OMAP2+: McBSP: hwmod adaptation for McBSP OMAP: McBSP: use omap_device APIs to modify SYSCONFIG OMAP: McBSP: Add pm runtime support OMAP: McBSP: APIs to pass DMA params from McBSP driver to client drivers ASoC: McBSP: get hw params from McBSP driver OMAP: hwmod: Removal of macros for data that is obtained from hwmod database arch/arm/mach-omap1/mcbsp.c | 383 +++ arch/arm/mach-omap2/mcbsp.c | 228 +++- arch/arm/mach-omap2/omap_hwmod.c |1 + arch/arm/mach-omap2/omap_hwmod_2420_data.c | 167 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 417 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 544 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 321 +++ arch/arm/mach-omap2/prcm-common.h|4 + arch/arm/plat-omap/devices.c | 10 +- arch/arm/plat-omap/include/plat/mcbsp.h | 69 +--- arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +- arch/arm/plat-omap/mcbsp.c | 207 +++--- sound/soc/omap/omap-mcbsp.c | 126 +-- 13 files changed, 2006 insertions(+), 475 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 01/13] OMAP: hwmod: Add member 'name' to omap_hwmod_addr_space struct
Adds a structure member 'name' to 'omap_hwmod_addr_space' structure.
The drivers can use platform_get_resource_byname() to get resource of
type 'IORESOURCE_MEM' by name so that it need not rely on the order to get
the proper resource.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 709543a..7bd4900 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1898,6 +1898,7 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh,
struct resource *res)
os = oh-slaves[i];
for (j = 0; j os-addr_cnt; j++) {
+ (res + r)-name = (os-addr + j)-name;
(res + r)-start = (os-addr + j)-pa_start;
(res + r)-end = (os-addr + j)-pa_end;
(res + r)-flags = IORESOURCE_MEM;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 76f0274..85899a7 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -178,7 +178,8 @@ struct omap_hwmod_omap2_firewall {
#define ADDR_TYPE_RT (1 1)
/**
- * struct omap_hwmod_addr_space - MPU address space handled by the hwmod
+ * struct omap_hwmod_addr_space - address space handled by the hwmod
+ * @name: name of the address space
* @pa_start: starting physical address
* @pa_end: ending physical address
* @flags: (see omap_hwmod_addr_space.flags macros above)
@@ -187,6 +188,7 @@ struct omap_hwmod_omap2_firewall {
* structure. GPMC is one example.
*/
struct omap_hwmod_addr_space {
+ const char *name;
u32 pa_start;
u32 pa_end;
u8 flags;
--
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 v2 03/13] OMAP2420: hwmod data: Add McBSP
From: Charulatha V ch...@ti.com
Add McBSP hwmod data for OMAP2420.
Also add macros in prcm-common.h for idlest bit of OMAP24XX McBSP devices
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 167
arch/arm/mach-omap2/prcm-common.h |4 +
2 files changed, 171 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b85c630..6c8b6ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -87,6 +87,8 @@ static struct omap_hwmod omap2420_uart2_hwmod;
static struct omap_hwmod omap2420_uart3_hwmod;
static struct omap_hwmod omap2420_i2c1_hwmod;
static struct omap_hwmod omap2420_i2c2_hwmod;
+static struct omap_hwmod omap2420_mcbsp1_hwmod;
+static struct omap_hwmod omap2420_mcbsp2_hwmod;
/* L4_CORE - L4_WKUP interface */
static struct omap_hwmod_ocp_if omap2420_l4_core__l4_wkup = {
@@ -864,6 +866,167 @@ static struct omap_hwmod omap2420_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class omap2420_mcbsp_hwmod_class = {
+ .name = mcbsp,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2420_mcbsp1_irqs[] = {
+ { .name = tx, .irq = 59 },
+ { .name = rx, .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp1_sdma_chs[] = {
+ { .name = rx, .dma_req = 32 },
+ { .name = tx, .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp1 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap2420_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcbsp1_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp1_dma_addrs[] = {
+ {
+ .name = dma,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp1_dma = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap2420_mcbsp1_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2420_mcbsp1_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2420_mcbsp1_slaves[] = {
+ omap2420_l4_core__mcbsp1,
+ omap2420_l4_core__mcbsp1_dma,
+};
+
+static struct omap_hwmod omap2420_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap2420_mcbsp_hwmod_class,
+ .mpu_irqs = omap2420_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2420_mcbsp1_irqs),
+ .sdma_reqs = omap2420_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2420_mcbsp1_sdma_chs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap2420_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2420_mcbsp2_irqs[] = {
+ { .name = tx, .irq = 62 },
+ { .name = rx, .irq = 63 },
+};
+
+static struct omap_hwmod_dma_info omap2420_mcbsp2_sdma_chs[] = {
+ { .name = rx, .dma_req = 34 },
+ { .name = tx, .dma_req = 33 },
+};
+
+static struct omap_hwmod_addr_space omap2420_mcbsp2_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48076000,
+ .pa_end = 0x480760ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp2 */
+static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 = {
+ .master = omap2420_l4_core_hwmod,
+ .slave = omap2420_mcbsp2_hwmod,
+ .clk= mcbsp2_ick,
+ .addr = omap2420_mcbsp2_addrs,
+ .addr_cnt =
[PATCH v2 02/13] OMAP: McBSP: Convert McBSP to platform device model
Implement McBSP as platform device and add support for
registering through platform device layer using resource
structures.
Later in this patch series, OMAP2+ McBSP driver would be modified to
use hwmod framework after populating the omap2+ hwmod database.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap1/mcbsp.c | 383 ++---
arch/arm/mach-omap2/mcbsp.c | 704 +-
arch/arm/plat-omap/devices.c| 10 +-
arch/arm/plat-omap/include/plat/mcbsp.h | 14 +-
arch/arm/plat-omap/mcbsp.c | 60 +++-
5 files changed, 966 insertions(+), 205 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index 8209736..2b89ebd 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -10,6 +10,7 @@
*
* Multichannel mode not supported.
*/
+#include linux/ioport.h
#include linux/module.h
#include linux/init.h
#include linux/clk.h
@@ -78,100 +79,344 @@ static struct omap_mcbsp_ops omap1_mcbsp_ops = {
};
#if defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP850)
+struct resource omap7xx_mcbsp_res[][6] = {
+ {
+ {
+ .name = mpu,
+ .start = OMAP7XX_MCBSP1_BASE,
+ .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = dma,
+ .start = OMAP7XX_MCBSP1_BASE,
+ .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = rx,
+ .start = INT_7XX_McBSP1RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = tx,
+ .start = INT_7XX_McBSP1TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = rx,
+ .start = OMAP_DMA_MCBSP1_RX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .name = tx,
+ .start = OMAP_DMA_MCBSP1_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ },
+ {
+ {
+ .name = mpu,
+ .start = OMAP7XX_MCBSP2_BASE,
+ .end = OMAP7XX_MCBSP2_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = dma,
+ .start = OMAP7XX_MCBSP2_BASE,
+ .end = OMAP7XX_MCBSP2_BASE + SZ_256,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = rx,
+ .start = INT_7XX_McBSP2RX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = tx,
+ .start = INT_7XX_McBSP2TX,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .name = rx,
+ .start = OMAP_DMA_MCBSP3_RX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .name = tx,
+ .start = OMAP_DMA_MCBSP3_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ },
+};
+
static struct omap_mcbsp_platform_data omap7xx_mcbsp_pdata[] = {
{
- .phys_base = OMAP7XX_MCBSP1_BASE,
- .dma_rx_sync= OMAP_DMA_MCBSP1_RX,
- .dma_tx_sync= OMAP_DMA_MCBSP1_TX,
- .rx_irq = INT_7XX_McBSP1RX,
- .tx_irq = INT_7XX_McBSP1TX,
.ops= omap1_mcbsp_ops,
},
{
- .phys_base = OMAP7XX_MCBSP2_BASE,
- .dma_rx_sync= OMAP_DMA_MCBSP3_RX,
- .dma_tx_sync= OMAP_DMA_MCBSP3_TX,
- .rx_irq = INT_7XX_McBSP2RX,
- .tx_irq = INT_7XX_McBSP2TX,
.ops= omap1_mcbsp_ops,
},
};
-#define OMAP7XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap7xx_mcbsp_pdata)
-#define OMAP7XX_MCBSP_REG_NUM (OMAP_MCBSP_REG_XCERH / sizeof(u16) + 1)
+#define OMAP7XX_MCBSP_RES_SZ ARRAY_SIZE(omap7xx_mcbsp_res[1])
+#define OMAP7XX_MCBSP_COUNTARRAY_SIZE(omap7xx_mcbsp_res)
#else
+#define omap7xx_mcbsp_res NULL
#define omap7xx_mcbsp_pdataNULL
-#define OMAP7XX_MCBSP_PDATA_SZ 0
-#define OMAP7XX_MCBSP_REG_NUM 0
+#define OMAP7XX_MCBSP_RES_SZ 0
+#define OMAP7XX_MCBSP_COUNT0
#endif
#ifdef CONFIG_ARCH_OMAP15XX
+struct resource omap15xx_mcbsp_res[][6] = {
+
[PATCH v2 04/13] OMAP2430: hwmod data: Add McBSP
From: Charulatha V ch...@ti.com
Add McBSP hwmod data for OMAP2430.
Added a revision member inorder to facilitate the driver to
differentiate between mcbsp in different omap.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 417
arch/arm/plat-omap/include/plat/mcbsp.h|2 +
2 files changed, 419 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 8ecfbcd..4f3f71f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -18,6 +18,7 @@
#include plat/serial.h
#include plat/i2c.h
#include plat/gpio.h
+#include plat/mcbsp.h
#include omap_hwmod_common_data.h
@@ -88,6 +89,11 @@ static struct omap_hwmod omap2430_uart2_hwmod;
static struct omap_hwmod omap2430_uart3_hwmod;
static struct omap_hwmod omap2430_i2c1_hwmod;
static struct omap_hwmod omap2430_i2c2_hwmod;
+static struct omap_hwmod omap2430_mcbsp1_hwmod;
+static struct omap_hwmod omap2430_mcbsp2_hwmod;
+static struct omap_hwmod omap2430_mcbsp3_hwmod;
+static struct omap_hwmod omap2430_mcbsp4_hwmod;
+static struct omap_hwmod omap2430_mcbsp5_hwmod;
/* I2C IP block address space length (in bytes) */
#define OMAP2_I2C_AS_LEN 128
@@ -919,6 +925,410 @@ static struct omap_hwmod omap2430_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2430_mcbsp_sysc = {
+ .rev_offs = 0x007C,
+ .sysc_offs = 0x008C,
+ .sysc_flags = (SYSC_HAS_SOFTRESET),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2430_mcbsp_hwmod_class = {
+ .name = mcbsp,
+ .sysc = omap2430_mcbsp_sysc,
+ .rev = MCBSP_CONFIG_TYPE2,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap2430_mcbsp1_irqs[] = {
+ { .name = tx, .irq = 59 },
+ { .name = rx, .irq = 60 },
+ { .name = ovr,.irq = 61 },
+ { .name = common, .irq = 64 },
+};
+
+static struct omap_hwmod_dma_info omap2430_mcbsp1_sdma_chs[] = {
+ { .name = rx, .dma_req = 32 },
+ { .name = tx, .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap2430_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp1 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap2430_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcbsp1_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap2430_mcbsp1_dma_addrs[] = {
+ {
+ .name = dma,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp1_dma = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap2430_mcbsp1_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap2430_mcbsp1_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap2430_mcbsp1_slaves[] = {
+ omap2430_l4_core__mcbsp1,
+ omap2430_l4_core__mcbsp1_dma,
+};
+
+static struct omap_hwmod omap2430_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap2430_mcbsp_hwmod_class,
+ .mpu_irqs = omap2430_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_mcbsp1_irqs),
+ .sdma_reqs = omap2430_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_mcbsp1_sdma_chs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap2430_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2430_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod_irq_info omap2430_mcbsp2_irqs[] = {
+ { .name = tx, .irq = 62 },
+ { .name = rx, .irq = 63
[PATCH v2 05/13] OMAP3: hwmod data: Add McBSP
From: Charulatha V ch...@ti.com
Add McBSP hwmod data for OMAP3.
Added a revision member inorder to facilitate the driver to
differentiate between mcbsp in different omap.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 534
arch/arm/plat-omap/include/plat/mcbsp.h|1 +
2 files changed, 535 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8d81813..0fb05d5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -22,6 +22,7 @@
#include plat/i2c.h
#include plat/gpio.h
#include plat/smartreflex.h
+#include plat/mcbsp.h
#include omap_hwmod_common_data.h
@@ -58,6 +59,14 @@ static struct omap_hwmod omap34xx_sr2_hwmod;
static struct omap_hwmod omap3xxx_dma_system_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp1_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp2_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp3_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp4_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp5_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp2_sidetone_hwmod;
+static struct omap_hwmod omap3xxx_mcbsp3_sidetone_hwmod;
+
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
.master = omap3xxx_l3_main_hwmod,
@@ -1227,6 +1236,522 @@ static struct omap_hwmod omap3xxx_dma_system_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
+/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap3xxx_mcbsp_sysc = {
+ .sysc_offs = 0x008c,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+ .clockact = 0x2,
+};
+
+static struct omap_hwmod_class omap3xxx_mcbsp_hwmod_class = {
+ .name = mcbsp,
+ .sysc = omap3xxx_mcbsp_sysc,
+ .rev = MCBSP_CONFIG_TYPE3,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod_irq_info omap3xxx_mcbsp1_irqs[] = {
+ { .name = irq, .irq = 16 },
+ { .name = tx, .irq = 59 },
+ { .name = rx, .irq = 60 },
+};
+
+static struct omap_hwmod_dma_info omap3xxx_mcbsp1_sdma_chs[] = {
+ { .name = rx, .dma_req = 32 },
+ { .name = tx, .dma_req = 31 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_core - mcbsp1 */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mcbsp1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap3xxx_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap3xxx_mcbsp1_dma_addrs[] = {
+ {
+ .name = dma,
+ .pa_start = 0x48074000,
+ .pa_end = 0x480740ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mcbsp1_dma = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mcbsp1_hwmod,
+ .clk= mcbsp1_ick,
+ .addr = omap3xxx_mcbsp1_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_mcbsp1_slaves[] = {
+ omap3xxx_l4_core__mcbsp1,
+ omap3xxx_l4_core__mcbsp1_dma,
+};
+
+static struct omap_hwmod omap3xxx_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap3xxx_mcbsp_hwmod_class,
+ .mpu_irqs = omap3xxx_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_irqs),
+ .sdma_reqs = omap3xxx_mcbsp1_sdma_chs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_sdma_chs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id = 1,
+ .module_bit = OMAP3430_EN_MCBSP1_SHIFT,
+ .module_offs = CORE_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_MCBSP1_SHIFT,
+ },
+ },
+ .slaves = omap3xxx_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
[PATCH v2 07/13] OMAP3: hwmod: add dev_attr for McBSP sidetone
Since the sidetone block is tightly coupled to the mcbsp, sidetone information
is directly added to mcbsp2 3 hwmod dev_attr.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 ++
arch/arm/plat-omap/include/plat/mcbsp.h|9 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0fb05d5..7c50609 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1388,6 +1388,10 @@ static struct omap_hwmod_ocp_if
*omap3xxx_mcbsp2_slaves[] = {
omap3xxx_l4_per__mcbsp2_dma,
};
+static struct omap_mcbsp_dev_attr omap34xx_mcbsp2_dev_attr = {
+ .sidetone = mcbsp2_sidetone,
+};
+
static struct omap_hwmod omap3xxx_mcbsp2_hwmod = {
.name = mcbsp2,
.class = omap3xxx_mcbsp_hwmod_class,
@@ -1407,6 +1411,7 @@ static struct omap_hwmod omap3xxx_mcbsp2_hwmod = {
},
.slaves = omap3xxx_mcbsp2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp2_slaves),
+ .dev_attr = omap34xx_mcbsp2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
@@ -1465,6 +1470,10 @@ static struct omap_hwmod_ocp_if
*omap3xxx_mcbsp3_slaves[] = {
omap3xxx_l4_per__mcbsp3_dma,
};
+static struct omap_mcbsp_dev_attr omap34xx_mcbsp3_dev_attr = {
+ .sidetone = mcbsp3_sidetone,
+};
+
static struct omap_hwmod omap3xxx_mcbsp3_hwmod = {
.name = mcbsp3,
.class = omap3xxx_mcbsp_hwmod_class,
@@ -1484,6 +1493,7 @@ static struct omap_hwmod omap3xxx_mcbsp3_hwmod = {
},
.slaves = omap3xxx_mcbsp3_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_mcbsp3_slaves),
+ .dev_attr = omap34xx_mcbsp3_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
};
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 06bd1dc..27bfb1d 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -489,6 +489,15 @@ struct omap_mcbsp {
#endif
void *reg_cache;
};
+
+/**
+ * omap_mcbsp_dev_attr - OMAP MCBSP device attributes for omap_hwmod
+ * @sidetone: name of the sidetone device
+ */
+struct omap_mcbsp_dev_attr {
+ const char *sidetone;
+};
+
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count, omap_mcbsp_cache_size;
--
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 v2 06/13] OMAP4: hwmod data: Add McBSP
From: Benoit Cousson b-cous...@ti.com
Added a revision member inorder to facilitate the driver to
differentiate between mcbsp in different omap.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 321
arch/arm/plat-omap/include/plat/mcbsp.h|1 +
2 files changed, 322 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..a3860df 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -24,6 +24,7 @@
#include plat/cpu.h
#include plat/gpio.h
#include plat/dma.h
+#include plat/mcbsp.h
#include omap_hwmod_common_data.h
@@ -1435,6 +1436,320 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
};
/*
+ * 'mcbsp' class
+ * multi channel buffered serial port controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_mcbsp_sysc = {
+ .sysc_offs = 0x008c,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_ENAWAKEUP |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mcbsp_hwmod_class = {
+ .name = mcbsp,
+ .sysc = omap44xx_mcbsp_sysc,
+ .rev = MCBSP_CONFIG_TYPE4,
+};
+
+/* mcbsp1 */
+static struct omap_hwmod omap44xx_mcbsp1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcbsp1_irqs[] = {
+ { .name = tx, .irq = 17 + OMAP44XX_IRQ_GIC_START },
+ { .name = rx, .irq = 0 },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcbsp1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 32 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 33 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcbsp1_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x40122000,
+ .pa_end = 0x401220ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - mcbsp1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1 = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_mcbsp1_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_mcbsp1_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcbsp1_addrs),
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcbsp1_dma_addrs[] = {
+ {
+ .name = dma,
+ .pa_start = 0x49022000,
+ .pa_end = 0x490220ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - mcbsp1 (dma) */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1_dma = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_mcbsp1_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_mcbsp1_dma_addrs,
+ .addr_cnt = ARRAY_SIZE(omap44xx_mcbsp1_dma_addrs),
+ .user = OCP_USER_SDMA,
+};
+
+/* mcbsp1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_mcbsp1_slaves[] = {
+ omap44xx_l4_abe__mcbsp1,
+ omap44xx_l4_abe__mcbsp1_dma,
+};
+
+static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
+ .name = mcbsp1,
+ .class = omap44xx_mcbsp_hwmod_class,
+ .mpu_irqs = omap44xx_mcbsp1_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_mcbsp1_irqs),
+ .sdma_reqs = omap44xx_mcbsp1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap44xx_mcbsp1_sdma_reqs),
+ .main_clk = mcbsp1_fck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_reg = OMAP4430_CM1_ABE_MCBSP1_CLKCTRL,
+ },
+ },
+ .slaves = omap44xx_mcbsp1_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_mcbsp1_slaves),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* mcbsp2 */
+static struct omap_hwmod omap44xx_mcbsp2_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mcbsp2_irqs[] = {
+ { .name = tx, .irq = 22 + OMAP44XX_IRQ_GIC_START },
+ { .name = rx, .irq = 0 },
+};
+
+static struct omap_hwmod_dma_info omap44xx_mcbsp2_sdma_reqs[] = {
+ { .name = tx, .dma_req = 16 + OMAP44XX_DMA_REQ_START },
+ { .name = rx, .dma_req = 17 + OMAP44XX_DMA_REQ_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mcbsp2_addrs[] = {
+ {
+ .name = mpu,
+ .pa_start = 0x40124000,
+ .pa_end = 0x401240ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* l4_abe - mcbsp2 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2 = {
+ .master =
[PATCH v2 08/13] OMAP2+: McBSP: hwmod adaptation for McBSP
Modify OMAP2+ McBSP to use omap hwmod framework APIs
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/mcbsp.c | 685 +++
1 files changed, 43 insertions(+), 642 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index bc004be..7d0fe2b 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -22,10 +22,10 @@
#include plat/dma.h
#include plat/cpu.h
#include plat/mcbsp.h
+#include plat/omap_device.h
#include control.h
-
/* McBSP internal signal muxing functions */
void omap2_mcbsp1_mux_clkr_src(u8 mux)
@@ -101,664 +101,65 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
}
EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
-
-/* Platform data */
-
-#ifdef CONFIG_SOC_OMAP2420
-struct resource omap2420_mcbsp_res[][6] = {
- {
- {
- .name = mpu,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = dma,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP1_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP1_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP1_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP1_TX,
- .flags = IORESOURCE_DMA,
- },
- },
+struct omap_device_pm_latency omap2_mcbsp_latency[] = {
{
- {
- .name = mpu,
- .start = OMAP24XX_MCBSP2_BASE,
- .end = OMAP24XX_MCBSP2_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = dma,
- .start = OMAP24XX_MCBSP2_BASE,
- .end = OMAP24XX_MCBSP2_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP2_IRQ_RX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = tx,
- .start = INT_24XX_MCBSP2_IRQ_TX,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = rx,
- .start = OMAP24XX_DMA_MCBSP2_RX,
- .flags = IORESOURCE_DMA,
- },
- {
- .name = tx,
- .start = OMAP24XX_DMA_MCBSP2_TX,
- .flags = IORESOURCE_DMA,
- },
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
},
};
-#define OMAP2420_MCBSP_RES_SZ ARRAY_SIZE(omap2420_mcbsp_res[1])
-#define OMAP2420_MCBSP_COUNT ARRAY_SIZE(omap2420_mcbsp_res)
-#else
-#define omap2420_mcbsp_res NULL
-#define OMAP2420_MCBSP_RES_SZ 0
-#define OMAP2420_MCBSP_COUNT 0
-#endif
+static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
+{
+ int id, count = 1;
+ char *name = omap-mcbsp;
+ struct omap_hwmod *oh_device[2];
+ struct omap_mcbsp_platform_data *pdata = NULL;
+ struct omap_device *od;
-#define omap2420_mcbsp_pdata NULL
+ sscanf(oh-name, mcbsp%d, id);
-#ifdef CONFIG_SOC_OMAP2430
-struct resource omap2430_mcbsp_res[][6] = {
- {
- {
- .name = mpu,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = dma,
- .start = OMAP24XX_MCBSP1_BASE,
- .end = OMAP24XX_MCBSP1_BASE + SZ_256,
- .flags = IORESOURCE_MEM,
- },
- {
- .name = rx,
- .start = INT_24XX_MCBSP1_IRQ_RX,
- .flags =
[PATCH v2 09/13] OMAP: McBSP: use omap_device APIs to modify SYSCONFIG
McBSP2/3 in OMAP3 has sidetone feature which requires autoidle
to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, omap_device APIs are used to modify SYSCONFIG register.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/plat-omap/mcbsp.c | 66 +++
1 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 275a37a..9bc2c73 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -27,6 +27,7 @@
#include plat/dma.h
#include plat/mcbsp.h
+#include plat/omap_device.h
/* XXX These sideways includes are a sign that something is wrong */
#include ../mach-omap2/cm2xxx_3xxx.h
@@ -228,9 +229,19 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
EXPORT_SYMBOL(omap_mcbsp_config);
#ifdef CONFIG_ARCH_OMAP3
+static struct omap_device *find_omap_device_by_dev(struct device *dev)
+{
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+ return container_of(pdev, struct omap_device, pdev);
+}
+
static void omap_st_on(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
/*
* Sidetone uses McBSP ICLK - which must not idle when sidetones
@@ -244,8 +255,7 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w | SIDETONEEN);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w ~(ST_AUTOIDLE));
+ omap_device_disable_autoidle(od);
/* Enable Sidetone from Sidetone Core */
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -255,12 +265,14 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
static void omap_st_off(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
w = MCBSP_ST_READ(mcbsp, SSELCR);
MCBSP_ST_WRITE(mcbsp, SSELCR, w ~(ST_SIDETONEEN));
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w | ST_AUTOIDLE);
+ omap_device_enable_autoidle(od);
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w ~(SIDETONEEN));
@@ -273,9 +285,11 @@ static void omap_st_off(struct omap_mcbsp *mcbsp)
static void omap_st_fir_write(struct omap_mcbsp *mcbsp, s16 *fir)
{
u16 val, i;
+ struct omap_device *od;
- val = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, val ~(ST_AUTOIDLE));
+ od = find_omap_device_by_dev(mcbsp-dev);
+
+ omap_device_disable_autoidle(od);
val = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -303,9 +317,11 @@ static void omap_st_chgain(struct omap_mcbsp *mcbsp)
{
u16 w;
struct omap_mcbsp_st_data *st_data = mcbsp-st_data;
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w ~(ST_AUTOIDLE));
+ omap_device_disable_autoidle(od);
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -648,49 +664,37 @@ EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
{
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
/*
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- u16 syscon;
-
- syscon = MCBSP_READ(mcbsp, SYSCON);
- syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
-
- if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
- syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
- CLOCKACTIVITY(0x02));
+ if (mcbsp-dma_op_mode != MCBSP_DMA_MODE_THRESHOLD)
+ omap_device_noidle(od);
+ else
MCBSP_WRITE(mcbsp, WAKEUPEN, XRDYEN | RRDYEN);
- } else {
- syscon |= SIDLEMODE(0x01);
- }
-
- MCBSP_WRITE(mcbsp, SYSCON, syscon);
}
}
static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp)
{
+ struct omap_device *od;
+
+ od = find_omap_device_by_dev(mcbsp-dev);
+
/*
* Disable wakup behavior, smart idle and all wakeups
*/
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- u16 syscon;
-
- syscon = MCBSP_READ(mcbsp, SYSCON);
- syscon = ~(ENAWAKEUP |
[PATCH v2 10/13] OMAP: McBSP: Add pm runtime support
Add pm runtime support for McBSP driver.
Reference to fclk is not removed because it is required when the
functional clock is switched from one source to another.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/mcbsp.c |5 +++--
arch/arm/plat-omap/include/plat/mcbsp.h |1 -
arch/arm/plat-omap/mcbsp.c | 23 ++-
3 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7d0fe2b..e232a49 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -23,6 +23,7 @@
#include plat/cpu.h
#include plat/mcbsp.h
#include plat/omap_device.h
+#include linux/pm_runtime.h
#include control.h
@@ -83,7 +84,7 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
return -EINVAL;
}
- clk_disable(mcbsp-fclk);
+ pm_runtime_put_sync(mcbsp-dev);
r = clk_set_parent(mcbsp-fclk, fck_src);
if (IS_ERR_VALUE(r)) {
@@ -93,7 +94,7 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
return -EINVAL;
}
- clk_enable(mcbsp-fclk);
+ pm_runtime_get_sync(mcbsp-dev);
clk_put(fck_src);
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 27bfb1d..75c176c 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -479,7 +479,6 @@ struct omap_mcbsp {
/* Protect the field .free, while checking if the mcbsp is in use */
spinlock_t lock;
struct omap_mcbsp_platform_data *pdata;
- struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP3
struct omap_mcbsp_st_data *st_data;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 9bc2c73..63938a2 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -28,6 +28,7 @@
#include plat/dma.h
#include plat/mcbsp.h
#include plat/omap_device.h
+#include linux/pm_runtime.h
/* XXX These sideways includes are a sign that something is wrong */
#include ../mach-omap2/cm2xxx_3xxx.h
@@ -768,8 +769,7 @@ int omap_mcbsp_request(unsigned int id)
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-request)
mcbsp-pdata-ops-request(id);
- clk_enable(mcbsp-iclk);
- clk_enable(mcbsp-fclk);
+ pm_runtime_get_sync(mcbsp-dev);
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_request(mcbsp);
@@ -817,8 +817,7 @@ err_clk_disable:
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_free(mcbsp);
- clk_disable(mcbsp-fclk);
- clk_disable(mcbsp-iclk);
+ pm_runtime_put_sync(mcbsp-dev);
spin_lock(mcbsp-lock);
mcbsp-free = true;
@@ -848,8 +847,7 @@ void omap_mcbsp_free(unsigned int id)
/* Do procedure specific to omap34xx arch, if applicable */
omap34xx_mcbsp_free(mcbsp);
- clk_disable(mcbsp-fclk);
- clk_disable(mcbsp-iclk);
+ pm_runtime_put_sync(mcbsp-dev);
if (mcbsp-io_type == OMAP_MCBSP_IRQ_IO) {
/* Free IRQs */
@@ -1862,32 +1860,24 @@ static int __devinit omap_mcbsp_probe(struct
platform_device *pdev)
}
mcbsp-dma_tx_sync = res-start;
- mcbsp-iclk = clk_get(pdev-dev, ick);
- if (IS_ERR(mcbsp-iclk)) {
- ret = PTR_ERR(mcbsp-iclk);
- dev_err(pdev-dev, unable to get ick: %d\n, ret);
- goto err_res;
- }
-
mcbsp-fclk = clk_get(pdev-dev, fck);
if (IS_ERR(mcbsp-fclk)) {
ret = PTR_ERR(mcbsp-fclk);
dev_err(pdev-dev, unable to get fck: %d\n, ret);
- goto err_fclk;
+ goto err_res;
}
mcbsp-pdata = pdata;
mcbsp-dev = pdev-dev;
mcbsp_ptr[id] = mcbsp;
platform_set_drvdata(pdev, mcbsp);
+ pm_runtime_enable(mcbsp-dev);
/* Initialize mcbsp properties for OMAP34XX if needed / applicable */
omap34xx_device_init(mcbsp);
return 0;
-err_fclk:
- clk_put(mcbsp-iclk);
err_res:
iounmap(mcbsp-io_base);
err_ioremap:
@@ -1910,7 +1900,6 @@ static int __devexit omap_mcbsp_remove(struct
platform_device *pdev)
omap34xx_device_exit(mcbsp);
clk_put(mcbsp-fclk);
- clk_put(mcbsp-iclk);
iounmap(mcbsp-io_base);
kfree(mcbsp);
--
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 v2 11/13] OMAP: McBSP: APIs to pass DMA params from McBSP driver to client drivers
After McBSP driver is hwmod adapted, the information about the hw would be
obtained from the hwmod database by the mcbsp driver. Since DMA programming is
handled by the client driver, APIs are provided to pass the DMA channel number
and base address of data register required by the client driver for DMA
programming.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap2/mcbsp.c |2 +
arch/arm/plat-omap/include/plat/mcbsp.h |7 +++
arch/arm/plat-omap/mcbsp.c | 64 +++
3 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index e232a49..3e87527 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -125,6 +125,8 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
return -ENOMEM;
}
+ pdata-mcbsp_config_type = oh-class-rev;
+
if (oh-class-rev == MCBSP_CONFIG_TYPE3) {
if (id == 2)
pdata-buffer_size = 0x500; /*FIFO size is 1024 + 256*/
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 75c176c..54058a3 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -81,6 +81,8 @@ static struct platform_device omap_mcbsp##port_nr = { \
#define OMAP_MCBSP_REG_DRR10x02
#define OMAP_MCBSP_REG_DXR20x04
#define OMAP_MCBSP_REG_DXR10x06
+#define OMAP_MCBSP_REG_DRR 0x02
+#define OMAP_MCBSP_REG_DXR 0x06
#define OMAP_MCBSP_REG_SPCR2 0x08
#define OMAP_MCBSP_REG_SPCR1 0x0a
#define OMAP_MCBSP_REG_RCR20x0c
@@ -437,6 +439,7 @@ struct omap_mcbsp_platform_data {
unsigned long phys_base_st;
u16 buffer_size;
#endif
+ unsigned int mcbsp_config_type;
};
struct omap_mcbsp_st_data {
@@ -487,6 +490,7 @@ struct omap_mcbsp {
u16 max_rx_thres;
#endif
void *reg_cache;
+ unsigned int mcbsp_config_type;
};
/**
@@ -555,6 +559,9 @@ int omap_mcbsp_set_io_type(unsigned int id,
omap_mcbsp_io_type_t io_type);
void omap2_mcbsp1_mux_clkr_src(u8 mux);
void omap2_mcbsp1_mux_fsr_src(u8 mux);
+int omap_mcbsp_dma_ch_params(unsigned int id, unsigned int stream);
+int omap_mcbsp_dma_reg_params(unsigned int id, unsigned int stream);
+
#ifdef CONFIG_ARCH_OMAP3
/* Sidetone specific API */
int omap_st_set_chgain(unsigned int id, int channel, s16 chgain);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 63938a2..1626e02 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -229,6 +229,69 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
}
EXPORT_SYMBOL(omap_mcbsp_config);
+/**
+ * omap_mcbsp_dma_params - returns the dma channel number
+ * @id - mcbsp id
+ * @stream - indicates the direction of data flow (rx or tx)
+ *
+ * Returns the dma channel number for the rx channel or tx channel
+ * based on the value of @stream for the requested mcbsp given by @id
+ */
+int omap_mcbsp_dma_ch_params(unsigned int id, unsigned int stream)
+{
+ struct omap_mcbsp *mcbsp;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ if (stream)
+ return mcbsp-dma_rx_sync;
+ else
+ return mcbsp-dma_tx_sync;
+}
+EXPORT_SYMBOL(omap_mcbsp_dma_ch_params);
+
+/**
+ * omap_mcbsp_dma_reg_params - returns the address of mcbsp data register
+ * @id - mcbsp id
+ * @stream - indicates the direction of data flow (rx or tx)
+ *
+ * Returns the address of mcbsp data transmit register or data receive register
+ * to be used by DMA for transferring/receiving data based on the value of
+ * @stream for the requested mcbsp given by @id
+ */
+int omap_mcbsp_dma_reg_params(unsigned int id, unsigned int stream)
+{
+ struct omap_mcbsp *mcbsp;
+ int data_reg;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ data_reg = mcbsp-phys_dma_base;
+
+ if (mcbsp-mcbsp_config_type MCBSP_CONFIG_TYPE2) {
+ if (stream)
+ data_reg += OMAP_MCBSP_REG_DRR1;
+ else
+ data_reg += OMAP_MCBSP_REG_DXR1;
+ } else {
+ if (stream)
+ data_reg += OMAP_MCBSP_REG_DRR;
+ else
+ data_reg += OMAP_MCBSP_REG_DXR;
+ }
+
+ return data_reg;
+}
+EXPORT_SYMBOL(omap_mcbsp_dma_reg_params);
+
#ifdef CONFIG_ARCH_OMAP3
static struct omap_device *find_omap_device_by_dev(struct device *dev)
{
@@ -1870,6 +1933,7 @@ static int __devinit
[PATCH v2 12/13] ASoC: McBSP: get hw params from McBSP driver
Removed the use of macros to obtain base address and DMA channel number.
Instead use the McBSP driver API's that passes base address and DMA
channel number to the client driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Cc: Jarkko Nikula jhnik...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 126 ++-
1 files changed, 4 insertions(+), 122 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index ede6afd..2175f09 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -69,110 +69,6 @@ static struct omap_mcbsp_data mcbsp_data[NUM_LINKS];
*/
static struct omap_pcm_dma_data omap_mcbsp_dai_dma_params[NUM_LINKS][2];
-#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static const int omap1_dma_reqs[][2] = {
- { OMAP_DMA_MCBSP1_TX, OMAP_DMA_MCBSP1_RX },
- { OMAP_DMA_MCBSP2_TX, OMAP_DMA_MCBSP2_RX },
- { OMAP_DMA_MCBSP3_TX, OMAP_DMA_MCBSP3_RX },
-};
-static const unsigned long omap1_mcbsp_port[][2] = {
- { OMAP1510_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP1510_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
- { OMAP1510_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP1510_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
- { OMAP1510_MCBSP3_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP1510_MCBSP3_BASE + OMAP_MCBSP_REG_DRR1 },
-};
-#else
-static const int omap1_dma_reqs[][2] = {};
-static const unsigned long omap1_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-static const int omap24xx_dma_reqs[][2] = {
- { OMAP24XX_DMA_MCBSP1_TX, OMAP24XX_DMA_MCBSP1_RX },
- { OMAP24XX_DMA_MCBSP2_TX, OMAP24XX_DMA_MCBSP2_RX },
-#if defined(CONFIG_SOC_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
- { OMAP24XX_DMA_MCBSP3_TX, OMAP24XX_DMA_MCBSP3_RX },
- { OMAP24XX_DMA_MCBSP4_TX, OMAP24XX_DMA_MCBSP4_RX },
- { OMAP24XX_DMA_MCBSP5_TX, OMAP24XX_DMA_MCBSP5_RX },
-#endif
-};
-#else
-static const int omap24xx_dma_reqs[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP4)
-static const int omap44xx_dma_reqs[][2] = {
- { OMAP44XX_DMA_MCBSP1_TX, OMAP44XX_DMA_MCBSP1_RX },
- { OMAP44XX_DMA_MCBSP2_TX, OMAP44XX_DMA_MCBSP2_RX },
- { OMAP44XX_DMA_MCBSP3_TX, OMAP44XX_DMA_MCBSP3_RX },
- { OMAP44XX_DMA_MCBSP4_TX, OMAP44XX_DMA_MCBSP4_RX },
-};
-#else
-static const int omap44xx_dma_reqs[][2] = {};
-#endif
-
-#if defined(CONFIG_SOC_OMAP2420)
-static const unsigned long omap2420_mcbsp_port[][2] = {
- { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR1 },
- { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1,
- OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1 },
-};
-#else
-static const unsigned long omap2420_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_SOC_OMAP2430)
-static const unsigned long omap2430_mcbsp_port[][2] = {
- { OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
- OMAP24XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
- OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
- OMAP2430_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
- OMAP2430_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
- OMAP2430_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
-};
-#else
-static const unsigned long omap2430_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP3)
-static const unsigned long omap34xx_mcbsp_port[][2] = {
- { OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DXR,
- OMAP34XX_MCBSP5_BASE + OMAP_MCBSP_REG_DRR },
-};
-#else
-static const unsigned long omap34xx_mcbsp_port[][2] = {};
-#endif
-
-#if defined(CONFIG_ARCH_OMAP4)
-static const unsigned long omap44xx_mcbsp_port[][2] = {
- { OMAP44XX_MCBSP1_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP1_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP44XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP44XX_MCBSP3_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP3_BASE + OMAP_MCBSP_REG_DRR },
- { OMAP44XX_MCBSP4_BASE + OMAP_MCBSP_REG_DXR,
- OMAP44XX_MCBSP4_BASE + OMAP_MCBSP_REG_DRR },
-};
-#else
-static const unsigned long omap44xx_mcbsp_port[][2] = {};
-#endif
-
static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream)
{
struct
[PATCH v2 13/13] OMAP: hwmod: Removal of macros for data that is obtained from hwmod database
Information like base address and DMA channel nubers should no longer
be obtained using macros. These information should be obtained from
hwmod database. Hence the macros that define the base address are removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
---
arch/arm/mach-omap1/mcbsp.c | 64 +++---
arch/arm/plat-omap/include/plat/mcbsp.h | 50 +---
2 files changed, 33 insertions(+), 81 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index 2b89ebd..d90f649 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -83,14 +83,14 @@ struct resource omap7xx_mcbsp_res[][6] = {
{
{
.name = mpu,
- .start = OMAP7XX_MCBSP1_BASE,
- .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .start = 0xfffb1000,
+ .end = 0xfffb10ff,
.flags = IORESOURCE_MEM,
},
{
.name = dma,
- .start = OMAP7XX_MCBSP1_BASE,
- .end = OMAP7XX_MCBSP1_BASE + SZ_256,
+ .start = 0xfffb1000,
+ .end = 0xfffb10ff,
.flags = IORESOURCE_MEM,
},
{
@@ -117,14 +117,14 @@ struct resource omap7xx_mcbsp_res[][6] = {
{
{
.name = mpu,
- .start = OMAP7XX_MCBSP2_BASE,
- .end = OMAP7XX_MCBSP2_BASE + SZ_256,
+ .start = 0xfffb1800,
+ .end = 0xfffb18ff,
.flags = IORESOURCE_MEM,
},
{
.name = dma,
- .start = OMAP7XX_MCBSP2_BASE,
- .end = OMAP7XX_MCBSP2_BASE + SZ_256,
+ .start = 0xfffb1800,
+ .end = 0xfffb18ff,
.flags = IORESOURCE_MEM,
},
{
@@ -172,14 +172,14 @@ struct resource omap15xx_mcbsp_res[][6] = {
{
{
.name = mpu,
- .start = OMAP1510_MCBSP1_BASE,
- .end = OMAP1510_MCBSP1_BASE + SZ_256,
+ .start = 0xe1011800,
+ .end = 0xe10118ff,
.flags = IORESOURCE_MEM,
},
{
.name = dma,
- .start = OMAP1510_MCBSP1_BASE,
- .end = OMAP1510_MCBSP1_BASE + SZ_256,
+ .start = 0xe1011800,
+ .end = 0xe10118ff,
.flags = IORESOURCE_MEM,
},
{
@@ -206,14 +206,14 @@ struct resource omap15xx_mcbsp_res[][6] = {
{
{
.name = mpu,
- .start = OMAP1510_MCBSP2_BASE,
- .end = OMAP1510_MCBSP2_BASE + SZ_256,
+ .start = 0xfffb1000,
+ .end = 0xfffb10ff,
.flags = IORESOURCE_MEM,
},
{
.name = dma,
- .start = OMAP1510_MCBSP2_BASE,
- .end = OMAP1510_MCBSP2_BASE + SZ_256,
+ .start = 0xfffb1000,
+ .end = 0xfffb10ff,
.flags = IORESOURCE_MEM,
},
{
@@ -240,14 +240,14 @@ struct resource omap15xx_mcbsp_res[][6] = {
{
{
.name = mpu,
- .start = OMAP1510_MCBSP3_BASE,
- .end = OMAP1510_MCBSP3_BASE + SZ_256,
+ .start = 0xe1017000,
+ .end = 0xe10170ff,
.flags = IORESOURCE_MEM,
},
{
.name = dma,
- .start = OMAP1510_MCBSP3_BASE,
- .end = OMAP1510_MCBSP3_BASE + SZ_256,
+ .start = 0xe1017000,
+ .end = 0xe10170ff,
.flags = IORESOURCE_MEM,
},
{
@@ -298,14 +298,14 @@ struct resource omap16xx_mcbsp_res[][6] = {
{
{
.name = mpu,
- .start = OMAP1610_MCBSP1_BASE,
- .end = OMAP1610_MCBSP1_BASE + SZ_256,
+ .start = 0xe1011800,
+ .end = 0xe10118ff,
.flags = IORESOURCE_MEM,
},
{
.name = dma,
- .start = OMAP1610_MCBSP1_BASE,
-
Re: [linux-pm] [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
On Mon, 31 Jan 2011, Rajendra Nayak wrote: Can you elaborate a bit more on how/why runtime PM transitions are disabled during system suspend, and how is it taken care of that a runtime resume of a device works however a subsequent runtime (re)suspend does not? I'll answer for Kevin. This is done by the PM core, in order to prevent runtime power transitions from interfering with a system power transition. The PM core increments the device's usage_count; this prevents the device from being runtime-suspended but it allows runtime-resume calls to go through. Alan Stern -- 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: [linux-pm] [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
-Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Monday, January 31, 2011 8:43 PM To: Rajendra Nayak Cc: Kevin Hilman; Ben Dooks; linux-...@vger.kernel.org; linux...@lists.linux-foundation.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [linux-pm] [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend On Mon, 31 Jan 2011, Rajendra Nayak wrote: Can you elaborate a bit more on how/why runtime PM transitions are disabled during system suspend, and how is it taken care of that a runtime resume of a device works however a subsequent runtime (re)suspend does not? I'll answer for Kevin. This is done by the PM core, in order to prevent runtime power transitions from interfering with a system power transition. The PM core increments the device's usage_count; this prevents the device from being runtime-suspended but it allows runtime-resume calls to go through. Thanks, I did remember seeing the pm_runtime_get_noresume() in dpm_prepare(). Just did not correlate it was the same Kevin was trying to say. Regards, Rajendra Alan Stern -- 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 10/13] OMAP3: Add voltage dependency table for VDD1.
Vishwanath Sripathy vishwanath...@ti.com writes: [...] Regarding 34xx testing, I did try to test it on 3430 SDP. However image was not booting up when I used pm branch. I see that with latest pm-core branch image boots up where as with pm branch it does not. Is this a known issue? I don't have a 3430SDP, but it boots for me on 3430/n900, 3530/omap3evm and 3630/zoom3. 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
Re: [linux-pm] [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
Alan Stern st...@rowland.harvard.edu writes: On Mon, 31 Jan 2011, Rajendra Nayak wrote: Can you elaborate a bit more on how/why runtime PM transitions are disabled during system suspend, and how is it taken care of that a runtime resume of a device works however a subsequent runtime (re)suspend does not? I'll answer for Kevin. This is done by the PM core, in order to prevent runtime power transitions from interfering with a system power transition. The PM core increments the device's usage_count; this prevents the device from being runtime-suspended but it allows runtime-resume calls to go through. I understand how this works, but frankly I'm still a bit fuzzy on why. I guess I'm still missing a good understanding of what interfering with a system power transition means, and why a runtime suspend qualifies as interfering but not a runtime resume. More specifically, the reason for $SUBJECT patch is precisely because a runtime resume is allowed, a runtime suspend is not, and thus a system power transititon is prevented. 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
RE: [query] smartreflex: No PMIC hook to init smartreflex
-Original Message- From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] Sent: Thursday, January 27, 2011 7:56 PM To: Menon, Nishanth; Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: RE: [query] smartreflex: No PMIC hook to init smartreflex Nishant, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, January 27, 2011 3:06 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [query] smartreflex: No PMIC hook to init smartreflex Sanjeev, On Tue, Jan 25, 2011 at 20:55, Premi, Sanjeev pr...@ti.com wrote: 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. This is a harmless warning (ideally, we should remove the pr_warning). the intent here is to have hook for pmic_init which could be populated for custom PMICs which may need something additional for Smart reflex enablement. if you look at the sr_pmic_data - it just has a single api for pmic_init e.g. in the case of TWL4030/5030, we might need to set the bit to switch mode from I2C1 to I2C_SR - e.g. the patch from Shweta[1] if Smartreflex AVS was the *only* mechanism in the system, we could have hooked pmic_init to this bit setting. but since the system can do voltage scaling (VP forceupdate/vc bypass) independent of SR AVS block, the patch in [1] does initialization independent of sr_pmic_data-pmic_init which makes sense. in short, my 2cents: the warning is probably something we should remove from the code. As you mentioned, incase of TWL4030/5030, we do not need any hook. However if some other PMIC is used that genuinely needs this hook, then shouldn't SR throw up this warning? As SR module is independent of PMIC, it cannot I possibly see different arguments from your description: 1) This is hook is not needed for TWL4030/5030. But still, still hook is needed for another PMIC. 2) It is okay to warn user for non-existent hook that is not really needed... in hope that there could be a different PMIC. 3) Despite saying that SR is independent of PMIC, we assume it as default and don't go thru the plugin route. Something seems to be missing in the argument. I haven't been able to spend more time on this since last mail (also reason for late response); but: 1) When user adds the hook - for different PMIC, this warning/info would go away. But not for current default systems. 2) By keeping TWL4030 as default, we are possibly not telling the person keen on replacing the PMIC what should be done? If SR is really PMIC independent, then warning is right only if TWL4030 is also 'plugged-in' as any other PMIC is expected to be. distinguish them. So I feel this warning should be present probably reworded better like No PMIC hook registered to init smartreflex. Either this PM IC does not need SR init or PMIC hook is missing. This wording - as is - would again be misleading. ~sanjeev Vishwa [1] http://marc.info/?l=linux-omapm=129584746102725w=2 Regards, Nishanth Menon -- 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] arm: Fix possible memory leak
Stefan Weil w...@mail.berlios.de writes:
sr_info was allocated and needs a kfree before returning.
This error was reported by cppcheck:
arch/arm/mach-omap2/smartreflex.c:837: error: Memory leak: sr_info
To: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Stefan Weil w...@mail.berlios.de
Thanks, will queue this for 2.6.38-rc in my pm-fixes branch.
Kevin
---
arch/arm/mach-omap2/smartreflex.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index af39d17..07324607 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -832,7 +832,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_free_devinfo;
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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: [linux-pm] [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
On Mon, 31 Jan 2011, Kevin Hilman wrote: I understand how this works, but frankly I'm still a bit fuzzy on why. I guess I'm still missing a good understanding of what interfering with a system power transition means, and why a runtime suspend qualifies as interfering but not a runtime resume. These are good questions. Rafael implemented this design originally; my contribution was only to warn him of the potential for problems. Therefore he should explain the rationale for the design. More specifically, the reason for $SUBJECT patch is precisely because a runtime resume is allowed, a runtime suspend is not, and thus a system power transititon is prevented. Alan Stern -- 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 19/23] arm: Fix possible null pointer read access
Stefan Weil w...@mail.berlios.de writes:
These errors were found by cppcheck:
arch/arm/mach-omap2/smartreflex.c:784: error: Possible null pointer
dereference: sr_info
arch/arm/mach-omap2/smartreflex.c:799: error: Possible null pointer
dereference: sr_info
Both conditional statements are executed when sr_info == NULL,
so accessing sr_info-voltdm would fail.
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Stefan Weil w...@mail.berlios.de
Thanks, queuing for 2.6.38-rc in my pm-fixes branch.
Kevin
---
arch/arm/mach-omap2/smartreflex.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 77ecebf..af39d17 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -780,8 +780,7 @@ static int omap_sr_autocomp_show(void *data, u64 *val)
struct omap_sr *sr_info = (struct omap_sr *) data;
if (!sr_info) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, sr_info-voltdm-name);
+ pr_warning(%s: omap_sr struct not found\n, __func__);
return -EINVAL;
}
@@ -795,8 +794,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
struct omap_sr *sr_info = (struct omap_sr *) data;
if (!sr_info) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, sr_info-voltdm-name);
+ pr_warning(%s: omap_sr struct not found\n, __func__);
return -EINVAL;
}
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] 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 + hwmod opt-clock change: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43264.html Change log: === changes since v2: - Per comments from Rajendra, removed 'work-around' code for adding opt-clocks in the clock framework in NULL,clk-name format; now the opt-clocks are same as dev,clk-role. [http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43205.html]. Hwmod patch mentioned above is required for the same. 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: clocks: Align DSS clock names and roles OMAP4: DSS2: clocks: Add ick as dummy clock arch/arm/mach-omap2/clock2420_data.c |6 +- arch/arm/mach-omap2/clock2430_data.c |6 +- arch/arm/mach-omap2/clock3xxx_data.c | 10 +- arch/arm/mach-omap2/clock44xx_data.c | 15 ++- 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, 140 insertions(+), 135 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 v3 1/4] OMAP2PLUS: clocks: Align DSS clock names and roles
Currently, clock database has dev, clock-name tuples for DSS2. Because of
this, the clock names are different across different OMAP platforms.
This patch aligns the DSS2 clock names and roles across OMAP 2420, 2430, 3xxx,
44xx platforms in the clock databases, hwmod databases for opt-clocks, and DSS
clock handling.
This ensures that 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 |6 +++---
arch/arm/mach-omap2/clock2430_data.c |6 +++---
arch/arm/mach-omap2/clock3xxx_data.c | 10 +-
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
drivers/video/omap2/dss/dss.c |8
6 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index d2abc2f..3c1712b 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1787,9 +1787,9 @@ 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),
+ CLK(omap_dss, sys_clk, dss2_fck, CK_242X),
+ CLK(omap_dss, tv_clk, 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..136171c 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1891,9 +1891,9 @@ 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),
+ CLK(omap_dss, sys_clk, dss2_fck, CK_243X),
+ CLK(omap_dss, tv_clk, 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..414de70 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3357,11 +3357,11 @@ 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, fck, dss1_alwon_fck_3430es1, CK_3430ES1),
+ CLK(omap_dss, fck, dss1_alwon_fck_3430es2, CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(omap_dss, tv_clk, dss_tv_fck,CK_3XXX),
+ CLK(omap_dss, video_clk,dss_96m_fck, CK_3XXX),
+ CLK(omap_dss, sys_clk, 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),
CLK(NULL, cam_mclk, cam_mclk, CK_34XX | CK_36XX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e8cb32f..9bd3ae5 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3107,11 +3107,11 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, dmic_sync_mux_ck, dmic_sync_mux_ck,
CK_443X),
CLK(NULL, dmic_fck, dmic_fck,
CK_443X),
CLK(NULL, dsp_fck, dsp_fck,
CK_443X),
- CLK(NULL, dss_sys_clk, dss_sys_clk,
CK_443X),
- CLK(NULL, dss_tv_clk, dss_tv_clk,
CK_443X),
- CLK(NULL, dss_dss_clk, dss_dss_clk,
CK_443X),
- CLK(NULL,
[PATCH v3 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 v3 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 v3 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.
This is needed for backward compatibility with OMAP2/3.
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 |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 9bd3ae5..615a361 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3112,6 +3112,11 @@ static struct omap_clk omap44xx_clks[] = {
CLK(omap_dss, dss_clk, dss_dss_clk,
CK_443X),
CLK(omap_dss, video_clk,dss_48mhz_clk,
CK_443X),
CLK(omap_dss, fck, dss_fck,
CK_443X),
+ /*
+* On OMAP4, DSS ick is a dummy clock; this is needed for compatibility
+* with OMAP2/3.
+*/
+ CLK(omap_dss, ick, dummy_ck,
CK_443X),
CLK(NULL, efuse_ctrl_cust_fck, efuse_ctrl_cust_fck,
CK_443X),
CLK(NULL, emif1_fck,emif1_fck,
CK_443X),
CLK(NULL, emif2_fck,emif2_fck,
CK_443X),
--
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 12/13] ASoC: McBSP: get hw params from McBSP driver
On Mon, Jan 31, 2011 at 08:20:36PM +0530, Kishon Vijay Abraham I wrote: Removed the use of macros to obtain base address and DMA channel number. Instead use the McBSP driver API's that passes base address and DMA channel number to the client driver. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Cc: Jarkko Nikula jhnik...@gmail.com Cc: Peter Ujfalusi peter.ujfal...@nokia.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.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 0/2] IOMMU error message cleanup
From: David Cohen david@dhcppc2.(none) Hi, OMAP IOMMU prints error messages twice. These patches remove the error message from the OMAP2,3 specific implementation and let them to be printed on the above layer only. Br, David --- David Cohen (2): OMAP: Add generic IOMMU errors code OMAP: Cleanup IOMMU error messages arch/arm/mach-omap2/iommu2.c| 33 +-- arch/arm/plat-omap/include/plat/iommu.h |9 +++- arch/arm/plat-omap/iommu.c | 36 -- 3 files changed, 48 insertions(+), 30 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 2/2] OMAP: Cleanup IOMMU error messages
IOMMU error messages are duplicated. They're printed on IOMMU specific
layer for OMAP2,3 and once again on the above layer. With this patch,
the error message is printed on the above layer only.
Signed-off-by: David Cohen david.co...@nokia.com
---
arch/arm/mach-omap2/iommu2.c| 33 +--
arch/arm/plat-omap/include/plat/iommu.h |2 +-
arch/arm/plat-omap/iommu.c | 36 --
3 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..bb3d75b 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -143,33 +143,32 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool
on)
__iommu_set_twl(obj, false);
}
-static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 *iommu_errs)
{
- int i;
+ u32 errs = 0;
u32 stat, da;
- const char *err_msg[] = {
- tlb miss,
- translation fault,
- emulation miss,
- table walk fault,
- multi hit fault,
- };
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *iommu_errs = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
-
- for (i = 0; i ARRAY_SIZE(err_msg); i++) {
- if (stat (1 i))
- printk(%s , err_msg[i]);
- }
- printk(\n);
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= IOMMU_ERR_MULTIHIT_FAULT;
+ *iommu_errs = errs;
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index c653fd7..267c5b5 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -83,7 +83,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
void (*set_twl)(struct iommu *obj, bool on);
- u32 (*fault_isr)(struct iommu *obj, u32 *ra);
+ u32 (*fault_isr)(struct iommu *obj, u32 *ra, u32 *iommu_errs);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
void (*tlb_load_cr)(struct iommu *obj, struct cr_regs *cr);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..c7c37a0 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -163,9 +163,9 @@ static u32 get_iopte_attr(struct iotlb_entry *e)
return arch_iommu-get_pte_attr(e);
}
-static u32 iommu_report_fault(struct iommu *obj, u32 *da)
+static u32 iommu_report_fault(struct iommu *obj, u32 *da, u32 *iommu_errs)
{
- return arch_iommu-fault_isr(obj, da);
+ return arch_iommu-fault_isr(obj, da, iommu_errs);
}
static void iotlb_lock_get(struct iommu *obj, struct iotlb_lock *l)
@@ -780,10 +780,18 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
*/
static irqreturn_t iommu_fault_handler(int irq, void *data)
{
- u32 stat, da;
+ int i;
+ u32 stat, da, errs;
u32 *iopgd, *iopte;
int err = -EIO;
struct iommu *obj = data;
+ const char *err_msg[] = {
+ tlb miss,
+ translation fault,
+ emulation miss,
+ table walk fault,
+ multi hit fault,
+ };
if (!obj-refcount)
return IRQ_NONE;
@@ -796,7 +804,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
return IRQ_HANDLED;
clk_enable(obj-clk);
- stat = iommu_report_fault(obj, da);
+ stat = iommu_report_fault(obj, da, errs);
clk_disable(obj-clk);
if (!stat)
return IRQ_HANDLED;
@@ -805,16 +813,20 @@ static irqreturn_t iommu_fault_handler(int irq, void
*data)
iopgd = iopgd_offset(obj, da);
- if (!iopgd_is_table(*iopgd)) {
- dev_err(obj-dev, %s: da:%08x pgd:%p *pgd:%08x\n, __func__,
- da, iopgd, *iopgd);
- return IRQ_NONE;
+ if (iopgd_is_table(*iopgd)) {
+ iopte = iopte_offset(iopgd, da);
+ dev_err(obj-dev, da:%08x pgd:%p *pgd:%08x pte:%p *pte:%08x :,
+ da, iopgd, *iopgd, iopte, *iopte);
+ } else {
+ dev_err(obj-dev, da:%08x pgd:%p *pgd:%08x :, da, iopgd,
+
[PATCH 1/2] OMAP: Add generic IOMMU errors code
Generic IOMMU errors code are necessary to handle errors on generic
layer.
Signed-off-by: David Cohen david.co...@nokia.com
---
arch/arm/plat-omap/include/plat/iommu.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 69230d6..c653fd7 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -109,6 +109,13 @@ struct iommu_platform_data {
u32 da_end;
};
+/* IOMMU errors */
+#define IOMMU_ERR_TLB_MISS (1 0)
+#define IOMMU_ERR_TRANS_FAULT (1 1)
+#define IOMMU_ERR_EMU_MISS (1 2)
+#define IOMMU_ERR_TBLWALK_FAULT(1 3)
+#define IOMMU_ERR_MULTIHIT_FAULT (1 4)
+
#if defined(CONFIG_ARCH_OMAP1)
#error iommu for this processor not implemented yet
#else
--
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] OMAP: powerdomain: remove unused func declaration
On Wed, 19 Jan 2011, Rajendra Nayak wrote:
Trivial fix to remove the unused function declaration
from the powerdomain header.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/powerdomain.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index c66431e..0b7a357 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -165,7 +165,6 @@ struct pwrdm_ops {
int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
};
-void pwrdm_fw_init(void);
void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
*custom_funcs);
struct powerdomain *pwrdm_lookup(const char *name);
--
1.7.0.4
For the archives, this patch was queued for 2.6.39 as part of the
pwrdm_clkdm_a_2.6.39 branch on git://git.pwsan.com/linux-2.6
- 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
[GIT PULL] omap fixes for v2.6.38-rc2
Hi Linus, Please pull some omap fixes from: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus This is mostly to fix few compiler warning that sneaked in during the merge window. Also included is one trivial omap1 related cleanup patch to keep the code consistent with omap2+, and one PTR_ERR fix. Regards, Tony The following changes since commit 6fb1b304255efc5c4c93874ac8c066272e257e28: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2011-01-26 16:31:44 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus Felipe Balbi (1): arm: omap2: mux: fix compile warning Julia Lawall (1): arch/arm/mach-omap2/dma.c: Convert IS_ERR result to PTR_ERR Russell King (1): omap2+: Fix unused variable warning for omap_irq_base Tony Lindgren (1): omap1: Simplify use of omap_irq_flags arch/arm/mach-omap1/include/mach/entry-macro.S | 13 - arch/arm/mach-omap1/irq.c |2 +- arch/arm/mach-omap2/dma.c |2 +- arch/arm/mach-omap2/include/mach/entry-macro.S | 14 -- arch/arm/mach-omap2/io.c |6 ++ arch/arm/mach-omap2/mux.c |2 +- 6 files changed, 5 insertions(+), 34 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
Re: [linux-pm] [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
On Monday, January 31, 2011, Alan Stern wrote: On Mon, 31 Jan 2011, Kevin Hilman wrote: I understand how this works, but frankly I'm still a bit fuzzy on why. I guess I'm still missing a good understanding of what interfering with a system power transition means, and why a runtime suspend qualifies as interfering but not a runtime resume. These are good questions. Rafael implemented this design originally; my contribution was only to warn him of the potential for problems. Therefore he should explain the rationale for the design. The reason why runtime resume is allowed during system power transitions is because in some cases during system suspend we simply have to resume devices that were previously runtime-suspended (for example, the PCI bus type does that). The reason why runtime suspend is not allowed during system power transitions if the following race: - A device has been suspended via a system suspend callback. - The runtime PM framework executes a (scheduled) suspend on that device, not knowing that it's already been suspended, which potentially results in accessing the device's registers in a low-power state. Now, it can be avoided if every driver does the right thing and checks whether the device is already suspended in its runtime suspend callback, but that would kind of defeat the purpose of the runtime PM framework, at least partially. Thanks, Rafael -- 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
OMAP PM fixes for 2.6.38-rc3
Tony, Please pull the following small set of PM-related fixes for 2.6.38-rc. Kevin The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linux 2.6.38-rc2 (2011-01-21 19:01:34 -0800) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_2.6.38/pm-fixes Aaro Koskinen (1): arm: mach-omap2: voltage: debugfs: fix memory leak Julia Lawall (1): OMAP: PM: SmartReflex: Add missing IS_ERR test Kevin Hilman (1): OMAP3: PM: fix save secure RAM to restore MPU power state Stefan Weil (2): OMAP: PM: SmartReflex: Fix possible memory leak OMAP: PM: SmartReflex: Fix possible null pointer read access arch/arm/mach-omap2/pm34xx.c |7 --- arch/arm/mach-omap2/smartreflex.c | 11 +-- arch/arm/mach-omap2/voltage.c |1 + 3 files changed, 10 insertions(+), 9 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
Re: [PATCHv3] OMAP: Enable Magic SysRq on serial console ttyOx
On Mon, Jan 24, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: On Fri, Jan 21, 2011 at 3:31 PM, Thomas Weber we...@corscience.de wrote: Magic SysRq key is not working for OMAP on new serial console ttyOx because SUPPORT_SYSRQ is not defined for omap-serial. This patch defines SUPPORT_SYSRQ in omap-serial and enables handling of Magic SysRq character. Further there is an issue of losing first break character. Removing the reset of the lsr_break_flag fixes this issue. Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Govindraj.R govindraj.r...@ti.com Tested-by: Manjunath G Kondaiah manj...@ti.com Acked-by: Kevin Hilman khil...@ti.com Greg, this one should go for .38-rc. Feel free to merge, or we can take it through the OMAP tree with your ack. Thanks, Kevin -- Hello, should I rebase this patch, because it does not apply after movement of driver/serial to driver/tty/serial? Thomas -- 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: Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
On Tue, Jan 25, 2011 at 09:03:22PM -0800, Sutharsan wrote: 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 I've already applied this patch, and you should have gotten the this patch has been applied email, right? So why was it resent? confused, greg k-h -- 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] Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
On Wed, Jan 26, 2011 at 08:58:54AM -0800, Sutharsan wrote: 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 Why was this sent again? totally confused, greg k-h -- 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: Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
On Mon, 2011-01-31 at 13:31 -0800, Greg KH wrote: On Tue, Jan 25, 2011 at 09:03:22PM -0800, Sutharsan wrote: 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 I've already applied this patch, and you should have gotten the this patch has been applied email, right? So why was it resent? I resent adding '[PATCH]' tag which was missing in my first submission. Please ignore this. confused, greg k-h --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. --- -- 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] Staging: Westbridge: fix EXPORT_SYMBOL errors reported by checkpatch.pl
On Mon, 2011-01-31 at 13:40 -0800, Greg KH wrote: On Wed, Jan 26, 2011 at 08:58:54AM -0800, Sutharsan wrote: 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 Why was this sent again? totally confused, I apologize for resending and creating confusion. There has been a problem with the mail client. Please ignore this as well. greg k-h --- This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. --- -- 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] OMAP3630: PM: don't warn the user with a trace in case of PM34XX_ERRATUM
Ricardo Salveti de Araujo ricardo.salv...@canonical.com writes:
In case in user has a OMAP3630 ES1.2 the kernel should warn the user
about the ERRATUM, but using pr_warn instead of WARN_ON is already
enough, as there is nothing else the user can do besides changing the
board.
Signed-off-by: Ricardo Salveti de Araujo ricardo.salv...@canonical.com
Thanks, queuing for 2.6.39 in my for_2.6.39/pm-misc branch.
Kevin
---
v1-v2:
* Use pr_warn instead of printk (Kevin Hilman)
arch/arm/mach-omap2/cpuidle34xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f7b22a1..876eeca 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -464,7 +464,7 @@ void omap_init_power_states(void)
if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
omap3_power_states[OMAP3_STATE_C7].valid = 0;
cpuidle_params_table[OMAP3_STATE_C7].valid = 0;
- WARN_ONCE(1, %s: core off state C7 disabled due to i583\n,
+ pr_warn(%s: core off state C7 disabled due to i583\n,
__func__);
}
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index a4aa192..88f09da 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -927,8 +927,7 @@ void omap3_pm_off_mode_enable(int enable)
pwrst-pwrdm == core_pwrdm
state == PWRDM_POWER_OFF) {
pwrst-next_state = PWRDM_POWER_RET;
- WARN_ONCE(1,
- %s: Core OFF disabled due to errata i583\n,
+ pr_warn(%s: Core OFF disabled due to errata i583\n,
__func__);
} else {
pwrst-next_state = state;
--
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] MAINTAINERS: add entry for OMAP powerdomain/clockdomain per-SoC layer support
Add Rajendra Nayak and myself as maintainers for the OMAP powerdomain/clockdomain per-SoC layer code. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com Signed-off-by: Benoît Cousson b-cous...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- This patch is being sent for comment only; Tony will probably queue this up with the rest of the OMAP patches in the .39 window. MAINTAINERS | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 55592f8..d203d8b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4451,6 +4451,16 @@ L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/*omap*/*pm* +OMAP POWERDOMAIN/CLOCKDOMAIN SOC ADAPTATION LAYER SUPPORT +M: Rajendra Nayak rna...@ti.com +M: Paul Walmsley p...@pwsan.com +L: linux-omap@vger.kernel.org +S: Maintained +F: arch/arm/mach-omap2/powerdomain2xxx_3xxx.c +F: arch/arm/mach-omap2/powerdomain44xx.c +F: arch/arm/mach-omap2/clockdomain2xxx_3xxx.c +F: arch/arm/mach-omap2/clockdomain44xx.c + OMAP AUDIO SUPPORT M: Jarkko Nikula jhnik...@gmail.com L: alsa-de...@alsa-project.org (subscribers-only) -- 1.7.2.3
Re: [PATCH] OMAP: hwmod: Do not expect an entry in clkdev to add alias for opt_clks
Hi Rajendra
one brief comment below. Also, when you post an updated version, could
you cc the linux-arm-kernel mailing list? That way I won't have to do
it...
On Fri, 28 Jan 2011, Rajendra Nayak wrote:
The _add_optional_clock_alias function expects an entry
already existing in the clkdev table in the form of
dev-id=NULL, con-id=role which might not be the case
always.
Instead, just check if an entry already exists in clkdev
in the dev-id=dev_name, con-id=role form, else go ahead
and add one.
Remove any assumption of an entry already existing in clkdev
table in any form.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/plat-omap/omap_device.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 57adb27..80d4f35 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -83,9 +83,11 @@
#include linux/err.h
#include linux/io.h
#include linux/clk.h
+#include linux/clkdev.h
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/clock.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -244,7 +246,7 @@ static inline struct omap_device *_find_by_pdev(struct
platform_device *pdev)
*
* For every optional clock present per hwmod per omap_device, this function
* adds an entry in the clocks list of the form dev-id=dev_name,
con-id=role
- * if an entry is already present in it with the form dev-id=NULL,
con-id=role
+ * if it does not exist already.
*
* The function is called from inside omap_device_build_ss(), after
* omap_device_register.
@@ -258,21 +260,32 @@ static void _add_optional_clock_alias(struct
omap_device *od,
struct omap_hwmod *oh)
{
int i;
+ struct clk_lookup *l;
+ struct omap_hwmod_opt_clk *oc;
for (i = 0; i oh-opt_clks_cnt; i++) {
- struct omap_hwmod_opt_clk *oc;
- int r;
+ struct clk *r;
oc = oh-opt_clks[i];
if (!oc-_clk)
continue;
- r = clk_add_alias(oc-role, dev_name(od-pdev.dev),
- (char *)oc-clk, od-pdev.dev);
- if (r)
+ r = clk_get_sys(dev_name(od-pdev.dev), oc-role);
+ if (!IS_ERR(r))
+ continue; /* clkdev entry exists */
+
+ r = omap_clk_get_by_name((char *)oc-clk);
+ if (IS_ERR(r)) {
pr_err(omap_device: %s: clk_add_alias for %s failed\n,
dev_name(od-pdev.dev), oc-role);
+ continue;
+ }
+
+ l = clkdev_alloc(r, oc-role, dev_name(od-pdev.dev));
+ if (!l)
+ return;
Please add a pr_err() in this case, similar to the above one; that way
in the unlikely event that this fails, there will be some sign of what is
happening... other than that, it looks good to me
+ clkdev_add(l);
}
}
--
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
- 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: handling clock nodes with both parent and divider selection
On Mon, 31 Jan 2011, Rajendra Nayak wrote: Hi Paul, On OMAP4, some aux clk nodes (part of SCRM) have control for both parent and divider selection. Is there a way in the current clock framework for OMAP's to handle this? For these clocks on OMAP3, we split the clock into two struct clks. For example, clkout2_src_ck handles source selection, and sys_clkout2 handles rate selection. clock3xxx_data.c has the details. At some point in the future, hopefully we'll be able to split all of the multiplexers and dividers into their own struct clks, or struct omap_clks, or something, so we don't have to implement these hacks. As I understand it, that would be closer to the actual hardware, anyway. The right time to do that would be after the clktype conversion... - 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 1/6] omap4: powerdomain: Add supported INACTIVE power state
Hello Santosh, On Fri, 28 Jan 2011, Santosh Shilimkar wrote: On OMAP4, one can explicitly program INACTIVE as the power state of the logic area inside the power domain. Techincally PD state programmed to ON and if all the clock domains within the PD are idled, is equivalent tp PD programmed to INACTIVE and all the clock domains within the PD are idled. There won't be any power difference in above two. Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD targeted state and also there is some additional latancy involved with PD INACTIVE vs PD ON, it's better to support it as an explcit PD state. This patch adds the support to allow explicit PD INACTIVE programming if supported. What does the hardware do when the powerdomain is programmed to INACTIVE? Does it actually force the clockdomains idle? - 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 4/6] omap4: dpll: Enable all DPLL autoidle at boot
Hi guys On Fri, 28 Jan 2011, Santosh Shilimkar wrote: From: Rajendra Nayak rna...@ti.com Enable all DPLL autoidle at boot on OMAP4. Is there some reason why we can't do this in the OMAP4 PM code? At some point, I think it would be good to essentially disable all PM at boot, and then let the PM code specifically enable autoidle later in the boot process, etc. The idea being that !CONFIG_PM would result in a chip programmed for lowest latency, etc. Signed-off-by: Rajendra Nayak rna...@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 e8cb32f..e5c59a0 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void) clkdev_add(c-lk); clk_register(c-lk.clk); omap2_init_clk_clkdm(c-lk.clk); + if (c-lk.clk-dpll_data) + omap3_dpll_allow_idle(c-lk.clk); } recalculate_root_clocks(); -- 1.6.0.4 - 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 v4 1/4] drivers: hwspinlock: add framework
On Mon, 31 Jan 2011 12:33:41 +0200 Ohad Ben-Cohen o...@wizery.com wrote: Add a platform-independent hwspinlock framework. Hardware spinlock devices are needed, e.g., in order to access data that is shared between remote processors, that otherwise have no alternative mechanism to accomplish synchronization and mutual exclusion operations. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: Hari Kanigeri h-kanige...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Cc: Arnd Bergmann a...@arndb.de Cc: Paul Walmsley p...@pwsan.com Acked-by: Tony Lindgren t...@atomide.com --- Documentation/hwspinlock.txt | 299 ++ drivers/Kconfig |2 + drivers/Makefile |2 + drivers/hwspinlock/Kconfig | 13 + drivers/hwspinlock/Makefile |5 + drivers/hwspinlock/hwspinlock.h | 61 drivers/hwspinlock/hwspinlock_core.c | 557 ++ include/linux/hwspinlock.h | 298 ++ It's a little irritating having two hwspinlock.h's. hwspinlock_internal.h wold be a conventional approach. But it's not a big deal. ... +/* + * A radix tree is used to maintain the available hwspinlock instances. + * The tree associates hwspinlock pointers with their integer key id, + * and provides easy-to-use API which makes the hwspinlock core code simple + * and easy to read. + * + * Radix trees are quick on lookups, and reasonably efficient in terms of + * storage, especially with high density usages such as this framework + * requires (a continuous range of integer keys, beginning with zero, is + * used as the ID's of the hwspinlock instances). + * + * The radix tree API supports tagging items in the tree, which this + * framework uses to mark unused hwspinlock instances (see the + * HWSPINLOCK_UNUSED tag above). As a result, the process of querying the + * tree, looking for an unused hwspinlock instance, is now reduced to a + * single radix tree API call. + */ Nice comment! +static RADIX_TREE(hwspinlock_tree, GFP_KERNEL); + ... +/** + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit + * @hwlock: the hwspinlock to be locked + * @timeout: timeout value in jiffies hm, why in jiffies? The problem here is that lazy programmers will use hwspin_lock_timeout(lock, 10, ...) and their code will work happily with HZ=100 but will explode with HZ=1000. IOW, this interface *requires* that all callers perform a seconds-to-jiffies conversion before calling hwspin_lock_timeout(). So why not reduce their effort and their ability to make mistakes by defining the API to take seconds? + * @mode: mode which controls whether local interrupts are disabled or not + * @flags: a pointer to where the caller's interrupt state will be saved at (if + * requested) + * + * This function locks the given @hwlock. If the @hwlock + * is already taken, the function will busy loop waiting for it to + * be released, but give up when @timeout jiffies have elapsed. If @timeout + * is %MAX_SCHEDULE_TIMEOUT, the function will never give up (therefore if a + * faulty remote core never releases the @hwlock, it will deadlock). + * + * Upon a successful return from this function, preemption is disabled + * (and possibly local interrupts, too), so the caller must not sleep, + * and is advised to release the hwspinlock as soon as possible. + * This is required in order to minimize remote cores polling on the + * hardware interconnect. + * + * The user decides whether local interrupts are disabled or not, and if yes, + * whether he wants their previous state to be saved. It is up to the user + * to choose the appropriate @mode of operation, exactly the same way users + * should decide between spin_lock, spin_lock_irq and spin_lock_irqsave. + * + * Returns 0 when the @hwlock was successfully taken, and an appropriate + * error code otherwise (most notably -ETIMEDOUT if the @hwlock is still + * busy after @timeout meets jiffies). The function will never sleep. + */ ... -- 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: [PATCHv3] OMAP: Enable Magic SysRq on serial console ttyOx
Thomas Weber thomas.weber.li...@googlemail.com writes: On Mon, Jan 24, 2011 at 10:47 PM, Kevin Hilman khil...@ti.com wrote: Govindraj govindraj...@gmail.com writes: On Fri, Jan 21, 2011 at 3:31 PM, Thomas Weber we...@corscience.de wrote: Magic SysRq key is not working for OMAP on new serial console ttyOx because SUPPORT_SYSRQ is not defined for omap-serial. This patch defines SUPPORT_SYSRQ in omap-serial and enables handling of Magic SysRq character. Further there is an issue of losing first break character. Removing the reset of the lsr_break_flag fixes this issue. Signed-off-by: Thomas Weber we...@corscience.de Acked-by: Govindraj.R govindraj.r...@ti.com Tested-by: Manjunath G Kondaiah manj...@ti.com Acked-by: Kevin Hilman khil...@ti.com Greg, this one should go for .38-rc. Feel free to merge, or we can take it through the OMAP tree with your ack. Thanks, Kevin -- Hello, should I rebase this patch, because it does not apply after movement of driver/serial to driver/tty/serial? Yes, please rebase. Thanks, 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
Re: [PATCH 2/2] OMAP: Cleanup IOMMU error messages
Hi David,
On Mon, Jan 31, 2011 at 11:25 AM, David Cohen david.co...@nokia.com wrote:
IOMMU error messages are duplicated. They're printed on IOMMU specific
layer for OMAP2,3 and once again on the above layer. With this patch,
the error message is printed on the above layer only.
So, you say they are duplicated, previously the type of fault was
printed in the omap2,3 code and the addresses involving the error
printed on plat code... with this patch both messages are printed on
plat code, I don't see where the duplication/fix is about.
AFAIK, your patch removes this line:
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
Which I assume is the one being printed again in plat code, right?
Signed-off-by: David Cohen david.co...@nokia.com
---
arch/arm/mach-omap2/iommu2.c | 33 +--
arch/arm/plat-omap/include/plat/iommu.h | 2 +-
arch/arm/plat-omap/iommu.c | 36 --
3 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..bb3d75b 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -143,33 +143,32 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool
on)
__iommu_set_twl(obj, false);
}
-static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 *iommu_errs)
{
- int i;
+ u32 errs = 0;
u32 stat, da;
- const char *err_msg[] = {
- tlb miss,
- translation fault,
- emulation miss,
- table walk fault,
- multi hit fault,
- };
AFAIU, this code living in mach-omap2, means that this errors are
common for omap2,3,4 which they are. Does moving them to plat code
implies that all omap platforms expect these errors?
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat = MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *iommu_errs = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj-dev, %s:\tda:%08x , __func__, da);
-
- for (i = 0; i ARRAY_SIZE(err_msg); i++) {
- if (stat (1 i))
- printk(%s , err_msg[i]);
- }
- printk(\n);
+ if (stat MMU_IRQ_TLBMISS)
+ errs |= IOMMU_ERR_TLB_MISS;
+ if (stat MMU_IRQ_TRANSLATIONFAULT)
+ errs |= IOMMU_ERR_TRANS_FAULT;
+ if (stat MMU_IRQ_EMUMISS)
+ errs |= IOMMU_ERR_EMU_MISS;
+ if (stat MMU_IRQ_TABLEWALKFAULT)
+ errs |= IOMMU_ERR_TBLWALK_FAULT;
+ if (stat MMU_IRQ_MULTIHITFAULT)
+ errs |= IOMMU_ERR_MULTIHIT_FAULT;
+ *iommu_errs = errs;
Is there any point in doing this?
Basically: *iommu_errs = stat, given that the mask values and the
error defines are the same for each case.
Besides I haven't seen two errors trigger a single interrupt.
...
- iopte = iopte_offset(iopgd, da);
-
- dev_err(obj-dev, %s: da:%08x pgd:%p *pgd:%08x pte:%p *pte:%08x\n,
- __func__, da, iopgd, *iopgd, iopte, *iopte);
+ for (i = 0; i ARRAY_SIZE(err_msg); i++) {
+ if (errs (1 i))
+ printk(KERN_CONT %s, err_msg[i]);
+ }
+ printk(\n);
I think we should get rid of the printks.
Regards,
Omar
--
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: [query] smartreflex: No PMIC hook to init smartreflex
Sanjeev, On Mon, Jan 31, 2011 at 9:50 PM, Premi, Sanjeev pr...@ti.com wrote: -Original Message- From: Vishwanath Sripathy [mailto:vishwanath...@ti.com] Sent: Thursday, January 27, 2011 7:56 PM To: Menon, Nishanth; Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: RE: [query] smartreflex: No PMIC hook to init smartreflex Nishant, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Menon, Nishanth Sent: Thursday, January 27, 2011 3:06 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [query] smartreflex: No PMIC hook to init smartreflex Sanjeev, On Tue, Jan 25, 2011 at 20:55, Premi, Sanjeev pr...@ti.com wrote: 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. This is a harmless warning (ideally, we should remove the pr_warning). the intent here is to have hook for pmic_init which could be populated for custom PMICs which may need something additional for Smart reflex enablement. if you look at the sr_pmic_data - it just has a single api for pmic_init e.g. in the case of TWL4030/5030, we might need to set the bit to switch mode from I2C1 to I2C_SR - e.g. the patch from Shweta[1] if Smartreflex AVS was the *only* mechanism in the system, we could have hooked pmic_init to this bit setting. but since the system can do voltage scaling (VP forceupdate/vc bypass) independent of SR AVS block, the patch in [1] does initialization independent of sr_pmic_data-pmic_init which makes sense. in short, my 2cents: the warning is probably something we should remove from the code. As you mentioned, incase of TWL4030/5030, we do not need any hook. However if some other PMIC is used that genuinely needs this hook, then shouldn't SR throw up this warning? As SR module is independent of PMIC, it cannot I possibly see different arguments from your description: 1) This is hook is not needed for TWL4030/5030. But still, still hook is needed for another PMIC. True. struct 'sr_pmic_data' is generic way of handling all Pmic. The pmic needs to register to SR which it does by API 'sr_pmic_init'. Today this API just enables SR bit CFG_ENABLE_SRFLX in TWL PM module registers which is redundant in case of TWL chips as SR bit is already set in 'omap_twl_init' API in file omap_twl.c But in future if this API 'sr_pmic_init' has some other functionality or in case when Pmic is not TWL family chip then the initialization done by 'sr_pmic_init' is necessary. 2) It is okay to warn user for non-existent hook that is not really needed... in hope that there could be a different PMIC. 3) Despite saying that SR is independent of PMIC, we assume it as default and don't go thru the plugin route. Something seems to be missing in the argument. I haven't been able to spend more time on this since last mail (also reason for late response); but: 1) When user adds the hook - for different PMIC, this warning/info would go away. But not for current default systems. If some other PMIC is registered then ideally this warning shouldn't come and if it comes it hampers SR role but for TWL4030/TWL5030 this warning is harmless. 2) By keeping TWL4030 as default, we are possibly not telling the person keen on replacing the PMIC what should be done? If SR is really PMIC independent, then warning is right only if TWL4030 is also 'plugged-in' as any other PMIC is expected to be. distinguish them. So I feel this warning should be present probably reworded better like No PMIC hook registered to init smartreflex. Either this PM IC does not need SR init or PMIC hook is missing. This wording - as is - would again be misleading. ~sanjeev Vishwa [1] http://marc.info/?l=linux-omapm=129584746102725w=2 Regards, Nishanth Menon -- 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
RE: [PATCH] OMAP: hwmod: Do not expect an entry in clkdev to add alias for opt_clks
Hi Paul,
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Tuesday, February 01, 2011 4:39 AM
To: Rajendra Nayak
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP: hwmod: Do not expect an entry in clkdev to
add alias for opt_clks
Hi Rajendra
one brief comment below. Also, when you post an updated version, could
you cc the linux-arm-kernel mailing list? That way I won't have to do
it...
Sure, I will. Sorry I missed it again. Will make sure I have
linux-arm-kernel
Cc'ed for all my patches hence forth.
Have a few comments below.
On Fri, 28 Jan 2011, Rajendra Nayak wrote:
The _add_optional_clock_alias function expects an entry
already existing in the clkdev table in the form of
dev-id=NULL, con-id=role which might not be the case
always.
Instead, just check if an entry already exists in clkdev
in the dev-id=dev_name, con-id=role form, else go ahead
and add one.
Remove any assumption of an entry already existing in clkdev
table in any form.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reported-by: Sumit Semwal sumit.sem...@ti.com
---
arch/arm/plat-omap/omap_device.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 57adb27..80d4f35 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -83,9 +83,11 @@
#include linux/err.h
#include linux/io.h
#include linux/clk.h
+#include linux/clkdev.h
#include plat/omap_device.h
#include plat/omap_hwmod.h
+#include plat/clock.h
/* These parameters are passed to _omap_device_{de,}activate() */
#define USE_WAKEUP_LAT 0
@@ -244,7 +246,7 @@ static inline struct omap_device
*_find_by_pdev(struct platform_device *pdev)
*
* For every optional clock present per hwmod per omap_device, this
function
* adds an entry in the clocks list of the form dev-id=dev_name,
con-id=role
- * if an entry is already present in it with the form dev-id=NULL,
con-id=role
+ * if it does not exist already.
*
* The function is called from inside omap_device_build_ss(), after
* omap_device_register.
@@ -258,21 +260,32 @@ static void _add_optional_clock_alias(struct
omap_device *od,
struct omap_hwmod *oh)
{
int i;
+ struct clk_lookup *l;
+ struct omap_hwmod_opt_clk *oc;
This was a stray change. Will fix in the updated version.
for (i = 0; i oh-opt_clks_cnt; i++) {
- struct omap_hwmod_opt_clk *oc;
- int r;
+ struct clk *r;
oc = oh-opt_clks[i];
if (!oc-_clk)
continue;
- r = clk_add_alias(oc-role, dev_name(od-pdev.dev),
- (char *)oc-clk, od-pdev.dev);
- if (r)
+ r = clk_get_sys(dev_name(od-pdev.dev), oc-role);
+ if (!IS_ERR(r))
+ continue; /* clkdev entry exists */
+
+ r = omap_clk_get_by_name((char *)oc-clk);
+ if (IS_ERR(r)) {
pr_err(omap_device: %s: clk_add_alias for %s
failed\n,
dev_name(od-pdev.dev), oc-role);
+ continue;
+ }
+
+ l = clkdev_alloc(r, oc-role, dev_name(od-pdev.dev));
+ if (!l)
+ return;
Please add a pr_err() in this case, similar to the above one; that way
in the unlikely event that this fails, there will be some sign of what
is
happening... other than that, it looks good to me
Ok, will add the pr_err().
One other thing I was thinking of is if the function name
_add_optional_clock_alias need to be changed to something like
_add_optional_clock_clkdev since we are adding a new clkdev entry,
if it does not exist, and no longer adding an 'alias' for an existing
entry.
Also, the adding of an entry in clkdev is today done for
optional clocks alone. Is there any reason why we should not do
this at runtime for all main clks and interface clks also.
That way we get rid of all dependencies with the static clkdev
table, and we might infact not need one if all entries are added
runtime.
Regards,
Rajendra
+ clkdev_add(l);
}
}
--
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
- 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 4/6] omap4: dpll: Enable all DPLL autoidle at boot
Hi Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, February 01, 2011 4:47 AM To: rna...@ti.com; Santosh Shilimkar Cc: linux-omap@vger.kernel.org; khil...@ti.com; b-cous...@ti.com; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 4/6] omap4: dpll: Enable all DPLL autoidle at boot Hi guys On Fri, 28 Jan 2011, Santosh Shilimkar wrote: From: Rajendra Nayak rna...@ti.com Enable all DPLL autoidle at boot on OMAP4. Is there some reason why we can't do this in the OMAP4 PM code? At some point, I think it would be good to essentially disable all PM at boot, and then let the PM code specifically enable autoidle later in the boot process, etc. The idea being that !CONFIG_PM would result in a chip programmed for lowest latency, etc. I guess it makes sense to do this late in boot and only if CONFIG_PM is enabled. Will make the necessary changes and repost. Regards, Rajendra Signed-off-by: Rajendra Nayak rna...@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 e8cb32f..e5c59a0 100644 --- a/arch/arm/mach-omap2/clock44xx_data.c +++ b/arch/arm/mach-omap2/clock44xx_data.c @@ -3300,6 +3300,8 @@ int __init omap4xxx_clk_init(void) clkdev_add(c-lk); clk_register(c-lk.clk); omap2_init_clk_clkdm(c-lk.clk); + if (c-lk.clk-dpll_data) + omap3_dpll_allow_idle(c-lk.clk); } recalculate_root_clocks(); -- 1.6.0.4 - 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 V2] OMAP3: PM: Set/reset T2 bit for Smartreflex on TWL.
Abhilash,
On Mon, Jan 31, 2011 at 7:19 PM, Koyamangalath, Abhilash
abhilash...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
Sent: Monday, January 24, 2011 11:07 AM
To: linux-omap@vger.kernel.org
Cc: Gopinath, Thara; Gulati, Shweta
Subject: [PATCH V2] OMAP3: PM: Set/reset T2 bit for Smartreflex on TWL.
From: Thara Gopinath th...@ti.com
The smartreflex bit on twl4030 needs to be enabled by default irrespective
of whether smartreflex module is enabled on the OMAP side or not.
This is because without this bit enabled the voltage scaling through
vp forceupdate does not function properly on OMAP3.API added
'omap3_twl_set_sr_bit' with parameter to set/clear SR bit. It is cleared
for platforms where voltage is not scaled using vpforceupdate
or vc_bypass Method. In those cases 'omap3_twl_set_sr_bit' is called
from board file, to make sure this bit is not overwritten in
'omap3_twl_init', a flag 'twl_sr_enable'
is added.
This patch is based on LO PM Branch and Smartreflex has been
tested on OMAP3430 SDP, OMAP3630 SDP and boot tested on
OMAP2430 SDP.
The function twl4030_vsel_to_uv (where you have added a call to
omap3_twl_set_sr_bit) method is getting invoked only from vp_volt_debug_get
(which is for debugfs) and omap_vp_get_curr_volt (which no one seems to be
calling). Due to this I was not able to get cpufreq to work.
(I finally got it working by calling omap3_twl_set_sr_bit from omap3_twl_init
instead).
It looks like I'm missing something, maybe an intermediate patch? (I'd
applied your patch manually on 2.6.37).
-Abhilash
The function 'omap3_twl_set_sr_bit' is called from omap3_twl_init
only, while manually applying the patch u saw the function defined
above omap3_twl_init in patch.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 62
arch/arm/mach-omap2/pm.h | 1 +
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-
omap2/omap_twl.c
index 00e1d2b..871a349 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -59,8 +59,15 @@
static bool is_offset_valid;
static u8 smps_offset;
+/*
+ * Flag to ensure Smartreflex bit in TWL
+ * being cleared in board file is not overwritten.
+ */
+static bool twl_sr_enable = true;
+#define TWL4030_DCDC_GLOBAL_CFG 0x06
#define REG_SMPS_OFFSET 0xE0
+#define SMARTREFLEX_ENABLE BIT(3)
static unsigned long twl4030_vsel_to_uv(const u8 vsel)
{
@@ -269,6 +276,16 @@ int __init omap3_twl_init(void)
omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
+ /*
+ * The smartreflex bit on twl4030 needs to be enabled by
+ * default irrespective of whether smartreflex module is
+ * enabled on the OMAP side or not. This is because without
+ * this bit enabled the voltage scaling through
+ * vp forceupdate does not function properly on OMAP3.
+ */
+ if (twl_sr_enable)
+ omap3_twl_set_sr_bit(1);
+
voltdm = omap_voltage_domain_lookup(mpu);
omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
@@ -277,3 +294,48 @@ int __init omap3_twl_init(void)
return 0;
}
+
+/**
+ * omap3_twl_set_sr_bit() - API to Set/Clear SR bit on TWL
+ * @flag: Flag to Set/Clear SR bit
+ *
+ * If flag is non zero, enables Smartreflex bit on TWL 4030
+ * to make sure voltage scaling through Vp forceupdate works.
+ * Else, the smartreflex bit on twl4030 is
+ * cleared as there are platforms which use
+ * OMAP3 and T2 but use Synchronized Scaling Hardware
+ * Strategy (ENABLE_VMODE=1) and Direct Strategy Software
+ * Scaling Mode (ENABLE_VMODE=0), for setting the voltages,
+ * in those scenarios this bit is to be cleared.
+ * API returns 0 on sucess, error is returned
+ * if I2C read/write fails.
+ */
+
+int omap3_twl_set_sr_bit(u8 flag)
+{
+ u8 temp;
+ int ret;
+
+ ret = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret)
+ goto err;
+
+ if (flag) {
+ temp |= SMARTREFLEX_ENABLE;
+ twl_sr_enable = true;
+ } else {
+ temp = ~SMARTREFLEX_ENABLE;
+ twl_sr_enable = false;
+ }
+
+ ret = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, temp,
+ TWL4030_DCDC_GLOBAL_CFG);
+ if (ret) {
+err:
+ pr_err(%s: Unable to Read/Write to TWL4030 through I2C bus
+ \n, __func__);
+ return -EINVAL;
+ }
+ return 0;
+}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 704766b..c98be66 100644
--- a/arch/arm/mach-omap2/pm.h
Re: [PATCH v4 1/4] drivers: hwspinlock: add framework
On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton a...@linux-foundation.org wrote: It's a little irritating having two hwspinlock.h's. hwspinlock_internal.h wold be a conventional approach. But it's not a big deal. ... +/** + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit + * @hwlock: the hwspinlock to be locked + * @timeout: timeout value in jiffies hm, why in jiffies? The problem here is that lazy programmers will use hwspin_lock_timeout(lock, 10, ...) and their code will work happily with HZ=100 but will explode with HZ=1000. IOW, this interface *requires* that all callers perform a seconds-to-jiffies conversion before calling hwspin_lock_timeout(). So why not reduce their effort and their ability to make mistakes by defining the API to take seconds? I considered that, but then decided to use jiffies in order to be consistent with wait_event_timeout/schedule_timeout (although I don't return the remaining jiffies in case the lock is taken before the timeout elapses), and also to allow user-selected granularity. But I do kind of like the idea of not using jiffies. We can probably even move to msecs, since anyway this is an error condition, and people who needs a quick check should just use the trylock() version. I'll do a quick respin of the patches with that and the hwspinlock_internal.h comment above. Thanks, Ohad. -- 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/6] omap4: powerdomain: Add supported INACTIVE power state
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Tuesday, February 01, 2011 4:44 AM To: Santosh Shilimkar Cc: linux-omap@vger.kernel.org; khil...@ti.com; b-cous...@ti.com; rna...@ti.com; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/6] omap4: powerdomain: Add supported INACTIVE power state Hello Santosh, On Fri, 28 Jan 2011, Santosh Shilimkar wrote: On OMAP4, one can explicitly program INACTIVE as the power state of the logic area inside the power domain. Techincally PD state programmed to ON and if all the clock domains within the PD are idled, is equivalent tp PD programmed to INACTIVE and all the clock domains within the PD are idled. There won't be any power difference in above two. Since the CPUIDLE C-states explicitly make use of INACTIVE as a PD targeted state and also there is some additional latancy involved with PD INACTIVE vs PD ON, it's better to support it as an explcit PD state. This patch adds the support to allow explicit PD INACTIVE programming if supported. What does the hardware do when the powerdomain is programmed to INACTIVE? Does it actually force the clockdomains idle? No. It doesn't force it. The power domain to hit INACTIVE, the clockdomain within the power domain needs to idle and it is still a prerequisite. With INACTIVE being programmed, we could issue a sleep transition. PD_ON: No power transition, only clocks are gated. Power domain stays ON. PD_INA: Power domain transitions to INACTIVE state. All logic and memory stay powered. This state allows for a voltage sleep transition. 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 v4 1/4] drivers: hwspinlock: add framework
On Tue, 1 Feb 2011 08:20:13 +0200 Ohad Ben-Cohen o...@wizery.com wrote: On Tue, Feb 1, 2011 at 1:38 AM, Andrew Morton a...@linux-foundation.org wrote: It's a little irritating having two hwspinlock.h's. hwspinlock_internal.h wold be a conventional approach. __But it's not a big deal. ... +/** + * __hwspin_lock_timeout() - lock an hwspinlock with timeout limit + * @hwlock: the hwspinlock to be locked + * @timeout: timeout value in jiffies hm, why in jiffies? The problem here is that lazy programmers will use __ __ __ __hwspin_lock_timeout(lock, 10, ...) and their code will work happily with HZ=100 but will explode with HZ=1000. IOW, this interface *requires* that all callers perform a seconds-to-jiffies conversion before calling hwspin_lock_timeout(). __So why not reduce their effort and their ability to make mistakes by defining the API to take seconds? I considered that, but then decided to use jiffies in order to be consistent with wait_event_timeout/schedule_timeout (although I don't return the remaining jiffies in case the lock is taken before the timeout elapses), and also to allow user-selected granularity. But I do kind of like the idea of not using jiffies. We can probably even move to msecs, since anyway this is an error condition, and people who needs a quick check should just use the trylock() version. I'll do a quick respin of the patches with that and the hwspinlock_internal.h comment above. OK.. The patch series looks OK to me. But there isn't a lot of point in me putting them into my tree. Maybe Tony or Russell or Greg can grab them if they like the look of it all? -- 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] musb: am35x: fix compile error due to control apis
On Thu, Jan 27, 2011 at 07:31:23AM -0500, Ben Gamari wrote: On Thu, 27 Jan 2011 06:48:10 +0200, Felipe Balbi ba...@ti.com wrote: sorry, quite busy at the moment, but here's one answer. Check this commit: commit a9c037832e9624e240c5019d0e01e9352e8f638d ... Thanks for the reply! So I take it that omap's usb_musb_init takes care of all of the new *_board_data fields now and therefore no board changes are necessary? correct. -- balbi -- 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
[PATCHv4] OMAP: Enable Magic SysRq on serial console ttyOx
Magic SysRq key is not working for OMAP on new serial
console ttyOx because SUPPORT_SYSRQ is not defined
for omap-serial.
This patch defines SUPPORT_SYSRQ in omap-serial and
enables handling of Magic SysRq character.
Further there is an issue of losing first break character.
Removing the reset of the lsr_break_flag fixes this issue.
Signed-off-by: Thomas Weber we...@corscience.de
Acked-by: Govindraj.R govindraj.r...@ti.com
Tested-by: Manjunath G Kondaiah manj...@ti.com
Acked-by: Kevin Hilman khil...@ti.com
---
v3-v4
Rebased to 2.6.38-rc2 after move of drivers/serial to drivers/tty/serial
Added Acked-by and Tested-by
drivers/tty/serial/omap-serial.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 7f2f010..699b344 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -20,6 +20,10 @@
* this driver as required for the omap-platform.
*/
+#if defined(CONFIG_SERIAL_OMAP_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
#include linux/module.h
#include linux/init.h
#include linux/console.h
@@ -190,7 +194,6 @@ static inline void receive_chars(struct uart_omap_port *up,
int *status)
if (up-port.line == up-port.cons-index) {
/* Recover the break flag from console xmit */
lsr |= up-lsr_break_flag;
- up-lsr_break_flag = 0;
}
#endif
if (lsr UART_LSR_BI)
--
1.7.4.rc3
--
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 v4 1/4] drivers: hwspinlock: add framework
On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton a...@linux-foundation.org wrote: I'll do a quick respin of the patches with that and the hwspinlock_internal.h comment above. OK.. The patch series looks OK to me. Can I add your Acked-by on the non-omap parts when I respin the series ? Thanks, Ohad. -- 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 v4 1/4] drivers: hwspinlock: add framework
On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen o...@wizery.com wrote: On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton a...@linux-foundation.org wrote: I'll do a quick respin of the patches with that and the hwspinlock_internal.h comment above. OK.. The patch series looks OK to me. Can I add your Acked-by on the non-omap parts when I respin the series ? spose so. I don't normally do acked-by's. I think it's my way of avoiding getting blamed when it all blows up. -- 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
