Re: Patch series in Tarball submitted (RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2)
On Wed, 14 Jan 2009 08:55:08 -0600 Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote: -Original Message- From: Hiremath, Vaibhav Sent: Wednesday, January 14, 2009 8:51 AM snip [Hiremath, Vaibhav] I tried to build camera driver as module and got following error - ERROR: ispmmu_get_mapeable_space [drivers/media/video/omap34xxcam.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 You have missed to export this symbol, please correct in next version of patches. Oops, good catch. Thanks, I'll correct that. No problem. Better to wait a little bit before posting the new version... I'm still analyzing the current posting. It would be useful if you could document the private ioctls you've added, to help me to better analyse the remaining patches. Cheers, Mauro -- 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] Wait for SDRC ready iso a blind delay
This patch improves the wakeup SRAM code polling the SDRC to become ready
instead of just waiting for a fixed amount of time.
---
arch/arm/mach-omap2/sleep34xx.S | 50 --
1 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 0c33e30..d29c180 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -38,6 +38,8 @@
#define PM_PREPWSTST_CORE_P0x48306AE8
#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
OMAP3430_PM_PREPWSTST)
+#define CM_IDLEST1_CORE_V IO_ADDRESS(OMAP3430_CM_BASE + 0x220)
+
/*
* This is the physical address of the register as specified
* by the _P. To be used while the MMU is still disabled.
@@ -57,6 +59,8 @@
#define SDRC_MR_1_P(OMAP343X_SDRC_BASE + SDRC_MR_1)
#define SDRC_EMR2_1_P (OMAP343X_SDRC_BASE + SDRC_EMR2_1)
#define SDRC_MANUAL_1_P(OMAP343X_SDRC_BASE + SDRC_MANUAL_1)
+#define SDRC_DLLA_STATUS_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_STATUS)
+#define SDRC_DLLA_CTRL_V OMAP34XX_SDRC_REGADDR(SDRC_DLLA_CTRL)
.text
/* Function call to get the restore pointer for resume from OFF */
@@ -192,7 +196,7 @@ loop:
nop
nop
nop
- bl i_dll_wait
+ bl wait_sdrc_ok
ldmfd sp!, {r0-r12, pc} @ restore regs and return
restore_es3:
@@ -651,21 +655,41 @@ skip_l2_inval:
nop
nop
nop
- bl i_dll_wait
+ bl wait_sdrc_ok
/* restore regs and return */
ldmfd sp!, {r0-r12, pc}
-i_dll_wait:
- ldr r4, clk_stabilize_delay
-
-i_dll_delay:
- subsr4, r4, #0x1
- bne i_dll_delay
- ldr r4, sdrc_power
- ldr r5, [r4]
- bic r5, r5, #0x40
- str r5, [r4]
- bx lr
+/* Make sure SDRC accesses are ok */
+wait_sdrc_ok:
+ldr r4, cm_idlest1_core
+ldr r5, [r4]
+and r5, r5, #0x2
+cmp r5, #0
+bne wait_sdrc_ok
+ldr r4, sdrc_power
+ldr r5, [r4]
+bic r5, r5, #0x40
+str r5, [r4]
+wait_dll_lock:
+/* Is dll in lock mode? */
+ldr r4, sdrc_dlla_ctrl
+ldr r5, [r4]
+tst r5, #0x4
+bxnelr
+/* wait till dll locks */
+ldr r4, sdrc_dlla_status
+ldr r5, [r4]
+and r5, r5, #0x4
+cmp r5, #0x4
+bne wait_dll_lock
+bx lr
+
+cm_idlest1_core:
+ .word CM_IDLEST1_CORE_V
+sdrc_dlla_status:
+ .word SDRC_DLLA_STATUS_V
+sdrc_dlla_ctrl:
+ .word SDRC_DLLA_CTRL_V
pm_prepwstst_core:
.word PM_PREPWSTST_CORE_V
pm_prepwstst_core_p:
--
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] Don't scale voltage in C1 state
This patch prevents VDD1 and VDD2 to go to the lowest OPP when entering C1. It improves wakeup latency from 600us to about 50us. Now with signoff :) Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- arch/arm/mach-omap2/pm34xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index b0b2188..87ef55e 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -1052,7 +1052,7 @@ static void __init configure_vc(void) OMAP3_PRM_VC_I2C_CFG_OFFSET); /* Setup voltctrl and other setup times */ - prm_write_mod_reg(OMAP3430_AUTO_RET | OMAP3430_AUTO_SLEEP, + prm_write_mod_reg(OMAP3430_AUTO_RET, OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET); prm_write_mod_reg(OMAP3430_CLKSETUP_DURATION, OMAP3430_GR_MOD, -- 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: new PM branch available
Ramesh Gupta Guntha wrote: Hi Kevin, On 1/14/09, Kevin Hilman khil...@deeprootsystems.com wrote: Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. I have tested on my SDP, I too observed the similar behaviour, I am seeing both PER and CORE are active. Hmm, if you're seeing both PER and CORE, then UART clocks are probably still active. Please try this: # echo 1 /sys/power/clocks_off_while_idle then try again. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new PM branch available
Sriram V wrote: Hi, OMAP3EVM. all domains hit retention in suspend. On enabling cpuidle, network and mmc is not stable. network is unable to get an IP address. Sriram, Can you send me your .config for omap3evm? I'm trying to get my recently received EVM working but I am getting lots of garbage on the serial console on linux-omap HEAD and PM branch on omap3evm. Do you have any additional patches for EVM that you're using? Kevin On Wed, Jan 14, 2009 at 3:21 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 Full git shortlog below[2] Enjoy, Kevin [1] See branch 'pm' in my git repo: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git which is also mirrored as the branch 'pm' of the normal linux-omap repo (but will not sync until 03:30 GMT) [2] git shortlog: Carlos Chinea (1): OMAP3:PM: Update SSI omapdev record Jouni Hogander (5): OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle loop OMAP3: PM: Fix wrong sequence in suspend. OMAP3: PM: Do not build suspend code if SUSPEND is not enabled OMAP: PM: Build fails if PM is not enabled OMAP2: PM: Fix omap2 build Kalle Jokiniemi (3): OMAP: PM: sysfs interface for enabling voltage off in idle OMAP3: PM: Fix cpu idle init sequencing OMAP: SRF: Fixes to shared resource framework (Ver.3) Kevin Hilman (4): OMAP3: PM: CPUidle: obey enable_off_mode flag OMAP3: PM: CPUidle: restrict C-states on UART activity OMAP3: PM: decouple PER and CORE context save and restore OMAP2/3: PM: system_rev - omap_rev() Paul Walmsley (29): OMAP2/3 clock: implement clock notifier infrastructure OMAP clock: add notifier infrastructure OMAP2/3 clock: store planned clock rates into temporary rate storage OMAP2/3 clock: add clk post-rate-change notifiers OMAP2/3 clock: add clock pre-rate-change notification OMAP2/3 clock: add clock prepare-rate-change notifications OMAP2/3 clock: add clock abort-rate-change notifications OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer. OMAP2/3 omapdev: add basic omapdev structure OMAP242x omapdev: add OMAP242x omapdev records OMAP243x omapdev: add OMAP243x omapdev records OMAP3xxx omapdev: add OMAP3xxx omapdev records OMAP2/3 omapdev: add code to walk the omapdev records ARM: MMU: add a Non-cacheable Normal executable memory type OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpll OMAP3 clock: add interconnect barriers to CORE DPLL M2 change OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency change OMAP3 SDRC: Add 166MHz, 83MHz SDRC settings for the BeagleBoard OMAP3 SDRC: initialize SDRC_POWER at boot OMAP3 SRAM: renumber registers to make space for argument passing OMAP3 clock: only unlock SDRC DLL if SDRC clk 83MHz OMAP3 clock: use pr_debug() rather than pr_info() in some clock change code OMAP3 clock: remove wait for DPLL3 M2 clock to stabilize OMAP3 clock: initialize SDRC timings at kernel start OMAP3 clock: add a short delay when lowering CORE clk rate OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock change OMAP3 SRAM: add more comments on the SRAM code OMAP3 SRAM: convert SRAM code to use macros rather than magic numbers Peter 'p2' De Schrijver (12): OMAP: PM counter infrastructure. OMAP: PM: Hook into PM counters OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each. OMAP: PM: Add pm-debug counters OMAP: PM debug: make powerdomains use PM-debug counters OMAP: PM: Add definitions for ETK pads and observability registers OMAP: Debug observability and ETK padconf implementation OMAP: Add debug observablity (debobs) Kconfig item OMAP: PM: Implement get_last_off_on_transaction_id() Save sram context after changing MPU, DSP or core clocks Fix omap_getspeed. Make sure omap cpufreq driver initializes after cpufreq framework and governors Rajendra Nayak (35): OMAP3: PM: GPMC context save/restore OMAP3: PM: GPIO context save/restore OMAP3: PM: I2C context save/restore OMAP3: PM: INTC context save/restore OMAP3: PM: PRCM context save/restore OMAP3: PM: Populate scratchpad contents OMAP3: PM: SCM context save/restore OMAP3: PM: SRAM restore function OMAP3: PM: handle PER/NEON/CORE in idle OMAP3: PM: Restore MMU table
Re: Important changes, please read
Tony Lindgren wrote: - We stop using source.mvista.com git tree, and only use the kernel.org git tree. There's no need for having two master trees, and kernel.org is the standard way to go. Big thanks to Monta Vista for hosting us for many years. The git path at http://vger.kernel.org/vger-lists.html#linux-omap needs to be changed. rtg -- Tim Gardner tim.gard...@canonical.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
[OMAPZOOM][PATCH 1/4] DSPBRIDGE: Free resources when user fails to do so
From: Fernando Guzman Lugo x0095...@ti.com
Date: Mon, 17 Nov 2008 15:49:56 -0600
Subject: [PATCH] DSPBRIDGE: Free resources when user fails to do so
Added error protection in bridge driver to handle
the cases where user applications detach the
processor without releasing DMM resources.
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/dspbridge/drv.h | 13 +++
drivers/dsp/bridge/rmgr/drv.c |3 +-
drivers/dsp/bridge/rmgr/proc.c | 31 +++
3 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/drv.h
b/arch/arm/plat-omap/include/dspbridge/drv.h
index 0a8fb7e..4345b56 100644
--- a/arch/arm/plat-omap/include/dspbridge/drv.h
+++ b/arch/arm/plat-omap/include/dspbridge/drv.h
@@ -427,4 +427,17 @@ struct PROCESS_CONTEXT{
extern DSP_STATUS DRV_ReleaseResources(IN u32 dwContext,
struct DRV_OBJECT *hDrvObject);
+/*
+ * DRV_ProcFreeDMMRes
+ * Purpose:
+ * Actual DMM De-Allocation.
+ * Parameters:
+ * hPCtxt: Path to the driver Registry Key.
+ * Returns:
+ * DSP_SOK if success;
+ */
+
+
+ extern DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt);
+
#endif /* DRV_ */
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index 2614103..22faf49 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -162,7 +162,6 @@ static DSP_STATUS RequestBridgeResourcesDSP(u32 dwContext,
s32 fRequest);
static DSP_STATUS PrintProcessInformation(void);
static DSP_STATUS DRV_ProcFreeNodeRes(HANDLE hPCtxt);
-static DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt);
static DSP_STATUS DRV_ProcFreeSTRMRes(HANDLE hPCtxt);
extern enum NODE_STATE NODE_GetState(HANDLE hNode);
@@ -559,7 +558,7 @@ DSP_STATUS DRV_UpdateDMMResElement(HANDLE hDMMRes, u32
pMpuAddr, u32 ulSize,
}
/* Actual DMM De-Allocation */
-static DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
+DSP_STATUS DRV_ProcFreeDMMRes(HANDLE hPCtxt)
{
struct PROCESS_CONTEXT *pCtxt = (struct PROCESS_CONTEXT *)hPCtxt;
DSP_STATUS status = DSP_SOK;
diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c
index eb7781d..d7798e7 100644
--- a/drivers/dsp/bridge/rmgr/proc.c
+++ b/drivers/dsp/bridge/rmgr/proc.c
@@ -140,6 +140,7 @@
#include dspbridge/dbreg.h
#include dspbridge/msg.h
#include dspbridge/wmdioctl.h
+#include dspbridge/drv.h
/* --- This */
#include dspbridge/proc.h
@@ -646,25 +647,27 @@ DSP_STATUS PROC_Detach(DSP_HPROCESSOR hProcessor)
pProcObject-g_pszLastCoff = NULL;
}
+#ifndef RES_CLEANUP_DISABLE
+ /* Return PID instead of process handle */
+ hProcess = current-pid;
+
+ res_status = CFG_GetObject((u32 *)hDRVObject, REG_DRV_OBJECT);
+ if (DSP_SUCCEEDED(res_status)) {
+ DRV_GetProcContext(hProcess,
+ (struct DRV_OBJECT *)hDRVObject, pPctxt,
+NULL, 0);
+ if (pPctxt != NULL) {
+ DRV_ProcFreeDMMRes(pPctxt);
+ pPctxt-hProcessor = NULL;
+ }
+ }
+#endif
+
/* Remove the Proc from the DEV List */
(void)DEV_RemoveProcObject(pProcObject-hDevObject,
(u32)pProcObject);
/* Free the Processor Object */
MEM_FreeObject(pProcObject);
-#ifndef RES_CLEANUP_DISABLE
- /* Return PID instead of process handle */
- hProcess = current-pid;
-
- res_status = CFG_GetObject((u32 *)hDRVObject, REG_DRV_OBJECT);
- /* res_status = CFG_GetObject(REG_DRV_OBJECT, (u32*)hDRVObject); */
- if (DSP_SUCCEEDED(res_status)) {
- DRV_GetProcContext(hProcess,
-(struct DRV_OBJECT *)hDRVObject, pPctxt,
-NULL, 0);
- if (pPctxt != NULL)
- pPctxt-hProcessor = NULL;
- }
-#endif
} else {
status = DSP_EHANDLE;
GT_0trace(PROC_DebugMask, GT_7CLASS,
--
1.6.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
[OMAPZOOM][PATCH 2/4] DSPBRIDGE: LM Timer release for hibernation
From: Ramesh Gupta grgu...@ti.com
Date: Mon, 17 Nov 2008 16:11:19 -0600
Subject: [PATCH] DSPBRIDGE: LM Timer release for hibernation
Release load monitor timer when the DSP is
inactive and goes to hibernation
Signed-off-by: Ramesh Gupta grgu...@ti.com
Signed-off-by: SuiLun Lam s-...@ti.com
---
drivers/dsp/bridge/wmd/tiomap_sm.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap_sm.c
b/drivers/dsp/bridge/wmd/tiomap_sm.c
index 63655d9..edc3bcf 100644
--- a/drivers/dsp/bridge/wmd/tiomap_sm.c
+++ b/drivers/dsp/bridge/wmd/tiomap_sm.c
@@ -190,7 +190,6 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
if (pDevContext-dwBrdState == BRD_DSP_HIBERNATION ||
pDevContext-dwBrdState == BRD_HIBERNATION) {
- pDevContext-dwBrdState = BRD_RUNNING;
#ifndef CONFIG_DISABLE_BRIDGE_PM
#ifndef CONFIG_DISABLE_BRIDGE_DVFS
#ifndef CONFIG_OMAP3_PM
@@ -235,9 +234,12 @@ DSP_STATUS CHNLSM_InterruptDSP(struct WMD_DEV_CONTEXT
*hDevContext)
mboxsetting.irqEnable0);
DBG_Trace(DBG_LEVEL6, MailBoxSettings: IRQENABLE1 = 0x%x\n,
mboxsetting.irqEnable1);
- /* Restart the peripheral clocks that were disabled */
- DSP_PeripheralClocks_Enable(hDevContext, NULL);
+ /* Restart the peripheral clocks that were disabled only
+* in DSP initiated Hibernation case.*/
+ if (pDevContext-dwBrdState == BRD_DSP_HIBERNATION)
+ DSP_PeripheralClocks_Enable(hDevContext, NULL);
+ pDevContext-dwBrdState = BRD_RUNNING;
}
while (--cnt) {
hwStatus = HW_MBOX_IsFull(resources.dwMboxBase,
--
1.6.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
[OMAPZOOM][PATCH 3/4] DSPBRIDGE: Mapping sidetone registers
From: Hari Kanigeri h-kanige...@ti.com
Date: Mon, 17 Nov 2008 16:20:06 -0600
Subject: [PATCH] DSPBRIDGE: Mapping sidetone registers
New 3430 HW feature integrated into McBSP2
and McBSP3, enabling a sidetone process, for DASF.
Bridge has to handle this new configuration.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
drivers/dsp/bridge/wmd/_tiomap.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/_tiomap.h b/drivers/dsp/bridge/wmd/_tiomap.h
index ed1bff9..5267eb2 100644
--- a/drivers/dsp/bridge/wmd/_tiomap.h
+++ b/drivers/dsp/bridge/wmd/_tiomap.h
@@ -161,6 +161,11 @@ struct MAP_L4PERIPHERAL {
#define PM_GRPSEL_BASE 0x48307000
#define DSPVA_GRPSEL_BASE 0x11821000
+#define L4_PERIPHERAL_SIDETONE_MCBSP20x49028000
+#define DSPVA_PERIPHERAL_SIDETONE_MCBSP2 0x11824000
+#define L4_PERIPHERAL_SIDETONE_MCBSP30x4902a000
+#define DSPVA_PERIPHERAL_SIDETONE_MCBSP3 0x11825000
+
/* define a static array with L4 mappings */
static const struct MAP_L4PERIPHERAL L4PeripheralTable[] = {
{L4_PERIPHERAL_MBOX, DSPVA_PERIPHERAL_MBOX},
@@ -196,6 +201,8 @@ static const struct MAP_L4PERIPHERAL L4PeripheralTable[] = {
{L4_PERIPHERAL_CM, DSPVA_PERIPHERAL_CM},
{L4_PERIPHERAL_PER, DSPVA_PERIPHERAL_PER},
{PM_GRPSEL_BASE, DSPVA_GRPSEL_BASE},
+ {L4_PERIPHERAL_SIDETONE_MCBSP2, DSPVA_PERIPHERAL_SIDETONE_MCBSP2},
+ {L4_PERIPHERAL_SIDETONE_MCBSP3, DSPVA_PERIPHERAL_SIDETONE_MCBSP3},
{L4_PERIPHERAL_NULL, DSPVA_PERIPHERAL_NULL}
};
--
1.6.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
[OMAPZOOM][PATCH 4/4] DSPBRIDGE Deleting unneeded mem alloc
From: Hiroshi DOYU hiroshi.d...@nokia.com Date: Mon, 17 Nov 2008 17:13:58 -0600 Subject: [PATCH] DSPBRIDGE Deleting unneeded mem alloc Since SYNC_InitializeCS() allocates struct SYNC_CSOBJECT for hProcLock, MEM_AllocObject() shouldn't be called for hProcLock. This was double allocation for the same pointer. Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com --- drivers/dsp/bridge/rmgr/proc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/dsp/bridge/rmgr/proc.c b/drivers/dsp/bridge/rmgr/proc.c index d7798e7..9afaaad 100644 --- a/drivers/dsp/bridge/rmgr/proc.c +++ b/drivers/dsp/bridge/rmgr/proc.c @@ -1009,7 +1009,6 @@ bool PROC_Init(void) DBC_Assert(!PROC_DebugMask.flags); GT_create(PROC_DebugMask, PR); /* PR for Processor */ - MEM_AllocObject(hProcLock, struct SYNC_CSOBJECT, SIGNATURECS); (void)SYNC_InitializeCS(hProcLock); } -- 1.6.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] Include TPS6235x based Power regulator support
On Wednesday 14 January 2009, Pillai, Manikandan wrote: Let me summarise the main problem I have been facing with regulators. The TPS6235x are I2C based devices. The regulator_register() functions require that the regulator_init_data is passed as platform_data(). But for i2c_client's platform data is initialized to some other value in the I2C driver. So the regulator_register() function fails. Then you're initializing the i2c_board_info.platform_data field incorrectly. Do that right (pass regulator_init_data), and this problem vanishes. Only the tps6235x.c driver, and in this case the regulator framework (sigh), care about that platform_data. The other problem which I encounter is with the function regulator_get(). Regulator_get() requires 2 parameters - device pointer should point to the One passed during regulator_register. It also takes a string a second parameter Which is compared with the supply string initialized in the regulator init data element regulator_consumer_supply.supply. You need to intialize regulator_init_data.consumer_supplies (and num_consumer_supplies) to include those two parameters. Your pr785.c file will need to set up the regulator_init_data before it declares the regulators. (And yes, there *could* be a chicken/egg problem there where it gets awkward to get all those devices in hand -- and pass them to the regulator framework -- before their probe routines get called and try using their regulators. So far, careful initcall sequencing has sufficed to resolve that...) Passing the client-dev, invoking regulator_register() fails. Of course. That's the regulator -- an I2C device -- not the regulated device. You pass regulator_get() the name of the regulated device and a logical name for its supply regulator. It then looks for data from a regulator_consumer_supply, which was handed to the regulator framework via regulator_init_data. Remember: the whole point of a driver using regulator_get() to get a client handle to its supply regulator is that it won't already *have* any knowledge about what regulator is used on any given board. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new PM branch available
On Tuesday 13 January 2009, Koen Kooi wrote:
[ cut here ]
WARNING: at arch/arm/mach-omap2/clock.c:1094 omap2_clk_register
+0x24/0x3c()
Modules linked in:
[c003b824] (dump_stack+0x0/0x14) from [c005b180] (warn_on_slowpath
+0x4c/0x68)
Just in the cause of better diagnostics ... that looks like maybe
if (!clk-clkdm.name) {
pr_debug(clock: %s: missing clockdomain, clk-name);
WARN_ON(1);
return -EINVAL;
}
triggered. A better way to write that, in recent kernels, is
if (WARN(!clk-clkdm.name,
clock: %s missing clockdomain\n, clk-name))
return -EINVAL;
Where better includes diagnostic message is always present
and thus line numbers matter less. (Line 1094 in my kernel
is the right bracket above, not the WARN_ON...)
- Dave
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Include TPS6235x based Power regulator support
On Wed, Jan 14, 2009 at 09:55:58AM -0800, David Brownell wrote: problem vanishes. Only the tps6235x.c driver, and in this case the regulator framework (sigh), care about that platform_data. The regulator framework will be fixed in .30. -- 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: OMAP3430 clock settings
On Wednesday 14 January 2009, Krishna Kishore wrote: After reading IVA2_CM and MPU_CM registers, I want to know how to calculate the clock speeds. You should be using the clock framework. If you do that, then clk_get_rate() does that for you. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] OMAP gptimer based event monitor driver for oprofile
On Tuesday 13 January 2009 16:31:53 ext Tony Lindgren wrote:
Hi,
Looks OK in general, few comments below.
Once you're done with the changes, this should get posted to
linux-arm-ker...@lists.arm.linux.org.uk for review with linux-omap
list Cc'd.
Thanks a lot for a patch review. I just have a few questions before
resubmitting a fixed version.
[...]
+static int gptimer_start(void)
+{
+ u32 count = counter_config[0].count;
+ gptimer = omap_dm_timer_request();
+ BUG_ON(gptimer == NULL);
Maybe just return -ENODEV here instead BUG_ON? In theory you could
build a multi-omap kernel that works on multiple boards, and you
could have all timers used up on some boards.
OK
+ omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
+ if (request_irq(omap_dm_timer_get_irq(gptimer), gptimer_interrupt,
+ IRQF_DISABLED, oprofile gptimer, NULL) != 0) {
+ printk(KERN_ERR oprofile: unable to request gptimer IRQ\n);
+ return -1;
Could return something from errno.h here.
I grepped the kernel sources for 'request_irq' calls and they are not very
consistent about what to return in the case when it fails. But one of the
most common variants to handle this error is just to propagate error code
returned by 'request_irq' outside. Would it be ok?
+ }
+
+ if (count 1)
+ count = 1;
+
+ omap_dm_timer_set_load_start(gptimer, 1, 0x - count);
+ omap_dm_timer_set_int_enable(gptimer, OMAP_TIMER_INT_OVERFLOW);
+ return 0;
+}
You might want to use omap_dm_timer_request_specific() instead, and
use a timer that's connected to WKUP domain. Otherwise you'll miss
timer events in off-while-idle and retention-while-idle.
Probably having timer events when idle is actually not desired. Ideally
oprofile should collect samples only when CPU is active and provide a
report which represents CPU usage more or less precisely. So maybe
CORE power domain suits better here?
Also 'common.c' from oprofile directory contains code under CONFIG_PM ifdef
and provides hooks supposedly for suspend and resume operations.
About 'omap_dm_timer_request_specific'. Would it be right to first try all the
timers from the suitable domain, and then try to get just any timer before
bailing out (to handle the case when most of the timers are already used)?
I suggest not to use GPTIMER12, as it's interrupt also gets triggered
by spurious interrupts. But maybe you can find some other timer that's
in the WKUP domain by reading the 34xx TRM.
Thanks, note about broken GPTIMER12 taken.
Note that you cannot use GPTIMER1 either, because it's used for the
system timer. I believe 24xx only has GPTIMER1 in the WKUP domain,
so you might want to use omap_dm_timer_request() if cpu_is_omap24xx().
Don't know if 2430 has more thant GPTIMER1 in WKUP domain.
IMHO there is little need to use this oprofile driver on OMAP2 chips at all
(except for testing purposes, which I actually also have done on OMAP2420
too prior to submitting initial revision of the patch). The hardware
performance counters work and do the job fine there. Supporting OMAP1 may
have some practical value.
--
Best regards,
Siarhei Siamashka
--
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] Include TPS6235x based Power regulator support
On Wednesday 14 January 2009, Mark Brown wrote: On Wed, Jan 14, 2009 at 09:55:58AM -0800, David Brownell wrote: problem vanishes. Only the tps6235x.c driver, and in this case the regulator framework (sigh), care about that platform_data. The regulator framework will be fixed in .30. That'll be nice, thanks. Good to be consistent, and stick to the policy that platform_data is *only* for use by the device's driver. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[OMAPZOOM][PATCH] DSPBRIDGE Wakeup IVA before accessing IVA MMU Registers
From: Ramesh Gupta grgu...@ti.com
Date: Wed, 14 Jan 2009 17:39:20 +0530
Subject: [PATCH] DSPBRIDGE Wakeup IVA before accessing IVA MMU Registers
Wakeup IVA before accessing IVA MMU Registers
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430.c
b/drivers/dsp/bridge/wmd/tiomap3430.c
index c05383e..d838169 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430.c
@@ -1289,6 +1290,7 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
struct HW_MMUMapAttrs_t hwAttrs;
u32 numOfActualTabEntries = 0;
u32 temp = 0;
+ struct CFG_HOSTRES resources;
u32 *pPhysAddrPageTbl = NULL;
struct vm_area_struct *vma;
struct mm_struct *mm = current-mm;
@@ -1296,6 +1298,10 @@ static DSP_STATUS WMD_BRD_MemMap(struct WMD_DEV_CONTEXT
*hDevContext,
DBG_Trace(DBG_ENTER, WMD_BRD_MemMap hDevContext %x, pa %x, va %x,
size %x, ulMapAttr %x\n, hDevContext, ulMpuAddr, ulVirtAddr,
ulNumBytes, ulMapAttr);
+ status = CFG_GetHostResources(
+ (struct CFG_DEVNODE *)DRV_GetFirstDevExtension(),
+ resources);
+
if (ulNumBytes == 0)
return DSP_EINVALIDARG;
@@ -1423,7 +1429,16 @@ func_cont:
* This is called from here instead from PteUpdate to avoid unnecessary
* repetition while mapping non-contiguous physical regions of a virtual
* region */
- HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
+ HW_PWRST_IVA2RegGet(resources.dwPrmBase, temp);
+ if ((temp HW_PWR_STATE_ON) == HW_PWR_STATE_OFF) {
+ /* IVA domain is not in ON state*/
+ DBG_Trace(DBG_LEVEL7, temp value is 0x%x\n, temp);
+ CLK_Enable(SERVICESCLK_iva2_ck);
+ WakeDSP(pDevContext, NULL);
+ HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
+ CLK_Disable(SERVICESCLK_iva2_ck);
+ } else
+ HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
DBG_Trace(DBG_ENTER, WMD_BRD_MemMap status %x\n, status);
return status;
}
@@ -1564,6 +1579,7 @@ static DSP_STATUS WMD_BRD_MemUnMap(struct WMD_DEV_CONTEXT
*hDevContext,
/* It is better to flush the TLB here, so that any stale old entries
* get flushed */
EXIT_LOOP:
+ IO_InterruptDSP2(pDevContext, MBX_PM_DSPWAKEUP);
HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
DBG_Trace(DBG_LEVEL1, WMD_BRD_MemUnMap vaCurr %x, pteAddrL1 %x
pteAddrL2 %x\n, vaCurr, pteAddrL1, pteAddrL2);
@@ -2048,6 +2064,7 @@ func_cont:
* repetition while mapping non-contiguous physical regions of a virtual
* region */
/* Waking up DSP before calling TLB Flush */
+ IO_InterruptDSP2(pDevContext, MBX_PM_DSPWAKEUP);
HW_MMU_TLBFlushAll(pDevContext-dwDSPMmuBase);
DBG_Trace(DBG_LEVEL7, WMD_BRD_MemMap at end status %x\n, status);
return status;
--
1.5.3.2
--
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: [REVIEW PATCH 04/14] OMAP: CAM: Add ISP user header and register defs
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@infradead.org]
Sent: Tuesday, January 13, 2009 2:42 PM
To: Aguirre Rodriguez, Sergio Alberto
Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org; video4linux-
l...@redhat.com; Sakari Ailus; Tuukka.O Toivonen; Nagalla, Hari
Subject: Re: [REVIEW PATCH 04/14] OMAP: CAM: Add ISP user header and
register defs
On Mon, 12 Jan 2009 20:03:15 -0600
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com wrote:
+/* ISP Private IOCTLs */
+#define VIDIOC_PRIVATE_ISP_CCDC_CFG\
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 1, struct
ispccdc_update_config)
+#define VIDIOC_PRIVATE_ISP_PRV_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 2, struct ispprv_update_config)
+#define VIDIOC_PRIVATE_ISP_AEWB_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 4, struct isph3a_aewb_config)
+#define VIDIOC_PRIVATE_ISP_AEWB_REQ \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 5, struct isph3a_aewb_data)
+#define VIDIOC_PRIVATE_ISP_HIST_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct isp_hist_config)
+#define VIDIOC_PRIVATE_ISP_HIST_REQ \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 7, struct isp_hist_data)
+#define VIDIOC_PRIVATE_ISP_AF_CFG \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 8, struct af_configuration)
+#define VIDIOC_PRIVATE_ISP_AF_REQ \
+ _IOWR('V', BASE_VIDIOC_PRIVATE + 9, struct isp_af_data)
Are those new ioctl meant to be used by the userspace API? If so, we need
to
understand each one, since maybe some of them make some sense to be in the
public API. Also, a proper documentation should be provided for all of
those
ioctls.
Yes, this Private IOCTLs that we added to the driver are currently being used
by some of our customers by their userspace applications that contain algos for
performing Auto Focus, AutoExposure, Auto White Balance, and some other gain
table programming into the driver. A description of each one is shown below:
OMAP3 ISP driver Private IOCTLs explanation
- VIDIOC_PRIVATE_ISP_CCDC_CFG: Configures the OMAP3 ISP CCDC module settings
contained in struct ispccdc_update_config (defined in
arch/arm/plat-omap/include/mach/isp_user.h).
/**
* ispccdc_update_config - Structure for CCDC configuration.
* @update: Specifies which CCDC registers should be updated.
* @flag: Specifies which CCDC functions should be enabled.
* @alawip: Enable/Disable A-Law compression.
* @bclamp: Black clamp control register.
* @blcomp: Black level compensation value for RGrGbB Pixels. 2's complement.
* @fpc: Number of faulty pixels corrected in the frame, address of FPC table.
* @cull: Cull control register.
* @colptn: Color pattern of the sensor.
* @lsc: Pointer to LSC gain table.
*/
struct ispccdc_update_config {
__u16 update;
__u16 flag;
enum alaw_ipwidth alawip;
struct ispccdc_bclamp *bclamp;
struct ispccdc_blcomp *blcomp;
struct ispccdc_fpc *fpc;
struct ispccdc_lsc_config *lsc_cfg;
struct ispccdc_culling *cull;
__u32 colptn;
__u8 *lsc;
};
- VIDIOC_PRIVATE_ISP_PRV_CFG: Configures the OMAP3 ISP Preview module settings
contained in struct ispprv_update_config (defined in
arch/arm/plat-omap/include/mach/isp_user.h).
/**
* struct ispprv_update_config - Structure for Preview Configuration (user).
* @update: Specifies which ISP Preview registers should be updated.
* @flag: Specifies which ISP Preview functions should be enabled.
* @yen: Pointer to luma enhancement table.
* @shading_shift: 3bit value of shift used in shading compensation.
* @prev_hmed: Pointer to structure containing the odd and even distance.
* between the pixels in the image along with the filter threshold.
* @prev_cfa: Pointer to structure containing the CFA interpolation table, CFA.
*format in the image, vertical and horizontal gradient threshold.
* @csup: Pointer to Structure for Chrominance Suppression coefficients.
* @prev_wbal: Pointer to structure for White Balance.
* @prev_blkadj: Pointer to structure for Black Adjustment.
* @rgb2rgb: Pointer to structure for RGB to RGB Blending.
* @prev_csc: Pointer to structure for Color Space Conversion from RGB-YCbYCr.
* @yclimit: Pointer to structure for Y, C Value Limit.
* @prev_dcor: Pointer to structure for defect correction.
* @prev_nf: Pointer to structure for Noise Filter
* @red_gamma: Pointer to red gamma correction table.
* @green_gamma: Pointer to green gamma correction table.
* @blue_gamma: Pointer to blue gamma correction table.
*/
struct ispprv_update_config {
__u16 update;
__u16 flag;
void *yen;
__u32 shading_shift;
struct ispprev_hmed *prev_hmed;
struct ispprev_cfa *prev_cfa;
struct ispprev_csup *csup;
struct ispprev_wbal *prev_wbal;
struct ispprev_blkadj *prev_blkadj;
struct ispprev_rgbtorgb *rgb2rgb;
Re: new PM branch available
Koen Kooi k.k...@student.utwente.nl writes: Op 13 jan 2009, om 22:51 heeft Kevin Hilman het volgende geschreven: Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 The bootlog on my rev C1D beagle looks suspicious: Hi Koen, Hmm, it looks like you're tree is missing the McBSP fix from Paul[1]. This patch made it in before v2.6.28-omap1 which the latest PM branch is based on, so I'm guessing you're not testing the latest PM branch. Kevin Texas Instruments X-Loader 1.4.2 (Dec 3 2008 - 23:20:13) Reading boot sector Booting from mmc U-Boot 2009.01-rc1-00102-g8ecaab3 (Jan 10 2009 - 13:56:28) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle board + LPDDR/NAND DRAM: 256 MB NAND: 256 MiB musb: using high speed In:serial Out: serial Err: serial Board revision: Cx Debug (GPIO6 datain): 0x0480 Hit any key to stop autoboot: 1 0 reading boot.scr ** Unable to read boot.scr from mmc 0:1 ** reading uImage 2556572 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Angstrom/2.6.28-pm1+gitrb5d11429 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2556508 Bytes = 2.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Uncompressing Linux done , booting the kernel. Linux version 2.6.28-omap1 (k...@dominion) (gcc version 4.2.1) #1 Sun Jan 11 18:52:51 CET 2009 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3 Beagle Board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c050be14, node_mem_map c054 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65024 pages, LIFO batch:15 Movable zone: 0 pages used for memmap OMAP3430 ES3.0 SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS2,115200n8 video=omapfb:vram:2M,vram: 4M,mode:640x...@60 omapfb.debug=y omap-dss.debug=y loglevel=10 omapfb.vram=4M,4M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Unknown boot option `omapfb.debug=y': ignoring Unknown boot option `omap-dss.debug=y': ignoring Unknown boot option `omapfb.vram=4M,4M': ignoring Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 1024 (order: 10, 4096 bytes) OMAP clockevent source: GPTIMER12 at 32768 Hz Console: colour dummy device 80x30 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 254336KB available (4712K code, 428K data, 188K init) Calibrating delay loop... 478.91 BogoMIPS (lpj=1867776) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 532 bytes regulator: core version 0.5 NET: Registered protocol family 16 Found NAND on CS0 Registering NAND on CS0 [ cut here ] WARNING: at arch/arm/mach-omap2/clock.c:1094 omap2_clk_register +0x24/0x3c() Modules linked in: [c003b824] (dump_stack+0x0/0x14) from [c005b180] (warn_on_slowpath +0x4c/0x68) [c005b134] (warn_on_slowpath+0x0/0x68) from [c00416a8] (omap2_clk_register+0x24/0x3c) r6:c04de968 r5:c04d82d8 r4:c04d8270 [c0041684] (omap2_clk_register+0x0/0x3c) from [c0048854] (clk_register+0x44/0xc8) [c0048810] (clk_register+0x0/0xc8) from [c00113ec] (omap2_mcbsp_init+0xc8/0x130) r7:c0469ded r6:0008 r5:c04d82d8 r4:c04d8270 [c0011324] (omap2_mcbsp_init+0x0/0x130) from [c00372d4] (do_one_initcall+0x64/0x198) [c0037270] (do_one_initcall+0x0/0x198) from [c0008718] (kernel_init +0x70/0xdc) [c00086a8] (kernel_init+0x0/0xdc) from [c005db54] (do_exit +0x0/0x6b4) r5: r4: ---[ end trace 1b75b31a2719ed1c ]--- [ cut here ] WARNING: at arch/arm/mach-omap2/clock.c:1094 omap2_clk_register +0x24/0x3c() Modules linked in: [c003b824] (dump_stack+0x0/0x14) from [c005b180] (warn_on_slowpath +0x4c/0x68) [c005b134]
Re: [PATCH] Don't scale voltage in C1 state
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: This patch prevents VDD1 and VDD2 to go to the lowest OPP when entering C1. It improves wakeup latency from 600us to about 50us. Now with signoff :) Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Thanks, pushing to PM branch. Kevin arch/arm/mach-omap2/pm34xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index b0b2188..87ef55e 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -1052,7 +1052,7 @@ static void __init configure_vc(void) OMAP3_PRM_VC_I2C_CFG_OFFSET); /* Setup voltctrl and other setup times */ - prm_write_mod_reg(OMAP3430_AUTO_RET | OMAP3430_AUTO_SLEEP, + prm_write_mod_reg(OMAP3430_AUTO_RET, OMAP3430_GR_MOD, OMAP3_PRM_VOLTCTRL_OFFSET); prm_write_mod_reg(OMAP3430_CLKSETUP_DURATION, OMAP3430_GR_MOD, -- 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 -- 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/1] OMAP gptimer based event monitor driver for oprofile
* Siarhei Siamashka siarhei.siamas...@nokia.com [090114 20:18]:
On Tuesday 13 January 2009 16:31:53 ext Tony Lindgren wrote:
Hi,
Looks OK in general, few comments below.
Once you're done with the changes, this should get posted to
linux-arm-ker...@lists.arm.linux.org.uk for review with linux-omap
list Cc'd.
Thanks a lot for a patch review. I just have a few questions before
resubmitting a fixed version.
[...]
+static int gptimer_start(void)
+{
+ u32 count = counter_config[0].count;
+ gptimer = omap_dm_timer_request();
+ BUG_ON(gptimer == NULL);
Maybe just return -ENODEV here instead BUG_ON? In theory you could
build a multi-omap kernel that works on multiple boards, and you
could have all timers used up on some boards.
OK
+ omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
+ if (request_irq(omap_dm_timer_get_irq(gptimer), gptimer_interrupt,
+ IRQF_DISABLED, oprofile gptimer, NULL) != 0) {
+ printk(KERN_ERR oprofile: unable to request gptimer IRQ\n);
+ return -1;
Could return something from errno.h here.
I grepped the kernel sources for 'request_irq' calls and they are not very
consistent about what to return in the case when it fails. But one of the
most common variants to handle this error is just to propagate error code
returned by 'request_irq' outside. Would it be ok?
Sure.
+ }
+
+ if (count 1)
+ count = 1;
+
+ omap_dm_timer_set_load_start(gptimer, 1, 0x - count);
+ omap_dm_timer_set_int_enable(gptimer, OMAP_TIMER_INT_OVERFLOW);
+ return 0;
+}
You might want to use omap_dm_timer_request_specific() instead, and
use a timer that's connected to WKUP domain. Otherwise you'll miss
timer events in off-while-idle and retention-while-idle.
Probably having timer events when idle is actually not desired. Ideally
oprofile should collect samples only when CPU is active and provide a
report which represents CPU usage more or less precisely. So maybe
CORE power domain suits better here?
I don't know, I guess you'll have to figure out what works best. Being
able to profile idle latencies would be very good data, as the wake-up
latencies from retention-while-idle and off-while-idle can be long.
Also 'common.c' from oprofile directory contains code under CONFIG_PM ifdef
and provides hooks supposedly for suspend and resume operations.
Yeah, well those are for suspend and resume. On omaps we can hit
retention or off mode during every idle loop if those features are
enabled in /sys/power. So if you have a gptimer running based on the
32KiHz source clock, and is in wake-up domain, you should be still able
to profile how long the off mode during idle took. From that point of
view using a gptimer is better than using the ARM cycle counter as the
whole ARM might be powered off during idle.
About 'omap_dm_timer_request_specific'. Would it be right to first try all the
timers from the suitable domain, and then try to get just any timer before
bailing out (to handle the case when most of the timers are already used)?
I suggest not to use GPTIMER12, as it's interrupt also gets triggered
by spurious interrupts. But maybe you can find some other timer that's
in the WKUP domain by reading the 34xx TRM.
Thanks, note about broken GPTIMER12 taken.
Note that you cannot use GPTIMER1 either, because it's used for the
system timer. I believe 24xx only has GPTIMER1 in the WKUP domain,
so you might want to use omap_dm_timer_request() if cpu_is_omap24xx().
Don't know if 2430 has more thant GPTIMER1 in WKUP domain.
IMHO there is little need to use this oprofile driver on OMAP2 chips at all
(except for testing purposes, which I actually also have done on OMAP2420
too prior to submitting initial revision of the patch). The hardware
performance counters work and do the job fine there. Supporting OMAP1 may
have some practical value.
OK
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Important changes, please read
* Tim Gardner tim.gard...@canonical.com [090114 18:42]: Tony Lindgren wrote: - We stop using source.mvista.com git tree, and only use the kernel.org git tree. There's no need for having two master trees, and kernel.org is the standard way to go. Big thanks to Monta Vista for hosting us for many years. The git path at http://vger.kernel.org/vger-lists.html#linux-omap needs to be changed. Good point. Also needs to be changed at: http://www.muru.com/linux/omap/README_OMAP_GIT Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
