RE: PM branch update: rebase to .31-rc, added omap_hwmod/omap_device
Kevin, I did some testing with the current PM branch and don't see this issue on SDP. I could not find the patch which fixes this issue. Can you please point us to the patch which fixes this issue? Regards, Teerth -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Wednesday, August 12, 2009 8:28 PM To: V, Hemanth Cc: linux-omap@vger.kernel.org Subject: Re: PM branch update: rebase to .31-rc, added omap_hwmod/omap_device Hemanth V heman...@ti.com writes: - Original Message - From: Kevin Hilman khil...@deeprootsystems.com Known problems: - network drivers and off-mode - various hangs when using off-while-idle and NFS-mounted rootfs - network drivers likely need some context save/restore support Kevin, was this known to work earlier. Could this be related to GPMC context save/restore. I wrote this based on some early testing of the latest PM branch, where I may of still had some bugs. But I also have not seen this in a while, so it may have been just a problem when I was reworking/reordering the context save/restore code. I decided to leave it in the 'known problems' list in case anyone else has seen it and because I didn't go back and re-test all the boards for this issue. I don't see any issues on SDP or EVM anymore, have you tested the current PM branch for this? 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 -- To unsubscribe from this list: send the line unsubscribe 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: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
On Wednesday 12 August 2009 14:48:33 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote: On Wed, 2009-08-12 at 13:45 +0200, ext Jarkko Nikula wrote: The threshold based transfer will cause that omap_pcm_pointer will loose a bit its accuracy. Probably irrelevant but still better to play safe at least over one kernel release before making it default. No, it doesn't loose accuracy =) It's as accurate with both modes. The difference is, that the other does things in bursts; In element mode it is kind of easy to estimate where the hardware actually in the playback case (aplay -f dat /dev/zero): omap_pcm_pointer returns 669, than the HW is around 669-512=157 (plus few samples). In threshold mode you only know that the HW is playing in between 0-512, 512-1024 somewhere. I know neither of these are accurate and these examples are quite oversimplified, but there is a difference and that difference is quite significant. that's called evolution rather than regression =) Note that evolution can also introduce regression... That's how things will be in the future =) I agree with you on this, since the threshold mode provides quite good power saving benefits. But on the other hand it would be still better to keep the element mode as default for at least one release cycle. If no report is coming about problems, than we can make the threshold mode for McBSP2 as the default -- Péter -- To unsubscribe from this list: send the line unsubscribe 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: pm: Fix error condition in _pwrdm_deps_lookup when pwrdm not found.
On Wed, 12 Aug 2009, Kevin Hilman wrote: Mike Chan m...@android.com writes: Check pwrdm_name instead of the address of a null struct when at the end of pwrdm_dep array. Reported-by: Paul Walmsley p...@pwsan.com Signed-off-by: Mike Chan m...@android.com Thanks, to keep it all together, I'll revert the original and merge this into a single patch. Great, then: Acked-by: Paul Walmsley p...@pwsan.com Kevin --- arch/arm/mach-omap2/powerdomain.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c index 0334609..02c1ef6 100644 --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch/arm/mach-omap2/powerdomain.c @@ -103,7 +103,7 @@ static struct powerdomain *_pwrdm_deps_lookup(struct powerdomain *pwrdm, } - if (!pd) + if (!pd-pwrdm_name) return ERR_PTR(-ENOENT); return pd-pwrdm; -- 1.5.4.5 - 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 2/2] DSPBRIDGE: Set VDD1 OPP1 while MPU initiated OFF mode
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Subject: [PATCH 2/2] DSPBRIDGE: Set VDD1 OPP1 while MPU initiated OFF mode
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Acked-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 7aa58d1..dfac5b6 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -292,8 +292,21 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext,
IN u32 dwCmd,
/* Turn off DSP Peripheral clocks */
status = DSP_PeripheralClocks_Disable(pDevContext, NULL);
- if (DSP_FAILED(status))
+ if (DSP_FAILED(status)) {
DBG_Trace(DBG_LEVEL7, SleepDSP- FAILED\n);
+ return status;
+ }
+#ifdef CONFIG_BRIDGE_DVFS
+ else if (targetPwrState == HW_PWR_STATE_OFF) {
+ struct dspbridge_platform_data *pdata =
+ omap_dspbridge_dev-dev.platform_data;
+ /*
+ * Set the OPP to low level before moving to OFF mode
+ */
+ if (pdata-dsp_set_min_opp)
+ (*pdata-dsp_set_min_opp)(VDD1_OPP1);
+ }
+#endif /* CONFIG_BRIDGE_DVFS */
}
#endif /* CONFIG_PM */
return status;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] DSPBRIDGE: Cleanup SleepDSP
From: Ameya Palande [mailto:ameya.pala...@nokia.com]
Subject: [PATCH 1/2] DSPBRIDGE: Cleanup SleepDSP
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
[omar ramirez: avoid saving mailbox settings while setting a contraint]
Acked-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 33 ++
1 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index b81df8c..7aa58d1 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -204,20 +204,21 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext,
IN u32 dwCmd,
struct CFG_HOSTRES resources;
struct DEH_MGR *hDehMgr;
u16 usCount = TIHELEN_ACKTIMEOUT;
- enum HW_PwrState_t pwrState;
- enum HW_PwrState_t targetPwrState;
+ enum HW_PwrState_t pwrState, targetPwrState;
- status = CFG_GetHostResources(
- (struct CFG_DEVNODE *)DRV_GetFirstDevExtension(), resources);
- if (DSP_FAILED(status))
- return status;
DBG_Trace(DBG_LEVEL7, SleepDSP- Enter function \n);
- /* next, check if sleep code is valid... */
+ /* Check if sleep code is valid */
if ((dwCmd != PWR_DEEPSLEEP) (dwCmd != PWR_EMERGENCYDEEPSLEEP)) {
DBG_Trace(DBG_LEVEL7, SleepDSP- Illegal sleep command\n);
return DSP_EINVALIDARG;
}
+
+ status = CFG_GetHostResources(
+ (struct CFG_DEVNODE *)DRV_GetFirstDevExtension(), resources);
+ if (DSP_FAILED(status))
+ return status;
+
switch (pDevContext-dwBrdState) {
case BRD_RUNNING:
status = HW_MBOX_saveSettings(resources.dwMboxBase);
@@ -245,7 +246,6 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext,
IN u32 dwCmd,
break;
case BRD_HIBERNATION:
case BRD_DSP_HIBERNATION:
- status = HW_MBOX_saveSettings(resources.dwMboxBase);
/* Already in Hibernation, so just return */
DBG_Trace(DBG_LEVEL7, SleepDSP- DSP already in
hibernation\n);
@@ -259,17 +259,22 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext,
IN u32 dwCmd,
SleepDSP- Bridge in Illegal state\n);
return DSP_EFAIL;
}
+
/* Get the PRCM DSP power domain status */
HW_PWR_IVA2StateGet(resources.dwPrmBase, HW_PWR_DOMAIN_DSP,
- pwrState);
- /* Wait for DSP to move into Standby state, how much time
- * should we wait?*/
+ pwrState);
+
+ /*
+ * Wait for DSP to move into Standby state, how much time
+ * should we wait?
+ */
while ((pwrState != targetPwrState) --usCount) {
udelay(500);
HW_PWR_IVA2StateGet(resources.dwPrmBase, HW_PWR_DOMAIN_DSP,
pwrState);
}
- if (usCount == 0) {
+
+ if (!usCount) {
DBG_Trace(DBG_LEVEL7, SleepDSP: Timed out Waiting for DSP
STANDBY %x \n, pwrState);
DEV_GetDehMgr(pDevContext-hDevObject, hDehMgr);
@@ -278,17 +283,19 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext,
IN u32 dwCmd,
} else {
DBG_Trace(DBG_LEVEL7, SleepDSP: DSP STANDBY Pwr state %x \n,
pwrState);
+
/* Update the Bridger Driver state */
if (enable_off_mode)
pDevContext-dwBrdState = BRD_HIBERNATION;
else
pDevContext-dwBrdState = BRD_RETENTION;
+
/* Turn off DSP Peripheral clocks */
status = DSP_PeripheralClocks_Disable(pDevContext, NULL);
if (DSP_FAILED(status))
DBG_Trace(DBG_LEVEL7, SleepDSP- FAILED\n);
}
-#endif
+#endif /* CONFIG_PM */
return status;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What does the DSPBRIDGE do?
Hi, I was wondering what the DSPBRIDGE does? I've used TI code composer studio in the past, and was wondering if that compiler is required to compile programs for the DSP available on the TI OMAP 3530. In terms of compiler infrastructure, can the current arm gcc tools be used for both the arm core and the dsp part? Or do you need to use TI CCS for the dsp part? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] OMAP3: update OMAP3 Beagle defconfig, v2
* Felipe Balbi m...@felipebalbi.com [090812 22:11]: On Wed, Aug 12, 2009 at 10:20:34AM -0700, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: * Felipe Balbi felipe.ba...@nokia.com [090812 15:29]: Hi, On Wed, Aug 12, 2009 at 02:24:15PM +0200, ext Tony Lindgren wrote: From: Paul Walmsley p...@pwsan.com Update the OMAP3 Beagle defconfig to add EHCI, MMC, TWL4030 GPIO support. Beagle can again use MMC rootfs after this patch. Tested on BeagleBoard rev C2. snip @@ -981,10 +987,11 @@ CONFIG_RTC_INTF_DEV=y # # Voltage and Current regulators # -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y # CONFIG_REGULATOR_FIXED_VOLTAGE is not set # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_BQ24022 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set musb will still fail here if we don't have twl4030-usb enabled. could you updated the patch to add that as well ?? Updated. Maybe take a look and see if the USB options make sense to you? I could not enable OTG for some reason.. Probably because OTG depends on CONFIG_PM I think. correct I don't have a Beagle, so somebody please check this defconfig and enable PM and OTG if possible. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/6] ARM: OMAP4: PM: Fix the PRM and CM base addresses
-Original Message-
From: Aguirre Rodriguez, Sergio Alberto
Sent: Wednesday, August 12, 2009 9:15 PM
To: Nayak, Rajendra; linux-arm-ker...@lists.arm.linux.org.uk
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra
Subject: RE: [PATCH v2 1/6] ARM: OMAP4: PM: Fix the PRM and CM
base addresses
Rajendra,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Rajendra Nayak
Sent: Wednesday, August 12, 2009 9:27 AM
To: linux-arm-ker...@lists.arm.linux.org.uk
Cc: linux-omap@vger.kernel.org; Nayak, Rajendra
Subject: [PATCH v2 1/6] ARM: OMAP4: PM: Fix the PRM and CM
base addresses
This patch fixes the PRM and CM base addresses and adds
a new CM2 base address for OMAP4
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/prcm.c |2 ++
arch/arm/plat-omap/common.c|2 ++
arch/arm/plat-omap/include/mach/common.h |1 +
arch/arm/plat-omap/include/mach/omap44xx.h |6 --
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..de307fa 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -27,6 +27,7 @@
static void __iomem *prm_base;
static void __iomem *cm_base;
+static void __iomem *cm2_base;
u32 omap_prcm_get_reset_sources(void)
{
@@ -124,4 +125,5 @@ void __init
omap2_set_globals_prcm(struct omap_globals
*omap2_globals)
{
prm_base = omap2_globals-prm;
cm_base = omap2_globals-cm;
+cm2_base = omap2_globals-cm2;
}
diff --git a/arch/arm/plat-omap/common.c
b/arch/arm/plat-omap/common.c
index ebcf006..e848a12 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -372,12 +372,14 @@ static struct omap_globals omap4_globals = {
.ctrl = OMAP2_IO_ADDRESS(OMAP443X_CTRL_BASE),
.prm= OMAP2_IO_ADDRESS(OMAP4430_PRM_BASE),
.cm = OMAP2_IO_ADDRESS(OMAP4430_CM_BASE),
+.cm2= OMAP2_IO_ADDRESS(OMAP4430_CM2_BASE),
};
void __init omap2_set_globals_443x(void)
{
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
+omap2_set_globals_prcm(omap4_globals);
}
#endif
diff --git a/arch/arm/plat-omap/include/mach/common.h
b/arch/arm/plat-
omap/include/mach/common.h
index fdeab42..878c4f9 100644
--- a/arch/arm/plat-omap/include/mach/common.h
+++ b/arch/arm/plat-omap/include/mach/common.h
@@ -55,6 +55,7 @@ struct omap_globals {
void __iomem*ctrl; /* System Control Module */
void __iomem*prm; /* Power and Reset Management */
void __iomem*cm;/* Clock Management */
+void __iomem*cm2;
};
void omap2_set_globals_242x(void);
diff --git a/arch/arm/plat-omap/include/mach/omap44xx.h
b/arch/arm/plat-
omap/include/mach/omap44xx.h
index 15dec7f..b46b154 100644
--- a/arch/arm/plat-omap/include/mach/omap44xx.h
+++ b/arch/arm/plat-omap/include/mach/omap44xx.h
@@ -23,8 +23,10 @@
#define L4_EMU_44XX_BASE0x5400
#define L3_44XX_BASE0x4400
#define OMAP4430_32KSYNCT_BASE 0x4a304000
-#define OMAP4430_CM_BASE0x4a004000
-#define OMAP4430_PRM_BASE 0x48306000
+#define OMAP4430_CM1_BASE 0x4a004000
+#define OMAP4430_CM_BASEOMAP4430_CM1_BASE
Why do you need 2 defines for the same value?
Hi Sergio,
PRCM had just one CM module in OMAP2/3 and OMAP4 has
2 of them , CM1 and CM2. The older CM defines are now mapped to CM1
for OMAP4 and new ones created for CM2.
regards,
Rajendra
Regards,
Sergio
+#define OMAP4430_CM2_BASE 0x4a008000
+#define OMAP4430_PRM_BASE 0x4a306000
#define OMAP44XX_GPMC_BASE 0x5000
#define OMAP443X_SCM_BASE 0x4a002000
#define OMAP443X_CTRL_BASE OMAP443X_SCM_BASE
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe
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 v2 5/6] ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4
-Original Message- From: Aguirre Rodriguez, Sergio Alberto Sent: Wednesday, August 12, 2009 11:11 PM To: Nayak, Rajendra; linux-arm-ker...@lists.arm.linux.org.uk Cc: linux-omap@vger.kernel.org Subject: RE: [PATCH v2 5/6] ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4 Rajendra, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Nayak, Rajendra Sent: Wednesday, August 12, 2009 9:28 AM To: linux-arm-ker...@lists.arm.linux.org.uk Cc: linux-omap@vger.kernel.org; Nayak, Rajendra Subject: [PATCH v2 5/6] ARM: OMAP4: PM: Adds CM1/2 register defs for OMAP4 This patch adds OMAP4 specific CM1 and CM2 module register defs and corresponding register field bit shifts Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/cm.h | 249 +- arch/arm/mach-omap2/cm1-regbits-44xx.h | 161 +++ arch/arm/mach-omap2/cm2-regbits-44xx.h | 269 3 files changed, 678 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/cm1-regbits-44xx.h create mode 100644 arch/arm/mach-omap2/cm2-regbits-44xx.h diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h index 1d3c93b..19f7aeb 100644 --- a/arch/arm/mach-omap2/cm.h +++ b/arch/arm/mach-omap2/cm.h @@ -4,10 +4,11 @@ /* * OMAP2/3 Clock Management (CM) register definitions According to the new content, this should be updated aswell, like: OMAP2/3/4 Clock Management (CM) register definitions Yes, I'll update that, thanks. Regards, Sergio snip -- To unsubscribe from this list: send the line unsubscribe 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 8/9] OMAP2: add board file for Nokia N800 and N810
On Tue, Aug 11, 2009 at 12:55:58PM +0300, Tony Lindgren wrote:
+#include mach/gpio.h
linux/gpio.h
+#include mach/io.h
linux/io.h
+static struct musb_hdrc_platform_data tusb_data = {
+ .mode = BOARD_MODE,
+ .set_power = tusb_set_power,
+ .set_clock = tusb_set_clock,
+ .min_power = 25, /* x2 = 50 mA drawn from VBUS as peripheral */
+ .power = 100, /* Max 100 mA VBUS for host mode */
+ .clock = osc_ck,
Still passing clock names around?
--
To unsubscribe from this list: send the line unsubscribe 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/9] OMAP: remove OMAP_TAG_SERIAL_CONSOLE
On Tue, Aug 11, 2009 at 12:46:31PM +0300, Tony Lindgren wrote: From: Kalle Valo kalle.v...@iki.fi Omap tags are deprecated and remove OMAP_TAG_SERIAL_CONSOLE. Console must be enabled with the console boot parameter instead. Ok. -- To unsubscribe from this list: send the line unsubscribe 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/9] OMAP: remove OMAP_TAG_UART
On Tue, Aug 11, 2009 at 12:47:56PM +0300, Tony Lindgren wrote: From: Kalle Valo kalle.v...@iki.fi Omap tags are deprecrated and convert all OMAP_TAG_UART cases to use omap_uart_platform_data instead. Ok. -- To unsubscribe from this list: send the line unsubscribe 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/9] OMAP: Remove omap boot parsing code
On Tue, Aug 11, 2009 at 12:49:15PM +0300, Tony Lindgren wrote: From: Roger Quadros ext-roger.quad...@nokia.com Remove left over code for parsing omap boot tags. This is no longer used. see commit fc0ef1bfa1353e048e055374a09c75320d22231b Ok. -- To unsubscribe from this list: send the line unsubscribe 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/9] OMAP: GPIO: Avoid generating extra IRQs
On Tue, Aug 11, 2009 at 12:50:32PM +0300, Tony Lindgren wrote: From: Eero Nurkkala ext-eero.nurkk...@nokia.com It is possible for GPIO IRQ lines configured with falling edge triggering only to get IRQs at the rising edge upon the exit of offmode. And vice versa. Prevent such IRQs to arrive by generating the IRQ obeying the detection scheme. Ok. -- To unsubscribe from this list: send the line unsubscribe 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/9] OMAP2: compile usb-tusb6010.c
On Tue, Aug 11, 2009 at 12:54:39PM +0300, Tony Lindgren wrote: From: Kalle Valo kalle.v...@iki.fi For some reason usb-tusb6010.c was't compiled, add it to Makefile and Kconfig. This is prepraration for upcoming n8x0 support. Ok. -- To unsubscribe from this list: send the line unsubscribe 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 9/9] OMAP2: n8x0: add n8x0_defconfig
On Tue, Aug 11, 2009 at 12:57:16PM +0300, Tony Lindgren wrote: From: Kalle Valo kalle.v...@iki.fi Add defconfig file for OMAP2 N800 and N810 devices. Ok. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] OMAP: iommu: fix wrong argument in flush_cache_vmap()
On Wed, Aug 12, 2009 at 03:12:00PM +0300, Tony Lindgren wrote: From: Hiroshi DOYU hiroshi.d...@nokia.com The second argument should be the end address, not the length. Actually there will not be any effect on the behavior of this driver since flush_cache_vmap() calls flush_cache_all() in the end. Ok. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] OMAP: iommu: add initial debugfs support
On Wed, Aug 12, 2009 at 03:13:24PM +0300, Tony Lindgren wrote: +static DEFINE_MUTEX(iommu_debug_lock); +static char local_buffer[SZ_4K]; I don't like this - what if the data you're sprintf'ing into this buffer overflows it? -- To unsubscribe from this list: send the line unsubscribe 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 04/10] OMAP3: 3430SDP: Fix defconfig
On Wed, Aug 12, 2009 at 03:16:00PM +0300, Tony Lindgren wrote: From: Sergio Aguirre saagui...@ti.com This patch makes the SDP boot again with the defconfig. Ok. -- To unsubscribe from this list: send the line unsubscribe 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 05/10] OMAP3: rx51_defconfig: add twl4030 to rx51 default configuration
On Wed, Aug 12, 2009 at 03:17:24PM +0300, Tony Lindgren wrote: From: Timo Kokkonen timo.t.kokko...@nokia.com twl4030 watchdog will be compiled as a module by default. Ok. -- To unsubscribe from this list: send the line unsubscribe 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 06/10] OMAP3: MMC: Add mux for pins
On Wed, Aug 12, 2009 at 03:18:49PM +0300, Tony Lindgren wrote:
+ if (mmc_controller-slots[0].wires == 8)
+ printk(KERN_WARNING
+ \n MMC2: DAT4, DAT5, DAT6, DAT7:
+ Setup the mux in board file);
+ }
+ if (controller_nr == 2) {
+ /* MMC3 */
+ printk(KERN_WARNING
+ \n MMC3: Setup the mux in board file:
+ Multiple options exist, so is board specific);
+ }
Having printks which issue a level, followed by a newline, message and
omitting the newline at the end looks really wrong:
- firstly, the KERN_WARNING \n line creates a blank line in the kernel
message log.
- the message itself will be at the kernels default message level
- the following kernel message will be appended to the end, with any
level tag exposed.
So I think the above printk statements are completely wrong and broken.
--
To unsubscribe from this list: send the line unsubscribe 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 07/10] OMAP3: Zoom2: Add TWL4030 support
On Wed, Aug 12, 2009 at 03:20:07PM +0300, Tony Lindgren wrote:
+static struct twl4030_keypad_data zoom2_kp_twl4030_data = {
+ .rows = 8,
+ .cols = 8,
+ .keymap = zoom2_twl4030_keymap,
+ .keymapsize = ARRAY_SIZE(zoom2_twl4030_keymap),
+ .rep= 1,
+};
Normally have a blank line here.
static void __init omap_zoom2_init_irq(void)
{
omap2_init_common_hw(NULL);
Otherwise ok.
--
To unsubscribe from this list: send the line unsubscribe 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 08/10] OMAP3: Zoom2: Update board defconfig
On Wed, Aug 12, 2009 at 03:21:25PM +0300, Tony Lindgren wrote: From: Vikram Pandita vikram.pand...@ti.com Update defconfig for Zoom2 to include TWL4030 core TWL4030 drivers (bci, gpio, keypad, usb, mmc) Ok. -- To unsubscribe from this list: send the line unsubscribe 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 09/10] OMAP3: beagle: add missing twl4030 usb platform_data
On Wed, Aug 12, 2009 at 03:22:51PM +0300, Tony Lindgren wrote: From: Felipe Balbi felipe.ba...@nokia.com without it twl4030_usb driver will not probe. Ok. -- To unsubscribe from this list: send the line unsubscribe 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: What does the DSPBRIDGE do?
Hi Vladimir, On Aug 13, 2009, at 11:41 AM, Vladimir Pantelic wrote: Elvis Dowson wrote: Hi, I was wondering what the DSPBRIDGE does? it allows the arm to load/run code on the dsp And this code would be compiled and linked using the ti dsp compiler? what role will the arm gcc compiler play, when using ti dsp compiler? Are there some examples this? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe 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: What does the DSPBRIDGE do?
ext Elvis Dowson wrote: Hi, I was wondering what the DSPBRIDGE does? It is an interface between ARM core and DSP core. You can use the bridge to load firmware into DSP, control its execution and allow data communication, e.g. MP3 stream input and PCM data output. I've used TI code composer studio in the past, and was wondering if that compiler is required to compile programs for the DSP available on the TI OMAP 3530. In terms of compiler infrastructure, can the current arm gcc tools be used for both the arm core and the dsp part? Or do you need to use TI CCS for the dsp part? you need separate compiler (i.e. CCS) to build code for DSP (i.e. CODECs). DSP will have C5000 or C6000 core (C64x in case of 3530) and not ARM core. ARM gcc is used only to build the Linux DSPbridge driver. Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe 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: What does the DSPBRIDGE do?
Hi Elvis, ext Elvis Dowson wrote: Hi Vladimir, On Aug 13, 2009, at 11:41 AM, Vladimir Pantelic wrote: Elvis Dowson wrote: Hi, I was wondering what the DSPBRIDGE does? it allows the arm to load/run code on the dsp And this code would be compiled and linked using the ti dsp compiler? what role will the arm gcc compiler play, when using ti dsp compiler? Are there some examples this? Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I guess you need TI compiler only for compiling Codes which run on DSP, rest of the stuff can be compiled using arm-gcc. 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: [PATCHv2 1/8] Regulator: Add TPS65023 regulator driver
On Wed, 2009-08-12 at 10:17 +0530, Anuj Aggarwal wrote:
Adding support for TI TPS65023 regulator driver
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
---
drivers/regulator/tps65023-regulator.c | 638
1 files changed, 638 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/tps65023-regulator.c
diff --git a/drivers/regulator/tps65023-regulator.c
b/drivers/regulator/tps65023-regulator.c
new file mode 100644
index 000..dbaf295
--- /dev/null
+++ b/drivers/regulator/tps65023-regulator.c
@@ -0,0 +1,638 @@
+/*
+ * tps65023-regulator.c
+ *
+ * Supports TPS65023 Regulator
+ *
+ * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any kind,
+ * whether express or implied; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+
+/* Register definitions */
+#define TPS65023_REG_VERSION0
+#define TPS65023_REG_PGOODZ 1
+#define TPS65023_REG_MASK 2
+#define TPS65023_REG_REG_CTRL 3
+#define TPS65023_REG_CON_CTRL 4
+#define TPS65023_REG_CON_CTRL2 5
+#define TPS65023_REG_DEF_CORE 6
+#define TPS65023_REG_DEFSLEW7
+#define TPS65023_REG_LDO_CTRL 8
+
+/* PGOODZ bitfields */
+#define TPS65023_PGOODZ_PWRFAILZBIT(7)
+#define TPS65023_PGOODZ_LOWBATTZBIT(6)
+#define TPS65023_PGOODZ_VDCDC1 BIT(5)
+#define TPS65023_PGOODZ_VDCDC2 BIT(4)
+#define TPS65023_PGOODZ_VDCDC3 BIT(3)
+#define TPS65023_PGOODZ_LDO2BIT(2)
+#define TPS65023_PGOODZ_LDO1BIT(1)
+
+/* MASK bitfields */
+#define TPS65023_MASK_PWRFAILZ BIT(7)
+#define TPS65023_MASK_LOWBATTZ BIT(6)
+#define TPS65023_MASK_VDCDC1BIT(5)
+#define TPS65023_MASK_VDCDC2BIT(4)
+#define TPS65023_MASK_VDCDC3BIT(3)
+#define TPS65023_MASK_LDO2 BIT(2)
+#define TPS65023_MASK_LDO1 BIT(1)
+
+/* REG_CTRL bitfields */
+#define TPS65023_REG_CTRL_VDCDC1_EN BIT(5)
+#define TPS65023_REG_CTRL_VDCDC2_EN BIT(4)
+#define TPS65023_REG_CTRL_VDCDC3_EN BIT(3)
+#define TPS65023_REG_CTRL_LDO2_ENBIT(2)
+#define TPS65023_REG_CTRL_LDO1_ENBIT(1)
+
+/* LDO_CTRL bitfields */
+#define TPS65023_LDO_CTRL_LDOx_SHIFT(ldo_id) ((ldo_id)*4)
+#define TPS65023_LDO_CTRL_LDOx_MASK(ldo_id) (0xF0 ((ldo_id)*4))
+
+/* Number of step-down converters available */
+#define TPS65023_NUM_DCDC3
+/* Number of LDO voltage regulators available */
+#define TPS65023_NUM_LDO 2
+/* Number of total regulators available */
+#define TPS65023_NUM_REGULATOR (TPS65023_NUM_DCDC + TPS65023_NUM_LDO)
+
+/* DCDCs */
+#define TPS65023_DCDC_1 0
+#define TPS65023_DCDC_2 1
+#define TPS65023_DCDC_3 2
+/* LDOs */
+#define TPS65023_LDO_1 3
+#define TPS65023_LDO_2 4
+
+#define TPS65023_MAX_REG_ID TPS65023_LDO_2
+
+/* Supported voltage values for regulators */
+static const u16 VDCDC1_VSEL_table[] = {
+ 800, 825, 850, 875,
+ 900, 925, 950, 975,
+ 1000, 1025, 1050, 1075,
+ 1100, 1125, 1150, 1175,
+ 1200, 1225, 1250, 1275,
+ 1300, 1325, 1350, 1375,
+ 1400, 1425, 1450, 1475,
+ 1500, 1525, 1550, 1600,
+};
+
+static const u16 LDO1_VSEL_table[] = {
+ 1000, 1100, 1300, 1800,
+ 2200, 2600, 2800, 3150,
+};
+
+static const u16 LDO2_VSEL_table[] = {
+ 1050, 1200, 1300, 1800,
+ 2500, 2800, 3000, 3300,
+};
+
+static unsigned int num_voltages[] = {ARRAY_SIZE(VDCDC1_VSEL_table),
+ 0, 0, ARRAY_SIZE(LDO1_VSEL_table),
+ ARRAY_SIZE(LDO2_VSEL_table)};
+
+/* Regulator specific details */
+struct tps_info {
+ const char *name;
+ unsigned min_uV;
+ unsigned max_uV;
+ bool fixed;
+ u8 table_len;
+ const u16 *table;
+};
+
+/* PMIC details */
+struct tps_pmic {
+ struct regulator_desc desc[TPS65023_NUM_REGULATOR];
+ struct i2c_client *client;
+ struct regulator_dev *rdev[TPS65023_NUM_REGULATOR];
+ const struct tps_info
Re: [PATCH] OMAP: Store reboot mode in scratchpad on OMAP34xx
Tony Lindgren t...@atomide.com writes:
* Juha Yrjola juha.yrj...@solidboot.com [090308 10:20]:
The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.
Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
---
arch/arm/mach-omap2/prcm.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..2bd239e 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,9 +43,15 @@ void omap_prcm_arch_reset(char mode)
if (cpu_is_omap24xx())
prcm_offs = WKUP_MOD;
-else if (cpu_is_omap34xx())
+else if (cpu_is_omap34xx()) {
+u32 l;
+
prcm_offs = OMAP3430_GR_MOD;
-else
+l = ('B' 24) | ('M' 16) | mode;
+/* Reserve the first word in scratchpad for communicating
+ * with the boot ROM. */
+omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+} else
WARN_ON(1);
prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
Looks OK to me, any comments from Kevin or Paul?
Acked-by: Kevin Hilman khil...@deeprootsystems.com
I've had this one in the PM branch for awhile now I think can go upstream.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Store reboot mode in scratchpad on OMAP34xx
On Thu, 13 Aug 2009, Kevin Hilman wrote:
Tony Lindgren t...@atomide.com writes:
* Juha Yrjola juha.yrj...@solidboot.com [090308 10:20]:
The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.
Signed-off-by: Juha Yrjola juha.yrj...@solidboot.com
---
arch/arm/mach-omap2/prcm.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..2bd239e 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,9 +43,15 @@ void omap_prcm_arch_reset(char mode)
if (cpu_is_omap24xx())
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx())
+ else if (cpu_is_omap34xx()) {
+ u32 l;
+
prcm_offs = OMAP3430_GR_MOD;
- else
+ l = ('B' 24) | ('M' 16) | mode;
+ /* Reserve the first word in scratchpad for communicating
+ * with the boot ROM. */
+ omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ } else
WARN_ON(1);
prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
Looks OK to me, any comments from Kevin or Paul?
Acked-by: Kevin Hilman khil...@deeprootsystems.com
I've had this one in the PM branch for awhile now I think can go upstream.
The omap_writel() should be nuked and replaced that with an
omap_ctrl_write(). Other than that, I don't have any comment on it...
- 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: Linux-omap PM: Fix dead lock condition in resource_release(vdd1_opp)
Wang Limei-E12499 e12...@motorola.com writes:
Kevin and Romit,
I agreed with you, thanks Kevin and Romit for the comments! Chunqiu
Wang coded resource-based mutex, below is the patch. Pls review and let
us know your feedback.
From 31f87ffb8eb1f854a9adb7fd96011d490f4655fa Mon Sep 17 00:00:00 2001
From: Chunqiu Wang cqw...@motorola.com
Date: Wed, 12 Aug 2009 16:22:09 +0800
Subject: [PATCH] Fix resource framework mutex lock issue when
resource_get or resource_release are called nestedly.
Could use a shorter summary (subject) and a more detailed changelog.
This patch is doing too many things in a single patch without enough
explanation.
Not only does it convert the global semaphore to a resource-specific
semaphore, but it also changing the locking slightly by moving some
things in/out of lock protection. That should be described in the
changelog as well.
Even better would be a first patch that simply converts the semaphore
to a resource-specific *mutex* (not resource-specific semaphore.) IOW,
use mutex API in linux/mutex.h:
struct mutex;
init_mutex()
mutex_lock()
mutex_unlock()
mutex_is_lockec()
...
Then, add a 2nd patch which does any reworking of the critical sections.
Kevin
Signed-off-by: Chunqiu Wang cqw...@motorola.com
---
arch/arm/plat-omap/include/mach/resource.h |2 +
arch/arm/plat-omap/resource.c | 38
+--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/resource.h
b/arch/arm/plat-omap/include/mach/resource.h
index f91d8ce..389cb67 100644
--- a/arch/arm/plat-omap/include/mach/resource.h
+++ b/arch/arm/plat-omap/include/mach/resource.h
@@ -22,6 +22,7 @@
#include linux/list.h
#include linux/mutex.h
+#include linux/semaphore.h
#include linux/device.h
#include mach/cpu.h
@@ -46,6 +47,7 @@ struct shared_resource {
/* Shared resource operations */
struct shared_resource_ops *ops;
struct list_head node;
+ struct semaphore resource_mutex;
};
struct shared_resource_ops {
diff --git a/arch/arm/plat-omap/resource.c
b/arch/arm/plat-omap/resource.c
index ec31727..758a138 100644
--- a/arch/arm/plat-omap/resource.c
+++ b/arch/arm/plat-omap/resource.c
@@ -264,6 +264,7 @@ int resource_register(struct shared_resource *resp)
return -EEXIST;
INIT_LIST_HEAD(resp-users_list);
+ sema_init(resp-resource_mutex, 1);
down(res_mutex);
/* Add the resource to the resource list */
@@ -326,14 +327,14 @@ int resource_request(const char *name, struct
device *dev,
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_request: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ down(resp-resource_mutex);
/* Call the resource specific validate function */
if (resp-ops-validate_level) {
ret = resp-ops-validate_level(resp, level);
@@ -361,16 +362,12 @@ int resource_request(const char *name, struct
device *dev,
}
user-level = level;
+ /* Recompute and set the current level for the resource */
+ ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
- /*
- * Recompute and set the current level for the resource.
- * NOTE: update_resource level moved out of spin_lock, as it may
call
- * pm_qos_add_requirement, which does a kzmalloc. This won't be
allowed
- * in iterrupt context. The spin_lock still protects add/remove
users.
- */
- if (!ret)
- ret = update_resource_level(resp);
+ up(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_request);
@@ -393,14 +390,14 @@ int resource_release(const char *name, struct
device *dev)
struct users_list *user;
int found = 0, ret = 0;
- down(res_mutex);
- resp = _resource_lookup(name);
+ resp = resource_lookup(name);
if (!resp) {
printk(KERN_ERR resource_release: Invalid resource
name\n);
ret = -EINVAL;
- goto res_unlock;
+ goto ret;
}
+ down(resp-resource_mutex);
list_for_each_entry(user, resp-users_list, node) {
if (user-dev == dev) {
found = 1;
@@ -421,7 +418,9 @@ int resource_release(const char *name, struct device
*dev)
/* Recompute and set the current level for the resource */
ret = update_resource_level(resp);
res_unlock:
- up(res_mutex);
+ up(resp-resource_mutex);
+
+ret:
return ret;
}
EXPORT_SYMBOL(resource_release);
@@ -438,15 +437,14 @@ int resource_get_level(const char *name)
struct shared_resource *resp;
u32 ret;
-
RE: [PATCH v2 1/6] ARM: OMAP4: PM: Fix the PRM and CM base addresses
Rajendra, snip +#define OMAP4430_CM1_BASE 0x4a004000 +#define OMAP4430_CM_BASE OMAP4430_CM1_BASE Why do you need 2 defines for the same value? Hi Sergio, PRCM had just one CM module in OMAP2/3 and OMAP4 has 2 of them , CM1 and CM2. That I can understand... The older CM defines are now mapped to CM1 for OMAP4 and new ones created for CM2. Ok, but if you're trying to set that convention, IMHO either keep one or the another. For example, you can keep only this definition: #define OMAP4430_CM1_BASE 0x4a004000 And change in all the currently merged code from CM to CM1... Anyways, its just my thoughts... Of course you're free to take them or not. Thanks and Regards, Sergio regards, Rajendra Regards, Sergio +#define OMAP4430_CM2_BASE 0x4a008000 +#define OMAP4430_PRM_BASE 0x4a306000 #define OMAP44XX_GPMC_BASE0x5000 #define OMAP443X_SCM_BASE 0x4a002000 #define OMAP443X_CTRL_BASEOMAP443X_SCM_BASE -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe 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: PM branch update: rebase to .31-rc, added omap_hwmod/omap_device
Reddy, Teerth tee...@ti.com writes: I did some testing with the current PM branch and don't see this issue on SDP. Thanks for testing. I could not find the patch which fixes this issue. Can you please point us to the patch which fixes this issue? To be honest, I actually don't know which patch fixed the issue. I saw the problem during some early testing of the latest PM branch, and in the process of restructuring the tree it went away. More than likely, I had left out part of the series when reorganizing that caused this temporary problem. I think I'll remove it from the 'known problems' list as it appears to have been operator error on my part. Kevin -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Wednesday, August 12, 2009 8:28 PM To: V, Hemanth Cc: linux-omap@vger.kernel.org Subject: Re: PM branch update: rebase to .31-rc, added omap_hwmod/omap_device Hemanth V heman...@ti.com writes: - Original Message - From: Kevin Hilman khil...@deeprootsystems.com Known problems: - network drivers and off-mode - various hangs when using off-while-idle and NFS-mounted rootfs - network drivers likely need some context save/restore support Kevin, was this known to work earlier. Could this be related to GPMC context save/restore. I wrote this based on some early testing of the latest PM branch, where I may of still had some bugs. But I also have not seen this in a while, so it may have been just a problem when I was reworking/reordering the context save/restore code. I decided to leave it in the 'known problems' list in case anyone else has seen it and because I didn't go back and re-test all the boards for this issue. I don't see any issues on SDP or EVM anymore, have you tested the current PM branch for this? 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 -- To unsubscribe from this list: send the line unsubscribe 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: TI OMAP 3503 GPIO signal I/O standard for interfacing with FPGA
On Wed, Aug 12, 2009 at 10:13 AM, Elvis Dowsonelvis.dow...@mac.com wrote: Hi John, On Aug 12, 2009, at 4:54 PM, John Sarman wrote: Use LVCMOS at 1.8V if you can not use 1.8 V (get another FPGA, just kidding) then you will need a buffer (level translator) between them. Thanks for the info. I think I have support for LVCMOS at 1.8v on the Virtex-5. :-) BTW, what about the GPMC controller, does same signal I/O standard apply? LVCMOS Single ended standard IO for low power low voltage. LVTTL Single ended standard IO for compatiblity with older technologies, can sink souce more current and have higher voltage tolerances. HSTL differential pair, no good for GPMC SSTL SSTL_18 Series Stub Terminated, used with DDR II memory; requires Vddq = 1.8v, Vt = 0.5 x Vddq. Worth doing research to see if this would make sense for the GPMC. GTL is a backplane Ghz IO only swings to 1.2V PCI for interfacing with the PCI bus, so again probably not. I would look into SSTL if you are going to interface the FPGA with the OMAP as if the FPGA appears as a memory device. Not 100% sure though. snip from omap 35xx page General Purpose Memory Controller (GPMC) * 16-bit Wide Multiplexed Address/Data Bus * Up to 8 Chip Select Pins With 128M-Byte Address Space per Chip Select Pin * Glueless Interface to NOR Flash, NAND Flash (With ECC Hamming Code Calculation), SRAM and Pseudo-SRAM * Flexible Asynchronous Protocol Control for Interface to Custom Logic (FPGA, CPLD, ASICs, etc.) * Nonmultiplexed Address/Data Mode (Limited 2K-Byte Address Space) /snip from omap 35xx page John Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe 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: TI OMAP 3503 GPIO signal I/O standard for interfacing with FPGA
Hi John, On Aug 13, 2009, at 5:14 PM, John Sarman wrote: snip from omap 35xx page General Purpose Memory Controller (GPMC) * 16-bit Wide Multiplexed Address/Data Bus * Up to 8 Chip Select Pins With 128M-Byte Address Space per Chip Select Pin * Glueless Interface to NOR Flash, NAND Flash (With ECC Hamming Code Calculation), SRAM and Pseudo-SRAM * Flexible Asynchronous Protocol Control for Interface to Custom Logic (FPGA, CPLD, ASICs, etc.) * Nonmultiplexed Address/Data Mode (Limited 2K-Byte Address Space) /snip from omap 35xx page Thanks for the info, I've read that section on the GPMC. I'm going to attempt this in stages. First I'll implement a simple protocol between the OMAP and the FPGA, e.g. use GPIOs to signal read and write operations, and the serial UART0 to transfer data to a memory location for the FPGA to process and return the result. Since the TI OMAP uses 1.8v signalling, I can directly interface it with the Virtex-5 and get a simple prototype up and running. After that, create a TI OMAP GPMC to PLB v4.6 Bus Bridge, to make the GPMC requests appear in the FPGA PLB bus, so that it can access the FPGA devices and peripherals connected to the PLB bus. I'm using the gumstix Overo for these tests, and the GPMC signals are not available on the Palo43 or summit expansion boards. It is available on the Overo J4/J6 connector though, but that needs a custom board to bring those signals out. Do you know if any other TI OMAP 35xx development board exposes the GPMC connectors? I just want to finish the software/firmware part before starting work on a custom expansion board. Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe 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 4/6] ARM: OMAP4: PM: Adds PRM register shift and mask bits
Hello Rajendra, (These comments apply to your patches 4 through 6.) First, a couple of general comments: 1. These should be redone using a generator script and Benoit's hardware data. This will reduce the maintainer load to review future versions of this file as the hardware is revised. 2. To continue on the topic of redundancy from our earlier messages: in these patches, there is quite a lot of it in both register addresses and bit definitions. See for example the WKUPDEP register bits (SDMA, TESLA, MPU, etc). The initiators are repeated over and over again. Same with some of the register addresses. CLKCTRL, DYNAMICDEP, STATICDEP, for example, are often repeated. At least for the register addresses, what is your opinion about using a multi-level macro to separate these out, and reduce the number of definitions, as is done in the output of experimental_gen_prm44xx_h.py, for example? Then to use an addressing macro that would take multiple arguments, something like what is described in the autogen file kernel-templates/mach-omap2/cm_prefix.h ? Then, a few specific comments: 1. Please add _MASK at the end of all single-bit defines. This is so there is no ambiguity as to whether a macro is a shift count or a bitmask. So, for example, +#define OMAP4430_MEMIF_STATDEP (1 4) should be +#define OMAP4430_MEMIF_STATDEP_MASK(1 4) This is something that should have been done with the earliest OMAP2/3 macros. We are slowly converting the ones that don't follow this pattern. 2. The register bit defines should be organized by register and each group should be separated with a blank line and comment with the register name. This is the way it was done in the existing mach-omap2/*regbits*.h files. This makes the files much more readable. Here is an example from OMAP3: /* PM_PWSTCTRL_CORE specific bits */ #define OMAP3430_MEM2ONSTATE_SHIFT 18 #define OMAP3430_MEM2ONSTATE_MASK (0x3 18) #define OMAP3430_MEM1ONSTATE_SHIFT 16 #define OMAP3430_MEM1ONSTATE_MASK (0x3 16) #define OMAP3430_MEM2RETSTATE (1 9) #define OMAP3430_MEM1RETSTATE (1 8) /* PM_PWSTST_CORE specific bits */ #define OMAP3430_MEM2STATEST_SHIFT 6 #define OMAP3430_MEM2STATEST_MASK (0x3 6) #define OMAP3430_MEM1STATEST_SHIFT 4 #define OMAP3430_MEM1STATEST_MASK (0x3 4) etc. Yes, those MEM2RETSTATE, MEM1RETSTATE defines should be suffixed with _MASK. 3. There are duplicate macros that should be removed. If bits are shared among registers, they should be moved into a shared section and marked with a comment with the registers that share them. Again this is done in the previous mach-omap2/*regbits*.h files for OMAP2/3. Here are some examples of duplicate macros from the OMAP4 data you posted: +#define OMAP4430_DPLL_SSC_TYPE (1 15) +#define OMAP4430_DPLL_SSC_DOWNSPREAD (1 14) +#define OMAP4430_DPLL_SSC_ACK (1 13) +#define OMAP4430_DPLL_SSC_EN (1 12) and +#define OMAP4430_LOSTMEM_NONRETAINED_BANK (1 8) 4. Have you checked for macro name collisions with different values? I have not spotted any collisions yet, but I am curious to know if you are testing for these. For example, on OMAP2/3, some macro names, like EN_DSS, are defined with different values for different registers. These were disambiguated by adding the register names. For example, #define OMAP3430_PM_WKDEP_MPU_EN_DSS_MASK (1 5) ... #define OMAP3430_PM_WKEN_DSS_EN_DSS (1 0) (Of course, this latter define should be named OMAP3430_PM_WKEN_DSS_EN_DSS_MASK.) 5. There are some typos: +#define OMAP4430_LOSTMEM_PERIHPMEM_MASKBITFIELD(8, 8) 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 v2 2/6] ARM: OMAP4: PM: PRM/CM module offsets for OMAP4
Hi Rajendra, On Wed, 12 Aug 2009, Rajendra Nayak wrote: This patch adds the offsets for new modules in PRM and CM for OMAP4 These are autogenerated using a python script developed by Paul Walmsley. Thanks, this looks good now. You might want to also acknowledge Benoit here too since he co-developed the scripts. - Paul Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/prcm-common.h | 49 + 1 files changed, 49 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index cb1ae84..b4ce3fa 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -49,6 +49,55 @@ #define OMAP3430_NEON_MOD0xb00 #define OMAP3430ES2_USBHOST_MOD 0xc00 +/* OMAP44XX specific module offsets */ +/* CM1 instances */ + +#define OMAP4430_CM1_OCP_SOCKET_MOD 0x +#define OMAP4430_CM1_CKGEN_MOD 0x0100 +#define OMAP4430_CM1_MPU_MOD 0x0300 +#define OMAP4430_CM1_TESLA_MOD 0x0400 +#define OMAP4430_CM1_ABE_MOD 0x0500 +#define OMAP4430_CM1_RESTORE_MOD 0x0e00 +#define OMAP4430_CM1_INSTR_MOD 0x0f00 + +/* CM2 instances */ + +#define OMAP4430_CM2_OCP_SOCKET_MOD 0x +#define OMAP4430_CM2_CKGEN_MOD 0x0100 +#define OMAP4430_CM2_ALWAYS_ON_MOD 0x0600 +#define OMAP4430_CM2_CORE_MOD0x0700 +#define OMAP4430_CM2_IVAHD_MOD 0x0f00 +#define OMAP4430_CM2_CAM_MOD 0x1000 +#define OMAP4430_CM2_DSS_MOD 0x1100 +#define OMAP4430_CM2_GFX_MOD 0x1200 +#define OMAP4430_CM2_L3INIT_MOD 0x1300 +#define OMAP4430_CM2_L4PER_MOD 0x1400 +#define OMAP4430_CM2_CEFUSE_MOD 0x1600 +#define OMAP4430_CM2_RESTORE_MOD 0x1e00 +#define OMAP4430_CM2_INSTR_MOD 0x1f00 + +/* PRM instances */ + +#define OMAP4430_PRM_OCP_SOCKET_MOD 0x +#define OMAP4430_PRM_CKGEN_MOD 0x0100 +#define OMAP4430_PRM_MPU_MOD 0x0300 +#define OMAP4430_PRM_TESLA_MOD 0x0400 +#define OMAP4430_PRM_ABE_MOD 0x0500 +#define OMAP4430_PRM_ALWAYS_ON_MOD 0x0600 +#define OMAP4430_PRM_CORE_MOD0x0700 +#define OMAP4430_PRM_IVAHD_MOD 0x0f00 +#define OMAP4430_PRM_CAM_MOD 0x1000 +#define OMAP4430_PRM_DSS_MOD 0x1100 +#define OMAP4430_PRM_GFX_MOD 0x1200 +#define OMAP4430_PRM_L3INIT_MOD 0x1300 +#define OMAP4430_PRM_L4PER_MOD 0x1400 +#define OMAP4430_PRM_CEFUSE_MOD 0x1600 +#define OMAP4430_PRM_WKUP_MOD0x1700 +#define OMAP4430_PRM_WKUP_CM_MOD 0x1800 +#define OMAP4430_PRM_EMU_MOD 0x1900 +#define OMAP4430_PRM_EMU_CM_MOD 0x1a00 +#define OMAP4430_PRM_DEVICE_MOD 0x1b00 +#define OMAP4430_PRM_INSTR_MOD 0x1f00 /* 24XX register bits shared between CM PRM registers */ -- 1.5.4.7 -- To unsubscribe from this list: send the line unsubscribe 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] PM OMAP3: Change omap3_save_secure_ram to be called only during init
Tero Kristo tero.kri...@nokia.com writes:
This function is now called only once during the initialization of the device
and consequent sleep cycles will re-use the same saved contents for secure
RAM. Users who need secure services should do secure RAM saving before
entering off-mode, if a secure service has been accessed after last save.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
You explain what you're doing, but you don't explain why.
Is there a large latency involved in this save/restore that you're
trying to eliminate for the no-secure-services case?
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 4223622..b8cf5f2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -127,6 +127,12 @@ static void omap3_core_restore_context(void)
omap_dma_global_context_restore();
}
+/*
+ * FIXME: This function should be called before entering off-mode after
+ * OMAP3 secure services have been accessed. Currently it is only called
+ * once during boot sequence, but this works as we are not using secure
+ * services.
+ */
static void omap3_save_secure_ram_context(u32 target_mpu_state)
{
u32 ret;
@@ -349,7 +355,6 @@ void omap_sram_idle(void)
OMAP3_PRM_VOLTCTRL_OFFSET);
omap3_core_save_context();
omap3_prcm_save_context();
- omap3_save_secure_ram_context(mpu_next_state);
}
/* Enable IO-PAD wakeup */
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
@@ -923,6 +928,18 @@ int __init omap3_pm_init(void)
}
omap3_save_scratchpad_contents();
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ local_irq_disable();
+ local_fiq_disable();
+
+ omap_dma_global_context_save();
+ omap3_save_secure_ram_context(PWRDM_POWER_ON);
+ omap_dma_global_context_restore();
+
+ local_irq_enable();
+ local_fiq_enable();
+ }
+
err1:
return ret;
err2:
--
1.5.4.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 v2] OMAP2/3: DMA errata correction
Vikram Pandita vikram.pand...@ti.com writes:
This errata is valid for:
OMAP2420 Errata 1.85 Impacts all 2420 ES rev
OMAP2430 Errata 1.10 Impacts only ES1.0
Description: DMA may hang when several channels are used in parallel
OMAP3430: Not impacted, so remove the errata fix for omap3
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Reviewed-by: Kamat, Nishant nska...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
---
[Note: Respin of -
http://patchwork.kernel.org/patch/32513/
Incorporated Nishant's review comment]
arch/arm/plat-omap/dma.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 34939bf..bf08634 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -946,7 +946,9 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_class_is_omap2()) {
+ } else if (cpu_is_omap242x() ||
+ (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
+
/* Errata: Need to write lch even if not using chaining */
dma_write(lch, CLNK_CTRL(lch));
}
--
1.6.3.3.334.g916e1
--
To unsubscribe from this list: send the line unsubscribe 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: 3430SDP: Build break in pm-2.6.29 branch
Gadiyar, Anand gadi...@ti.com writes:
With the omap_3430sdp_pm_defconfig, I get the following build break
CC arch/arm/mach-omap2/pm34xx.o
arch/arm/mach-omap2/pm34xx.c: In function 'prcm_interrupt_handler':
arch/arm/mach-omap2/pm34xx.c:286: error: 'OMAP3_PRM_IRQSTATUS_MPU_OFFSET'
undeclared (first use in this function)
arch/arm/mach-omap2/pm34xx.c:286: error: (Each undeclared identifier is
reported only once
arch/arm/mach-omap2/pm34xx.c:286: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-omap2/pm34xx.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
Thanks for the report. This is a problem with my backport of Jon
Hunter's PRCM IRQ rework.
Just pushed the fix below to pm-2.6.29.
Kevin
commit e63cf0710a4fb639d91d3e8b05aa485fbfa381b3
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Thu Aug 13 07:21:15 2009 -0700
OMAP3: PM: PRCM IRQ rework: fix backport error.
Reported-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1fee053..a064605 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -283,7 +283,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
do {
irqstatus_mpu = prm_read_mod_reg(OCP_MOD,
- OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+ OMAP2_PRM_IRQSTATUS_MPU_OFFSET);
if (irqstatus_mpu (OMAP3430_WKUP_ST | OMAP3430_IO_ST)) {
c = _prcm_int_handle_wakeup();
@@ -301,9 +301,9 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
}
prm_write_mod_reg(irqstatus_mpu, OCP_MOD,
- OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+ OMAP2_PRM_IRQSTATUS_MPU_OFFSET);
- } while (prm_read_mod_reg(OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET));
+ } while (prm_read_mod_reg(OCP_MOD, OMAP2_PRM_IRQSTATUS_MPU_OFFSET));
return IRQ_HANDLED;
}
--
To unsubscribe from this list: send the line unsubscribe 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: What does the DSPBRIDGE do?
Hi Elvis, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ameya Palande Subject: Re: What does the DSPBRIDGE do? Hi Elvis, ext Elvis Dowson wrote: Hi Vladimir, On Aug 13, 2009, at 11:41 AM, Vladimir Pantelic wrote: Elvis Dowson wrote: Hi, I was wondering what the DSPBRIDGE does? it allows the arm to load/run code on the dsp And this code would be compiled and linked using the ti dsp compiler? what role will the arm gcc compiler play, when using ti dsp compiler? Are there some examples this? You can also checkout our portal in omapzoom, if you need a more technical overview about dspbridge you can check out in the Docs section: db_linux_rguide.pdf db_linux_pguide.pdf https://www.omapzoom.org/gf/project/omapbridge/wiki/? Samples to the code are at: DSP Bridge Userspace gitweb: http://dev.omapzoom.org/?p=tidspbridge/userspace-dspbridge.git;a=summary DSP samples (code running in the dsp, either baseimage or dll): source/samples/dsp MPU samples (arm side app using bridge to interact with the dsp): source/samples/mpu/src As mentioned before: GCC compiler will take care of bridge driver (compiled in the kernel), libbridge.so (API) and samples (in case youe need them). CGT Tools and DSP/BIOS package is used to generate the code which will be running on the dsp side. You can look here for initial environment setup: https://www.omapzoom.org/gf/project/omapbridge/wiki/?pagename=Build+userspace+files Best regards, Elvis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I guess you need TI compiler only for compiling Codes which run on DSP, rest of the stuff can be compiled using arm-gcc. 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 - 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: What does the DSPBRIDGE do?
Thanks Omar!! You can also checkout our portal in omapzoom, if you need a more technical overview about dspbridge you can check out in the Docs section: db_linux_rguide.pdf db_linux_pguide.pdf https://www.omapzoom.org/gf/project/omapbridge/wiki/? Samples to the code are at: DSP Bridge Userspace gitweb: http://dev.omapzoom.org/?p=tidspbridge/userspace-dspbridge.git;a=summary DSP samples (code running in the dsp, either baseimage or dll): source/samples/dsp MPU samples (arm side app using bridge to interact with the dsp): source/samples/mpu/src As mentioned before: GCC compiler will take care of bridge driver (compiled in the kernel), libbridge.so (API) and samples (in case youe need them). CGT Tools and DSP/BIOS package is used to generate the code which will be running on the dsp side. You can look here for initial environment setup: https://www.omapzoom.org/gf/project/omapbridge/wiki/?pagename=Build+userspace+files -- To unsubscribe from this list: send the line unsubscribe 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 03/20] OMAP: McBSP: Use appropriate value for startup delay
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/mcbsp.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 84cc323..2383b08 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -359,7 +359,13 @@ void omap_mcbsp_start(unsigned int id) w = OMAP_MCBSP_READ(io_base, SPCR1); OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1); - udelay(100); + /* +* Worst case: CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec +* REVISIT: 100us may give enough time for two CLKSRG, however +* due to some unknown PM related, clock gating etc. reason it +* is now at 500us. +*/ + udelay(500); /* Start frame sync */ w = OMAP_MCBSP_READ(io_base, SPCR2); -- 1.6.2.GIT -- To unsubscribe from this list: send the line unsubscribe 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 08/20] OMAP: McBSP: Add link DMA mode selection
From: Peter Ujfalusi peter.ujfal...@nokia.com
It adds a new sysfs file, where the user can configure the mcbsp mode to use.
If the mcbsp channel is in use, it does not allow the change.
Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode,
store it, than use it to implement the different modes.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |8 +++
arch/arm/plat-omap/mcbsp.c | 84 +++
2 files changed, 92 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 51a6655..9b2b03e 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -255,6 +255,11 @@
/** McBSP SYSCONFIG bit definitions /
#define SOFTRST0x0002
+/** McBSP DMA operating modes **/
+#define MCBSP_DMA_MODE_ELEMENT 0
+#define MCBSP_DMA_MODE_THRESHOLD 1
+#define MCBSP_DMA_MODE_FRAME 2
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
@@ -385,6 +390,7 @@ struct omap_mcbsp {
struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP34XX
+ int dma_op_mode;
u16 max_tx_thres;
u16 max_rx_thres;
#endif
@@ -401,6 +407,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold);
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
u16 omap_mcbsp_get_max_tx_threshold(unsigned int id);
u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
+int omap_mcbsp_get_dma_op_mode(unsigned int id);
#else
static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{ }
@@ -408,6 +415,7 @@ static inline void omap_mcbsp_set_rx_threshold(unsigned int
id, u16 threshold)
{ }
static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0;
}
static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0;
}
+static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 13e7ce3..6a4a621 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -282,6 +282,29 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id)
return mcbsp-max_rx_thres;
}
EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
+
+/*
+ * omap_mcbsp_get_dma_op_mode just return the current configured
+ * operating mode for the mcbsp channel
+ */
+int omap_mcbsp_get_dma_op_mode(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ int dma_op_mode;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%u)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ spin_lock_irq(mcbsp-lock);
+ dma_op_mode = mcbsp-dma_op_mode;
+ spin_unlock_irq(mcbsp-lock);
+
+ return dma_op_mode;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
#endif
/*
@@ -1063,9 +1086,65 @@ static DEVICE_ATTR(prop, 0644, prop##_show,
prop##_store);
THRESHOLD_PROP_BUILDER(max_tx_thres);
THRESHOLD_PROP_BUILDER(max_rx_thres);
+static ssize_t dma_op_mode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
+ int dma_op_mode;
+
+ spin_lock_irq(mcbsp-lock);
+ dma_op_mode = mcbsp-dma_op_mode;
+ spin_unlock_irq(mcbsp-lock);
+
+ return sprintf(buf, current mode: %d\n
+ possible mode values are:\n
+ %d - %s\n
+ %d - %s\n
+ %d - %s\n,
+ dma_op_mode,
+ MCBSP_DMA_MODE_ELEMENT, element mode,
+ MCBSP_DMA_MODE_THRESHOLD, threshold mode,
+ MCBSP_DMA_MODE_FRAME, frame mode);
+}
+
+static ssize_t dma_op_mode_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
+ unsigned long val;
+ int status;
+
+ status = strict_strtoul(buf, 0, val);
+ if (status)
+ return status;
+
+ spin_lock_irq(mcbsp-lock);
+
+ if (!mcbsp-free) {
+ size = -EBUSY;
+ goto unlock;
+ }
+
+ if (val MCBSP_DMA_MODE_FRAME || val MCBSP_DMA_MODE_ELEMENT) {
+ size = -EINVAL;
+ goto unlock;
+ }
+
+ mcbsp-dma_op_mode = val;
+
+unlock:
+ spin_unlock_irq(mcbsp-lock);
+
+ return size;
+}
+
+static
[PATCHv3 05/20] OMAP: McBSP: Create and export max_(r|t)x_thres property
This patch export through sysfs two properties to configure
maximum threshold for transmission and reception on each
mcbsp instance. Also, it exports two helper functions to
allow mcbsp users to read this values.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c |5 +
arch/arm/plat-omap/include/mach/mcbsp.h | 11 +++
arch/arm/plat-omap/mcbsp.c | 122 +++
3 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index a5c0f04..f837114 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -129,6 +129,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops= omap2_mcbsp_ops,
+ .buffer_size= 0x7F,
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -137,6 +138,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
.ops= omap2_mcbsp_ops,
+ .buffer_size= 0x3FF,
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
@@ -145,6 +147,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops= omap2_mcbsp_ops,
+ .buffer_size= 0x7F,
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -153,6 +156,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops= omap2_mcbsp_ops,
+ .buffer_size= 0x7F,
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -161,6 +165,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops= omap2_mcbsp_ops,
+ .buffer_size= 0x7F,
},
};
#define OMAP34XX_MCBSP_PDATA_SZARRAY_SIZE(omap34xx_mcbsp_pdata)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index c3dac63..51a6655 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -348,6 +348,9 @@ struct omap_mcbsp_platform_data {
u8 dma_rx_sync, dma_tx_sync;
u16 rx_irq, tx_irq;
struct omap_mcbsp_ops *ops;
+#ifdef CONFIG_ARCH_OMAP34XX
+ u16 buffer_size;
+#endif
};
struct omap_mcbsp {
@@ -381,6 +384,10 @@ struct omap_mcbsp {
struct omap_mcbsp_platform_data *pdata;
struct clk *iclk;
struct clk *fclk;
+#ifdef CONFIG_ARCH_OMAP34XX
+ u16 max_tx_thres;
+ u16 max_rx_thres;
+#endif
};
extern struct omap_mcbsp **mcbsp_ptr;
extern int omap_mcbsp_count;
@@ -392,11 +399,15 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg * config
#ifdef CONFIG_ARCH_OMAP34XX
void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold);
void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
+u16 omap_mcbsp_get_max_tx_threshold(unsigned int id);
+u16 omap_mcbsp_get_max_rx_threshold(unsigned int id);
#else
static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
{ }
static inline void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold)
{ }
+static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0;
}
+static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0;
}
#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 4efc6d7..2c97051 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -246,6 +246,42 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
OMAP_MCBSP_WRITE(io_base, THRSH1, threshold);
}
EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
+
+/*
+ * omap_mcbsp_get_max_tx_thres just return the current configured
+ * maximum threshold for transmission
+ */
+u16 omap_mcbsp_get_max_tx_threshold(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ return mcbsp-max_tx_thres;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_max_tx_threshold);
+
+/*
+ *
[PATCHv3 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold
Use dma mode property to configure NO IDLE or SMART IDLE of McBSPs. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/mcbsp.c | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 1db2ebc..8a78b61 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -317,7 +317,15 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); - syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); + + spin_lock_irq(mcbsp-lock); + if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) + syscon |= SIDLEMODE(0x02); + else + syscon |= SIDLEMODE(0x01); + spin_unlock_irq(mcbsp-lock); + + syscon |= (ENAWAKEUP | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN); -- 1.6.2.GIT -- To unsubscribe from this list: send the line unsubscribe 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 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
When no-idle mode is taken, wakeups need not to be enabled.
Moreover, CLOCKACTIVITY bits are unnecessary with this mode
also.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
Acked-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 8a78b61..c6df47d 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -319,16 +319,17 @@ static inline void omap34xx_mcbsp_request(struct
omap_mcbsp *mcbsp)
syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
spin_lock_irq(mcbsp-lock);
- if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
- syscon |= SIDLEMODE(0x02);
- else
+ if (mcbsp-dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
+ syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
+ CLOCKACTIVITY(0x02));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN,
+ XRDYEN | RRDYEN);
+ } else {
syscon |= SIDLEMODE(0x01);
+ }
spin_unlock_irq(mcbsp-lock);
- syscon |= (ENAWAKEUP | CLOCKACTIVITY(0x02));
OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
-
- OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN);
}
}
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 09/20] OMAP: McBSP: Wakeups utilized
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
This patch enables the smart idle mode while
McBPS is being utilized. Once it's done,
force idle mode is taken instead. Apart of it,
it also configures what signals will wake mcbsp up.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h | 17 +++
arch/arm/plat-omap/mcbsp.c | 46 +++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 9b2b03e..2c5612a 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -138,6 +138,7 @@
#define OMAP_MCBSP_REG_THRSH1 0x94
#define OMAP_MCBSP_REG_IRQST 0xA0
#define OMAP_MCBSP_REG_IRQEN 0xA4
+#define OMAP_MCBSP_REG_WAKEUPEN0xA8
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
@@ -253,6 +254,8 @@
#define RDISABLE 0x0001
/** McBSP SYSCONFIG bit definitions /
+#define SIDLEMODE(value) ((value)3)
+#define ENAWAKEUP 0x0004
#define SOFTRST0x0002
/** McBSP DMA operating modes **/
@@ -260,6 +263,20 @@
#define MCBSP_DMA_MODE_THRESHOLD 1
#define MCBSP_DMA_MODE_FRAME 2
+/** McBSP WAKEUPEN bit definitions */
+#define XEMPTYEOFEN0x4000
+#define XRDYEN 0x0400
+#define XEOFEN 0x0200
+#define XFSXEN 0x0100
+#define XSYNCERREN 0x0080
+#define RRDYEN 0x0008
+#define REOFEN 0x0004
+#define RFSREN 0x0002
+#define RSYNCERREN 0x0001
+#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
+XSYNCERREN | RRDYEN | REOFEN | RFSREN | \
+RSYNCERREN)
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 6a4a621..eb2147d 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -305,6 +305,46 @@ int omap_mcbsp_get_dma_op_mode(unsigned int id)
return dma_op_mode;
}
EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
+
+static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
+{
+ /*
+* Enable wakup behavior, smart idle and all wakeups
+* REVISIT: some wakeups may be unnecessary
+*/
+ if (cpu_is_omap34xx()) {
+ u16 syscon;
+
+ syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
+ syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
+ syscon |= (ENAWAKEUP | SIDLEMODE(0x02));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
+
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, WAKEUPEN_ALL);
+ }
+}
+
+static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp)
+{
+ /*
+* Disable wakup behavior, smart idle and all wakeups
+*/
+ if (cpu_is_omap34xx()) {
+ u16 syscon;
+ u16 wakeupen;
+
+ syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
+ syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
+ OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
+
+ wakeupen = OMAP_MCBSP_READ(mcbsp-io_base, WAKEUPEN);
+ wakeupen = ~WAKEUPEN_ALL;
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, wakeupen);
+ }
+}
+#else
+static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) {}
+static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp) {}
#endif
/*
@@ -366,6 +406,9 @@ int omap_mcbsp_request(unsigned int id)
clk_enable(mcbsp-iclk);
clk_enable(mcbsp-fclk);
+ /* Do procedure specific to omap34xx arch, if applicable */
+ omap34xx_mcbsp_request(mcbsp);
+
/*
* Make sure that transmitter, receiver and sample-rate generator are
* not running before activating IRQs.
@@ -414,6 +457,9 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp-pdata mcbsp-pdata-ops mcbsp-pdata-ops-free)
mcbsp-pdata-ops-free(id);
+ /* Do procedure specific to omap34xx arch, if applicable */
+ omap34xx_mcbsp_free(mcbsp);
+
clk_disable(mcbsp-fclk);
clk_disable(mcbsp-iclk);
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 07/20] OMAP: McBSP: Rename thres sysfs symbols
This patch renames the symbols that handles threshold
sysfs properties. This way we can add more sysfs properties
to them.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/mcbsp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 2c97051..13e7ce3 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -1063,24 +1063,24 @@ static DEVICE_ATTR(prop, 0644, prop##_show,
prop##_store);
THRESHOLD_PROP_BUILDER(max_tx_thres);
THRESHOLD_PROP_BUILDER(max_rx_thres);
-static const struct attribute *threshold_attrs[] = {
+static const struct attribute *additional_attrs[] = {
dev_attr_max_tx_thres.attr,
dev_attr_max_rx_thres.attr,
NULL,
};
-static const struct attribute_group threshold_attr_group = {
- .attrs = (struct attribute **)threshold_attrs,
+static const struct attribute_group additional_attr_group = {
+ .attrs = (struct attribute **)additional_attrs,
};
-static inline int __devinit omap_thres_add(struct device *dev)
+static inline int __devinit omap_additional_add(struct device *dev)
{
- return sysfs_create_group(dev-kobj, threshold_attr_group);
+ return sysfs_create_group(dev-kobj, additional_attr_group);
}
-static inline void __devexit omap_thres_remove(struct device *dev)
+static inline void __devexit omap_additional_remove(struct device *dev)
{
- sysfs_remove_group(dev-kobj, threshold_attr_group);
+ sysfs_remove_group(dev-kobj, additional_attr_group);
}
static inline void __devinit omap34xx_device_init(struct omap_mcbsp *mcbsp)
@@ -1088,9 +1088,9 @@ static inline void __devinit omap34xx_device_init(struct
omap_mcbsp *mcbsp)
if (cpu_is_omap34xx()) {
mcbsp-max_tx_thres = max_thres(mcbsp);
mcbsp-max_rx_thres = max_thres(mcbsp);
- if (omap_thres_add(mcbsp-dev))
+ if (omap_additional_add(mcbsp-dev))
dev_warn(mcbsp-dev,
- Unable to create threshold controls\n);
+ Unable to create additional controls\n);
} else {
mcbsp-max_tx_thres = -EINVAL;
mcbsp-max_rx_thres = -EINVAL;
@@ -1100,7 +1100,7 @@ static inline void __devinit omap34xx_device_init(struct
omap_mcbsp *mcbsp)
static inline void __devexit omap34xx_device_exit(struct omap_mcbsp *mcbsp)
{
if (cpu_is_omap34xx())
- omap_thres_remove(mcbsp-dev);
+ omap_additional_remove(mcbsp-dev);
}
#else
static inline void __devinit omap34xx_device_init(struct omap_mcbsp *mcbsp) {}
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 00/20] OMAP ASoC changes in DMA utilization
Hello again guys, Here is version 3 of these changes. I've changed just 2 things: - all mcbsp instances are in element mode by default - moved all mcbsp related code to omap-mcbsp.c (although a single callback is still needed) Jarkko, I think we can add your patch for reading strings for dma op mode later on. BR, Eduardo Valentin (11): OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers. OMAP: McBSP: Use appropriate value for startup delay OMAP: McBSP: Add transmit/receive threshold handler OMAP: McBSP: Create and export max_(r|t)x_thres property OMAP: McBSP: Rename thres sysfs symbols OMAP: McBSP: Change wakeup signals OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold ASoC: OMAP: Make DMA 64 aligned ASoC: OMAP: Enable DMA burst mode ASoC: OMAP: Use McBSP threshold to playback and capture ASoC: OMAP: Use DMA operating mode of McBSP Eero Nurkkala (7): OMAP: McBSP: Provide functions for ASoC frame syncronization OMAP: McBSP: Wakeups utilized OMAP: McBSP: Retain McBSP FCLK clockactivity OMAP: McBSP: Do not enable wakeups for no-idle mode OMAP: McBSP: Let element DMA mode hit retention also ASoC: Add runtime check for RFIG and XFIG ASoC: Always syncronize audio transfers on frames Peter Ujfalusi (2): OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 OMAP: McBSP: Add link DMA mode selection arch/arm/mach-omap2/mcbsp.c |5 + arch/arm/plat-omap/include/mach/mcbsp.h | 49 arch/arm/plat-omap/mcbsp.c | 377 ++- sound/soc/omap/omap-mcbsp.c | 77 ++- sound/soc/omap/omap-pcm.c | 14 +- sound/soc/omap/omap-pcm.h |2 + 6 files changed, 511 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 10/20] OMAP: McBSP: Change wakeup signals
Configure only XRDYEN and RRDYEN wakeup signals
in order to get better power consumption.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |3 ---
arch/arm/plat-omap/mcbsp.c |7 ++-
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 2c5612a..776ea4d 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -273,9 +273,6 @@
#define REOFEN 0x0004
#define RFSREN 0x0002
#define RSYNCERREN 0x0001
-#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
-XSYNCERREN | RRDYEN | REOFEN | RFSREN | \
-RSYNCERREN)
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index eb2147d..c2fd038 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -320,7 +320,7 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp
*mcbsp)
syscon |= (ENAWAKEUP | SIDLEMODE(0x02));
OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
- OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, WAKEUPEN_ALL);
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN);
}
}
@@ -331,15 +331,12 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp
*mcbsp)
*/
if (cpu_is_omap34xx()) {
u16 syscon;
- u16 wakeupen;
syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON);
syscon = ~(ENAWAKEUP | SIDLEMODE(0x03));
OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon);
- wakeupen = OMAP_MCBSP_READ(mcbsp-io_base, WAKEUPEN);
- wakeupen = ~WAKEUPEN_ALL;
- OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, wakeupen);
+ OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, 0);
}
}
#else
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 02/20] OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 77191c5..51908fb 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,10 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_THRSH2 0x90 +#define OMAP_MCBSP_REG_THRSH1 0x94 +#define OMAP_MCBSP_REG_IRQST 0xA0 +#define OMAP_MCBSP_REG_IRQEN 0xA4 #define OMAP_MCBSP_REG_XCCR0xAC #define OMAP_MCBSP_REG_RCCR0xB0 -- 1.6.2.GIT -- To unsubscribe from this list: send the line unsubscribe 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 11/20] OMAP: McBSP: Retain McBSP FCLK clockactivity
From: Eero Nurkkala ext-eero.nurkk...@nokia.com FCLK may get autogated so that it prevents the McBSP to work properly. It is the bit 9 that must be set for maintaining the McBSP FCLK. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com Acked-by: Jarkko Nikula jarkko.nik...@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h |1 + arch/arm/plat-omap/mcbsp.c |6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 776ea4d..895f001 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -254,6 +254,7 @@ #define RDISABLE 0x0001 /** McBSP SYSCONFIG bit definitions / +#define CLOCKACTIVITY(value) ((value)8) #define SIDLEMODE(value) ((value)3) #define ENAWAKEUP 0x0004 #define SOFTRST0x0002 diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index c2fd038..1db2ebc 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -316,8 +316,8 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp) u16 syscon; syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - syscon = ~(ENAWAKEUP | SIDLEMODE(0x03)); - syscon |= (ENAWAKEUP | SIDLEMODE(0x02)); + syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, XRDYEN | RRDYEN); @@ -333,7 +333,7 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp) u16 syscon; syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); - syscon = ~(ENAWAKEUP | SIDLEMODE(0x03)); + syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, 0); -- 1.6.2.GIT -- To unsubscribe from this list: send the line unsubscribe 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 04/20] OMAP: McBSP: Add transmit/receive threshold handler
This patch adds a way to handle transmit/receive threshold.
It export to mcbsp users a callback registration procedure.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |9 +
arch/arm/plat-omap/mcbsp.c | 50 +++
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 51908fb..c3dac63 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -389,6 +389,15 @@ int omap_mcbsp_init(void);
void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data *config,
int size);
void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg *
config);
+#ifdef CONFIG_ARCH_OMAP34XX
+void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold);
+void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold);
+#else
+static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
+{ }
+static inline void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold)
+{ }
+#endif
int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
void omap_mcbsp_start(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 2383b08..4efc6d7 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -198,6 +198,56 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
}
EXPORT_SYMBOL(omap_mcbsp_config);
+#ifdef CONFIG_ARCH_OMAP34XX
+/*
+ * omap_mcbsp_set_tx_threshold configures how to deal
+ * with transmit threshold. the threshold value and handler can be
+ * configure in here.
+ */
+void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ OMAP_MCBSP_WRITE(io_base, THRSH2, threshold);
+}
+EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold);
+
+/*
+ * omap_mcbsp_set_rx_threshold configures how to deal
+ * with receive threshold. the threshold value and handler can be
+ * configure in here.
+ */
+void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ OMAP_MCBSP_WRITE(io_base, THRSH1, threshold);
+}
+EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold);
+#endif
+
/*
* We can choose between IRQ based or polled IO.
* This needs to be called before omap_mcbsp_request().
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 17/20] ASoC: Add runtime check for RFIG and XFIG
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
This is, no RFIG or XFIG (Not defined in 34xx), correct
initiliazation of rccr and xccr.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
sound/soc/omap/omap-mcbsp.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index a5d46a7..8f361b1 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -321,8 +321,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
/* Generic McBSP register settings */
regs-spcr2 |= XINTM(3) | FREE;
regs-spcr1 |= RINTM(3);
- regs-rcr2 |= RFIG;
- regs-xcr2 |= XFIG;
+ /* RFIG and XFIG are not defined in 34xx */
+ if (!cpu_is_omap34xx()) {
+ regs-rcr2 |= RFIG;
+ regs-xcr2 |= XFIG;
+ }
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
regs-xccr = DXENDLY(1) | XDMAEN;
regs-rccr = RFULL_CYCLE | RDMAEN;
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 19/20] ASoC: OMAP: Use McBSP threshold to playback and capture
This patch changes the way DMA is done in omap-pcm.c
in order to reduce power consumption. There is no need
to have so much SW control in order to have DMA in idle
state during audio streaming. Configuring McBSP threshold value
and DMA to FRAME_SYNC are sufficient.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 47 +-
sound/soc/omap/omap-pcm.c |7 +-
sound/soc/omap/omap-pcm.h |2 +
3 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 0272d3f..8a7b5ef 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -139,28 +139,59 @@ static const unsigned long omap34xx_mcbsp_port[][2] = {
static const unsigned long omap34xx_mcbsp_port[][2] = {};
#endif
+static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ int samples = snd_pcm_lib_period_bytes(substream) 1;
+
+ /* Configure McBSP internal buffer usage */
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ omap_mcbsp_set_tx_threshold(mcbsp_data-bus_id, samples - 1);
+ else
+ omap_mcbsp_set_rx_threshold(mcbsp_data-bus_id, samples - 1);
+}
+
static int omap_mcbsp_dai_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
+ int bus_id = mcbsp_data-bus_id;
int err = 0;
- if (cpu_is_omap343x() mcbsp_data-bus_id == 1) {
+ if (!cpu_dai-active)
+ err = omap_mcbsp_request(bus_id);
+
+ if (cpu_is_omap343x()) {
+ int max_period;
+
/*
* McBSP2 in OMAP3 has 1024 * 32-bit internal audio buffer.
* Set constraint for minimum buffer size to the same than FIFO
* size in order to avoid underruns in playback startup because
* HW is keeping the DMA request active until FIFO is filled.
*/
+ if (bus_id == 1)
+ snd_pcm_hw_constraint_minmax(substream-runtime,
+ SNDRV_PCM_HW_PARAM_BUFFER_BYTES,
+ 4096, UINT_MAX);
+
+ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+ max_period = omap_mcbsp_get_max_tx_threshold(bus_id);
+ else
+ max_period = omap_mcbsp_get_max_rx_threshold(bus_id);
+
+ max_period++;
+ max_period = 1;
+
snd_pcm_hw_constraint_minmax(substream-runtime,
- SNDRV_PCM_HW_PARAM_BUFFER_BYTES, 4096, UINT_MAX);
+ SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+ 32, max_period);
}
- if (!cpu_dai-active)
- err = omap_mcbsp_request(mcbsp_data-bus_id);
-
return err;
}
@@ -220,7 +251,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
struct omap_mcbsp_reg_cfg *regs = mcbsp_data-regs;
int dma, bus_id = mcbsp_data-bus_id, id = cpu_dai-id;
- int wlen, channels, wpf;
+ int wlen, channels, wpf, sync_mode = OMAP_DMA_SYNC_ELEMENT;
unsigned long port;
unsigned int format;
@@ -236,6 +267,9 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
} else if (cpu_is_omap343x()) {
dma = omap24xx_dma_reqs[bus_id][substream-stream];
port = omap34xx_mcbsp_port[bus_id][substream-stream];
+ omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
+ omap_mcbsp_set_threshold;
+ sync_mode = OMAP_DMA_SYNC_FRAME;
} else {
return -ENODEV;
}
@@ -243,6 +277,7 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
substream-stream ? Audio Capture : Audio Playback;
omap_mcbsp_dai_dma_params[id][substream-stream].dma_req = dma;
omap_mcbsp_dai_dma_params[id][substream-stream].port_addr = port;
+ omap_mcbsp_dai_dma_params[id][substream-stream].sync_mode = sync_mode;
cpu_dai-dma_data = omap_mcbsp_dai_dma_params[id][substream-stream];
if (mcbsp_data-configured) {
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 5d41371..5e24e08 100644
---
[PATCHv3 20/20] ASoC: OMAP: Use DMA operating mode of McBSP
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 8a7b5ef..4369622 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -144,7 +144,14 @@ static void omap_mcbsp_set_threshold(struct
snd_pcm_substream *substream)
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_dai *cpu_dai = rtd-dai-cpu_dai;
struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai-private_data);
- int samples = snd_pcm_lib_period_bytes(substream) 1;
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(mcbsp_data-bus_id);
+ int samples;
+
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ samples = snd_pcm_lib_period_bytes(substream) 1;
+ else
+ samples = 1;
/* Configure McBSP internal buffer usage */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
@@ -166,6 +173,7 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
err = omap_mcbsp_request(bus_id);
if (cpu_is_omap343x()) {
+ int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id);
int max_period;
/*
@@ -187,7 +195,8 @@ static int omap_mcbsp_dai_startup(struct snd_pcm_substream
*substream,
max_period++;
max_period = 1;
- snd_pcm_hw_constraint_minmax(substream-runtime,
+ if (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)
+ snd_pcm_hw_constraint_minmax(substream-runtime,
SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
32, max_period);
}
@@ -269,7 +278,10 @@ static int omap_mcbsp_dai_hw_params(struct
snd_pcm_substream *substream,
port = omap34xx_mcbsp_port[bus_id][substream-stream];
omap_mcbsp_dai_dma_params[id][substream-stream].set_threshold =
omap_mcbsp_set_threshold;
- sync_mode = OMAP_DMA_SYNC_FRAME;
+ /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */
+ if (omap_mcbsp_get_dma_op_mode(bus_id) ==
+ MCBSP_DMA_MODE_THRESHOLD)
+ sync_mode = OMAP_DMA_SYNC_FRAME;
} else {
return -ENODEV;
}
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 06/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
From: Peter Ujfalusi peter.ujfal...@nokia.com
Do not allow applications to use the full buffer found on
McBSP1,3,4,5. Using the full buffer in threshold mode causes
the McBSP buffer to run dry, which can be observed as channels
are switching (in reality the channels are shifting).
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/mach-omap2/mcbsp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index f837114..7d22caf 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -129,7 +129,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
@@ -147,7 +147,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
{
.phys_base = OMAP34XX_MCBSP4_BASE,
@@ -156,7 +156,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
{
.phys_base = OMAP34XX_MCBSP5_BASE,
@@ -165,7 +165,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
.ops= omap2_mcbsp_ops,
- .buffer_size= 0x7F,
+ .buffer_size= 0x6F,
},
};
#define OMAP34XX_MCBSP_PDATA_SZARRAY_SIZE(omap34xx_mcbsp_pdata)
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 01/20] OMAP: McBSP: Provide functions for ASoC frame syncronization
From: Eero Nurkkala ext-eero.nurkk...@nokia.com
ASoC has an annoying bug letting either L or R channel to be
played on L channel. In other words, L and R channels can
switch at random. This provides McBSP funtionality that may
be used to fix this feature.
Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |2 +
arch/arm/plat-omap/mcbsp.c | 52 +++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index bb154ea..77191c5 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -389,6 +389,8 @@ int omap_mcbsp_request(unsigned int id);
void omap_mcbsp_free(unsigned int id);
void omap_mcbsp_start(unsigned int id);
void omap_mcbsp_stop(unsigned int id);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable);
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable);
void omap_mcbsp_xmit_word(unsigned int id, u32 word);
u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index efa0e01..84cc323 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -398,6 +398,58 @@ void omap_mcbsp_stop(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_stop);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+ u16 w;
+
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ w = OMAP_MCBSP_READ(io_base, XCCR);
+
+ if (enable)
+ OMAP_MCBSP_WRITE(io_base, XCCR, w ~(XDISABLE));
+ else
+ OMAP_MCBSP_WRITE(io_base, XCCR, w | XDISABLE);
+}
+EXPORT_SYMBOL(omap_mcbsp_xmit_enable);
+
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *io_base;
+ u16 w;
+
+ if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
+ return;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ io_base = mcbsp-io_base;
+
+ w = OMAP_MCBSP_READ(io_base, RCCR);
+
+ if (enable)
+ OMAP_MCBSP_WRITE(io_base, RCCR, w ~(RDISABLE));
+ else
+ OMAP_MCBSP_WRITE(io_base, RCCR, w | RDISABLE);
+}
+EXPORT_SYMBOL(omap_mcbsp_recv_enable);
+
/* polled mcbsp i/o operations */
int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
{
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 15/20] ASoC: OMAP: Make DMA 64 aligned
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
sound/soc/omap/omap-pcm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 84a1950..2422a42 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -288,7 +288,7 @@ static struct snd_pcm_ops omap_pcm_ops = {
.mmap = omap_pcm_mmap,
};
-static u64 omap_pcm_dmamask = DMA_BIT_MASK(32);
+static u64 omap_pcm_dmamask = DMA_BIT_MASK(64);
static int omap_pcm_preallocate_dma_buffer(struct snd_pcm *pcm,
int stream)
@@ -338,7 +338,7 @@ int omap_pcm_new(struct snd_card *card, struct snd_soc_dai
*dai,
if (!card-dev-dma_mask)
card-dev-dma_mask = omap_pcm_dmamask;
if (!card-dev-coherent_dma_mask)
- card-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ card-dev-coherent_dma_mask = DMA_BIT_MASK(64);
if (dai-playback.channels_min) {
ret = omap_pcm_preallocate_dma_buffer(pcm,
--
1.6.2.GIT
--
To unsubscribe from this list: send the line unsubscribe 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 14/20] OMAP: McBSP: Let element DMA mode hit retention also
From: Eero Nurkkala ext-eero.nurkk...@nokia.com The device no longer hits retention if element DMA mode is taken for at least the duration of the serial console timeout. Force element DMA mode to shut down through smartidle. Signed-off-by: Eero Nurkkala ext-eero.nurkk...@nokia.com Acked-by: Eduardo Valentin eduardo.valen...@nokia.com --- arch/arm/plat-omap/mcbsp.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index c6df47d..a4af1fa 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -343,6 +343,15 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp *mcbsp) syscon = OMAP_MCBSP_READ(mcbsp-io_base, SYSCON); syscon = ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + /* +* HW bug workaround - If no_idle mode is taken, we need to +* go to smart_idle before going to always_idle, or the +* device will not hit retention anymore. +*/ + syscon |= SIDLEMODE(0x02); + OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); + + syscon = ~(SIDLEMODE(0x03)); OMAP_MCBSP_WRITE(mcbsp-io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp-io_base, WAKEUPEN, 0); -- 1.6.2.GIT -- To unsubscribe from this list: send the line unsubscribe 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 16/20] ASoC: OMAP: Enable DMA burst mode
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- sound/soc/omap/omap-pcm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 2422a42..5d41371 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -176,6 +176,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) omap_enable_dma_irq(prtd-dma_ch, OMAP_DMA_FRAME_IRQ); + omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; } -- 1.6.2.GIT -- To unsubscribe from this list: send the line unsubscribe 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] PM OMAP3: Change omap3_save_secure_ram to be called only during init
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 13 August, 2009 17:17
To: Kristo Tero (Nokia-D/Tampere)
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] PM OMAP3: Change omap3_save_secure_ram to
be called only during init
Tero Kristo tero.kri...@nokia.com writes:
This function is now called only once during the
initialization of the device
and consequent sleep cycles will re-use the same saved
contents for secure
RAM. Users who need secure services should do secure RAM
saving before
entering off-mode, if a secure service has been accessed
after last save.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
You explain what you're doing, but you don't explain why.
Is there a large latency involved in this save/restore that you're
trying to eliminate for the no-secure-services case?
There are both latency and reliability issues. The context save uses a hardware
resource which takes an order of hundreds of milliseconds to initialize after a
wake up from off-mode, and also there is no way of checking whether it is ready
from kernel side or not. It just crashes if you use it too quickly.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 19 ++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 4223622..b8cf5f2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -127,6 +127,12 @@ static void omap3_core_restore_context(void)
omap_dma_global_context_restore();
}
+/*
+ * FIXME: This function should be called before entering
off-mode after
+ * OMAP3 secure services have been accessed. Currently it
is only called
+ * once during boot sequence, but this works as we are not
using secure
+ * services.
+ */
static void omap3_save_secure_ram_context(u32 target_mpu_state)
{
u32 ret;
@@ -349,7 +355,6 @@ void omap_sram_idle(void)
OMAP3_PRM_VOLTCTRL_OFFSET);
omap3_core_save_context();
omap3_prcm_save_context();
-omap3_save_secure_ram_context(mpu_next_state);
}
/* Enable IO-PAD wakeup */
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
@@ -923,6 +928,18 @@ int __init omap3_pm_init(void)
}
omap3_save_scratchpad_contents();
+if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+local_irq_disable();
+local_fiq_disable();
+
+omap_dma_global_context_save();
+omap3_save_secure_ram_context(PWRDM_POWER_ON);
+omap_dma_global_context_restore();
+
+local_irq_enable();
+local_fiq_enable();
+}
+
err1:
return ret;
err2:
--
1.5.4.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
[PATCH] Runtime detection of Si features
The OMAP35x family has multiple variants differing
in the HW features. This patch detects these features
at runtime and prints information during the boot.
Since most of the code seemed repetitive, macros
have been used for readability.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/id.c | 106 --
1 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..4476491 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -25,9 +25,49 @@
#include mach/control.h
#include mach/cpu.h
+/*
+ * OMAP3 features
+ */
+#define OMAP3_CONTROL_OMAP_STATUS 0x044c
+
+#define OMAP3_SGX_SHIFT13
+#define OMAP3_SGX_MASK (3 OMAP3_SGX_SHIFT)
+#defineFEAT_SGX_FULL 0
+#defineFEAT_SGX_HALF 1
+#defineFEAT_SGX_NONE 2
+
+#define OMAP3_IVA_SHIFT12
+#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT)
+#defineFEAT_IVA0
+#defineFEAT_IVA_NONE 1
+
+#define OMAP3_L2CACHE_SHIFT10
+#define OMAP3_L2CACHE_MASK (3 OMAP3_L2CACHE_SHIFT)
+#defineFEAT_L2CACHE_NONE 0
+#defineFEAT_L2CACHE_64KB 1
+#defineFEAT_L2CACHE_128KB 2
+#defineFEAT_L2CACHE_256KB 3
+
+#define OMAP3_ISP_SHIFT5
+#define OMAP3_ISP_MASK (1 OMAP3_ISP_SHIFT)
+#defineFEAT_ISP0
+#defineFEAT_ISP_NONE 1
+
+#define OMAP3_NEON_SHIFT 4
+#define OMAP3_NEON_MASK(1 OMAP3_NEON_SHIFT)
+#defineFEAT_NEON 0
+#defineFEAT_NEON_NONE 1
+
+
+#define OMAP_HAS_L2CACHE 1
+#define OMAP_HAS_IVA (1 1)
+#define OMAP_HAS_SGX (1 2)
+#define OMAP_HAS_NEON (1 3)
+#define OMAP_HAS_ISP (1 4)
+
static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
-
+static u32 omap_features ;
unsigned int omap_rev(void)
{
@@ -35,6 +75,19 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+#define OMAP3_HAS_FEATURE(feat,flag) \
+ unsigned int omap3_has_ ##feat(void)\
+ { \
+ return (omap_features OMAP_HAS_ ##flag); \
+ } \
+ EXPORT_SYMBOL(omap3_has_ ##feat);
+
+OMAP3_HAS_FEATURE(l2cache, L2CACHE);
+OMAP3_HAS_FEATURE(sgx, SGX);
+OMAP3_HAS_FEATURE(iva, IVA);
+OMAP3_HAS_FEATURE(neon, NEON);
+OMAP3_HAS_FEATURE(isp, ISP);
+
/**
* omap_chip_is - test whether currently running OMAP matches a chip type
* @oc: omap_chip_t to test against
@@ -155,7 +208,33 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
}
-void __init omap34xx_check_revision(void)
+#define OMAP3_CHECK_FEATURE(status,feat) \
+ if (((status OMAP3_ ##feat## _MASK) \
+OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
+ omap_features |= OMAP_HAS_ ##feat; \
+ }
+
+void __init omap3_check_features(void)
+{
+ u32 status, temp;
+
+ omap_features = 0;
+
+ status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
+
+ OMAP3_CHECK_FEATURE(status, L2CACHE);
+ OMAP3_CHECK_FEATURE(status, IVA);
+ OMAP3_CHECK_FEATURE(status, SGX);
+ OMAP3_CHECK_FEATURE(status, NEON);
+ OMAP3_CHECK_FEATURE(status, ISP);
+
+ /*
+* TODO: Get additional info (where applicable)
+* e.g. Size of L2 cache.
+*/
+}
+
+void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
@@ -212,6 +291,22 @@ out:
pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
}
+#define OMAP3_SHOW_FEATURE(feat) \
+ if (omap3_has_ ##feat()) { \
+ pr_info ( - #feat : Y); \
+ } else {\
+ pr_info ( - #feat : N); \
+ }
+
+void __init omap3_cpuinfo(void)
+{
+ OMAP3_SHOW_FEATURE(l2cache);
+ OMAP3_SHOW_FEATURE(iva);
+ OMAP3_SHOW_FEATURE(sgx);
+ OMAP3_SHOW_FEATURE(neon);
+ OMAP3_SHOW_FEATURE(isp);
+}
+
/*
* Try to detect the exact revision of the omap we're running on
*/
@@ -223,8 +318,11 @@ void __init omap2_check_revision(void)
*/
if (cpu_is_omap24xx())
omap24xx_check_revision();
- else if (cpu_is_omap34xx())
- omap34xx_check_revision();
+ else if (cpu_is_omap34xx()) {
+ omap3_check_features();
RE: [PATCH V2 0/32] mmc and omap_hsmmc patches
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Madhusudhan Sent: Thursday, July 30, 2009 7:53 PM To: 'Matt Fleming'; 'Adrian Hunter' Cc: 'Andrew Morton'; 'Jarkko Lavinen'; 'linux-omap Mailing List'; 'Pierre Ossman'; 'Denis Karpov'; 'lkml' Subject: RE: [PATCH V2 0/32] mmc and omap_hsmmc patches -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Matt Fleming Sent: Wednesday, July 29, 2009 6:13 AM To: Adrian Hunter Cc: Andrew Morton; Jarkko Lavinen; linux-omap Mailing List; Pierre Ossman; Denis Karpov; lkml Subject: Re: [PATCH V2 0/32] mmc and omap_hsmmc patches On Tue, Jul 28, 2009 at 01:38:34PM +0300, Adrian Hunter wrote: Hi Here is version 2 of our 32 patches for mmc and omap_hsmmc. They include Matt Fleming's change for card caps, and 2 other fixes: - use a spin lock rather than enable / diable irq - make disable delay specified in milliseconds not jiffies because the value is an int, and jiffies are unsigned long (also millisecs are better anyway) Thanks for doing this Adrian. I appreciate it. My Reviewed-by tag still applies. I reviewed the omap_hsmmc series. They look good. Regards, Madhu Hi Andrew, I am curious to know is this series lined up for upstream? Thanks, Madhu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142)
-Original Message- From: Kalle Jokiniemi [mailto:kalle.jokini...@digia.com] Sent: Friday, August 07, 2009 4:00 PM To: Roger Quadros Cc: Kevin Hilman; Nayak, Rajendra; linux-omap@vger.kernel.org Subject: Re: [RFC][PATCH] OMAP3: PM: Fix workaround implementation for OMAP3 errata (1.142) On Fri, 2009-08-07 at 11:48 +0300, Roger Quadros wrote: ext Kalle Jokiniemi wrote: On Fri, 2009-08-07 at 11:03 +0300, Roger Quadros wrote: ext Kalle Jokiniemi wrote: On Fri, 2009-08-07 at 01:14 +0300, Kevin Hilman wrote: Roger Quadros ext-roger.quad...@nokia.com writes: As per errata 1.142, on EMU/HS devices, SDRC_POWER should be programmed for automatic self-refresh before transition to OFF mode. In the current implementation this is done in omap3_scratchpad_contents() which is wrong, since this is the value that will be restored while resuming from OFF mode and not while transitioning to it. This patch implements the workaround in the correct way as per errata. Signed-off-by: Roger Quadros ext-roger.quad...@nokia.com This looks right to me. Rajendra, Kalle, any comments? since you were the originators of the original patch. Kevin --- arch/arm/mach-omap2/control.c | 16 ++-- arch/arm/mach-omap2/pm34xx.c | 20 ++-- 2 files changed, 16 insertions(+), 20 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index a7159a9..0a563c8 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -272,20 +272,8 @@ void omap3_save_scratchpad_contents(void) (sdrc_read_reg(SDRC_ERR_TYPE) 0x); sdrc_block_contents.dll_a_ctrl = sdrc_read_reg(SDRC_DLLA_CTRL); sdrc_block_contents.dll_b_ctrl = 0x0; - /* - * Due to a OMAP3 errata (1.142), on EMU/HS devices SRDC should - * be programed to issue automatic self refresh on timeout - * of AUTO_CNT = 1 prior to any transition to OFF mode. - */ - if ((omap_type() != OMAP2_DEVICE_TYPE_GP) - (omap_rev() = OMAP3430_REV_ES3_0)) - sdrc_block_contents.power = (sdrc_read_reg(SDRC_POWER) - ~(SDRC_POWER_AUTOCOUNT_MASK| - SDRC_POWER_CLKCTRL_MASK)) | - (1 SDRC_POWER_AUTOCOUNT_SHIFT) | - SDRC_SELF_REFRESH_ON_AUTOCOUNT; - else - sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER); + + sdrc_block_contents.power = sdrc_read_reg(SDRC_POWER); Why do you want to remove the workaround from scratchpad? When we wake up from off mode, the boot ROM code writes these settings as the first sdrc_power settings after wakeup. If that setting does not include the workaround, we'll have a period of time where sdram is not being refreshed. This hits especially HS devices that do long secure context restore in ROM code as well. I suppose SDRAM is always refreshed (i.e. auto refresh) when ON. However when we enter OFF mode it should be _self_ refreshed. That is done by the below code before we switch to OFF mode. The erratum speaks of auto-refresh failing after waking up from CORE off mode. I think there is the described workaround in place in sleep34xx.S code to kick up the auto refresh, but this still leaves a short gap between boot ROM and the sleep code. Unless the self-refresh mode does not get changed by the scratchpad settings? - Kalle There are 2 parts in the errata 1.142. The 1st part is what you are talking about. And it needs to be applied only on ES3.0 devices. The 2nd part is valid only for HS devices. ..it is mandatory on HS device to have the SDRC issuing automatic self-refresh entries on inactivity periods.. My patch is only fixing the implementation of the 2nd part without changing the work around for the 1st part. no? The fix for second part is ok. But I have understood that the scratchpad change was an additional safeguard against the 1st part. Rajendra, any comments? Sorry, I was off for a while, hence the delay in responding. So the errata has just one part and not two. Its just that the workaround is different on GP and HS. So to summarise Errata: SDRAM is always put in selfrefresh while in OFF. On the way out of OFF once SDRC is restored by ROM code, the very first access to SDRAM brings it out of self refresh and then automatic autorefresh commands should be sent, but are not sent due to SDRC state machine being in an inappropriate state. WA: Issue a manual MR/EMR2 write command to SDRAM. ON GP devices doing this immediately on a jump to kernel SDRAM restore pointer code worked fine as there was no access to SDRAM from ROMcode. However on HS devices the ROM code itself did some SDRAM access causing the SDRAM to come out of self refresh (while the romcode was still
Re: linux-omap-2.6 git not updated?
Tony Lindgren t...@atomide.com writes: * Tony Lindgren t...@atomide.com [090812 16:48]: * Gadiyar, Anand gadi...@ti.com [090812 16:27]: Tony, Is something wrong with the kernel.org mirror? The last commit I see is: commit 4baadee6e2dd5228e1b17cb5f931c4e0ed8fcb96 Author: Anand Gadiyar gadi...@ti.com Date: Wed Aug 5 16:22:59 2009 +0300 I do see that the other branches (upstream, omap4, ...) are updated. Looks like only the master is not yet reflecting the patches you applied in the last 7 days. Yeah I have not updated master yet with the patches going upstream. Will reset arch/arm/*omap* in master, and merge in the posted upstream branches. Updated now with the patches queued for mainline. Tony, Can you merge in the .31 fixes branches that RMK has already pulled in also? These are the PM fixes from me and Paul's fixes branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Runtime detection of Si features
Sanjeev Premi pr...@ti.com writes:
The OMAP35x family has multiple variants differing
in the HW features. This patch detects these features
at runtime and prints information during the boot.
Since most of the code seemed repetitive, macros
have been used for readability.
Signed-off-by: Sanjeev Premi pr...@ti.com
I like the feature-based approach.
A couple questions though. Is there a bit/register that reports the
collapsed powerdomains of the devices with modified PRCM?
Also, how will other code query the features? You're currently
exporting the omap_has_*() functions, but there are no prototypes.
I think I'd rather see a static inline functions in mach/cpu.h
for checking features. Comments to that end inlined below...
---
arch/arm/mach-omap2/id.c | 106
--
1 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..4476491 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -25,9 +25,49 @@
#include mach/control.h
#include mach/cpu.h
+/*
+ * OMAP3 features
+ */
+#define OMAP3_CONTROL_OMAP_STATUS0x044c
This should probably go in mach/control.h
+#define OMAP3_SGX_SHIFT 13
+#define OMAP3_SGX_MASK (3 OMAP3_SGX_SHIFT)
+#define FEAT_SGX_FULL 0
+#define FEAT_SGX_HALF 1
+#define FEAT_SGX_NONE 2
+#define OMAP3_IVA_SHIFT 12
+#define OMAP3_IVA_MASK (1 OMAP3_SGX_SHIFT)
+#define FEAT_IVA0
+#define FEAT_IVA_NONE 1
+
+#define OMAP3_L2CACHE_SHIFT 10
+#define OMAP3_L2CACHE_MASK (3 OMAP3_L2CACHE_SHIFT)
+#define FEAT_L2CACHE_NONE 0
+#define FEAT_L2CACHE_64KB 1
+#define FEAT_L2CACHE_128KB 2
+#define FEAT_L2CACHE_256KB 3
+
+#define OMAP3_ISP_SHIFT 5
+#define OMAP3_ISP_MASK (1 OMAP3_ISP_SHIFT)
+#define FEAT_ISP0
+#define FEAT_ISP_NONE 1
+
+#define OMAP3_NEON_SHIFT 4
+#define OMAP3_NEON_MASK (1 OMAP3_NEON_SHIFT)
+#define FEAT_NEON 0
+#define FEAT_NEON_NONE 1
+
+
+#define OMAP_HAS_L2CACHE 1
+#define OMAP_HAS_IVA (1 1)
+#define OMAP_HAS_SGX (1 2)
+#define OMAP_HAS_NEON(1 3)
+#define OMAP_HAS_ISP (1 4)
+
Use BIT()
Rename to OMAP3_*
move to mach/cpu.h
static struct omap_chip_id omap_chip;
static unsigned int omap_revision;
-
+static u32 omap_features ;
Call this omap3_features and make it global (with extern in mach/cpu.h)
unsigned int omap_rev(void)
{
@@ -35,6 +75,19 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+#define OMAP3_HAS_FEATURE(feat,flag) \
+ unsigned int omap3_has_ ##feat(void)\
make this
static inline unsigned int omap3_has_ ##feat(void) ...
+ { \
+ return (omap_features OMAP_HAS_ ##flag); \
+ } \
+ EXPORT_SYMBOL(omap3_has_ ##feat);
+OMAP3_HAS_FEATURE(l2cache, L2CACHE);
+OMAP3_HAS_FEATURE(sgx, SGX);
+OMAP3_HAS_FEATURE(iva, IVA);
+OMAP3_HAS_FEATURE(neon, NEON);
+OMAP3_HAS_FEATURE(isp, ISP);
+
... and move this set to mach/cpu.h
and I'm ok with the rest of this patch.
Kevin
/**
* omap_chip_is - test whether currently running OMAP matches a chip type
* @oc: omap_chip_t to test against
@@ -155,7 +208,33 @@ void __init omap24xx_check_revision(void)
pr_info(\n);
}
-void __init omap34xx_check_revision(void)
+#define OMAP3_CHECK_FEATURE(status,feat) \
+ if (((status OMAP3_ ##feat## _MASK) \
+ OMAP3_ ##feat## _SHIFT) != FEAT_ ##feat## _NONE) { \
+ omap_features |= OMAP_HAS_ ##feat; \
+ }
+
+void __init omap3_check_features(void)
+{
+ u32 status, temp;
+
+ omap_features = 0;
+
+ status = omap_ctrl_readl(OMAP3_CONTROL_OMAP_STATUS);
+
+ OMAP3_CHECK_FEATURE(status, L2CACHE);
+ OMAP3_CHECK_FEATURE(status, IVA);
+ OMAP3_CHECK_FEATURE(status, SGX);
+ OMAP3_CHECK_FEATURE(status, NEON);
+ OMAP3_CHECK_FEATURE(status, ISP);
+
+ /*
+ * TODO: Get additional info (where applicable)
+ * e.g. Size of L2 cache.
+ */
+}
+
+void __init omap3_check_revision(void)
{
u32 cpuid, idcode;
u16 hawkeye;
@@ -212,6 +291,22 @@ out:
pr_info(OMAP%04x %s\n, omap_rev() 16, rev_name);
}
+#define
Re: [PATCH V2 0/32] mmc and omap_hsmmc patches
On Thu, 13 Aug 2009 10:27:15 -0500 Madhusudhan madhu...@ti.com wrote: I am curious to know is this series lined up for upstream? yup. http://userweb.kernel.org/~akpm/mmotm/ is the place to check for that. -- To unsubscribe from this list: send the line unsubscribe 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] Runtime detection of Si features
Kevin Hilman had written, on 08/13/2009 11:13 AM, the following: Sanjeev Premi pr...@ti.com writes: The OMAP35x family has multiple variants differing in the HW features. This patch detects these features at runtime and prints information during the boot. Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? -- 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] Runtime detection of Si features
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Thursday, August 13, 2009 11:31 AM To: Kevin Hilman Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] Runtime detection of Si features Kevin Hilman had written, on 08/13/2009 11:13 AM, the following: Sanjeev Premi pr...@ti.com writes: The OMAP35x family has multiple variants differing in the HW features. This patch detects these features at runtime and prints information during the boot. Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? We are hitting exactly this issue with I2C errata 1.153 Instead of basing the errata check on cpu_is...(), its more appropriate to base it on IP revision of I2C. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Runtime detection of Si features
Pandita, Vikram vikram.pand...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Nishanth Menon Sent: Thursday, August 13, 2009 11:31 AM To: Kevin Hilman Cc: Premi, Sanjeev; linux-omap@vger.kernel.org Subject: Re: [PATCH] Runtime detection of Si features Kevin Hilman had written, on 08/13/2009 11:13 AM, the following: Sanjeev Premi pr...@ti.com writes: The OMAP35x family has multiple variants differing in the HW features. This patch detects these features at runtime and prints information during the boot. Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? We are hitting exactly this issue with I2C errata 1.153 Instead of basing the errata check on cpu_is...(), its more appropriate to base it on IP revision of I2C. Shouldn't the IP revision of I2C be avaialble in an I2C revision register an be used in the driver instead of cpu_is*? 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: OMAP PM status?
Kevin Hilman khil...@deeprootsystems.com writes: Hi Kalle, Hello, Kalle Valo kalle.v...@iki.fi writes: as you might guess, I'm eagerly waiting for OMAP PM support to hit mainline :) I'm just curious, what's the current status? Are we going to get PM support in 2.6.32? Hmmm, good question. To avoid giving an answer that can be archived and used against me, I updated the PM branch wiki page[1] with a 'mainline plans' section[2] which I can edit as plans slip^Wchange. :) Excellent, the page was very helpful for me and I'm sure also for others. Especially I'm interested about 2420 support for n8x0. Well, I'm afraid I've done basically no testing for OMAP2, and have been focusing solely on OMAP3. I'm pretty sure things at least should compile for OMAP2, as care has been taken to keep OMAP2 up to speed with OMAP3 for the base features, but I haven't done any boot testing on OMAP2 for some time. I'm sorry to hear that, but I understand that you don't have time for everything. That being said, all the infrastructure for OMAP2 that was in linux-omap is already in mainline so will work as good as it did in linux-omap. The last time I actually tried PM on OMAP2, I found/fixed a bug[3] in the asm sleep code for OMAP2 that was causing fault. At least it no longer faults when suspended Of course, I'll be glad to take any OMAP2 patches/fixes and get them upstream with the rest of my changes, but I'm afraid with my current plans, I do not have the cycles to spend on OMAP2. As soon as I find some spare time (which usually means three to four months from now :) I'll start experimenting with N800 PM. If I have any problems, I'll send email to the list as usual. Thanks. -- Kalle Valo -- To unsubscribe from this list: send the line unsubscribe 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] Runtime detection of Si features
Kevin Hilman had written, on 08/13/2009 11:40 AM, the following: Pandita, Vikram vikram.pand...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sent: Thursday, August 13, 2009 11:31 AM Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? We are hitting exactly this issue with I2C errata 1.153 Instead of basing the errata check on cpu_is...(), its more appropriate to base it on IP revision of I2C. Shouldn't the IP revision of I2C be avaialble in an I2C revision register an be used in the driver instead of cpu_is*? what I was proposing is a much more generic infrastructure which i2c among other modules can use. Getting IP revision is already available in the specific IP modules REVISION registers - we might want to standardize how drivers handle revision based feature/errata set to ensure that they would have an optimal way to handle the same.. just my 2 cents.. -- 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 00/10] OMAP PM debug infrastructure for 2.6.32
This series adds the PM debug infrastructure which is currently used in the OMAP PM branch[1]. Applies on v2.6.31-rc5 plus previous PM fixes queue: [PATCH 00/14] OMAP PM fixes for .31-rc series Kevin [1] http://elinux.org/OMAP_Power_Management Peter 'p2' De Schrijver (8): 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 OMAP3: Debug observability and ETK padconf implementation OMAP3: Add debug observablity (debobs) Kconfig item Tero Kristo (2): OMAP: PM debug: Add PRCM register dump support OMAP: PM: Added suspend target state control to debugfs for OMAP3 arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/clock.c |2 + arch/arm/mach-omap2/clockdomain.c | 10 +- arch/arm/mach-omap2/debobs.c | 240 ++ arch/arm/mach-omap2/pm-debug.c| 413 - arch/arm/mach-omap2/pm.h | 11 + arch/arm/mach-omap2/pm24xx.c |4 +- arch/arm/mach-omap2/pm34xx.c | 38 ++- arch/arm/mach-omap2/powerdomain.c | 110 +++- arch/arm/plat-omap/Kconfig|7 + arch/arm/plat-omap/include/mach/clockdomain.h |3 +- arch/arm/plat-omap/include/mach/control.h | 47 +++- arch/arm/plat-omap/include/mach/debobs.h |7 + arch/arm/plat-omap/include/mach/powerdomain.h | 15 +- 14 files changed, 893 insertions(+), 17 deletions(-) create mode 100644 arch/arm/mach-omap2/debobs.c mode change 100644 = 100755 arch/arm/mach-omap2/pm.h create mode 100644 arch/arm/plat-omap/include/mach/debobs.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] OMAP: PM counter infrastructure.
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This patch provides the infrastructure to count how many times a
powerdomain entered a given power state (on, inactive, retention,
off). A number of functions are provided which will be called by the
chip specific powerdomain and clockdomain code whenever a transition
might have happened.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clockdomain.c |2 +
arch/arm/mach-omap2/powerdomain.c | 101 -
arch/arm/plat-omap/include/mach/powerdomain.h |7 ++
3 files changed, 108 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 0e7d501..26912a9 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -484,6 +484,8 @@ void omap2_clkdm_allow_idle(struct clockdomain *clkdm)
v __ffs(clkdm-clktrctrl_mask),
clkdm-pwrdm.ptr-prcm_offs,
CM_CLKSTCTRL);
+
+ pwrdm_clkdm_state_switch(clkdm);
}
/**
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 983f1cb..a2d9871 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -35,6 +35,11 @@
#include mach/powerdomain.h
#include mach/clockdomain.h
+enum {
+ PWRDM_STATE_NOW = 0,
+ PWRDM_STATE_PREV,
+};
+
/* pwrdm_list contains all registered struct powerdomains */
static LIST_HEAD(pwrdm_list);
@@ -102,6 +107,63 @@ static struct powerdomain *_pwrdm_deps_lookup(struct
powerdomain *pwrdm,
return pd-pwrdm;
}
+static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
+{
+
+ int prev;
+ int state;
+
+ if (pwrdm == NULL)
+ return -EINVAL;
+
+ state = pwrdm_read_pwrst(pwrdm);
+
+ switch (flag) {
+ case PWRDM_STATE_NOW:
+ prev = pwrdm-state;
+ break;
+ case PWRDM_STATE_PREV:
+ prev = pwrdm_read_prev_pwrst(pwrdm);
+ if (pwrdm-state != prev)
+ pwrdm-state_counter[prev]++;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (state != prev)
+ pwrdm-state_counter[state]++;
+
+ pwrdm-state = state;
+
+ return 0;
+}
+
+static int _pwrdm_pre_transition_cb(struct powerdomain *pwrdm)
+{
+ pwrdm_clear_all_prev_pwrst(pwrdm);
+ _pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
+ return 0;
+}
+
+static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm)
+{
+ _pwrdm_state_switch(pwrdm, PWRDM_STATE_PREV);
+ return 0;
+}
+
+static __init void _pwrdm_setup(struct powerdomain *pwrdm)
+{
+ int i;
+
+ for (i = 0; i 4; i++)
+ pwrdm-state_counter[i] = 0;
+
+ pwrdm_wait_transition(pwrdm);
+ pwrdm-state = pwrdm_read_pwrst(pwrdm);
+ pwrdm-state_counter[pwrdm-state] = 1;
+
+}
/* Public functions */
@@ -117,9 +179,12 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
{
struct powerdomain **p = NULL;
- if (pwrdm_list)
- for (p = pwrdm_list; *p; p++)
+ if (pwrdm_list) {
+ for (p = pwrdm_list; *p; p++) {
pwrdm_register(*p);
+ _pwrdm_setup(*p);
+ }
+ }
}
/**
@@ -1110,4 +1175,36 @@ int pwrdm_wait_transition(struct powerdomain *pwrdm)
return 0;
}
+int pwrdm_state_switch(struct powerdomain *pwrdm)
+{
+ return _pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
+}
+
+int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
+{
+ if (clkdm != NULL clkdm-pwrdm.ptr != NULL) {
+ pwrdm_wait_transition(clkdm-pwrdm.ptr);
+ return pwrdm_state_switch(clkdm-pwrdm.ptr);
+ }
+
+ return -EINVAL;
+}
+int pwrdm_clk_state_switch(struct clk *clk)
+{
+ if (clk != NULL clk-clkdm != NULL)
+ return pwrdm_clkdm_state_switch(clk-clkdm);
+ return -EINVAL;
+}
+
+int pwrdm_pre_transition(void)
+{
+ pwrdm_for_each(_pwrdm_pre_transition_cb);
+ return 0;
+}
+
+int pwrdm_post_transition(void)
+{
+ pwrdm_for_each(_pwrdm_post_transition_cb);
+ return 0;
+}
diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h
b/arch/arm/plat-omap/include/mach/powerdomain.h
index 69c9e67..52663fc 100644
--- a/arch/arm/plat-omap/include/mach/powerdomain.h
+++ b/arch/arm/plat-omap/include/mach/powerdomain.h
@@ -117,6 +117,8 @@ struct powerdomain {
struct list_head node;
+ int state;
+ unsigned state_counter[4];
};
@@ -164,4 +166,9 @@ bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm);
int pwrdm_wait_transition(struct powerdomain *pwrdm);
+int pwrdm_state_switch(struct powerdomain *pwrdm);
+int
[PATCH 02/10] OMAP: PM: Hook into PM counters
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This patch modifies the clock, clockdomain and OMAP3 specific
powerdomain code to call the PM counter infrastructure whenever one or
more powerdomains might have changed state.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clock.c |2 ++
arch/arm/mach-omap2/clockdomain.c |3 +++
arch/arm/mach-omap2/pm34xx.c |6 ++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index b0665f1..8ccbd23 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -1041,5 +1041,7 @@ void omap2_clk_disable_unused(struct clk *clk)
omap2_clk_disable(clk);
} else
_omap2_clk_disable(clk);
+ if (clk-clkdm != NULL)
+ pwrdm_clkdm_state_switch(clk-clkdm);
}
#endif
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 26912a9..5b0b90b 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -574,6 +574,7 @@ int omap2_clkdm_clk_enable(struct clockdomain *clkdm,
struct clk *clk)
omap2_clkdm_wakeup(clkdm);
pwrdm_wait_transition(clkdm-pwrdm.ptr);
+ pwrdm_clkdm_state_switch(clkdm);
return 0;
}
@@ -626,6 +627,8 @@ int omap2_clkdm_clk_disable(struct clockdomain *clkdm,
struct clk *clk)
else
omap2_clkdm_sleep(clkdm);
+ pwrdm_clkdm_state_switch(clkdm);
+
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 488d595..f197624 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -170,6 +170,8 @@ static void omap_sram_idle(void)
printk(KERN_ERR Invalid mpu state in sram_idle\n);
return;
}
+ pwrdm_pre_transition();
+
omap2_gpio_prepare_for_retention();
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -182,6 +184,9 @@ static void omap_sram_idle(void)
omap_uart_resume_idle(1);
omap_uart_resume_idle(0);
omap2_gpio_resume_after_retention();
+
+ pwrdm_post_transition();
+
}
/*
@@ -271,6 +276,7 @@ static int set_pwrdm_state(struct powerdomain *pwrdm, u32
state)
if (sleep_switch) {
omap2_clkdm_allow_idle(pwrdm-pwrdm_clkdms[0]);
pwrdm_wait_transition(pwrdm);
+ pwrdm_state_switch(pwrdm);
}
err:
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each.
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Add some infrastructure to easily iterate over clock and power
domains.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/clockdomain.c |5 +++--
arch/arm/mach-omap2/pm24xx.c |4 ++--
arch/arm/mach-omap2/pm34xx.c |8
arch/arm/plat-omap/include/mach/clockdomain.h |3 ++-
arch/arm/plat-omap/include/mach/powerdomain.h |3 ++-
5 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 5b0b90b..4ef7b4f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -299,7 +299,8 @@ struct clockdomain *clkdm_lookup(const char *name)
* anything else to indicate failure; or -EINVAL if the function pointer
* is null.
*/
-int clkdm_for_each(int (*fn)(struct clockdomain *clkdm))
+int clkdm_for_each(int (*fn)(struct clockdomain *clkdm, void *user),
+ void *user)
{
struct clockdomain *clkdm;
int ret = 0;
@@ -309,7 +310,7 @@ int clkdm_for_each(int (*fn)(struct clockdomain *clkdm))
mutex_lock(clkdm_mutex);
list_for_each_entry(clkdm, clkdm_list, node) {
- ret = (*fn)(clkdm);
+ ret = (*fn)(clkdm, user);
if (ret)
break;
}
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 528dbdc..bff5c4e 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -333,7 +333,7 @@ static struct platform_suspend_ops omap_pm_ops = {
.valid = suspend_valid_only_mem,
};
-static int _pm_clkdm_enable_hwsup(struct clockdomain *clkdm)
+static int _pm_clkdm_enable_hwsup(struct clockdomain *clkdm, void *unused)
{
omap2_clkdm_allow_idle(clkdm);
return 0;
@@ -385,7 +385,7 @@ static void __init prcm_setup_regs(void)
omap2_clkdm_sleep(gfx_clkdm);
/* Enable clockdomain hardware-supervised control for all clkdms */
- clkdm_for_each(_pm_clkdm_enable_hwsup);
+ clkdm_for_each(_pm_clkdm_enable_hwsup, NULL);
/* Enable clock autoidle for all domains */
cm_write_mod_reg(OMAP24XX_AUTO_CAM |
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f197624..331dfca 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -664,7 +664,7 @@ static void __init prcm_setup_regs(void)
omap3_d2d_idle();
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm)
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
@@ -689,7 +689,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm)
* supported. Initiate sleep transition for other clockdomains, if
* they are not used
*/
-static int __init clkdms_setup(struct clockdomain *clkdm)
+static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
{
if (clkdm-flags CLKDM_CAN_ENABLE_AUTO)
omap2_clkdm_allow_idle(clkdm);
@@ -722,13 +722,13 @@ static int __init omap3_pm_init(void)
goto err1;
}
- ret = pwrdm_for_each(pwrdms_setup);
+ ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
goto err2;
}
- (void) clkdm_for_each(clkdms_setup);
+ (void) clkdm_for_each(clkdms_setup, NULL);
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
diff --git a/arch/arm/plat-omap/include/mach/clockdomain.h
b/arch/arm/plat-omap/include/mach/clockdomain.h
index b9d0dd2..99ebd88 100644
--- a/arch/arm/plat-omap/include/mach/clockdomain.h
+++ b/arch/arm/plat-omap/include/mach/clockdomain.h
@@ -95,7 +95,8 @@ int clkdm_register(struct clockdomain *clkdm);
int clkdm_unregister(struct clockdomain *clkdm);
struct clockdomain *clkdm_lookup(const char *name);
-int clkdm_for_each(int (*fn)(struct clockdomain *clkdm));
+int clkdm_for_each(int (*fn)(struct clockdomain *clkdm, void *user),
+ void *user);
struct powerdomain *clkdm_get_pwrdm(struct clockdomain *clkdm);
void omap2_clkdm_allow_idle(struct clockdomain *clkdm);
diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h
b/arch/arm/plat-omap/include/mach/powerdomain.h
index 52663fc..de03f3d 100644
--- a/arch/arm/plat-omap/include/mach/powerdomain.h
+++ b/arch/arm/plat-omap/include/mach/powerdomain.h
@@ -128,7 +128,8 @@ int pwrdm_register(struct powerdomain *pwrdm);
int pwrdm_unregister(struct powerdomain *pwrdm);
struct powerdomain *pwrdm_lookup(const char *name);
-int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm));
+int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user),
+ void *user);
[PATCH 04/10] OMAP: PM: Add pm-debug counters
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This patch provides the debugfs entries and a function which will be
called by the PM code to register the time spent per domain per
state. Also some new fields are added to the powerdomain struct to
keep the time information.
NOTE: As of v2.6.29, using getnstimeofday() after drivers are
suspended is no longer safe since the timekeeping subsystem is also
suspended as part of the suspend process. Instead use sched_clock()
which on OMAP returns the 32k SYNC timer in nanoseconds.
Also, do not print out status for meta powerdomains (dpll*)
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm-debug.c| 178 -
arch/arm/mach-omap2/pm.h |4 +
arch/arm/plat-omap/include/mach/powerdomain.h |5 +
3 files changed, 186 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 6cc375a..9199c17 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -20,13 +20,15 @@
*/
#include linux/kernel.h
-#include linux/timer.h
+#include linux/sched.h
#include linux/clk.h
#include linux/err.h
#include linux/io.h
#include mach/clock.h
#include mach/board.h
+#include mach/powerdomain.h
+#include mach/clockdomain.h
#include prm.h
#include cm.h
@@ -150,3 +152,177 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
for (i = 0; i reg_count; i++)
printk(KERN_INFO %-20s: 0x%08x\n, regs[i].name, regs[i].val);
}
+
+#ifdef CONFIG_DEBUG_FS
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+struct dentry *pm_dbg_dir;
+
+static int pm_dbg_init_done;
+
+enum {
+ DEBUG_FILE_COUNTERS = 0,
+ DEBUG_FILE_TIMERS,
+};
+
+static const char pwrdm_state_names[][4] = {
+ OFF,
+ RET,
+ INA,
+ ON
+};
+
+void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
+{
+ s64 t;
+
+ if (!pm_dbg_init_done)
+ return ;
+
+ /* Update timer for previous state */
+ t = sched_clock();
+
+ pwrdm-state_timer[prev] += t - pwrdm-timer;
+
+ pwrdm-timer = t;
+}
+
+static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
+{
+ struct seq_file *s = (struct seq_file *)user;
+
+ if (strcmp(clkdm-name, emu_clkdm) == 0 ||
+ strcmp(clkdm-name, wkup_clkdm) == 0 ||
+ strncmp(clkdm-name, dpll, 4) == 0)
+ return 0;
+
+ seq_printf(s, %s-%s (%d), clkdm-name,
+ clkdm-pwrdm.ptr-name,
+ atomic_read(clkdm-usecount));
+ seq_printf(s, \n);
+
+ return 0;
+}
+
+static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
+{
+ struct seq_file *s = (struct seq_file *)user;
+ int i;
+
+ if (strcmp(pwrdm-name, emu_pwrdm) == 0 ||
+ strcmp(pwrdm-name, wkup_pwrdm) == 0 ||
+ strncmp(pwrdm-name, dpll, 4) == 0)
+ return 0;
+
+ if (pwrdm-state != pwrdm_read_pwrst(pwrdm))
+ printk(KERN_ERR pwrdm state mismatch(%s) %d != %d\n,
+ pwrdm-name, pwrdm-state, pwrdm_read_pwrst(pwrdm));
+
+ seq_printf(s, %s (%s), pwrdm-name,
+ pwrdm_state_names[pwrdm-state]);
+ for (i = 0; i 4; i++)
+ seq_printf(s, ,%s:%d, pwrdm_state_names[i],
+ pwrdm-state_counter[i]);
+
+ seq_printf(s, \n);
+
+ return 0;
+}
+
+static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
+{
+ struct seq_file *s = (struct seq_file *)user;
+ int i;
+
+ if (strcmp(pwrdm-name, emu_pwrdm) == 0 ||
+ strcmp(pwrdm-name, wkup_pwrdm) == 0 ||
+ strncmp(pwrdm-name, dpll, 4) == 0)
+ return 0;
+
+ pwrdm_state_switch(pwrdm);
+
+ seq_printf(s, %s (%s), pwrdm-name,
+ pwrdm_state_names[pwrdm-state]);
+
+ for (i = 0; i 4; i++)
+ seq_printf(s, ,%s:%lld, pwrdm_state_names[i],
+ pwrdm-state_timer[i]);
+
+ seq_printf(s, \n);
+ return 0;
+}
+
+static int pm_dbg_show_counters(struct seq_file *s, void *unused)
+{
+ pwrdm_for_each(pwrdm_dbg_show_counter, s);
+ clkdm_for_each(clkdm_dbg_show_counter, s);
+
+ return 0;
+}
+
+static int pm_dbg_show_timers(struct seq_file *s, void *unused)
+{
+ pwrdm_for_each(pwrdm_dbg_show_timer, s);
+ return 0;
+}
+
+static int pm_dbg_open(struct inode *inode, struct file *file)
+{
+ switch ((int)inode-i_private) {
+ case DEBUG_FILE_COUNTERS:
+ return single_open(file, pm_dbg_show_counters,
+ inode-i_private);
+ case DEBUG_FILE_TIMERS:
+ default:
+ return single_open(file,
[PATCH 05/10] OMAP: PM debug: make powerdomains use PM-debug counters
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Make the powerdomain code call the new hook for updating the time.
Also implement the updated pwrdm_for_each.
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/powerdomain.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index a2d9871..5a6cef3 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -35,6 +35,8 @@
#include mach/powerdomain.h
#include mach/clockdomain.h
+#include pm.h
+
enum {
PWRDM_STATE_NOW = 0,
PWRDM_STATE_PREV,
@@ -134,19 +136,21 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
if (state != prev)
pwrdm-state_counter[state]++;
+ pm_dbg_update_time(pwrdm, prev);
+
pwrdm-state = state;
return 0;
}
-static int _pwrdm_pre_transition_cb(struct powerdomain *pwrdm)
+static int _pwrdm_pre_transition_cb(struct powerdomain *pwrdm, void *unused)
{
pwrdm_clear_all_prev_pwrst(pwrdm);
_pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
return 0;
}
-static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm)
+static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused)
{
_pwrdm_state_switch(pwrdm, PWRDM_STATE_PREV);
return 0;
@@ -282,7 +286,8 @@ struct powerdomain *pwrdm_lookup(const char *name)
* anything else to indicate failure; or -EINVAL if the function
* pointer is null.
*/
-int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm))
+int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user),
+ void *user)
{
struct powerdomain *temp_pwrdm;
unsigned long flags;
@@ -293,7 +298,7 @@ int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm))
read_lock_irqsave(pwrdm_rwlock, flags);
list_for_each_entry(temp_pwrdm, pwrdm_list, node) {
- ret = (*fn)(temp_pwrdm);
+ ret = (*fn)(temp_pwrdm, user);
if (ret)
break;
}
@@ -1198,13 +1203,13 @@ int pwrdm_clk_state_switch(struct clk *clk)
int pwrdm_pre_transition(void)
{
- pwrdm_for_each(_pwrdm_pre_transition_cb);
+ pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
return 0;
}
int pwrdm_post_transition(void)
{
- pwrdm_for_each(_pwrdm_post_transition_cb);
+ pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] OMAP: PM debug: Add PRCM register dump support
From: Tero Kristo tero.kri...@nokia.com
Allows dumping out current register contents from the debug filesystem, and
also allows user to add arbitrary register save points into code. Current
register contents are available under debugfs at:
[debugfs]/pm_debug/registers/current
To add a save point, do following:
From module init (or somewhere before the save call, called only once):
pm_dbg_init_regset(n); // n=1..4, allocates memory for dump area #n
From arbitrary code location:
pm_dbg_regset_save(n); // n=1..4, saves registers to dump area #n
After this, the register dump can be seen under [debugfs]/pm_debug/registers/n
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm-debug.c | 208
arch/arm/mach-omap2/pm.h |4 +
2 files changed, 212 insertions(+), 0 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/pm-debug.c
mode change 100644 = 100755 arch/arm/mach-omap2/pm.h
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
old mode 100644
new mode 100755
index 9199c17..37b883b
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -157,6 +157,8 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
#include linux/debugfs.h
#include linux/seq_file.h
+static void pm_dbg_regset_store(u32 *ptr);
+
struct dentry *pm_dbg_dir;
static int pm_dbg_init_done;
@@ -166,6 +168,159 @@ enum {
DEBUG_FILE_TIMERS,
};
+struct pm_module_def {
+ char name[8]; /* Name of the module */
+ short type; /* CM or PRM */
+ unsigned short offset;
+ int low; /* First register address on this module */
+ int high; /* Last register address on this module */
+};
+
+#define MOD_CM 0
+#define MOD_PRM 1
+
+static const struct pm_module_def pm_dbg_reg_modules[] = {
+ { IVA2, MOD_CM, OMAP3430_IVA2_MOD, 0, 0x4c },
+ { OCP, MOD_CM, OCP_MOD, 0, 0x10 },
+ { MPU, MOD_CM, MPU_MOD, 4, 0x4c },
+ { CORE, MOD_CM, CORE_MOD, 0, 0x4c },
+ { SGX, MOD_CM, OMAP3430ES2_SGX_MOD, 0, 0x4c },
+ { WKUP, MOD_CM, WKUP_MOD, 0, 0x40 },
+ { CCR, MOD_CM, PLL_MOD, 0, 0x70 },
+ { DSS, MOD_CM, OMAP3430_DSS_MOD, 0, 0x4c },
+ { CAM, MOD_CM, OMAP3430_CAM_MOD, 0, 0x4c },
+ { PER, MOD_CM, OMAP3430_PER_MOD, 0, 0x4c },
+ { EMU, MOD_CM, OMAP3430_EMU_MOD, 0x40, 0x54 },
+ { NEON, MOD_CM, OMAP3430_NEON_MOD, 0x20, 0x48 },
+ { USB, MOD_CM, OMAP3430ES2_USBHOST_MOD, 0, 0x4c },
+
+ { IVA2, MOD_PRM, OMAP3430_IVA2_MOD, 0x50, 0xfc },
+ { OCP, MOD_PRM, OCP_MOD, 4, 0x1c },
+ { MPU, MOD_PRM, MPU_MOD, 0x58, 0xe8 },
+ { CORE, MOD_PRM, CORE_MOD, 0x58, 0xf8 },
+ { SGX, MOD_PRM, OMAP3430ES2_SGX_MOD, 0x58, 0xe8 },
+ { WKUP, MOD_PRM, WKUP_MOD, 0xa0, 0xb0 },
+ { CCR, MOD_PRM, PLL_MOD, 0x40, 0x70 },
+ { DSS, MOD_PRM, OMAP3430_DSS_MOD, 0x58, 0xe8 },
+ { CAM, MOD_PRM, OMAP3430_CAM_MOD, 0x58, 0xe8 },
+ { PER, MOD_PRM, OMAP3430_PER_MOD, 0x58, 0xe8 },
+ { EMU, MOD_PRM, OMAP3430_EMU_MOD, 0x58, 0xe4 },
+ { GLBL, MOD_PRM, OMAP3430_GR_MOD, 0x20, 0xe4 },
+ { NEON, MOD_PRM, OMAP3430_NEON_MOD, 0x58, 0xe8 },
+ { USB, MOD_PRM, OMAP3430ES2_USBHOST_MOD, 0x58, 0xe8 },
+ { , 0, 0, 0, 0 },
+};
+
+#define PM_DBG_MAX_REG_SETS 4
+
+static void *pm_dbg_reg_set[PM_DBG_MAX_REG_SETS];
+
+static int pm_dbg_get_regset_size(void)
+{
+ static int regset_size;
+
+ if (regset_size == 0) {
+ int i = 0;
+
+ while (pm_dbg_reg_modules[i].name[0] != 0) {
+ regset_size += pm_dbg_reg_modules[i].high +
+ 4 - pm_dbg_reg_modules[i].low;
+ i++;
+ }
+ }
+ return regset_size;
+}
+
+static int pm_dbg_show_regs(struct seq_file *s, void *unused)
+{
+ int i, j;
+ unsigned long val;
+ int reg_set = (int)s-private;
+ u32 *ptr;
+ void *store = NULL;
+ int regs;
+ int linefeed;
+
+ if (reg_set == 0) {
+ store = kmalloc(pm_dbg_get_regset_size(), GFP_KERNEL);
+ ptr = store;
+ pm_dbg_regset_store(ptr);
+ } else {
+ ptr = pm_dbg_reg_set[reg_set - 1];
+ }
+
+ i = 0;
+
+ while (pm_dbg_reg_modules[i].name[0] != 0) {
+ regs = 0;
+ linefeed = 0;
+ if (pm_dbg_reg_modules[i].type == MOD_CM)
+ seq_printf(s, MOD: CM_%s (%08x)\n,
+ pm_dbg_reg_modules[i].name,
+ (u32)(OMAP3430_CM_BASE +
+ pm_dbg_reg_modules[i].offset));
+ else
+ seq_printf(s, MOD: PRM_%s (%08x)\n,
+ pm_dbg_reg_modules[i].name,
+ (u32)(OMAP3430_PRM_BASE +
+
[PATCH 07/10] OMAP: PM: Add definitions for ETK pads and observability registers
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/plat-omap/include/mach/control.h | 47 +++- 1 files changed, 45 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/control.h b/arch/arm/plat-omap/include/mach/control.h index 8140dbc..81afe26 100644 --- a/arch/arm/plat-omap/include/mach/control.h +++ b/arch/arm/plat-omap/include/mach/control.h @@ -141,8 +141,51 @@ #define OMAP343X_CONTROL_TEST_KEY_13 (OMAP2_CONTROL_GENERAL + 0x00fc) #define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190) #define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194) -#define OMAP343X_CONTROL_PBIAS_LITE(OMAP2_CONTROL_GENERAL + 0x02b0) -#define OMAP343X_CONTROL_TEMP_SENSOR (OMAP2_CONTROL_GENERAL + 0x02b4) +#define OMAP343X_CONTROL_DEBOBS(i) (OMAP2_CONTROL_GENERAL + 0x01B0 \ + + ((i) 1) * 4 + (!(i 1)) * 2) +#define OMAP343X_CONTROL_PROG_IO0 (OMAP2_CONTROL_GENERAL + 0x01D4) +#define OMAP343X_CONTROL_PROG_IO1 (OMAP2_CONTROL_GENERAL + 0x01D8) +#define OMAP343X_CONTROL_DSS_DPLL_SPREADING(OMAP2_CONTROL_GENERAL + 0x01E0) +#define OMAP343X_CONTROL_CORE_DPLL_SPREADING (OMAP2_CONTROL_GENERAL + 0x01E4) +#define OMAP343X_CONTROL_PER_DPLL_SPREADING(OMAP2_CONTROL_GENERAL + 0x01E8) +#define OMAP343X_CONTROL_USBHOST_DPLL_SPREADING(OMAP2_CONTROL_GENERAL + 0x01EC) +#define OMAP343X_CONTROL_PBIAS_LITE(OMAP2_CONTROL_GENERAL + 0x02B0) +#define OMAP343X_CONTROL_TEMP_SENSOR (OMAP2_CONTROL_GENERAL + 0x02B4) +#define OMAP343X_CONTROL_SRAMLDO4 (OMAP2_CONTROL_GENERAL + 0x02B8) +#define OMAP343X_CONTROL_SRAMLDO5 (OMAP2_CONTROL_GENERAL + 0x02C0) +#define OMAP343X_CONTROL_CSI (OMAP2_CONTROL_GENERAL + 0x02C4) + + +/* 34xx PADCONF register offsets */ +#define OMAP343X_PADCONF_ETK(i)(OMAP2_CONTROL_PADCONFS + 0x5a8 + \ + (i)*2) +#define OMAP343X_PADCONF_ETK_CLK OMAP343X_PADCONF_ETK(0) +#define OMAP343X_PADCONF_ETK_CTL OMAP343X_PADCONF_ETK(1) +#define OMAP343X_PADCONF_ETK_D0OMAP343X_PADCONF_ETK(2) +#define OMAP343X_PADCONF_ETK_D1OMAP343X_PADCONF_ETK(3) +#define OMAP343X_PADCONF_ETK_D2OMAP343X_PADCONF_ETK(4) +#define OMAP343X_PADCONF_ETK_D3OMAP343X_PADCONF_ETK(5) +#define OMAP343X_PADCONF_ETK_D4OMAP343X_PADCONF_ETK(6) +#define OMAP343X_PADCONF_ETK_D5OMAP343X_PADCONF_ETK(7) +#define OMAP343X_PADCONF_ETK_D6OMAP343X_PADCONF_ETK(8) +#define OMAP343X_PADCONF_ETK_D7OMAP343X_PADCONF_ETK(9) +#define OMAP343X_PADCONF_ETK_D8OMAP343X_PADCONF_ETK(10) +#define OMAP343X_PADCONF_ETK_D9OMAP343X_PADCONF_ETK(11) +#define OMAP343X_PADCONF_ETK_D10 OMAP343X_PADCONF_ETK(12) +#define OMAP343X_PADCONF_ETK_D11 OMAP343X_PADCONF_ETK(13) +#define OMAP343X_PADCONF_ETK_D12 OMAP343X_PADCONF_ETK(14) +#define OMAP343X_PADCONF_ETK_D13 OMAP343X_PADCONF_ETK(15) +#define OMAP343X_PADCONF_ETK_D14 OMAP343X_PADCONF_ETK(16) +#define OMAP343X_PADCONF_ETK_D15 OMAP343X_PADCONF_ETK(17) + +/* 34xx GENERAL_WKUP regist offsets */ +#define OMAP343X_CONTROL_WKUP_DEBOBSMUX(i) (OMAP343X_CONTROL_GENERAL_WKUP + \ + 0x008 + (i)) +#define OMAP343X_CONTROL_WKUP_DEBOBS0 (OMAP343X_CONTROL_GENERAL_WKUP + 0x008) +#define OMAP343X_CONTROL_WKUP_DEBOBS1 (OMAP343X_CONTROL_GENERAL_WKUP + 0x00C) +#define OMAP343X_CONTROL_WKUP_DEBOBS2 (OMAP343X_CONTROL_GENERAL_WKUP + 0x010) +#define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014) +#define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018) /* 34xx D2D idle-related pins, handled by PM core */ #define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250 -- 1.6.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] OMAP3: Debug observability and ETK padconf implementation
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/debobs.c | 240 ++
arch/arm/plat-omap/include/mach/debobs.h |7 +
2 files changed, 247 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/debobs.c
create mode 100644 arch/arm/plat-omap/include/mach/debobs.h
diff --git a/arch/arm/mach-omap2/debobs.c b/arch/arm/mach-omap2/debobs.c
new file mode 100644
index 000..397a599
--- /dev/null
+++ b/arch/arm/mach-omap2/debobs.c
@@ -0,0 +1,240 @@
+/*
+ * arch/arm/mach-omap2/debobs.c
+ *
+ * Handle debobs pads
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver peter.de-schrij...@nokia.com
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/debugfs.h
+#include linux/uaccess.h
+#include linux/module.h
+#include linux/gpio.h
+
+#include mach/control.h
+#include mach/mux.h
+#include mach/board.h
+
+#define ETK_GPIO_BEGIN 12
+#define ETK_GPIO(i)(ETK_GPIO_BEGIN + i)
+#define NUM_OF_DEBOBS_PADS 18
+
+static int debobs_initialized;
+
+enum debobs_pad_mode {
+ GPIO = 0,
+ OBS = 1,
+ ETK = 2,
+ NO_MODE = 3,
+};
+
+static char *debobs_pad_mode_names[] = {
+ [GPIO] = GPIO,
+ [OBS] = OBS,
+ [ETK] = ETK,
+};
+
+struct obs {
+ u16 offset;
+ u8 value;
+ u8 mask;
+};
+
+struct debobs_pad {
+ enum debobs_pad_mode mode;
+ struct obs core_obs;
+ struct obs wakeup_obs;
+};
+
+static struct debobs_pad debobs_pads[NUM_OF_DEBOBS_PADS];
+
+static int debobs_mode_open(struct inode *inode, struct file *file)
+{
+ file-private_data = inode-i_private;
+
+ return 0;
+}
+
+static ssize_t debobs_mode_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ char buffer[10];
+ int size;
+ int pad_number = (int)file-private_data;
+ struct debobs_pad *e = debobs_pads[pad_number];
+
+ size = snprintf(buffer, sizeof(buffer), %s\n,
+ debobs_pad_mode_names[e-mode]);
+ return simple_read_from_buffer(user_buf, count, ppos, buffer, size);
+}
+
+static ssize_t debobs_mode_write(struct file *file, const char __user
*user_buf,
+ size_t count, loff_t *ppos)
+{
+ char buffer[10];
+ int buf_size, i, pad_number;
+ u16 muxmode = OMAP34XX_MUX_MODE7;
+
+ memset(buffer, 0, sizeof(buffer));
+ buf_size = min(count, (sizeof(buffer)-1));
+
+ if (copy_from_user(buffer, user_buf, buf_size))
+ return -EFAULT;
+
+ pad_number = (int)file-private_data;
+
+ for (i = 0; i NO_MODE; i++) {
+ if (!strnicmp(debobs_pad_mode_names[i],
+ buffer,
+ strlen(debobs_pad_mode_names[i]))) {
+ switch (i) {
+ case ETK:
+ muxmode = OMAP34XX_MUX_MODE0;
+ break;
+ case GPIO:
+ muxmode = OMAP34XX_MUX_MODE4;
+ break;
+ case OBS:
+ muxmode = OMAP34XX_MUX_MODE7;
+ break;
+ }
+ omap_ctrl_writew(muxmode,
+ OMAP343X_PADCONF_ETK(pad_number));
+ debobs_pads[pad_number].mode = i;
+
+ return count;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static const struct file_operations debobs_mode_fops = {
+ .open = debobs_mode_open,
+ .read = debobs_mode_read,
+ .write = debobs_mode_write,
+};
+
+static int debobs_get(void *data, u64 *val)
+{
+ struct obs *o = data;
+
+ *val = o-value;
+
+ return 0;
+}
+
+static int debobs_set(void *data, u64 val)
+{
+ struct obs *o = data;
+
+ val = BIT(o-mask) - 1;
+
+ omap_ctrl_writeb(val, o-offset);
+ o-value = val;
+
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(debobs_fops, debobs_get, debobs_set, %llu\n);
+
+static
[PATCH 09/10] OMAP3: Add debug observablity (debobs) Kconfig item
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/Makefile |3 +++ arch/arm/plat-omap/Kconfig |7 +++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 735bae5..cc515a4 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -44,6 +44,9 @@ iommu-$(CONFIG_ARCH_OMAP3)+= omap3-iommu.o obj-$(CONFIG_OMAP_IOMMU) += $(iommu-y) +# Debobs +obj-$(CONFIG_OMAP3_DEBOBS) += debobs.o + # Specific board support obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index efe85d0..4e90a36 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -143,6 +143,13 @@ config OMAP_32K_TIMER endchoice +config OMAP3_DEBOBS + bool OMAP3 Debug observability support + depends on ARCH_OMAP3 DEBUG_FS + default n + help + Use ETK pads for debug observability + config OMAP_32K_TIMER_HZ int Kernel internal timer frequency for 32KHz timer range 32 1024 -- 1.6.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] OMAP: PM: Added suspend target state control to debugfs for OMAP3
From: Tero Kristo tero.kri...@nokia.com
Target state can be read / programmed via files under:
[debugfs]/pm_debug/[pwrdm]/suspend
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/pm-debug.c | 31 +--
arch/arm/mach-omap2/pm.h |3 +++
arch/arm/mach-omap2/pm34xx.c | 24
3 files changed, 56 insertions(+), 2 deletions(-)
mode change 100755 = 100644 arch/arm/mach-omap2/pm-debug.c
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
old mode 100755
new mode 100644
index 37b883b..eded6a4
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/err.h
#include linux/io.h
+#include linux/module.h
#include mach/clock.h
#include mach/board.h
@@ -478,10 +479,28 @@ int pm_dbg_regset_init(int reg_set)
return 0;
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+static int pwrdm_suspend_get(void *data, u64 *val)
+{
+ *val = omap3_pm_get_suspend_state((struct powerdomain *)data);
+
+ if (*val = 0)
+ return 0;
+ return *val;
+}
+
+static int pwrdm_suspend_set(void *data, u64 val)
+{
+ return omap3_pm_set_suspend_state((struct powerdomain *)data, (int)val);
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(pwrdm_suspend_fops, pwrdm_suspend_get,
+ pwrdm_suspend_set, %llu\n);
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *dir)
{
int i;
s64 t;
+ struct dentry *d;
t = sched_clock();
@@ -490,6 +509,14 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *unused)
pwrdm-timer = t;
+ if (strncmp(pwrdm-name, dpll, 4) == 0)
+ return 0;
+
+ d = debugfs_create_dir(pwrdm-name, (struct dentry *)dir);
+
+ (void) debugfs_create_file(suspend, S_IRUGO|S_IWUSR, d,
+ (void *)pwrdm, pwrdm_suspend_fops);
+
return 0;
}
@@ -508,7 +535,7 @@ static int __init pm_dbg_init(void)
(void) debugfs_create_file(time, S_IRUGO,
d, (void *)DEBUG_FILE_TIMERS, debug_fops);
- pwrdm_for_each(pwrdms_setup, NULL);
+ pwrdm_for_each(pwrdms_setup, (void *)d);
pm_dbg_dir = debugfs_create_dir(registers, d);
if (IS_ERR(pm_dbg_dir))
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 8fa8567..8400f57 100755
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -13,6 +13,9 @@
#include mach/powerdomain.h
+extern int omap3_pm_get_suspend_state(struct powerdomain *pwrdm);
+extern int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state);
+
#ifdef CONFIG_PM_DEBUG
extern void omap2_pm_dump(int mode, int resume, unsigned int us);
extern int omap2_pm_debug;
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 331dfca..26f2aca 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -664,6 +664,30 @@ static void __init prcm_setup_regs(void)
omap3_d2d_idle();
}
+int omap3_pm_get_suspend_state(struct powerdomain *pwrdm)
+{
+ struct power_state *pwrst;
+
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ if (pwrst-pwrdm == pwrdm)
+ return pwrst-next_state;
+ }
+ return -EINVAL;
+}
+
+int omap3_pm_set_suspend_state(struct powerdomain *pwrdm, int state)
+{
+ struct power_state *pwrst;
+
+ list_for_each_entry(pwrst, pwrst_list, node) {
+ if (pwrst-pwrdm == pwrdm) {
+ pwrst-next_state = state;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
--
1.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Runtime detection of Si features
Nishanth Menon had written, on 08/13/2009 11:43 AM, the following: Kevin Hilman had written, on 08/13/2009 11:40 AM, the following: Pandita, Vikram vikram.pand...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sent: Thursday, August 13, 2009 11:31 AM Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? We are hitting exactly this issue with I2C errata 1.153 Instead of basing the errata check on cpu_is...(), its more appropriate to base it on IP revision of I2C. Shouldn't the IP revision of I2C be avaialble in an I2C revision register an be used in the driver instead of cpu_is*? what I was proposing is a much more generic infrastructure which i2c among other modules can use. Getting IP revision is already available in the specific IP modules REVISION registers - we might want to standardize how drivers handle revision based feature/errata set to ensure that they would have an optimal way to handle the same.. just my 2 cents.. Thinking of this a little more: driver's smart handling aside, having a sysfs entry to dump the features and erratas for each of the modules used is so much nice to have.. sigh.. just wondering if anyone has ideas how feasible this might be.. -- 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] Runtime detection of Si features
Nishanth Menon n...@ti.com writes: Nishanth Menon had written, on 08/13/2009 11:43 AM, the following: Kevin Hilman had written, on 08/13/2009 11:40 AM, the following: Pandita, Vikram vikram.pand...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sent: Thursday, August 13, 2009 11:31 AM Since most of the code seemed repetitive, macros have been used for readability. Signed-off-by: Sanjeev Premi pr...@ti.com I like the feature-based approach. A couple questions though. Is there a bit/register that reports the collapsed powerdomains of the devices with modified PRCM? Also, how will other code query the features? You're currently exporting the omap_has_*() functions, but there are no prototypes. I think I'd rather see a static inline functions in mach/cpu.h for checking features. Comments to that end inlined below... Wonder if we can setup some sort of infrastructure for: a) features b) erratas linked to OMAP revs + even better w.r.t silicon module(SGX,I2c) revisions since at times they are used across multiple OMAPs? We are hitting exactly this issue with I2C errata 1.153 Instead of basing the errata check on cpu_is...(), its more appropriate to base it on IP revision of I2C. Shouldn't the IP revision of I2C be avaialble in an I2C revision register an be used in the driver instead of cpu_is*? what I was proposing is a much more generic infrastructure which i2c among other modules can use. Getting IP revision is already available in the specific IP modules REVISION registers - we might want to standardize how drivers handle revision based feature/errata set to ensure that they would have an optimal way to handle the same.. just my 2 cents.. Thinking of this a little more: driver's smart handling aside, having a sysfs entry to dump the features and erratas for each of the modules used is so much nice to have.. sigh.. just wondering if anyone has ideas how feasible this might be.. $SUBJECT patch will dump all the chip features during boot, and it shouldn't be much work too add this to /proc/cpuinfo either. The errata are another story and should be left to another patch IMHO since Sanjeev is just tring to get base 35xx support enabled for now. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support
Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, August 13, 2009 11:53 AM To: linux-arm-ker...@lists.arm.linux.org.uk; linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; Tero Kristo Subject: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support From: Tero Kristo tero.kri...@nokia.com Allows dumping out current register contents from the debug filesystem, and also allows user to add arbitrary register save points into code. Current register contents are available under debugfs at: [debugfs]/pm_debug/registers/current To add a save point, do following: From module init (or somewhere before the save call, called only once): pm_dbg_init_regset(n); // n=1..4, allocates memory for dump area #n From arbitrary code location: pm_dbg_regset_save(n); // n=1..4, saves registers to dump area #n After this, the register dump can be seen under [debugfs]/pm_debug/registers/n Signed-off-by: Tero Kristo tero.kri...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm-debug.c | 208 arch/arm/mach-omap2/pm.h |4 + 2 files changed, 212 insertions(+), 0 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/pm-debug.c mode change 100644 = 100755 arch/arm/mach-omap2/pm.h I guess these 755 mode changes weren't intentional... :) Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 10/10] OMAP: PM: Added suspend target state control to debugfs for OMAP3
Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, August 13, 2009 11:53 AM To: linux-arm-ker...@lists.arm.linux.org.uk; linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; Tero Kristo Subject: [PATCH 10/10] OMAP: PM: Added suspend target state control to debugfs for OMAP3 From: Tero Kristo tero.kri...@nokia.com Target state can be read / programmed via files under: [debugfs]/pm_debug/[pwrdm]/suspend Signed-off-by: Tero Kristo tero.kri...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm-debug.c | 31 +-- arch/arm/mach-omap2/pm.h |3 +++ arch/arm/mach-omap2/pm34xx.c | 24 3 files changed, 56 insertions(+), 2 deletions(-) mode change 100755 = 100644 arch/arm/mach-omap2/pm-debug.c diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm- debug.c old mode 100755 new mode 100644 And here one 755 mode change mistake in 6/10 is fixed... So, you'll need to refresh this aswell I guess... Regards, Sergio -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: update Pandora defconfig
This patch enables MMC, EHCI, OTG, GPIO LEDs, TWL4030 GPIO and sound drivers in Pandora's defconfig. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- FYI, OMAP3: defconfigs: remove SYSFS_DEPRECATED flag still applies cleanly after this. arch/arm/configs/omap3_pandora_defconfig | 401 +- 1 files changed, 288 insertions(+), 113 deletions(-) diff --git a/arch/arm/configs/omap3_pandora_defconfig b/arch/arm/configs/omap3_pandora_defconfig index b54ad2e..898fd79 100644 --- a/arch/arm/configs/omap3_pandora_defconfig +++ b/arch/arm/configs/omap3_pandora_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.28-rc7 -# Fri Dec 5 11:54:09 2008 +# Linux kernel version: 2.6.31-rc5-omap1 +# Thu Aug 13 22:00:47 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -9,7 +9,6 @@ CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_MMU=y -# CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -18,13 +17,12 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -42,6 +40,15 @@ CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 @@ -57,8 +64,12 @@ CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set @@ -69,17 +80,21 @@ CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y -CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y -CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Performance Counters +# CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_STRIP_ASM_SYMS is not set +CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set @@ -90,10 +105,14 @@ CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y -# CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set @@ -101,11 +120,8 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y -CONFIG_KMOD=y CONFIG_BLOCK=y -# CONFIG_LBD is not set -# CONFIG_BLK_DEV_IO_TRACE is not set -# CONFIG_LSF is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -121,7 +137,6 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory -CONFIG_CLASSIC_RCU=y # CONFIG_FREEZER is not set # @@ -132,14 +147,15 @@ CONFIG_CLASSIC_RCU=y # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set -# CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set +# CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -148,22 +164,25 @@ CONFIG_CLASSIC_RCU=y # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set -# CONFIG_ARCH_KS8695 is not set -# CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set -# CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_MSM is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set +# CONFIG_ARCH_S3C64XX is not set # CONFIG_ARCH_SHARK is not set #
[PATCH 08/13] DSPBRIDGE: Use pr_ctxt in DRV_RemoveProcContext
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
---
.../plat-omap/include/dspbridge/resourcecleanup.h |2 +-
drivers/dsp/bridge/rmgr/drv.c | 36 +++-
drivers/dsp/bridge/rmgr/drv_interface.c|4 +-
3 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
index b43fa16..5592f38 100644
--- a/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
+++ b/arch/arm/plat-omap/include/dspbridge/resourcecleanup.h
@@ -43,7 +43,7 @@ extern DSP_STATUS DRV_GetProcContext(u32 phProcess,
extern DSP_STATUS DRV_RemoveAllResources(HANDLE pPctxt);
extern DSP_STATUS DRV_RemoveProcContext(struct DRV_OBJECT *hDRVObject,
-HANDLE hPCtxt, HANDLE hProcess);
+HANDLE hPCtxt);
extern DSP_STATUS DRV_GetNodeResElement(HANDLE hNode, HANDLE nodeRes,
HANDLE pCtxt);
diff --git a/drivers/dsp/bridge/rmgr/drv.c b/drivers/dsp/bridge/rmgr/drv.c
index e64b997..a13932c 100644
--- a/drivers/dsp/bridge/rmgr/drv.c
+++ b/drivers/dsp/bridge/rmgr/drv.c
@@ -317,36 +317,40 @@ DSP_STATUS DRV_InsertProcContext(struct DRV_OBJECT
*hDrVObject, HANDLE hPCtxt)
/* Delete a process context from process resource context list */
DSP_STATUS DRV_RemoveProcContext(struct DRV_OBJECT *hDRVObject,
-HANDLE hPCtxt, HANDLE hProcess)
+ HANDLE pr_ctxt)
{
DSP_STATUS status = DSP_SOK;
- struct PROCESS_CONTEXT*pCtxt2 = NULL;
- struct PROCESS_CONTEXT*pTmp = NULL;
- struct PROCESS_CONTEXT*pCtxtList = NULL;
+ struct PROCESS_CONTEXT *pr_ctxt_list = NULL;
+ struct PROCESS_CONTEXT *ptr_prev;
DBC_Assert(hDRVObject != NULL);
- DRV_GetProcContext((u32)hProcess, hDRVObject, pCtxt2, NULL, 0);
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 12);
- DRV_GetProcCtxtList(pCtxtList, hDRVObject);
+ DRV_GetProcCtxtList(pr_ctxt_list, hDRVObject);
+
+ /* Special condition */
+ if (pr_ctxt_list == pr_ctxt) {
+ hDRVObject-procCtxtList = NULL;
+ goto func_cont;
+ }
+
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 13);
- pTmp = pCtxtList;
- while ((pCtxtList != NULL) (pCtxtList != pCtxt2)) {
- pTmp = pCtxtList;
- pCtxtList = pCtxtList-next;
+ while (pr_ctxt_list (pr_ctxt_list != pr_ctxt)) {
+ ptr_prev = pr_ctxt_list;
+ pr_ctxt_list = pr_ctxt_list-next;
GT_0trace(curTrace, GT_ENTER,
DRV_RemoveProcContext: 2);
}
+
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 3);
- if (hDRVObject-procCtxtList == pCtxt2)
- hDRVObject-procCtxtList = pCtxt2-next;
- if (pCtxtList == NULL)
+ if (!pr_ctxt_list)
return DSP_ENOTFOUND;
- else if (pTmp-next != NULL)
- pTmp-next = pTmp-next-next;
+ else
+ ptr_prev-next = pr_ctxt_list-next;
- MEM_Free(pCtxt2);
+func_cont:
+ MEM_Free(pr_ctxt);
GT_0trace(curTrace, GT_ENTER, DRV_RemoveProcContext: 7);
return status;
diff --git a/drivers/dsp/bridge/rmgr/drv_interface.c
b/drivers/dsp/bridge/rmgr/drv_interface.c
index 1cb3d74..fa79695 100644
--- a/drivers/dsp/bridge/rmgr/drv_interface.c
+++ b/drivers/dsp/bridge/rmgr/drv_interface.c
@@ -481,7 +481,7 @@ static int __devexit omap34xx_bridge_remove(struct
platform_device *pdev)
}
pTmp = pCtxtclosed-next;
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
-pCtxtclosed, (void *)pCtxtclosed-pid);
+ pCtxtclosed);
pCtxtclosed = pTmp;
}
@@ -630,7 +630,7 @@ static int bridge_release(struct inode *ip, struct file
*filp)
PROC_Detach(proc_obj_ptr, pr_ctxt);
}
DRV_RemoveProcContext((struct DRV_OBJECT *)hDrvObject,
- pr_ctxt, (void *)pr_ctxt-pid);
+ pr_ctxt);
} else {
status = -EIO;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
From: Jon Hunter jon-hun...@ti.com
This is version 2 of this patch. I have incorporated the changes
recommended by Kevin Hilman.
Depending on the OMAP3 boot mode the MUSB peripheral may or may not be
accessible when the kernel starts.
The OMAP3 can boot from several devices including USB. The sequence of the
devices the OMAP will attempt to boot from is configured via the sys_boot
pins on the device. If USB is one of the devices the OMAP boot ROM attempts
to boot from on power-on, then the interface clock to the MUSB peripheral
will be enabled by the boot ROM and the MUSB peripheral will be accessible
when the kernel boots. However, if USB is not one of the devices OMAP
attempts to boot from, then the interface clock is not enabled and the MUSB
peripheral will not be accessible on start-up.
If the MUSB peripheral is not accessible when the kernel boots, then the
kernel will crash when attempting to access the OTG_SYSCONFIG in the
function musb_platform_init(). The actual cause of the crash is the write
to the OTG_SYSCONFIG register in the function usb_musb_pm_init() to reset
the MUSB peripheral which occurs prior to calling musb_platform_init().
The function usb_musb_pm_init() does not check to see if the interface
clock for the MUSB peripheral is enabled before writing to MUSB register.
This write access does not generate a data-abort at this point, but because
this write does not complete all future accesses to the MUSB controller will
generate data-aborts regardless of whether the interface clock has been
enabled at a later stage. The only way I have found to recover from this is
resetting the device. My understanding is that the interconnect works in
this way to prevent a bad access locking up the system.
This patch ensures the interface clock for the MUSB in the function
usb_musb_pm_init() is enabled. This patch also ensures that the interface
clock is disabled after the reset is complete. My reasoning for always
disabling the clock rather than maintaing its state is:
1). If the MUSB peripheral is not being used then the interface clock should
be disabled.
2). The musb_set_clock() function uses a static variable called clk_on to
determine if the MUSB interface clock is on or off. On boot-up clk_on will
be 0 and so this function assumes that the clock is off by default which
may not be the case in the current code.
I have also added a while-loop to wait for the reset of the MUSB module to
complete before this function exits and the interface clock it disabled.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/usb-musb.c | 34 +++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3efa19c..247f653 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -35,10 +35,20 @@
#define OTG_SYSCONFIG 0x404
#define OTG_SYSC_SOFTRESET BIT(1)
+#define OTG_SYSSTATUS 0x408
+#define OTG_SYSS_RESETDONE BIT(0)
+
+static struct platform_device dummy_pdev = {
+ .dev = {
+ .bus = platform_bus_type,
+ },
+};
static void __init usb_musb_pm_init(void)
{
void __iomem *otg_base;
+ struct clk *otg_clk;
+ struct device *dev = dummy_pdev.dev;
if (!cpu_is_omap34xx())
return;
@@ -47,9 +57,27 @@ static void __init usb_musb_pm_init(void)
if (WARN_ON(!otg_base))
return;
- /* Reset OTG controller. After reset, it will be in
-* force-idle, force-standby mode. */
- __raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+ dev_set_name(dev, musb_hdrc);
+ otg_clk = clk_get(dev, ick);
+
+ if (otg_clk clk_enable(otg_clk)) {
+ printk(KERN_WARNING
+ %s: Unable to enable clocks for MUSB,
+ cannot reset.\n, __func__);
+ } else {
+ /* Reset OTG controller. After reset, it will be in
+* force-idle, force-standby mode. */
+ __raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+
+ while (!(OTG_SYSS_RESETDONE
+ __raw_readl(otg_base + OTG_SYSSTATUS)))
+ cpu_relax();
+ }
+
+ if (otg_clk) {
+ clk_disable(otg_clk);
+ clk_put(otg_clk);
+ }
iounmap(otg_base);
}
--
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
Re: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support
Aguirre Rodriguez, Sergio Alberto saagui...@ti.com writes: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, August 13, 2009 11:53 AM To: linux-arm-ker...@lists.arm.linux.org.uk; linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; Tero Kristo Subject: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support From: Tero Kristo tero.kri...@nokia.com Allows dumping out current register contents from the debug filesystem, and also allows user to add arbitrary register save points into code. Current register contents are available under debugfs at: [debugfs]/pm_debug/registers/current To add a save point, do following: From module init (or somewhere before the save call, called only once): pm_dbg_init_regset(n); // n=1..4, allocates memory for dump area #n From arbitrary code location: pm_dbg_regset_save(n); // n=1..4, saves registers to dump area #n After this, the register dump can be seen under [debugfs]/pm_debug/registers/n Signed-off-by: Tero Kristo tero.kri...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm-debug.c | 208 arch/arm/mach-omap2/pm.h |4 + 2 files changed, 212 insertions(+), 0 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/pm-debug.c mode change 100644 = 100755 arch/arm/mach-omap2/pm.h I guess these 755 mode changes weren't intentional... :) Indeed, they were not. 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: [PATCHv2] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
Jon Hunter jon-hun...@ti.com writes:
This is version 2 of this patch. I have incorporated the changes
recommended by Kevin Hilman.
Depending on the OMAP3 boot mode the MUSB peripheral may or may not be
accessible when the kernel starts.
The OMAP3 can boot from several devices including USB. The sequence of the
devices the OMAP will attempt to boot from is configured via the sys_boot
pins on the device. If USB is one of the devices the OMAP boot ROM attempts
to boot from on power-on, then the interface clock to the MUSB peripheral
will be enabled by the boot ROM and the MUSB peripheral will be accessible
when the kernel boots. However, if USB is not one of the devices OMAP
attempts to boot from, then the interface clock is not enabled and the MUSB
peripheral will not be accessible on start-up.
If the MUSB peripheral is not accessible when the kernel boots, then the
kernel will crash when attempting to access the OTG_SYSCONFIG in the
function musb_platform_init(). The actual cause of the crash is the write
to the OTG_SYSCONFIG register in the function usb_musb_pm_init() to reset
the MUSB peripheral which occurs prior to calling musb_platform_init().
The function usb_musb_pm_init() does not check to see if the interface
clock for the MUSB peripheral is enabled before writing to MUSB register.
This write access does not generate a data-abort at this point, but because
this write does not complete all future accesses to the MUSB controller will
generate data-aborts regardless of whether the interface clock has been
enabled at a later stage. The only way I have found to recover from this is
resetting the device. My understanding is that the interconnect works in
this way to prevent a bad access locking up the system.
This patch ensures the interface clock for the MUSB in the function
usb_musb_pm_init() is enabled. This patch also ensures that the interface
clock is disabled after the reset is complete. My reasoning for always
disabling the clock rather than maintaing its state is:
1). If the MUSB peripheral is not being used then the interface clock should
be disabled.
2). The musb_set_clock() function uses a static variable called clk_on to
determine if the MUSB interface clock is on or off. On boot-up clk_on will
be 0 and so this function assumes that the clock is off by default which
may not be the case in the current code.
I have also added a while-loop to wait for the reset of the MUSB module to
complete before this function exits and the interface clock it disabled.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Jon, you're raising the bar and spoiling us with such descriptive
changelogs. If everyone was as thorough as you, the world would be a
merrier place. :)
Thanks, pushing to PM branch and pm-2.6.29.
Kevin
arch/arm/mach-omap2/usb-musb.c | 34 +++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3efa19c..247f653 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -35,10 +35,20 @@
#define OTG_SYSCONFIG 0x404
#define OTG_SYSC_SOFTRESET BIT(1)
+#define OTG_SYSSTATUS 0x408
+#define OTG_SYSS_RESETDONE BIT(0)
+
+static struct platform_device dummy_pdev = {
+ .dev = {
+ .bus = platform_bus_type,
+ },
+};
static void __init usb_musb_pm_init(void)
{
void __iomem *otg_base;
+ struct clk *otg_clk;
+ struct device *dev = dummy_pdev.dev;
if (!cpu_is_omap34xx())
return;
@@ -47,9 +57,27 @@ static void __init usb_musb_pm_init(void)
if (WARN_ON(!otg_base))
return;
- /* Reset OTG controller. After reset, it will be in
- * force-idle, force-standby mode. */
- __raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+ dev_set_name(dev, musb_hdrc);
+ otg_clk = clk_get(dev, ick);
+
+ if (otg_clk clk_enable(otg_clk)) {
+ printk(KERN_WARNING
+ %s: Unable to enable clocks for MUSB,
+ cannot reset.\n, __func__);
+ } else {
+ /* Reset OTG controller. After reset, it will be in
+ * force-idle, force-standby mode. */
+ __raw_writel(OTG_SYSC_SOFTRESET, otg_base + OTG_SYSCONFIG);
+
+ while (!(OTG_SYSS_RESETDONE
+ __raw_readl(otg_base + OTG_SYSSTATUS)))
+ cpu_relax();
+ }
+
+ if (otg_clk) {
+ clk_disable(otg_clk);
+ clk_put(otg_clk);
+ }
iounmap(otg_base);
}
--
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
Re: [PATCHv2] OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it
Kevin Hilman khil...@deeprootsystems.com writes: Jon Hunter jon-hun...@ti.com writes: This is version 2 of this patch. I have incorporated the changes recommended by Kevin Hilman. [...] Thanks, pushing to PM branch and pm-2.6.29. Just FYI in case you cant find this patch in the PM branch. While rebasing the PM branch, I grouped this patch along with hwmod and the MMC reset removal so you wont set it on the tip of the PM branch. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support
Kevin Hilman khil...@deeprootsystems.com writes: Aguirre Rodriguez, Sergio Alberto saagui...@ti.com writes: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, August 13, 2009 11:53 AM To: linux-arm-ker...@lists.arm.linux.org.uk; linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; Tero Kristo Subject: [PATCH 06/10] OMAP: PM debug: Add PRCM register dump support From: Tero Kristo tero.kri...@nokia.com Allows dumping out current register contents from the debug filesystem, and also allows user to add arbitrary register save points into code. Current register contents are available under debugfs at: [debugfs]/pm_debug/registers/current To add a save point, do following: From module init (or somewhere before the save call, called only once): pm_dbg_init_regset(n); // n=1..4, allocates memory for dump area #n From arbitrary code location: pm_dbg_regset_save(n); // n=1..4, saves registers to dump area #n After this, the register dump can be seen under [debugfs]/pm_debug/registers/n Signed-off-by: Tero Kristo tero.kri...@nokia.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/pm-debug.c | 208 arch/arm/mach-omap2/pm.h |4 + 2 files changed, 212 insertions(+), 0 deletions(-) mode change 100644 = 100755 arch/arm/mach-omap2/pm-debug.c mode change 100644 = 100755 arch/arm/mach-omap2/pm.h I guess these 755 mode changes weren't intentional... :) Indeed, they were not. Thanks. OK, fixed these locally but not worth a repost. These will be updated in the version pushed for pull request when reviewed/accepted. 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: [PATCHv3 14/20] OMAP: McBSP: Let element DMA mode hit retention also
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Eduardo Valentin The device no longer hits retention if element DMA mode is taken for at least the duration of the serial console timeout. Force element DMA mode to shut down through smartidle. Probably this behaves as you say but it seems possible that the bug is somewhere else in device handling. The generic hope is you can set smart-idle + wakeups at init time and never need to touch them again. There are a few known cases where the hardware IP does have some bug which force you to dynamically play with bits. Clockactivity settings are usually static also, but depending on how you configure your device (slave or master clocking) you will need to dynamically set these. It most you don't need all this dynamic twiddling of the idle protocol handshake bits. Doing it once at pm_init is what should be necessary. One example which comes to mind is MMC with DMA mode. Early drivers were finding RET was gated once the driver was active. In the first pass port to 3430 the writer toggled smart/no/forced idle and the system went happily back to sleep. However, after some profiling it was seen that this method of putting the device down ended up causing the clock disable to the device to take a very long time. Another level of digging into documents was done and it was found that it was necessary to reset some command line as part of a clean shut down. Doing it this way allowed the system to idle, and the time to shut down clocks was just a few nS instead of uS. As I recall some status was not cleared until the reset of the line. It did happen that toggling through handshakes had a side effect of also clearing it, but not in the intended way. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv3 14/20] OMAP: McBSP: Let element DMA mode hit retention also
On Fri, 2009-08-14 at 05:19 +0200, ext Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Eduardo Valentin The device no longer hits retention if element DMA mode is taken for at least the duration of the serial console timeout. Force element DMA mode to shut down through smartidle. Probably this behaves as you say but it seems possible that the bug is somewhere else in device handling. For some reason unknown to us, if NO_IDLE mode is taken, and long enough of a arecord | aplay loop was tried (a minute or so), then, and when closing the loop, the device never hit retention anymore =) But after the fix, yes it does so. The generic hope is you can set smart-idle + wakeups at init time and never need to touch them again. There are a few known cases where the hardware IP does have some bug which force you to dynamically play with bits. Right. I did try to set them initially at device init (that was one of the first things I tried with McBSP), but things were not really working as expected. (Well, having iclk and fclk on and putting those at device init caused the whole HW device to jam). Another thing is, that if the McBSP is a slave (external clocking), then there will be unnecessary wakeups? If smart-idle + wakeups are always set? (and the slave clocks the McBSP WCLK and BCLK). BTW, are the wakeups active if McBSP is in reset state? Clockactivity settings are usually static also, but depending on how you configure your device (slave or master clocking) you will need to dynamically set these. It most you don't need all this dynamic twiddling of the idle protocol handshake bits. Doing it once at pm_init is what should be necessary. One example which comes to mind is MMC with DMA mode. Early drivers were finding RET was gated once the driver was active. In the first pass port to 3430 the writer toggled smart/no/forced idle and the system went happily back to sleep. However, after some profiling it was seen that this method of putting the device down ended up causing the clock disable to the device to take a very long time. Another level of digging into documents was done and it was found that it was necessary to reset some command line as part of a clean shut down. Doing it this way allowed the system to idle, and the time to shut down clocks was just a few nS instead of uS. As I recall some status was not cleared until the reset of the line. It did happen that toggling through handshakes had a side effect of also clearing it, but not in the intended way. Whether a few uSec:s or nS:s, doesn't really matter in this case? (if that even was the case). Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
