Re: [RFC][PATCH]: Adding support for omap-serail driver
Vikram,
What about UART3 supporting IRDA and CIR modes?
Is that planned to be added?
We do have an driver to support IrDA -- drivers/net/irda/omap-ir.c
+static unsigned int check_modem_status(struct uart_omap_port *up)
What is the use case for modem_status?
This is basically used to handle any change in uart line[cts,dcd],
like an change in status of cts line should be handled
which is done using the function by checking the MSR[modem status register].
+ if (jiffies_to_msecs(jiffies - up_activity) 1) {
+ mod_timer(up-uart_dma.rx_timer, jiffies +
+ usecs_to_jiffies(up-uart_dma.rx_timeout));
Is this a 10 second timeout? Is this acceptable way?
This has to be done in conjunction with the inactivity timer in
mach-omap2/serial.c
This timeout is the period where we except some activity on rx line as
we dont the time period we receive data hence we keep rx dma channel
active for minimum of 10 secs, however this can be reduced.
-
Regards,
Govindraj.R
--
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][RFC] OMAP3: PM: Adding OSWR support
Girish -Original Message- From: Ghongdemath, Girish Sent: Wednesday, September 02, 2009 5:03 AM To: Sripathy, Vishwanath; 'Tony Lindgren'; Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath Subject: RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support OSWR stands for Open Switch With Retention. This is one of the target power states where logic is lost for all the modules in the power domain except for the ones with Built in retention Flip Flops. This is the main difference between OFF and So, this's supported for CORE, PER and MPU? -Girish OSWR is supported for only for Core and MPU domains (in SW). PER will be in OFF state when Core is in OSWR. -- 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/10] OMAP3: update OMAP3 Beagle defconfig, v3
Hi, On Sun, Aug 30, 2009 at 12:38:07AM +0200, ext Eric Witcher wrote: From: Ming Lei tom.leim...@gmail.com This patch fixes the .probe failure of twl4030_usb driver if it is compiled into kernel. Since twl4030_usb USB transceiver .probe depends on twl4030-regulator, marking twl4030_usb_init as subsys_initcall_sync can make it called after twl4030-regulator initialization is finished, then twl4030_usb USB transceiver driver can be probed successfully. Signed-off-by: Ming Lei tom.leim...@gmail.com Tested-by: Eric Witcher ewitc...@mindspring.com Acked-by: Felipe Balbi felipe.ba...@nokia.com should go to Greg KH on linux-usb -- 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
Re: [PATCH] OMAP4: MMC driver support on OMAP4
Resending the patch, CC'ing LO.
--Kishore
This Patch adds basic support for all 5 MMC controllers on OMAP4.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
This patch doesn't include mmc-regulator support
arch/arm/mach-omap2/devices.c | 42 +
arch/arm/plat-omap/include/mach/irqs.h |2 +
arch/arm/plat-omap/include/mach/mmc.h |9 ++-
drivers/mmc/host/Kconfig |6 ++--
drivers/mmc/host/omap_hsmmc.c | 10 +++
5 files changed, 60 insertions(+), 9 deletions(-)
Index: kernel-omap4-base/arch/arm/mach-omap2/devices.c
===
--- kernel-omap4-base.orig/arch/arm/mach-omap2/devices.c
+++ kernel-omap4-base/arch/arm/mach-omap2/devices.c
@@ -397,7 +397,7 @@ static inline void omap_init_sha1_md5(vo
/*-*/
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
#define MMCHS_SYSCONFIG0x0010
#define MMCHS_SYSCONFIG_SWRESET(1 1)
@@ -424,8 +424,8 @@ static struct platform_device dummy_pdev
**/
static void __init omap_hsmmc_reset(void)
{
- u32 i, nr_controllers = cpu_is_omap34xx() ? OMAP34XX_NR_MMC :
- OMAP24XX_NR_MMC;
+ u32 i, nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
+ (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
for (i = 0; i nr_controllers; i++) {
u32 v, base = 0;
@@ -442,8 +442,21 @@ static void __init omap_hsmmc_reset(void
case 2:
base = OMAP3_MMC3_BASE;
break;
+ case 3:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC4_BASE;
+ break;
+ case 4:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC5_BASE;
+ break;
}
+ if (cpu_is_omap44xx())
+ base += OMAP4_MMC_REG_OFFSET;
+
dummy_pdev.id = i;
dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
iclk = clk_get(dev, ick);
@@ -540,11 +553,23 @@ void __init omap2_init_mmc(struct omap_m
irq = INT_24XX_MMC2_IRQ;
break;
case 2:
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap44xx() !cpu_is_omap34xx())
return;
base = OMAP3_MMC3_BASE;
irq = INT_34XX_MMC3_IRQ;
break;
+ case 3:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+ irq = INT_44XX_MMC4_IRQ;
+ break;
+ case 4:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+ irq = INT_44XX_MMC5_IRQ;
+ break;
default:
continue;
}
@@ -552,8 +577,15 @@ void __init omap2_init_mmc(struct omap_m
if (cpu_is_omap2420()) {
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
+ } else if (cpu_is_omap44xx()) {
+ if (i 3) {
+ base += OMAP4_MMC_REG_OFFSET;
+ irq += IRQ_GIC_START;
+ }
+ size = OMAP4_HSMMC_SIZE;
+ name = mmci-omap-hs;
} else {
- size = HSMMC_SIZE;
+ size = OMAP3_HSMMC_SIZE;
name = mmci-omap-hs;
}
omap_mmc_add(name, i, base, size, irq, mmc_data[i]);
Index: kernel-omap4-base/arch/arm/plat-omap/include/mach/irqs.h
===
--- kernel-omap4-base.orig/arch/arm/plat-omap/include/mach/irqs.h
+++ kernel-omap4-base/arch/arm/plat-omap/include/mach/irqs.h
@@ -503,6 +503,7 @@
#define INT_44XX_FPKA_READY_IRQ(50 + IRQ_GIC_START)
#define INT_44XX_SHA1MD51_IRQ (51 + IRQ_GIC_START)
#define INT_44XX_RNG_IRQ (52 + IRQ_GIC_START)
+#define INT_44XX_MMC5_IRQ (59 + IRQ_GIC_START)
#define INT_44XX_I2C3_IRQ (61 + IRQ_GIC_START)
#define INT_44XX_FPKA_ERROR_IRQ(64 + IRQ_GIC_START)
#define INT_44XX_PBIAS_IRQ (75 + IRQ_GIC_START)
@@ -511,6 +512,7 @@
#define INT_44XX_TLL_IRQ (78 + IRQ_GIC_START)
#define INT_44XX_PARTHASH_IRQ (79 + IRQ_GIC_START)
Re: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
On Tue, Sep 01, 2009 at 03:35:15PM +0200, Ameya Palande wrote: Hi, Current DSPBridge MPU side API provides following IOCTLs which are related to reserving and mapping DSP address space: 1. DSPProcessor_ReserveMemory(): Reserve a virtually contiguous region of DSP address space. 2. DSPProcessor_Map(): Maps an MPU buffer to the DSP virtual address space. 3. DSPProcessor_UnMap(): Remove an MPU buffer mapping from the DSP virtual address space. 4. DSPProcessor_UnReserveMemory(): Frees a previously reserved region of the DSP virtual address space. Typical call sequence is: DSPProcessor_ReserveMemory() DSPProcessor_Map() DSPProcessor_UnMap() DSPProcessor_UnReserveMemory() Current approach has following problems: 1. Caller has to perform 4 system calls in order to map and unmap a buffer. 2. Kernel has no idea about the type of buffer (input/output). So depending on buffer type caller has to explicitly call DSPProcessor_FlushMemory() or DSPProcessor_InvalidateMemory(). Proposed approach: Introduce 2 new IOCTLs which combine (reserve, map) and (unmap, unreserve). Caller should also specify buffer type (input/output) attribute as a parameter to new mapping IOCTL. Benefits of new approach: 1. Saves 2 system calls per map and unmap pair. 2. By implementing lazy unreserve we can introduce cache of reserved mappings, which can skip reserve, unreserve operations. 3. Kernel can take care of flushing/invalidating cache depending on buffer type, which saves system call overhead and removed explicit cache control from user space. These IOCTLs can be added to the current set of API which doesn't break compatibility with old applications. Waiting for comments! Ideas proposed in this document are from: 1. Hiroshi Doyu hiroshi.d...@nokia.com 2. Felipe Contreras felipe.contre...@nokia.com The whole proposal looks good to me :) However, sometimes you would still want to do some extra cache operations afer Map() there should be a way to do 'flush', 'clean' and 'inv'. Cheers. -- Felipe Contreras -- 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: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
The initial idea behind DSPProcessor_ReserveMemory call was to provide the User's the option of doing DSP buffer management for a pool of memory by themselves. So, call Reserve one time, and do map/unmap multiple times within that region, and call Unreserve only once you are done using the Buffer. But obviously that's not how this is being used. Thank you, Best regards, Hari -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Felipe Contreras Sent: Wednesday, September 02, 2009 10:38 AM To: Palande Ameya (Nokia-D/Helsinki) Cc: linux-omap@vger.kernel.org; Ramirez Luna, Omar; Guzman Lugo, Fernando; Doyu Hiroshi (Nokia-D/Helsinki); Tereshonkov Roman (Nokia-D/Helsinki) Subject: Re: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL On Tue, Sep 01, 2009 at 03:35:15PM +0200, Ameya Palande wrote: Hi, Current DSPBridge MPU side API provides following IOCTLs which are related to reserving and mapping DSP address space: 1. DSPProcessor_ReserveMemory(): Reserve a virtually contiguous region of DSP address space. 2. DSPProcessor_Map(): Maps an MPU buffer to the DSP virtual address space. 3. DSPProcessor_UnMap(): Remove an MPU buffer mapping from the DSP virtual address space. 4. DSPProcessor_UnReserveMemory(): Frees a previously reserved region of the DSP virtual address space. Typical call sequence is: DSPProcessor_ReserveMemory() DSPProcessor_Map() DSPProcessor_UnMap() DSPProcessor_UnReserveMemory() Current approach has following problems: 1. Caller has to perform 4 system calls in order to map and unmap a buffer. 2. Kernel has no idea about the type of buffer (input/output). So depending on buffer type caller has to explicitly call DSPProcessor_FlushMemory() or DSPProcessor_InvalidateMemory(). Proposed approach: Introduce 2 new IOCTLs which combine (reserve, map) and (unmap, unreserve). Caller should also specify buffer type (input/output) attribute as a parameter to new mapping IOCTL. Benefits of new approach: 1. Saves 2 system calls per map and unmap pair. 2. By implementing lazy unreserve we can introduce cache of reserved mappings, which can skip reserve, unreserve operations. 3. Kernel can take care of flushing/invalidating cache depending on buffer type, which saves system call overhead and removed explicit cache control from user space. These IOCTLs can be added to the current set of API which doesn't break compatibility with old applications. Waiting for comments! Ideas proposed in this document are from: 1. Hiroshi Doyu hiroshi.d...@nokia.com 2. Felipe Contreras felipe.contre...@nokia.com The whole proposal looks good to me :) However, sometimes you would still want to do some extra cache operations afer Map() there should be a way to do 'flush', 'clean' and 'inv'. Cheers. -- Felipe Contreras -- 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] OMAP4: MMC driver support on OMAP4
-Original Message-
From: kishore kadiyala [mailto:kishore.kadiy...@ti.com]
Sent: Wednesday, September 02, 2009 8:30 AM
To: linux-ker...@vger.kernel.org
Cc: linux-omap@vger.kernel.org; jarkko.lavi...@nokia.com; madhu...@ti.com
Subject: Re: [PATCH] OMAP4: MMC driver support on OMAP4
Resending the patch, CC'ing LO.
--Kishore
This Patch adds basic support for all 5 MMC controllers on OMAP4.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
This patch doesn't include mmc-regulator support
What is the specific reason? How are MMC4 and MMC5 powered up then?
Does MMC1 and MMC2 work with mmctwl4030 wrapper?
arch/arm/mach-omap2/devices.c | 42
+
arch/arm/plat-omap/include/mach/irqs.h |2 +
arch/arm/plat-omap/include/mach/mmc.h |9 ++-
drivers/mmc/host/Kconfig |6 ++--
drivers/mmc/host/omap_hsmmc.c | 10 +++
5 files changed, 60 insertions(+), 9 deletions(-)
Index: kernel-omap4-base/arch/arm/mach-omap2/devices.c
===
--- kernel-omap4-base.orig/arch/arm/mach-omap2/devices.c
+++ kernel-omap4-base/arch/arm/mach-omap2/devices.c
@@ -397,7 +397,7 @@ static inline void omap_init_sha1_md5(vo
/*---
--*/
-#ifdef CONFIG_ARCH_OMAP3
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
#define MMCHS_SYSCONFIG 0x0010
#define MMCHS_SYSCONFIG_SWRESET (1 1)
@@ -424,8 +424,8 @@ static struct platform_device dummy_pdev
**/
static void __init omap_hsmmc_reset(void)
{
- u32 i, nr_controllers = cpu_is_omap34xx() ? OMAP34XX_NR_MMC :
- OMAP24XX_NR_MMC;
+ u32 i, nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
+ (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
for (i = 0; i nr_controllers; i++) {
u32 v, base = 0;
@@ -442,8 +442,21 @@ static void __init omap_hsmmc_reset(void
case 2:
base = OMAP3_MMC3_BASE;
break;
+ case 3:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC4_BASE;
+ break;
+ case 4:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC5_BASE;
+ break;
}
+ if (cpu_is_omap44xx())
+ base += OMAP4_MMC_REG_OFFSET;
+
dummy_pdev.id = i;
dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
iclk = clk_get(dev, ick);
@@ -540,11 +553,23 @@ void __init omap2_init_mmc(struct omap_m
irq = INT_24XX_MMC2_IRQ;
break;
case 2:
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap44xx() !cpu_is_omap34xx())
return;
base = OMAP3_MMC3_BASE;
irq = INT_34XX_MMC3_IRQ;
break;
+ case 3:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
The reset fn sets up the base as OMAP4_MMC4_BASE. Why add the OFFSET here?
+ irq = INT_44XX_MMC4_IRQ;
+ break;
+ case 4:
+ if (!cpu_is_omap44xx())
+ return;
+ base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
Ditto
+ irq = INT_44XX_MMC5_IRQ;
+ break;
default:
continue;
}
@@ -552,8 +577,15 @@ void __init omap2_init_mmc(struct omap_m
if (cpu_is_omap2420()) {
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
+ } else if (cpu_is_omap44xx()) {
+ if (i 3) {
+ base += OMAP4_MMC_REG_OFFSET;
+ irq += IRQ_GIC_START;
Why base is updated at multiple places within this fn?
+ }
+ size = OMAP4_HSMMC_SIZE;
+ name = mmci-omap-hs;
} else {
- size = HSMMC_SIZE;
+ size = OMAP3_HSMMC_SIZE;
name = mmci-omap-hs;
}
omap_mmc_add(name, i, base, size, irq, mmc_data[i]);
Index: kernel-omap4-base/arch/arm/plat-omap/include/mach/irqs.h
===
--- kernel-omap4-base.orig/arch/arm/plat-omap/include/mach/irqs.h
+++ kernel-omap4-base/arch/arm/plat-omap/include/mach/irqs.h
@@
mmcqd cpu utilization
Hi, Has anyone monitored the cpu utilization percentage when a MMC/SD card is in use? I have noticed that mmc_queue_thread mmcqd consumes a lot of cpu cycles in a periodic fashion. What I mean here is that I see spikes of high cpu utilization due to mmcqd. There will a cp or similar which will be already consuming cpu to transfer data to the MMC/SD device. Further mmcqd increases that load randomly to a high number. Has anyone seen similar behavior? Any thoughts? Regards, Madhu -- 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] dspbridge: use linux memory allocator directly
From: Andy Shevchenko ext-andriy.shevche...@nokia.com
Instead of MEM_Calloc()/MEM_Free() use kzalloc()/kfree() calls. Thus we get rid
of mem.h dependency.
Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/list.h | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h
b/arch/arm/plat-omap/include/dspbridge/list.h
index c9d9e49..cda1d21 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -49,8 +49,8 @@
#define LIST_
#include dspbridge/host_os.h
-/* MEM_Calloc(), MEM_NONPAGED, MEM_Free() */
-#include dspbridge/mem.h
+#include linux/types.h
+#include linux/slab.h
#include linux/list.h
#define LST_ELEMlist_head
@@ -85,9 +85,9 @@ struct LST_LIST {
static inline struct LST_LIST *LST_Create(void)
{
struct LST_LIST *pList;
+ gfp_t flags = (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL;
- pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
- MEM_NONPAGED);
+ pList = (struct LST_LIST *) kzalloc(sizeof(struct LST_LIST), flags);
if (pList != NULL)
INIT_LIST_HEAD(pList-head);
@@ -116,7 +116,8 @@ static inline struct LST_LIST *LST_Create(void)
*/
static inline void LST_Delete(struct LST_LIST *pList)
{
- MEM_Free(pList);
+ if (pList != NULL)
+ kfree(pList);
}
/*
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmcqd cpu utilization
On Wed, 2 Sep 2009 12:23:59 -0500 Madhusudhan madhu...@ti.com wrote: Hi, Has anyone monitored the cpu utilization percentage when a MMC/SD card is in use? I have noticed that mmc_queue_thread mmcqd consumes a lot of cpu cycles in a periodic fashion. What I mean here is that I see spikes of high cpu utilization due to mmcqd. There will a cp or similar which will be already consuming cpu to transfer data to the MMC/SD device. Further mmcqd increases that load randomly to a high number. Has anyone seen similar behavior? Any thoughts? My guess would be that the omap driver doesn't (cannot?) use the hardware to wait for busy to end, so the system must poll. Anything better than that guess will require some profiling. :) Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: [PATCH] dspbridge: use linux memory allocator directly
On Wed, Sep 02, 2009 at 07:27:10PM +0200, ext Andy Shevchenko wrote:
From: Andy Shevchenko ext-andriy.shevche...@nokia.com
Instead of MEM_Calloc()/MEM_Free() use kzalloc()/kfree() calls. Thus we get
rid
of mem.h dependency.
Signed-off-by: Andy Shevchenko ext-andriy.shevche...@nokia.com
---
arch/arm/plat-omap/include/dspbridge/list.h | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/list.h
b/arch/arm/plat-omap/include/dspbridge/list.h
index c9d9e49..cda1d21 100644
--- a/arch/arm/plat-omap/include/dspbridge/list.h
+++ b/arch/arm/plat-omap/include/dspbridge/list.h
@@ -49,8 +49,8 @@
#define LIST_
#include dspbridge/host_os.h
-/* MEM_Calloc(), MEM_NONPAGED, MEM_Free() */
-#include dspbridge/mem.h
+#include linux/types.h
+#include linux/slab.h
#include linux/list.h
#define LST_ELEMlist_head
@@ -85,9 +85,9 @@ struct LST_LIST {
static inline struct LST_LIST *LST_Create(void)
{
struct LST_LIST *pList;
+ gfp_t flags = (in_atomic()) ? GFP_ATOMIC : GFP_KERNEL;
- pList = (struct LST_LIST *) MEM_Calloc(sizeof(struct LST_LIST),
- MEM_NONPAGED);
+ pList = (struct LST_LIST *) kzalloc(sizeof(struct LST_LIST), flags);
if (pList != NULL)
INIT_LIST_HEAD(pList-head);
@@ -116,7 +116,8 @@ static inline struct LST_LIST *LST_Create(void)
*/
static inline void LST_Delete(struct LST_LIST *pList)
{
- MEM_Free(pList);
+ if (pList != NULL)
+ kfree(pList);
No need to check, since kfree does it for you.
--Imre
--
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] DSPBRIDGE: Fix memory leak in PROC_AutoStart()
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
drivers/dsp/bridge/rmgr/proc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index a75b64a..91ab64f 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -512,6 +512,10 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode,
No Exec file found \n);
}
func_cont:
+ if (hProcObject-g_pszLastCoff) {
+ MEM_Free(hProcObject-g_pszLastCoff);
+ hProcObject-g_pszLastCoff = NULL;
+ }
MEM_FreeObject(hProcObject);
func_end:
GT_1trace(PROC_DebugMask, GT_ENTER,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] DSPBRIDGE: Fix memory leak in PROC_AutoStart()
Signed-off-by: Ameya Palande ameya.pala...@nokia.com --- drivers/dsp/bridge/rmgr/proc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index a75b64a..eb8b4a9 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -512,6 +512,7 @@ DSP_STATUS PROC_AutoStart(struct CFG_DEVNODE *hDevNode, No Exec file found \n); } func_cont: + MEM_Free(hProcObject-g_pszLastCoff); MEM_FreeObject(hProcObject); func_end: GT_1trace(PROC_DebugMask, GT_ENTER, -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mmcqd cpu utilization
-Original Message- From: Pierre Ossman [mailto:pie...@ossman.eu] Sent: Wednesday, September 02, 2009 12:41 PM To: Madhusudhan Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; h...@lst.de Subject: Re: mmcqd cpu utilization On Wed, 2 Sep 2009 12:23:59 -0500 Madhusudhan madhu...@ti.com wrote: Hi, Has anyone monitored the cpu utilization percentage when a MMC/SD card is in use? I have noticed that mmc_queue_thread mmcqd consumes a lot of cpu cycles in a periodic fashion. What I mean here is that I see spikes of high cpu utilization due to mmcqd. There will a cp or similar which will be already consuming cpu to transfer data to the MMC/SD device. Further mmcqd increases that load randomly to a high number. Has anyone seen similar behavior? Any thoughts? My guess would be that the omap driver doesn't (cannot?) use the hardware to wait for busy to end, so the system must poll. So your guess hints probably at wait_for_completion(complete). Am I correct? Regards, Madhu Anything better than that guess will require some profiling. :) Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. -- 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: mmcqd cpu utilization
Madhu, My guess would be that the omap driver doesn't (cannot?) use the hardware to wait for busy to end, so the system must poll. So your guess hints probably at wait_for_completion(complete). Am I correct? Madhu wait_for_completion is blocking call. Please check 'omap_mmc_request' -- 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 00/18] OMAP: DSS2: Intro
On Tue, 01 Sep 2009 10:10:19 +0300 Artem Bityutskiy dedeki...@gmail.com wrote: Andrew, could you please help with merging this piece of (well written) code? Could you give your blessing to include it into linux-next now, and merge this during the next merge window? I'll merge them (after I've looked through them, which I'll do now). But there are more rejects than I'm prepared to cope with. The various arch/arm files have undergone some changes in linux-next which yield more breakage than I'm prepared to try to fix. For example, arch/arm/mach-omap2/board-3430sdp.c:sdp3430_config[] ends up being an empty array! Then there's the matter of these patches, already in -mm: omapfb-add-support-for-the-apollon-lcd.patch omapfb-add-support-for-mipi-dcs-compatible-lcds.patch omapfb-add-support-for-the-amstrad-delta-lcd.patch omapfb-add-support-for-the-2430sdp-lcd.patch omapfb-add-support-for-the-omap2evm-lcd.patch omapfb-add-support-for-the-3430sdp-lcd.patch omapfb-add-support-for-the-omap3-evm-lcd.patch omapfb-add-support-for-the-omap3-beagle-dvi-output.patch omapfb-add-support-for-the-gumstix-overo-lcd.patch omapfb-add-support-for-the-zoom-mdk-lcd.patch omapfb-add-support-for-rotation-on-the-blizzard-lcd-ctrl.patch n770-enable-lcd-mipi-dcs-in-kconfig.patch omapfb-dispc-various-typo-fixes.patch omapfb-dispc-disable-iface-clocks-along-with-func-clocks.patch omapfb-dispc-enable-wake-up-capability.patch omapfb-dispc-allow-multiple-external-irq-handlers.patch omapfb-suspend-resume-only-if-fb-device-is-already-initialized.patch omapfb-fix-coding-style-remove-dead-line.patch omapfb-add-fb-manual-update-option-to-kconfig.patch omapfb-hwa742-fix-pointer-to-be-const.patch -- 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][RFC] OMAP3: PM: Adding OSWR support
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Hunter, Jon Not to split hairs, but the OMAP3430 Technical Reference Manual states that OSwR means Open Switch Retention. So no with. This W always bother me too! No bother with W, its part of switch. Underlying spec's have always defined it as following: OSWR stands for Open SWitch Retention CSWR stands for Closed SWitch Retention Regards, Richard W. -- 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-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
On Tue, Aug 18, 2009 at 8:04 AM, Kevin
Hilmankhil...@deeprootsystems.com wrote:
Wang Limei-E12499 e12...@motorola.com writes:
Seems like I did not submit the patch in the right way, before I setup
my mail correctly, attach the patches in the mail.
You're patches are still line-wrapped.
I strongly recommend using git-format-patch and git-send-email to
submit patches. Chunqiu was able to do this. Please consult him.
Also, no need to CC linux-omap-owner. linux-omap is all that is needed.
This patch has been reviewed and merged into our android-omap-2.6.29 tree
http://android.git.kernel.org/?p=kernel/omap.git;a=commit;h=0b6a9b6514c7ccfa0c76e4defdaea3dcbc617633
Kevin if you're having line wrap problems feel free to pull it from
here, assuming everyone's feedback has been addressed
-- MIke
Thanks,
Kevin
PATCH1:0001-Add-per-resource-mutex-for-OMAP-resource-framework.patch
From b4e9cc01f9d1aaeec39cc1ee794e5efaec61c781 Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Fri, 14 Aug 2009 17:34:32 +0800
Subject: [PATCH] Add per-resource mutex for OMAP resource framework
Current OMAP resource fwk uses a global res_mutex
for resource_request and resource_release calls
for all the available resources.It may cause dead
lock if resource_request/resource_release is called
recursively.
For current OMAP3 VDD1/VDD2 resource, the change_level
implementation is mach-omap2/resource34xx.c/set_opp(),
when using resource_release to remove vdd1 constraint,
this function may call resource_release again to release
Vdd2 constrait if target vdd1 level is less than OPP3.
in this scenario, the global res_mutex down operation
will be called again, this will cause the second
down operation hang there.
To fix the problem, per-resource mutex is added
to avoid hangup when resource_request/resource_release
is called recursively.
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h | 2 ++
arch/arm/plat-omap/resource.c | 27
+++
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..d482fb8 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -46,6 +46,8 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ /* Protect each resource */
+ struct mutex resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..5eae4e8 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ mutex_init(resp-resource_mutex);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -362,7 +363,7 @@ int resource_request(const char *name, struct device
*dev,
user-level = level;
res_unlock:
- up(res_mutex);
+ mutex_unlock(resp-resource_mutex);
/*
* Recompute and set the current level for the resource.
* NOTE: update_resource level moved out of spin_lock, as it may
call
@@ -371,6 +372,7 @@ res_unlock:
*/
if (!ret)
ret = update_resource_level(resp);
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +395,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ mutex_lock(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +423,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret =
RE: [RFC][PATCH]: Adding support for omap-serail driver
I don't see much added value to use omap_uart_idle_timer() in serial.c since
it will be called anyway after timeout.
Is it more simple to do it in omap_uart_prepare_idle()?
Hence omap_uart_prepare_idle() can be move into driver/serial/omap_serial.c
eventually.
+extern int are_driveromap_uarts_active(int *);
+
static void omap_uart_idle_timer(unsigned long data)
{
struct omap_uart_state *uart = (struct omap_uart_state *)data;
+ int dummy;
+
+ if (are_driveromap_uarts_active(dummy)){
+ /* Keep UART on NoIdle when DMA channel is
enabled in omap
+ * serial: do not allow UART to goto Smart-idle
till its done
+ * dma'ing
+ */
+ omap_uart_block_sleep(uart);
+ return;
+ }
omap_uart_allow_sleep(uart);
}
-Original Message-
From: Pandita, Vikram [mailto:vikram.pand...@ti.com]
Sent: Tuesday, September 01, 2009 10:58 PM
To: Govindraj; HU TAO-TGHK48
Cc: vimal singh; linux-omap@vger.kernel.org; LKML;
linux-ser...@vger.kernel.org; Ye Yuan.Bo-A22116; Chen Xiaolong-A21785
Subject: RE: [RFC][PATCH]: Adding support for omap-serail driver
govindraj
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Govindraj
Sent: Tuesday, September 01, 2009 2:14 AM
To: HU TAO-TGHK48
Cc: vimal singh; linux-omap@vger.kernel.org; LKML;
linux-ser...@vger.kernel.org; Ye Yuan.Bo-A22116; Chen Xiaolong-A21785
Subject: Re: [RFC][PATCH]: Adding support for omap-serail driver
On Mon, Aug 31, 2009 at 5:20 PM, HU
TAO-TGHK48ta...@motorola.com wrote:
1. Shall we cleanup PM related stuff in
arch/arm/mach-omap2/serial.c
as well?
Originally serail.c register UART IRQ to decide if
UART idle for
a while and is able to enter low power mode (e.g. retention).
To work with original 8250 driver, it is probably the only way
since 8250 is not aware of OMAP PM.
However it would be more reasonable to merge PM stuff to
omap-serial.c. since the new driver is already OMAP specific
2. There is an issue for DMA with current implementation
in serial.c
When Rx DMA is active NO Rx IRQ will be generated.
So serial.c will easily set uart-can_sleep with 1
even there is
Rx DMA ongoing
+ if ((iir 0x4) up-use_dma) {
+ up-ier = ~UART_IER_RDI;
+ serial_out(up, UART_IER, up-ier
In my view, the best way is to do the idle detection in
omap_serial.c.
Yes I understand that we cannot adapt 8250 PM model for omap-serial
driver in DMA mode I am currently working on that adaption with dma
mode and will be posting a separate patch for changes on serial.c.
Wouldn't it be cleaner to inherit and adapt the Serial-PM framework
from serial.c rather than redefining the PM changes in the driver.
As Serial-PM framework already has support for interrupt mode and we
have to adapt the same for DMA mode.
Also defining PM changes in omap-serial would need changes
in PM framework.
As PM framework calls functions from serail.c file if we are
defining
PM framework in our driver then we may need to redefine the
functions
as in serial.c or modify the PM-framework for uart-activity check.
I feel adapting the existing serial-PM framework for DMA
mode would be
better rather than doing these changes.
You can take reference of how to integrate omap-serial driver
PM with mach-omap2/serial.c as follows, for reference ---
---
From 69112426bd6009cb11e104b9aafcc65429d662f0 Mon Sep 17 00:00:00 2001
From: Vikram Pandita vikram.pand...@ti.com
Date: Fri, 21 Aug 2009 11:15:58 -0500
Subject: [RFC PATCH] OMAP: Serial: Keep uart in no idle mode
when DMA ongoing
Keep UART in NoIdle mode when DMA is going on.
Only once UART transfers are complete, switch to smart idle and
allow OsIdle to kick in
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/serial.c | 12
drivers/serial/omap-serial.c |2 +-
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c
b/arch/arm/mach-omap2/serial.c
index ff9beb7..a6ee6ab 100755
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -359,9 +359,21 @@ static void omap_uart_allow_sleep(struct
omap_uart_state *uart)
del_timer(uart-timer);
}
+extern int are_driveromap_uarts_active(int *);
+
static void omap_uart_idle_timer(unsigned long data)
{
struct omap_uart_state *uart = (struct omap_uart_state *)data;
+ int dummy;
+
+ if (are_driveromap_uarts_active(dummy)){
+ /* Keep UART on NoIdle when DMA channel is
enabled in omap
+ * serial: do not allow UART to goto Smart-idle
till its done
+ * dma'ing
+ */
+ omap_uart_block_sleep(uart);
+ return;
+ }
