Re: [PATCH V2 5/10] omap: Add functions for dynamic remuxing of pins
Tony Lindgren wrote:
* Adrian Hunter adrian.hun...@nokia.com [100116 17:31]:
From 33beb5bc36cba739971dc8919a6929925ad3dafc Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 13 Jan 2010 10:27:17 -0800
Subject: [PATCH] omap: Add functions for dynamic remuxing of pins
Make the omap_mux_read and write available for board code,
and rename omap_mux_set_board_signals into omap_mux_write_array.
In some cases we want to change the signals dynamically,
mostly for power management.
Note that we cannot use the signal names as they are set
__init to save memory.
I'll try to merge this as a fix since it fixes dynamic remuxing.
Adrian, can I add your Acked-by?
Sure.
Acked-by: Adrian Hunter adrian.hun...@nokia.com
Regards,
Tony
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 22 +++---
arch/arm/mach-omap2/mux.h | 24
2 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index a8febd3..50298b4 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -51,7 +51,7 @@ struct omap_mux_entry {
static unsigned long mux_phys;
static void __iomem *mux_base;
-static inline u16 omap_mux_read(u16 reg)
+u16 omap_mux_read(u16 reg)
{
if (cpu_is_omap24xx())
return __raw_readb(mux_base + reg);
@@ -59,7 +59,7 @@ static inline u16 omap_mux_read(u16 reg)
return __raw_readw(mux_base + reg);
}
-static inline void omap_mux_write(u16 val, u16 reg)
+void omap_mux_write(u16 val, u16 reg)
{
if (cpu_is_omap24xx())
__raw_writeb(val, mux_base + reg);
@@ -67,6 +67,14 @@ static inline void omap_mux_write(u16 val, u16 reg)
__raw_writew(val, mux_base + reg);
}
+void omap_mux_write_array(struct omap_board_mux *board_mux)
+{
+ while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
+ omap_mux_write(board_mux-value, board_mux-reg_offset);
+ board_mux++;
+ }
+}
+
#if defined(CONFIG_ARCH_OMAP24XX) defined(CONFIG_OMAP_MUX)
static struct omap_mux_cfg arch_mux_cfg;
@@ -833,14 +841,6 @@ static void __init omap_mux_set_cmdline_signals(void)
kfree(options);
}
-static void __init omap_mux_set_board_signals(struct omap_board_mux *board_mux)
-{
- while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
- omap_mux_write(board_mux-value, board_mux-reg_offset);
- board_mux++;
- }
-}
-
static int __init omap_mux_copy_names(struct omap_mux *src,
struct omap_mux *dst)
{
@@ -992,7 +992,7 @@ static void omap_mux_init_package(struct omap_mux *superset,
static void omap_mux_init_signals(struct omap_board_mux *board_mux)
{
omap_mux_set_cmdline_signals();
- omap_mux_set_board_signals(board_mux);
+ omap_mux_write_array(board_mux);
}
#else
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index d8b4d5a..f8c2e7a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -147,6 +147,30 @@ u16 omap_mux_get_gpio(int gpio);
void omap_mux_set_gpio(u16 val, int gpio);
/**
+ * omap_mux_read() - read mux register
+ * @mux_offset:Offset of the mux register
+ *
+ */
+u16 omap_mux_read(u16 mux_offset);
+
+/**
+ * omap_mux_write() - write mux register
+ * @val: New mux register value
+ * @mux_offset:Offset of the mux register
+ *
+ * This should be only needed for dynamic remuxing of non-gpio signals.
+ */
+void omap_mux_write(u16 val, u16 mux_offset);
+
+/**
+ * omap_mux_write_array() - write an array of mux registers
+ * @board_mux: Array of mux registers terminated by MAP_MUX_TERMINATOR
+ *
+ * This should be only needed for dynamic remuxing of non-gpio signals.
+ */
+void omap_mux_write_array(struct omap_board_mux *board_mux);
+
+/**
* omap3_mux_init() - initialize mux system with board specific set
* @board_mux: Board specific mux table
* @flags: OMAP package type used for the board
--
1.6.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
--
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 CPU ID: fix OMAP4 build failure
Santosh, -Original Message- From: Shilimkar, Santosh Sent: Wednesday, January 20, 2010 12:52 PM To: Pagare, Abhijit; Paul Walmsley; Pagare, Abhijit Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure Abhijit, snip I had used this flag earlier as there was nothing fixed as to name it as ES1 that time. So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case and should be removed. A patch would be essential to take care of that in the places where it is used. If you feel the same I can send a patch for fixing this. Tony has already created the patch. Please use that and test it on OMAP4. I will test it on OMAP4 but my point was as follows, The patch that is sent has both the definitions of CHIP_IS_OMAP4430 and CHIP_IS_OMAP4430ES1 where the later is initialized with the former's value. I was actually wondering why the former is required anyways. It is a redundant thing and can be replaced totally. 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
[no subject]
unsubscribe linux-omap -- 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] DSPBRIDGE: replace init_timer with init_timer_on_stack
On Wed, 2010-01-20 at 01:45 +0100, ext Nishanth Menon wrote:
With LOCK_DEP enabled and DEBUG_OBJECTS_TIMERS, DSPBridge
SYNC_WaitOnMultipleEvents will fail with message
ODEBUG: object is on stack, but not annotated
since the timeout timer is on the stack, we should rightly use
init_timer_on_stack.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/services/sync.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/services/sync.c
b/drivers/dsp/bridge/services/sync.c
index c2d79c7..d246656 100644
--- a/drivers/dsp/bridge/services/sync.c
+++ b/drivers/dsp/bridge/services/sync.c
@@ -330,7 +330,7 @@ DSP_STATUS SYNC_WaitOnMultipleEvents(struct SYNC_OBJECT
**hSyncEvents,
if (Wp-state != wo_signalled dwTimeout 0) {
struct timer_list timeout;
if (dwTimeout != SYNC_INFINITE) {
- init_timer(timeout);
+ init_timer_on_stack(timeout);
timeout.function = timeout_callback;
timeout.data = (unsigned long)Wp;
timeout.expires = jiffies + dwTimeout * HZ / 1000;
Acked-by: Ameya Palande ameya.pala...@nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DSPBRIDGE: dont pass invalid DSP OPP requests
Hi Nishanth,
On Wed, 2010-01-20 at 02:44 +0100, ext Nishanth Menon wrote:
If DSP baseimage requests for invalid OPPs, do not pass them
to the rest of the linux kernel subsystem. with a test baseimage
it was found to send
IO_DispatchPM: WMDIOCTL_CONSTRAINT_REQUEST with parameter 0.
this is an invalid OPP ID and should not be passed anywhere.
we add a param check for this prior to passing it along to the
workqueue.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/wmd/io_sm.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 6c140c5..618bedb 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -960,9 +960,12 @@ static void IO_DispatchPM(struct work_struct *work)
pArg[1] = pIOMgr-pSharedMem-oppRequest.rqstOppPt;
DBG_Trace(DBG_LEVEL7, IO_DispatchPM : Value of OPP
value =0x%x \n, pArg[1]);
- status = pIOMgr-pIntfFxns-pfnDevCntrl(pIOMgr-
- hWmdContext, WMDIOCTL_CONSTRAINT_REQUEST,
- pArg);
+ if (!pArg[1])
+ status = DSP_EINVALIDARG;
+ else
+ status = pIOMgr-pIntfFxns-pfnDevCntrl(pIOMgr-
+ hWmdContext,
+ WMDIOCTL_CONSTRAINT_REQUEST, pArg);
if (DSP_FAILED(status)) {
DBG_Trace(DBG_LEVEL7, IO_DispatchPM : Failed
to set constraint = 0x%x \n,
Instead of checking just for 0, isn't it better to check for any value
outside of valid OPPs? (Especially if we need robust implementation
which shouldn't break because of DSP BIOS blackbox!).
Cheers,
Ameya.
--
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 5/6] DSPBRIDGE: remove wrong comment from RequestBridgeResources
On Tue, 2010-01-19 at 21:54 +0100, ext Omar Ramirez Luna wrote:
From: Fernando Guzman Lugo x0095...@ti.com
This patch removes a wrong pointer and set to NULL dwSysCtrlBase
as it shouldn't be used anymore after iounmap.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/rmgr/drv.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 56ceb6c..9b07f25 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -1138,11 +1138,9 @@ static DSP_STATUS RequestBridgeResources(u32
dwContext, s32 bRequest)
iounmap((void *)pResources-dwPerPmBase);
if (pResources-dwCorePmBase)
iounmap((void *)pResources-dwCorePmBase);
- if (pResources-dwSysCtrlBase) {
+ if (pResources-dwSysCtrlBase)
iounmap(pResources-dwSysCtrlBase);
- /* don't set pResources-dwSysCtrlBase to null
- * as it is used in BOARD_Stop */
- }
+
pResources-dwPrmBase = NULL;
pResources-dwCmBase = NULL;
pResources-dwMboxBase = NULL;
@@ -1152,6 +1150,7 @@ static DSP_STATUS RequestBridgeResources(u32 dwContext,
s32 bRequest)
pResources-dwMemBase[4] = (u32) NULL;
pResources-dwWdTimerDspBase = NULL;
pResources-dwDmmuBase = NULL;
+ pResources-dwSysCtrlBase = NULL;
dwBuffSize = sizeof(struct CFG_HOSTRES);
status = REG_SetValue(CURRENTCONFIG, (u8 *)pResources,
Acked-by: Ameya Palande ameya.pala...@nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] DSPBRIDGE: Remove unused variables from resource cleanup
On Tue, 2010-01-19 at 21:54 +0100, ext Omar Ramirez Luna wrote:
From: Fernando Guzman Lugo x0095...@ti.com
This patch removes an unused variable parameter from
resource cleanup code.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
.../plat-omap/include/dspbridge/resourcecleanup.h |3 +--
drivers/dsp/bridge/rmgr/drv.c |5 +
drivers/dsp/bridge/rmgr/strm.c |4 ++--
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index a6f4397..4ded5aa 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -63,8 +63,7 @@ extern DSP_STATUS DRV_GetDMMResElement(u32 pMapAddr, HANDLE
dmmRes,
extern DSP_STATUS DRV_RemoveDMMResElement(HANDLE dmmRes, HANDLE pCtxt);
-extern DSP_STATUS DRV_ProcUpdateSTRMRes(u32 uNumBufs, HANDLE STRMRes,
- HANDLE pCtxt);
+extern DSP_STATUS DRV_ProcUpdateSTRMRes(u32 uNumBufs, HANDLE STRMRes);
extern DSP_STATUS DRV_ProcInsertSTRMResElement(HANDLE hStrm, HANDLE STRMRes,
HANDLE pPctxt);
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 7e85095..56ceb6c 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -339,7 +339,6 @@ DSP_STATUS DRV_GetDMMResElement(u32 pMapAddr, HANDLE
hDMMRes, HANDLE hPCtxt)
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
struct DMM_RES_OBJECT **pDMMRes = (struct DMM_RES_OBJECT **)hDMMRes;
DSP_STATUS status = DSP_SOK;
- struct DMM_RES_OBJECT *pTempDMM2 = NULL;
struct DMM_RES_OBJECT *pTempDMM = NULL;
DBC_Assert(hPCtxt != NULL);
@@ -349,7 +348,6 @@ DSP_STATUS DRV_GetDMMResElement(u32 pMapAddr, HANDLE
hDMMRes, HANDLE hPCtxt)
DRV_GetDMMResElement: 2 pTempDMM:%x
pTempDMM-ulDSPAddr:%x pMapAddr:%x\n, pTempDMM,
pTempDMM-ulDSPAddr, pMapAddr);
- pTempDMM2 = pTempDMM;
pTempDMM = pTempDMM-next;
}
if (pTempDMM != NULL) {
@@ -579,12 +577,11 @@ DSP_STATUS DRV_GetSTRMResElement(HANDLE hStrm, HANDLE
hSTRMRes, HANDLE hPCtxt)
}
/* Updating the stream resource element */
-DSP_STATUS DRV_ProcUpdateSTRMRes(u32 uNumBufs, HANDLE hSTRMRes, HANDLE
hPCtxt)
+DSP_STATUS DRV_ProcUpdateSTRMRes(u32 uNumBufs, HANDLE hSTRMRes)
{
DSP_STATUS status = DSP_SOK;
struct STRM_RES_OBJECT **STRMRes = (struct STRM_RES_OBJECT **)hSTRMRes;
- DBC_Assert(hPCtxt != NULL);
(*STRMRes)-uNumBufs = uNumBufs;
return status;
}
diff --git a/drivers/dsp/bridge/rmgr/strm.c b/drivers/dsp/bridge/rmgr/strm.c
index b0b4d32..febb6c2 100644
--- a/drivers/dsp/bridge/rmgr/strm.c
+++ b/drivers/dsp/bridge/rmgr/strm.c
@@ -158,7 +158,7 @@ DSP_STATUS STRM_AllocateBuffer(struct STRM_OBJECT *hStrm,
u32 uSize,
if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pr_ctxt) !=
DSP_ENOTFOUND)
- DRV_ProcUpdateSTRMRes(uNumBufs, hSTRMRes, pr_ctxt);
+ DRV_ProcUpdateSTRMRes(uNumBufs, hSTRMRes);
#endif
func_end:
return status;
@@ -340,7 +340,7 @@ DSP_STATUS STRM_FreeBuffer(struct STRM_OBJECT *hStrm, u8
**apBuffer,
#ifndef RES_CLEANUP_DISABLE
if (DRV_GetSTRMResElement(hStrm, hSTRMRes, pr_ctxt) !=
DSP_ENOTFOUND)
- DRV_ProcUpdateSTRMRes(uNumBufs-i, hSTRMRes, pr_ctxt);
+ DRV_ProcUpdateSTRMRes(uNumBufs-i, hSTRMRes);
#endif
return status;
}
Acked-by: Ameya Palande ameya.pala...@nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure
-Original Message- From: Shilimkar, Santosh Sent: Wednesday, January 20, 2010 12:52 PM To: Pagare, Abhijit; Paul Walmsley; Pagare, Abhijit Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure Abhijit, snip I had used this flag earlier as there was nothing fixed as to name it as ES1 that time. So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case and should be removed. A patch would be essential to take care of that in the places where it is used. If you feel the same I can send a patch for fixing this. Tony has already created the patch. Please use that and test it on OMAP4. I will test it on OMAP4 but my point was as follows, The patch that is sent has both the definitions of CHIP_IS_OMAP4430 and CHIP_IS_OMAP4430ES1 where the later is initialized with the former's value. I was actually wondering why the former is required anyways. It is a redundant thing and can be replaced totally. I just rescanned the patch and now understand what you are saying. Tony's patch is fixing OMAP3 versions and Paul's patch for OMAP4. Just do the correction you mentioned for OMAP4 in Paul's patch and after testing post it. If you can test both these patches, that would be even better. 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
[PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
From: Eduardo Valentin eduardo.valen...@nokia.com
OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
With this patch, omap opp layer now has its compilation flags
bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
A new file has been created to contain cpu freq code related to
OMAP3: cpufreq34xx.c.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/Makefile |5 +
arch/arm/mach-omap2/cpufreq34xx.c | 133 ++
arch/arm/mach-omap2/omap3-opp.h | 13 +++
arch/arm/mach-omap2/pm.h |6 --
arch/arm/mach-omap2/pm34xx.c | 105
arch/arm/plat-omap/Makefile |2 +
arch/arm/plat-omap/include/plat/opp.h | 145 +
7 files changed, 263 insertions(+), 146 deletions(-)
create mode 100644 arch/arm/mach-omap2/cpufreq34xx.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4ca93f1..22f2afd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -42,6 +42,11 @@ obj-$(CONFIG_PM_DEBUG) += pm-debug.o
obj-$(CONFIG_OMAP_SMARTREFLEX) += smartreflex.o
endif
+# CPU Frequency
+ifeq ($(CONFIG_CPU_FREQ),y)
+obj-$(CONFIG_ARCH_OMAP3) += cpufreq34xx.o
+endif
+
# PRCM
obj-$(CONFIG_ARCH_OMAP2) += cm.o
obj-$(CONFIG_ARCH_OMAP3) += cm.o
diff --git a/arch/arm/mach-omap2/cpufreq34xx.c
b/arch/arm/mach-omap2/cpufreq34xx.c
new file mode 100644
index 000..07873e8
--- /dev/null
+++ b/arch/arm/mach-omap2/cpufreq34xx.c
@@ -0,0 +1,133 @@
+/*
+ * arch/arm/mach-omap2/cpufreq34xx.c
+ * OMAP3 resource init/change_level/validate_level functions
+ *
+ * Copyright (C) 2009 - 2010 Texas Instruments Incorporated.
+ * Nishanth Menon
+ * Copyright (C) 2009 - 2010 Deep Root Systems, LLC.
+ * Kevin Hilman
+ * Copyright (C) 2010 Nokia Corporation.
+ * Eduardo Valentin
+ *
+ * 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 PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ * History:
+ *
+ */
+
+#include linux/module.h
+#include linux/err.h
+
+#include plat/opp.h
+#include plat/cpu.h
+
+static struct omap_opp_def __initdata omap34xx_mpu_rate_table[] = {
+ /* OPP1 */
+ OMAP_OPP_DEF(true, 12500, 975000),
+ /* OPP2 */
+ OMAP_OPP_DEF(true, 25000, 1075000),
+ /* OPP3 */
+ OMAP_OPP_DEF(true, 5, 120),
+ /* OPP4 */
+ OMAP_OPP_DEF(true, 55000, 127),
+ /* OPP5 */
+ OMAP_OPP_DEF(true, 6, 135),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap34xx_l3_rate_table[] = {
+ /* OPP1 */
+ OMAP_OPP_DEF(false, 0, 975000),
+ /* OPP2 */
+ OMAP_OPP_DEF(true, 8300, 105),
+ /* OPP3 */
+ OMAP_OPP_DEF(true, 16600, 115),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap34xx_dsp_rate_table[] = {
+ /* OPP1 */
+ OMAP_OPP_DEF(true, 9000, 975000),
+ /* OPP2 */
+ OMAP_OPP_DEF(true, 18000, 1075000),
+ /* OPP3 */
+ OMAP_OPP_DEF(true, 36000, 120),
+ /* OPP4 */
+ OMAP_OPP_DEF(true, 4, 127),
+ /* OPP5 */
+ OMAP_OPP_DEF(true, 43000, 135),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap36xx_mpu_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 3, 93),
+ /* OPP2 - OPP100 */
+ OMAP_OPP_DEF(true, 6, 110),
+ /* OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF(false, 8, 126),
+ /* OPP4 - OPP-SB */
+ OMAP_OPP_DEF(false, 10, 131),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap36xx_l3_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 1, 93),
+ /* OPP2 - OPP100, OPP-Turbo, OPP-SB */
+ OMAP_OPP_DEF(true, 2, 1137500),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+static struct omap_opp_def __initdata omap36xx_dsp_rate_table[] = {
+ /* OPP1 - OPP50 */
+ OMAP_OPP_DEF(true, 26000, 93),
+ /* OPP2 - OPP100 */
+ OMAP_OPP_DEF(true, 52000, 110),
+ /* OPP3 - OPP-Turbo */
+ OMAP_OPP_DEF(false, 66000, 126),
+ /* OPP4 - OPP-SB */
+ OMAP_OPP_DEF(false, 87500, 131),
+ /* Terminator */
+ OMAP_OPP_DEF(0, 0, 0)
+};
+
+void __init omap3_pm_init_opp_table(void)
Re: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
From: Eduardo Valentin eduardo.valen...@nokia.com OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. With this patch, omap opp layer now has its compilation flags bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. A new file has been created to contain cpu freq code related to OMAP3: cpufreq34xx.c. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/mach-omap2/Makefile |5 + NAK. Your kernel will not boot if you build it without CONFIG_CPU_FREQ. -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
From: Eduardo Valentin eduardo.valen...@nokia.com OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. With this patch, omap opp layer now has its compilation flags bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. A new file has been created to contain cpu freq code related to OMAP3: cpufreq34xx.c. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com NAK also for the following non-working kernel (smartreflex without cpufreq). -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 12:13:17PM +0100, ext Romit Dasgupta wrote: From: Eduardo Valentin eduardo.valen...@nokia.com OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. With this patch, omap opp layer now has its compilation flags bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. A new file has been created to contain cpu freq code related to OMAP3: cpufreq34xx.c. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/mach-omap2/Makefile |5 + NAK. Your kernel will not boot if you build it without CONFIG_CPU_FREQ. I guess you mean without CONFIG_CPU_FREQ and SMART_REFLEX -- Eduardo Valentin -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/mach-omap2/Makefile |5 + NAK. Your kernel will not boot if you build it without CONFIG_CPU_FREQ. I guess you mean without CONFIG_CPU_FREQ and SMART_REFLEX Just without CONFIG_CPU_FREQ. Did it boot? -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote: From: Eduardo Valentin eduardo.valen...@nokia.com OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. With this patch, omap opp layer now has its compilation flags bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. A new file has been created to contain cpu freq code related to OMAP3: cpufreq34xx.c. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com NAK also for the following non-working kernel (smartreflex without cpufreq). Then this is a problem of dependency with smartreflex and cpufreq. In this case better to solve this other problem with another patch. This patch is to rip off cpufreq code from pm34xx, as stated in the above description. And sorry, I didn't get your boot log (if you intended to put it, as you said following non-working kernel BR, -- Eduardo Valentin -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Eduardo Valentin wrote: On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote: From: Eduardo Valentin eduardo.valen...@nokia.com OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. With this patch, omap opp layer now has its compilation flags bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. A new file has been created to contain cpu freq code related to OMAP3: cpufreq34xx.c. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com NAK also for the following non-working kernel (smartreflex without cpufreq). Then this is a problem of dependency with smartreflex and cpufreq. In this case better to solve this other problem with another patch. This patch is to rip off cpufreq code from pm34xx, as stated in the above description. In that case the right fix should 1) __not__ include opp.h for non cpufreq builds OR 2) If it includes opp.h the functions for getting current opp should abstract out the right mechanism to get current frequency/voltage from the chip/power IC. And sorry, I didn't get your boot log (if you intended to put it, as you said following non-working kernel Actually I meant for the following non-working kernel __configuration__. I do not have boot logs! -- 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] DSPBRIDGE: dont pass invalid DSP OPP requests
Ameya Palande said the following on 01/20/2010 04:01 AM:
Hi Nishanth,
On Wed, 2010-01-20 at 02:44 +0100, ext Nishanth Menon wrote:
If DSP baseimage requests for invalid OPPs, do not pass them
to the rest of the linux kernel subsystem. with a test baseimage
it was found to send
IO_DispatchPM: WMDIOCTL_CONSTRAINT_REQUEST with parameter 0.
this is an invalid OPP ID and should not be passed anywhere.
we add a param check for this prior to passing it along to the
workqueue.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/wmd/io_sm.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 6c140c5..618bedb 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -960,9 +960,12 @@ static void IO_DispatchPM(struct work_struct *work)
pArg[1] = pIOMgr-pSharedMem-oppRequest.rqstOppPt;
DBG_Trace(DBG_LEVEL7, IO_DispatchPM : Value of OPP
value =0x%x \n, pArg[1]);
- status = pIOMgr-pIntfFxns-pfnDevCntrl(pIOMgr-
-hWmdContext, WMDIOCTL_CONSTRAINT_REQUEST,
-pArg);
+ if (!pArg[1])
+ status = DSP_EINVALIDARG;
+ else
+ status = pIOMgr-pIntfFxns-pfnDevCntrl(pIOMgr-
+hWmdContext,
+WMDIOCTL_CONSTRAINT_REQUEST, pArg);
if (DSP_FAILED(status)) {
DBG_Trace(DBG_LEVEL7, IO_DispatchPM : Failed
to set constraint = 0x%x \n,
Instead of checking just for 0, isn't it better to check for any value
outside of valid OPPs? (Especially if we need robust implementation
which shouldn't break because of DSP BIOS blackbox!).
yeah, i agree. should check for the max level also. dropping this and
will resend.
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
Re: [PATCH] mfd: twl4030: Driver for twl4030 madc module
Hi, all! On Wed, Nov 25, 2009 at 1:47 PM, Amit Kucheria amit.kuche...@verdurent.com wrote: From: Mikko Ylinen mikko.k.yli...@nokia.com This ADC allows monitoring of analog signals such as battery levels, temperatures, etc. Several people have contributed to this driver on the linux-omap list. Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com --- drivers/mfd/Kconfig | 21 ++ drivers/mfd/Makefile | 3 +- drivers/mfd/twl4030-madc.c | 548 ++ include/linux/i2c/twl4030-madc.h | 126 + 4 files changed, 697 insertions(+), 1 deletions(-) create mode 100644 drivers/mfd/twl4030-madc.c create mode 100644 include/linux/i2c/twl4030-madc.h We have just tried to adopt this driver to our custom OMAP3 board, but were unable to get any interrupts. Any ideas on what is missing? We've checked whole TRM and found nothing wrong yet :( Thanks a lot. S. -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
With this patch, omap opp layer now has its compilation flags
bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
A new file has been created to contain cpu freq code related to
OMAP3: cpufreq34xx.c.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
NAK also for the following non-working kernel (smartreflex without
cpufreq).
Then this is a problem of dependency with smartreflex and cpufreq. In this
case
better to solve this other problem with another patch. This patch is to rip
off
cpufreq code from pm34xx, as stated in the above description.
In that case the right fix should
OK
1) __not__ include opp.h for non cpufreq builds
I guess the patch is more or less this option, as it maps
all functions inside opp.h to nops if it is a cpufreq build.
And all related real code is not compiled.
Basically removes the opp layer code if cpufreq is disabled.
One thing I forgot to add here was this part:
diff --git a/arch/arm/plat-omap/include/plat/opp_twl_tps.h
b/arch/arm/plat-omap/include/plat/opp
index 8784e5f..0460ca8 100644
--- a/arch/arm/plat-omap/include/plat/opp_twl_tps.h
+++ b/arch/arm/plat-omap/include/plat/opp_twl_tps.h
@@ -15,7 +15,16 @@
#include linux/kernel.h
+#ifdef CONFIG_CPU_FREQ
unsigned long omap_twl_vsel_to_uv(const u8 vsel);
u8 omap_twl_uv_to_vsel(unsigned long uV);
+#else
+static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+}
+static inline u8 omap_twl_uv_to_vsel(unsigned long uV)
+{
+}
+#endif
OR
2) If it includes opp.h the functions for getting current opp
should abstract out the right mechanism to get current frequency/voltage from
the chip/power IC.
I guess this looks as good way to do it. But the patch I sent is more like the
first
option and fixes the compilation issue.
And sorry, I didn't get your boot log (if you intended to put it, as you
said
following non-working kernel
Actually I meant for the following non-working kernel __configuration__. I do
not have boot logs!
Ahh. right! No I see. Yeah, as mention in other thread, the patch is meant to
fix that one.
--
Eduardo Valentin
--
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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Eduardo Valentin wrote: On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote: Eduardo Valentin wrote: On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote: From: Eduardo Valentin eduardo.valen...@nokia.com OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only. With this patch, omap opp layer now has its compilation flags bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c. A new file has been created to contain cpu freq code related to OMAP3: cpufreq34xx.c. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com NAK also for the following non-working kernel (smartreflex without cpufreq). Then this is a problem of dependency with smartreflex and cpufreq. In this case better to solve this other problem with another patch. This patch is to rip off cpufreq code from pm34xx, as stated in the above description. In that case the right fix should OK 1) __not__ include opp.h for non cpufreq builds I guess the patch is more or less this option, as it maps all functions inside opp.h to nops if it is a cpufreq build. And all related real code is not compiled. Basically removes the opp layer code if cpufreq is disabled. IMHO, making functions return 0 will give you run time issues when opp related APIs are called in non cpufreq path. So your patch will for the time being solve the build issue but not runtime issue. Hence I suggested to compile out opp.h if you are not using cpufreq. Solving a build issue is not the right fix for this. -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 01:44:31PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
With this patch, omap opp layer now has its compilation flags
bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
A new file has been created to contain cpu freq code related to
OMAP3: cpufreq34xx.c.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
NAK also for the following non-working kernel (smartreflex without
cpufreq).
Then this is a problem of dependency with smartreflex and cpufreq. In
this case
better to solve this other problem with another patch. This patch is to
rip off
cpufreq code from pm34xx, as stated in the above description.
In that case the right fix should
OK
1) __not__ include opp.h for non cpufreq builds
I guess the patch is more or less this option, as it maps
all functions inside opp.h to nops if it is a cpufreq build.
And all related real code is not compiled.
Basically removes the opp layer code if cpufreq is disabled.
IMHO, making functions return 0 will give you run time issues when opp related
APIs are called in non cpufreq path. So your patch will for the time being
solve
the build issue but not runtime issue. Hence I suggested to compile out opp.h
if
you are not using cpufreq. Solving a build issue is not the right fix for
this.
No, they are cleaned up by compiler. The following:
+static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return 0;
+}
will be translated to a nop in final kernel image.
That's the whole idea of this patch.
--
Eduardo Valentin
--
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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 01:44:31PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ only.
With this patch, omap opp layer now has its compilation flags
bound to CONFIG_CPU_FREQ. Also its code has been removed from pm34xx.c.
A new file has been created to contain cpu freq code related to
OMAP3: cpufreq34xx.c.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
NAK also for the following non-working kernel (smartreflex without
cpufreq).
Then this is a problem of dependency with smartreflex and cpufreq. In
this case
better to solve this other problem with another patch. This patch is to
rip off
cpufreq code from pm34xx, as stated in the above description.
In that case the right fix should
OK
1) __not__ include opp.h for non cpufreq builds
I guess the patch is more or less this option, as it maps
all functions inside opp.h to nops if it is a cpufreq build.
And all related real code is not compiled.
Basically removes the opp layer code if cpufreq is disabled.
IMHO, making functions return 0 will give you run time issues when opp
related
APIs are called in non cpufreq path. So your patch will for the time being
solve
the build issue but not runtime issue. Hence I suggested to compile out
opp.h if
you are not using cpufreq. Solving a build issue is not the right fix for
this.
No, they are cleaned up by compiler. The following:
+static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return 0;
+}
will be translated to a nop in final kernel image.
That's the whole idea of this patch.
Ok, what I mean is that it still solves build issue only. It does not produce a
bootable kernel without CPU_FREQ but with SMARTREFLEX. Smartreflex is almost
always there for a OMAP kernel. It is not a rarely used feature. So this patch
should have another part that fixes the Smartreflex issue!
--
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/2] OMAP: DSS: Add display board file for zoom boards
On Tue, Jan 19, 2010 at 7:52 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Y, Kishore
Sent: Tuesday, January 19, 2010 6:42 PM
To: Tomi Valkeinen
Cc: linux-omap@vger.kernel.org
Subject: [PATCH 1/2] OMAP: DSS: Add display board file for zoom
boards
From: Kishore Y kishor...@ti.com
board-zoom-display.c added as a common file for display
fucntionality
on boards zoom2, zoom3 and 3630sdp
Signed-off-by: Mukund Mittal mmit...@ti.com
Signed-off-by: Kishore Y kishor...@ti.com
---
arch/arm/mach-omap2/Makefile | 3 +
arch/arm/mach-omap2/board-zoom-display.c | 232
+
arch/arm/mach-omap2/board-zoom-peripherals.c | 36
arch/arm/mach-omap2/include/mach/board-zoom.h | 3 +
4 files changed, 274 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-zoom-display.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-
omap2/Makefile
index b32678b..3dbe694 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -91,14 +91,17 @@ obj-$(CONFIG_MACH_NOKIA_RX51) +=
board-rx51.o \
board-rx51-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-display.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-display.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \
+ board-zoom-display.o \
board-zoom-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
new file mode 100644
index 000..c8f47f4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-display.c
snip
+static int zoom_panel_enable_tv(struct omap_dss_device *dssdev)
+{
+ int ret;
+ struct regulator *vdac_reg;
+
+ vdac_reg = regulator_get(NULL, vdda_dac);
+ if (IS_ERR(vdac_reg)) {
+ pr_err(Unable to get vdac regulator\n);
+ return PTR_ERR(vdac_reg);
+ }
[Hiremath, Vaibhav] Same here.
Actually you don't need this regulator_get() at all, DSS2 core already
calls it for you. With upcoming DSS2 updates you will not need
regulator_get() vpll2 too, so I guess it can already be removed too.
--
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 12/18] OMAP3 clock: split out DPLL3 M2 divider functions into clkt3xxx_dpll3m2.c
Paul, On Wed, 20-Jan-10 12:06 AM +0530, Paul Walmsley wrote: (cc'ing Ranjith) Hi Alexander, On Fri, 15 Jan 2010, Alexander Shishkin wrote: On Fri, Jan 15, 2010 at 02:07:04 -0700, Paul Walmsley wrote: Split the DPLL3 M2 divider clock functions out of clock34xx.c and move them into clkt3xxx_dpll3m2.c to improve maintainability. I'm not very familiar with maintainability issues of dpll3m2, so forgive me if it is ignorant for me to ask you to elaborate on this. That is a very good point, those original patch changelogs are pretty crappy. OMAP clock code - same great taste, now with more maintainability! I will update them and repost with more detail. It does look like a bit of an overkill to have a separate file for a divider. But again, I might well be missing the point. Yep, this is definitely a borderline case where it might be more appropriate to keep it in the clock34xx.c file. What ultimately motivated splitting it out was the thought that the AM3517/3505 chips probably won't need this function, since I don't believe they support DVFS [1], so we could skip compiling this function for kernels built for those devices via the Makefile, and not need #ifdefs. Ranjith, could you correct me if I am wrong about the DVFS part? You are right, AM35xx devices do not support DVFS. In fact, the only power management support planned is for the suspend/resume capability with retention (no off mode) 1. AM35x ARM Microprocessor Technical Reference Manual, http://www.ti.com/litv/pdf/sprugr0 - Ranjith -- 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 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
On Wed, Jan 20, 2010 at 01:54:30PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 01:44:31PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 01:00:05PM +0100, ext Romit Dasgupta wrote:
Eduardo Valentin wrote:
On Wed, Jan 20, 2010 at 12:14:59PM +0100, ext Romit Dasgupta wrote:
From: Eduardo Valentin eduardo.valen...@nokia.com
OMAP OPP layer functions now have dependencies of CONFIG_CPU_FREQ
only.
With this patch, omap opp layer now has its compilation flags
bound to CONFIG_CPU_FREQ. Also its code has been removed from
pm34xx.c.
A new file has been created to contain cpu freq code related to
OMAP3: cpufreq34xx.c.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
NAK also for the following non-working kernel (smartreflex without
cpufreq).
Then this is a problem of dependency with smartreflex and cpufreq. In
this case
better to solve this other problem with another patch. This patch is to
rip off
cpufreq code from pm34xx, as stated in the above description.
In that case the right fix should
OK
1) __not__ include opp.h for non cpufreq builds
I guess the patch is more or less this option, as it maps
all functions inside opp.h to nops if it is a cpufreq build.
And all related real code is not compiled.
Basically removes the opp layer code if cpufreq is disabled.
IMHO, making functions return 0 will give you run time issues when opp
related
APIs are called in non cpufreq path. So your patch will for the time being
solve
the build issue but not runtime issue. Hence I suggested to compile out
opp.h if
you are not using cpufreq. Solving a build issue is not the right fix for
this.
No, they are cleaned up by compiler. The following:
+static inline unsigned long omap_twl_vsel_to_uv(const u8 vsel)
+{
+ return 0;
+}
will be translated to a nop in final kernel image.
That's the whole idea of this patch.
Ok, what I mean is that it still solves build issue only. It does not produce
a
bootable kernel without CPU_FREQ but with SMARTREFLEX. Smartreflex is almost
always there for a OMAP kernel. It is not a rarely used feature. So this patch
should have another part that fixes the Smartreflex issue!
Actually, system boots. It does not break the system. What I've tried is:
- rx51 board
- omap3_pm_defconfig without CPU_FREQ
- linux-omap-pm/pm-wip-opp branch + this patch
System boots, but smartreflex disables itself:
...
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Power Management for TI OMAP3.
SR: OPP rate tables not defined for platform, not enabling SmartReflex
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
,..
But it does not break booting procedure.
So, I don't see why this would be a reason for doing this compilation fix
into two steps. Unless you see another issue.
BR,
--
Eduardo Valentin
--
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 1/6] omap3: pm: re-program the sleep state of TRITON resources by modifying the REMAP register
x0080...@ti.com wrote:
From: Lesly A M x0080...@ti.com
omap3: pm: re-program the sleep state of TRITON resources by modifying the
REMAP register
Removed the warning print with checking order of scripts, since the order
is not important. Only the values configured in the register, which is
pointing to
the starting address of each sequence should be correct.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl4030-power.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
Index: linux-omap-pm/drivers/mfd/twl4030-power.c
===
--- linux-omap-pm.orig/drivers/mfd/twl4030-power.c2010-01-19
19:18:56.0 +0530
+++ linux-omap-pm/drivers/mfd/twl4030-power.c 2010-01-19 19:19:02.0
+0530
@@ -416,14 +416,35 @@
return err;
}
- return 0;
+
+ /* Set the remap sleep cmd */
+ err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+ rconfig_addr + REMAP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 Resource %d remap could not read\n,
+ rconfig-resource);
+ return err;
+ }
+
+ if (rconfig-remap_sleep = 0) {
+ remap = ~SLEEP_STATE_MASK;
+ remap |= rconfig-remap_sleep;
+ }
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+ rconfig_addr + REMAP_OFFSET);
+ if (err 0) {
+ pr_err(TWL4030 failed to program remap sleep cmd \n);
+ return err;
+ }
+
Is it necessary to initialize the remap sleep twice?
+ return err;
}
static int __init load_twl4030_script(struct twl4030_script *tscript,
u8 address)
{
int err;
- static int order;
/* Make sure the script isn't going beyond last valid address (0x3f) */
if ((address + tscript-size) END_OF_SCRIPT) {
@@ -444,7 +465,6 @@
err = twl4030_config_wakeup12_sequence(address);
if (err)
goto out;
- order = 1;
}
if (tscript-flags TWL4030_WAKEUP3_SCRIPT) {
err = twl4030_config_wakeup3_sequence(address);
@@ -452,10 +472,6 @@
goto out;
}
if (tscript-flags TWL4030_SLEEP_SCRIPT)
- if (order)
- pr_warning(TWL4030: Bad order of scripts (sleep \
- script before wakeup) Leads to boot\
- failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
out:
return err;
--
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
--
Sincerely yours,
Mike.
--
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/8] OMAP3: PM: Open Switch Retention support in the cpuidle thread.
In OMAP all power domains embed some logic and some memory. The power domain memory contains memory arrays: powered by a dedicated voltage rail memory logic : powered by the same voltage rail as the power domain logic but has a dedicated power switch(power on switch) The power domain logic for some power domains can be split between retention flip flops (RFF) or nonretention flip flops (DFF). When a power domain is in Open Switch Retention(OSWR) power on switch is set to 0, Vdd can be lowered to its retention value and is provided only to the RFF logic. Only the RFF logic is retained. The DFF logic is lost and reset on wakeup. The voltage to the memory arrays can be retained or cut which will in turn lead to memory arrays retaining or losing their contents This patch series introduces OSWR support for MPU and core domain in the cpuidle thread. The voltage to memory arrays in these power domains are also cut during OSWR. Thara Gopinath (8): PM: Increase the cpu idle max state. OMAP3 PM: Conditional UART context save restore. OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state OMAP3 PM: Defining .pwrsts_logic_ret field for core power domain structure OMAP3 PM: Adding conditional core powerdomain context save and restore OMAP3 PM: Enable DPLL4 autoidle after system off. OMAP3 PM: Support for Open SWitch Retention for Core and MPU power domains in cpuidle path OMAP3 PM: Support to enable disable OSWR feature from pm debug fs arch/arm/mach-omap2/board-3430sdp.c |4 + arch/arm/mach-omap2/cpuidle34xx.c | 138 +++-- arch/arm/mach-omap2/pm-debug.c|5 + arch/arm/mach-omap2/pm.h |1 + arch/arm/mach-omap2/pm34xx.c | 137 ++--- arch/arm/mach-omap2/powerdomain.c | 84 +++ arch/arm/mach-omap2/powerdomains34xx.h|2 + arch/arm/mach-omap2/serial.c | 17 ++-- arch/arm/mach-omap2/sleep34xx.S |4 + arch/arm/plat-omap/include/plat/powerdomain.h |4 + arch/arm/plat-omap/include/plat/serial.h |2 +- include/linux/cpuidle.h |2 +- 12 files changed, 342 insertions(+), 58 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 4/8] OMAP3 PM: Defining .pwrsts_logic_ret field for core power domain structure
This patch adds the flag .pwrsts_logic_ret info for the core power domain
in the associated powerdomain structure. This flag specifies the states
core domain logic can hit in event of the domain entering retention.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/powerdomains34xx.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index 588f7e0..6a058c7 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -208,6 +208,7 @@ static struct powerdomain core_34xx_pre_es3_1_pwrdm = {
CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0),
.pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
.dep_bit = OMAP3430_EN_CORE_SHIFT,
.banks= 2,
.pwrsts_mem_ret = {
@@ -226,6 +227,7 @@ static struct powerdomain core_34xx_es3_1_pwrdm = {
.prcm_offs= CORE_MOD,
.omap_chip= OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1),
.pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts_logic_ret = PWRSTS_OFF_RET,
.dep_bit = OMAP3430_EN_CORE_SHIFT,
.flags= PWRDM_HAS_HDWR_SAR, /* for USBTLL only */
.banks= 2,
--
1.5.6.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
[PATCH 3/8] OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state
This patch adds APIs pwrdm_read_next_logic_pwrst and
pwrdm_read_next_mem_pwrst for reading the next programmed
logic and memory state a powerdomain is to hit in event
of the next power domain state being retention.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 71 +
arch/arm/plat-omap/include/plat/powerdomain.h |2 +
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 26b3f3e..06bf290 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -964,6 +964,29 @@ int pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
}
/**
+ * pwrdm_read_next_logic_pwrst - get next powerdomain logic power state
+ * @pwrdm: struct powerdomain * to get next logic power state
+ *
+ * Return the powerdomain pwrdm's logic power state. Returns -EINVAL
+ * if the powerdomain pointer is null or returns the next logic
+ * power state upon success.
+ */
+int pwrdm_read_next_logic_pwrst(struct powerdomain *pwrdm)
+{
+ if (!pwrdm)
+ return -EINVAL;
+
+ /*
+* The register bit names below may not correspond to the
+* actual names of the bits in each powerdomain's register,
+* but the type of value returned is the same for each
+* powerdomain.
+*/
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
+ OMAP3430_LOGICSTATEST);
+}
+
+/**
* pwrdm_read_mem_pwrst - get current memory bank power state
* @pwrdm: struct powerdomain * to get current memory bank power state
* @bank: memory bank number (0-3)
@@ -1065,6 +1088,54 @@ int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
}
/**
+ * pwrdm_read_next_mem_pwrst - get next memory bank power state
+ * @pwrdm: struct powerdomain * to get mext memory bank power state
+ * @bank: memory bank number (0-3)
+ *
+ * Return the powerdomain pwrdm's next memory power state for bank
+ * x. Returns -EINVAL if the powerdomain pointer is null, -EEXIST if
+ * the target memory bank does not exist or is not controllable, or
+ * returns the next memory power state upon success.
+ */
+int pwrdm_read_next_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
+{
+ u32 m;
+
+ if (!pwrdm)
+ return -EINVAL;
+
+ if (pwrdm-banks (bank + 1))
+ return -EEXIST;
+
+ /*
+* The register bit names below may not correspond to the
+* actual names of the bits in each powerdomain's register,
+* but the type of value returned is the same for each
+* powerdomain.
+*/
+ switch (bank) {
+ case 0:
+ m = OMAP3430_SHAREDL1CACHEFLATRETSTATE;
+ break;
+ case 1:
+ m = OMAP3430_L1FLATMEMRETSTATE;
+ break;
+ case 2:
+ m = OMAP3430_SHAREDL2CACHEFLATRETSTATE;
+ break;
+ case 3:
+ m = OMAP3430_SHAREDL2CACHEFLATRETSTATE;
+ break;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
+ }
+
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ PM_PWSTCTRL, m);
+}
+
+/**
* pwrdm_clear_all_prev_pwrst - clear previous powerstate register for a pwrdm
* @pwrdm: struct powerdomain * to clear
*
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 0b96005..7576559 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -170,8 +170,10 @@ int pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8
bank, u8 pwrst);
int pwrdm_read_logic_pwrst(struct powerdomain *pwrdm);
int pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm);
+int pwrdm_read_next_logic_pwrst(struct powerdomain *pwrdm);
int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
+int pwrdm_read_next_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
int pwrdm_enable_hdwr_sar(struct powerdomain *pwrdm);
int pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm);
--
1.5.6.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
[PATCH 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
DPLL4 autoidle is controlled through the register CM_PLL_AUTOIDLE which is to be restored by rom code from the scratchpad in case of a core domain context loss. But enabling this bit in scratchpad causes rom code to take an extra 20 ms delay in the restore path. To avoid this delay this bit is not enabled in the scratchpad today. This means after a core off happens DPLL4 autoidle is never again enabled back. This patch enables DPLL4 autoidle in case of core domain losing context. Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm34xx.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e4db1ea..6e6d954 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -520,6 +520,14 @@ void omap_sram_idle(void) */ if (cpu_is_omap3430()) usb_musb_disable_autoidle(); + /* We do not program the scratchpad to restore back +* PER DPLL in autoidle due to 20 ms delay in +* rom code restore path. So enable it explicitly +* after core off +*/ + cm_rmw_mod_reg_bits( + 0x0, (1 OMAP3430_AUTO_PERIPH_DPLL_SHIFT), + PLL_MOD, CM_AUTOIDLE); } omap_uart_resume_idle(0); omap_uart_resume_idle(1); -- 1.5.6.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
[PATCH 2/8] OMAP3 PM: Conditional UART context save restore.
Currently UART context save is done in idle
thread thru a call to omap_uart_prepare_idle irrespective of
what power state is attained by the power domain to which
the UART belongs to. This patch allows omap_uart_prepare_idle
to take power state as a parameter and this function in
turn does a uart context save only if the passed power state
is PWRDM_POWER_OFF. In the restore path a restore will
happen only if a valid save has happened.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |6 +++---
arch/arm/mach-omap2/serial.c | 17 +++--
arch/arm/plat-omap/include/plat/serial.h |2 +-
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8f5e819..895e9ef 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -418,7 +418,7 @@ void omap_sram_idle(void)
} else
omap3_per_save_context();
}
- omap_uart_prepare_idle(2);
+ omap_uart_prepare_idle(2, per_next_state);
}
if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
@@ -435,8 +435,8 @@ void omap_sram_idle(void)
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
- omap_uart_prepare_idle(0);
- omap_uart_prepare_idle(1);
+ omap_uart_prepare_idle(0, core_next_state);
+ omap_uart_prepare_idle(1, core_next_state);
if (core_next_state == PWRDM_POWER_OFF) {
u32 voltctrl = OMAP3430_AUTO_OFF;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 837b347..fb59d5f 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -168,9 +168,6 @@ static void omap_uart_save_context(struct omap_uart_state
*uart)
u16 lcr = 0;
struct plat_serial8250_port *p = uart-p;
- if (!enable_off_mode)
- return;
-
lcr = serial_read_reg(p, UART_LCR);
serial_write_reg(p, UART_LCR, 0xBF);
uart-dll = serial_read_reg(p, UART_DLL);
@@ -189,9 +186,6 @@ static void omap_uart_restore_context(struct
omap_uart_state *uart)
u16 efr = 0;
struct plat_serial8250_port *p = uart-p;
- if (!enable_off_mode)
- return;
-
if (!uart-context_valid)
return;
@@ -235,12 +229,15 @@ static inline void omap_uart_enable_clocks(struct
omap_uart_state *uart)
#ifdef CONFIG_PM
-static inline void omap_uart_disable_clocks(struct omap_uart_state *uart)
+static inline void omap_uart_disable_clocks(struct omap_uart_state *uart,
+ int power_state)
{
if (!uart-clocked)
return;
- omap_uart_save_context(uart);
+ if (power_state == PWRDM_POWER_OFF)
+ omap_uart_save_context(uart);
+
uart-clocked = 0;
clk_disable(uart-ick);
clk_disable(uart-fck);
@@ -329,13 +326,13 @@ static void omap_uart_idle_timer(unsigned long data)
omap_uart_allow_sleep(uart);
}
-void omap_uart_prepare_idle(int num)
+void omap_uart_prepare_idle(int num, int power_state)
{
struct omap_uart_state *uart;
list_for_each_entry(uart, uart_list, node) {
if (num == uart-num uart-can_sleep) {
- omap_uart_disable_clocks(uart);
+ omap_uart_disable_clocks(uart, power_state);
return;
}
}
diff --git a/arch/arm/plat-omap/include/plat/serial.h
b/arch/arm/plat-omap/include/plat/serial.h
index f5a4a92..ca76742 100644
--- a/arch/arm/plat-omap/include/plat/serial.h
+++ b/arch/arm/plat-omap/include/plat/serial.h
@@ -57,7 +57,7 @@ extern void omap_serial_init_port(int port);
extern int omap_uart_can_sleep(void);
extern void omap_uart_check_wakeup(void);
extern void omap_uart_prepare_suspend(void);
-extern void omap_uart_prepare_idle(int num);
+extern void omap_uart_prepare_idle(int num, int power_state);
extern void omap_uart_resume_idle(int num);
extern void omap_uart_enable_irqs(int enable);
#endif
--
1.5.6.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
[PATCH 1/8] PM: Increase the cpu idle max state.
This patch increases the maximum number of C states possible in a system in the cpuidle framework. This is necessary for OMAP3/OMAP4 when support for open switch retention of powerdomains are added in the cpuidle path. Signed-off-by: Thara Gopinath th...@ti.com --- include/linux/cpuidle.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h index dcf77fa..8ec8300 100644 --- a/include/linux/cpuidle.h +++ b/include/linux/cpuidle.h @@ -17,7 +17,7 @@ #include linux/kobject.h #include linux/completion.h -#define CPUIDLE_STATE_MAX 8 +#define CPUIDLE_STATE_MAX 16 #define CPUIDLE_NAME_LEN 16 #define CPUIDLE_DESC_LEN 32 -- 1.5.6.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
[PATCH 5/8] OMAP3 PM: Adding conditional core powerdomain context save and restore
This patch adds a parameter core_state , depicting the power state
which the core domain will attempt to enter, to omap3_core_save_context
and omap3_core_restore_context. This is so as to distinguish between
the context save and restore required when core domain is attempting
OSWR and OFF. Core OSWR does not require interrupt controller,
system control module and dma controller context save and retore
where as Core OFF reuires these.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 71 +-
1 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 895e9ef..e4db1ea 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -150,44 +150,57 @@ static void omap3_disable_io_chain(void)
prm_clear_mod_reg_bits(OMAP3430_EN_IO_CHAIN, WKUP_MOD, PM_WKEN);
}
-static void omap3_core_save_context(void)
+static void omap3_core_save_context(int core_state)
{
- u32 control_padconf_off;
+ if (core_state == PWRDM_POWER_OFF) {
+ u32 control_padconf_off;
+
+ /* Save the padconf registers */
+ control_padconf_off = omap_ctrl_readl(
+ OMAP343X_CONTROL_PADCONF_OFF);
+ control_padconf_off |= START_PADCONF_SAVE;
+ omap_ctrl_writel(control_padconf_off,
+ OMAP343X_CONTROL_PADCONF_OFF);
+ /* wait for the save to complete */
+ while (!(omap_ctrl_readl(
+ OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
+ PADCONF_SAVE_DONE))
+ udelay(1);
- /* Save the padconf registers */
- control_padconf_off = omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
- control_padconf_off |= START_PADCONF_SAVE;
- omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
- /* wait for the save to complete */
- while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
-PADCONF_SAVE_DONE))
- udelay(1);
+ /*
+* Force write last pad into memory, as this can fail in some
+* cases according to erratas 1.157, 1.185
+*/
+ omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14),
+ OMAP343X_CONTROL_MEM_WKUP + 0x2a0);
- /*
-* Force write last pad into memory, as this can fail in some
-* cases according to erratas 1.157, 1.185
-*/
- omap_ctrl_writel(omap_ctrl_readl(OMAP343X_PADCONF_ETK_D14),
- OMAP343X_CONTROL_MEM_WKUP + 0x2a0);
+ /* Save the Interrupt controller context */
+ omap_intc_save_context();
+
+ /* Save the system control module context,
+* padconf already save above
+*/
+ omap3_control_save_context();
+ omap_dma_global_context_save();
+ }
- /* Save the Interrupt controller context */
- omap_intc_save_context();
/* Save the GPMC context */
omap3_gpmc_save_context();
- /* Save the system control module context, padconf already save above*/
- omap3_control_save_context();
- omap_dma_global_context_save();
}
-static void omap3_core_restore_context(void)
+static void omap3_core_restore_context(int core_state)
{
- /* Restore the control module context, padconf restored by h/w */
- omap3_control_restore_context();
+ if (core_state == PWRDM_POWER_OFF) {
+ /* Restore the control module context,
+* padconf restored by h/w
+*/
+ omap3_control_restore_context();
+ /* Restore the interrupt controller context */
+ omap_intc_restore_context();
+ omap_dma_global_context_restore();
+ }
/* Restore the GPMC context */
omap3_gpmc_restore_context();
- /* Restore the interrupt controller context */
- omap_intc_restore_context();
- omap_dma_global_context_restore();
}
/*
@@ -445,7 +458,7 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(voltctrl,
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
- omap3_core_save_context();
+ omap3_core_save_context(PWRDM_POWER_OFF);
omap3_prcm_save_context();
} else if (core_next_state == PWRDM_POWER_RET) {
prm_set_mod_reg_bits(OMAP3430_AUTO_RET,
@@ -497,7 +510,7 @@ void omap_sram_idle(void)
if (core_next_state PWRDM_POWER_ON) {
core_prev_state = pwrdm_read_prev_pwrst(core_pwrdm);
if (core_prev_state ==
[PATCH 7/8] OMAP3 PM: Support for Open Switch Retention for Core and MPU power domains in cpuidle path
This patch adds Open SWitch Retention (OSWR) support for
MPU/CORE domains in Cpuidle. In addition to the normal
power domain retention(Closed SWitch retention) in OSWR,
the powerdomain logic is turned OFF. Power domain memory
banks can be chosen to be retained or turned off. In this
implementation both MPU and Core domain memory banks are
turned off during OSWR.
This patch also adds counters ret_logic_off_counter and
ret_mem_off_counter for each power domain. This keeps track
of power domain logic and memory off during powerdomain
retention. These counters together with the retention counter
can be used to find out whether a power domain has entered
OSWR or not. In case of OSWR both the retention counter and
ret_logic_off_counter will get incremented. ret_mem_off_counter
will get incremented if memory bank off during retention
is implemented. In this implementation in case of core or mpu
domain entering OSWR all three flags will be incremented. In
case of normal retention or CSWR only the retention counter
will be incremented
To support this feature two new C states are being added to
the existing C states which makes the new states look like below.
C1 - MPU WFI + Core active
C2 - MPU WFI + Core inactive
C3 - MPU CSWR + Core inactive
C4 - MPU OFF + Core inactive
C5 - MPU CSWR + Core CSWR
C6 - MPU OFF + Core CSWR
C7 - MPU OSWR + CORE OSWR (New State)
C8 - MPU OFF + CORE OSWR (New State)
C9 - MPU OFF + CORE OFF
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |4 +
arch/arm/mach-omap2/cpuidle34xx.c | 129 +++--
arch/arm/mach-omap2/pm-debug.c|3 +
arch/arm/mach-omap2/pm34xx.c | 55 +--
arch/arm/mach-omap2/powerdomain.c | 13 +++
arch/arm/mach-omap2/sleep34xx.S |4 +
arch/arm/plat-omap/include/plat/powerdomain.h |2 +
7 files changed, 194 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 7d68445..071cf22 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -72,6 +72,10 @@ static struct cpuidle_params omap3_cpuidle_params_table[] = {
/* C6 */
{1, 3000, 8500, 15000},
/* C7 */
+ {1, 4000, 1, 15},
+ /* C8 */
+ {1, 8000, 25000, 25},
+ /* C9 */
{1, 1, 3, 30},
};
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 1cfa5a6..419f683 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -36,14 +36,16 @@
#ifdef CONFIG_CPU_IDLE
-#define OMAP3_MAX_STATES 7
+#define OMAP3_MAX_STATES 9
#define OMAP3_STATE_C1 0 /* C1 - MPU WFI + Core active */
#define OMAP3_STATE_C2 1 /* C2 - MPU WFI + Core inactive */
#define OMAP3_STATE_C3 2 /* C3 - MPU CSWR + Core inactive */
#define OMAP3_STATE_C4 3 /* C4 - MPU OFF + Core iactive */
-#define OMAP3_STATE_C5 4 /* C5 - MPU RET + Core RET */
-#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core RET */
-#define OMAP3_STATE_C7 6 /* C7 - MPU OFF + Core OFF */
+#define OMAP3_STATE_C5 4 /* C5 - MPU CSWR + Core CSWR */
+#define OMAP3_STATE_C6 5 /* C6 - MPU OFF + Core CSWR */
+#define OMAP3_STATE_C7 6 /* C7 - MPU OSWR + Core OSWR */
+#define OMAP3_STATE_C8 7 /* C8 - MPU OFF + Core OSWR */
+#define OMAP3_STATE_C9 8 /* C9 - MPU OFF + CORE OFF */
struct omap3_processor_cx {
u8 valid;
@@ -52,6 +54,11 @@ struct omap3_processor_cx {
u32 wakeup_latency;
u32 mpu_state;
u32 core_state;
+ u32 mpu_logicl1_ret_state;
+ u32 mpu_l2cache_ret_state;
+ u32 core_logic_state;
+ u32 core_mem1_ret_state;
+ u32 core_mem2_ret_state;
u32 threshold;
u32 flags;
};
@@ -81,6 +88,10 @@ static struct cpuidle_params cpuidle_params_table[] = {
/* C6 */
{1, 3000, 8500, 15000},
/* C7 */
+ {1, 4000, 1, 15},
+ /* C8 */
+ {1, 8000, 25000, 25},
+ /* C9 */
{1, 1, 3, 30},
};
@@ -119,6 +130,11 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
struct omap3_processor_cx *cx = cpuidle_get_statedata(state);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
+ u32 mpu_logicl1_ret_state = cx-mpu_logicl1_ret_state;
+ u32 mpu_l2cache_ret_state = cx-mpu_l2cache_ret_state;
+ u32 core_logic_state = cx-core_logic_state;
+ u32 core_mem1_ret_state = cx-core_mem1_ret_state;
+ u32 core_mem2_ret_state = cx-core_mem2_ret_state;
current_cx_state = *cx;
@@ -135,6 +151,20 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
core_state = PWRDM_POWER_RET;
}
+ /* For any state above inactive set the logic and memory
[PATCH 8/8] OMAP3 PM: Support to enable disable OSWR feature from pm debug fs
This patch adds enable_oswr flag in pm debug fs to enable
disable OSWR feature.
To enable this feature:
echo 1 path/debug/pm_debug/enable_oswr
To disable this feature
echo 0 path/debug/pm_debug/enable_oswr
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c |9 +
arch/arm/mach-omap2/pm-debug.c|2 ++
arch/arm/mach-omap2/pm.h |1 +
arch/arm/mach-omap2/pm34xx.c |1 +
4 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 419f683..91ef0df 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -155,11 +155,20 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
* bits in case the powerdomain enters retention
*/
if (mpu_state = PWRDM_POWER_RET) {
+ if (!enable_oswr) {
+ mpu_logicl1_ret_state = PWRDM_POWER_RET;
+ mpu_l2cache_ret_state = PWRDM_POWER_RET;
+ }
pwrdm_set_logic_retst(mpu_pd, mpu_logicl1_ret_state);
pwrdm_set_mem_retst(mpu_pd, 0, mpu_l2cache_ret_state);
}
if (core_state = PWRDM_POWER_RET) {
+ if (!enable_oswr) {
+ core_logic_state = PWRDM_POWER_RET;
+ core_mem1_ret_state = PWRDM_POWER_RET;
+ core_mem2_ret_state = PWRDM_POWER_RET;
+ }
pwrdm_set_logic_retst(core_pd, core_logic_state);
pwrdm_set_mem_retst(core_pd, 0, core_mem1_ret_state);
pwrdm_set_mem_retst(core_pd, 1, core_mem2_ret_state);
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 035cfa7..cdb081b 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -601,6 +601,8 @@ static int __init pm_dbg_init(void)
enable_off_mode, pm_dbg_option_fops);
(void) debugfs_create_file(sleep_while_idle, S_IRUGO | S_IWUGO, d,
sleep_while_idle, pm_dbg_option_fops);
+ (void) debugfs_create_file(enable_oswr, S_IRUGO | S_IWUGO, d,
+ enable_oswr, pm_dbg_option_fops);
(void) debugfs_create_file(wakeup_timer_seconds, S_IRUGO | S_IWUGO, d,
wakeup_timer_seconds, pm_dbg_option_fops);
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 75aa685..03c49a8 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -15,6 +15,7 @@
extern u32 enable_off_mode;
extern u32 sleep_while_idle;
+extern u32 enable_oswr;
extern u32 voltage_off_while_idle;
extern void *omap3_secure_ram_storage;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bfdcac2..53c08a5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -73,6 +73,7 @@ static inline bool is_suspending(void)
u32 enable_off_mode;
u32 sleep_while_idle;
+u32 enable_oswr;
u32 wakeup_timer_seconds;
u32 voltage_off_while_idle;
--
1.5.6.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] DSPBRIDGE: dont pass invalid DSP OPP requests
From: Nishanth Menon on Wednesday, January 20, 2010 6:02 AM
Ameya Palande said the following on 01/20/2010 04:01 AM:
Hi Nishanth,
On Wed, 2010-01-20 at 02:44 +0100, ext Nishanth Menon wrote:
If DSP baseimage requests for invalid OPPs, do not pass them
to the rest of the linux kernel subsystem. with a test baseimage
it was found to send
IO_DispatchPM: WMDIOCTL_CONSTRAINT_REQUEST with parameter 0.
this is an invalid OPP ID and should not be passed anywhere.
we add a param check for this prior to passing it along to the
workqueue.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/wmd/io_sm.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 6c140c5..618bedb 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -960,9 +960,12 @@ static void IO_DispatchPM(struct work_struct *work)
pArg[1] = pIOMgr-pSharedMem-oppRequest.rqstOppPt;
DBG_Trace(DBG_LEVEL7, IO_DispatchPM : Value of OPP
value =0x%x \n, pArg[1]);
- status = pIOMgr-pIntfFxns-pfnDevCntrl(pIOMgr-
-hWmdContext, WMDIOCTL_CONSTRAINT_REQUEST,
-pArg);
+ if (!pArg[1])
+ status = DSP_EINVALIDARG;
+ else
+ status = pIOMgr-pIntfFxns-pfnDevCntrl(pIOMgr-
+hWmdContext,
+WMDIOCTL_CONSTRAINT_REQUEST, pArg);
if (DSP_FAILED(status)) {
DBG_Trace(DBG_LEVEL7, IO_DispatchPM : Failed
to set constraint = 0x%x \n,
Instead of checking just for 0, isn't it better to check for any value
outside of valid OPPs? (Especially if we need robust implementation
which shouldn't break because of DSP BIOS blackbox!).
Dsp will ask only for the opps programmed to the shared memory... so no need,
as long as the shared memory is filled with the right values.
yeah, i agree. should check for the max level also. dropping this and
will resend.
Dsp doesn't request opp 0 to kernel.
- 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
[PATCH] OMAP: omap_device: add omap_device_is_valid()
The omap_device struct contains a 'struct platform_device'. Normally,
converting a platform_device pointer to an omap_device pointer
consists of simply doing a container_of(), as is done currently by the
to_omap_device() macro.
However, if this is attempted when using platform_device that has not
been created as part of the omap_device creation, the container_of()
will point to a memory location before the platform_device pointer
which will contain random data.
Therefore, we need a way to detect valid omap_device pointers. This
patch solves this by using the simple magic number approach.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 16
2 files changed, 18 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 76d4917..4677ff7 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -62,6 +62,7 @@
*
*/
struct omap_device {
+ u32 magic;
struct platform_device pdev;
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
@@ -81,6 +82,7 @@ int omap_device_shutdown(struct platform_device *pdev);
/* Core code interface */
+bool omap_device_is_valid(struct omap_device *od);
int omap_device_count_resources(struct omap_device *od);
int omap_device_fill_resources(struct omap_device *od, struct resource *res);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d8c75c8..3d1baa1 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -100,6 +100,8 @@
# error Unknown OMAP device
#endif
+#define OMAP_DEVICE_MAGIC 0xf00dcafe
+
/* Private functions */
/**
@@ -417,6 +419,8 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
if (ret)
goto odbs_exit4;
+ od-magic = OMAP_DEVICE_MAGIC;
+
return od;
odbs_exit4:
@@ -599,6 +603,18 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
}
/**
+ * omap_device_is_valid()
+ * @od: struct omap_device *
+ *
+ * Return whether struct omap_device pointer @od points to a valid
+ * omap_device.
+ */
+bool omap_device_is_valid(struct omap_device *od)
+{
+ return (od od-magic == OMAP_DEVICE_MAGIC);
+}
+
+/**
* omap_device_get_pwrdm - return the powerdomain * associated with @od
* @od: struct omap_device *
*
--
1.6.6
--
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 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
Hi Thara, two comments: On Wed, 20 Jan 2010, Thara Gopinath wrote: DPLL4 autoidle is controlled through the register CM_PLL_AUTOIDLE which is to be restored by rom code from the scratchpad in case of a core domain context loss. But enabling this bit in scratchpad causes rom code to take an extra 20 ms delay in the restore path. To avoid this delay this bit is not enabled in the scratchpad today. This means after a core off happens DPLL4 autoidle is never again enabled back. This patch enables DPLL4 autoidle in case of core domain losing context. Shouldn't this be contingent on whether DPLL4 autoidle was enabled before the CORE off transition? Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm34xx.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e4db1ea..6e6d954 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -520,6 +520,14 @@ void omap_sram_idle(void) */ if (cpu_is_omap3430()) usb_musb_disable_autoidle(); + /* We do not program the scratchpad to restore back + * PER DPLL in autoidle due to 20 ms delay in + * rom code restore path. So enable it explicitly + * after core off + */ This multi-line comment needs to be fixed to conform to Documentation/CodingStyle. + cm_rmw_mod_reg_bits( + 0x0, (1 OMAP3430_AUTO_PERIPH_DPLL_SHIFT), + PLL_MOD, CM_AUTOIDLE); } omap_uart_resume_idle(0); omap_uart_resume_idle(1); -- 1.5.6.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 - 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] OMAP35xx:SDIO IRQ Support for OMAP35xx
On 21.12.2009 17:46, Mike Rapoport wrote:
Hi,
Phaneendra Kumar Alapati wrote:
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneendra Kumarph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
I've tried the patch on CM-T35 that has Marvell 88W8686 on-board and
surprisingly I get a lot of command timeouts from the libertas driver :(
---
libertas: requeueing command 0x0006 due to timeout (#1)
libertas: Received result 0 to command 6 after 1 retries
libertas: command 0x0006 timed out
---
I hope I'll find time to debug it in the next few days and provide more valuable
information...
There is a test report from Overo air that there it doesn't work, too:
http://old.nabble.com/Re%3A-Overo-wifi-speed-and-WPA2-connection-issue-p27231874.html
Any news on this patch?
Best regards
Dirk
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD (1 26)
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
int vdd;
int protect_card;
int reqs_blocked;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ }
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
spin_lock(host-irq_lock);
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO Card Interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+ host-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE)));
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) (~CIRQ_ENABLE)));
+ }
+
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq
[no subject]
Bcc: Subject: GPIO chip select support in omap2_mcspi driver Hey, Recently I have been looking to use a BeagleBoard to drive several serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, the BeagleBoard is severely limited by the number of SPI controllers it exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 with one). This is insufficient for our application and thus I have been investigating adding support to the mcspi driver for using GPIO lines as chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. To this end, I have a few questions about how this support was implemented. First, it seems that the s3c24xx driver is built on the spi_bitbang driver, despite interfacing with a dedicated hardware SPI controller. What is the reason for this? Was this done specifically for the purpose of incorporating support for GPIO CS pins? It seems like the rough idea is to add a cs_gpio field to the device struct (omap2_mcspi) and add the appropriate code to the omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The potential problem I can see with this is that omap2_mcspi_set_enable() is called to enable the channel before the force_cs() is called (in omap2_mcspi_work()). If I'm interpreting the documentation correctly, the enable bit starts the clocks, meaning that the chip will begin clocking out data before CS is brought high. I must be missing something here, no? For reference, I included a short list of relevant commits below, largely for my own benefit. I would greatly appreciate any feedback you might have. Thanks, - Ben pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 -- 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 0/3] OMAP4: prcm/clock fixes
Hi, On Tue, 19 Jan 2010, Paul Walmsley wrote: On Tue, 19 Jan 2010, Paul Walmsley wrote: This patch is now posted for any comments or review: http://www.pwsan.com/omap/patches/omap4_clk_fix/0001-OMAP4-PRCM-Define-shift-macros-as-n-instead-of-1.patch Thanks, this is a total brown paper bag bug :-( Queued for 2.6.33-rc. Based on some advice from Tony, this patch has been moved to the for_2.6.34 branch. Please let me know if this causes any problems. - 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 v2] More OMAP clock/hwmod fixes for 2.6.33-rc
Hi Tony, The following changes since commit 7284ce6c9f6153d1777df5f310c959724d1bd446: Linus Torvalds (1): Linux 2.6.33-rc4 are available in the git repository at: git://git.pwsan.com/linux-2.6 for_2.6.33rc_d This updated branch updates RMK's E-mail address and moves the OMAP4 PRCM shift patch to the for_2.6.34 branch. Paul Walmsley (1): OMAP1 clock: fix for BUG: spinlock lockup on CPU#0 Rajendra Nayak (2): OMAP4: PRCM: Fix the base address for CHIRONSS reg defines OMAP4: clocks: Fix the clksel_rate struct DPLL divs Russell King (1): OMAP3: clock: Remove unnecessarily .init initializers from OMAP3 clocks Thara Gopinath (1): OMAP3: hwmod: Adding flag to prevent caching of sysconfig register. arch/arm/mach-omap1/clock.c |6 +- arch/arm/mach-omap2/clock34xx_data.c |4 -- arch/arm/mach-omap2/clock44xx_data.c | 62 +- arch/arm/mach-omap2/omap_hwmod.c |3 +- arch/arm/mach-omap2/prm.h|2 + arch/arm/mach-omap2/prm44xx.h| 32 +++--- arch/arm/plat-omap/include/plat/omap_hwmod.h |1 + 7 files changed, 55 insertions(+), 55 deletions(-) - 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
[PATCH 0/4] omap fixes for 2.6.33-rc4
Hi all, Here are some omap fixes for review. Regards, Tony --- Roel Kluin (1): OMAP: dma_chan[lch_head].flag OMAP_DMA_ACTIVE tested twice in omap_dma_unlink_lch() Tony Lindgren (3): omap: Fix cmdline muxing omap: Fix functions for dynamic remuxing of pins omap3: Fix cpu detection arch/arm/mach-omap2/id.c | 41 +++-- arch/arm/mach-omap2/mux.c | 27 -- arch/arm/mach-omap2/mux.h | 24 +++ arch/arm/plat-omap/dma.c |2 +- arch/arm/plat-omap/include/plat/cpu.h |1 + 5 files changed, 64 insertions(+), 31 deletions(-) -- Signature -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] omap: Fix cmdline muxing
Looks like cmdline muxing got broken at some point when we decided to limit muxing to __init code. Currently omap_mux_entry list is not yet initialized when we try to initialize cmdline muxing. Fix this by calling omap_mux_init_list() before calling omap_mux_set_cmdline_signals(). Reported-by: Philip Balister phi...@balister.org Tested-by: Philip Balister phi...@balister.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/mux.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c index 459ef23..40ea9fd 100644 --- a/arch/arm/mach-omap2/mux.c +++ b/arch/arm/mach-omap2/mux.c @@ -998,12 +998,15 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size, omap_mux_package_fixup(package_subset, superset); if (package_balls) omap_mux_package_init_balls(package_balls, superset); - omap_mux_set_cmdline_signals(); - omap_mux_set_board_signals(board_mux); #endif omap_mux_init_list(superset); +#ifdef CONFIG_OMAP_MUX + omap_mux_set_cmdline_signals(); + omap_mux_set_board_signals(board_mux); +#endif + return 0; } -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] omap3: Fix cpu detection
We need to set the omap_chip.oc carefully for the clocks to work.
To fix this, set the omap_chip.oc in omap3_check_features() based
on the CONTROL_IDCODE and silicon revision registers.
Also add handling for 34xx es3.1.2 as es3.1 for now.
Fixes booting on at least overo board.
Based on an earlier patch by Paul Walmsley p...@pwsan.com.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/id.c | 41 +++--
arch/arm/plat-omap/include/plat/cpu.h |1 +
2 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a091b53..3d65c50 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -188,6 +188,8 @@ void __init omap3_check_revision(void)
u16 hawkeye;
u8 rev;
+ omap_chip.oc = CHIP_IS_OMAP3430;
+
/*
* We cannot access revision registers on ES1.0.
* If the processor type is Cortex-A8 and the revision is 0x0
@@ -196,6 +198,7 @@ void __init omap3_check_revision(void)
cpuid = read_cpuid(CPUID_ID);
if cpuid 4) 0xfff) == 0xc08) ((cpuid 0xf) == 0x0)) {
omap_revision = OMAP3430_REV_ES1_0;
+ omap_chip.oc |= CHIP_IS_OMAP3430ES1;
return;
}
@@ -216,18 +219,28 @@ void __init omap3_check_revision(void)
case 0: /* Take care of early samples */
case 1:
omap_revision = OMAP3430_REV_ES2_0;
+ omap_chip.oc |= CHIP_IS_OMAP3430ES2;
break;
case 2:
omap_revision = OMAP3430_REV_ES2_1;
+ omap_chip.oc |= CHIP_IS_OMAP3430ES2;
break;
case 3:
omap_revision = OMAP3430_REV_ES3_0;
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
break;
case 4:
+ omap_revision = OMAP3430_REV_ES3_1;
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ break;
+ case 7:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- omap_revision = OMAP3430_REV_ES3_1;
+ omap_revision = OMAP3430_REV_ES3_1_2;
+
+ /* REVISIT: Add CHIP_IS_OMAP3430ES3_1_2? */
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
}
break;
case 0xb868:
@@ -235,14 +248,18 @@ void __init omap3_check_revision(void)
*
* Set the device to be OMAP3505 here. Actual device
* is identified later based on the features.
+*
+* REVISIT: AM3505/AM3517 should have their own CHIP_IS
*/
omap_revision = OMAP3505_REV(rev);
+ omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
/* FALLTHROUGH */
default:
/* Unknown default to latest silicon rev as default*/
omap_revision = OMAP3630_REV_ES1_0;
+ omap_chip.oc |= CHIP_IS_OMAP3630ES1;
}
}
@@ -360,6 +377,7 @@ void __init omap2_check_revision(void)
omap3_check_revision();
omap3_check_features();
omap3_cpuinfo();
+ return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
return;
@@ -374,27 +392,14 @@ void __init omap2_check_revision(void)
if (cpu_is_omap243x()) {
/* Currently only supports 2430ES2.1 and 2430-all */
omap_chip.oc |= CHIP_IS_OMAP2430;
+ return;
} else if (cpu_is_omap242x()) {
/* Currently only supports 2420ES2.1.1 and 2420-all */
omap_chip.oc |= CHIP_IS_OMAP2420;
- } else if (cpu_is_omap3505() || cpu_is_omap3517()) {
- omap_chip.oc = CHIP_IS_OMAP3430 | CHIP_IS_OMAP3430ES3_1;
- } else if (cpu_is_omap343x()) {
- omap_chip.oc = CHIP_IS_OMAP3430;
- if (omap_rev() == OMAP3430_REV_ES1_0)
- omap_chip.oc |= CHIP_IS_OMAP3430ES1;
- else if (omap_rev() = OMAP3430_REV_ES2_0
-omap_rev() = OMAP3430_REV_ES2_1)
- omap_chip.oc |= CHIP_IS_OMAP3430ES2;
- else if (omap_rev() == OMAP3430_REV_ES3_0)
- omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
- else if (omap_rev() == OMAP3430_REV_ES3_1)
- omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
- else if (omap_rev() == OMAP3630_REV_ES1_0)
- omap_chip.oc |= CHIP_IS_OMAP3630ES1;
- } else {
- pr_err(Uninitialized
[PATCH 4/4] OMAP: dma_chan[lch_head].flag OMAP_DMA_ACTIVE tested twice in omap_dma_unlink_lch()
From: Roel Kluin roel.kl...@gmail.com
The same flag and bits were tested twice.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 09d82b3..728c642 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -1183,7 +1183,7 @@ void omap_dma_unlink_lch(int lch_head, int lch_queue)
}
if ((dma_chan[lch_head].flags OMAP_DMA_ACTIVE) ||
- (dma_chan[lch_head].flags OMAP_DMA_ACTIVE)) {
+ (dma_chan[lch_queue].flags OMAP_DMA_ACTIVE)) {
printk(KERN_ERR omap_dma: You need to stop the DMA channels
before unlinking\n);
dump_stack();
--
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/4] omap: Fix functions for dynamic remuxing of pins
Make the omap_mux_read and write available for board code,
and rename omap_mux_set_board_signals into omap_mux_write_array.
Also add the related prototypes and comments into mux.h.
In some cases we want to change the signals dynamically,
mostly for power management.
Note that we cannot use the signal names as they are set
__init to save memory.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/mux.c | 22 +++---
arch/arm/mach-omap2/mux.h | 24
2 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 40ea9fd..3f59bd1 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -51,7 +51,7 @@ struct omap_mux_entry {
static unsigned long mux_phys;
static void __iomem *mux_base;
-static inline u16 omap_mux_read(u16 reg)
+u16 omap_mux_read(u16 reg)
{
if (cpu_is_omap24xx())
return __raw_readb(mux_base + reg);
@@ -59,7 +59,7 @@ static inline u16 omap_mux_read(u16 reg)
return __raw_readw(mux_base + reg);
}
-static inline void omap_mux_write(u16 val, u16 reg)
+void omap_mux_write(u16 val, u16 reg)
{
if (cpu_is_omap24xx())
__raw_writeb(val, mux_base + reg);
@@ -67,6 +67,14 @@ static inline void omap_mux_write(u16 val, u16 reg)
__raw_writew(val, mux_base + reg);
}
+void omap_mux_write_array(struct omap_board_mux *board_mux)
+{
+ while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
+ omap_mux_write(board_mux-value, board_mux-reg_offset);
+ board_mux++;
+ }
+}
+
#if defined(CONFIG_ARCH_OMAP24XX) defined(CONFIG_OMAP_MUX)
static struct omap_mux_cfg arch_mux_cfg;
@@ -833,14 +841,6 @@ static void __init omap_mux_set_cmdline_signals(void)
kfree(options);
}
-static void __init omap_mux_set_board_signals(struct omap_board_mux *board_mux)
-{
- while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
- omap_mux_write(board_mux-value, board_mux-reg_offset);
- board_mux++;
- }
-}
-
static int __init omap_mux_copy_names(struct omap_mux *src,
struct omap_mux *dst)
{
@@ -1004,7 +1004,7 @@ int __init omap_mux_init(u32 mux_pbase, u32 mux_size,
#ifdef CONFIG_OMAP_MUX
omap_mux_set_cmdline_signals();
- omap_mux_set_board_signals(board_mux);
+ omap_mux_write_array(board_mux);
#endif
return 0;
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index d8b4d5a..f8c2e7a 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -147,6 +147,30 @@ u16 omap_mux_get_gpio(int gpio);
void omap_mux_set_gpio(u16 val, int gpio);
/**
+ * omap_mux_read() - read mux register
+ * @mux_offset:Offset of the mux register
+ *
+ */
+u16 omap_mux_read(u16 mux_offset);
+
+/**
+ * omap_mux_write() - write mux register
+ * @val: New mux register value
+ * @mux_offset:Offset of the mux register
+ *
+ * This should be only needed for dynamic remuxing of non-gpio signals.
+ */
+void omap_mux_write(u16 val, u16 mux_offset);
+
+/**
+ * omap_mux_write_array() - write an array of mux registers
+ * @board_mux: Array of mux registers terminated by MAP_MUX_TERMINATOR
+ *
+ * This should be only needed for dynamic remuxing of non-gpio signals.
+ */
+void omap_mux_write_array(struct omap_board_mux *board_mux);
+
+/**
* omap3_mux_init() - initialize mux system with board specific set
* @board_mux: Board specific mux table
* @flags: OMAP package type used for the board
--
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
[RFC] [PATCH 2/2] DSPBRIDGE: pm: use pm-wip-opp APIs for opp list
Use the PM-WIP-OPP branch apis for generating the opp list for DSP.
This allows for scaling accross 3430,3440,3450 and 3630 series.
Caveat: does not handle dynamic addition of opp after the
bridgedriver is inserted - this can be done once the framework for
the same is made available
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
caveat: this does not use the ENUM implementation yet, this can be once it is
merged to pm-wip-opp branch.
arch/arm/mach-omap2/dspbridge.c | 99 ++-
1 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
index 26b860f..935afd7 100644
--- a/arch/arm/mach-omap2/dspbridge.c
+++ b/arch/arm/mach-omap2/dspbridge.c
@@ -15,6 +15,20 @@
#ifdef CONFIG_BRIDGE_DVFS
#include mach/omap-pm.h
+#include plat/opp.h
+/*
+ * The DSP load balancer works on the following logic:
+ * Opp frequencies:
+ * 0 - Freq 1 Freq 2 - Freq 3
+ * DSP Thresholds for the frequencies:
+ * 0M---X- Freq 1 ---M--X- Freq 2 M--X- Freq 3
+ * Where, M is the minimal threshold and X is maximum threshold
+ *
+ * if from Freq x to Freq y; where x y, transition happens on M
+ * if from Freq x to Freq y; where x y, transition happens on X
+ */
+#define BRIDGE_THRESH_HIGH_PERCENT 95
+#define BRIDGE_THRESH_LOW_PERCENT 88
#endif
#include dspbridge/host_os.h
@@ -42,7 +56,90 @@ static struct dspbridge_platform_data dspbridge_pdata
__initdata = {
static int get_opp_table(struct dspbridge_platform_data *pdata)
{
#ifdef CONFIG_BRIDGE_DVFS
- /* Do nothing now - fill based on PM implementation */
+ int mpu_freqs;
+ int dsp_freqs;
+ int i;
+ struct omap_opp *opp;
+ unsigned long freq, old_rate;
+
+ mpu_freqs = opp_get_opp_count(mpu_opps);
+ dsp_freqs = opp_get_opp_count(dsp_opps);
+ if (mpu_freqs 0 || dsp_freqs 0 || mpu_freqs != dsp_freqs) {
+ pr_err(mpu and dsp frequencies are inconsistent!
+ mpu_freqs=%d dsp_freqs=%d\n, mpu_freqs, dsp_freqs);
+ return -EINVAL;
+ }
+ /* allocate memory if we have opps initialized */
+ pdata-mpu_speeds = kzalloc(sizeof(u32) * mpu_freqs,
+ GFP_KERNEL);
+ if (!pdata-mpu_speeds) {
+ pr_err(unable to allocate memory for the mpu
+ frequencies\n);
+ return -ENOMEM;
+ }
+ opp = mpu_opps;
+ i = 0;
+ freq = 0;
+ while (!IS_ERR(opp = opp_find_freq_ceil(opp, freq))) {
+ pdata-mpu_speeds[i] = freq;
+ freq++;
+ i++;
+ }
+ pdata-mpu_num_speeds = mpu_freqs;
+ pdata-mpu_min_speed = pdata-mpu_speeds[0];
+ pdata-mpu_max_speed = pdata-mpu_speeds[mpu_freqs - 1];
+ /* need an initial terminator */
+ pdata-dsp_freq_table = kzalloc(
+ sizeof(struct dsp_shm_freq_table) *
+ (dsp_freqs + 1), GFP_KERNEL);
+ if (!pdata-dsp_freq_table) {
+ pr_err(unable to allocate memory for the dsp
+ frequencies\n);
+ return -ENOMEM;
+ }
+
+ opp = dsp_opps;
+ i = 1;
+ freq = 0;
+ old_rate = 0;
+ /*
+* the freq table is in terms of khz.. so we need to
+* divide by 1000
+*/
+ while (!IS_ERR(opp = opp_find_freq_ceil(opp, freq))) {
+ /* dsp frequencies are in khz */
+ u32 rate = freq / 1000;
+ /*
+* On certain 34xx silicons, certain OPPs are duplicated
+* for DSP - handle those by copying previous opp value
+*/
+ if (rate == old_rate) {
+ memcpy(pdata-dsp_freq_table[i],
+ pdata-dsp_freq_table[i-1],
+ sizeof(struct dsp_shm_freq_table));
+ } else {
+ pdata-dsp_freq_table[i].dsp_freq = rate;
+ pdata-dsp_freq_table[i].u_volts =
+ opp_get_voltage(opp);
+ /*
+* min threshold:
+* NOTE: index 1 needs a min of 0! else no
+* scaling happens at DSP!
+*/
+ pdata-dsp_freq_table[i].thresh_min_freq =
+ ((old_rate * BRIDGE_THRESH_LOW_PERCENT) / 100);
+
+ /* max threshold */
+ pdata-dsp_freq_table[i].thresh_max_freq =
+ ((rate * BRIDGE_THRESH_HIGH_PERCENT) / 100);
+ }
+ old_rate = rate;
+
[PATCH 0/2] DSPBRIDGE: cleanup OPP handling
Applies on DSPbridge branch: this is a two patch series of which patch 2/2 is provided as two options: a) using legacy implementation b) cleaner one using pm-wip-opp APIs. only (b) has been tested on a 3630 platform. Nishanth Menon (2): DSPBRIDGE: remove dependency of mpu freq DSPBRIDGE: pm: use old implementation for opps OR DSPBRIDGE: pm: use pm-wip-opp APIs for opp list [RFC] arch/arm/mach-omap2/dspbridge.c| 125 arch/arm/plat-omap/include/dspbridge/host_os.h | 13 +++- drivers/dsp/bridge/rmgr/drv_interface.c| 38 --- drivers/dsp/bridge/rmgr/node.c |4 +- drivers/dsp/bridge/rmgr/proc.c |4 +- drivers/dsp/bridge/wmd/io_sm.c | 20 ++--- 6 files changed, 148 insertions(+), 56 deletions(-) Cc: Ameya Palande ameya.pala...@nokia.com Cc: Deepak Chitriki deepak.chitr...@ti.com Cc: Felipe Contreras felipe.contre...@nokia.com Cc: Hiroshi Doyu hiroshi.d...@nokia.com Cc: Omar Ramirez Luna omar.rami...@ti.com 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
[PATCH 2/2] DSPBRIDGE: pm: use old implementation for opps
Use the old implementation for OPP list generation and update.
this is a 1-1 implementation of what we had previously without
support for 3630.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
This probably belongs to dspbridge-pm branch - I dont personally dont like
doing opp handling the way it is done currently, but dont want to mess around
with the current implementation.
arch/arm/mach-omap2/dspbridge.c | 59 ++-
1 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
index 26b860f..120d8a2 100644
--- a/arch/arm/mach-omap2/dspbridge.c
+++ b/arch/arm/mach-omap2/dspbridge.c
@@ -42,7 +42,64 @@ static struct dspbridge_platform_data dspbridge_pdata
__initdata = {
static int get_opp_table(struct dspbridge_platform_data *pdata)
{
#ifdef CONFIG_BRIDGE_DVFS
- /* Do nothing now - fill based on PM implementation */
+ /* legacy values for 3430 */
+ u32 vdd1_dsp_freq[6][4] = {
+ {0, 0, 0, 0},
+ /*OPP1*/
+ {0, 9, 0, 86000},
+ /*OPP2*/
+ {0, 18, 8, 17},
+ /*OPP3*/
+ {0, 36, 16, 34},
+ /*OPP4*/
+ {0, 396000, 325000, 376000},
+ /*OPP5*/
+ {0, 43, 355000, 43},
+ };
+ struct omap_opp vdd1_rate_table_bridge[] = {
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0},
+ };
+ pdata-dsp_num_speeds = VDD1_OPP5;
+ pdata-mpu_speeds = kzalloc(sizeof(u32) * pdata-dsp_num_speeds,
+ GFP_KERNEL);
+ if (!pdata-mpu_speeds) {
+ pr_err(unable to allocate memory for the mpu
+ frequencies\n);
+ return -ENOMEM;
+ }
+ pdata-dsp_freq_table = kzalloc(
+ sizeof(struct dsp_shm_freq_table) *
+ (pdata-dsp_num_speeds + 1), GFP_KERNEL);
+ if (!pdata-dsp_freq_table) {
+ pr_err(unable to allocate memory for the dsp
+ frequencies\n);
+ return -ENOMEM;
+ }
+ for (i = 0; i 6; i++)
+ pdata-mpu_speed[i] = vdd1_rate_table_bridge[i].rate;
+ pdata-mpu_max_speed = pdata-mpu_speed[VDD1_OPP5];
+ pdata-mpu_min_speed = pdata-mpu_speed[VDD1_OPP1];
+ pdata-dsp_num_speeds = VDD1_OPP5;
+ for (i = 0; i = pdata-dsp_num_speeds; i++) {
+ pdata-dsp_freq_table[i].u_volts =
+ vdd1_dsp_freq[i][0];
+ frequency = pdata-dsp_freq_table[i].dsp_freq =
+ frequency = vdd1_dsp_freq[i][1];
+ pdata-dsp_freq_table[i].thresh_min_freq =
+ vdd1_dsp_freq[i][2];
+ pdata-dsp_freq_table[i].thresh_max_freq =
+ vdd1_dsp_freq[i][3];
+ }
#endif
return 0;
}
--
1.6.3.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
[PATCH 1/2] DSPBRIDGE: remove dependency of mpu freq
Current DSPBridge uses hardcoded logic which is not scalable
across OMAP3 silicons. introduce a structure based implementation
this allows for dsp frequency table indices to be generated runtime
instead of being compile time.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/dspbridge.c| 28 +
arch/arm/plat-omap/include/dspbridge/host_os.h | 13 +++-
drivers/dsp/bridge/rmgr/drv_interface.c| 38
drivers/dsp/bridge/rmgr/node.c |4 +-
drivers/dsp/bridge/rmgr/proc.c |4 +-
drivers/dsp/bridge/wmd/io_sm.c | 20
6 files changed, 51 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
index ea109a3..26b860f 100644
--- a/arch/arm/mach-omap2/dspbridge.c
+++ b/arch/arm/mach-omap2/dspbridge.c
@@ -30,6 +30,23 @@ static struct dspbridge_platform_data dspbridge_pdata
__initdata = {
#endif
};
+/**
+ * get_opp_table() - populate the pdata with opp info
+ * @pdata: pointer to pdata
+ *
+ * OPP table implementation is a variant b/w platforms.
+ * the platform file now incorporates this into the build
+ * itself and uses the interface to talk to platform specific
+ * functions
+ */
+static int get_opp_table(struct dspbridge_platform_data *pdata)
+{
+#ifdef CONFIG_BRIDGE_DVFS
+ /* Do nothing now - fill based on PM implementation */
+#endif
+ return 0;
+}
+
static int __init dspbridge_init(void)
{
struct platform_device *pdev;
@@ -48,6 +65,10 @@ static int __init dspbridge_init(void)
if (!pdev)
goto err_out;
+ err = get_opp_table(pdata);
+ if (err)
+ goto err_out;
+
err = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (err)
goto err_out;
@@ -60,6 +81,10 @@ static int __init dspbridge_init(void)
return 0;
err_out:
+ kfree(pdata-mpu_speeds);
+ kfree(pdata-dsp_freq_table);
+ pdata-mpu_speeds = NULL;
+ pdata-dsp_freq_table = NULL;
platform_device_put(pdev);
return err;
}
@@ -67,6 +92,9 @@ module_init(dspbridge_init);
static void __exit dspbridge_exit(void)
{
+ struct dspbridge_platform_data *pdata = dspbridge_pdata;
+ kfree(pdata-mpu_speeds);
+ kfree(pdata-dsp_freq_table);
platform_device_unregister(dspbridge_pdev);
}
module_exit(dspbridge_exit);
diff --git a/arch/arm/plat-omap/include/dspbridge/host_os.h
b/arch/arm/plat-omap/include/dspbridge/host_os.h
index 066c4d7..ebf6a80 100644
--- a/arch/arm/plat-omap/include/dspbridge/host_os.h
+++ b/arch/arm/plat-omap/include/dspbridge/host_os.h
@@ -54,12 +54,23 @@
#define INT_MAIL_MPU_IRQ26
#define INT_DSP_MMU_IRQ28
+struct dsp_shm_freq_table {
+ unsigned long u_volts;
+ unsigned long dsp_freq;
+ unsigned long thresh_min_freq;
+ unsigned long thresh_max_freq;
+};
struct dspbridge_platform_data {
void(*dsp_set_min_opp)(u8 opp_id);
u8 (*dsp_get_opp)(void);
void(*cpu_set_freq)(unsigned long f);
unsigned long (*cpu_get_freq)(void);
- unsigned long mpu_speed[6];
+ unsigned long *mpu_speeds;
+ u8 mpu_num_speeds;
+ unsigned long mpu_min_speed;
+ unsigned long mpu_max_speed;
+ struct dsp_shm_freq_table *dsp_freq_table;
+ u8 dsp_num_speeds;
u32 phys_mempool_base;
u32 phys_mempool_size;
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index d8fe250..9330f44 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -169,44 +169,12 @@ static struct file_operations bridge_fops = {
static u32 timeOut = 1000;
#ifdef CONFIG_BRIDGE_DVFS
static struct clk *clk_handle;
-s32 dsp_max_opps = VDD1_OPP5;
#endif
-/* Maximum Opps that can be requested by IVA*/
-/*vdd1 rate table*/
-#ifdef CONFIG_BRIDGE_DVFS
-const struct omap_opp vdd1_rate_table_bridge[] = {
- {0, 0, 0},
- /*OPP1*/
- {S125M, VDD1_OPP1, 0},
- /*OPP2*/
- {S250M, VDD1_OPP2, 0},
- /*OPP3*/
- {S500M, VDD1_OPP3, 0},
- /*OPP4*/
- {S550M, VDD1_OPP4, 0},
- /*OPP5*/
- {S600M, VDD1_OPP5, 0},
-};
-#endif
#endif
struct dspbridge_platform_data *omap_dspbridge_pdata;
-u32 vdd1_dsp_freq[6][4] = {
- {0, 0, 0, 0},
- /*OPP1*/
- {0, 9, 0, 86000},
- /*OPP2*/
- {0, 18, 8, 17},
- /*OPP3*/
- {0, 36, 16, 34},
- /*OPP4*/
- {0, 396000, 325000, 376000},
- /*OPP5*/
- {0, 43, 355000, 43},
-};
-
#ifdef CONFIG_BRIDGE_DVFS
static
[PATCH] omap: Enable GPMC clock in gpmc_init
Don't assume that gpmc_l3_clk is on, enable it before touching configuration registers. Signed-off-by: Olof Johansson o...@lixom.net diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index e86f5ca..dea72f3 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -534,6 +534,8 @@ void __init gpmc_init(void) BUG(); } + clk_enable(gpmc_l3_clk); + l = gpmc_read_reg(GPMC_REVISION); printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f); /* Set smart idle mode and automatic L3 clock gating */ -- 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 0/3] DSPBRIDGE: Return right error codes
From: Ramirez Luna, Omar on Tuesday, January 19, 2010 12:15 PM This set of patches fixes the overwritten or missing error codes returned from different bridge layers. Fernando Guzman Lugo (3): DSPBRIDGE: return right error codes wmd directory DSPBRIDGE: return right error codes services directory DSPBRIDGE: return right error codes rmgr directory drivers/dsp/bridge/rmgr/dbdcd.c | 31 ++-- drivers/dsp/bridge/rmgr/disp.c | 36 ++-- drivers/dsp/bridge/rmgr/drv.c | 89 + drivers/dsp/bridge/rmgr/dspdrv.c| 27 ++-- drivers/dsp/bridge/rmgr/mgr.c | 23 +-- drivers/dsp/bridge/rmgr/nldr.c | 32 +-- drivers/dsp/bridge/rmgr/node.c | 123 ++-- drivers/dsp/bridge/rmgr/proc.c | 100 -- drivers/dsp/bridge/rmgr/strm.c | 31 +-- drivers/dsp/bridge/services/cfg.c |8 +- drivers/dsp/bridge/services/clk.c |7 +- drivers/dsp/bridge/services/reg.c | 25 +-- drivers/dsp/bridge/services/sync.c |1 - drivers/dsp/bridge/wmd/chnl_sm.c| 230 +++ drivers/dsp/bridge/wmd/io_sm.c | 322 ++- drivers/dsp/bridge/wmd/mmu_fault.c |4 +- drivers/dsp/bridge/wmd/msg_sm.c | 47 +++-- drivers/dsp/bridge/wmd/tiomap3430.c | 28 +-- drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 10 +- drivers/dsp/bridge/wmd/tiomap_io.c | 10 +- drivers/dsp/bridge/wmd/tiomap_sm.c |2 - drivers/dsp/bridge/wmd/ue_deh.c | 21 +-- 22 files changed, 542 insertions(+), 665 deletions(-) Pushed to dspbridge - 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: [PATCH 0/6] DSPBRIDGE: fixes from current patch queue
From: Ramirez Luna, Omar on Tuesday, January 19, 2010 2:54 PM Fixes and cleanups accumulated due to baseline sync. This set should be applied after Return right error codes patch set. Fernando Guzman Lugo (4): DSPBRIDGE: remove NLDR_Free wrapper function DSPBRIDGE: Optimize remove resource functions DSPBRIDGE: remove wrong comment from RequestBridgeResources DSPBRIDGE: Always print DSP traces Omar Ramirez Luna (2): DSPBRIDGE: Rename DEBUG define to use menuconfig style DSPBRIDGE: Remove unused variables from resource cleanup arch/arm/plat-omap/include/dspbridge/dbg.h |4 +- arch/arm/plat-omap/include/dspbridge/nldr.h|1 - arch/arm/plat-omap/include/dspbridge/nldrdefs.h|1 - .../plat-omap/include/dspbridge/resourcecleanup.h |3 +- drivers/dsp/bridge/Makefile|2 +- drivers/dsp/bridge/gen/_gt_para.c |2 +- drivers/dsp/bridge/gen/gt.c|2 +- drivers/dsp/bridge/rmgr/drv.c | 98 drivers/dsp/bridge/rmgr/drv_interface.c|4 +- drivers/dsp/bridge/rmgr/nldr.c | 19 +--- drivers/dsp/bridge/rmgr/node.c | 13 +-- drivers/dsp/bridge/rmgr/proc.c | 18 ++-- drivers/dsp/bridge/rmgr/strm.c |4 +- drivers/dsp/bridge/services/cfg.c | 14 ++-- drivers/dsp/bridge/services/dbg.c |4 +- drivers/dsp/bridge/services/mem.c |2 +- drivers/dsp/bridge/wmd/io_sm.c | 10 +- 17 files changed, 82 insertions(+), 119 deletions(-) Pushed to dspbridge - 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: [PATCH] DSPBRIDGE: replace init_timer with init_timer_on_stack
From: Ameya Palande on Wednesday, January 20, 2010 3:55 AM
On Wed, 2010-01-20 at 01:45 +0100, ext Nishanth Menon wrote:
With LOCK_DEP enabled and DEBUG_OBJECTS_TIMERS, DSPBridge
SYNC_WaitOnMultipleEvents will fail with message
ODEBUG: object is on stack, but not annotated
since the timeout timer is on the stack, we should rightly use
init_timer_on_stack.
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/services/sync.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/services/sync.c
b/drivers/dsp/bridge/services/sync.c
index c2d79c7..d246656 100644
--- a/drivers/dsp/bridge/services/sync.c
+++ b/drivers/dsp/bridge/services/sync.c
@@ -330,7 +330,7 @@ DSP_STATUS SYNC_WaitOnMultipleEvents(struct SYNC_OBJECT
**hSyncEvents,
if (Wp-state != wo_signalled dwTimeout 0) {
struct timer_list timeout;
if (dwTimeout != SYNC_INFINITE) {
-init_timer(timeout);
+init_timer_on_stack(timeout);
timeout.function = timeout_callback;
timeout.data = (unsigned long)Wp;
timeout.expires = jiffies + dwTimeout * HZ / 1000;
Acked-by: Ameya Palande ameya.pala...@nokia.com
Pushed to dspbridge
- 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: [PATCH 1/4] omap: Clean the serial port defines
Hi,
* Pandita, Vikram vikram.pand...@ti.com [100118 16:37]:
snip
Is it possible to use the same approach as mach-omap2/ for physical address
assignments?
I like that approach.
Refer this part from mach-omap2:
+ serial_platform_data0[0].mapbase = omap2_globals-uart1_phys;
+ serial_platform_data1[0].mapbase = omap2_globals-uart2_phys;
+ serial_platform_data2[0].mapbase = omap2_globals-uart3_phys;
.irq= INT_UART1,
.flags = UPF_BOOT_AUTOCONF,
.iotype = UPIO_MEM,
It would be possible if we had omap1_globals. But we don't have it as
the address space is so similar across all omap1 processors.
.macro busyuart,rd,rx
-1001: ldrb\rd, [\rx, #(0x5 2)] @ OMAP-1510 and friends
-and \rd, \rd, #0x60
-teq \rd, #0x60
-beq 1002f
-ldrb\rd, [\rx, #(0x5 0)] @ OMAP-730 only
-and \rd, \rd, #0x60
-teq \rd, #0x60
+1001: ldrb\rd, [\rx, #(UART_LSR OMAP_PORT_SHIFT)]
Zoom2/3 kind of boards have external debug Serial port.
For those boards and maybe others, the shift value is 1 and not
OMAP_PORT_SHIFT(2).
OK, thanks for pointing that out. Let's add the shift as a variable
in debug-macro.S, see the next patch in the series.
This solution is not extensible to zoom2/3 boards with external debug board
uarts.
How do we address that?
It should be doable, we need to initialize zoom external uart physical
and virtual address in uncompress.h, and also initialize the shift for
it.
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
snip
@@ -269,11 +278,15 @@ static struct omap_globals omap343x_globals = {
.ctrl = OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE),
.prm= OMAP2_L4_IO_ADDRESS(OMAP3430_PRM_BASE),
.cm = OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE),
+.uart1_phys = OMAP3_UART1_BASE,
+.uart2_phys = OMAP3_UART2_BASE,
+.uart3_phys = OMAP3_UART3_BASE,
OMAP3630 also has 4 UARTS and this same global is getting used for both 34xx
and 36xx.
This is not right.
For 3630 uart4_phys = 0x49042000
OK, updated.
+#define OMAP3_UART1_BASE0x4806a000
+#define OMAP3_UART2_BASE0x4806c000
+#define OMAP3_UART3_BASE0x4902
Need to add 0x4904 2000 for 3630 UART4
OK, added now. Care to look and ack the attached updated patch?
Regards,
Tony
From ecfb8e2561eb91a76797fdf38204bfa70f1d062b Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 20 Jan 2010 14:11:59 -0800
Subject: [PATCH] omap: Clean the serial port defines
This way we don't have conflicts with the defines
with compiling in multiple omaps. Set the addresses
for uarts in struct omap_globals for the early serial
init code.
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/include/mach/debug-macro.S b/arch/arm/mach-omap1/include/mach/debug-macro.S
index aedb746..23e4724 100644
--- a/arch/arm/mach-omap1/include/mach/debug-macro.S
+++ b/arch/arm/mach-omap1/include/mach/debug-macro.S
@@ -11,6 +11,10 @@
*
*/
+#include linux/serial_reg.h
+
+#include plat/serial.h
+
.macro addruart,rx
mrc p15, 0, \rx, c1, c0
tst \rx, #1 @ MMU enabled?
@@ -30,13 +34,13 @@
.endm
.macro busyuart,rd,rx
-1001: ldrb \rd, [\rx, #(0x5 2)] @ OMAP-1510 and friends
- and \rd, \rd, #0x60
- teq \rd, #0x60
+1001: ldrb \rd, [\rx, #(UART_LSR OMAP_PORT_SHIFT)]
+ and \rd, \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
+ teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
beq 1002f
- ldrb \rd, [\rx, #(0x5 0)] @ OMAP-730 only
- and \rd, \rd, #0x60
- teq \rd, #0x60
+ ldrb \rd, [\rx, #(UART_LSR OMAP7XX_PORT_SHIFT)]
+ and \rd, \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
+ teq \rd, #(UART_LSR_TEMT | UART_LSR_THRE)
bne 1001b
1002:
.endm
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 6e5207c..349de90 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -64,7 +64,7 @@ static void __init omap_serial_reset(struct plat_serial8250_port *p)
static struct plat_serial8250_port serial_platform_data[] = {
{
- .mapbase = OMAP_UART1_BASE,
+ .mapbase = OMAP1_UART1_BASE,
.irq = INT_UART1,
.flags = UPF_BOOT_AUTOCONF,
.iotype = UPIO_MEM,
@@ -72,7 +72,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
.uartclk = OMAP16XX_BASE_BAUD * 16,
},
{
- .mapbase = OMAP_UART2_BASE,
+ .mapbase = OMAP1_UART2_BASE,
.irq = INT_UART2,
.flags = UPF_BOOT_AUTOCONF,
.iotype = UPIO_MEM,
@@ -80,7 +80,7 @@ static struct plat_serial8250_port serial_platform_data[] = {
.uartclk = OMAP16XX_BASE_BAUD * 16,
},
{
- .mapbase = OMAP_UART3_BASE,
+ .mapbase = OMAP1_UART3_BASE,
.irq = INT_UART3,
.flags = UPF_BOOT_AUTOCONF,
.iotype = UPIO_MEM,
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc
-Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Saturday, January 16, 2010 7:33 PM To: Tony Lindgren Cc: Adrian Hunter; Madhusudhan Chikkature; Paul Walmsley; linux-omap Mailing List; linux-mmc Mailing List; Andrew Morton Subject: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc From a65fae702aa81d4596d6fbefd2ab3c8ea87c244a Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Sun, 17 Jan 2010 02:34:22 +0200 Subject: [PATCH] omap: Rename mmc-twl4030 files to hsmmc mmc-twl4030.[ch] no longer has any dependency on twl4030 and should be renamed to reflect that. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com --- arch/arm/mach-omap2/Makefile | 28 ++-- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |2 +- arch/arm/mach-omap2/hsmmc.c | 247 ++ arch/arm/mach-omap2/hsmmc.h | 34 arch/arm/mach-omap2/mmc-twl4030.c| 247 - - arch/arm/mach-omap2/mmc-twl4030.h| 34 17 files changed, 307 insertions(+), 307 deletions(-) create mode 100644 arch/arm/mach-omap2/hsmmc.c create mode 100644 arch/arm/mach-omap2/hsmmc.h delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b32678b..a7e4c5a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -71,42 +71,42 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \ board-rx51-sdram.o \ board-rx51-peripherals.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_ZOOM2)+= board-zoom2.o \ board-zoom-peripherals.o \ -mmc-twl4030.o \ +hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3)+= board-zoom3.o \ board-zoom-peripherals.o \ -mmc-twl4030.o \ +hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \ board-zoom-peripherals.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_CM_T35)+= board-cm-t35.o \ -mmc-twl4030.o +
RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Madhusudhan Sent: Wednesday, January 20, 2010 5:42 PM To: 'Adrian Hunter'; 'Tony Lindgren' Cc: 'Paul Walmsley'; 'linux-omap Mailing List'; 'linux-mmc Mailing List'; 'Andrew Morton' Subject: RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc -Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Saturday, January 16, 2010 7:33 PM To: Tony Lindgren Cc: Adrian Hunter; Madhusudhan Chikkature; Paul Walmsley; linux-omap Mailing List; linux-mmc Mailing List; Andrew Morton Subject: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc From a65fae702aa81d4596d6fbefd2ab3c8ea87c244a Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Sun, 17 Jan 2010 02:34:22 +0200 Subject: [PATCH] omap: Rename mmc-twl4030 files to hsmmc mmc-twl4030.[ch] no longer has any dependency on twl4030 and should be renamed to reflect that. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com --- arch/arm/mach-omap2/Makefile | 28 ++-- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |2 +- arch/arm/mach-omap2/hsmmc.c | 247 ++ arch/arm/mach-omap2/hsmmc.h | 34 arch/arm/mach-omap2/mmc-twl4030.c| 247 --- -- - arch/arm/mach-omap2/mmc-twl4030.h| 34 17 files changed, 307 insertions(+), 307 deletions(-) create mode 100644 arch/arm/mach-omap2/hsmmc.c create mode 100644 arch/arm/mach-omap2/hsmmc.h delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b32678b..a7e4c5a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -71,42 +71,42 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ board-rx51-sdram.o \ board-rx51-peripherals.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \ board-zoom-peripherals.o \ - mmc-twl4030.o \ + hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \ board-zoom-peripherals.o \ - mmc-twl4030.o \ + hsmmc.o \
[ANNOUNCE] rebased dspbridge-pm on top of dspbridge
Hi All, dspbridge-pm branch was rebased on top of latest dspbridge, so please update your local branches. As a reminder: dspbridge is based on top of 2.6.32 LO dspbridge-pm is based on top of pm-2.6.32 LO-pm 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: [PATCH] omap: Enable GPMC clock in gpmc_init
* Olof Johansson o...@lixom.net [100120 14:36]: Don't assume that gpmc_l3_clk is on, enable it before touching configuration registers. Seems like this is OK to do even though we do not disable it anywhere currently since we're setting smart idle and L3 autogating also in gpmc_init. So adding to omap-fixes. Regards, Tony Signed-off-by: Olof Johansson o...@lixom.net diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index e86f5ca..dea72f3 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -534,6 +534,8 @@ void __init gpmc_init(void) BUG(); } + clk_enable(gpmc_l3_clk); + l = gpmc_read_reg(GPMC_REVISION); printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f); /* Set smart idle mode and automatic L3 clock gating */ -- 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
[APPLIED] [PATCH] omap: Enable GPMC clock in gpmc_init
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): adbf7434abf0c710a5253438fd7a7d12db26272a PatchWorks http://patchwork.kernel.org/patch/74138/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=adbf7434abf0c710a5253438fd7a7d12db26272a -- 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: Enable GPMC clock in gpmc_init
Hello Olof,
On Wed, 20 Jan 2010, Olof Johansson wrote:
Don't assume that gpmc_l3_clk is on, enable it before touching
configuration registers.
Signed-off-by: Olof Johansson o...@lixom.net
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index e86f5ca..dea72f3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -534,6 +534,8 @@ void __init gpmc_init(void)
BUG();
}
+ clk_enable(gpmc_l3_clk);
+
l = gpmc_read_reg(GPMC_REVISION);
printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f);
/* Set smart idle mode and automatic L3 clock gating */
Care to try an approach similar to the following? Compile-tested, but
otherwise untested.
- Paul
From 93bef5c90eed5247cfeada601beacdc734891924 Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Wed, 20 Jan 2010 18:16:18 -0700
Subject: [PATCH] OMAP GPMC: add fine-grained clock control
OMAP4 GPMC has a software-controllable GPMC clock gate, so, take
advantage of it by only enabling the GPMC clock when needed. Since
OMAP2xxx/3 don't have a separate software-controllable GPMC clock,
this change should not affect these platforms, aside from slowing some
of the gpmc.c functions down slightly.
Also rename gpmc_l3_clk to the more generic gpmc_clk.
Since the GPMC clock is now enabled and disabled on demand, the
ENABLE_ON_INIT clock flag can be removed from the GPMC clocks; do so.
While here, add some to-do items to the initial comment block.
Finally, add a gpmc_ocp_barrier() function, intended to ensure that
all register writes to the GPMC are complete before disabling the GPMC
clock. Barriers are added where they appear to be needed.
---
arch/arm/mach-omap2/clock2xxx_data.c |1 -
arch/arm/mach-omap2/clock34xx_data.c |1 -
arch/arm/mach-omap2/gpmc.c | 92 --
3 files changed, 76 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2xxx_data.c
b/arch/arm/mach-omap2/clock2xxx_data.c
index 97dc7cf..0997104 100644
--- a/arch/arm/mach-omap2/clock2xxx_data.c
+++ b/arch/arm/mach-omap2/clock2xxx_data.c
@@ -1804,7 +1804,6 @@ static struct clk gpmc_fck = {
.name = gpmc_fck,
.ops= clkops_null, /* RMK: missing? */
.parent = core_l3_ck,
- .flags = ENABLE_ON_INIT,
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
};
diff --git a/arch/arm/mach-omap2/clock34xx_data.c
b/arch/arm/mach-omap2/clock34xx_data.c
index c6031d7..fab9e5b 100644
--- a/arch/arm/mach-omap2/clock34xx_data.c
+++ b/arch/arm/mach-omap2/clock34xx_data.c
@@ -1654,7 +1654,6 @@ static struct clk gpmc_fck = {
.name = gpmc_fck,
.ops= clkops_null,
.parent = core_l3_ick,
- .flags = ENABLE_ON_INIT, /* huh? */
.clkdm_name = core_l3_clkdm,
.recalc = followparent_recalc,
};
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 3f1334f..3ccd1d5 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1,7 +1,7 @@
/*
* GPMC support functions
*
- * Copyright (C) 2005-2006 Nokia Corporation
+ * Copyright (C) 2005-2006, 2010 Nokia Corporation
*
* Author: Juha Yrjola
*
@@ -11,6 +11,20 @@
* 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.
+ *
+ * XXX Convert this to an early platform driver or something similar
+ *
+ * XXX This code is missing support for some of the OMAP3 GPMC features,
+ * such as CYCLE2CYCLESAMECSEN, CYCLE2CYCLEDIFFCSEN, CYCLE2CYCLEDELAY,
+ * BUSTURNAROUND, etc.
+ *
+ * XXX It's insufficient for the GPMC timing setup code to only take
+ * into account the target chip timing parameters - it must also take
+ * into consideration board timing parameters. For example, bus level
+ * translators between the OMAP and the target chip can introduce
+ * latency that can affect timings. In some extreme cases, PCB
+ * transmission line effects (e.g., rise time, fall time) may also
+ * need to be taken into account.
*/
#undef DEBUG
@@ -96,7 +110,7 @@ static unsigned gpmc_cs_map;
static void __iomem *gpmc_base;
-static struct clk *gpmc_l3_clk;
+static struct clk *gpmc_clk;
static void gpmc_write_reg(int idx, u32 val)
{
@@ -108,6 +122,11 @@ static u32 gpmc_read_reg(int idx)
return __raw_readl(gpmc_base + idx);
}
+static void gpmc_ocp_barrier(void)
+{
+ gpmc_read_reg(GPMC_REVISION);
+}
+
void gpmc_cs_write_reg(int cs, int idx, u32 val)
{
void __iomem *reg_addr;
@@ -124,13 +143,12 @@ u32 gpmc_cs_read_reg(int cs, int idx)
return __raw_readl(reg_addr);
}
-/* TODO: Add support for gpmc_fck to clock framework and use it */
unsigned long gpmc_get_fclk_period(void)
{
- unsigned
Re: [PATCH] omap: Enable GPMC clock in gpmc_init
I forgot to mention, it applies on top of your patch. - 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
[PATCH 5/4] omap: Enable GPMC clock in gpmc_init
Here's one more fix. Tony From 1daa8c1d75876f690ed8d3f13c806034af5984eb Mon Sep 17 00:00:00 2001 From: Olof Johansson o...@lixom.net Date: Wed, 20 Jan 2010 22:39:29 + Subject: [PATCH] omap: Enable GPMC clock in gpmc_init Don't assume that gpmc_l3_clk is on, enable it before touching configuration registers. Note that the current code assumes that this clock is always enabled. We are already setting smart idle and L3 autogating for GPMC clock in gpmc_init. Signed-off-by: Olof Johansson o...@lixom.net Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index bd8cb59..3f1334f 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -534,6 +534,8 @@ void __init gpmc_init(void) BUG(); } + clk_enable(gpmc_l3_clk); + l = gpmc_read_reg(GPMC_REVISION); printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f); /* Set smart idle mode and automatic L3 clock gating */
Omapfb issue
Hello everyone, We are facing an issue with Framebuffer (omapfb) driver while starting Xorg. Currently we are using Devkit8000 and trying to boot Linux with our inhouse rootfs. While booting the X throws an error saying: (EE) omapfb(0): FBIOBLANK: Invalid argument However, X comes up but crashes if we try to launch application which use X. I have attached Xorg log file for your reference. Please let us know if there is a issue with omapfb drivers. We are using Linux 2.6.28-rc9-omap1 (which came with the board). Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p3 video=omapfb:mode:7inch_LCD Your help will be much appreciated. Thanks and regards, Karthick :) Xorg.0.log Description: Xorg.0.log
RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure
Hello Abhijit, On Wed, 20 Jan 2010, Pagare, Abhijit wrote: I think the latest patch-set that I had posted has this change in it. You can refer to the patch in the link below http://marc.info/?l=linux-omapm=126088474831309w=2 Looks like this patch had somehow not made it into the for_2.6.34 branch; this has now been fixed, which resolves the problem. But this part we should discuss further: I had used this flag earlier as there was nothing fixed as to name it as ES1 that time. Yep, I understand. So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case and should be removed. A patch would be essential to take care of that in the places where it is used. If you feel the same I can send a patch for fixing this. In the past, there have been some clock, clockdomain, powerdomain, IP block, etc. changes going from ES1 to ES2 revisions. But most clocks, etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for what stays the same. Until ES2 details are available, this shouldn't require any further changes to the codebase aside from id.c. We don't currently define a rollup macro for CHIP_IS_OMAP3430, but it's planned for 2.6.34 to include all of the individual CHIP_IS_OMAP* bits. We'd do the same thing for OMAP2xxx but most of the 2xxx data in the kernel tree has no ES-level information, so we'll probably leave those as-is. We'll probably add in a Sitara CHIP_IS_* bit in there also. Anyway, there's no need for you to change your patch, now that it's included in the for_2.6.34 branch. But keep in mind that we'll probably post another id.c cleanup patch to change things around as described above, unless you or others have some strong reason not to... - 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] OMAP CPU ID: fix OMAP4 build failure
Hello Abhijit, On Wed, 20 Jan 2010, Paul Walmsley wrote: So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case and should be removed. A patch would be essential to take care of that in the places where it is used. If you feel the same I can send a patch for fixing this. In the past, there have been some clock, clockdomain, powerdomain, IP block, etc. changes going from ES1 to ES2 revisions. But most clocks, etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for what stays the same. Until ES2 details are available, this shouldn't require any further changes to the codebase aside from id.c. I guess the rollup should probably be CHIP_IS_OMAP44XX. Do you happen to know whether software will be able to discriminate between 4430 and 4440 chips at run-time, and if so, what mechanism to use? - 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
[PATCH] DSPBRIDGE: Fix BUG scheduling while atomic
From: Fernando Guzman Lugo x0095...@ti.com
This patch fixes the BUG schedule/sleep while atomic which
was in the IO_DPC function, this function runs as a tasklet
and called a function that could be scheduled (OPP change).
we use in_interrupt to detect this and handle accordingly
Original Patch by Fernando:
http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commitdiff;h=2dcd1964a138c85b5545f687f96c96b489fe4a00
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Nishanth Menon n...@ti.com
Cc: Omar Ramirez omap.rami...@ti.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Deepak Chitriki deepak.chitr...@ti.com
---
drivers/dsp/bridge/wmd/_tiomap_pwr.h|7 +++
drivers/dsp/bridge/wmd/io_sm.c |2 +-
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 31 +++
drivers/dsp/bridge/wmd/tiomap_sm.c | 13 ++---
4 files changed, 41 insertions(+), 12 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/_tiomap_pwr.h
b/drivers/dsp/bridge/wmd/_tiomap_pwr.h
index da2e7d9..54d7ca4 100644
--- a/drivers/dsp/bridge/wmd/_tiomap_pwr.h
+++ b/drivers/dsp/bridge/wmd/_tiomap_pwr.h
@@ -89,5 +89,12 @@ DSP_STATUS DSP_PeripheralClocks_Enable(struct
WMD_DEV_CONTEXT *pDevContext,
*/
void DSPClkWakeupEventCtrl(u32 ClkId, bool enable);
+/**
+ * tiomap3430_bump_dsp_opp_level() - bump up opp if required
+ *
+ * if the system is at a minimum opp, request for higher opp
+ */
+DSP_STATUS tiomap3430_bump_dsp_opp_level(void);
+
#endif /* _TIOMAP_PWR_ */
diff --git a/drivers/dsp/bridge/wmd/io_sm.c b/drivers/dsp/bridge/wmd/io_sm.c
index 79a714a..3481beb 100644
--- a/drivers/dsp/bridge/wmd/io_sm.c
+++ b/drivers/dsp/bridge/wmd/io_sm.c
@@ -1132,7 +1132,7 @@ void IO_Schedule(struct IO_MGR *pIOMgr)
spin_lock_irqsave(pIOMgr-dpc_lock, flags);
pIOMgr-dpc_req++;
spin_unlock_irqrestore(pIOMgr-dpc_lock, flags);
-
+ tiomap3430_bump_dsp_opp_level();
/* Schedule DPC */
tasklet_schedule(pIOMgr-dpc_tasklet);
}
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 94b399f..54cba9f 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -806,3 +806,34 @@ void DSPClkWakeupEventCtrl(u32 ClkId, bool enable)
break;
}
}
+
+/**
+ * tiomap3430_bump_dsp_opp_level() - bump up the opp if at minimum
+ *
+ * if we need a higher opp index, request for the same
+ */
+DSP_STATUS tiomap3430_bump_dsp_opp_level(void)
+{
+#ifndef CONFIG_BRIDGE_DVFS
+ u32 opplevel;
+
+ struct dspbridge_platform_data *pdata =
+ omap_dspbridge_dev-dev.platform_data;
+
+ if (pdata-dsp_get_opp) {
+ opplevel = (*pdata-dsp_get_opp)();
+
+ /*
+* If OPP is at minimum level, increase it before waking
+* up the DSP.
+*/
+ if (opplevel == 1 pdata-dsp_set_min_opp) {
+ (*pdata-dsp_set_min_opp)(opp_level + 1);
+ DBG_Trace(DBG_LEVEL7, CHNLSM_InterruptDSP: Setting
+ the vdd1 constraint level to %d before
+ waking DSP \n, opp_level + 1);
+ }
+ }
+#endif
+ return DSP_SOK;
+}
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index b04ed6d..1d2e5d7 100644
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -96,11 +96,6 @@ DSP_STATUS CHNLSM_DisableInterrupt(struct WMD_DEV_CONTEXT
*pDevContext)
DSP_STATUS CHNLSM_InterruptDSP2(struct WMD_DEV_CONTEXT *pDevContext,
u16 wMbVal)
{
-#ifdef CONFIG_BRIDGE_DVFS
- struct dspbridge_platform_data *pdata =
- omap_dspbridge_dev-dev.platform_data;
- u32 opplevel = 0;
-#endif
struct CFG_HOSTRES resources;
DSP_STATUS status = DSP_SOK;
unsigned long timeout;
@@ -114,12 +109,8 @@ DSP_STATUS CHNLSM_InterruptDSP2(struct WMD_DEV_CONTEXT
*pDevContext,
if (pDevContext-dwBrdState == BRD_DSP_HIBERNATION ||
pDevContext-dwBrdState == BRD_HIBERNATION) {
#ifdef CONFIG_BRIDGE_DVFS
- if (pdata-dsp_get_opp)
- opplevel = (*pdata-dsp_get_opp)();
- if (opplevel == VDD1_OPP1) {
- if (pdata-dsp_set_min_opp)
- (*pdata-dsp_set_min_opp)(VDD1_OPP2);
- }
+ if (!in_interrupt())
+ tiomap3430_bump_dsp_opp_level();
#endif
/* Restart the peripheral clocks */
DSP_PeripheralClocks_Enable(pDevContext, NULL);
--
1.6.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
Re: [PATCHv3 1/6] OMAP: Powerdomains: Add support for INACTIVE state on pwrdm level
Hi Tero,
I regret the delay in reviewing. I haven't kept up on the comments on
this thread, so if I've asked a question that you've already answered,
please feel free to point me to the response.
A few comments/questions:
On Fri, 15 Jan 2010, Tero Kristo wrote:
From: Tero Kristo tero.kri...@nokia.com
Currently only ON, RET and OFF are supported, and ON is arguably broken as it
allows the powerdomain to enter INACTIVE state unless idle is prevented.
Now, pwrdm code prevents idle if ON is selected, and also adds support for
INACTIVE. This simplifies the control needed inside sleep code.
This patch also requires caching of next power state inside powerdomain code,
as INACTIVE is not directly supported by hardware.
The idea seems like a good one, and a simplification for the PM code. I'm
a little worried that this patch mixes hardware-programmable powerdomain
states with logical powerdomain states. I wonder if we would be better
off separating, for example, the logic of putting a powerdomain into
INACTIVE state and any other logical powerdomain management, from the
physical details of how the chip is programmed. Just looking for your
comments on this, not necessarily any changes in your patches in this
regard.
Next powerstate is thus now stored for each powerdomain in next_state.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/powerdomain.c | 32
arch/arm/mach-omap2/powerdomains34xx.h| 26 ++--
arch/arm/plat-omap/include/plat/powerdomain.h |4 +++
3 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 26b3f3e..a08d596 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -110,8 +110,8 @@ static struct powerdomain *_pwrdm_deps_lookup(struct
powerdomain *pwrdm,
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
- int prev;
- int state;
+ u8 prev;
+ u8 state;
if (pwrdm == NULL)
return -EINVAL;
@@ -218,7 +218,9 @@ int pwrdm_register(struct powerdomain *pwrdm)
pr_debug(powerdomain: registered %s\n, pwrdm-name);
ret = 0;
-
+ pwrdm-next_state =
+ prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
+ OMAP_POWERSTATE_MASK);
pr_unlock:
write_unlock_irqrestore(pwrdm_rwlock, flags);
@@ -699,19 +701,38 @@ int pwrdm_get_mem_bank_count(struct powerdomain *pwrdm)
*/
int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
{
+ u8 prg_pwrst;
+
if (!pwrdm)
return -EINVAL;
+ if (pwrdm-next_state == pwrst)
+ return 0;
+
if (!(pwrdm-pwrsts (1 pwrst)))
return -EINVAL;
pr_debug(powerdomain: setting next powerstate for %s to %0x\n,
pwrdm-name, pwrst);
+ /* INACTIVE is reserved, so we program pwrdm as ON */
+ if (pwrst == PWRDM_POWER_INACTIVE)
+ prg_pwrst = PWRDM_POWER_ON;
+ else
+ prg_pwrst = pwrst;
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
- (pwrst OMAP_POWERSTATE_SHIFT),
+ (prg_pwrst OMAP_POWERSTATE_SHIFT),
pwrdm-prcm_offs, PM_PWSTCTRL);
+ /* If next state is ON, prevent idle */
+ if (pwrst == PWRDM_POWER_ON)
+ omap2_clkdm_deny_idle(pwrdm-pwrdm_clkdms[0]);
+ else
+ omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
Looks like this will force clockdomains into hardware-supervised mode,
even if they were originally programmed into software-supervised mode.
Please fix this so clockdomains that were originally programmed into
software-supervised mode aren't inadvertently switched.
+
+ pwrdm-next_state = pwrst;
+
return 0;
}
@@ -728,8 +749,7 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
if (!pwrdm)
return -EINVAL;
- return prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
- OMAP_POWERSTATE_MASK);
+ return pwrdm-next_state;
}
/**
diff --git a/arch/arm/mach-omap2/powerdomains34xx.h
b/arch/arm/mach-omap2/powerdomains34xx.h
index 588f7e0..f50a3f2 100644
--- a/arch/arm/mach-omap2/powerdomains34xx.h
+++ b/arch/arm/mach-omap2/powerdomains34xx.h
@@ -165,7 +165,7 @@ static struct powerdomain iva2_pwrdm = {
.omap_chip= OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
.dep_bit = OMAP3430_PM_WKDEP_MPU_EN_IVA2_SHIFT,
.wkdep_srcs = iva2_wkdeps,
- .pwrsts = PWRSTS_OFF_RET_ON,
+ .pwrsts = PWRSTS_OFF_RET_INA_ON,
.pwrsts_logic_ret = PWRSTS_OFF_RET,
.banks= 4,
.pwrsts_mem_ret = {
@@ -188,7 +188,7 @@ static struct powerdomain mpu_34xx_pwrdm = {
Re: [PATCH 05/10] OMAP clockdomains: add usecounting for wakeup and sleep dependencies
Hi,
Kevin identified two bugs in this patch (and the one that immediately
followed it) during PM branch testing. These bugs, and the fixes
implemented for them, are described below in the revised patch. In the
process of fixing it, this patch and the next one were combined.
This patch has taken the place of the previously-posted 05/10 and 06/10
patches in the for_2.6.34 branch.
regards,
- Paul
From: Paul Walmsley p...@pwsan.com
Subject: [PATCH] OMAP clockdomains: add usecounting for wakeup and sleep
dependencies
Add usecounting for wakeup and sleep dependencies. In the current
situation, if several functions add dependencies on the same
clockdomains, when the first dependency removal function is called,
the dependency will be incorrectly removed from the hardware.
Add clkdm_clear_all_wkdeps() and clkdm_clear_all_sleepdeps(), which
provide a fast and usecounting-consistent way to clear all hardware
clockdomain dependencies, since accesses to these registers can be
quite slow. pm{2,3}4xx.c has been updated to use these new functions.
The original version of this patch did not touch these files, which
previously wrote directly to the wkdep registers, and thus confused
the usecounting code. This problem was found by Kevin Hilman
khil...@deeprootsystems.com.
N.B.: This patch introduces one significant functional difference over
the previous pm34xx.c code: sleepdeps are now cleared during
clockdomain initialization, whereas previously they were left
untouched. This has been tested by Kevin and confirmed to work.
The original version of this patch also did not take into
consideration that some clockdomains do not have sleep or wakeup
dependency sources, which caused NULL pointer dereferences. This
problem was debugged and fixed by Kevin Hilman
khil...@deeprootsystems.com.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Cc: Jouni Högander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/clockdomain.c | 216 ++---
arch/arm/mach-omap2/pm24xx.c | 49 ---
arch/arm/mach-omap2/pm34xx.c |3 +
arch/arm/plat-omap/include/plat/clockdomain.h |8 +
4 files changed, 237 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 2af9996..6eaa931 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -113,7 +113,6 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
return ERR_PTR(-EINVAL);
for (cd = deps; cd-clkdm_name; cd++) {
-
if (!omap_chip_is(cd-omap_chip))
continue;
@@ -122,7 +121,6 @@ static struct clkdm_dep *_clkdm_deps_lookup(struct
clockdomain *clkdm,
if (cd-clkdm == clkdm)
break;
-
}
if (!cd-clkdm_name)
@@ -254,6 +252,96 @@ static void _omap2_clkdm_set_hwsup(struct clockdomain
*clkdm, int enable)
}
+/**
+ * _init_wkdep_usecount - initialize wkdep usecounts to match hardware
+ * @clkdm: clockdomain to initialize wkdep usecounts
+ *
+ * Initialize the wakeup dependency usecount variables for clockdomain @clkdm.
+ * If a wakeup dependency is present in the hardware, the usecount will be
+ * set to 1; otherwise, it will be set to 0. Software should clear all
+ * software wakeup dependencies prior to calling this function if it wishes
+ * to ensure that all usecounts start at 0. No return value.
+ */
+static void _init_wkdep_usecount(struct clockdomain *clkdm)
+{
+ u32 v;
+ struct clkdm_dep *cd;
+
+ if (!clkdm-wkdep_srcs)
+ return;
+
+ for (cd = clkdm-wkdep_srcs; cd-clkdm_name; cd++) {
+ if (!omap_chip_is(cd-omap_chip))
+ continue;
+
+ if (!cd-clkdm cd-clkdm_name)
+ cd-clkdm = _clkdm_lookup(cd-clkdm_name);
+
+ if (!cd-clkdm) {
+ WARN(!cd-clkdm, clockdomain: %s: wkdep clkdm %s not
+found\n, clkdm-name, cd-clkdm_name);
+ continue;
+ }
+
+ v = prm_read_mod_bits_shift(clkdm-pwrdm.ptr-prcm_offs,
+ PM_WKDEP,
+ (1 cd-clkdm-dep_bit));
+
+ if (v)
+ pr_debug(clockdomain: %s: wakeup dependency already
+set to wake up when %s wakes\n,
+clkdm-name, cd-clkdm-name);
+
+ atomic_set(cd-wkdep_usecount, (v) ? 1 : 0);
+ }
+}
+
+/**
+ * _init_sleepdep_usecount - initialize sleepdep usecounts to match hardware
+ * @clkdm: clockdomain to initialize sleepdep usecounts
+ *
+ * Initialize the sleep dependency usecount variables for clockdomain @clkdm.
+ * If a sleep dependency is present in the hardware, the usecount
RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Thursday, January 21, 2010 8:57 AM To: Pagare, Abhijit Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure Hello Abhijit, On Wed, 20 Jan 2010, Paul Walmsley wrote: So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case and should be removed. A patch would be essential to take care of that in the places where it is used. If you feel the same I can send a patch for fixing this. In the past, there have been some clock, clockdomain, powerdomain, IP block, etc. changes going from ES1 to ES2 revisions. But most clocks, etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for what stays the same. Until ES2 details are available, this shouldn't require any further changes to the codebase aside from id.c. I guess the rollup should probably be CHIP_IS_OMAP44XX. Do you happen to know whether software will be able to discriminate between 4430 and 4440 chips at run-time, and if so, what mechanism to use? ID_CODE would be different which can be used for this. -- 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 CPU ID: fix OMAP4 build failure
On Thu, 21 Jan 2010, Shilimkar, Santosh wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul Walmsley I guess the rollup should probably be CHIP_IS_OMAP44XX. Do you happen to know whether software will be able to discriminate between 4430 and 4440 chips at run-time, and if so, what mechanism to use? ID_CODE would be different which can be used for this. Okay, great. - 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 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Wednesday, January 20, 2010 11:05 PM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off. Hi Thara, two comments: On Wed, 20 Jan 2010, Thara Gopinath wrote: DPLL4 autoidle is controlled through the register CM_PLL_AUTOIDLE which is to be restored by rom code from the scratchpad in case of a core domain context loss. But enabling this bit in scratchpad causes rom code to take an extra 20 ms delay in the restore path. To avoid this delay this bit is not enabled in the scratchpad today. This means after a core off happens DPLL4 autoidle is never again enabled back. This patch enables DPLL4 autoidle in case of core domain losing context. Shouldn't this be contingent on whether DPLL4 autoidle was enabled before the CORE off transition? Hi Paul, Hmmm may be yes.. But you see today we enable all autoidle bits in the init. Why I had to make this unconditional is because later before core entering OSWR I explicitly disable this bit in the register. This is so as to match this register content with those of scratchpad during OSWR. Failing to do this rom code while exiting OSWR will take the path it takes while coming out of core off . This causes a crash in the system today. Also another reason is omap3_prcm_save_context needs to be called only during core off today. If I move saving of this bit and restoring it back into omap3_prcm_save_context and omap3_prcm_restore_context I will have to call it during core OSWR also. Wanted to avoid the extra complications. But if this approach is not ok, I can modify the save restore APIs to take power state as a parameter and do only dpll4 autoidle save and restore in case of OSWR. Is this ok? Signed-off-by: Thara Gopinath th...@ti.com --- arch/arm/mach-omap2/pm34xx.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index e4db1ea..6e6d954 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -520,6 +520,14 @@ void omap_sram_idle(void) */ if (cpu_is_omap3430()) usb_musb_disable_autoidle(); + /* We do not program the scratchpad to restore back +* PER DPLL in autoidle due to 20 ms delay in +* rom code restore path. So enable it explicitly +* after core off +*/ This multi-line comment needs to be fixed to conform to Documentation/CodingStyle. Oops.. My bad. Will fix and resend the patch. Don't know why checkpatch is not catching this. I will wait a couple of days for comments on other patches also and resend all of them after fixing the relevant comments. + cm_rmw_mod_reg_bits( + 0x0, (1 OMAP3430_AUTO_PERIPH_DPLL_SHIFT), + PLL_MOD, CM_AUTOIDLE); } omap_uart_resume_idle(0); omap_uart_resume_idle(1); -- 1.5.6.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 - 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] OMAP3: PM: Dynamic calculation of SDRC clock stabilization delay
Hi Teerth, any update on Kevin's comments? This patch shouldn't use a hardcoded value. Please explain further why that formula can't be included... - Paul On Wed, 6 Jan 2010, Kevin Hilman wrote: Reddy, Teerth tee...@ti.com writes: From e5e82efbf6f736984668cc5e94d62635ed4de05e Mon Sep 17 00:00:00 2001 From: Teerth Reddy tee...@ti.com Date: Wed, 23 Dec 2009 18:40:34 +0530 Subject: [PATCH] Dynamic Calculation of SDRC clock stabilization delay Subject prefix should probably be 'OMAP3: SDRC:'. The patch has the changes to calculate the dpll3 clock stabilization delay dynamically. The SRAM delay is calibrated during bootup using the gptimers and used while calculating the stabilization delay. Thanks for the update using the GPtimer. I think this simplifies things quite a bit in terms of upstream code, however there are a couple of new snags. More below... By using the dynamic method the dependency on the type of cache being used is removed. Hence there is no need of loop based calculation. TO DO: However the value of 6us for SDRC to stabilize has been hardcoded currently. The formula used to calculate this value gives a very small number thus causing instability. The right formula will be used which will work across all boards. Can you explain which platforms the hard-coded value should work for and how that value was determined? Also, should we be expecting another patch for this 'TO DO' part. To me this is a problem that prevents merging this patch. Signed-off-by: Teerth Reddy tee...@ti.com Signed-off-by: Romit Dasgupta ro...@ti.com --- arch/arm/mach-omap2/clock34xx.c| 21 +-- arch/arm/mach-omap2/clock34xx.h|2 + arch/arm/mach-omap2/clock34xx_data.c |4 +++ arch/arm/mach-omap2/sram34xx.S | 25 ++ arch/arm/plat-omap/include/plat/sram.h |5 +++ arch/arm/plat-omap/sram.c | 43 6 files changed, 91 insertions(+), 9 deletions(-) diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c index d9329e2..6d87419 100644 --- a/arch/arm/mach-omap2/clock34xx.c +++ b/arch/arm/mach-omap2/clock34xx.c @@ -56,9 +56,18 @@ */ #define DPLL5_FREQ_FOR_USBHOST 12000 +/* + * SDRC_TIME_STABILIZE: Time for SDRC to stabilize in us + * TO DO: Use formula to calculate across all platforms + */ +#defineSDRC_TIME_STABILIZE 6 + /* needed by omap3_core_dpll_m2_set_rate() */ struct clk *sdrc_ick_p, *arm_fck_p; +/* SRAM delay required for sdrc clk stab delay calculation */ +unsigned int delay_sram; + Please get rid of the global variable and get the delay value by calling a function that returns the value. Also, please be sure to do this with SMP in mind. /** * omap3430es2_clk_ssi_find_idlest - return CM_IDLEST info for SSI * @clk: struct clk * being enabled @@ -215,16 +224,10 @@ int omap3_core_dpll_m2_set_rate(struct clk *clk, unsigned long rate) unlock_dll = 1; } - /* -* XXX This only needs to be done when the CPU frequency changes -*/ + /* Calculate the number of MPU cycles to wait for SDRC to stabilize */ + _mpurate = arm_fck_p-rate / CYCLES_PER_MHZ; - c = (_mpurate SDRC_MPURATE_SCALE) SDRC_MPURATE_BASE_SHIFT; - c += 1; /* for safety */ - c *= SDRC_MPURATE_LOOPS; - c = SDRC_MPURATE_SCALE; - if (c == 0) - c = 1; + c = ((SDRC_TIME_STABILIZE * _mpurate) / (delay_sram * 2)); pr_debug(clock: changing CORE DPLL rate from %lu to %lu\n, clk-rate, validrate); diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h index 9a2c07e..1bc5044 100644 --- a/arch/arm/mach-omap2/clock34xx.h +++ b/arch/arm/mach-omap2/clock34xx.h @@ -21,4 +21,6 @@ extern const struct clkops clkops_omap3430es2_hsotgusb_wait; extern const struct clkops clkops_omap3430es2_dss_usbhost_wait; extern const struct clkops clkops_noncore_dpll_ops; +extern unsigned int delay_sram; + #endif diff --git a/arch/arm/mach-omap2/clock34xx_data.c b/arch/arm/mach-omap2/clock34xx_data.c index 8bdcc9c..e5d0941 100644 --- a/arch/arm/mach-omap2/clock34xx_data.c +++ b/arch/arm/mach-omap2/clock34xx_data.c @@ -22,6 +22,7 @@ #include plat/control.h #include plat/clkdev_omap.h +#include plat/sram.h #include clock.h #include clock34xx.h @@ -3285,5 +3286,8 @@ int __init omap2_clk_init(void) sdrc_ick_p = clk_get(NULL, sdrc_ick); arm_fck_p = clk_get(NULL, arm_fck); + /* Measure sram delay */ + delay_sram = measure_sram_delay(1); + pr_debug(SRAM delay: %d\n, delay_sram); return 0; } diff --git a/arch/arm/mach-omap2/sram34xx.S b/arch/arm/mach-omap2/sram34xx.S index de99ba2..b4fba50 100644 --- a/arch/arm/mach-omap2/sram34xx.S
[PATCH 1/2] DSPBRIDGE: improve constraint_value handling
currently pConstraint value is a pointer which is dereferenced
twice(when debug is enabled) to get to the opp index. instead
dereference it correctly once. since the meaning of the variable
changes, rename it as opp_idx
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 084f406..5dfbef8 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -66,18 +66,20 @@ DSP_STATUS handle_constraints_set(struct WMD_DEV_CONTEXT
*pDevContext,
IN void *pArgs)
{
#ifdef CONFIG_BRIDGE_DVFS
- u32 *pConstraintVal;
+ u32 opp_idx;
struct dspbridge_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
- pConstraintVal = (u32 *)(pArgs);
+ /* pick up the opp index */
+ opp_idx = *(((u32 *)(pArgs)) + 1);
+
/* Read the target value requested by DSP */
DBG_Trace(DBG_LEVEL7, handle_constraints_set:
- opp requested = 0x%x\n, (u32)*(pConstraintVal+1));
+ opp requested = 0x%x\n, opp_idx);
/* Set the new opp value */
if (pdata-dsp_set_min_opp)
- (*pdata-dsp_set_min_opp)((u32)*(pConstraintVal+1));
+ (*pdata-dsp_set_min_opp)(opp_idx);
#endif /* #ifdef CONFIG_BRIDGE_DVFS */
return DSP_SOK;
}
--
1.6.3.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
[PATCH 2/2] DSPBRIDGE: sanitize opp_idx before passing to PM
DSP is not supposed to return bad opp_indices which are not part of
the opp table we created for it. If it does, throw an error, and
refuse to switch the OPP.
Ref: discussion: http://marc.info/?t=12639519602r=1w=2
Depends on: http://marc.info/?l=linux-omapm=126402596424801w=2
Cc: Ameya Palande ameya.pala...@nokia.com
Cc: Deepak Chitriki deepak.chitr...@ti.com
Cc: Felipe Contreras felipe.contre...@nokia.com
Cc: Hiroshi Doyu hiroshi.d...@nokia.com
Cc: Omar Ramirez Luna omar.rami...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 5dfbef8..a13e035 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -73,6 +73,12 @@ DSP_STATUS handle_constraints_set(struct WMD_DEV_CONTEXT
*pDevContext,
/* pick up the opp index */
opp_idx = *(((u32 *)(pArgs)) + 1);
+ /* Sanity check to ensure things are fine */
+ if (!opp_idx || (opp_idx pdata-dsp_num_speeds)) {
+ pr_err(%s: DSP requested for an invalid OPP %d Vs %d-%d!\n,
+ __func__, opp_idx, 1, pdata-dsp_num_speeds);
+ return DSP_EINVALIDARG;
+ }
/* Read the target value requested by DSP */
DBG_Trace(DBG_LEVEL7, handle_constraints_set:
opp requested = 0x%x\n, opp_idx);
--
1.6.3.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
[PATCH 0/2] DSPBRIDGE: trivial opp constraint
in continuation of the discussion in: http://marc.info/?t=12639519602r=1w=2 patch #2 in this series depends on: http://marc.info/?l=linux-omapm=126402596424801w=2 Nishanth Menon (2): DSPBRIDGE: improve constraint_value handling DSPBRIDGE: sanitize opp_idx before passing to PM drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 16 1 files changed, 12 insertions(+), 4 deletions(-) Cc: Ameya Palande ameya.pala...@nokia.com Cc: Deepak Chitriki deepak.chitr...@ti.com Cc: Felipe Contreras felipe.contre...@nokia.com Cc: Hiroshi Doyu hiroshi.d...@nokia.com Cc: Omar Ramirez Luna omar.rami...@ti.com 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
RE: [PATCH 0/3] OMAP4: prcm/clock fixes
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 21, 2010 2:17 AM To: Nayak, Rajendra Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: RE: [PATCH 0/3] OMAP4: prcm/clock fixes Hi, On Tue, 19 Jan 2010, Paul Walmsley wrote: On Tue, 19 Jan 2010, Paul Walmsley wrote: This patch is now posted for any comments or review: http://www.pwsan.com/omap/patches/omap4_clk_fix/0001-OMAP4-PRC M-Define-shift-macros-as-n-instead-of-1.patch Thanks, this is a total brown paper bag bug :-( Queued for 2.6.33-rc. Based on some advice from Tony, this patch has been moved to the for_2.6.34 branch. Please let me know if this causes any problems. Thanks Paul, that should be just fine. - 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 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
Hello Thara,
On Thu, 21 Jan 2010, Gopinath, Thara wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, January 20, 2010 11:05 PM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
On Wed, 20 Jan 2010, Thara Gopinath wrote:
DPLL4 autoidle is controlled through the register CM_PLL_AUTOIDLE
which is to be restored by rom code from the scratchpad in case
of a core domain context loss. But enabling this bit in scratchpad
causes rom code to take an extra 20 ms delay in the restore path.
To avoid this delay this bit is not enabled in the scratchpad today.
This means after a core off happens DPLL4 autoidle is never again
enabled back.
This patch enables DPLL4 autoidle in case of core domain losing
context.
Shouldn't this be contingent on whether DPLL4 autoidle was enabled before
the CORE off transition?
Hi Paul, Hmmm may be yes.. But you see today we enable all autoidle bits
in the init.
That may change depending on device wakeup latency constraints. If a
device has a low wakeup latency, we may choose to keep a DPLL running.
Sometimes this is also changed to work around silicon bugs. So we should
avoid adding code that makes assumptions about any of those autoidle bits.
Why I had to make this unconditional is because later before core
entering OSWR I explicitly disable this bit in the register. This is so
as to match this register content with those of scratchpad during OSWR.
Failing to do this rom code while exiting OSWR will take the path it
takes while coming out of core off . This causes a crash in the system
today.
Fine, but can't you save the previous state of the DPLL autoidle with
omap3_dpll_autoidle_read() before you disable it prior to OSWR, and just
restore it afterwards?
Also another reason is omap3_prcm_save_context needs to be called
only during core off today.
Is this because the CM registers are part of the logic section of the CORE
powerdomain?
If I move saving of this bit and restoring it back into
omap3_prcm_save_context and omap3_prcm_restore_context I will have to
call it during core OSWR also.
If you're not calling those now for OSWR, you shouldn't have to call them
just to save and restore the DPLL4 autoidle state, right? Wouldn't it
work to simply read the current autoidle state with
omap3_dpll_autoidle_read() before entering OSWR, then restore it
afterwards with omap3_dpll_{allow,deny}_idle() ?
Wanted to avoid the extra complications.
And the extra delay. Reads and writes from L4_WAKEUP-connected devices
are sllloow.
But if this approach is not ok, I can modify the save restore APIs to
take power state as a parameter and do only dpll4 autoidle save and
restore in case of OSWR. Is this ok?
Well, let me know what you think of the above...
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e4db1ea..6e6d954 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -520,6 +520,14 @@ void omap_sram_idle(void)
*/
if (cpu_is_omap3430())
usb_musb_disable_autoidle();
+ /* We do not program the scratchpad to restore back
+ * PER DPLL in autoidle due to 20 ms delay in
+ * rom code restore path. So enable it explicitly
+ * after core off
+ */
This multi-line comment needs to be fixed to conform to
Documentation/CodingStyle.
Oops.. My bad. Will fix and resend the patch. Don't know why checkpatch
is not catching this. I will wait a couple of days for comments on other
patches also and resend all of them after fixing the relevant comments.
+ cm_rmw_mod_reg_bits(
+ 0x0, (1 OMAP3430_AUTO_PERIPH_DPLL_SHIFT),
+ PLL_MOD, CM_AUTOIDLE);
One other comment. Any reason why this patch can't use the
omap3_dpll_allow_idle() and omap3_dpll_deny_idle() functions, rather than
writing to the register directly?
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
--
1.5.6.3
- 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 7/8] OMAP3 PM: Support for Open Switch Retention for Core and MPU power domains in cpuidle path
Just FYI some of the multiline comments in this patch have the same problem as mentioned before. - 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 1/6] omap3: pm: re-program the sleep state of TRITON resources by modifying the REMAP register
- Original Message -
From: Mike Rapoport m...@compulab.co.il
To: x0080...@ti.com
Cc: linux-omap@vger.kernel.org; Nishanth Menon n...@ti.com; David
Derrick dderr...@ti.com; Samuel Ortiz sa...@linux.intel.com
Sent: Wednesday, January 20, 2010 8:58 PM
Subject: Re: [PATCH v2 1/6] omap3: pm: re-program the sleep state of TRITON
resources by modifying the REMAP register
x0080...@ti.com wrote:
From: Lesly A M x0080...@ti.com
omap3: pm: re-program the sleep state of TRITON resources by modifying
the REMAP register
Removed the warning print with checking order of scripts, since the order
is not important. Only the values configured in the register, which is
pointing to
the starting address of each sequence should be correct.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
drivers/mfd/twl4030-power.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
Index: linux-omap-pm/drivers/mfd/twl4030-power.c
===
--- linux-omap-pm.orig/drivers/mfd/twl4030-power.c 2010-01-19
19:18:56.0 +0530
+++ linux-omap-pm/drivers/mfd/twl4030-power.c 2010-01-19
19:19:02.0 +0530
@@ -416,14 +416,35 @@
return err;
}
- return 0;
+
+ /* Set the remap sleep cmd */
+ err = twl_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+ rconfig_addr + REMAP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 Resource %d remap could not read\n,
+ rconfig-resource);
+ return err;
+ }
+
+ if (rconfig-remap_sleep = 0) {
+ remap = ~SLEEP_STATE_MASK;
+ remap |= rconfig-remap_sleep;
+ }
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER, remap,
+ rconfig_addr + REMAP_OFFSET);
+ if (err 0) {
+ pr_err(TWL4030 failed to program remap sleep cmd \n);
+ return err;
+ }
+
Is it necessary to initialize the remap sleep twice?
No.
Sorry.. I didn't notice that Amit has already pushed this.
+ return err;
}
static int __init load_twl4030_script(struct twl4030_script *tscript,
u8 address)
{
int err;
- static int order;
/* Make sure the script isn't going beyond last valid address (0x3f) */
if ((address + tscript-size) END_OF_SCRIPT) {
@@ -444,7 +465,6 @@
err = twl4030_config_wakeup12_sequence(address);
if (err)
goto out;
- order = 1;
}
if (tscript-flags TWL4030_WAKEUP3_SCRIPT) {
err = twl4030_config_wakeup3_sequence(address);
@@ -452,10 +472,6 @@
goto out;
}
if (tscript-flags TWL4030_SLEEP_SCRIPT)
- if (order)
- pr_warning(TWL4030: Bad order of scripts (sleep \
- script before wakeup) Leads to boot\
- failure on some boards\n);
err = twl4030_config_sleep_sequence(address);
out:
return err;
--
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
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state
Hi Thara,
some more comments:
On Wed, 20 Jan 2010, Thara Gopinath wrote:
This patch adds APIs pwrdm_read_next_logic_pwrst and
Shouldn't this be pwrdm_read_logic_retst(), to match the existing code's
pwrdm_set_logic_retst() ?
pwrdm_read_next_mem_pwrst
and similarly, shouldn't this be pwrdm_read_next_mem_retst() to match the
existing code's pwrdm_read_mem_retst() ?
for reading the next programmed logic and memory state a powerdomain is
to hit in event of the next power domain state being retention.
Signed-off-by: Thara Gopinath th...@ti.com
---
arch/arm/mach-omap2/powerdomain.c | 71
+
arch/arm/plat-omap/include/plat/powerdomain.h |2 +
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 26b3f3e..06bf290 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -964,6 +964,29 @@ int pwrdm_read_prev_logic_pwrst(struct powerdomain
*pwrdm)
}
/**
+ * pwrdm_read_next_logic_pwrst - get next powerdomain logic power state
+ * @pwrdm: struct powerdomain * to get next logic power state
+ *
+ * Return the powerdomain pwrdm's logic power state. Returns -EINVAL
+ * if the powerdomain pointer is null or returns the next logic
+ * power state upon success.
+ */
+int pwrdm_read_next_logic_pwrst(struct powerdomain *pwrdm)
(see above)
+{
+ if (!pwrdm)
+ return -EINVAL;
+
+ /*
+ * The register bit names below may not correspond to the
+ * actual names of the bits in each powerdomain's register,
+ * but the type of value returned is the same for each
+ * powerdomain.
+ */
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs, PM_PWSTCTRL,
+ OMAP3430_LOGICSTATEST);
+}
+
+/**
* pwrdm_read_mem_pwrst - get current memory bank power state
* @pwrdm: struct powerdomain * to get current memory bank power state
* @bank: memory bank number (0-3)
@@ -1065,6 +1088,54 @@ int pwrdm_read_prev_mem_pwrst(struct powerdomain
*pwrdm, u8 bank)
}
/**
+ * pwrdm_read_next_mem_pwrst - get next memory bank power state
+ * @pwrdm: struct powerdomain * to get mext memory bank power state
+ * @bank: memory bank number (0-3)
+ *
+ * Return the powerdomain pwrdm's next memory power state for bank
+ * x. Returns -EINVAL if the powerdomain pointer is null, -EEXIST if
+ * the target memory bank does not exist or is not controllable, or
+ * returns the next memory power state upon success.
+ */
+int pwrdm_read_next_mem_pwrst(struct powerdomain *pwrdm, u8 bank)
(see above)
+{
+ u32 m;
+
+ if (!pwrdm)
+ return -EINVAL;
+
+ if (pwrdm-banks (bank + 1))
+ return -EEXIST;
+
+ /*
+ * The register bit names below may not correspond to the
+ * actual names of the bits in each powerdomain's register,
+ * but the type of value returned is the same for each
+ * powerdomain.
+ */
+ switch (bank) {
+ case 0:
+ m = OMAP3430_SHAREDL1CACHEFLATRETSTATE;
+ break;
+ case 1:
+ m = OMAP3430_L1FLATMEMRETSTATE;
+ break;
+ case 2:
+ m = OMAP3430_SHAREDL2CACHEFLATRETSTATE;
+ break;
+ case 3:
+ m = OMAP3430_SHAREDL2CACHEFLATRETSTATE;
+ break;
+ default:
+ WARN_ON(1); /* should never happen */
+ return -EEXIST;
+ }
+
+ return prm_read_mod_bits_shift(pwrdm-prcm_offs,
+ PM_PWSTCTRL, m);
+}
+
+/**
* pwrdm_clear_all_prev_pwrst - clear previous powerstate register for a
pwrdm
* @pwrdm: struct powerdomain * to clear
*
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 0b96005..7576559 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -170,8 +170,10 @@ int pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8
bank, u8 pwrst);
int pwrdm_read_logic_pwrst(struct powerdomain *pwrdm);
int pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm);
+int pwrdm_read_next_logic_pwrst(struct powerdomain *pwrdm);
(as above)
int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
+int pwrdm_read_next_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
(as above)
int pwrdm_enable_hdwr_sar(struct powerdomain *pwrdm);
int pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm);
--
1.5.6.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
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure
Hello Paul, -Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 21, 2010 8:50 AM To: Pagare, Abhijit Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- ker...@lists.infradead.org Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure Hello Abhijit, On Wed, 20 Jan 2010, Pagare, Abhijit wrote: I think the latest patch-set that I had posted has this change in it. You can refer to the patch in the link below http://marc.info/?l=linux-omapm=126088474831309w=2 Looks like this patch had somehow not made it into the for_2.6.34 branch; this has now been fixed, which resolves the problem. But this part we should discuss further: I had used this flag earlier as there was nothing fixed as to name it as ES1 that time. Yep, I understand. So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case and should be removed. A patch would be essential to take care of that in the places where it is used. If you feel the same I can send a patch for fixing this. In the past, there have been some clock, clockdomain, powerdomain, IP block, etc. changes going from ES1 to ES2 revisions. But most clocks, etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for what stays the same. Until ES2 details are available, this shouldn't require any further changes to the codebase aside from id.c. Sounds okay. We don't currently define a rollup macro for CHIP_IS_OMAP3430, but it's planned for 2.6.34 to include all of the individual CHIP_IS_OMAP* bits. We'd do the same thing for OMAP2xxx but most of the 2xxx data in the kernel tree has no ES-level information, so we'll probably leave those as-is. We'll probably add in a Sitara CHIP_IS_* bit in there also. Anyway, there's no need for you to change your patch, now that it's included in the for_2.6.34 branch. But keep in mind that we'll probably post another id.c cleanup patch to change things around as described above, unless you or others have some strong reason not to... Yes a patch will be essential for cleaning the id.c as we would have to also match up to the changes made by Tony for OMAP3 in his recently posted OMAP3: Fix cpu detection patch. I can send the patch when we need to push that change in for OMAP4. Thanks Regards, Abhijit - 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 0/8] OMAP3: PM: Open Switch Retention support in the cpuidle thread.
Hi Thara, I'd like to merge the powerdomain changes separately from the other changes, most of which should probably go through Kevin's PM branch. After you revise your patches based on the comments, can you take your patches 3, 4, and the powerdomain portions of patch 7 and post those in a separate series as an OSWR preparatory powerdomain patch set? That will make it easier for both Kevin and I to handle. Note: the powerdomain code will need to be edited somewhat to bring it up-to-date with the latest OMAP4 changes in the for_2.6.34 branch, which is where your patches will go. I'm happy to do this, but after I do it, will you be able to test the updated series to ensure that this process didn't break anything? regards, - 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/8] OMAP3 PM: Defining .pwrsts_logic_ret field for core power domain structure
On Wed, 20 Jan 2010, Thara Gopinath wrote: This patch adds the flag .pwrsts_logic_ret info for the core power domain in the associated powerdomain structure. This flag specifies the states core domain logic can hit in event of the domain entering retention. Signed-off-by: Thara Gopinath th...@ti.com Looks fine to me, - 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] OMAP35xx:SDIO IRQ Support for OMAP35xx
Hi Dirk,
Dirk Behme wrote:
On 21.12.2009 17:46, Mike Rapoport wrote:
Hi,
Phaneendra Kumar Alapati wrote:
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneendra Kumarph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
I've tried the patch on CM-T35 that has Marvell 88W8686 on-board and
surprisingly I get a lot of command timeouts from the libertas driver :(
---
libertas: requeueing command 0x0006 due to timeout (#1)
libertas: Received result 0 to command 6 after 1 retries
libertas: command 0x0006 timed out
---
I hope I'll find time to debug it in the next few days and provide
more valuable
information...
There is a test report from Overo air that there it doesn't work, too:
http://old.nabble.com/Re%3A-Overo-wifi-speed-and-WPA2-connection-issue-p27231874.html
Any news on this patch?
Unfortunately I haven't got time to see why libertas is unhappy with
this patch.. :(
Best regards
Dirk
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD(1 26)
#define SOFTRESET(1 1)
#define RESETDONE(1 0)
+#define CIRQ(1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL(1 11)
+#define CLKEXTFREE(1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines
should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
intvdd;
intprotect_card;
intreqs_blocked;
+intsdio_int;
structomap_mmc_platform_data*pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+if (host-sdio_int) {
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+}
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
spin_lock(host-irq_lock);
+data = host-data;
+status = OMAP_HSMMC_READ(host-base, STAT);
+dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+if (status CIRQ) {
+dev_dbg(mmc_dev(host-mmc), SDIO Card Interrupt\n);
+mmc_signal_sdio_irq(host-mmc);
+}
+}
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
-data = host-data;
-status = OMAP_HSMMC_READ(host-base, STAT);
-dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host
*mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int
enable)
+{
+struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+host-sdio_int = enable;
+if (enable) {
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+} else {
+OMAP_HSMMC_WRITE(host-base, IE,
+(OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE)));
+OMAP_HSMMC_WRITE(host-base, ISE,
+(OMAP_HSMMC_READ(host-base, ISE) (~CIRQ_ENABLE)));
+}
+
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1519,7 +1557,7 @@ static const struct mmc_host_ops omap_hsmmc_ops
= {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-/* NYET -- enable_sdio_irq */
+.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static const struct mmc_host_ops omap_hsmmc_ps_ops = {
@@ -1529,7 +1567,7 @@ static const struct mmc_host_ops
omap_hsmmc_ps_ops = {
.set_ios = omap_hsmmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
-/* NYET -- enable_sdio_irq */
+.enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
#ifdef CONFIG_DEBUG_FS
@@ -1657,6 +1695,7 @@
RE: [PATCH 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
Hi Paul,
That may change depending on device wakeup latency constraints. If a
device has a low wakeup latency, we may choose to keep a DPLL running.
Sometimes this is also changed to work around silicon bugs. So we should
avoid adding code that makes assumptions about any of those autoidle bits.
Why I had to make this unconditional is because later before core
entering OSWR I explicitly disable this bit in the register. This is so
as to match this register content with those of scratchpad during OSWR.
Failing to do this rom code while exiting OSWR will take the path it
takes while coming out of core off . This causes a crash in the system
today.
Fine, but can't you save the previous state of the DPLL autoidle with
omap3_dpll_autoidle_read() before you disable it prior to OSWR, and just
restore it afterwards?
Also another reason is omap3_prcm_save_context needs to be called
only during core off today.
Is this because the CM registers are part of the logic section of the CORE
powerdomain?
This is because CM module is built with Retention flip flops(RFF) and during
OSWR the voltage is still supplied to the logic built with RFF. Thus no content
loss.
If I move saving of this bit and restoring it back into
omap3_prcm_save_context and omap3_prcm_restore_context I will have to
call it during core OSWR also.
If you're not calling those now for OSWR, you shouldn't have to call them
just to save and restore the DPLL4 autoidle state, right? Wouldn't it
work to simply read the current autoidle state with
omap3_dpll_autoidle_read() before entering OSWR, then restore it
afterwards with omap3_dpll_{allow,deny}_idle() ?
Wanted to avoid the extra complications.
And the extra delay. Reads and writes from L4_WAKEUP-connected devices
are sllloow.
Agreed.
But if this approach is not ok, I can modify the save restore APIs to
take power state as a parameter and do only dpll4 autoidle save and
restore in case of OSWR. Is this ok?
Well, let me know what you think of the above...
I am ok with this. Only thing is it will involve a clk_get(dpll4_clk) and
then rest of the API calls as you have suggested. Considering this is in
cpuidle path, will the latencies be high?
If we have a latency issue, we can still keep the logic same as you have
suggested and instead of dpll api's directly use CM API's to implement the
same. So use cm_read_mod_reg and cm_rmw_mod_reg_bits.
Regards
Thara
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/8] OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 21, 2010 11:43 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH 3/8] OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state Hi Thara, some more comments: On Wed, 20 Jan 2010, Thara Gopinath wrote: This patch adds APIs pwrdm_read_next_logic_pwrst and Shouldn't this be pwrdm_read_logic_retst(), to match the existing code's pwrdm_set_logic_retst() ? pwrdm_read_next_mem_pwrst and similarly, shouldn't this be pwrdm_read_next_mem_retst() to match the existing code's pwrdm_read_mem_retst() ? Hello Paul, Yes agreed. I just looked at pwrdm_read_next_pwrst and implemented these. Will repost with correct API names. Regards Thara -- 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 0/8] OMAP3: PM: Open Switch Retention support in the cpuidle thread.
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, January 21, 2010 11:54 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com Subject: Re: [PATCH 0/8] OMAP3: PM: Open Switch Retention support in the cpuidle thread. Hi Thara, I'd like to merge the powerdomain changes separately from the other changes, most of which should probably go through Kevin's PM branch. After you revise your patches based on the comments, can you take your patches 3, 4, and the powerdomain portions of patch 7 and post those in a separate series as an OSWR preparatory powerdomain patch set? That will make it easier for both Kevin and I to handle. When you say patch 7, I believe you are mentioning the book keeping part for OSWR where logic_ret_off and mem_ret_off counters are added. I can separate this out and post these three patches separately. Do let me know should I base these on linux-omap master branch or Kevin's pm tree. Note: the powerdomain code will need to be edited somewhat to bring it up-to-date with the latest OMAP4 changes in the for_2.6.34 branch, which is where your patches will go. I'm happy to do this, but after I do it, will you be able to test the updated series to ensure that this process didn't break anything? Thanks for this and sure I can test the updated series! But I do not understand what OMAP4 specific support has to be added for these three patches. These three patches will be considerably free of OMAP2/OMAP3/OMAP4 specific stuff. Or are you talking of rebasing on 2.6.34 kernel? Regards Thara -- 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 6/8] OMAP3 PM: Enable DPLL4 autoidle after system off.
Hi, On Thu, 21 Jan 2010, Gopinath, Thara wrote: But if this approach is not ok, I can modify the save restore APIs to take power state as a parameter and do only dpll4 autoidle save and restore in case of OSWR. Is this ok? Well, let me know what you think of the above... I am ok with this. Only thing is it will involve a clk_get(dpll4_clk) and then rest of the API calls as you have suggested. Considering this is in cpuidle path, will the latencies be high? How about doing the clk_get() in advance in omap3_pm_init(), and store the struct clk pointer in a static variable that can be referenced from the cpuidle path? If we have a latency issue, we can still keep the logic same as you have suggested and instead of dpll api's directly use CM API's to implement the same. So use cm_read_mod_reg and cm_rmw_mod_reg_bits. We could but let's try the DPLL API first. I doubt the difference between using the DPLL API and using the cm_* functions will be measurable. If you look at the code for those functions, there's not much to them. - 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: [PATCHv3 1/1] OMAP3: PM: move omap opp layer from pm34xx.c
Actually, system boots. It does not break the system. What I've tried is: - rx51 board - omap3_pm_defconfig without CPU_FREQ - linux-omap-pm/pm-wip-opp branch + this patch System boots, but smartreflex disables itself: ... TCP cubic registered NET: Registered protocol family 17 NET: Registered protocol family 15 Power Management for TI OMAP3. SR: OPP rate tables not defined for platform, not enabling SmartReflex VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 ,.. But it does not break booting procedure. So, I don't see why this would be a reason for doing this compilation fix into two steps. Unless you see another issue. Ok sorry about the misunderstanding then. Its ok from my side. ACKed. -- 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 0/8] OMAP3: PM: Open Switch Retention support in the cpuidle thread.
On Thu, 21 Jan 2010, Gopinath, Thara wrote:
-Original Message-
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Thursday, January 21, 2010 11:54 AM
To: Gopinath, Thara
Cc: linux-omap@vger.kernel.org; khil...@deeprootsystems.com
Subject: Re: [PATCH 0/8] OMAP3: PM: Open Switch Retention support in the
cpuidle thread.
I'd like to merge the powerdomain changes separately from the other
changes, most of which should probably go through Kevin's PM branch.
After you revise your patches based on the comments, can you take your
patches 3, 4, and the powerdomain portions of patch 7 and post those in a
separate series as an OSWR preparatory powerdomain patch set? That will
make it easier for both Kevin and I to handle.
When you say patch 7, I believe you are mentioning the book keeping part
for OSWR where logic_ret_off and mem_ret_off counters are added.
Yes, to be specific, I'm talking about:
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 06bf290..ef9f1bb 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -126,6 +126,16 @@ static int _pwrdm_state_switch(struct powerdomain
*pwrdm, int flag)
prev = pwrdm_read_prev_pwrst(pwrdm);
if (pwrdm-state != prev)
pwrdm-state_counter[prev]++;
+ if (prev == PWRDM_POWER_RET) {
+ if ((pwrdm-pwrsts_logic_ret == PWRSTS_OFF_RET)
+ (pwrdm_read_prev_logic_pwrst(pwrdm) ==
+PWRDM_POWER_OFF))
+ pwrdm-ret_logic_off_counter++;
+ if ((pwrdm-pwrsts_mem_ret[0] == PWRSTS_OFF_RET)
+ (pwrdm_read_prev_mem_pwrst(pwrdm, 0) ==
+ PWRDM_POWER_OFF))
+ pwrdm-ret_mem_off_counter++;
+ }
break;
default:
return -EINVAL;
@@ -161,6 +171,9 @@ static __init void _pwrdm_setup(struct powerdomain *pwrdm)
for (i = 0; i PWRDM_MAX_PWRSTS; i++)
pwrdm-state_counter[i] = 0;
+ pwrdm-ret_logic_off_counter = 0;
+ pwrdm-ret_mem_off_counter = 0;
+
pwrdm_wait_transition(pwrdm);
pwrdm-state = pwrdm_read_pwrst(pwrdm);
pwrdm-state_counter[pwrdm-state] = 1;
and
diff --git a/arch/arm/plat-omap/include/plat/powerdomain.h
b/arch/arm/plat-omap/include/plat/powerdomain.h
index 7576559..405ccd6 100644
--- a/arch/arm/plat-omap/include/plat/powerdomain.h
+++ b/arch/arm/plat-omap/include/plat/powerdomain.h
@@ -124,6 +124,8 @@ struct powerdomain {
int state;
unsigned state_counter[PWRDM_MAX_PWRSTS];
+ unsigned ret_logic_off_counter;
+ unsigned ret_mem_off_counter;
#ifdef CONFIG_PM_DEBUG
s64 timer;
I can separate this out and post these three patches separately. Do let
me know should I base these on linux-omap master branch or Kevin's pm
tree.
l-o master, please.
Note: the powerdomain code will need to be edited somewhat to bring it
up-to-date with the latest OMAP4 changes in the for_2.6.34 branch, which
is where your patches will go. I'm happy to do this, but after I do it,
will you be able to test the updated series to ensure that this process
didn't break anything?
Thanks for this and sure I can test the updated series!
Great.
But I do not understand what OMAP4 specific support has to be added for
these three patches. These three patches will be considerably free of
OMAP2/OMAP3/OMAP4 specific stuff. Or are you talking of rebasing on
2.6.34 kernel?
OMAP4 has an additional memory bank. Also the names of the bitfields have
been abstracted out, e.g., OMAP_MEM0_RETSTATE_MASK instead of
OMAP3430_SHAREDL1CACHEFLATRETSTATE. You can check 'for_2.6.34' branch at
git://git.pwsan.com/linux-2.6 to see what it looks like.
- 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 2/6] omap3: pm: Using separate clk/volt setup_time for RET and OFF states
Manuel, Lesly Arackal had written, on 01/19/2010 11:35 AM, the following:
From: Lesly A M x0080...@ti.com
omap3: pm: Using separate clk/volt setup_time for RET and OFF states
Copied the setuptime in each board file, since OMAP3430 OMAP3630
has different voltage levels for the same states.
Made the changes to program the setup time according to
the target state of CORE power domain.
The voltsetup2 is used only when the device exits sys_off mode
(with PRM_VOLTCTRL[3]SEL_OFF set to 1).
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-3430sdp.c | 14 --
arch/arm/mach-omap2/board-3630sdp.c | 25 ++
arch/arm/mach-omap2/board-zoom-peripherals.c |4 +
arch/arm/mach-omap2/board-zoom2.c | 25 ++
arch/arm/mach-omap2/board-zoom3.c | 25 ++
arch/arm/mach-omap2/include/mach/board-zoom.h |2
arch/arm/mach-omap2/pm.h | 11 +++-
arch/arm/mach-omap2/pm34xx.c | 60 +-
8 files changed, 143 insertions(+), 23 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-3430sdp.c 2010-01-19
19:18:55.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/board-3430sdp.c 2010-01-19
19:19:23.0 +0530
@@ -75,13 +75,19 @@
{1, 1, 3, 30},
};
-/* FIXME: These are not the optimal setup values to be used on 3430sdp*/
+/* FIXME: These are not the optimal setup values to be used on 3430sdp */
static struct prm_setup_vc omap3_setuptime_table = {
- .clksetup = 0xff,
- .voltsetup_time1 = 0xfff,
- .voltsetup_time2 = 0xfff,
+ /* CLK SETUPTIME for RET OFF */
+ .clksetup_ret = 0xff,
+ .clksetup_off = 0xff,
+ /* VOLT SETUPTIME for RET OFF */
+ .voltsetup_time1_ret = 0xfff,
+ .voltsetup_time2_ret = 0xfff,
+ .voltsetup_time1_off = 0xfff,
+ .voltsetup_time2_off = 0xfff,
.voltoffset = 0xff,
.voltsetup2 = 0xff,
+ /* VC COMMAND VALUES for VDD1/VDD2 */
.vdd0_on = 0x30,
.vdd0_onlp = 0x20,
.vdd0_ret = 0x1e,
Index: linux-omap-pm/arch/arm/mach-omap2/board-3630sdp.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-3630sdp.c 2010-01-19
19:18:55.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/board-3630sdp.c 2010-01-19
19:19:23.0 +0530
@@ -25,6 +25,29 @@
#include mux.h
#include sdram-hynix-h8mbx00u0mer-0em.h
+#include pm.h
+
+static struct prm_setup_vc omap3_setuptime_table = {
+ /* CLK SETUPTIME for RET OFF */
+ .clksetup_ret = 0xff,
+ .clksetup_off = 0xff,
+ /* VOLT SETUPTIME for RET OFF */
+ .voltsetup_time1_ret = 0xfff,
+ .voltsetup_time2_ret = 0xfff,
+ .voltsetup_time1_off = 0xfff,
+ .voltsetup_time2_off = 0xfff,
+ .voltoffset = 0xff,
+ .voltsetup2 = 0xff,
+ /* VC COMMAND VALUES for VDD1/VDD2 */
+ .vdd0_on = 0x28, /* 1.1v */
+ .vdd0_onlp = 0x20, /* 1.0v */
+ .vdd0_ret = 0x13, /* 0.83v */
+ .vdd0_off = 0x00, /* 0.6v */
+ .vdd1_on = 0x2B, /* 1.1375v */
+ .vdd1_onlp = 0x20, /* 1.0v */
+ .vdd1_ret = 0x14, /* 0.85v */
+ .vdd1_off = 0x00, /* 0.6v */
+};
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
@@ -97,7 +120,7 @@
static void __init omap_sdp_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBP);
- zoom_peripherals_init();
+ zoom_peripherals_init(omap3_setuptime_table);
board_smc91x_init();
enable_board_wakeup_source();
usb_ehci_init(ehci_pdata);
Index: linux-omap-pm/arch/arm/mach-omap2/board-zoom-peripherals.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-zoom-peripherals.c
2010-01-19 19:18:55.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/board-zoom-peripherals.c 2010-01-19
19:19:23.0 +0530
@@ -26,6 +26,7 @@
#include mux.h
#include mmc-twl4030.h
+#include pm.h
/* Zoom2 has Qwerty keyboard*/
static int board_keymap[] = {
@@ -271,10 +272,11 @@
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-void __init zoom_peripherals_init(void)
+void __init zoom_peripherals_init(void *peripheral_data)
{
omap_i2c_init();
omap_serial_init();
usb_musb_init();
enable_board_wakeup_source();
+ omap3_pm_init_vc((struct prm_setup_vc *)peripheral_data);
}
Index: linux-omap-pm/arch/arm/mach-omap2/board-zoom2.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-zoom2.c2010-01-19
19:18:55.0 +0530
+++
Re: [PATCH v2 3/6] omap3: pm: Update Triton2 scripts
Manuel, Lesly Arackal had written, on 01/19/2010 11:35 AM, the following:
From: Lesly A M x0080...@ti.com
omap3: pm: Update Triton2 scripts
Updated the sleep, wakeup warm_reset sequence as recommended by David Derrick.
Used broadcast command, modified the resource type association and remap
sleep_state.
Added the new script changes for zoom[2,3] boards.
VDD1, VDD2 and VPLL1 are remapped to turn off during sleep state.
Changed RES_TYPE2 of VPLL1, VDD1, VDD2, REGEN, NRESPWRON SYSEN to '1'
and VINTANA1, VINTANA2, VINTDIG, VIO, CLKEN HFCLKOUT to '2'.
How about VMMC,VAUX and other resources?
HFCLKOUT is attached to P3, to disable HFCLK when clk_req signal is toggled.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-3430sdp.c | 83
arch/arm/mach-omap2/board-zoom-peripherals.c | 107 +++
include/linux/i2c/twl.h |4 +
3 files changed, 161 insertions(+), 33 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-3430sdp.c 2010-01-19
21:34:57.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/board-3430sdp.c 2010-01-19
21:41:26.0 +0530
@@ -448,14 +448,11 @@
static struct twl4030_ins __initdata sleep_on_seq[] = {
- /* Turn off HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_OFF), 2},
- /* Turn OFF VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 2},
- /* Turn OFF VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
- /* Turn OFF VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 2},
+ /* Broadcast message to put res to sleep */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_SLEEP), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_SLEEP), 2},
};
static struct twl4030_script sleep_on_script __initdata = {
@@ -465,14 +462,9 @@
};
static struct twl4030_ins wakeup_p12_seq[] __initdata = {
- /* Turn on HFCLKOUT */
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 2},
- /* Turn ON VDD2 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 2},
- /* Turn ON VPLL1 */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 2},
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wakeup_p12_script __initdata = {
@@ -482,7 +474,9 @@
};
static struct twl4030_ins wakeup_p3_seq[] __initdata = {
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+ /* Broadcast message to put res to active */
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wakeup_p3_script __initdata = {
@@ -494,18 +488,23 @@
static struct twl4030_ins wrst_seq[] __initdata = {
/*
* Reset twl4030.
- * Reset VDD1 regulator.
- * Reset VDD2 regulator.
- * Reset VPLL1 regulator.
- * Enable sysclk output.
+ * Reset Main_Ref.
+ * Reset All type2_group2.
+ * Reset VUSB_3v1.
+ * Reset All type2_group1.
+ * Reset RC.
* Reenable twl4030.
*/
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_Main_Ref, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_VUSB_3V1, RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
+ RES_STATE_WRST), 2},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0,
+ RES_STATE_WRST), 2},
+ {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wrst_script __initdata = {
.script = wrst_seq,
@@ -521,12
Re: [PATCH v2 5/6] omap3: pm: Use generic TRITON power scripts for OMAP3430 board
Manuel, Lesly Arackal had written, on 01/19/2010 11:36 AM, the following:
From: Lesly A M x0080...@ti.com
omap3: pm: Use generic TRITON power scripts for OMAP3430 board
^ + subject
I suppose you meant SDP3430 as zoom2 is also OMAP3430 and so are few
more boards out in the list..
Removed the sleep/wakeup/warm_rest sequence from the board file.
Using the api(use_generic_twl4030_script) to update
the sleep/wakeup/warm_rest sequence voltsetup_time in the board file.
Signed-off-by: Lesly A M x0080...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/Makefile|3 -
arch/arm/mach-omap2/board-3430sdp.c | 79 +---
2 files changed, 6 insertions(+), 76 deletions(-)
Index: linux-omap-pm/arch/arm/mach-omap2/Makefile
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/Makefile 2010-01-19
20:59:58.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/Makefile 2010-01-19 21:14:14.0
+0530
@@ -89,7 +89,8 @@
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \
- mmc-twl4030.o
+ mmc-twl4030.o \
+ twl4030-script.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-sdram.o \
Index: linux-omap-pm/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-pm.orig/arch/arm/mach-omap2/board-3430sdp.c 2010-01-19
21:00:25.0 +0530
+++ linux-omap-pm/arch/arm/mach-omap2/board-3430sdp.c 2010-01-19
21:15:38.0 +0530
@@ -46,6 +46,7 @@
#include mux.h
#include sdram-qimonda-hyb18m512160af-6.h
#include mmc-twl4030.h
+#include twl4030-script.h
#include pm.h
#include omap3-opp.h
@@ -446,79 +447,6 @@
.irq_line = 1,
};
-
-static struct twl4030_ins __initdata sleep_on_seq[] = {
- /* Broadcast message to put res to sleep */
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
- RES_STATE_SLEEP), 2},
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
- RES_STATE_SLEEP), 2},
-};
-
-static struct twl4030_script sleep_on_script __initdata = {
- .script = sleep_on_seq,
- .size = ARRAY_SIZE(sleep_on_seq),
- .flags = TWL4030_SLEEP_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p12_seq[] __initdata = {
- /* Broadcast message to put res to active */
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
- RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p12_script __initdata = {
- .script = wakeup_p12_seq,
- .size = ARRAY_SIZE(wakeup_p12_seq),
- .flags = TWL4030_WAKEUP12_SCRIPT,
-};
-
-static struct twl4030_ins wakeup_p3_seq[] __initdata = {
- /* Broadcast message to put res to active */
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
- RES_STATE_ACTIVE), 2},
-};
-
-static struct twl4030_script wakeup_p3_script __initdata = {
- .script = wakeup_p3_seq,
- .size = ARRAY_SIZE(wakeup_p3_seq),
- .flags = TWL4030_WAKEUP3_SCRIPT,
-};
-
-static struct twl4030_ins wrst_seq[] __initdata = {
-/*
- * Reset twl4030.
- * Reset Main_Ref.
- * Reset All type2_group2.
- * Reset VUSB_3v1.
- * Reset All type2_group1.
- * Reset RC.
- * Reenable twl4030.
- */
- {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, RES_Main_Ref, RES_STATE_WRST), 2},
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R2,
- RES_STATE_WRST), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, RES_VUSB_3V1, RES_STATE_WRST), 2},
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, RES_TYPE_R0, RES_TYPE2_R1,
- RES_STATE_WRST), 2},
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_RC, RES_TYPE_ALL, RES_TYPE2_R0,
- RES_STATE_WRST), 2},
- {MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
-};
-static struct twl4030_script wrst_script __initdata = {
- .script = wrst_seq,
- .size = ARRAY_SIZE(wrst_seq),
- .flags = TWL4030_WRST_SCRIPT,
-};
-
-static struct twl4030_script *twl4030_scripts[] __initdata = {
-
Re: [PATCH 2/2] DSPBRIDGE: pm: use old implementation for opps
arch/arm/mach-omap2/dspbridge.c | 59
++-
1 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
index 26b860f..120d8a2 100644
--- a/arch/arm/mach-omap2/dspbridge.c
+++ b/arch/arm/mach-omap2/dspbridge.c
@@ -42,7 +42,64 @@ static struct dspbridge_platform_data dspbridge_pdata
__initdata = {
static int get_opp_table(struct dspbridge_platform_data *pdata)
{
#ifdef CONFIG_BRIDGE_DVFS
- /* Do nothing now - fill based on PM implementation */
+ /* legacy values for 3430 */
+ u32 vdd1_dsp_freq[6][4] = {
+ {0, 0, 0, 0},
+ /*OPP1*/
+ {0, 9, 0, 86000},
+ /*OPP2*/
+ {0, 18, 8, 17},
+ /*OPP3*/
+ {0, 36, 16, 34},
+ /*OPP4*/
+ {0, 396000, 325000, 376000},
+ /*OPP5*/
+ {0, 43, 355000, 43},
+ };
+ struct omap_opp vdd1_rate_table_bridge[] = {
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0},
+ };
+ pdata-dsp_num_speeds = VDD1_OPP5;
Why dont you use ARRAY_SIZE - 1 ?
+ pdata-mpu_speeds = kzalloc(sizeof(u32) * pdata-dsp_num_speeds,
+ GFP_KERNEL);
I understand pdata-dsp_num_speeds == pdata-mpu_num_speeds. But don't you think
passing pdata-mpu_num_speeds makes more sense here?
+ if (!pdata-mpu_speeds) {
+ pr_err(unable to allocate memory for the mpu
+ frequencies\n);
+ return -ENOMEM;
+ }
As I mentioned in my earlier email. You return to the caller here but you free
pdata-dsp_freq_table in the caller even if pdata-dsp_freq_table is not
allocated.
+ pdata-dsp_freq_table = kzalloc(
+ sizeof(struct dsp_shm_freq_table) *
+ (pdata-dsp_num_speeds + 1), GFP_KERNEL);
+ if (!pdata-dsp_freq_table) {
+ pr_err(unable to allocate memory for the dsp
+ frequencies\n);
+ return -ENOMEM;
+ }
+ for (i = 0; i 6; i++)
Why are you hard coding numeric 6 here?
+ pdata-mpu_speed[i] = vdd1_rate_table_bridge[i].rate;
+ pdata-mpu_max_speed = pdata-mpu_speed[VDD1_OPP5];
You can use ARRAY_SIZE.
+ pdata-mpu_min_speed = pdata-mpu_speed[VDD1_OPP1];
+ pdata-dsp_num_speeds = VDD1_OPP5;
Same..ARRAY_SIZE...
+ for (i = 0; i = pdata-dsp_num_speeds; i++) {
+ pdata-dsp_freq_table[i].u_volts =
+ vdd1_dsp_freq[i][0];
+ frequency = pdata-dsp_freq_table[i].dsp_freq =
+ frequency = vdd1_dsp_freq[i][1];
+ pdata-dsp_freq_table[i].thresh_min_freq =
+ vdd1_dsp_freq[i][2];
+ pdata-dsp_freq_table[i].thresh_max_freq =
+ vdd1_dsp_freq[i][3];
+ }
#endif
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] DSPBRIDGE: remove dependency of mpu freq
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
+
static int __init dspbridge_init(void)
{
struct platform_device *pdev;
@@ -48,6 +65,10 @@ static int __init dspbridge_init(void)
if (!pdev)
goto err_out;
+ err = get_opp_table(pdata);
+ if (err)
+ goto err_out;
+
err = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (err)
goto err_out;
@@ -60,6 +81,10 @@ static int __init dspbridge_init(void)
return 0;
err_out:
+ kfree(pdata-mpu_speeds);
+ kfree(pdata-dsp_freq_table);
Are we sure that pdata-dsp_freq_table is NULL before initialization?
Looking at your second part of the patch. You seem to invoke kfree for
pdata-dsp_freq_table even if pdata-dsp_freq_table is not allocated.
So my question is :
--
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/2] DSPBRIDGE: remove dependency of mpu freq
Romit Dasgupta wrote:
diff --git a/arch/arm/mach-omap2/dspbridge.c
b/arch/arm/mach-omap2/dspbridge.c
+
static int __init dspbridge_init(void)
{
struct platform_device *pdev;
@@ -48,6 +65,10 @@ static int __init dspbridge_init(void)
if (!pdev)
goto err_out;
+err = get_opp_table(pdata);
+if (err)
+goto err_out;
+
err = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (err)
goto err_out;
@@ -60,6 +81,10 @@ static int __init dspbridge_init(void)
return 0;
err_out:
+kfree(pdata-mpu_speeds);
+kfree(pdata-dsp_freq_table);
Are we sure that pdata-dsp_freq_table is NULL before initialization?
Looking at your second part of the patch. You seem to invoke kfree for
pdata-dsp_freq_table even if pdata-dsp_freq_table is not allocated.
So my question is :
missed the last part of the mail. If pdata-dsp_freq_table is NULL to start
with. This is ok. Otherwise this needs to be changed.
--
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/2] DSPBRIDGE: remove dependency of mpu freq
Dasgupta, Romit had written, on 01/21/2010 01:40 AM, the following:
Romit Dasgupta wrote:
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
+
static int __init dspbridge_init(void)
{
struct platform_device *pdev;
@@ -48,6 +65,10 @@ static int __init dspbridge_init(void)
if (!pdev)
goto err_out;
+ err = get_opp_table(pdata);
+ if (err)
+ goto err_out;
+
err = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (err)
goto err_out;
@@ -60,6 +81,10 @@ static int __init dspbridge_init(void)
return 0;
err_out:
+ kfree(pdata-mpu_speeds);
+ kfree(pdata-dsp_freq_table);
Are we sure that pdata-dsp_freq_table is NULL before initialization?
Looking at your second part of the patch. You seem to invoke kfree for
pdata-dsp_freq_table even if pdata-dsp_freq_table is not allocated.
So my question is :
missed the last part of the mail. If pdata-dsp_freq_table is NULL to start
with. This is ok. Otherwise this needs to be changed.
;) yep it is NULL to start with as the same file passes pdata from:
static struct dspbridge_platform_data dspbridge_pdata __initdata
and kfree is NULL safe :D.
--
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
Re: [PATCH 1/2] DSPBRIDGE: remove dependency of mpu freq
@@ -67,6 +92,9 @@ module_init(dspbridge_init);
static void __exit dspbridge_exit(void)
{
+ struct dspbridge_platform_data *pdata = dspbridge_pdata;
+ kfree(pdata-mpu_speeds);
+ kfree(pdata-dsp_freq_table);
platform_device_unregister(dspbridge_pdev);
}
module_exit(dspbridge_exit);
Ok if pdata-mpu_speeds, pdata-dsp_freq_table are NULL to start with, then you
need to make them NULL after kfree as well. Otherwise next time you insert the
module it may fail if pdata_mpu_speeds is initialized but pdata-dsp_freq_table
is 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
Re: [PATCH 2/2] DSPBRIDGE: pm: use old implementation for opps
Dasgupta, Romit had written, on 01/21/2010 01:38 AM, the following:
arch/arm/mach-omap2/dspbridge.c | 59 ++-
1 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/dspbridge.c b/arch/arm/mach-omap2/dspbridge.c
index 26b860f..120d8a2 100644
--- a/arch/arm/mach-omap2/dspbridge.c
+++ b/arch/arm/mach-omap2/dspbridge.c
@@ -42,7 +42,64 @@ static struct dspbridge_platform_data dspbridge_pdata
__initdata = {
static int get_opp_table(struct dspbridge_platform_data *pdata)
{
#ifdef CONFIG_BRIDGE_DVFS
- /* Do nothing now - fill based on PM implementation */
+ /* legacy values for 3430 */
+ u32 vdd1_dsp_freq[6][4] = {
+ {0, 0, 0, 0},
+ /*OPP1*/
+ {0, 9, 0, 86000},
+ /*OPP2*/
+ {0, 18, 8, 17},
+ /*OPP3*/
+ {0, 36, 16, 34},
+ /*OPP4*/
+ {0, 396000, 325000, 376000},
+ /*OPP5*/
+ {0, 43, 355000, 43},
+ };
+ struct omap_opp vdd1_rate_table_bridge[] = {
+ {0, 0, 0},
+ /*OPP1*/
+ {S125M, VDD1_OPP1, 0},
+ /*OPP2*/
+ {S250M, VDD1_OPP2, 0},
+ /*OPP3*/
+ {S500M, VDD1_OPP3, 0},
+ /*OPP4*/
+ {S550M, VDD1_OPP4, 0},
+ /*OPP5*/
+ {S600M, VDD1_OPP5, 0},
+ };
+ pdata-dsp_num_speeds = VDD1_OPP5;
Why dont you use ARRAY_SIZE - 1 ?
This is a 1-1 transposition of old code here. further improvement
patches is a good thing to have (though I find the usage of ARRAY_SIZE
still wont make it cpu independent).
+ pdata-mpu_speeds = kzalloc(sizeof(u32) * pdata-dsp_num_speeds,
+ GFP_KERNEL);
I understand pdata-dsp_num_speeds == pdata-mpu_num_speeds. But don't you think
passing pdata-mpu_num_speeds makes more sense here?
thanks for catching this - yeah, it is right to use mpu_num_speeds
(even though the nums are the same)
+ if (!pdata-mpu_speeds) {
+ pr_err(unable to allocate memory for the mpu
+ frequencies\n);
+ return -ENOMEM;
+ }
As I mentioned in my earlier email. You return to the caller here but you free
pdata-dsp_freq_table in the caller even if pdata-dsp_freq_table is not
allocated.
yes, that is coz kfree is NULL safe. you can verify that by writing a
simple code and testing on checkpatch:
if (ptr)
kfree(ptr);
+ pdata-dsp_freq_table = kzalloc(
+ sizeof(struct dsp_shm_freq_table) *
+ (pdata-dsp_num_speeds + 1), GFP_KERNEL);
+ if (!pdata-dsp_freq_table) {
+ pr_err(unable to allocate memory for the dsp
+ frequencies\n);
+ return -ENOMEM;
+ }
+ for (i = 0; i 6; i++)
Why are you hard coding numeric 6 here?
carry over of old code - intention is *not* to optimize this.
+ pdata-mpu_speed[i] = vdd1_rate_table_bridge[i].rate;
+ pdata-mpu_max_speed = pdata-mpu_speed[VDD1_OPP5];
You can use ARRAY_SIZE.
+ pdata-mpu_min_speed = pdata-mpu_speed[VDD1_OPP1];
+ pdata-dsp_num_speeds = VDD1_OPP5;
Same..ARRAY_SIZE...
intention was to retain the old logic here.
+ for (i = 0; i = pdata-dsp_num_speeds; i++) {
+ pdata-dsp_freq_table[i].u_volts =
+ vdd1_dsp_freq[i][0];
+ frequency = pdata-dsp_freq_table[i].dsp_freq =
+ frequency = vdd1_dsp_freq[i][1];
+ pdata-dsp_freq_table[i].thresh_min_freq =
+ vdd1_dsp_freq[i][2];
+ pdata-dsp_freq_table[i].thresh_max_freq =
+ vdd1_dsp_freq[i][3];
+ }
#endif
return 0;
}
--
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
