Re: [PATCH] OMAP: DSS2: Add back authors of panel-generic.c based drivers
On Thu, 2010-11-18 at 09:45 +0800, ext Bryan Wu wrote: Signed-off-by: Bryan Wu bryan...@canonical.com --- drivers/video/omap2/displays/panel-generic-dpi.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c b/drivers/video/omap2/displays/panel-generic-dpi.c index 6702cf6..07eb30e 100644 --- a/drivers/video/omap2/displays/panel-generic-dpi.c +++ b/drivers/video/omap2/displays/panel-generic-dpi.c @@ -4,6 +4,16 @@ * Copyright (C) 2010 Canonical Ltd. * Author: Bryan Wu bryan...@canonical.com * + * LCD panel driver for Sharp LQ043T1DG01 + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Vaibhav Hiremath hvaib...@ti.com + * + * LCD panel driver for Toppoly TDO35S + * + * Copyright (C) 2009 CompuLab, Ltd. + * Author: Mike Rapoport m...@compulab.co.il + * * Copyright (C) 2008 Nokia Corporation * Author: Tomi Valkeinen tomi.valkei...@nokia.com * Thanks, applied. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #8)
On Thu, 2010-11-18 at 10:14 +0800, ext Bryan Wu wrote: On Wed, Nov 17, 2010 at 10:18 PM, Tomi Valkeinen Are you also interested in solving the backlight issue? =) Yeah, can I start with drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c. I plan to move the blacklight code to drivers/video/blacklight/ and let sharp_ls to use panel-generic-dpi.c driver. Yes, I think that's a good solution for the panels which have a separate backlight (ie. all these dummy panels). However, I'm not sure how that would work for panels with more integrated backlight, for example Taal. But we don't need to worry about that right now. Tomi -- To unsubscribe from this list: send the line unsubscribe 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] i2c-omap: Set latency requirements only once for several messages
Ordinary I2C read consist of two messages. First a write operation
to tell register address and then read operation to get data.
CPU wake up latency is set and removed twice in read case.
Set latency requirement before the message processing loop
and remove the requirement after the loop to remove latency
adjustment operations between the messages.
Signed-off-by: Samu Onkalo samu.p.onk...@nokia.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Acked-by: Paul Walmsley p...@pwsan.com
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b33c785..3e9323e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -616,12 +616,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
* REVISIT: We should abort the transfer on signals, but the bus goes
* into arbitration and we're currently unable to recover from it.
*/
- if (dev-set_mpu_wkup_lat != NULL)
- dev-set_mpu_wkup_lat(dev-dev, dev-latency);
r = wait_for_completion_timeout(dev-cmd_complete,
OMAP_I2C_TIMEOUT);
- if (dev-set_mpu_wkup_lat != NULL)
- dev-set_mpu_wkup_lat(dev-dev, -1);
dev-buf_len = 0;
if (r 0)
return r;
@@ -672,12 +668,18 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r 0)
goto out;
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-set_mpu_wkup_lat(dev-dev, dev-latency);
+
for (i = 0; i num; i++) {
r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num - 1)));
if (r != 0)
break;
}
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-set_mpu_wkup_lat(dev-dev, -1);
+
if (r == 0)
r = num;
--
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
[PATCH v3] OMAP2+: PM: omap device: API's for handling mstandby mode
Certain errata's in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
releases no standby mode and sets it to smart standby or no
standby˝ depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata's which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata's:
1. Errata ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Errata ID: i541(all omap2plus except omap4)
sDMA FIFO draining does not finish
3. OMAP3430 ES1.0(Errata ID:i88) will require DMA to be put in
no mstandby mode before disabling the channel after completing
the data transfer operation.
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v2: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
arch/arm/mach-omap2/omap_hwmod.c | 45 +++-
arch/arm/plat-omap/include/plat/omap_device.h |3 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +-
arch/arm/plat-omap/omap_device.c | 73 +
4 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..9c1c2fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,50 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+ sf = oh-class-sysc-sysc_flags;
+
+ if (sf SYSC_HAS_MIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ }
+ retval = _set_master_standbymode(oh, idlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ return retval;
+}
+
+/**
* omap_hwmod_register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2116,4 +2160,3 @@ int omap_hwmod_for_each_by_class(const char *classname,
return ret;
}
-
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..14a6c46 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -109,13 +109,14 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
/* Other */
-
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7eaa8ed..c7ff65a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -354,7 +354,7 @@ struct omap_hwmod_omap4_prcm {
*
* HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
* of idle,
Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init
Thomas Petazzoni had written, on 11/16/2010 07:20 AM, the following: would prevent you from having no OPP table (the case where a NULL OPP table is passed is tested *before* in omapX_init_opp()). HUH?? NULL table to a static function - what code are you talking about?? why are you so behind BUG_ON, when there are valid reasons for reentry into code. In the current design, yes, there are indeed valid reasons for reentry into the omapX_init_opp() function, and that's exactly the point I'm critizicing here. how about: if (omap_table_init) return -EEXIST; does that make it better? it still retains the ability to handle both kinds of platforms as well as not BUG out. -- 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] omap: nand: remove hardware ECC as default
CONFIG_MTD_NAND_OMAP_HWECC defined wronly in patch submitted during 2.6.36 that using the hardware ECC by default Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- drivers/mtd/nand/omap2.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index cd41c58..15682ec 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -7,7 +7,6 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#define CONFIG_MTD_NAND_OMAP_HWECC #include linux/platform_device.h #include linux/dma-mapping.h -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: No more software ECC in omap2.c NAND driver. Why?
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Charles Manning Sent: Thursday, November 18, 2010 6:36 AM To: linux-omap@vger.kernel.org Subject: No more software ECC in omap2.c NAND driver. Why? Between 2.6.35 and 2.6.36 there have need quite a few changes in the NAND driver, including a change from software to hardware ECC. The new code has hardware ECC forced on by: #define CONFIG_MTD_NAND_OMAP_HWECC I am surprised that this was done. Surely this should have been a Kconfig option to select either sw ECC or hw ECC? Does moving to hardware ECC to the exclusion of software ECC reduce functionality? [Ghorai] This is wrongly added by me, during last few patches. So I have send the fix as you mentioned too as. [PATCH] omap: nand: remove hardware ECC as default And please let me know still if it has any issue. And I am re-working on the patches for the different ecc schema including s/w, h/w or different, to pass it form board file. Does the new hwecc scheme still support sub-page writes or does it only provide full page writes? If sub-page writes are lost then this has a ripple effect in breaking the way some UBI stuff works. [Ghorai] 1. do you think this sub-page read/write support was there before, say in 2.6.35? And breaks in 2.6.36? 2. In that case would you please let know what are the size(s) used for sub-page/read write? -- Charles -- To unsubscribe from this list: send the line unsubscribe 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
OMAP3 sleep code clean-up
Vishwanath BS vishwanath...@ti.com, Jean Pihet j-pi...@ti.com: [PATCH 1/2]: OMAP3 PM: move omap3 sleep to ddr For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. [PATCH 2/2] OMAP3: clean up ASM idle code Clean up of the ASM code: - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - reworked the comments for better readability, - reworked the code formating and alignment, - added comments for the i443 errata workarounds, - replaced the cache flush code by a call to the kernel common code for ARMv7 (v7_flush_kern_cache_all), which is better maintained and so more mature, - clean up of non used symbols. Tested on Zoom3, OMAP3EVM, Beagleboard, n900 with full RET and OFF mode. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Changed the commit comments.
Cc: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain *clkdm,
void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP3: clean up ASM idle code
From: Vishwanath BS vishwanath...@ti.com Clean up of the ASM code: - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - reworked the comments for better readability, - reworked the code formating and alignment, - added comments for the i443 errata workarounds, - replaced the cache flush code by a call to the kernel common code for ARMv7 (v7_flush_kern_cache_all), which is better maintained and so more mature, - clean up of non used symbols. Tested on Zoom3, OMAP3EVM, Beagleboard, n900 with full RET and OFF mode. Signed-off-by: Vishwanath BS vishwanath...@ti.com Heavily reworked from Vishwa's original patch. Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/control.h |2 + arch/arm/mach-omap2/pm.h|6 +- arch/arm/mach-omap2/pm34xx.c|4 +- arch/arm/mach-omap2/sleep34xx.S | 354 +++ 4 files changed, 143 insertions(+), 223 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index b6c6b7c..78f7f19 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -270,6 +270,8 @@ #define OMAP343X_SCRATCHPAD_ROM(OMAP343X_CTRL_BASE + 0x860) #define OMAP343X_SCRATCHPAD(OMAP343X_CTRL_BASE + 0x910) #define OMAP343X_SCRATCHPAD_ROM_OFFSET 0x19C +#define OMAP343X_SCRATCHPAD_REGADDR(reg) OMAP2_L4_IO_ADDRESS(\ + OMAP343X_SCRATCHPAD + reg) /* AM35XX_CONTROL_IPSS_CLK_CTRL bits */ #define AM35XX_USBOTG_VBUSP_CLK_SHIFT 0 diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h index 0d75bfd..9ff051d 100644 --- a/arch/arm/mach-omap2/pm.h +++ b/arch/arm/mach-omap2/pm.h @@ -75,14 +75,12 @@ extern void omap24xx_idle_loop_suspend(void); extern void omap24xx_cpu_suspend(u32 dll_ctrl, void __iomem *sdrc_dlla_ctrl, void __iomem *sdrc_power); -extern void omap34xx_cpu_suspend(u32 *addr, int save_state); + +extern void omap34xx_save_cpu_context_wfi(u32 *addr, int save_state); extern void save_secure_ram_context(u32 *addr); extern void omap3_save_scratchpad_contents(void); extern unsigned int omap24xx_idle_loop_suspend_sz; -extern unsigned int omap34xx_suspend_sz; extern unsigned int save_secure_ram_context_sz; extern unsigned int omap24xx_cpu_suspend_sz; -extern unsigned int omap34xx_cpu_suspend_sz; - #endif diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 035ca47..18ad1ed 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -404,7 +404,7 @@ void omap_sram_idle(void) /* * On EMU/HS devices ROM code restores a SRDC value * from scratchpad which has automatic self refresh on timeout - * of AUTO_CNT = 1 enabled. This takes care of errata 1.142. + * of AUTO_CNT = 1 enabled. This takes care of errata ID i443. * Hence store/restore the SDRC_POWER register here. */ if (omap_rev() = OMAP3430_REV_ES3_0 @@ -417,7 +417,7 @@ void omap_sram_idle(void) * get saved. The restore path then reads from this * location and restores them back. */ - omap34xx_cpu_suspend(omap3_arm_context, save_state); + omap34xx_save_cpu_context_wfi(omap3_arm_context, save_state); cpu_init(); /* Restore normal SDRC POWER settings */ diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2fb205a..47a0d36 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -33,21 +33,21 @@ #include sdrc.h #include control.h -#define SDRC_SCRATCHPAD_SEM_V 0xfa00291c - -#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \ - OMAP3430_PM_PREPWSTST) -#define PM_PREPWSTST_CORE_P0x48306AE8 -#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \ - OMAP3430_PM_PREPWSTST) +#define SDRC_SCRATCHPAD_SEM_OFFS 0xc +#define SDRC_SCRATCHPAD_SEM_V OMAP343X_SCRATCHPAD_REGADDR\ + (SDRC_SCRATCHPAD_SEM_OFFS) +#define PM_PREPWSTST_CORE_POMAP3430_PRM_BASE + CORE_MOD +\ + OMAP3430_PM_PREPWSTST #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) #define SRAM_BASE_P0x4020 -#define CONTROL_STAT 0x480022F0 -#define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is - * available */ +#define CONTROL_STAT OMAP343X_CTRL_BASE + OMAP343X_CONTROL_STATUS + +/* Move this as correct place is available */ +#define SCRATCHPAD_MEM_OFFS0x310 + #define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ - + SCRATCHPAD_MEM_OFFS) +
RE: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which cannot be handled with this - RTA disable
- errata i608
You need to disable RTA while coming out of OFF - we cannot handle this on
GP devices if this is not done.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Changed the commit comments.
Cc: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3 PM: move omap3 sleep to ddr
NIshant,
On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Jean Pihet
Sent: Thursday, November 18, 2010 8:52 AM
To: linux-omap@vger.kernel.org
Cc: Vishwanath BS; Kevin Hillman; Jean Pihet
Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
From: Vishwanath BS vishwanath...@ti.com
For historical reasons the OMAP3 sleep code is run from SRAM.
This code can run from DDR which provides better performance and
leaves the SRAM available for other uses.
Tested on ZOOM3, OMAP3EVM, Beagleboard, n900
with full RET and OFF modes.
Sorry, But I disagree with this patch.
There is a silicon errata which cannot be handled with this - RTA disable
- errata i608
You need to disable RTA while coming out of OFF - we cannot handle this on
GP devices if this is not done.
When you come out of Core off, SRAM contents are anyway lost. So you
have to run from DDR after ROM Code completes. This behavior has not
changed with this patch. I fail to understand your concern here.
Vishwa
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Kevin Hillman khil...@deeprootsystems.com
Changed the commit comments.
Cc: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 9 +
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..035ca47 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -65,8 +65,6 @@ struct power_state {
static LIST_HEAD(pwrst_list);
-static void (*_omap_sram_idle)(u32 *addr, int save_state);
-
static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
@@ -346,9 +344,6 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
- if (!_omap_sram_idle)
- return;
-
pwrdm_clear_all_prev_pwrst(mpu_pwrdm);
pwrdm_clear_all_prev_pwrst(neon_pwrdm);
pwrdm_clear_all_prev_pwrst(core_pwrdm);
@@ -422,7 +417,7 @@ void omap_sram_idle(void)
* get saved. The restore path then reads from this
* location and restores them back.
*/
- _omap_sram_idle(omap3_arm_context, save_state);
+ omap34xx_cpu_suspend(omap3_arm_context, save_state);
cpu_init();
/* Restore normal SDRC POWER settings */
@@ -972,8 +967,6 @@ static int __init clkdms_setup(struct clockdomain
*clkdm, void *unused)
void omap_push_sram_idle(void)
{
- _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
- omap34xx_cpu_suspend_sz);
if (omap_type() != OMAP2_DEVICE_TYPE_GP)
_omap_save_secure_sram =
omap_sram_push(save_secure_ram_context,
save_secure_ram_context_sz);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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] OMAP3 PM: move omap3 sleep to ddr
-Original Message- From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com] Sent: Thursday, November 18, 2010 9:09 AM To: Nishanth Menon Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean Pihet-XID Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr NIshant, On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Thursday, November 18, 2010 8:52 AM To: linux-omap@vger.kernel.org Cc: Vishwanath BS; Kevin Hillman; Jean Pihet Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. When you come out of Core off, SRAM contents are anyway lost. So you have to run from DDR after ROM Code completes. This behavior has not changed with this patch. I fail to understand your concern here. I could potentially be mistaken. Let me do one thing - I will post out the patches that I have to the list and we can see how this all works together. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Hi Nishant, On Thu, Nov 18, 2010 at 4:11 PM, Nishanth Menon n...@ti.com wrote: -Original Message- From: Sripathy, Vishwanath [mailto:vishwanath...@ti.com] Sent: Thursday, November 18, 2010 9:09 AM To: Nishanth Menon Cc: Jean Pihet; linux-omap@vger.kernel.org; Kevin Hillman; Jean Pihet-XID Subject: Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr NIshant, On Thu, Nov 18, 2010 at 8:27 PM, Nishanth Menon n...@ti.com wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Jean Pihet Sent: Thursday, November 18, 2010 8:52 AM To: linux-omap@vger.kernel.org Cc: Vishwanath BS; Kevin Hillman; Jean Pihet Subject: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. When you come out of Core off, SRAM contents are anyway lost. So you have to run from DDR after ROM Code completes. This behavior has not changed with this patch. I fail to understand your concern here. I could potentially be mistaken. Let me do one thing - I will post out the patches that I have to the list and we can see how this all works together Ok, fine. I did not find any 36xx specific workaround for the errata i608 issue. Is there one already available? Thanks, Jean 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 v2] OMAP: DSS2: OMAPFB: Add null pointer check
On Tue, 2010-11-16 at 12:49 +0100, ext Samreen wrote: A null pointer check added. And using kstrdup() instead of kmalloc() strcpy() Signed-off-by: Samreen samr...@ti.com --- Version2: - Using kstrdup() instead of kmalloc() strcpy() - Using ENOMEM as error code instead of EINVAL - Subject changed appropriately The link to v1 of patch is: https://patchwork.kernel.org/patch/319642/ Thanks, applied. Tomi -- To unsubscribe from this list: send the line unsubscribe 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] OMAP3 PM: move omap3 sleep to ddr
-Original Message- From: Jean Pihet [mailto:jean.pi...@newoldbits.com] Sent: Thursday, November 18, 2010 9:15 AM [...] Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. When you come out of Core off, SRAM contents are anyway lost. So you have to run from DDR after ROM Code completes. This behavior has not changed with this patch. I fail to understand your concern here. I could potentially be mistaken. Let me do one thing - I will post out the patches that I have to the list and we can see how this all works together Ok, fine. I did not find any 36xx specific workaround for the errata i608 issue. Is there one already available? Yes, I have a series of patches addressing that as well.. hoping to test On EMU/HS devices prior to posting - GP devices (3430/3630) tested. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
Nishanth Menon n...@ti.com writes: From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. You need to provide some more details here as to exactly why this patch prevents the ability to do this workaround. As Vishwa pointed out, when returning from OFF mode, current code already starts in DDR since SRAM is lost. The current code also already can jump back into SRAM for certain errata/fixup (c.f. es3_sdrc_fix in current code.) 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 v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
* Paul Mundt let...@linux-sh.org [101117 22:09]: On Wed, Nov 17, 2010 at 02:28:11PM +0200, Tomi Valkeinen wrote: On Tue, 2010-11-16 at 21:10 +0100, ext Tony Lindgren wrote: Sure a module would be even better. My point is that the selection of all the features should be enabled by default and the board options come from platform_data. Ok, let's build DSS all panel drivers as modules by default. Somehow I've gotten the impression from linux ml that enabling features by default is bad. But perhaps it's more about intervening features than normal drivers. The general rule is to avoid default enabling unless you really need it, but it still remains optional (which is why it's not being selected, instead). Some, like gpiolib, have come up with WANT/NEED options for the platform code to select in order to work out the desired behaviour, and you may benefit from a similar approach for your subsystem if it's really that integral for some parts. The flip side of course is that if you expect your users to primarily be using the defconfigs provided, you can simply leave it default disabled in the Kconfig and set the options you want in the defconfigs. Unless you can say with certainty that all OMAP3 boards are going to want DSS enabled or modular by default, it's almost always better to just leave it up to the defconfigs. I wish we could just do default m if ARCH_OMAP2PLUS_TYPICAL.. But meanwhile setting it as a module in omap2plus_defconfig does the trick though like you say. Regards, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
Kevin Hilman had written, on 11/18/2010 09:52 AM, the following: Nishanth Menon n...@ti.com writes: From: Vishwanath BS vishwanath...@ti.com For historical reasons the OMAP3 sleep code is run from SRAM. This code can run from DDR which provides better performance and leaves the SRAM available for other uses. Tested on ZOOM3, OMAP3EVM, Beagleboard, n900 with full RET and OFF modes. Sorry, But I disagree with this patch. There is a silicon errata which cannot be handled with this - RTA disable - errata i608 You need to disable RTA while coming out of OFF - we cannot handle this on GP devices if this is not done. You need to provide some more details here as to exactly why this patch prevents the ability to do this workaround. As Vishwa pointed out, when returning from OFF mode, current code already starts in DDR since SRAM is lost. The current code also already can jump back into SRAM for certain errata/fixup (c.f. es3_sdrc_fix in current code.) scratchpad_contents.public_restore_ptr - this is the restore pointer that is invoked when we get out of OFF mode. - on 3430 and 3630, I agree it in SDRAM, for es3_sdrc_fix, it relocates the required code to sram as it cannot be run in ddr. - so I believe no issues there. But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? -- 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 2/2] OMAP3: clean up ASM idle code
* Jean Pihet jean.pi...@newoldbits.com [101118 06:43]: From: Vishwanath BS vishwanath...@ti.com Clean up of the ASM code: - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - reworked the comments for better readability, - reworked the code formating and alignment, - added comments for the i443 errata workarounds, - replaced the cache flush code by a call to the kernel common code for ARMv7 (v7_flush_kern_cache_all), which is better maintained and so more mature, - clean up of non used symbols. This should be broken into several patches. The first patch should be to use v7_flush_kern_cache_all instead of the buggy older copy of that in sleep34xx.S. After that, any readability and formatting patches should contain no functional changes. Regards, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Nishanth Menon n...@ti.com [101118 08:46]: But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? I too am a bit concerned how this will all keep working. For light testing it may be running OK if it happens to run from cache.. Also, moving the code out of SRAM will limit the options for what we may need to do with DDR or L3. Retention is something to consider, are there issues with that? Regards, 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] OMAP MUX framework changes
Hi Dan,
* Dan Murphy dmur...@ti.com [101117 09:58]:
@@ -81,10 +81,14 @@ void omap_mux_write(struct omap_mux_partition *partition,
u16 val,
void omap_mux_write_array(struct omap_mux_partition *partition,
struct omap_board_mux *board_mux)
{
- while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
- omap_mux_write(partition, board_mux-value,
-board_mux-reg_offset);
- board_mux++;
+ if (partition) {
+ while (board_mux-reg_offset != OMAP_MUX_TERMINATOR) {
+ omap_mux_write(partition, board_mux-value,
+board_mux-reg_offset);
+ board_mux++;
+ }
+ } else {
+ pr_err(%s: Partition was NULL\n, __func__);
}
}
Can you please make this into a separate patch. And instead of
indenting the code more, just do something like:
if (!partition)
return -EINVAL;
Regards,
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
[PATCH] arm: omap1: make some functions static
Make some functions static to get rid of the following sparse warnings:
arch/arm/mach-omap1/mcbsp.c:177:12: warning: symbol 'omap1_mcbsp_init'
was not declared. Should it be static?
arch/arm/mach-omap1/mux.c:346:22: warning: symbol 'omap1_cfg_reg' was
not declared. Should it be static?
arch/arm/plat-omap/dma.c:177:5: warning: symbol 'omap_dma_in_1510_mode'
was not declared. Should it be static?
arch/arm/plat-omap/sram.c:273:12: warning: symbol 'omap1_sram_init' was
not declared. Should it be static?
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap1/mcbsp.c |2 +-
arch/arm/mach-omap1/mux.c |2 +-
arch/arm/plat-omap/dma.c|2 +-
arch/arm/plat-omap/sram.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index b3a796a..372ea71 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -174,7 +174,7 @@ static struct omap_mcbsp_platform_data
omap16xx_mcbsp_pdata[] = {
#define OMAP16XX_MCBSP_REG_NUM 0
#endif
-int __init omap1_mcbsp_init(void)
+static int __init omap1_mcbsp_init(void)
{
if (cpu_is_omap7xx()) {
omap_mcbsp_count = OMAP7XX_MCBSP_PDATA_SZ;
diff --git a/arch/arm/mach-omap1/mux.c b/arch/arm/mach-omap1/mux.c
index 7835add..5fdef7a 100644
--- a/arch/arm/mach-omap1/mux.c
+++ b/arch/arm/mach-omap1/mux.c
@@ -343,7 +343,7 @@ MUX_CFG(Y14_1610_CCP_DATAM,9, 21,6, 2,
3, 1,2, 0, 0)
#define OMAP1XXX_PINS_SZ 0
#endif /* CONFIG_ARCH_OMAP15XX || CONFIG_ARCH_OMAP16XX */
-int __init_or_module omap1_cfg_reg(const struct pin_config *cfg)
+static int __init_or_module omap1_cfg_reg(const struct pin_config *cfg)
{
static DEFINE_SPINLOCK(mux_spin_lock);
unsigned long flags;
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 2c28265..a863f55 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -174,7 +174,7 @@ static inline void omap_enable_channel_irq(int lch);
#ifdef CONFIG_ARCH_OMAP15XX
/* Returns 1 if the DMA module is in OMAP1510-compatible mode, 0 otherwise */
-int omap_dma_in_1510_mode(void)
+static int omap_dma_in_1510_mode(void)
{
return enable_1510_mode;
}
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index e2c8eeb..93641df 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -270,7 +270,7 @@ void omap_sram_reprogram_clock(u32 dpllctl, u32 ckctl)
_omap_sram_reprogram_clock(dpllctl, ckctl);
}
-int __init omap1_sram_init(void)
+static int __init omap1_sram_init(void)
{
_omap_sram_reprogram_clock =
omap_sram_push(omap1_sram_reprogram_clock,
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap1: mbox: delete unused variable
Delete unused variable from probe().
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap1/mailbox.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 12d6880..c0e1f48 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -145,7 +145,6 @@ static int __devinit omap1_mbox_probe(struct
platform_device *pdev)
{
struct resource *mem;
int ret;
- int i;
struct omap_mbox **list;
list = omap1_mboxes;
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap1: mbox: make variables static
Make some variables static to get rid of the following warnings:
arch/arm/mach-omap1/mailbox.c:136:18: warning: symbol 'mbox_dsp_info'
was not declared. Should it be static?
arch/arm/mach-omap1/mailbox.c:142:18: warning: symbol 'omap1_mboxes'
was not declared. Should it be static?
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap1/mailbox.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/mailbox.c b/arch/arm/mach-omap1/mailbox.c
index 1a85a42..12d6880 100644
--- a/arch/arm/mach-omap1/mailbox.c
+++ b/arch/arm/mach-omap1/mailbox.c
@@ -133,13 +133,13 @@ static struct omap_mbox1_priv omap1_mbox_dsp_priv = {
},
};
-struct omap_mbox mbox_dsp_info = {
+static struct omap_mbox mbox_dsp_info = {
.name = dsp,
.ops= omap1_mbox_ops,
.priv = omap1_mbox_dsp_priv,
};
-struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
+static struct omap_mbox *omap1_mboxes[] = { mbox_dsp_info, NULL };
static int __devinit omap1_mbox_probe(struct platform_device *pdev)
{
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap2: timer-gp: delete unused variable
Delete a redundant local variable.
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap2/timer-gp.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index e13c29e..f9052e1 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -203,7 +203,7 @@ static struct clocksource clocksource_gpt = {
static void __init omap2_gp_clocksource_init(void)
{
static struct omap_dm_timer *gpt;
- u32 tick_rate, tick_period;
+ u32 tick_rate;
static char err1[] __initdata = KERN_ERR
%s: failed to request dm-timer\n;
static char err2[] __initdata = KERN_ERR
@@ -216,7 +216,6 @@ static void __init omap2_gp_clocksource_init(void)
omap_dm_timer_set_source(gpt, OMAP_TIMER_SRC_SYS_CLK);
tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gpt));
- tick_period = (tick_rate / HZ) - 1;
omap_dm_timer_set_load_start(gpt, 1, 0);
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap1: board-ams-delta: fix cast
Use IOMEM() macro to get rid of the following sparse warning:
arch/arm/mach-omap1/board-ams-delta.c:319:36: warning: incorrect type
in initializer (different address spaces)
arch/arm/mach-omap1/board-ams-delta.c:319:36:expected void
[noderef] asn:2*membase
arch/arm/mach-omap1/board-ams-delta.c:319:36:got void *noident
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap1/board-ams-delta.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 1d4163b..1948cd3 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -28,6 +28,7 @@
#include asm/mach/arch.h
#include asm/mach/map.h
+#include plat/io.h
#include plat/board-ams-delta.h
#include mach/gpio.h
#include plat/keypad.h
@@ -316,7 +317,7 @@ static void __init ams_delta_init(void)
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
- .membase= (void *) AMS_DELTA_MODEM_VIRT,
+ .membase= IOMEM(AMS_DELTA_MODEM_VIRT),
.mapbase= AMS_DELTA_MODEM_PHYS,
.irq= -EINVAL, /* changed later */
.flags = UPF_BOOT_AUTOCONF,
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] OMAP cleanups
Some small OMAP cleanups to eliminate noise from compilation/sparse checks: Aaro Koskinen (6): arm: omap1: add missing includes arm: omap1: make some functions static arm: omap1: mbox: make variables static arm: omap1: mbox: delete unused variable arm: omap1: board-ams-delta: fix cast arm: omap2: timer-gp: delete unused variable arch/arm/mach-omap1/board-ams-delta.c |3 ++- arch/arm/mach-omap1/devices.c |1 + arch/arm/mach-omap1/flash.c |1 + arch/arm/mach-omap1/mailbox.c |5 ++--- arch/arm/mach-omap1/mcbsp.c |2 +- arch/arm/mach-omap1/mux.c |2 +- arch/arm/mach-omap1/serial.c |2 ++ arch/arm/mach-omap1/time.c|1 + arch/arm/mach-omap2/timer-gp.c|3 +-- arch/arm/plat-omap/dma.c |2 +- arch/arm/plat-omap/sram.c |2 +- 11 files changed, 14 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap1: add missing includes
Add missing includes to get rid of the following sparse warnings:
arch/arm/mach-omap1/devices.c:225:13: warning: symbol
'omap1_camera_init' was not declared. Should it be static?
arch/arm/mach-omap1/flash.c:15:6: warning: symbol 'omap1_set_vpp' was
not declared. Should it be static?
arch/arm/mach-omap1/serial.c:190:6: warning: symbol
'omap_serial_wake_trigger' was not declared. Should it be static?
arch/arm/mach-omap1/time.c:252:18: warning: symbol 'omap_timer' was not
declared. Should it be static?
Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com
---
arch/arm/mach-omap1/devices.c |1 +
arch/arm/mach-omap1/flash.c |1 +
arch/arm/mach-omap1/serial.c |2 ++
arch/arm/mach-omap1/time.c|1 +
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index e7f9ee6..86ad38a 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/spi/spi.h
+#include mach/camera.h
#include mach/hardware.h
#include asm/mach/map.h
diff --git a/arch/arm/mach-omap1/flash.c b/arch/arm/mach-omap1/flash.c
index 0b07a78..acd1616 100644
--- a/arch/arm/mach-omap1/flash.c
+++ b/arch/arm/mach-omap1/flash.c
@@ -11,6 +11,7 @@
#include plat/io.h
#include plat/tc.h
+#include plat/flash.h
void omap1_set_vpp(struct map_info *map, int enable)
{
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index b78d074..0845fbb 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -27,6 +27,8 @@
#include mach/gpio.h
#include plat/fpga.h
+#include pm.h
+
static struct clk * uart1_ck;
static struct clk * uart2_ck;
static struct clk * uart3_ck;
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 1be6a21..7f75bc6 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -52,6 +52,7 @@
#include asm/mach/irq.h
#include asm/mach/time.h
+#include plat/common.h
#define OMAP_MPU_TIMER_BASEOMAP_MPU_TIMER1_BASE
#define OMAP_MPU_TIMER_OFFSET 0x100
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: nand: remove hardware ECC as default
* Sukumar Ghorai s-gho...@ti.com [101118 06:12]: CONFIG_MTD_NAND_OMAP_HWECC defined wronly in patch submitted during 2.6.36 that using the hardware ECC by default Signed-off-by: Sukumar Ghorai s-gho...@ti.com --- drivers/mtd/nand/omap2.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index cd41c58..15682ec 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -7,7 +7,6 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#define CONFIG_MTD_NAND_OMAP_HWECC #include linux/platform_device.h #include linux/dma-mapping.h This looks like a fix for the -rc cycle. Can you please update the description a bit to specify which commit broke it and what the error is now? Regards, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
* Tony Lindgren t...@atomide.com [101118 09:42]: * Nishanth Menon n...@ti.com [101118 08:46]: But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? I too am a bit concerned how this will all keep working. For light testing it may be running OK if it happens to run from cache.. This in the retention case, in off-idle those should be powered down.. 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: * Nishanth Menon n...@ti.com [101118 08:46]: But after wfi in wait_sdrc_ok as part of the code executing in SRAM today omap34xx_cpu_suspend - we are waiting for DPLL3 lock prior to accessing DDR - how do we execute that logic in SDRAM? I too am a bit concerned how this will all keep working. For light testing it may be running OK if it happens to run from cache.. As Vishwa pointed out, when going out of OFF mode the SRAM and the caches are lost. That means the low power mode _has to_ rely on SDRAM at wake-up. About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Also, moving the code out of SRAM will limit the options for what we may need to do with DDR or L3. What are the options? All the executable code runs from DDR anyway. Retention is something to consider, are there issues with that? No issue so far. See the points 1) and 2) here above. Regards, Tony Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP3: clean up ASM idle code
On Thu, Nov 18, 2010 at 6:41 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 06:43]: From: Vishwanath BS vishwanath...@ti.com Clean up of the ASM code: - reworked and simplified the execution paths, for better readability and to avoid duplication of code, - reworked the comments for better readability, - reworked the code formating and alignment, - added comments for the i443 errata workarounds, - replaced the cache flush code by a call to the kernel common code for ARMv7 (v7_flush_kern_cache_all), which is better maintained and so more mature, - clean up of non used symbols. This should be broken into several patches. The first patch should be to use v7_flush_kern_cache_all instead of the buggy older copy of that in sleep34xx.S. Agree After that, any readability and formatting patches should contain no functional changes. Will rework and repost once something goes out of the on-going discussions. Regards, Tony Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3 PM: move omap3 sleep to ddr
* Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Regards, 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 1/2] OMAP3 PM: move omap3 sleep to ddr
On Thu, Nov 18, 2010 at 7:27 PM, Tony Lindgren t...@atomide.com wrote: * Jean Pihet jean.pi...@newoldbits.com [101118 10:06]: On Thu, Nov 18, 2010 at 6:52 PM, Tony Lindgren t...@atomide.com wrote: About the DPLL lock: 1) wait_sdrc_ok is only called when back from the non-OFF modes, 2) I checked that when running wait_sdrc_ok the CORE is already out of idle and the DPLL is already locked. Note: l-o code has no support for the voltages OFF and the external clocks OFF. What to conclude from 1) and 2)? In my test setup ot looks like wait_sdrc_ok is of no use, but I agree this a premature conclusion. Yeah we should figure out in which cases wait_sdrc_ok is needed. BTW, are you sure you're hitting core idle in your tests? Yes it is OK from the console messages and the counters values in /debug/pm_debug/count. Let me confirm asap with the PRCM registers dump. Regards, Tony Thanks, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote: * Paul Mundt let...@linux-sh.org [101117 22:09]: Unless you can say with certainty that all OMAP3 boards are going to want DSS enabled or modular by default, it's almost always better to just leave it up to the defconfigs. I wish we could just do default m if ARCH_OMAP2PLUS_TYPICAL.. But meanwhile setting it as a module in omap2plus_defconfig does the trick though like you say. Something like this should be quite doable if the Kconfig fragments work is ever completed. If this is something that interests you you may wish to give it a bit of a nudge :-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] OMAP4: hsmmc: Initialise the mmc mux pins
* sricharan r.sricha...@ti.com [101114 23:26]:
Use the mux framework to initialise the mmc mux pins.
Signed-off-by: sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/devices.c | 83
+
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index eaf3799..56b1ac9 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -784,6 +784,89 @@ static inline void omap2_mmc_mux(struct
omap_mmc_platform_data *mmc_controller,
* For MMC3 the pins need to be muxed in the board-*.c files
*/
}
+
+ if (cpu_is_omap44xx()) {
+ switch (controller_nr) {
+ case 0:
+ /* MMC 1 */
+ omap_mux_init_signal(sdmmc1_clk.sdmmc1_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_cmd.sdmmc1_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat0.sdmmc1_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].caps
+ (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+ omap_mux_init_signal(sdmmc1_dat1.sdmmc1_dat1,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat2.sdmmc1_dat2,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat3.sdmmc1_dat3,
+ OMAP_PIN_INPUT_PULLUP);
+ }
This does not solve the selected pins issue. For example, you don't know
if it's sdmmc1_dat1.sdmmc1_dat1 or gpmc_ad9.sdmmc_dat1. That selection
is board specific.
So you either have to pass the selected pins from the board-*.c file,
or do the muxing in board-*.c file. It depends on the the case.
How about take a look at specifying the pin names in board-*.c in
struct omap_mmc_platform_data?
Regards,
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 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
* sricharan r.sricha...@ti.com [101114 23:26]: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. snip 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. For the common modules, we should have generic platform init code using hwmod. And that init code is the logical place to do the muxing. We also need to consider that the pin muxing is board specific. So in cases where the are alternative signal paths, we need to pass the signal names from board-*.c file to the platform driver init code. Regards, 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 v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3
* Paul Mundt let...@linux-sh.org [101118 10:29]: On Thu, Nov 18, 2010 at 08:44:14AM -0800, Tony Lindgren wrote: * Paul Mundt let...@linux-sh.org [101117 22:09]: Unless you can say with certainty that all OMAP3 boards are going to want DSS enabled or modular by default, it's almost always better to just leave it up to the defconfigs. I wish we could just do default m if ARCH_OMAP2PLUS_TYPICAL.. But meanwhile setting it as a module in omap2plus_defconfig does the trick though like you say. Something like this should be quite doable if the Kconfig fragments work is ever completed. If this is something that interests you you may wish to give it a bit of a nudge :-) Yeah maybe eventually at some point.. Got several merge cycles of other things to fix.. And the defconfig can be used for now :) 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
[PATCH v3 3/5] OMAP: mailbox: fix checkpatch warnings
Fix the checkpatch warnings observed in mailbox module Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/plat-omap/mailbox.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c index 9ce3570..abfc495 100644 --- a/arch/arm/plat-omap/mailbox.c +++ b/arch/arm/plat-omap/mailbox.c @@ -279,11 +279,11 @@ static int omap_mbox_startup(struct omap_mbox *mbox) return 0; - fail_alloc_rxq: +fail_alloc_rxq: mbox_queue_free(mbox-txq); - fail_alloc_txq: +fail_alloc_txq: free_irq(mbox-irq, mbox); - fail_request_irq: +fail_request_irq: if (mbox-ops-shutdown) mbox-ops-shutdown(mbox); @@ -394,7 +394,8 @@ static int __init omap_mbox_init(void) /* kfifo size sanity check: alignment and minimal size */ mbox_kfifo_size = ALIGN(mbox_kfifo_size, sizeof(mbox_msg_t)); - mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, sizeof(mbox_msg_t)); + mbox_kfifo_size = max_t(unsigned int, mbox_kfifo_size, + sizeof(mbox_msg_t)); return 0; } -- 1.7.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/5] OMAP: mailbox: change full flag per mailbox queue instead of global
From: Fernando Guzman Lugo x0095...@ti.com
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Version 3:
- Remove spin_lock protection. When the full flag is
true the interrupt for that mailbox is disabled. So there
is no race condition if full flag is modified before
calling omap_mbox_enable_irq.
Reported-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..13f2ef3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..9ce3570 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -148,6 +147,10 @@ static void mbox_rx_work(struct work_struct *work)
if (mq-callback)
mq-callback((void *)msg);
+ if (mq-full) {
+ mq-full = false;
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ }
}
}
@@ -170,7 +173,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigeri h-kanige...@ti.com --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; l = mbox_read_reg(p-irqdisable); - l = ~bit; + if (cpu_is_omap44xx()) + l |= bit; + else + l = ~bit; mbox_write_reg(l, p-irqdisable); } -- 1.7.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/5] OMAP: mailbox: enhancements and fixes
Sending the patch set by seperating the clock related patch seperated out based on Paul Walmsey's comment. http://www.spinics.net/lists/arm-kernel/msg103692.html The clock patch will be sent out as a seperate patch. The previous versions of this patch set can be found here http://www.spinics.net/lists/linux-omap/msg39988.html http://www.spinics.net/lists/linux-omap/msg39931.html http://www.mail-archive.com/linux-omap@vger.kernel.org/msg37278.html Fernando Guzman Lugo (1): OMAP: mailbox: change full flag per mailbox queue instead of global Hari Kanigeri (4): OMAP: mailbox: fix rx interrupt disable in omap4 OMAP: mailbox: fix checkpatch warnings OMAP: mailbox: send message in process context OMAP: mailbox: add notification support for multiple readers arch/arm/mach-omap2/mailbox.c |5 +- arch/arm/plat-omap/include/plat/mailbox.h |8 +- arch/arm/plat-omap/mailbox.c | 127 + 3 files changed, 82 insertions(+), 58 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/5] OMAP: mailbox: send message in process context
Schedule the Tasklet to send only when mailbox fifo is full and there are
pending messages in kifo, else send the message directly in the Process
context. This would avoid needless scheduling of Tasklet for every message
transfer
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/plat-omap/mailbox.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index abfc495..b14bc34 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -92,20 +92,25 @@ int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t
msg)
struct omap_mbox_queue *mq = mbox-txq;
int ret = 0, len;
- spin_lock(mq-lock);
+ spin_lock_bh(mq-lock);
if (kfifo_avail(mq-fifo) sizeof(msg)) {
ret = -ENOMEM;
goto out;
}
+ if (kfifo_is_empty(mq-fifo) !__mbox_poll_for_space(mbox)) {
+ mbox_fifo_write(mbox, msg);
+ goto out;
+ }
+
len = kfifo_in(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
tasklet_schedule(mbox-txq-tasklet);
out:
- spin_unlock(mq-lock);
+ spin_unlock_bh(mq-lock);
return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/5] OMAP: mailbox: add notification support for multiple readers
In the current mailbox driver, the mailbox internal pointer for
callback can be directly manipulated by the Users, so a second
User can easily corrupt the first user's callback pointer.
The initial effort to correct this issue can be referred here:
https://patchwork.kernel.org/patch/107520/
Along with fixing the above stated issue, this patch adds the
flexibility option to register notifications from
multiple readers to the events received on a mailbox instance.
The discussion regarding this can be referred here.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30671.html
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |7 +-
arch/arm/plat-omap/mailbox.c | 102 -
2 files changed, 60 insertions(+), 49 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 13f2ef3..cc3921e 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -46,7 +46,6 @@ struct omap_mbox_queue {
struct kfifofifo;
struct work_struct work;
struct tasklet_struct tasklet;
- int (*callback)(void *);
struct omap_mbox*mbox;
bool full;
};
@@ -58,13 +57,15 @@ struct omap_mbox {
struct omap_mbox_ops*ops;
struct device *dev;
void*priv;
+ int use_count;
+ struct blocking_notifier_head notifier;
};
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
-struct omap_mbox *omap_mbox_get(const char *);
-void omap_mbox_put(struct omap_mbox *);
+struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);
+void omap_mbox_put(struct omap_mbox *mbox, struct notifier_block *nb);
int omap_mbox_register(struct device *parent, struct omap_mbox **);
int omap_mbox_unregister(void);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index b14bc34..b1f8f2c 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -28,6 +28,7 @@
#include linux/slab.h
#include linux/kfifo.h
#include linux/err.h
+#include linux/notifier.h
#include plat/mailbox.h
@@ -150,8 +151,8 @@ static void mbox_rx_work(struct work_struct *work)
len = kfifo_out(mq-fifo, (unsigned char *)msg, sizeof(msg));
WARN_ON(len != sizeof(msg));
- if (mq-callback)
- mq-callback((void *)msg);
+ blocking_notifier_call_chain(mq-mbox-notifier, len,
+ (void *)msg);
if (mq-full) {
mq-full = false;
omap_mbox_enable_irq(mq-mbox, IRQ_RX);
@@ -247,41 +248,40 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
int ret = 0;
struct omap_mbox_queue *mq;
- if (mbox-ops-startup) {
- mutex_lock(mbox_configured_lock);
- if (!mbox_configured)
+ mutex_lock(mbox_configured_lock);
+ if (!mbox_configured++) {
+ if (likely(mbox-ops-startup)) {
ret = mbox-ops-startup(mbox);
-
- if (ret) {
- mutex_unlock(mbox_configured_lock);
- return ret;
- }
- mbox_configured++;
- mutex_unlock(mbox_configured_lock);
+ if (unlikely(ret))
+ goto fail_startup;
+ } else
+ goto fail_startup;
}
- ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
- mbox-name, mbox);
- if (ret) {
- printk(KERN_ERR
- failed to register mailbox interrupt:%d\n, ret);
- goto fail_request_irq;
- }
-
- mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
- if (!mq) {
- ret = -ENOMEM;
- goto fail_alloc_txq;
- }
- mbox-txq = mq;
+ if (!mbox-use_count++) {
+ ret = request_irq(mbox-irq, mbox_interrupt, IRQF_SHARED,
+ mbox-name, mbox);
+ if (unlikely(ret)) {
+ pr_err(failed to register mailbox interrupt:%d\n,
+ ret);
+ goto fail_request_irq;
+ }
+ mq = mbox_queue_alloc(mbox, NULL, mbox_tx_tasklet);
+ if (!mq) {
+ ret = -ENOMEM;
+ goto fail_alloc_txq;
+ }
+ mbox-txq = mq;
- mq = mbox_queue_alloc(mbox, mbox_rx_work, NULL);
- if (!mq) {
- ret
[PATCH] OMAP4: clocks: add dummy clock for mailbox
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigeri h-kanige...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..bdd9b85 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2687,6 +2687,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick,dummy_ck,
CK_443X),
CLK(NULL, uart4_ick,dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
+ CLK(NULL, mailboxes_ick,dummy_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
--
1.7.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP MUX framework changes
Hi Tony, On 11/18/2010 6:57 PM, Tony Lindgren wrote: Hi Dan, [...] Can you please make this into a separate patch. And instead of indenting the code more, just do something like: if (!partition) return -EINVAL; Do you want me to merge that in my current OMAP4 series branch? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
On 11/18/2010 8:06 PM, Tony Lindgren wrote: * sricharanr.sricha...@ti.com [101114 23:26]: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. snip 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. For the common modules, we should have generic platform init code using hwmod. And that init code is the logical place to do the muxing. We also need to consider that the pin muxing is board specific. So in cases where the are alternative signal paths, we need to pass the signal names from board-*.c file to the platform driver init code. What about the omap_board_mux array in board file? Do you want to get rid of it, or is the plan is to use that for pads that does not belong to any driver or pads that are purely board specific? Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem using UART3 on Logic Torpedo w/2.6.32
All,
I have a 2.6.32 kernel based on the L23.i3.3 kernel (2.6.32) from TI,
and I've run into an interesting problem with UART3 (maps to /dev/ttyS1
on the Torpedo board).
On the host I have it hooked up to /dev/ttyS1, so I turn on CTS/RTS and
set the baudrate by:
host$ stty 115200 crtscts /dev/ttyS1
And the same on the target:
OMAP-35x$ stty 115200 crtscts /dev/ttyS1
To force the board to throttle the serial I slowed down the console to
19200:
OMAP-35x$ stty 19200 /dev/ttyS0
On the target console I capture the data from the host (and show it on
the serial port):
OMAP-35x$ cat /dev/ttyS1 | tee /tmp/x
and on the host send the data:
host$ dd if=/dev/urandom count=100 bs=1024 | hexdump -C /tmp/x
host$ cat /tmp/x /dev/ttyS1
I'd expect to see something like the following on the target:
35 2c a6 97 23 35 95 9a fb 91 6d 6e ce f8 32 d7
|5,..#5mn..2.|
0010 6b 0b cf 66 e6 3a b4 55 91 5f 86 8f 41 c9 49 76
|k..f.:.U._..A.Iv|
0020 e6 cf fa 0a 0e db 69 0c db 14 6b 76 62 4c 5b 9e
|..i...kvbL[.|
0030 98 1b 5f 30 16 d6 ed 96 dc d7 f1 3b 59 a0 ec ac
|.._0...;Y...|
0040 86 8c 9b 28 21 b8 a0 98 ed cf 96 39 15 a4 7b 9e
|...(!..9..{.|
0050 bf 01 aa 09 1a 12 1f c3 49 b3 92 73 00 84 52 de
|I..s..R.|
0060 c0 d3 4b 1d ca 84 04 ea 60 ef 7f b2 63 36 eb 5e
|..K.`...c6.^|
0070 28 0c 20 2a 86 a2 36 bb c7 c0 27 da 87 c8 8b 1e |(.
*..6...'.|
0080 5d b7 04 b3 2c 0b 29 f4 8d 4f 5f fe 90 b0 1b 96
|]...,.)..O_.|
0090 b8 82 94 ae 92 37 31 03 dc 1b c3 c0 38 b1 16 77
|.71.8..w|
Instead I see:
OMAP-35x# head /tmp/x
35 2c a6 97 23 6b 0b ca fb 91 6d 6e ce f8 32 d6 8f
41.#5mn..2.|
0010 .Iv|
00f 66 e6 3a b4 55 91 5f 8669 0c c9 49 76
|k..f.:.U._..A.|.20 e6 cf
fa 0a 0e db 1b 5f db 14 6b 76 62 4c 5b 9e b 59 a.i...kvbL[.|
0030 98.|
30 16 d6 ed 96 dc d7 f1 3b 59 e0 ec ac
|.._0...;Y.(!..0040 86 8c
9b 28 21 b8 a0 98 09d cf 96 39 15 a4 7b 9e |.00 84 9..{.|
0050 bf 0100 1a 12 1f c3 49 b3 92 73 a 60 52 de
|I..s..R.|
.`60 c0 d3 4b 1d ca 84 04 e0 2a 8ef 7f b2 63 36 eb 5e |..7 c8
8b...c6.^|
0070 28 0c 2806 a2 36 bb c7 c0 27 da 87 8d 4f 1e |(.
*..6...'.|
00.)..O_ 5d b7 04 b3 2c 0b 29 f4 ae 92 5f fe 90 b0 1b 96 |]...,.).6
7.|
0090 b8 82 94 00a0 37 31 03 dc 1b c3 c0 38 b1 7c 77
|.71.8..w|
Looking deeper:
OMAP-35x# hexdump -C /tmp/x | head
30 30 30 30 30 30 30 30 20 20 33 35 20 32 63 20 |
35 2c |
0010 61 36 20 39 37 20 32 33 20 36 62 20 30 62 20 63 |a6 97 23 6b
0b c|
0020 61 20 20 66 62 20 39 31 20 36 64 20 36 65 20 63 |a fb 91 6d
6e c|
0030 65 20 66 38 20 33 32 20 64 36 20 38 66 20 34 31 |e f8 32 d6
8f 41|
0040 2e 23 35 2e 2e 2e 2e 6d 6e 2e 2e 32 2e 7c 0a 30
|.#5mn..2.|.0|
0050 30 30 30 30 30 31 30 20 20 2e 49 76 7c 0a 30 30 |010
.Iv|.00|
0060 66 20 36 36 20 65 36 20 33 61 20 62 34 20 35 35 |f 66 e6 3a
b4 55|
0070 20 20 39 31 20 35 66 20 38 36 36 39 20 30 63 20 | 91 5f
8669 0c |
0080 20 63 39 20 34 39 20 37 36 20 20 7c 6b 2e 2e 66 | c9 49 76
|k..f|
0090 2e 3a 2e 55 2e 5f 2e 2e 41 2e 7c 2e 2e 2e 2e 2e
|.:.U._..A.|.|
However if I instead use UART2 and replicate the above steps, all is
well. I've looked at the serial signals and CTS/RTS are responding as
expected. I tried switching drivers from the 8250 to the OMAP_SERIAL,
and the results look the same.
Any ideas what is happening?
--
Peter Barada
pet...@logicpd.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.
* Cousson, Benoit b-cous...@ti.com [101118 12:56]: On 11/18/2010 8:06 PM, Tony Lindgren wrote: * sricharanr.sricha...@ti.com [101114 23:26]: This series updates the core device drivers to use mux framework for OMAP4 SDP and PANDA board. It's generated against the linux-omap master branch. It has a dependency on the Benoit's omap4 mux data series. snip 2. Do PAD configuration independently for each module Pros: a. Avoids repetition of similar data for different boards. b. Gives a knowledge of how pins are configured for a module to the respective owners. c. Pads are not initialised unless they are really needed. Cons: a. Can become difficult to maintain if lot of data tend to be different across boards. For the common modules, we should have generic platform init code using hwmod. And that init code is the logical place to do the muxing. We also need to consider that the pin muxing is board specific. So in cases where the are alternative signal paths, we need to pass the signal names from board-*.c file to the platform driver init code. What about the omap_board_mux array in board file? Do you want to get rid of it, or is the plan is to use that for pads that does not belong to any driver or pads that are purely board specific? Well we might as well keep it around for now as that's the way some people prefer to do the muxing. But yeah, eventually that could be for only board specific unused pads. I'll post some sample patches related to the uart (re)muxing within next few days, then let's see how that will work for other devices. Here's the rough plan in case you have some ideas on it: 1. board-*.c code calls omap_serial_init_port with struct omap_device_mux array that contains the pin names 2. serial.c init code muxes the pins the right way and sets wake-up events for omap3 4. It also populates the runtime remux values needed for omap2 uart 3. serial.c init code saves the struct omap_device_mux pointer to the related hwmod entry 4. omap_device_idle/shutdown can then call omap_remux if the omap_device_mux entry exists ... This should solve how devices need to initialize the pads. It should also work for all devices that may require runtime remuxing, like some USB transceivers and eMMC. Regards, 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] OMAP MUX framework changes
* Cousson, Benoit b-cous...@ti.com [101118 12:52]: Hi Tony, On 11/18/2010 6:57 PM, Tony Lindgren wrote: Hi Dan, [...] Can you please make this into a separate patch. And instead of indenting the code more, just do something like: if (!partition) return -EINVAL; Do you want me to merge that in my current OMAP4 series branch? I got that already pulled, so I'd prefer not to touch that branch any longer unless we have to. Sounds like this can be a separate patch. Regards, 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
Suspend / Resume and sys_clkout1
I am working with a board that deviates from what seems to be common OMAP-as-clock-slave-from-the-TWL4030-PMIC-clock-master practice. In order to get this board to work correctly when used with SmartReflex-enabled, I had to add the following to the board initialization function: /* In this architecture, we use the OMAP3 as a 19.2 MHz clock * master and the TWL4030 as a clock slave, fed via the OMAP3's * sys_clkout1 pin. * * We need to request the 'sys_clkout1' clock source to at least * give it a reference count of one (1); otherwise, if the SmartReflex * power management code has been configured, it'll get unceremoniously * turned off with a message: * * Disabling unused clock sys_clkout1 * * and general system functionality fails thereafter. */ sys_clkout1 = clk_get(NULL, sys_clkout1); BUG_ON(IS_ERR(sys_clkout1)); clk_enable(sys_clkout1); However, now working with suspend/resume functionality, I see that this clock is preventing the system from fully going down to sleep. This leads me to believe that perhaps board-specific initialization was/is not the right place for this as there is no board-specific suspend/resume handling. Any recommendations on a more architecturally-correct way to address OMAP-as-clock-master-to-the-TWL4030-PMIC-clock-slave in a suspend/resume-friendly way? Best, Grant-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clocks: add dummy clock for mailbox
Hi Hari,
On 11/18/2010 8:20 PM, Kanigeri, Hari wrote:
In omap4, there is no explicit configuration register to enable mailbox clocks.
Defining dummy clock for mailbox clock module to keep the mailbox driver
backward compatible with previous omaps.
Signed-off-by: Hari Kanigerih-kanige...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index e10db7a..bdd9b85 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2687,6 +2687,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick, dummy_ck, CK_443X),
CLK(NULL, uart4_ick, dummy_ck, CK_443X),
CLK(omap_wdt, ick,dummy_ck,
CK_443X),
+ CLK(NULL, mailboxes_ick, dummy_ck, CK_443X),
};
int __init omap4xxx_clk_init(void)
OK, that one is easy but... I will still have to update the script to
generate it, so:
Acked-by: Benoit Cousson b-cous...@ti.com
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clocks: add dummy clock for mailbox
Benoit, OK, that one is easy but... I will still have to update the script to generate it, so: Sure, thank you. Best regards, Hari Kanigeri -- To unsubscribe from this list: send the line unsubscribe 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 v3 1/5] OMAP: mailbox: change full flag per mailbox queue instead of global
On 11/18/2010 8:15 PM, Kanigeri, Hari wrote:
From: Fernando Guzman Lugox0095...@ti.com
As pointed by Ohad Ben-Cohen, the variable rq_full flag is a
global variable, so if there are multiple mailbox users
there will be conflics. Now there is a full flag per
mailbox queue.
Version 2:
- Rebase to the latest.
Version 3:
You should not put the patch revisions here, because it will stay in the
changelog when it will be in GIT.
You'd better put that in the cover-letter or after the ---.
Everything after --- will not be taken into account in the changelog.
Regards,
Benoit
- Remove spin_lock protection. When the full flag is
true the interrupt for that mailbox is disabled. So there
is no race condition if full flag is modified before
calling omap_mbox_enable_irq.
Reported-by: Ohad Ben-Coheno...@wizery.com
Signed-off-by: Fernando Guzman Lugox0095...@ti.com
Signed-off-by: Hari Kanigerih-kanige...@ti.com
---
arch/arm/plat-omap/include/plat/mailbox.h |1 +
arch/arm/plat-omap/mailbox.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 9976565..13f2ef3 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -48,6 +48,7 @@ struct omap_mbox_queue {
struct tasklet_struct tasklet;
int (*callback)(void *);
struct omap_mbox*mbox;
+ bool full;
};
struct omap_mbox {
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index d2fafb8..9ce3570 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -33,7 +33,6 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox **mboxes;
-static bool rq_full;
static int mbox_configured;
static DEFINE_MUTEX(mbox_configured_lock);
@@ -148,6 +147,10 @@ static void mbox_rx_work(struct work_struct *work)
if (mq-callback)
mq-callback((void *)msg);
+ if (mq-full) {
+ mq-full = false;
+ omap_mbox_enable_irq(mq-mbox, IRQ_RX);
+ }
}
}
@@ -170,7 +173,7 @@ static void __mbox_rx_interrupt(struct omap_mbox *mbox)
while (!mbox_fifo_empty(mbox)) {
if (unlikely(kfifo_avail(mq-fifo) sizeof(msg))) {
omap_mbox_disable_irq(mbox, IRQ_RX);
- rq_full = true;
+ mq-full = true;
goto nomem;
}
--
To unsubscribe from this list: send the line unsubscribe 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 v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
On 11/18/2010 8:15 PM, Hari Kanigeri wrote: disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigerih-kanige...@ti.com --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; l = mbox_read_reg(p-irqdisable); - l= ~bit; + if (cpu_is_omap44xx()) Since it is not omap version specific but IP version specific, you should not use cpu_is_ to do that. Moreover cpu_is calls should be used during init only. You can use the rev field in hwmod_class in order to detect the IP version. Smartreflex series for 3630 is already using that kind of mechanism. You will have to copy that revision information into pdata struct and then use that here. Benoit + l |= bit; + else + l= ~bit; mbox_write_reg(l, p-irqdisable); } -- To unsubscribe from this list: send the line unsubscribe 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 v3 2/5] OMAP: mailbox: fix rx interrupt disable in omap4
Benoit, On Thu, Nov 18, 2010 at 5:28 PM, Cousson, Benoit b-cous...@ti.com wrote: On 11/18/2010 8:15 PM, Hari Kanigeri wrote: disabling rx interrupt on omap4 is different than its pre-decessors. The bit in OMAP4_MAILBOX_IRQENABLE_CLR should be set to disable the interrupts instead of clearing the bit. Signed-off-by: Hari Kanigerih-kanige...@ti.com --- arch/arm/mach-omap2/mailbox.c | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 42dbfa4..82b5ced 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -195,7 +195,10 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox, struct omap_mbox2_priv *p = (struct omap_mbox2_priv *)mbox-priv; u32 l, bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit; l = mbox_read_reg(p-irqdisable); - l= ~bit; + if (cpu_is_omap44xx()) Since it is not omap version specific but IP version specific, you should not use cpu_is_ to do that. Moreover cpu_is calls should be used during init only. You can use the rev field in hwmod_class in order to detect the IP version. Smartreflex series for 3630 is already using that kind of mechanism. You will have to copy that revision information into pdata struct and then use that here. I see your point, but since mailbox hwmod patches from Omar are still under review I didn't find any other option than to enable this This is critical functionality that I want to include in and not wait till the hwmod patches are accepted. Please let me know if there is any other way of approaching this problem ? Thank you, Best regards, Hari -- To unsubscribe from this list: send the line unsubscribe 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/13] OMAP3: OFF mode fixes
Bunch of fixes as part of phase 1 targetting mainly OMAP3630 HS devices for OFF mode logic. It is important to note - for proper functionality of HS OFF mode on OMAP3630, CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE=y and CONFIG_OMAP3_L2_AUX_SECURE_SERVICE_SET_ID should be set to the correct service that the security PPA supports on the platform. Based on kernel.org 2.6.37-rc2 tag Smoke tested on: SDP3630 -GP Zoom3 (3630): GP EMU (Es1.1, ES1.2) SDP3430 - GP EMU (ES3.1) These are fixes for corner case bugs seen, so tests of off and ret done with wakeup timer - behavior between 2.6.37-rc2 before and after applying patch seen consistent. Request for testing this series for comparison between master and this series requested for additional platforms where available. Archana Sriram (1): OMAP3: PM: Errata i582: per domain reset issue: uart Eduardo Valentin (3): OMAP3: PM: Deny MPU idle while saving secure RAM OMAP3: PM: Apply errata i540 before save secure ram OMAP3630: PM: Errata i583: disable coreoff if ES1.2 Nishanth Menon (3): OMAP3: PM: make secure ram save size configurable OMAP3: PM: Fix secure save size for OMAP3 OMAP3630: PM: Errata i608: disable RTA Peter 'p2' De Schrijver (2): OMAP3: PM: Errata i581 suppport: dll kick strategy OMAP3630: PM: Disable L2 cache while invalidating L2 cache Richard Woodruff (1): OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all Tero Kristo (3): OMAP3: PM: Save secure RAM context before entering WFI OMAP3: PM: optional save secure RAM context every core off cycle OMAP3: PM: allocate secure RAM context memory from low-mem arch/arm/mach-omap2/control.c|5 +- arch/arm/mach-omap2/control.h|5 + arch/arm/mach-omap2/io.c | 11 ++ arch/arm/mach-omap2/pm.h | 40 +++ arch/arm/mach-omap2/pm34xx.c | 184 - arch/arm/mach-omap2/serial.c | 80 + arch/arm/mach-omap2/sleep34xx.S | 187 ++--- arch/arm/plat-omap/include/plat/serial.h |4 + 8 files changed, 412 insertions(+), 104 deletions(-) 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 07/13] OMAP3: PM: allocate secure RAM context memory from low-mem
From: Tero Kristo tero.kri...@nokia.com
Currently memory is allocated from kernel heap, which is located at high-mem.
Low-mem allocation is needed due to limitation in ROMCode which mirrors
memory every 256MB of memory blocks back to the first block
Allocation needs to be done later in the process compared to the traditional
reserve as the size required to be allocated depends on the cpu type we are
booting on, and is done as part of the map_io path instead of the reserve
path
[...@ti.com: modified to use memblock and rebased to 2.6.37-rc2]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/io.c | 11 +++
arch/arm/mach-omap2/pm.h |2 ++
arch/arm/mach-omap2/pm34xx.c | 39 ++-
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 40562dd..6098f81 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -41,6 +41,7 @@
#include plat/omap-pm.h
#include plat/powerdomain.h
#include powerdomains.h
+#include pm.h
#include plat/clockdomain.h
#include clockdomains.h
@@ -230,6 +231,13 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
+static void __init _omap_pm_reserve_sdram_memblock(void)
+{
+ if (cpu_is_omap34xx())
+ omap3_pm_reserve_sdram_memblock();
+
+}
+
static void __init _omap2_map_common_io(void)
{
/* Normally devicemaps_init() would flush caches and tlb after
@@ -241,6 +249,9 @@ static void __init _omap2_map_common_io(void)
omap2_check_revision();
omap_sram_init();
+
+ /* Allocate the secure SRAM storage after sram init and cpu detect */
+ _omap_pm_reserve_sdram_memblock();
}
#ifdef CONFIG_ARCH_OMAP2420
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 39934ec..fcca056 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -114,11 +114,13 @@ struct omap3_secure_copy_data {
#if defined(CONFIG_PM)
extern int __init omap3_secure_copy_data_set(struct omap3_secure_copy_data *d);
+extern void __init omap3_pm_reserve_sdram_memblock(void);
#else
static inline int omap3_secure_copy_data_set(struct omap3_secure_copy_data *d)
{
return -EINVAL;
}
+static inline void omap3_pm_reserve_sdram_memblock(void) { }
#endif
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index bbb1a40..7877f74 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/delay.h
#include linux/slab.h
+#include linux/memblock.h
#include plat/sram.h
#include plat/clockdomain.h
@@ -60,6 +61,8 @@ static struct omap3_secure_copy_data secure_copy_data = {
.save_every_cycle = false, /* explicit for readability */
};
+#define OMAP3_SECURE_MAX_ALLOCATE_ADDRESS 0x8fff
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -198,7 +201,7 @@ static void omap3_save_secure_ram_context(u32
target_mpu_state)
*/
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
secure_ram_save_status = _omap_save_secure_sram((u32 *)
- __pa(omap3_secure_ram_storage));
+ (omap3_secure_ram_storage));
pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
if (!secure_copy_data.save_every_cycle)
secure_ram_saved = 1;
@@ -1065,14 +1068,6 @@ static int __init omap3_pm_init(void)
omap3_idle_init();
clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
- if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
- omap3_secure_ram_storage =
- kmalloc(secure_copy_data.size, GFP_KERNEL);
- if (!omap3_secure_ram_storage)
- printk(KERN_ERR Memory allocation failed when
- allocating for secure sram context\n);
-
- }
omap3_save_scratchpad_contents();
err1:
@@ -1087,3 +1082,29 @@ err2:
}
late_initcall(omap3_pm_init);
+
+void __init omap3_pm_reserve_sdram_memblock(void)
+{
+ phys_addr_t size = secure_copy_data.size;
+ phys_addr_t paddr;
+ phys_addr_t max_addr = OMAP3_SECURE_MAX_ALLOCATE_ADDRESS;
+
+ if (!size || !cpu_is_omap34xx() || omap_type() == OMAP2_DEVICE_TYPE_GP)
+ return;
+
+ /*
+* On OMAP3 Silicon, due to ROM Code limitation, we should
+* not have the allocation beyond the first 256MB area.
+* This limitation is true for both OMAP3430 and 3630 and
+* all versions of the same.
+*/
+ paddr = memblock_alloc_base(size, SZ_1M, max_addr);
+
+ if (!paddr) {
+ pr_err(%s: failed to reserve %x bytes\n,
+ __func__, size);
+ return;
+ }
+
+
[PATCH 12/13] OMAP3630: PM: Disable L2 cache while invalidating L2 cache
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
This disables L2 cache before invalidating it and reenables it afterwards.
This is be done according to ARM documentation. Currently this is identified
as being needed on OMAP3630 as the disable enable is done from public side
while, on OMAP3430, this is done in the secure side.
[...@ti.com: ported to 2.6.37-rc2, added hooks to enable the logic only on 3630]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
---
arch/arm/mach-omap2/pm.h|2 ++
arch/arm/mach-omap2/pm34xx.c|4
arch/arm/mach-omap2/sleep34xx.S | 31 +++
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index fcca056..d50a1fc 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -115,12 +115,14 @@ struct omap3_secure_copy_data {
#if defined(CONFIG_PM)
extern int __init omap3_secure_copy_data_set(struct omap3_secure_copy_data *d);
extern void __init omap3_pm_reserve_sdram_memblock(void);
+extern void enable_omap3630_toggle_l2_on_restore(void);
#else
static inline int omap3_secure_copy_data_set(struct omap3_secure_copy_data *d)
{
return -EINVAL;
}
static inline void omap3_pm_reserve_sdram_memblock(void) { }
+static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1ced230..0102d60 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1052,6 +1052,10 @@ static void pm_errata_configure(void)
pm34xx_errata = ~PER_WAKEUP_ERRATA_i582;
if (cpu_is_omap3630())
pm34xx_errata |= RTA_ERRATA_i608;
+ /* Enable the l2 cache toggling in sleep logic */
+ if (cpu_is_omap3630())
+ enable_omap3630_toggle_l2_on_restore();
+
}
}
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 7259541..a5c63a6 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -111,6 +111,19 @@ ENTRY(get_omap3630_restore_pointer_sz)
.word . - get_omap3630_restore_pointer
.text
+/*
+ * L2 cache needs to be toggled for stable OFF mode functionality on 3630.
+ * This function sets up a fflag that will allow for this toggling to take
+ * place on 3630. Hopefully some version in the future maynot need this
+ */
+ENTRY(enable_omap3630_toggle_l2_on_restore)
+stmfd sp!, {lr} @ save registers on stack
+ /* Setup so that we will disable and enable l2 */
+ mov r1, #0x1
+ str r1, l2dis_3630
+ldmfd sp!, {pc} @ restore regs and return
+
+ .text
/* Function call to get the restore pointer for for ES3 to resume from OFF */
ENTRY(get_es3_restore_pointer)
stmfd sp!, {lr} @ save registers on stack
@@ -119,6 +132,7 @@ ENTRY(get_es3_restore_pointer)
ENTRY(get_es3_restore_pointer_sz)
.word . - get_es3_restore_pointer
+
ENTRY(es3_sdrc_fix)
ldr r4, sdrc_syscfg @ get config addr
ldr r5, [r4]@ get value
@@ -282,6 +296,14 @@ restore:
moveq r9, #0x3@ MPU OFF = L1 and L2 lost
movne r9, #0x1@ Only L1 and L2 lost = avoid L2 invalidation
bne logic_l1_restore
+
+ ldr r0, l2dis_3630
+ cmp r0, #0x1@ should we disable L2 on 3630?
+ bne skipl2dis
+ mrc p15, 0, r0, c1, c0, 1
+ bic r0, r0, #2 @ disable L2 cache
+ mcr p15, 0, r0, c1, c0, 1
+skipl2dis:
ldr r0, control_stat
ldr r1, [r0]
and r1, #0x700
@@ -342,6 +364,13 @@ smi:.word 0xE1600070 @ Call SMI monitor
(smieq)
mov r12, #0x2
.word 0xE1600070@ Call SMI monitor (smieq)
logic_l1_restore:
+ ldr r1, l2dis_3630
+ cmp r1, #0x1@ Do we need to re-enable L2 on 3630?
+ bne skipl2reen
+ mrc p15, 0, r1, c1, c0, 1
+ orr r1, r1, #2 @ re-enable L2 cache
+ mcr p15, 0, r1, c1, c0, 1
+skipl2reen:
mov r1, #0
/* Invalidate all instruction caches to PoU
* and flush branch target cache */
@@ -677,6 +706,8 @@ control_mem_rta:
.word CONTROL_MEM_RTA_CTRL
kernel_flush:
.word v7_flush_dcache_all
+l2dis_3630:
+ .word 0
/* these 2 words need to be at the end !!! */
kick_counter:
.word 0
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all
From: Richard Woodruff r-woodru...@ti.com Analysis in TI kernel with ETM showed that using cache mapped flush in kernel instead of SO mapped flush cost drops by 65% (3.39mS down to 1.17mS) for clean_l2 which is used during sleep sequences. Overall: - speed up - unfortunately there isn't a good alternative flush method today - code reduction and less maintenance and potential bug in unmaintained code This also fixes the bug with the clean_l2 function usage. Reported-by: Tony Lindgren t...@atomide.com [...@ti.com: ported rkw's proposal to 2.6.37-rc2] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Richard Woodruff r-woodru...@ti.com --- Side note: just dcache needs to be flushed based on inputs from TI internal team arch/arm/mach-omap2/sleep34xx.S | 79 ++ 1 files changed, 13 insertions(+), 66 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 2fb205a..8f207b2 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -520,72 +520,17 @@ clean_caches: cmp r9, #1 /* Check whether L2 inval is required or not*/ bne skip_l2_inval clean_l2: - /* read clidr */ - mrc p15, 1, r0, c0, c0, 1 - /* extract loc from clidr */ - andsr3, r0, #0x700 - /* left align loc bit field */ - mov r3, r3, lsr #23 - /* if loc is 0, then no need to clean */ - beq finished - /* start clean at cache level 0 */ - mov r10, #0 -loop1: - /* work out 3x current cache level */ - add r2, r10, r10, lsr #1 - /* extract cache type bits from clidr*/ - mov r1, r0, lsr r2 - /* mask of the bits for current cache only */ - and r1, r1, #7 - /* see what cache we have at this level */ - cmp r1, #2 - /* skip if no cache, or just i-cache */ - blt skip - /* select current cache level in cssr */ - mcr p15, 2, r10, c0, c0, 0 - /* isb to sych the new cssrcsidr */ - isb - /* read the new csidr */ - mrc p15, 1, r1, c0, c0, 0 - /* extract the length of the cache lines */ - and r2, r1, #7 - /* add 4 (line length offset) */ - add r2, r2, #4 - ldr r4, assoc_mask - /* find maximum number on the way size */ - andsr4, r4, r1, lsr #3 - /* find bit position of way size increment */ - clz r5, r4 - ldr r7, numset_mask - /* extract max number of the index size*/ - andsr7, r7, r1, lsr #13 -loop2: - mov r9, r4 - /* create working copy of max way size*/ -loop3: - /* factor way and cache number into r11 */ - orr r11, r10, r9, lsl r5 - /* factor index number into r11 */ - orr r11, r11, r7, lsl r2 - /*clean invalidate by set/way */ - mcr p15, 0, r11, c7, c10, 2 - /* decrement the way*/ - subsr9, r9, #1 - bge loop3 - /*decrement the index */ - subsr7, r7, #1 - bge loop2 -skip: - add r10, r10, #2 - /* increment cache number */ - cmp r3, r10 - bgt loop1 -finished: - /*swith back to cache level 0 */ - mov r10, #0 - /* select current cache level in cssr */ - mcr p15, 2, r10, c0, c0, 0 - isb + /* +* jump out to kernel flush routine +* - resue that code is better +* - it executes in a cached space so is faster than refetch per-block +* - should be faster and will change with kernel +* - 'might' have to copy address, load and jump to it +*/ + ldr r1, kernel_flush + mov lr, pc + bx r1 + skip_l2_inval: /* Data memory barrier and Data sync barrier */ mov r1, #0 @@ -668,5 +613,7 @@ cache_pred_disable_mask: .word 0xE7FB control_stat: .word CONTROL_STAT +kernel_flush: + .word v7_flush_dcache_all ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] OMAP3: PM: Apply errata i540 before save secure ram
From: Eduardo Valentin eduardo.valen...@nokia.com
We need to disable the autoidle bit from MPU INTC,
otherwise INTC would get stall, and we would never
come out of WFI. This must be done before save secure ram
as well because save secure ram also does WFI.
This patch is just a addition to the current W/A we have for i540,
in order to cover the WFI inside the save secure ram.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f520b38..c7e2db0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -422,6 +422,14 @@ void omap_sram_idle(void)
omap3_per_save_context();
}
+ /*
+* We need to disable the autoidle bit from MPU INTC,
+* otherwise INTC would get stall, and we would never
+* come out of WFI. This is done here because
+* save secure ram also does WFI.
+*/
+ omap3_intc_prepare_idle();
+
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
@@ -433,8 +441,6 @@ void omap_sram_idle(void)
}
}
- omap3_intc_prepare_idle();
-
/*
* On EMU/HS devices ROM code restores a SRDC value
* from scratchpad which has automatic self refresh on timeout
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] OMAP3: PM: Errata i582: per domain reset issue: uart
From: Archana Sriram archana.sri...@ti.com
Errata Id:i582
PER Domain reset issue after Domain-OFF/OSWR Wakeup.
Issue:
When Peripheral Power Domain (PER-PD) is woken up from OFF / OSWR
state while Core Power Domain (CORE-PD) is kept active, write or
read access to some internal memory (e.g., UART3 FIFO) does not
work correctly.
Workaround :
* Prevent PER from going off when CORE has not gone to off.
* When both CORE-PD and PER-PD goes into OSWR/OFF, PER-PD should be
brought to active before CORE-PD.This can be done by configuring a wakeup
dependency so that CORE-PD and PER-PD will wake up at the same time.
Acked-by: Tero Kristo tero.kri...@nokia.com
Tested-by: Eduardo Valentin eduardo.valen...@nokia.com
Tested-by: Westerberg Mika ext-mika.1.westerb...@nokia.com
[vishwanath...@ti.com: initial code and suggestions]
Signed-off-by: Vishwanath BS vishwanath...@ti.com
[...@ti.com: forward ported to 2.6.37-rc2 and suggestions]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Archana Sriram archana.sri...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 41 +++-
arch/arm/mach-omap2/serial.c | 80 ++
arch/arm/plat-omap/include/plat/serial.h |4 ++
3 files changed, 124 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c7e2db0..218d0b0 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -84,6 +84,10 @@ static struct powerdomain *cam_pwrdm;
static int secure_ram_save_status;
static int secure_ram_saved;
+#define PER_WAKEUP_ERRATA_i582 (1 0)
+static u16 pm34xx_errata;
+#define IS_PM34XX_ERRATA(id) (pm34xx_errata (id))
+
static inline void omap3_per_save_context(void)
{
omap_gpio_save_context();
@@ -371,7 +375,8 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON;
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
- int core_prev_state, per_prev_state;
+ int core_prev_state = PWRDM_POWER_ON;
+ int per_prev_state = PWRDM_POWER_ON;
u32 sdrc_pwr = 0;
if (!_omap_sram_idle)
@@ -496,6 +501,23 @@ void omap_sram_idle(void)
omap3_per_restore_context();
omap_uart_resume_idle(2);
omap_uart_resume_idle(3);
+ if (IS_PM34XX_ERRATA(PER_WAKEUP_ERRATA_i582)
+ omap_uart_check_per_uarts_used()
+ (core_prev_state == PWRDM_POWER_ON)
+ (per_prev_state == PWRDM_POWER_OFF)) {
+ /*
+* We dont seem to have a real recovery other than reset
+* Errata i582:Alternative available here is to do a
+* reboot OR go to per off/core off, we will just print
+* and cause uart to be in an unstable state and
+* continue on till we hit the next off transition.
+* Reboot of the device due to this corner case is
+* undesirable.
+*/
+ if (omap_uart_per_errata())
+ pr_err(%s: PER UART hit with Errata i582
+ Corner case.\n, __func__);
+ }
}
/* Disable IO-PAD and IO-CHAIN wakeup */
@@ -1021,15 +1043,27 @@ void omap_push_sram_idle(void)
save_secure_ram_context_sz);
}
+static void pm_errata_configure(void)
+{
+ if (cpu_is_omap34xx()) {
+ pm34xx_errata |= PER_WAKEUP_ERRATA_i582;
+ if (cpu_is_omap3630() (omap_rev() OMAP3630_REV_ES1_1))
+ pm34xx_errata = ~PER_WAKEUP_ERRATA_i582;
+ }
+}
+
static int __init omap3_pm_init(void)
{
struct power_state *pwrst, *tmp;
struct clockdomain *neon_clkdm, *per_clkdm, *mpu_clkdm, *core_clkdm;
+ struct clockdomain *wkup_clkdm;
int ret;
if (!cpu_is_omap34xx())
return -ENODEV;
+ pm_errata_configure();
+
printk(KERN_ERR Power Management for TI OMAP3.\n);
/* XXX prcm_setup_regs needs to be before enabling hw
@@ -1067,6 +1101,7 @@ static int __init omap3_pm_init(void)
neon_clkdm = clkdm_lookup(neon_clkdm);
mpu_clkdm = clkdm_lookup(mpu_clkdm);
per_clkdm = clkdm_lookup(per_clkdm);
+ wkup_clkdm = clkdm_lookup(wkup_clkdm);
core_clkdm = clkdm_lookup(core_clkdm);
omap_push_sram_idle();
@@ -1077,6 +1112,10 @@ static int __init omap3_pm_init(void)
pm_idle = omap3_pm_idle;
omap3_idle_init();
+ /* Allow per to wakeup the system if errata is applicable */
+ if (IS_PM34XX_ERRATA(PER_WAKEUP_ERRATA_i582) cpu_is_omap34xx())
+ clkdm_add_wkdep(per_clkdm, wkup_clkdm);
+
clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
[PATCH 03/13] OMAP3: PM: make secure ram save size configurable
OMAP3 users of HS/EMU devices at times choose to use their
own PPA which could be configured to use different sized storage
area based on their security needs. Convert the hardcoded size
define to a more configurable form to map to these users. we introduce
the structure omap3_secure_copy_data to describe PPA specific behavior
we will further populate in follow on patches. secure_copy_data_set
is introduced to allow for board files to populate custom parameters
as desired.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm.h | 23 +++
arch/arm/mach-omap2/pm34xx.c | 27 ++-
2 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 0d75bfd..c0af788 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -85,4 +85,27 @@ extern unsigned int save_secure_ram_context_sz;
extern unsigned int omap24xx_cpu_suspend_sz;
extern unsigned int omap34xx_cpu_suspend_sz;
+/**
+ * struct omap3_secure_copy_data - describe behavior for the secure ram copy
+ * @size: size of copy to be saved - this is based on the PPA used
+ * secure ram size could be configured to various sizes, this is
+ * the size used + 64 byte header required.
+ *
+ * Different platforms use different security PPAs based on their unique needs.
+ * This structure describes the delta behavior expected for these custom
+ * platforms. The defaults are configured for official TI OMAP3 PPA behavior.
+ */
+struct omap3_secure_copy_data {
+ u32 size;
+};
+
+#if defined(CONFIG_PM)
+extern int __init omap3_secure_copy_data_set(struct omap3_secure_copy_data *d);
+#else
+static inline int omap3_secure_copy_data_set(struct omap3_secure_copy_data *d)
+{
+ return -EINVAL;
+}
+#endif
+
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..633b696 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -54,6 +54,11 @@
#define OMAP343X_TABLE_VALUE_OFFSET 0xc0
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0xc8
+/* Secure ram save size - store the defaults */
+static struct omap3_secure_copy_data secure_copy_data = {
+ .size = 0x803F,
+};
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -154,6 +159,26 @@ static void omap3_core_restore_context(void)
omap_dma_global_context_restore();
}
+/**
+ * omap3_secure_copy_data_set() - set up the secure ram copy size
+ * @data - platform specific customization
+ *
+ * This function should be invoked by the board's init_irq function to update
+ * data prior to pm_init call is invoked. This call be done to update based on
+ * ppa used on that platform.
+ *
+ * Returns -EINVAL for bad values, and 0 if all good.
+ */
+int __init omap3_secure_copy_data_set(struct omap3_secure_copy_data *data)
+{
+ if (!data || !data-size)
+ return -EINVAL;
+
+ memcpy(secure_copy_data, data, sizeof(secure_copy_data));
+
+ return 0;
+}
+
/*
* FIXME: This function should be called before entering off-mode after
* OMAP3 secure services have been accessed. Currently it is only called
@@ -1038,7 +1063,7 @@ static int __init omap3_pm_init(void)
clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
omap3_secure_ram_storage =
- kmalloc(0x803F, GFP_KERNEL);
+ kmalloc(secure_copy_data.size, GFP_KERNEL);
if (!omap3_secure_ram_storage)
printk(KERN_ERR Memory allocation failed when
allocating for secure sram context\n);
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] OMAP3630: PM: Errata i608: disable RTA
Errata id: i608 RTA (Retention Till Access) feature is not supported and leads to device stability issues when enabled. This impacts modules with embedded memories on OMAP3630 Workaround is to disable RTA on boot and coming out of core off. For disabling rta coming out of off mode, we do this by overriding the restore pointer for 3630 to allow us restore handler as the first point of entry before caches are touched and is common for GP and HS devices. to disable earlier than this could be possible by modifying the ppa for HS devices, but not for GP devices. Signed-off-by: Ambresh K ambr...@ti.com Signed-off-by: Nishanth Menon n...@ti.com --- arch/arm/mach-omap2/control.c |5 - arch/arm/mach-omap2/control.h |5 + arch/arm/mach-omap2/pm34xx.c| 12 arch/arm/mach-omap2/sleep34xx.S | 25 + 4 files changed, 46 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 1fa3294..728f268 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -241,7 +241,10 @@ void omap3_save_scratchpad_contents(void) /* Populate the Scratchpad contents */ scratchpad_contents.boot_config_ptr = 0x0; - if (omap_rev() != OMAP3430_REV_ES3_0 + if (cpu_is_omap3630()) + scratchpad_contents.public_restore_ptr = + virt_to_phys(get_omap3630_restore_pointer()); + else if (omap_rev() != OMAP3430_REV_ES3_0 omap_rev() != OMAP3430_REV_ES3_1) scratchpad_contents.public_restore_ptr = virt_to_phys(get_restore_pointer()); diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index b6c6b7c..d7911c5 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -204,6 +204,10 @@ #define OMAP343X_CONTROL_WKUP_DEBOBS3 (OMAP343X_CONTROL_GENERAL_WKUP + 0x014) #define OMAP343X_CONTROL_WKUP_DEBOBS4 (OMAP343X_CONTROL_GENERAL_WKUP + 0x018) +/* 36xx-only RTA - Retention till Accesss control registers and bits */ +#define OMAP36XX_CONTROL_MEM_RTA_CTRL 0x40C +#define OMAP36XX_RTA_DISABLE 0x0 + /* 34xx D2D idle-related pins, handled by PM core */ #define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250 #define OMAP3_PADCONF_SAD2D_IDLEACK0x254 @@ -347,6 +351,7 @@ extern void omap3_save_scratchpad_contents(void); extern void omap3_clear_scratchpad_contents(void); extern u32 *get_restore_pointer(void); extern u32 *get_es3_restore_pointer(void); +extern u32 *get_omap3630_restore_pointer(void); extern u32 omap3_arm_context[128]; extern void omap3_control_save_context(void); extern void omap3_control_restore_context(void); diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 218d0b0..1ced230 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -85,6 +85,7 @@ static int secure_ram_save_status; static int secure_ram_saved; #define PER_WAKEUP_ERRATA_i582 (1 0) +#define RTA_ERRATA_i608(1 1) static u16 pm34xx_errata; #define IS_PM34XX_ERRATA(id) (pm34xx_errata (id)) @@ -1049,6 +1050,8 @@ static void pm_errata_configure(void) pm34xx_errata |= PER_WAKEUP_ERRATA_i582; if (cpu_is_omap3630() (omap_rev() OMAP3630_REV_ES1_1)) pm34xx_errata = ~PER_WAKEUP_ERRATA_i582; + if (cpu_is_omap3630()) + pm34xx_errata |= RTA_ERRATA_i608; } } @@ -1115,6 +1118,15 @@ static int __init omap3_pm_init(void) /* Allow per to wakeup the system if errata is applicable */ if (IS_PM34XX_ERRATA(PER_WAKEUP_ERRATA_i582) cpu_is_omap34xx()) clkdm_add_wkdep(per_clkdm, wkup_clkdm); + /* +* RTA is disabled during initialization as per errata i608 +* it is safer to disable rta by the bootloader, but we would like +* to be doubly sure here and prevent any mishaps. +*/ + if (IS_PM34XX_ERRATA(RTA_ERRATA_i608)) + omap_ctrl_writel(OMAP36XX_RTA_DISABLE, + OMAP36XX_CONTROL_MEM_RTA_CTRL); + clkdm_add_wkdep(neon_clkdm, mpu_clkdm); diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 5a4468f..7259541 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -45,6 +45,8 @@ #define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) #define SRAM_BASE_P0x4020 #define CONTROL_STAT 0x480022F0 +#define CONTROL_MEM_RTA_CTRL (OMAP343X_CTRL_BASE\ + + OMAP36XX_CONTROL_MEM_RTA_CTRL) #define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is * available */ #define SCRATCHPAD_BASE_P (OMAP343X_CTRL_BASE + OMAP343X_CONTROL_MEM_WKUP\ @@ -99,6 +101,14 @@ ENTRY(get_restore_pointer)
[PATCH 06/13] OMAP3: PM: Fix secure save size for OMAP3
Use TI recommended save_secure_ram size for OMAP3 using TI official
OMAP3 PPA. Note: custom platforms may have different save sizes.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/pm34xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index b20ecf5..bbb1a40 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -56,7 +56,7 @@
/* Secure ram save size - store the defaults */
static struct omap3_secure_copy_data secure_copy_data = {
- .size = 0x803F,
+ .size = 0xF040, /* 60k + 64 byte header */
.save_every_cycle = false, /* explicit for readability */
};
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] OMAP3: PM: Save secure RAM context before entering WFI
From: Tero Kristo tero.kri...@nokia.com
Currently this is done during initialization. move this to just before
wfi call in omap_sram_idle.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 35 ++-
1 files changed, 14 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 633b696..ba85e9c 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -77,6 +77,8 @@ static int (*_omap_save_secure_sram)(u32 *addr);
static struct powerdomain *mpu_pwrdm, *neon_pwrdm;
static struct powerdomain *core_pwrdm, *per_pwrdm;
static struct powerdomain *cam_pwrdm;
+static int secure_ram_save_status;
+static int secure_ram_saved;
static inline void omap3_per_save_context(void)
{
@@ -182,30 +184,22 @@ int __init omap3_secure_copy_data_set(struct
omap3_secure_copy_data *data)
/*
* 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
+ * once during first OFF transition, but this works as we are not using secure
* services.
*/
static void omap3_save_secure_ram_context(u32 target_mpu_state)
{
- u32 ret;
-
- if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ if (!secure_ram_saved omap_type() != OMAP2_DEVICE_TYPE_GP) {
/*
* MPU next state must be set to POWER_ON temporarily,
* otherwise the WFI executed inside the ROM code
* will hang the system.
*/
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
- ret = _omap_save_secure_sram((u32 *)
+ secure_ram_save_status = _omap_save_secure_sram((u32 *)
__pa(omap3_secure_ram_storage));
pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
- /* Following is for error tracking, it should not happen */
- if (ret) {
- printk(KERN_ERR save_secure_sram() returns %08x\n,
- ret);
- while (1)
- ;
- }
+ secure_ram_saved = 1;
}
}
@@ -426,6 +420,7 @@ void omap_sram_idle(void)
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+ omap3_save_secure_ram_context(mpu_next_state);
}
}
@@ -498,6 +493,13 @@ void omap_sram_idle(void)
pwrdm_post_transition();
+ /* Check if secure RAM save failed for some reason */
+ if (secure_ram_save_status 0) {
+ WARN(1, secure ram save failed (%d)\n,
+ secure_ram_save_status);
+ secure_ram_save_status = 0;
+ }
+
omap2_clkdm_allow_idle(mpu_pwrdm-pwrdm_clkdms[0]);
}
@@ -1068,15 +1070,6 @@ static int __init omap3_pm_init(void)
printk(KERN_ERR Memory allocation failed when
allocating for secure sram context\n);
- 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();
}
omap3_save_scratchpad_contents();
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] OMAP3: PM: Deny MPU idle while saving secure RAM
From: Eduardo Valentin eduardo.valen...@nokia.com
Deny MPU idle before save secure ram and allow it after save secure RAM.
We want to deny MPU going to low power state because, there is a short
time window where a wakeup event would happen around the time the MPU
is going to idle. Since the first thing ROM code does after WFI is to
read INTCPS register, we could reach a situation where the INTCPS is
in idle, but the read is sent to it. That would produce a data abord
during the save of secure ram, which will hang the system. we need
to prevent clock transitions as well during this timeframe.
[...@ti.com: rebased to 2.6.37-rc2, used omap2_clkdm_deny_idle for
clock prevention]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7877f74..f520b38 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -194,15 +194,19 @@ int __init omap3_secure_copy_data_set(struct
omap3_secure_copy_data *data)
static void omap3_save_secure_ram_context(u32 target_mpu_state)
{
if (!secure_ram_saved omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ struct clockdomain *clkd = mpu_pwrdm-pwrdm_clkdms[0];
+
/*
* MPU next state must be set to POWER_ON temporarily,
* otherwise the WFI executed inside the ROM code
* will hang the system.
*/
pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
+ omap2_clkdm_deny_idle(clkd);
secure_ram_save_status = _omap_save_secure_sram((u32 *)
(omap3_secure_ram_storage));
pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
+ omap2_clkdm_allow_idle(clkd);
if (!secure_copy_data.save_every_cycle)
secure_ram_saved = 1;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] OMAP3: PM: Errata i581 suppport: dll kick strategy
From: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com Errata i581 impacts OMAP3 platforms. PRCM DPLL control FSM removes SDRC_IDLEREQ before DPLL3 locks causing the DPLL not to be locked at times. IMPORTANT: this is not a complete workaround implementation as recommended by the silicon errata. this is a support logic for detecting lockups and attempting to recover where possible and is known to provide stability in multiple platforms. Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com --- arch/arm/mach-omap2/sleep34xx.S | 52 +++--- 1 files changed, 47 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S index 8f207b2..5a4468f 100644 --- a/arch/arm/mach-omap2/sleep34xx.S +++ b/arch/arm/mach-omap2/sleep34xx.S @@ -42,6 +42,7 @@ OMAP3430_PM_PREPWSTST) #define PM_PWSTCTRL_MPU_P OMAP3430_PRM_BASE + MPU_MOD + OMAP2_PM_PWSTCTRL #define CM_IDLEST1_CORE_V OMAP34XX_CM_REGADDR(CORE_MOD, CM_IDLEST1) +#define CM_IDLEST_CKGEN_V OMAP34XX_CM_REGADDR(PLL_MOD, CM_IDLEST) #define SRAM_BASE_P0x4020 #define CONTROL_STAT 0x480022F0 #define SCRATCHPAD_MEM_OFFS0x310 /* Move this as correct place is @@ -554,31 +555,67 @@ skip_l2_inval: /* Make sure SDRC accesses are ok */ wait_sdrc_ok: + +/* DPLL3 must be locked before accessing the SDRC. Maybe the HW ensures this. */ + ldr r4, cm_idlest_ckgen +wait_dpll3_lock: + ldr r5, [r4] + tst r5, #1 + beq wait_dpll3_lock + ldr r4, cm_idlest1_core +wait_sdrc_ready: ldr r5, [r4] -and r5, r5, #0x2 -cmp r5, #0 -bne wait_sdrc_ok +tst r5, #0x2 +bne wait_sdrc_ready + /* allow DLL powerdown upon hw idle req */ ldr r4, sdrc_power ldr r5, [r4] bic r5, r5, #0x40 str r5, [r4] -wait_dll_lock: +is_dll_in_lock_mode: + /* Is dll in lock mode? */ ldr r4, sdrc_dlla_ctrl ldr r5, [r4] tst r5, #0x4 bxnelr /* wait till dll locks */ -ldr r4, sdrc_dlla_status +wait_dll_lock_timed: + ldr r4, wait_dll_lock_counter + add r4, r4, #1 + str r4, wait_dll_lock_counter + ldr r4, sdrc_dlla_status +movr6, #8 /* Wait 20uS for lock */ +wait_dll_lock: + subsr6, r6, #0x1 + beq kick_dll ldr r5, [r4] and r5, r5, #0x4 cmp r5, #0x4 bne wait_dll_lock bx lr + /* disable/reenable DLL if not locked */ +kick_dll: + ldr r4, sdrc_dlla_ctrl + ldr r5, [r4] + mov r6, r5 + bic r6, #(13) /* disable dll */ + str r6, [r4] + dsb + orr r6, r6, #(13) /* enable dll */ + str r6, [r4] + dsb + ldr r4, kick_counter + add r4, r4, #1 + str r4, kick_counter + b wait_dll_lock_timed + cm_idlest1_core: .word CM_IDLEST1_CORE_V +cm_idlest_ckgen: + .word CM_IDLEST_CKGEN_V sdrc_dlla_status: .word SDRC_DLLA_STATUS_V sdrc_dlla_ctrl: @@ -615,5 +652,10 @@ control_stat: .word CONTROL_STAT kernel_flush: .word v7_flush_dcache_all + /* these 2 words need to be at the end !!! */ +kick_counter: + .word 0 +wait_dll_lock_counter: + .word 0 ENTRY(omap34xx_cpu_suspend_sz) .word . - omap34xx_cpu_suspend -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] OMAP3630: PM: Errata i583: disable coreoff if ES1.2
From: Eduardo Valentin eduardo.valen...@nokia.com
Limitation i583: Self_Refresh Exit issue after OFF mode
Issue:
When device is waking up from OFF mode, then SDRC state machine sends
inappropriate sequence violating JEDEC standards.
Impact:
OMAP3630 ES1.2 is impacted as follows depending on the platform:
CS0: for 38.4MHz as internal sysclk, DDR content seen to be stable, while
for all other sysclk frequencies, varied levels of instability
seen based on varied parameters.
CS1: impacted
This patch takes option #3 as recommended by the Silicon errata:
Avoid core power domain transitioning to OFF mode. Power consumption
impact is expected in this case.
To do this, we route OFF requests to RET request on the impacted revisions
of silicon.
[...@ti.com: rebased the code to 2.6.37-rc2- short circuit code changed a bit]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0102d60..1890e49 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -86,6 +86,7 @@ static int secure_ram_saved;
#define PER_WAKEUP_ERRATA_i582 (1 0)
#define RTA_ERRATA_i608(1 1)
+#define SDRC_WAKEUP_ERRATA_i583(1 0)
static u16 pm34xx_errata;
#define IS_PM34XX_ERRATA(id) (pm34xx_errata (id))
@@ -437,6 +438,17 @@ void omap_sram_idle(void)
omap3_intc_prepare_idle();
/* CORE */
+ /*
+* Errata i583: implementation for ES rev Es1.2 on 3630
+* We cannot enable OFF mode in a stable form for previous
+* revisions, transition instead to RET
+*/
+ if (IS_PM34XX_ERRATA(SDRC_WAKEUP_ERRATA_i583)
+ (core_next_state == PWRDM_POWER_OFF)) {
+ pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_RET);
+ core_next_state = PWRDM_POWER_RET;
+ }
+
if (core_next_state PWRDM_POWER_ON) {
omap_uart_prepare_idle(0);
omap_uart_prepare_idle(1);
@@ -1050,6 +1062,8 @@ static void pm_errata_configure(void)
pm34xx_errata |= PER_WAKEUP_ERRATA_i582;
if (cpu_is_omap3630() (omap_rev() OMAP3630_REV_ES1_1))
pm34xx_errata = ~PER_WAKEUP_ERRATA_i582;
+ if (cpu_is_omap3630() (omap_rev() OMAP3630_REV_ES1_2))
+ pm34xx_errata |= SDRC_WAKEUP_ERRATA_i583;
if (cpu_is_omap3630())
pm34xx_errata |= RTA_ERRATA_i608;
/* Enable the l2 cache toggling in sleep logic */
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] OMAP3: PM: optional save secure RAM context every core off cycle
From: Tero Kristo tero.kri...@nokia.com
Some PPAs now supports saving secure RAM context several times.
Now we will save it before every core off cycle.
board files can register with params to allow configuration based
on the PPA used.
[...@ti.com: converted to struct option for various PPAs in the wild]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
Signed-off-by: Tero Kristo tero.kri...@nokia.com
---
arch/arm/mach-omap2/pm.h | 13 +
arch/arm/mach-omap2/pm34xx.c |4 +++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index c0af788..39934ec 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -90,6 +90,18 @@ extern unsigned int omap34xx_cpu_suspend_sz;
* @size: size of copy to be saved - this is based on the PPA used
* secure ram size could be configured to various sizes, this is
* the size used + 64 byte header required.
+ * @save_every_cycle: While going to OFF mode and coming out of it on HS/EMU
+ * devices, secure service is provided to enable saving the
+ * contexts of secure ram and secure status of various drivers
+ * using secure devices. However, there are many kinds of secure
+ * conditions in the wild:
+ * 1. Implements its own save and restore using pm hooks
+ * 2. Generic drivers which depend on OMAP PM code to handle the
+ *same correspondingly, PPA may or may not allow capability
+ *to save in every transition to OFF mode.
+ * 3. PPA may be buggy and does'nt allow multiple saves
+ * Support of this depends heavily on the PPA used and the security
+ * driver capability. If in doubt, contact the security team.
*
* Different platforms use different security PPAs based on their unique needs.
* This structure describes the delta behavior expected for these custom
@@ -97,6 +109,7 @@ extern unsigned int omap34xx_cpu_suspend_sz;
*/
struct omap3_secure_copy_data {
u32 size;
+ bool save_every_cycle;
};
#if defined(CONFIG_PM)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index ba85e9c..b20ecf5 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -57,6 +57,7 @@
/* Secure ram save size - store the defaults */
static struct omap3_secure_copy_data secure_copy_data = {
.size = 0x803F,
+ .save_every_cycle = false, /* explicit for readability */
};
struct power_state {
@@ -199,7 +200,8 @@ static void omap3_save_secure_ram_context(u32
target_mpu_state)
secure_ram_save_status = _omap_save_secure_sram((u32 *)
__pa(omap3_secure_ram_storage));
pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
- secure_ram_saved = 1;
+ if (!secure_copy_data.save_every_cycle)
+ secure_ram_saved = 1;
}
}
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex
Hi Benoît, On Tue, 16 Nov 2010, Cousson, Benoit wrote: Funny, I was about to send you a RFC to get rid of that mutex :-) Today that mutex is preventing us to be re-entrant during hwmod lookup and for_each_by_class iteration, and we'd like to in order to manage link between 2 hwmods. The context is the link between mcbsp and sidetone on OMAP3. Since this module are tightly coupled, I was suggesting to Kishon to add the sidetone reference directly in the mcbsp hwmod in order to create a omap_device that will handle the 2 hwmods at the same time. Since we are using the iteration to get all the hwmod that belongs to the mcbsp class we cannot call the lookup function to get the sidetone hwmod at that time. For the moment we need to do 2 iteration and use intermediate storage to workaround that. After checking the purpose of the mutex, I was wondering if this is useful. For the moment the creation of the hwmod list is done only at init time, and nothing is supposed to change that at runtime except the unregister function. So I've started to get rid of this function, then of the mutex and I added the __init to all these registration functions to avoid the usage at runtime. It will save a little bit of memory as well. Thanks to that we can now use the omap_hwmod_lookup inside the omap_hwmod_for_each_by_class. Does that make sense to you? I can send you the patches if you want. Yep, that sounds fine to me. I'll plan to drop the mutex rename patch once you send your patch to avoid the noise. I guess that omap_hwmod_register() can become static also, and can be renamed to _register(), and we'll just use omap_hwmod_init() as the entry point to register hwmods. - Paul
Re: [PATCH v3] OMAP2+: PM: omap device: API's for handling mstandby mode
On Thu, Nov 18, 2010 at 04:21:48PM +0530, G, Manjunath Kondaiah wrote:
Certain errata's in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
releases no standby mode and sets it to smart standby or no
standby˝ depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata's which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata's:
1. Errata ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Errata ID: i541(all omap2plus except omap4)
sDMA FIFO draining does not finish
3. OMAP3430 ES1.0(Errata ID:i88) will require DMA to be put in
no mstandby mode before disabling the channel after completing
the data transfer operation.
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v2: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
arch/arm/mach-omap2/omap_hwmod.c | 45 +++-
arch/arm/plat-omap/include/plat/omap_device.h |3 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +-
arch/arm/plat-omap/omap_device.c | 73
+
4 files changed, 122 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..9c1c2fc 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,50 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod
*oh, u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
Sorry. I forgot to take mutex here. I will add this change and repost
this patch.
-Manjunath
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] OMAP2+: PM: omap device: API's for handling mstandby mode
Certain errata's in OMAP2+ processors will require forcing
master standby to no standby mode before completing on going
operation. Without this, the results will be unpredictable.
Since current implementation of PM run time framework does not support
changing sysconfig settings during middle of the on going operation,
these API's will support the same. One API will force the device's
sysconfig mstandby mode settings to no standby and other API will
releases no standby mode and sets it to smart standby or no
standby˝ depending on HWMOD_SWSUP_MSTANDBY value.
These API's should be used by device drivers only incase of
erratum applicable to their modules if there is no other methods
to resolve.
These API's are required for multiple DMA errata's which require
putting DMA controller in no mstandby mode before stopping dma.
The applicable errata's:
1. Errata ID: i557(Applicable for omap36xx all ES versions)
The channel hangs when the Pause bit (DMA4_CDPi [7] ) is cleared
through config port while in Standby.
2. Errata ID: i541(all omap2plus except omap4)
sDMA FIFO draining does not finish
3. OMAP3430 ES1.0(Errata ID:i88) will require DMA to be put in
no mstandby mode before disabling the channel after completing
the data transfer operation.
Also fixes typo HWMOD_SWSUP_MSTDBY to HWMOD_SWSUP_MSTANDBY in
omap_hwmod.h
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: linux-arm-ker...@lists.infradead.org
---
Change summary:
v3: Review comments incorporated for:
https://patchwork.kernel.org/patch/282212/
v4: added mutex changes
---
arch/arm/mach-omap2/omap_hwmod.c | 49 -
arch/arm/plat-omap/include/plat/omap_device.h |3 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h |4 +-
arch/arm/plat-omap/omap_device.c | 73 +
4 files changed, 126 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5a30658..43c90ba 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1427,6 +1427,54 @@ int omap_hwmod_set_slave_idlemode(struct omap_hwmod *oh,
u8 idlemode)
}
/**
+ * omap_hwmod_set_master_standbymode - set the hwmod's OCP mstandby mode
+ * @oh: struct omap_hwmod *
+ * @midlemode: flag to set mstandby to either no standby or smart standby
+ *
+ * Sets the IP block's OCP mstandby mode in hardware, and updates our
+ * local copy. Intended to be used by drivers that have some erratum
+ * that requires direct manipulation of the MIDLEMODE bits. Returns
+ * -EINVAL if @oh is null, or passes along the return value from
+ * _set_master_standbymode().
+ *
+ * Any users of this function should be scrutinized carefully.
+ */
+int omap_hwmod_set_master_standbymode(struct omap_hwmod *oh, u8 idlemode)
+{
+ u32 v;
+ u8 sf;
+ int retval = 0;
+
+ if (!oh)
+ return -EINVAL;
+
+ v = oh-_sysc_cache;
+
+ if (!oh-class-sysc)
+ return -EINVAL;
+
+ mutex_lock(omap_hwmod_mutex);
+
+ v = oh-_sysc_cache;
+ sf = oh-class-sysc-sysc_flags;
+
+ if (sf SYSC_HAS_MIDLEMODE) {
+ if (idlemode)
+ idlemode = HWMOD_IDLEMODE_NO;
+ else
+ idlemode = (oh-flags HWMOD_SWSUP_MSTANDBY) ?
+ HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+ }
+ retval = _set_master_standbymode(oh, idlemode, v);
+ if (!retval)
+ _write_sysconfig(v, oh);
+
+ mutex_unlock(omap_hwmod_mutex);
+
+ return retval;
+}
+
+/**
* omap_hwmod_register - register a struct omap_hwmod
* @oh: struct omap_hwmod *
*
@@ -2116,4 +2164,3 @@ int omap_hwmod_for_each_by_class(const char *classname,
return ret;
}
-
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 28e2d1a..14a6c46 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -109,13 +109,14 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
struct powerdomain *omap_device_get_pwrdm(struct omap_device *od);
/* Other */
-
int omap_device_idle_hwmods(struct omap_device *od);
int omap_device_enable_hwmods(struct omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_require_no_mstandby(struct platform_device *pdev);
+int omap_device_release_no_mstandby(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 7eaa8ed..c7ff65a 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -354,7 +354,7 @@ struct
