Re: [PATCH 0/2 v2] ARM: OMAP3: add support for cm-t35 board
Tony Lindgren wrote: * Mike Rapoport m...@compulab.co.il [091019 07:00]: Mike Rapoport wrote: The following patches add support for CompuLab CM-T35 board. Any comments on these? Just few cosmetic comments I just replied with. I will need to integrate the mach - plat headers series first before I'll start adding more code, so it will be few more days probably. Would you like me to rebase on top of linux-omap after the headers move will be integrated? Or just keep the patch on top of Linus' tree? Regards, Tony -- Sincerely yours, Mike. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, October 19, 2009 10:54 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; S, Venkatraman; Hari n; Jarkko
Nikula
Subject: Re: [PATCH v2] ARM: OMAP: SDMA: Fix omap_stop_dma() API for
channel linking
* Santosh Shilimkar santosh.shilim...@ti.com [091015 00:07]:
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma
when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Reviewed-By: Tony Lindgren t...@atomide.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/dma.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index fd3154a..1c933b4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -987,6 +987,11 @@ void omap_stop_dma(int lch)
/* Mark the current channel */
dma_chan_link_map[cur_lch] = 1;
+ /* Disable the DMA channel */
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
disable_lnk(cur_lch);
next_lch = dma_chan[cur_lch].next_lch;
Hmm, I'm thinking it should be like this instead to also clear
the dma_chan[lch].flags instead of returning before that.
Can you try this with your testcase?
This works too. OMAP1 doesn't support channel linking so this is fine. In case
it was, then it would have been an issue.
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 0eb676d..b53125f 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -978,6 +978,14 @@ void omap_stop_dma(int lch)
{
u32 l;
+ /* Disable all interrupts on the channel */
+ if (cpu_class_is_omap1())
+ dma_write(0, CICR(lch));
+
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1)
{
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -995,18 +1003,8 @@ void omap_stop_dma(int lch)
next_lch = dma_chan[cur_lch].next_lch;
cur_lch = next_lch;
} while (next_lch != -1);
-
- return;
}
- /* Disable all interrupts on the channel */
- if (cpu_class_is_omap1())
- dma_write(0, CICR(lch));
-
- l = dma_read(CCR(lch));
- l = ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
-
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
EXPORT_SYMBOL(omap_stop_dma);
--
To unsubscribe from this list: send the line unsubscribe 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 11/14] omap: Remap L3, L4 to get more kernel io address space
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, October 20, 2009 5:51 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 11/14] omap: Remap L3, L4 to get more kernel io address space * Tony Lindgren t...@atomide.com [091016 16:42]: From: Santosh Shilimkar santosh.shilim...@ti.com This patch remap L3 and L4 io space to get more kernel address space. With this patch, 512 MB of IO space is reclaimed. Some more combinations are possible but to make it uniform across OMAP24XX, OMAP34XX and OMAP4430, these io combinations are chosen Once this is reviewed and tested sufficiently, a documentation entry can be created to ease up reading and debugging. Like Documentation/arm/omap/io_map.txt Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/plat-omap/include/mach/io.h | 97 ++--- arch/arm/plat-omap/include/mach/vmalloc.h |2 - 2 files changed, 60 insertions(+), 39 deletions(-) snip diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/plat-omap/include/mach/vmalloc.h index b97dfaf..9eebf62 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/plat-omap/include/mach/vmalloc.h @@ -17,5 +17,5 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define VMALLOC_END (PAGE_OFFSET + 0x1800) +#define VMALLOC_END (PAGE_OFFSET + 0x3800) This vmalloc.h change causes issues on omap1. I'll update the series to ifdef this define. Then I'll split the file in the later patches into separate vmalloc.h for mach-omap1 and mach-omap2, see below. OK Regrads Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 08/14] omap: Use ioremap for omap4 L4 code
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Monday, October 19, 2009 10:42 PM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Shilimkar, Santosh santosh.shilim...@ti.com [091019 00:27]: Tony, -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Monday, October 19, 2009 5:54 AM To: Shilimkar, Santosh Cc: linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Tony Lindgren t...@atomide.com [091017 09:19]: * Shilimkar, Santosh santosh.shilim...@ti.com [091017 03:49]: Thanks Tony for this ioremap series!! -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, October 17, 2009 5:16 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org; Shilimkar, Santosh Subject: Re: [PATCH 08/14] omap: Use ioremap for omap4 L4 code * Tony Lindgren t...@atomide.com [091016 16:42]: Use ioremap for omap4 L4 code Santosh, can you please check and ack this patch? Especially some of the ioremap sizes may be wrong. Also, this one I cannot boot test, so it's just compile tested. I have checked the patch and it looks all right except few typo. Also the scu_base is needed bit earlier. snip Here is the patch on top of ioremap series which should fix above mentioned things. With below patch + two serial related patches the kernel boots on OMAP4430. Great, will update. Thanks for taking the time to fix it! Here's this one updated with Santosh's fix merged in. V2 has one typo which I think I also missed in my patch. + /* Static mapping, never released */ + gic_cpu_base_addr = ioremap(OMAP44XX_GIC_CPU_BASE, SZ_512); + BUG_ON(!base); Should be BUG_ON(!gic_cpu_base_addr); OK, here's V3 of the patch. It's complete now :) Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] FIX OMAP3:McBSP poll read and write for OMAP3
omap_mcbsp_pollwrite and omap_mcbsp_pollread functions access
McBSP registers as 16-bit registers.
In OMAP3, McBSP registers (DRR_REG and DXR_REG) are limited to
32-bit data accesses (L4 Interconnect). 16-bit and 8-bit is
not allowed and can corrupt register content.
This patch adds omap3_mcbsp_pollwrite and
omap3_mcbsp_pollread functions for OMAP3 cpu, inorder to
perform 32 bit access of above mentioned McBSP registers.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
---
arch/arm/plat-omap/include/mach/mcbsp.h |4 +
arch/arm/plat-omap/mcbsp.c | 92 ++-
2 files changed, 95 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 0c5f937..b0f9260 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -406,6 +406,10 @@ void omap_mcbsp_set_spi_mode(unsigned int id, const struct
omap_mcbsp_spi_cfg *
/* Polled read/write functions */
int omap_mcbsp_pollread(unsigned int id, u16 * buf);
int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
+
+int omap3_mcbsp_pollread(unsigned int id, u32 *buf);
+int omap3_mcbsp_pollwrite(unsigned int id, u32 buf);
+
int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t io_type);
#endif
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index b6b520d..1212d11 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -425,7 +425,7 @@ void omap_mcbsp_stop(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_stop);
-/* polled mcbsp i/o operations */
+/* polled mcbsp i/o operations for omap1 and omap2420 */
int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
{
struct omap_mcbsp *mcbsp;
@@ -515,6 +515,96 @@ int omap_mcbsp_pollread(unsigned int id, u16 *buf)
}
EXPORT_SYMBOL(omap_mcbsp_pollread);
+/* polled mcbsp i/o operations for omap3 */
+int omap3_mcbsp_pollwrite(unsigned int id, u32 buf)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *base;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+
+ mcbsp = id_to_mcbsp_ptr(id);
+ base = mcbsp-io_base;
+
+ OMAP_MCBSP_WRITE(base, DXR, buf);
+ /* if frame sync error - clear the error */
+ if (OMAP_MCBSP_READ(base, SPCR2) XSYNC_ERR) {
+ /* clear error */
+ OMAP_MCBSP_WRITE(base, SPCR2, OMAP_MCBSP_READ(base, SPCR2)
+(~XSYNC_ERR));
+ /* resend */
+ return -EPERM;
+ } else {
+ /* wait for transmit confirmation */
+ int attemps = 0;
+ while (!(OMAP_MCBSP_READ(base, SPCR2) XRDY)) {
+ if (attemps++ 1000) {
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2)
+ (~XRST));
+ udelay(10);
+ OMAP_MCBSP_WRITE(base, SPCR2,
+ OMAP_MCBSP_READ(base, SPCR2) |
+ (XRST));
+ udelay(10);
+ dev_err(mcbsp-dev, Could not write to
+McBSP%d Register\n, mcbsp-id);
+ return -ENOENT;
+ }
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(omap3_mcbsp_pollwrite);
+
+int omap3_mcbsp_pollread(unsigned int id, u32 *buf)
+{
+ struct omap_mcbsp *mcbsp;
+ void __iomem *base;
+
+ if (!omap_mcbsp_check_valid_id(id)) {
+ printk(KERN_ERR %s: Invalid id (%d)\n, __func__, id + 1);
+ return -ENODEV;
+ }
+ mcbsp = id_to_mcbsp_ptr(id);
+
+ base = mcbsp-io_base;
+ /* if frame sync error - clear the error */
+ if (OMAP_MCBSP_READ(base, SPCR1) RSYNC_ERR) {
+ /* clear error */
+ OMAP_MCBSP_WRITE(base, SPCR1, OMAP_MCBSP_READ(base, SPCR1)
+(~RSYNC_ERR));
+ /* resend */
+ return -EPERM;
+ } else {
+ /* wait for recieve confirmation */
+ int attemps = 0;
+ while (!(OMAP_MCBSP_READ(base, SPCR1) RRDY)) {
+ if (attemps++ 1000) {
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1)
+ (~RRST));
+ udelay(10);
+ OMAP_MCBSP_WRITE(base, SPCR1,
+ OMAP_MCBSP_READ(base, SPCR1) |
+ (RRST));
+
Re: [PATCH 5/5] mfd: twl4030-power: Optimised power scripts for the rx51
On Mon, Oct 19, 2009 at 04:22:39PM -0700, Tony Lindgren wrote:
* Samuel Ortiz sa...@linux.intel.com [091019 12:15]:
Hi Amit,
On Mon, Oct 19, 2009 at 03:11:08PM +0300, Amit Kucheria wrote:
The power scripts optimisation was mainly done by:
Tero Kristo tero.kri...@nokia.com and
Arnaud Mandy ext-arnaud.2.ma...@nokia.com
I'm only refactoring and testing it against the mainline kernel.
Fine with me but if you want me to carry this patch, I'd like to get an ACK
from Tony or one of the 2 above mentioned Nokia developers.
Acked-by: Tony Lindgren t...@atomide.com
Thanks Amit, Tony. Patch applied.
Cheers,
Samuel.
Cheers,
Samuel.
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Tero Kristo tero.kri...@nokia.com
Cc: linux-omap@vger.kernel.org
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 118
++
1 files changed, 82 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index c1af532..d933050 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -292,15 +292,9 @@ static struct twl4030_usb_data rx51_usb_data = {
static struct twl4030_ins sleep_on_seq[] __initdata = {
/*
- * Turn off VDD1 and VDD2.
+ * Turn off everything
*/
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_OFF), 4},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_OFF), 2},
-/*
- * And also turn off the OMAP3 PLLs and the sysclk output.
- */
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_OFF), 3},
- {MSG_SINGULAR(DEV_GRP_P1, 0x17, RES_STATE_OFF), 3},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 1, 0, RES_STATE_SLEEP), 2},
};
static struct twl4030_script sleep_on_script __initdata = {
@@ -311,14 +305,9 @@ static struct twl4030_script sleep_on_script
__initdata = {
static struct twl4030_ins wakeup_seq[] __initdata = {
/*
- * Reenable the OMAP3 PLLs.
- * Wakeup VDD1 and VDD2.
- * Reenable sysclk output.
+ * Reenable everything
*/
- {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_ACTIVE), 0x30},
- {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_ACTIVE), 0x30},
- {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_ACTIVE), 0x37},
- {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 3},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 1, 0, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wakeup_script __initdata = {
@@ -329,10 +318,9 @@ static struct twl4030_script wakeup_script
__initdata = {
static struct twl4030_ins wakeup_p3_seq[] __initdata = {
/*
- * Wakeup VDD1 (dummy to be able to insert a delay)
- * Enable CLKEN
+ * Reenable everything
*/
- {MSG_SINGULAR(DEV_GRP_P1, 0x17, RES_STATE_ACTIVE), 3},
+ {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 1, 0, RES_STATE_ACTIVE), 2},
};
static struct twl4030_script wakeup_p3_script __initdata = {
@@ -353,12 +341,11 @@ static struct twl4030_ins wrst_seq[] __initdata = {
{MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_OFF), 2},
{MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_ALL, 0, 1, RES_STATE_ACTIVE),
0x13},
- {MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 2, RES_STATE_WRST), 0x13},
{MSG_BROADCAST(DEV_GRP_NULL, RES_GRP_PP, 0, 3, RES_STATE_OFF), 0x13},
{MSG_SINGULAR(DEV_GRP_NULL, RES_VDD1, RES_STATE_WRST), 0x13},
{MSG_SINGULAR(DEV_GRP_NULL, RES_VDD2, RES_STATE_WRST), 0x13},
{MSG_SINGULAR(DEV_GRP_NULL, RES_VPLL1, RES_STATE_WRST), 0x35},
- {MSG_SINGULAR(DEV_GRP_P1, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
+ {MSG_SINGULAR(DEV_GRP_P3, RES_HFCLKOUT, RES_STATE_ACTIVE), 2},
{MSG_SINGULAR(DEV_GRP_NULL, RES_RESET, RES_STATE_ACTIVE), 2},
};
@@ -380,22 +367,81 @@ static struct twl4030_script *twl4030_scripts[]
__initdata = {
};
static struct twl4030_resconfig twl4030_rconfig[] __initdata = {
- { .resource = RES_VINTANA1, .devgroup = -1, .type = -1, .type2 = 1 },
- { .resource = RES_VINTANA2, .devgroup = -1, .type = -1, .type2 = 1 },
- { .resource = RES_VINTDIG, .devgroup = -1, .type = -1, .type2 = 1 },
- { .resource = RES_VMMC1, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VMMC2, .devgroup = DEV_GRP_NULL, .type = -1,
- .type2 = 3},
- { .resource = RES_VAUX1, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VAUX2, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VAUX3, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VAUX4, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VPLL2, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VDAC, .devgroup = -1, .type = -1, .type2 = 3},
- { .resource = RES_VSIM, .devgroup = DEV_GRP_NULL, .type = -1,
- .type2 = 3},
- { .resource = RES_CLKEN, .devgroup =
Re: [PATCH 1/5] mfd: twl4030-power: Rename DEVGROUP to DEV_GRP
Hi Amit,
On Tue, Oct 20, 2009 at 09:07:13AM +0300, Amit Kucheria wrote:
On 09 Oct 19, Samuel Ortiz wrote:
Hi Amit,
I've applied patches 1,2 and 3 to my for-next branch.
I dont think patch 4 is really useful, and I'll wait for an ACK from Tony or
Nokia before pushing patch 5.
Thanks for your work.
Cheers,
Samuel.
Samuel,
I hope you meant you're taking patches 1, 2, 4 and 5.
Yes, sorry about it. So, patches 1,2,4 and 5 applied.
Cheers,
Samuel.
3 is the one just moving stuff around and may be discarded.
Thanks.
Regards,
Amit
On Mon, Oct 19, 2009 at 03:10:44PM +0300, Amit Kucheria wrote:
Stick to the names used in the reference manual
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
Cc: sa...@linux.intel.com
Cc: linux-omap@vger.kernel.org
---
drivers/mfd/twl4030-power.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index d423e0c..82e3bcb 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -69,12 +69,12 @@ static u8 twl4030_start_script_address = 0x2b;
/* resource configuration registers */
-#define DEVGROUP_OFFSET 0
+#define DEV_GRP_OFFSET 0
#define TYPE_OFFSET 1
-/* Bit positions */
-#define DEVGROUP_SHIFT 5
-#define DEVGROUP_MASK(7 DEVGROUP_SHIFT)
+/* Bit positions in the registers */
+#define DEV_GRP_SHIFT5
+#define DEV_GRP_MASK (7 DEV_GRP_SHIFT)
#define TYPE_SHIFT 0
#define TYPE_MASK(7 TYPE_SHIFT)
#define TYPE2_SHIFT 3
@@ -328,7 +328,7 @@ static int __init twl4030_configure_resource(struct
twl4030_resconfig *rconfig)
/* Set resource group */
err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, grp,
- rconfig_addr + DEVGROUP_OFFSET);
+ rconfig_addr + DEV_GRP_OFFSET);
if (err) {
pr_err(TWL4030 Resource %d group could not be read\n,
rconfig-resource);
@@ -336,10 +336,10 @@ static int __init twl4030_configure_resource(struct
twl4030_resconfig *rconfig)
}
if (rconfig-devgroup = 0) {
- grp = ~DEVGROUP_MASK;
- grp |= rconfig-devgroup DEVGROUP_SHIFT;
+ grp = ~DEV_GRP_MASK;
+ grp |= rconfig-devgroup DEV_GRP_SHIFT;
err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
- grp, rconfig_addr + DEVGROUP_OFFSET);
+ grp, rconfig_addr + DEV_GRP_OFFSET);
if (err 0) {
pr_err(TWL4030 failed to program devgroup\n);
return err;
--
1.6.3.3
--
Intel Open Source Technology Centre
http://oss.intel.com/
--
Amit Kucheria, Finland
--
Intel Open Source Technology Centre
http://oss.intel.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 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core
On Mon, Oct 19, 2009 at 03:42:17PM +0300, Peter Ujfalusi wrote: New MFD child to twl4030 MFD device. This MFD device will be used by the drivers, which needs resources from the twl4030 codec like audio and vibra. The platform specific configuration data is passed along to the child drivers (audio, vibra). Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com +config TWL4030_CODEC + bool Support codec part of the TWL4030 family chips This seems like something that users shouldn't really have to worry about selecting explicitly - might it be better to have it selected by the drivers that use it instead? It feels like it's an implementation detail of the driver. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD
On Mon, Oct 19, 2009 at 03:42:20PM +0300, Peter Ujfalusi wrote:
TWL4030 codec is now using the device registration via
tlw4030_codec MFD device.
This looks pretty good but obviously depends on the MFD changes. The
major thing that jumps out at me is the removal of the register
definitions from the ASoC headers - it might be nice to have that done
as part of the MFD patch, or as a separate patch.
You've also got the bias being brought up when the ASoC system comes up
rather than when the driver comes up. To be honest it doesn't really
make any difference either way, it's just slightly different to other
drivers. What is useful with things like twl4030 which take a little
while to come up is if you can do the bias bringup out of line from
device probe, avoiding blocking system startup on CODEC bringup. That's
definitely a separate patch, I'm just mentioning it for interest here.
There's also a couple of debug prints (like in the remove function) and
+MODULE_ALIAS(platform:twl4030_codec:audio);
Is that second colon right given...
+ .driver = {
+ .name = twl4030_codec_audio,
+ .owner = THIS_MODULE,
this.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP3: move check_revision above check_features
omap3_check_revision() does not depend on omap3_check_features()
move this above so that we can add logic based on revision
detected in check_features.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/id.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 1c15112..702d3b4 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -328,8 +328,8 @@ void __init omap2_check_revision(void)
if (cpu_is_omap24xx())
omap24xx_check_revision();
else if (cpu_is_omap34xx()) {
- omap3_check_features();
omap3_check_revision();
+ omap3_check_features();
omap3_cpuinfo();
}
else if (cpu_is_omap44xx()) {
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP3: introduce DPLL4 Jtype
The patchset introduces jtype DPLLs which as a first stage introduces it for 3630. 3430 has a previous version of DPLL and process changes in 3630 neccessitates this for DPLL4 Patchset has been created for linux-omap - tmlind tree Nishanth Menon (1): OMAP3: move check_revision above check_features Richard Woodruff (1): OMAP3:clk - introduce DPLL4 jtype support arch/arm/mach-omap2/clock34xx.c | 45 ++- arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++- arch/arm/mach-omap2/id.c|5 +++- arch/arm/plat-omap/include/plat/clock.h |3 ++ arch/arm/plat-omap/include/plat/cpu.h |2 + 5 files changed, 58 insertions(+), 3 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 2/2] OMAP3:clk: introduce DPLL4 jtype support
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block requiring
special divisor bits and additional reg fields
To allow for silicons to use this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630
silicon
Tested with SDP3430, SDP3630
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Sonasath, Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 45 ++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|3 ++
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |2 +
5 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index c258f87..ba96023 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -675,6 +675,40 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv -j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16 m, u8 n)
+{
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+ ++n; /* always n+1 below */
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+ * target sigma-delta to near 250MHz
+ * sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+ */
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ ++sd;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -707,6 +741,13 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
v = ~(dd-mult_mask | dd-div1_mask);
v |= m __ffs(dd-mult_mask);
v |= (n - 1) __ffs(dd-div1_mask);
+ if (dd-jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, dco, sd_div, m, n);
+ v = ~(dd-dco_sel_mask | dd-sd_div_mask);
+ v |= dco __ffs(dd-dco_sel_mask);
+ v |= sd_div __ffs(dd-sd_div_mask);
+ }
__raw_writel(v, dd-mult_div1_reg);
/* We let the clock framework set the other output dividers later */
@@ -1022,7 +1063,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
v = __raw_readl(dd-control_reg) dd-enable_mask;
v = __ffs(dd-enable_mask);
- if (v != OMAP3XXX_EN_DPLL_LOCKED)
+ if (v != OMAP3XXX_EN_DPLL_LOCKED (!dd-jtype))
rate = clk-parent-rate;
else
rate = clk-parent-rate * 2;
@@ -1135,6 +1176,8 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (omap3_has_jtype_dpll4())
+ dpll4_ck.dpll_data-jtype = 1;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 702d3b4..9cc 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,8 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
+ if (cpu_is_omap3630())
+ omap3_features |= OMAP3_HAS_JTYPE_DPLL4;
/*
* TODO: Get additional info (where applicable)
* e.g. Size of L2 cache.
@@ -314,6 +316,7 @@ void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(sgx);
Re: [alsa-devel] [PATCH 1/4] MFD: twl4030: add twl4030_codec MFD as a new child to the core
On Tuesday 20 October 2009 13:03:34 ext Mark Brown wrote: On Mon, Oct 19, 2009 at 03:42:17PM +0300, Peter Ujfalusi wrote: New MFD child to twl4030 MFD device. This MFD device will be used by the drivers, which needs resources from the twl4030 codec like audio and vibra. The platform specific configuration data is passed along to the child drivers (audio, vibra). Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com +config TWL4030_CODEC + bool Support codec part of the TWL4030 family chips This seems like something that users shouldn't really have to worry about selecting explicitly - might it be better to have it selected by the drivers that use it instead? It feels like it's an implementation detail of the driver. Yes, first I had the TWL4030_CODEC selected in the sound/soc/codecs/Kconfig, but for some reason I have decided to add user selectable config option instead and use the depends on in the codecs Makefile. I'll make the change as you suggested. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD
On Tuesday 20 October 2009 13:25:40 ext Mark Brown wrote:
On Mon, Oct 19, 2009 at 03:42:20PM +0300, Peter Ujfalusi wrote:
TWL4030 codec is now using the device registration via
tlw4030_codec MFD device.
This looks pretty good but obviously depends on the MFD changes.
Thanks, yes it all depends on the MFD changes.
The major thing that jumps out at me is the removal of the register
definitions from the ASoC headers - it might be nice to have that done
as part of the MFD patch, or as a separate patch.
The reason why I have done it like this is that with one patch I only touch one
subsystem at the time:
1. MFD changes only
2. OMAP related changes
3. soc codec driver change
In patch 1, the register definitions had to be added, so that the twl4030_codec
driver knows the registers (and there could be the vibra driver placed
separately from the soc codec driver).
In patch 3, where I modify the soc codec driver to use the new method, than I
remove the definitions and use the existing header file, introduced by the
first
patch.
All in all, after each patch the kernel can be builds, boots and works as
before.
You've also got the bias being brought up when the ASoC system comes up
rather than when the driver comes up. To be honest it doesn't really
make any difference either way, it's just slightly different to other
drivers.
I was thinking that if you built the kernel with SND_SOC_ALL_CODECS on OMAP
platform for some reason and you don't actually use the twl4030 as audio device
- no machine driver, which would use it, than the codec part would be off.
But yes, probably I can move the povering up to the probe function.
What is useful with things like twl4030 which take a little
while to come up is if you can do the bias bringup out of line from
device probe, avoiding blocking system startup on CODEC bringup. That's
definitely a separate patch, I'm just mentioning it for interest here.
I'm sure there will be another round for this series, so I can make this change
at the same time within the patch, since this anyway changes the way how the
driver is loaded/probed.
There's also a couple of debug prints (like in the remove function) and
I'll get rid of them.
But at least this time I did not had those unneeded casts, which I usually have
;)
+MODULE_ALIAS(platform:twl4030_codec:audio);
Is that second colon right given...
I'm not sure about it at all either. I did not found any other 'nested MFD'
drivers around, so this is just a guess
Should it be:
+MODULE_ALIAS(platform:twl4030_codec_audio);
+ .driver = {
+ .name = twl4030_codec_audio,
+ .owner = THIS_MODULE,
this.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD
On Tue, Oct 20, 2009 at 02:30:49PM +0300, Peter Ujfalusi wrote: In patch 1, the register definitions had to be added, so that the twl4030_codec driver knows the registers (and there could be the vibra driver placed separately from the soc codec driver). In patch 3, where I modify the soc codec driver to use the new method, than I remove the definitions and use the existing header file, introduced by the first patch. All in all, after each patch the kernel can be builds, boots and works as before. Sure, though I suspect patch 3 could just be split in two happily with an include. I don't really mind either way. If you are going to keep them as one patch it'd be good to call out the move in the changelog. You've also got the bias being brought up when the ASoC system comes up rather than when the driver comes up. To be honest it doesn't really make any difference either way, it's just slightly different to other drivers. I was thinking that if you built the kernel with SND_SOC_ALL_CODECS on OMAP platform for some reason and you don't actually use the twl4030 as audio device - no machine driver, which would use it, than the codec part would be off. But yes, probably I can move the povering up to the probe function. That's a good enough reason to leave things as they are, though really if you're building SND_SOC_ALL_CODECs in a production system you're being a bit strange. +MODULE_ALIAS(platform:twl4030_codec:audio); Is that second colon right given... I'm not sure about it at all either. I did not found any other 'nested MFD' drivers around, so this is just a guess Should it be: +MODULE_ALIAS(platform:twl4030_codec_audio); Yes. The aliasing makes no reference to the parents of the device, it only cares about the device name - for the purposes of module loading and driver matching it's identical to any other platform device. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD
On Tuesday 20 October 2009 14:51:06 ext Mark Brown wrote: Sure, though I suspect patch 3 could just be split in two happily with an include. I don't really mind either way. If you are going to keep them as one patch it'd be good to call out the move in the changelog. I'll split the soc codec patch to two, one is changing the header the other is for the change in the codec driver. That's a good enough reason to leave things as they are, though really if you're building SND_SOC_ALL_CODECs in a production system you're being a bit strange. Fair enough. +MODULE_ALIAS(platform:twl4030_codec_audio); Yes. The aliasing makes no reference to the parents of the device, it only cares about the device name - for the purposes of module loading and driver matching it's identical to any other platform device. Good to know, I'll change this as well. Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] twl4030: Do not dereference null pointer in error path
Hi Samuel,
From: ext Samuel Ortiz [mailto:sa...@linux.intel.com]
Sent: 19 October, 2009 18:53
On Fri, Oct 16, 2009 at 04:21:41PM +0200,
ilkka.koski...@nokia.com wrote:
Hi Samuel,
What is the status of this patch and the other one:
[PATCH 2/2] twl4030: Enable low-power mode to 32KHz oscillator
I'm sorry but it seems I havent received those 2 patches.
Could you please
re-send them ?
Sorry, my mistake. I already forgot that the patches never
reached you. I'll resend them right away.
Cheers, Ilkka
-Original Message-
From: Koskinen Ilkka (Nokia-D/Tampere)
Sent: 30 September, 2009 18:12
To: linux-ker...@vger.kernel.org; sa...@linux.intel.com
Cc: linux-omap@vger.kernel.org; Koskinen Ilkka (Nokia-D/Tampere)
Subject: [PATCH 1/2] twl4030: Do not dereference null pointer
in error path
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
drivers/mfd/twl4030-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index e424cf6..8cf0a02 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -792,7 +792,7 @@ twl4030_probe(struct i2c_client *client,
const struct i2c_device_id *id)
twl-client = i2c_new_dummy(client-adapter,
twl-address);
if (!twl-client) {
- dev_err(twl-client-dev,
+ dev_err(client-dev,
can't attach client %d\n, i);
status = -ENOMEM;
goto fail;
--
1.6.0.4
--
Intel Open Source Technology Centre
http://oss.intel.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 2/2] OMAP3:clk: introduce DPLL4 jtype support
Nishanth,
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Tuesday, October 20, 2009 5:49 AM
From: Richard Woodruff r-woodru...@ti.com
DPLL4 for 3630 introduces a changed block requiring
special divisor bits and additional reg fields
To allow for silicons to use this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630
silicon
Tested with SDP3430, SDP3630
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Sonasath, Moiz Sonasath m-sonas...@ti.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 45
++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|3 ++
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |2 +
5 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c
b/arch/arm/mach-omap2/clock34xx.c
index c258f87..ba96023 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -675,6 +675,40 @@ static void
omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv -j-type DPLL4 compensation variables
Put a space before the j-type, and add better description.
Doesn't clarify what it really does IMHO:
Something like:
* lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div,
u16 m, u8 n)
+{
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
Add Space after var declarations.
Declare function as static.
Should you do something like:
BUG_ON(!clk-parent);
? (not sure)
What do you think?
Regards,
Sergio
+ ++n; /* always n+1 below */
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+ * target sigma-delta to near 250MHz
+ * sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+ */
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ ++sd;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -707,6 +741,13 @@ static int
omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16 freqsel)
v = ~(dd-mult_mask | dd-div1_mask);
v |= m __ffs(dd-mult_mask);
v |= (n - 1) __ffs(dd-div1_mask);
+ if (dd-jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, dco, sd_div, m, n);
+ v = ~(dd-dco_sel_mask | dd-sd_div_mask);
+ v |= dco __ffs(dd-dco_sel_mask);
+ v |= sd_div __ffs(dd-sd_div_mask);
+ }
__raw_writel(v, dd-mult_div1_reg);
/* We let the clock framework set the other output
dividers later */
@@ -1022,7 +1063,7 @@ static unsigned long
omap3_clkoutx2_recalc(struct clk *clk)
v = __raw_readl(dd-control_reg) dd-enable_mask;
v = __ffs(dd-enable_mask);
- if (v != OMAP3XXX_EN_DPLL_LOCKED)
+ if (v != OMAP3XXX_EN_DPLL_LOCKED (!dd-jtype))
rate = clk-parent-rate;
else
rate = clk-parent-rate * 2;
@@ -1135,6 +1176,8 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (omap3_has_jtype_dpll4())
+ dpll4_ck.dpll_data-jtype = 1;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT 8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK
(0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK
(0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK
(0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK(0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff
RE: [PATCH 2/2] OMAP3:clk: introduce DPLL4 jtype support
From: Aguirre Rodriguez, Sergio Alberto Sent: Tuesday, October 20, 2009 9:16 AM + * lookup_dco_sddiv -j-type DPLL4 compensation variables Put a space before the j-type, and add better description. Doesn't clarify what it really does IMHO: Something like: * lookup_dco_sddiv - Set j-type DPLL4 compensation variables For 45nm it was necessary to use a different DPLL IP for DPLL4 (dpllj). The other DPLLs are same which was used in 65nm (dpllm). The register interface is slightly different. Code could have said is type A or B, but simple choice was to follow internal name convention. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] OMAP3: PM: Configure PRM setup times from board files
Rajendra Nayak rna...@ti.com writes:
The setup times to be programmed in the PRM module on OMAP
(for clksetup, voltsetup etc) are board specific.
They depend heavily on the PMIC used and even on different boards
with the same PMIC, they vary based on the sleep/wake
sequence used, system clock speed et al.
This patch makes it possible for these setup values to be
configured from different board files.
omap3_pm_init_vc() can now be optionally called from board files
to initialise the setup times. If board files do not use
this function to pass the setup times, default/conservative
values are used which are safe but would cause higher wakeup
latencies from sleep states.
This patch only updates the 3430sdp board file to use
omap3_pm_init_vc() to update the setup times.
Signed-off-by: Rajendra Nayak rna...@ti.com
Thanks, pulling into PM branch.
Kevin
---
arch/arm/mach-omap2/board-3430sdp.c | 18 ++
arch/arm/mach-omap2/pm.h|2 +-
arch/arm/mach-omap2/pm34xx.c|5 -
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 14868b5..0f1975c 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -56,6 +56,23 @@
#define TWL4030_MSECURE_GPIO 22
+/* FIXME: These are not the optimal setup values to be used on 3430sdp*/
+static struct prm_setup_vc omap3_setuptime_table = {
+ .clksetup = 0xff,
+ .voltsetup_time1 = 0xfff,
+ .voltsetup_time2 = 0xfff,
+ .voltoffset = 0xff,
+ .voltsetup2 = 0xff,
+ .vdd0_on = 0x30,
+ .vdd0_onlp = 0x20,
+ .vdd0_ret = 0x1e,
+ .vdd0_off = 0x00,
+ .vdd1_on = 0x2c,
+ .vdd1_onlp = 0x20,
+ .vdd1_ret = 0x1e,
+ .vdd1_off = 0x00,
+};
+
static int board_keymap[] = {
KEY(0, 0, KEY_LEFT),
KEY(0, 1, KEY_RIGHT),
@@ -185,6 +202,7 @@ static void __init omap_3430sdp_init_irq(void)
{
omap_board_config = sdp3430_config;
omap_board_config_size = ARRAY_SIZE(sdp3430_config);
+ omap3_pm_init_vc(omap3_setuptime_table);
omap2_init_common_hw(hyb18m512160af6_sdrc_params, NULL,
omap3_mpu_rate_table,
omap3_dsp_rate_table, omap3_l3_rate_table);
omap_init_irq();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f8d11a2..ca673c5 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -41,7 +41,7 @@ struct prm_setup_vc {
u16 vdd1_ret;
u16 vdd1_off;
};
-extern void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc);
+extern void omap3_pm_init_vc(struct prm_setup_vc *setup_vc);
extern int resource_set_opp_level(int res, u32 target_level, int flags);
extern int resource_access_opp_lock(int res, int delta);
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 01260ec..3d7ae2f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -1027,8 +1027,11 @@ int omap3_pm_set_suspend_state(struct powerdomain
*pwrdm, int state)
return -EINVAL;
}
-void omap3_set_prm_setup_vc(struct prm_setup_vc *setup_vc)
+void omap3_pm_init_vc(struct prm_setup_vc *setup_vc)
{
+ if (!setup_vc)
+ return;
+
prm_setup.clksetup = setup_vc-clksetup;
prm_setup.voltsetup_time1 = setup_vc-voltsetup_time1;
prm_setup.voltsetup_time2 = setup_vc-voltsetup_time2;
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework
Sripathy, Vishwanath vishwanath...@ti.com writes:
Sysfs entry vdd_opp currently does not use constraint framework.
Because of this, even if you set the opp via this entry, it has no effect
since it can be overridden by on demand governor any time.
This patch has changes to make vdd_opp to use constraint framework.
vdd_lock variable has to be used when application wants to disable DVFS
altogether. This will override any other constraints and will lock the
OPP to given value.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
This raises an issue that I've been thinking about for awhile.
Basically, I'd like to drop all the /sys/power/vdd* options.
Since we can do the equivalent with CPUFreq using the userspace
governor, I don't see the point of having an additional interface.
Comments?
Kevin
---
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 13783f3..bcdc00d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ static ssize_t idle_store(struct kobject *k, struct
kobj_attribute *,
static ssize_t vdd_opp_show(struct kobject *, struct kobj_attribute *, char
*);
static ssize_t vdd_opp_store(struct kobject *k, struct kobj_attribute *,
const char *buf, size_t n);
+static ssize_t vdd_opp_lock_store(struct kobject *k, struct kobj_attribute *,
+ const char *buf, size_t n);
static struct kobj_attribute vdd1_opp_attr =
__ATTR(vdd1_opp, 0644, vdd_opp_show, vdd_opp_store);
@@ -103,6 +105,41 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
const char *buf, size_t n)
{
unsigned short value;
+ struct omap_opp *opp_table;
+
+ if (sscanf(buf, %hu, value) != 1)
+ return -EINVAL;
+
+ if (attr == vdd1_opp_attr) {
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ opp_table = omap_get_mpu_rate_table();
+ omap_pm_cpu_set_freq(sysfs_cpufreq_dev,
+ opp_table[value].rate);
+ } else if (attr == vdd2_opp_attr) {
+ if (value MIN_VDD2_OPP || (value MAX_VDD2_OPP)) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ if (value == VDD2_OPP2)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 83*1000*4);
+ else if (value == VDD2_OPP3)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 166*1000*4);
+
+ } else {
+ return -EINVAL;
+ }
+ return n;
+}
+
+static ssize_t vdd_opp_lock_store(struct kobject *kobj,
+ struct kobj_attribute *attr, const char *buf, size_t n)
+{
+ unsigned short value;
int flags = 0;
if (sscanf(buf, %hu, value) != 1)
@@ -121,6 +158,11 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
if (vdd1_locked == 0 value != 0) {
resource_lock_opp(VDD1_OPP);
vdd1_locked = 1;
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD1_OPP, value, flags);
}
} else if (attr == vdd2_lock_attr) {
flags = OPP_IGNORE_LOCK;
@@ -134,21 +176,12 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
if (vdd2_locked == 0 value != 0) {
resource_lock_opp(VDD2_OPP);
vdd2_locked = 1;
+ if (value MIN_VDD2_OPP || value MAX_VDD2_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD2_OPP, value, flags);
}
- }
-
- if (attr == vdd1_opp_attr) {
- if (value 1 || value 5) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD1_OPP, value, flags);
- } else if (attr == vdd2_opp_attr) {
- if (value 2 || value 3) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD2_OPP, value, flags);
} else {
return -EINVAL;
}
--
To unsubscribe from this list:
Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
tero.kri...@nokia.com writes:
There was one report from a custom board when it made a
difference. I've not tried to double check
this data. I don't have the reporters setup so there is no
guarantee I could reproduce anyway. In
general optimization seemed to make sense.
I second it.
Regards,
Girish
Is there errata number available for this issue by the way? I could attach
this to the patch.
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
Except omap_write* functions are deprecated.
I'd rather see a call into the interrupt code. Something like
omap_intc_prepare_idle()
Also, isn't this only needed if CORE != ON?
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
and omap_intc_resume_idle()
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 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message-
From: ext Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: 20 October, 2009 19:02
To: Kristo Tero (Nokia-D/Tampere)
Cc: giris...@ti.com; r-woodru...@ti.com;
linux-omap@vger.kernel.org; Hogander Jouni (Nokia-D/Tampere)
Subject: Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in
interrupt controller
tero.kri...@nokia.com writes:
There was one report from a custom board when it made a
difference. I've not tried to double check
this data. I don't have the reporters setup so there is no
guarantee I could reproduce anyway. In
general optimization seemed to make sense.
I second it.
Regards,
Girish
Is there errata number available for this issue by the way?
I could attach this to the patch.
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO,
WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of
sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
Except omap_write* functions are deprecated.
I see, will use __raw_writel here then.
I'd rather see a call into the interrupt code. Something like
omap_intc_prepare_idle()
Can do these changes to add the interface yes. Though name would be
omap3_intc_prepare_idle() / ...resume_idle() as this is only needed for OMAP3.
Also, isn't this only needed if CORE != ON?
I understood from the problem description that this is needed always when we
are entering WFI, because we might have L3/L4 sleep/run transitions there even
if CORE is on.
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE +
INTC_SYSCONFIG);
and omap_intc_resume_idle()
-Tero--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/17] OMAP3: PM: Dynamic check for CORE target state
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
Sleep code will now check if core will actually enter power save state or
not. This is needed so that PER domain does not enter retention / off while
core stays on and thus preventing I/O pad wakeups.
This also optimizes core context save and restore logic, it will skip
saving / restoring core context when this is requested but not needed.
I understand this being useful to save an extra save/restore but not
sure about the wakeup issue.
If CORE stays ON, then yes, IO pad will not be armed so IOpad wakeups
will not work. But module level wakeups should work fine. It seems
the bug is actually that module level wakeups are not properly
configured.
There were definitely problems in the PM branch with module level
wakeups. We now have fixes at least for GPIO and UART3 module level
wakeups which were found to be broken if CORE was left on.
This is easy enough to test/debug by forcing CORE to say on:
# echo 3 /debug/pm_debug/core_pwrdm/suspend
going into suspend and testing the various wakeup sources.
Kevin
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/cm.h |1 +
arch/arm/mach-omap2/pm34xx.c | 46
+-
2 files changed, 46 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cm.h b/arch/arm/mach-omap2/cm.h
index a2fcfcc..715ab14 100644
--- a/arch/arm/mach-omap2/cm.h
+++ b/arch/arm/mach-omap2/cm.h
@@ -76,6 +76,7 @@
#define OMAP3430ES2_CM_CLKEN20x0004
#define OMAP3430ES2_CM_FCLKEN3 0x0008
#define OMAP3430_CM_IDLEST_PLL CM_IDLEST2
+#define OMAP3430_CM_IDLEST3 0x0028
#define OMAP3430_CM_AUTOIDLE_PLL CM_AUTOIDLE2
#define OMAP3430ES2_CM_AUTOIDLE2_PLL CM_AUTOIDLE2
#define OMAP3430_CM_CLKSEL1 CM_CLKSEL
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 5e2ef63..e8704a6 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -64,6 +64,28 @@ u32 sleep_while_idle;
u32 wakeup_timer_seconds;
u32 voltage_off_while_idle;
+/* IDLEST bitmasks for core status checks */
+#define CORE_IDLEST1_ALL (\
+ OMAP3430ES2_ST_MMC3_MASK|OMAP3430_ST_ICR_MASK|\
+ OMAP3430_ST_AES2_MASK|OMAP3430_ST_SHA12_MASK|\
+ OMAP3430_ST_DES2_MASK|OMAP3430_ST_MMC2_MASK|\
+ OMAP3430_ST_MMC1_MASK|OMAP3430_ST_MSPRO_MASK|\
+ OMAP3430_ST_HDQ_MASK|OMAP3430_ST_MCSPI4_MASK|\
+ OMAP3430_ST_MCSPI3_MASK|OMAP3430_ST_MCSPI2_MASK|\
+ OMAP3430_ST_MCSPI1_MASK|OMAP3430_ST_I2C3_MASK|\
+ OMAP3430_ST_I2C2_MASK|OMAP3430_ST_I2C1_MASK|\
+ OMAP3430_ST_GPT11_MASK|OMAP3430_ST_GPT10_MASK|\
+ OMAP3430_ST_MCBSP5_MASK|OMAP3430_ST_MCBSP1_MASK|\
+ OMAP3430ES2_ST_HSOTGUSB_STDBY_MASK|\
+ OMAP3430ES2_ST_SSI_IDLE_MASK|OMAP3430_ST_SDMA_MASK|\
+ OMAP3430_ST_SSI_STDBY_MASK|OMAP3430_ST_D2D_MASK)
+#define CORE_IDLEST2_ALL (\
+ OMAP3430_ST_PKA_MASK|OMAP3430_ST_AES1_MASK|\
+ OMAP3430_ST_RNG_MASK|OMAP3430_ST_SHA11_MASK|\
+ OMAP3430_ST_DES1_MASK)
+#define CORE_IDLEST3_ALL (\
+ OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -408,6 +430,7 @@ void omap_sram_idle(void)
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
+ int core_saved_state = PWRDM_POWER_ON;
if (!_omap_sram_idle)
return;
@@ -439,9 +462,28 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ /*
+ * Check whether core will enter idle or not. This is needed
+ * because I/O pad wakeup will fail if core stays on and PER
+ * enters off. This will also prevent unnecessary core context
+ * save / restore.
+ */
+ core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+ if (core_next_state PWRDM_POWER_ON) {
+ core_saved_state = core_next_state;
+ if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) CORE_IDLEST1_ALL)
+ != CORE_IDLEST1_ALL ||
+ (cm_read_mod_reg(CORE_MOD, CM_IDLEST2) CORE_IDLEST2_ALL)
+ != CORE_IDLEST2_ALL ||
+ (cm_read_mod_reg(CORE_MOD, OMAP3430_CM_IDLEST3)
+ CORE_IDLEST3_ALL) != CORE_IDLEST3_ALL) {
+ core_next_state = PWRDM_POWER_ON;
+ pwrdm_set_next_pwrst(core_pwrdm,
Re: 24xx/n8x0 booting again, linux-omap updated to -rc5
Tony Lindgren wrote at 2009-10-15 20:27 -0500: Thanks to Paul's OMAP2xxx clock: set up clockdomain pointer in struct clk patch, we got 24xx booting again both in mainline and in linux-omap. That's excellent news! That is commit f856f168bcbc5f49253dd12a4d8452857a785f1c ? But I must be missing something somewhere... I have not yet been able to get the N810 to boot. I see only the Nokia splash. Note that I just want to see the framebuffer console at this point: I expect a panic due to no root fs. Attached is the config I'm using, which is based on n8x0_defconfig. I am using the arm-linux-gnueabi cross-compiler from emdebian, v4.2. What version is recommended, preferably available from emdebian (4.1, 4.2, 4.3, 4.4)? The following patch is also needed to change the n8x0 serial console CMDLINE from ttyS0 to ttyS2 as the port numbering now matches the physical ports. The patch is already in linux-omap, but not yet in mainline. If that is only for the serial console, I should need no console= option, right? I've tried it both ways... Thanks. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.32-rc4 # Tue Oct 20 11:25:03 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_TREE_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # # Kernel Performance Events And Counters # CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y # # GCOV-based kernel profiling # # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBDAF is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_FREEZER is not set # # System Type # CONFIG_MMU=y # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set # CONFIG_ARCH_ORION5X is not set # CONFIG_ARCH_MMP is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_W90X900 is not set #
Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
tero.kri...@nokia.com writes:
[...]
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO,
WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of
sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
Except omap_write* functions are deprecated.
I see, will use __raw_writel here then.
I'd rather see a call into the interrupt code. Something like
omap_intc_prepare_idle()
Can do these changes to add the interface yes. Though name would be
omap3_intc_prepare_idle() / ...resume_idle() as this is only needed for OMAP3.
OK.
Also, isn't this only needed if CORE != ON?
I understood from the problem description that this is needed always when we
are entering WFI, because we might have L3/L4 sleep/run transitions there
even if CORE is on.
OK.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: timekeeping: time should not stop during suspend
Jean Pihet jpi...@mvista.com writes:
Kevin,
On Friday 25 September 2009 01:35:48 Kevin Hilman wrote:
During suspend, the kernel timekeeping subsystem is shut down. Before
suspend and upon resume, it uses a weak function
read_persistent_clock() to determine the amount of time that elapsed
during suspend.
This function was not implemented on OMAP, so from the timekeeping
subsystem perspective (and thus userspace as well) it appeared that no
time elapsed during suspend.
This patch uses the 32k sync timer as a the persistent clock the 32k
sync timer value converted to seconds.
NOTE: This does *NOT* handle wrapping of the 32k sync timer, so
wrapping of the 32k sync timer during suspend may cause
problems. Also, there are not interrupts when the 32k sync
timer wraps, so something else has to be done.
I think we should read the 32k timer value before entering the sleep and
reading it again at resume time. Doing so up to one overflow could be
handled, which means a maximum sleep period of 36.4 hours.
Now the time wrap problem imposes the system to wake-up before 36.4 hours. We
have a few options:
1) always use the wake-up timer with a wake-up time 36.4 hours
2) rely on the user space to set the wake-up timer correctly, depending on
the
applications needs.
I am for option 1.
Any thoughts?
I agree with option 1.
Kevin
Reported-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
Tested on OMAP3 using PM branch.
If no issues, I will queue for 2.6.32-rc fixes
arch/arm/plat-omap/common.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index b3f70e6..3e4325b 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -178,6 +178,21 @@ unsigned long long sched_clock(void)
return ret;
}
+/**
+ * read_persistent_clock - Return time in seconds from the persistent
clock. + */
+unsigned long read_persistent_clock(void)
+{
+unsigned long long ret;
+cycle_t cycles;
+
+cycles = clocksource_32k.read(clocksource_32k);
+ret = (cycles * clocksource_32k.mult_orig) clocksource_32k.shift;
+do_div(ret, NSEC_PER_SEC);
+
+return (unsigned long)ret;
+}
+
static int __init omap_init_clocksource_32k(void)
{
static char err[] __initdata = KERN_ERR
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2
I've added a patch to split vmalloc.h into this series to allow different VMALLOC_END on omap1 and omap2. Regards, Tony From 72464dbae2749dd57bc2b3cd57d4fc6ba7abca37 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 19 Oct 2009 17:26:29 -0700 Subject: [PATCH] omap: Split vmalloc.h for mach-omap1 and mach-omap2 Earlier patch omap: Remap L3, L4 to get more kernel io address space changed the VMALLOC_END. However, this change causes problems on mach-omap1: BUG: mapping for 0xe000 at 0xe000 overlaps vmalloc space BUG: mapping for 0xe100 at 0xe100 overlaps vmalloc space Fix this by creating separate vmalloc.h files for mach-omap1 and mach-omap2. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/mach-omap1/include/mach/vmalloc.h similarity index 86% copy from arch/arm/plat-omap/include/mach/vmalloc.h copy to arch/arm/mach-omap1/include/mach/vmalloc.h index fc338a5..1b2af14 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/mach-omap1/include/mach/vmalloc.h @@ -1,5 +1,5 @@ /* - * arch/arm/plat-omap/include/mach/vmalloc.h + * arch/arm/mach-omap1/include/mach/vmalloc.h * * Copyright (C) 2000 Russell King. * @@ -17,8 +17,4 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_ARCH_OMAP1 #define VMALLOC_END(PAGE_OFFSET + 0x1800) -#else -#define VMALLOC_END(PAGE_OFFSET + 0x3800) -#endif diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/mach-omap2/include/mach/vmalloc.h similarity index 85% rename from arch/arm/plat-omap/include/mach/vmalloc.h rename to arch/arm/mach-omap2/include/mach/vmalloc.h index fc338a5..9ce9b6e 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/mach-omap2/include/mach/vmalloc.h @@ -17,8 +17,4 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_ARCH_OMAP1 -#define VMALLOC_END(PAGE_OFFSET + 0x1800) -#else -#define VMALLOC_END(PAGE_OFFSET + 0x3800) -#endif +#define VMALLOC_END (PAGE_OFFSET + 0x3800) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] omap: headers: Create headers necessary for compile under mach-omap1 and mach-omap2
Here's this one updated with the vmalloc.h split patch inserted into the series earlier. Regards, Tony From 3eff851b9dc1e84aa0822772e0be9afb0c973585 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 19 Oct 2009 17:32:58 -0700 Subject: [PATCH] omap: headers: Create headers necessary for compile under mach-omap1 and mach-omap2 Create the headers needed for compiling under mach-omap1/include/mach and mach-omap2/include/mach. This was done with the following script: #!/bin/bash mach_files=clkdev.h gpio.h hardware.h io.h irqs.h memory.h \ smp.h system.h timex.h uncompress.h vmalloc.h omaps=mach-omap1 mach-omap2 mach_dir_old=arch/arm/plat-omap/include/mach plat_dir_new=arch/arm/plat-omap/include/plat mkdir -p $plat_dir_new git add $plat_dir_new for dir in $omaps; do mach_dir_new=arch/arm/$dir/include/mach for header in $mach_files; do file=$mach_dir_new/$header if [ ! -f $file ]; then echo -ne /*\n * $file\n */\n\n#include plat/$header\n $file git add $file if [ ! -f $plat_dir_new/$header ]; then git mv $mach_dir_old/$header $plat_dir_new/$header fi fi done done Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap1/include/mach/clkdev.h b/arch/arm/mach-omap1/include/mach/clkdev.h new file mode 100644 index 000..ea8640e --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/clkdev.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/clkdev.h + */ + +#include plat/clkdev.h diff --git a/arch/arm/mach-omap1/include/mach/gpio.h b/arch/arm/mach-omap1/include/mach/gpio.h new file mode 100644 index 000..e737706 --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/gpio.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/gpio.h + */ + +#include plat/gpio.h diff --git a/arch/arm/mach-omap1/include/mach/hardware.h b/arch/arm/mach-omap1/include/mach/hardware.h new file mode 100644 index 000..a3f6287 --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/hardware.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/hardware.h + */ + +#include plat/hardware.h diff --git a/arch/arm/mach-omap1/include/mach/io.h b/arch/arm/mach-omap1/include/mach/io.h new file mode 100644 index 000..57bdf74 --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/io.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/io.h + */ + +#include plat/io.h diff --git a/arch/arm/mach-omap1/include/mach/irqs.h b/arch/arm/mach-omap1/include/mach/irqs.h new file mode 100644 index 000..9292fdc --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/irqs.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/irqs.h + */ + +#include plat/irqs.h diff --git a/arch/arm/mach-omap1/include/mach/memory.h b/arch/arm/mach-omap1/include/mach/memory.h new file mode 100644 index 000..e9b600c --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/memory.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/memory.h + */ + +#include plat/memory.h diff --git a/arch/arm/mach-omap1/include/mach/smp.h b/arch/arm/mach-omap1/include/mach/smp.h new file mode 100644 index 000..80a371c --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/smp.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/smp.h + */ + +#include plat/smp.h diff --git a/arch/arm/mach-omap1/include/mach/system.h b/arch/arm/mach-omap1/include/mach/system.h new file mode 100644 index 000..a6c1b3a --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/system.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/system.h + */ + +#include plat/system.h diff --git a/arch/arm/mach-omap1/include/mach/timex.h b/arch/arm/mach-omap1/include/mach/timex.h new file mode 100644 index 000..4793790 --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/timex.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/timex.h + */ + +#include plat/timex.h diff --git a/arch/arm/mach-omap1/include/mach/uncompress.h b/arch/arm/mach-omap1/include/mach/uncompress.h new file mode 100644 index 000..0ff22dc --- /dev/null +++ b/arch/arm/mach-omap1/include/mach/uncompress.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap1/include/mach/uncompress.h + */ + +#include plat/uncompress.h diff --git a/arch/arm/mach-omap2/include/mach/clkdev.h b/arch/arm/mach-omap2/include/mach/clkdev.h new file mode 100644 index 000..53b0274 --- /dev/null +++ b/arch/arm/mach-omap2/include/mach/clkdev.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap2/include/mach/clkdev.h + */ + +#include plat/clkdev.h diff --git a/arch/arm/mach-omap2/include/mach/gpio.h b/arch/arm/mach-omap2/include/mach/gpio.h new file mode 100644 index 000..be4d290 --- /dev/null +++ b/arch/arm/mach-omap2/include/mach/gpio.h @@ -0,0 +1,5 @@ +/* + * arch/arm/mach-omap2/include/mach/gpio.h + */ + +#include plat/gpio.h diff --git
Re: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use Constraint Framework
* Kevin Hilman khil...@deeprootsystems.com [091020 08:51]:
Sripathy, Vishwanath vishwanath...@ti.com writes:
Sysfs entry vdd_opp currently does not use constraint framework.
Because of this, even if you set the opp via this entry, it has no effect
since it can be overridden by on demand governor any time.
This patch has changes to make vdd_opp to use constraint framework.
vdd_lock variable has to be used when application wants to disable DVFS
altogether. This will override any other constraints and will lock the
OPP to given value.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
This raises an issue that I've been thinking about for awhile.
Basically, I'd like to drop all the /sys/power/vdd* options.
Since we can do the equivalent with CPUFreq using the userspace
governor, I don't see the point of having an additional interface.
Comments?
Total ack from me!
Tony
Kevin
---
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 13783f3..bcdc00d 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -47,6 +47,8 @@ static ssize_t idle_store(struct kobject *k, struct
kobj_attribute *,
static ssize_t vdd_opp_show(struct kobject *, struct kobj_attribute *,
char *);
static ssize_t vdd_opp_store(struct kobject *k, struct kobj_attribute *,
const char *buf, size_t n);
+static ssize_t vdd_opp_lock_store(struct kobject *k, struct kobj_attribute
*,
+ const char *buf, size_t n);
static struct kobj_attribute vdd1_opp_attr =
__ATTR(vdd1_opp, 0644, vdd_opp_show, vdd_opp_store);
@@ -103,6 +105,41 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
const char *buf, size_t n)
{
unsigned short value;
+ struct omap_opp *opp_table;
+
+ if (sscanf(buf, %hu, value) != 1)
+ return -EINVAL;
+
+ if (attr == vdd1_opp_attr) {
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ opp_table = omap_get_mpu_rate_table();
+ omap_pm_cpu_set_freq(sysfs_cpufreq_dev,
+ opp_table[value].rate);
+ } else if (attr == vdd2_opp_attr) {
+ if (value MIN_VDD2_OPP || (value MAX_VDD2_OPP)) {
+ printk(KERN_ERR vdd_opp_store: Invalid value\n);
+ return -EINVAL;
+ }
+ if (value == VDD2_OPP2)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 83*1000*4);
+ else if (value == VDD2_OPP3)
+ omap_pm_set_min_bus_tput(sysfs_cpufreq_dev,
+ OCP_INITIATOR_AGENT, 166*1000*4);
+
+ } else {
+ return -EINVAL;
+ }
+ return n;
+}
+
+static ssize_t vdd_opp_lock_store(struct kobject *kobj,
+ struct kobj_attribute *attr, const char *buf, size_t n)
+{
+ unsigned short value;
int flags = 0;
if (sscanf(buf, %hu, value) != 1)
@@ -121,6 +158,11 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
if (vdd1_locked == 0 value != 0) {
resource_lock_opp(VDD1_OPP);
vdd1_locked = 1;
+ if (value MIN_VDD1_OPP || value MAX_VDD1_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD1_OPP, value, flags);
}
} else if (attr == vdd2_lock_attr) {
flags = OPP_IGNORE_LOCK;
@@ -134,21 +176,12 @@ static ssize_t vdd_opp_store(struct kobject *kobj,
struct kobj_attribute *attr,
if (vdd2_locked == 0 value != 0) {
resource_lock_opp(VDD2_OPP);
vdd2_locked = 1;
+ if (value MIN_VDD2_OPP || value MAX_VDD2_OPP) {
+ printk(KERN_ERR vdd_opp_store: Invalid
value\n);
+ return -EINVAL;
+ }
+ resource_set_opp_level(VDD2_OPP, value, flags);
}
- }
-
- if (attr == vdd1_opp_attr) {
- if (value 1 || value 5) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD1_OPP, value, flags);
- } else if (attr == vdd2_opp_attr) {
- if (value 2 || value 3) {
- printk(KERN_ERR vdd_opp_store: Invalid value\n);
- return -EINVAL;
- }
- resource_set_opp_level(VDD2_OPP, value, flags);
} else {
RE: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2
Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, October 20, 2009 11:57 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2 I've added a patch to split vmalloc.h into this series to allow different VMALLOC_END on omap1 and omap2. Regards, Tony From 72464dbae2749dd57bc2b3cd57d4fc6ba7abca37 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 19 Oct 2009 17:26:29 -0700 Subject: [PATCH] omap: Split vmalloc.h for mach-omap1 and mach-omap2 Earlier patch omap: Remap L3, L4 to get more kernel io address space changed the VMALLOC_END. However, this change causes problems on mach-omap1: BUG: mapping for 0xe000 at 0xe000 overlaps vmalloc space BUG: mapping for 0xe100 at 0xe100 overlaps vmalloc space Fix this by creating separate vmalloc.h files for mach-omap1 and mach-omap2. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/mach-omap1/include/mach/vmalloc.h similarity index 86% copy from arch/arm/plat-omap/include/mach/vmalloc.h copy to arch/arm/mach-omap1/include/mach/vmalloc.h index fc338a5..1b2af14 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/mach-omap1/include/mach/vmalloc.h @@ -1,5 +1,5 @@ /* - * arch/arm/plat-omap/include/mach/vmalloc.h + * arch/arm/mach-omap1/include/mach/vmalloc.h I thought that keeping file paths was discouraged... Why not getting rid of it to avoid changing it every time? Regards, Sergio * * Copyright (C) 2000 Russell King. * @@ -17,8 +17,4 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_ARCH_OMAP1 #define VMALLOC_END (PAGE_OFFSET + 0x1800) -#else -#define VMALLOC_END (PAGE_OFFSET + 0x3800) -#endif diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/mach-omap2/include/mach/vmalloc.h similarity index 85% rename from arch/arm/plat-omap/include/mach/vmalloc.h rename to arch/arm/mach-omap2/include/mach/vmalloc.h index fc338a5..9ce9b6e 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/mach-omap2/include/mach/vmalloc.h @@ -17,8 +17,4 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_ARCH_OMAP1 -#define VMALLOC_END (PAGE_OFFSET + 0x1800) -#else -#define VMALLOC_END (PAGE_OFFSET + 0x3800) -#endif +#define VMALLOC_END(PAGE_OFFSET + 0x3800) -- To unsubscribe from this list: send the line unsubscribe 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 03/17] PM: Block CORE off when DSS is active
tero.kri...@nokia.com writes:
From: Kalle Jokiniemi kalle.jokini...@digia.com
If CORE power domain is allowed to reach off state
while display is active, the display will go blank.
Fixed by adding a check in idle loop.
What is root cause? I guess it is due to extra latency
required to wakeup from OFF?
In that case, it should be better to use the
omap_pm_set_max_dev_wakeup_lat() function and set a latency
constraint to the CORE.
I believe the root cause is that if core enters off while display is
doing something (between DSS data bursts for example), then when the
display next wakes up and tries to access memories, core has lost
its context which is rather bad. It is not really a wakeup latency
issue as such.
Still trying to fully understand...
So when the DSS wakes and tries to access memories, CORE should be
woken up from OFF but the context restore (done by MPU) will not have
happenend resulting in badness.
If that's the case, this really should be a constraint set by the DSS
driver. I'm not crazy about adding more special case handling in the
idle path.
While it's not technically a latency constraint we could use
omap_pm_set_max_mpu_wakeup_lat() in the DSS driver with a FIXME
comment to the effect that its not a latency constraint but rather a
prevent CORE context loss type of constraint.
Longer term, we'll need a new OMAP PM function for this. Something like
omap_pm_set_maximum_context_loss(struct device *initiator,
strict device *target,
u32 count);
Where count is 0 to prevent context loss and 1 to allow. In this case,
the initiator would be the dss device and the target would be a new
device used for L3. Comments?
Kevin
On the other hand, I remember a discussion between Kevin and
Tomi saying that this API might not be fully functional yet.
Regards,
Benoit
Signed-off-by: Kalle Jokiniemi ext-kalle.jokini...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index e8704a6..52a3f2b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -103,7 +103,7 @@ 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, *iva2_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm;
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -427,6 +427,7 @@ 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 dss_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
@@ -469,6 +470,7 @@ void omap_sram_idle(void)
* save / restore.
*/
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+ dss_state = pwrdm_read_pwrst(dss_pwrdm);
if (core_next_state PWRDM_POWER_ON) {
core_saved_state = core_next_state;
if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1)
CORE_IDLEST1_ALL)
@@ -479,6 +481,10 @@ void omap_sram_idle(void)
CORE_IDLEST3_ALL) !=
CORE_IDLEST3_ALL) {
core_next_state = PWRDM_POWER_ON;
pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_ON);
+ } else if (core_next_state == PWRDM_POWER_OFF
+ dss_state == PWRDM_POWER_ON) {
+ core_next_state = PWRDM_POWER_RET;
+ pwrdm_set_next_pwrst(core_pwrdm,
PWRDM_POWER_RET);
}
}
@@ -1234,6 +1240,7 @@ static int __init omap3_pm_init(void)
core_pwrdm = pwrdm_lookup(core_pwrdm);
cam_pwrdm = pwrdm_lookup(cam_pwrdm);
iva2_pwrdm = pwrdm_lookup(iva2_pwrdm);
+ dss_pwrdm = pwrdm_lookup(dss_pwrdm);
omap_push_sram_idle();
#ifdef CONFIG_SUSPEND
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe
linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/17] OMAP:PM: Precedence fix
Tero Kristo tero.kri...@nokia.com writes: From: Carlos Chinea carlos.chi...@nokia.com Signed-off-by: Carlos Chinea carlos.chi...@nokia.com Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com Patch looks good, but needs better subject and a changelog. Kevin --- arch/arm/mach-omap2/pm34xx.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index 4addc41..588ab79 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -225,8 +225,8 @@ static void omap3_core_save_context(void) control_padconf_off |= START_PADCONF_SAVE; omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF); /* wait for the save to complete */ - while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) - PADCONF_SAVE_DONE) + while (!(omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS) + PADCONF_SAVE_DONE)) ; /* Save the Interrupt controller context */ omap3_intc_save_context(); -- 1.5.4.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/17] OMAP2/3: GPTIMER: Clear pending interrupts when entering suspend
Tero Kristo tero.kri...@nokia.com writes: From: Tero Kristo tero.kri...@nokia.com OMAP GP timers keep running for a few cycles after they are stopped, which can cause the timer to expire and generate an interrupt. The pending interrupt will prevent OMAP from entering suspend, thus we ack it manually. Signed-off-by: Tero Kristo tero.kri...@nokia.com --- arch/arm/mach-omap2/timer-gp.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c index 9c056ff..c9d47bb 100644 --- a/arch/arm/mach-omap2/timer-gp.c +++ b/arch/arm/mach-omap2/timer-gp.c @@ -92,9 +92,21 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode, case CLOCK_EVT_MODE_ONESHOT: break; case CLOCK_EVT_MODE_UNUSED: - case CLOCK_EVT_MODE_SHUTDOWN: case CLOCK_EVT_MODE_RESUME: break; + case CLOCK_EVT_MODE_SHUTDOWN: + /* + * Wait for min period x 2 to make sure that timer is + * stopped + */ + udelay(evt-min_delta_ns / 500); + /* + * Clear possibly pending interrupt, this will occasionally + * generate spurious timer IRQs during suspend but this + * is okay, as another option is not to enter suspend at all + */ + omap_dm_timer_write_status(gptimer, OMAP_TIMER_INT_OVERFLOW); + break; Seems to me that this fix should just be done in omap_dm_timer_stop() since it could also result in extra interrupts in when using oneshot mode under dyntick. 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 11/17] Make USBHOST powerdomain go to sleep after warm reset.
Tero Kristo tero.kri...@nokia.com writes:
From: Peter De-Schrijver peter.de-schrij...@nokia.com
This patch makes sure the USBHOST and SGX powerdomains can go to any sleep
state after a warm reset.
Workaround looks ok, but the changelog should describe the cause of
problem. IOW, why weren't these domains transitioning after a warm
reset?
Kevin
Signed-off-by: Peter 'p2' De Schrijver peter.de-schrij...@nokia.com
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/cm-regbits-34xx.h |1 +
arch/arm/mach-omap2/pm34xx.c | 18 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..3152553 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -680,6 +680,7 @@
#define OMAP3430_CLKSEL_GPT2_SHIFT 0
/* CM_SLEEPDEP_PER specific bits */
+#define OMAP3430_CM_SLEEPDEP_PER_EN_MPU (1 1)
#define OMAP3430_CM_SLEEPDEP_PER_EN_IVA2 (1 2)
/* CM_CLKSTCTRL_PER */
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 47f5738..1fa778f 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/delay.h
#include mach/sram.h
#include mach/prcm.h
@@ -934,6 +935,24 @@ static void __init prcm_setup_regs(void)
prm_write_mod_reg(0, OMAP3430_CAM_MOD, PM_WKDEP);
prm_write_mod_reg(0, OMAP3430_PER_MOD, PM_WKDEP);
if (omap_rev() OMAP3430_REV_ES1_0) {
+
+ /*
+ * This workaround is needed to prevent SGX and USBHOST from
+ * failing to transition to RET/OFF after a warm reset in OFF
+ * mode. Workaround sets a sleepdep of each of these domains
+ * with MPU, waits for a min 2 sysclk cycles and clears the
+ * sleepdep.
+ */
+ cm_write_mod_reg(OMAP3430_CM_SLEEPDEP_PER_EN_MPU,
+ OMAP3430ES2_USBHOST_MOD, OMAP3430_CM_SLEEPDEP);
+ cm_write_mod_reg(OMAP3430_CM_SLEEPDEP_PER_EN_MPU,
+ OMAP3430ES2_SGX_MOD, OMAP3430_CM_SLEEPDEP);
+ udelay(100);
+ cm_write_mod_reg(0, OMAP3430ES2_USBHOST_MOD,
+ OMAP3430_CM_SLEEPDEP);
+ cm_write_mod_reg(0, OMAP3430ES2_SGX_MOD,
+ OMAP3430_CM_SLEEPDEP);
+
prm_write_mod_reg(0, OMAP3430ES2_SGX_MOD, PM_WKDEP);
prm_write_mod_reg(0, OMAP3430ES2_USBHOST_MOD, PM_WKDEP);
} else
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2
* Aguirre Rodriguez, Sergio Alberto saagui...@ti.com [091020 10:15]: Tony, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, October 20, 2009 11:57 AM To: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org Subject: [PATCH 3b/6] omap: Split vmalloc.h for mach-omap1 and mach-omap2 I've added a patch to split vmalloc.h into this series to allow different VMALLOC_END on omap1 and omap2. Regards, Tony From 72464dbae2749dd57bc2b3cd57d4fc6ba7abca37 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Mon, 19 Oct 2009 17:26:29 -0700 Subject: [PATCH] omap: Split vmalloc.h for mach-omap1 and mach-omap2 Earlier patch omap: Remap L3, L4 to get more kernel io address space changed the VMALLOC_END. However, this change causes problems on mach-omap1: BUG: mapping for 0xe000 at 0xe000 overlaps vmalloc space BUG: mapping for 0xe100 at 0xe100 overlaps vmalloc space Fix this by creating separate vmalloc.h files for mach-omap1 and mach-omap2. Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/mach-omap1/include/mach/vmalloc.h similarity index 86% copy from arch/arm/plat-omap/include/mach/vmalloc.h copy to arch/arm/mach-omap1/include/mach/vmalloc.h index fc338a5..1b2af14 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/mach-omap1/include/mach/vmalloc.h @@ -1,5 +1,5 @@ /* - * arch/arm/plat-omap/include/mach/vmalloc.h + * arch/arm/mach-omap1/include/mach/vmalloc.h I thought that keeping file paths was discouraged... Why not getting rid of it to avoid changing it every time? Well mostly to keep things consistent with existing files. If we want to, we can do a separate series to remove the paths for all the files later on. Regards, Tony Regards, Sergio * * Copyright (C) 2000 Russell King. * @@ -17,8 +17,4 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_ARCH_OMAP1 #define VMALLOC_END(PAGE_OFFSET + 0x1800) -#else -#define VMALLOC_END(PAGE_OFFSET + 0x3800) -#endif diff --git a/arch/arm/plat-omap/include/mach/vmalloc.h b/arch/arm/mach-omap2/include/mach/vmalloc.h similarity index 85% rename from arch/arm/plat-omap/include/mach/vmalloc.h rename to arch/arm/mach-omap2/include/mach/vmalloc.h index fc338a5..9ce9b6e 100644 --- a/arch/arm/plat-omap/include/mach/vmalloc.h +++ b/arch/arm/mach-omap2/include/mach/vmalloc.h @@ -17,8 +17,4 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#ifdef CONFIG_ARCH_OMAP1 -#define VMALLOC_END(PAGE_OFFSET + 0x1800) -#else -#define VMALLOC_END(PAGE_OFFSET + 0x3800) -#endif +#define VMALLOC_END (PAGE_OFFSET + 0x3800) -- To unsubscribe from this list: send the line unsubscribe 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 16/17] OMAP3: PM: Write voltage and clock setup times dynamically in idle loop
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
It is suggested by TI (SWPA152 February 2009) to write clksetup,
voltsetup_time1, voltsetup_time2, voltsetup2 dynamically in idle loop.
Can you summarize the reasons why?
Signed-off-by: Jouni Hogander jouni.hogan...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c | 36 +---
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index f492142..ae83121 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -575,6 +575,30 @@ void omap_sram_idle(void)
if (regset_save_on_suspend)
pm_dbg_regset_save(1);
+ /* Write voltage setup times which are changed dynamically */
AFAICT, we only set these values at init time and they are never
changed. Are there some forthcoming patches that change these
dynamically?
Kevin
+ if (core_next_state == PWRDM_POWER_OFF) {
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ } else {
+ prm_write_mod_reg((prm_setup.voltsetup_time2
+ OMAP3430_SETUP_TIME2_SHIFT) |
+ (prm_setup.voltsetup_time1
+ OMAP3430_SETUP_TIME1_SHIFT),
+ OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
+ prm_write_mod_reg(0, OMAP3430_GR_MOD,
+ OMAP3_PRM_VOLTSETUP2_OFFSET);
+ /*
+ * Use static 1 as only HF_CLKOUT is turned off.
+ * Value taken from application note SWPA152
+ */
+ prm_write_mod_reg(0x1, OMAP3430_GR_MOD,
+ OMAP3_PRM_CLKSETUP_OFFSET);
+ }
+
/*
* omap3_arm_context is the location where ARM registers
* get saved. The restore path then reads from this
@@ -1379,19 +1403,9 @@ static void __init configure_vc(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
- /* Write setup times */
- prm_write_mod_reg(prm_setup.clksetup, OMAP3430_GR_MOD,
- OMAP3_PRM_CLKSETUP_OFFSET);
- prm_write_mod_reg((prm_setup.voltsetup_time2
- OMAP3430_SETUP_TIME2_SHIFT) |
- (prm_setup.voltsetup_time1
- OMAP3430_SETUP_TIME1_SHIFT),
- OMAP3430_GR_MOD, OMAP3_PRM_VOLTSETUP1_OFFSET);
-
+ /* Write static setup times */
prm_write_mod_reg(prm_setup.voltoffset, OMAP3430_GR_MOD,
OMAP3_PRM_VOLTOFFSET_OFFSET);
- prm_write_mod_reg(prm_setup.voltsetup2, OMAP3430_GR_MOD,
- OMAP3_PRM_VOLTSETUP2_OFFSET);
pm_dbg_regset_init(1);
pm_dbg_regset_init(2);
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use ConstraintFramework
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, October 20, 2009 12:02 PM To: Kevin Hilman Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: Re: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use ConstraintFramework * Kevin Hilman khil...@deeprootsystems.com [091020 08:51]: Sripathy, Vishwanath vishwanath...@ti.com writes: Sysfs entry vdd_opp currently does not use constraint framework. Because of this, even if you set the opp via this entry, it has no effect since it can be overridden by on demand governor any time. This patch has changes to make vdd_opp to use constraint framework. vdd_lock variable has to be used when application wants to disable DVFS altogether. This will override any other constraints and will lock the OPP to given value. Since we can do the equivalent with CPUFreq using the userspace governor, I don't see the point of having an additional interface. Comments? Total ack from me! Only thing what I think of is, L3 rate. -Girish -- To unsubscribe from this list: send the line unsubscribe 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] ARM: OMAP: SDMA: Fix omap_stop_dma() API for channel linking
* Shilimkar, Santosh santosh.shilim...@ti.com [091019 23:29]:
Tony,
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, October 19, 2009 10:54 PM
To: Shilimkar, Santosh
Cc: linux-omap@vger.kernel.org; S, Venkatraman; Hari n; Jarkko
Nikula
Subject: Re: [PATCH v2] ARM: OMAP: SDMA: Fix omap_stop_dma() API for
channel linking
* Santosh Shilimkar santosh.shilim...@ti.com [091015 00:07]:
OMAP sDMA driver API omap_stop_dma() doesn't really stop the dma
when used
in linking scenario. This patch fixes the same.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Reviewed-By: Tony Lindgren t...@atomide.com
CC: Hari n hari.z...@gmail.com
CC: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/dma.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index fd3154a..1c933b4 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -987,6 +987,11 @@ void omap_stop_dma(int lch)
/* Mark the current channel */
dma_chan_link_map[cur_lch] = 1;
+ /* Disable the DMA channel */
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
disable_lnk(cur_lch);
next_lch = dma_chan[cur_lch].next_lch;
Hmm, I'm thinking it should be like this instead to also clear
the dma_chan[lch].flags instead of returning before that.
Can you try this with your testcase?
This works too. OMAP1 doesn't support channel linking so this is fine. In
case it was, then it would have been an issue.
OK, I've updated your original patch with these changes, and
will add it to omap-fixes.
Regards,
Tony
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 0eb676d..b53125f 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -978,6 +978,14 @@ void omap_stop_dma(int lch)
{
u32 l;
+ /* Disable all interrupts on the channel */
+ if (cpu_class_is_omap1())
+ dma_write(0, CICR(lch));
+
+ l = dma_read(CCR(lch));
+ l = ~OMAP_DMA_CCR_EN;
+ dma_write(l, CCR(lch));
+
if (!omap_dma_in_1510_mode() dma_chan[lch].next_lch != -1)
{
int next_lch, cur_lch = lch;
char dma_chan_link_map[OMAP_DMA4_LOGICAL_DMA_CH_COUNT];
@@ -995,18 +1003,8 @@ void omap_stop_dma(int lch)
next_lch = dma_chan[cur_lch].next_lch;
cur_lch = next_lch;
} while (next_lch != -1);
-
- return;
}
- /* Disable all interrupts on the channel */
- if (cpu_class_is_omap1())
- dma_write(0, CICR(lch));
-
- l = dma_read(CCR(lch));
- l = ~OMAP_DMA_CCR_EN;
- dma_write(l, CCR(lch));
-
dma_chan[lch].flags = ~OMAP_DMA_ACTIVE;
}
EXPORT_SYMBOL(omap_stop_dma);
--
To unsubscribe from this list: send the line unsubscribe 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 17/17] OMAP3: PM: Force disable OTG autoidle
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
OMAP3 sleep can be prevented in some cases where OTG autoidle is enabled.
This patch force disables autoidle during boot and after wakeup from off-mode.
See omap erratas 1.164 and 1.165.
The init-at-boot step isn't needed as this is already done in
PM branch (see usb-muxb.c:usb_musb_pm_init()).
Signed-off-by: Tero Kristo tero.kri...@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 ae83121..5f351f2 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -94,6 +94,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define OTG_SYSCONFIG(OMAP34XX_HSUSB_OTG_BASE + 0x404)
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -423,6 +425,16 @@ static void restore_table_entry(void)
restore_control_register(control_reg_value);
}
+static inline void disable_otg_autoidle(void)
+{
+ /*
+ * OTG autoidle can prevent core domain sleep in some cases, thus
+ * disable it. See omap erratas 1.164 and 1.165.
+ */
+ cm_set_mod_reg_bits(OMAP3430_EN_HSOTGUSB, CORE_MOD, CM_ICLKEN1);
Is the ICLK enable required as part of the fix too? I don't see
mention of enabling the iclk as part of the workaround for either of
these errata.
If the iclk needs to be enabled, it should be done at init using
the clk API.
+ omap_writel(0x0, OTG_SYSCONFIG);
omap_writel() deprecated.
+}
+
For readability, this should be a function in the USB core code
(either usb-musb.c or a static inline in mach/usb.h)
Kevin
void omap_sram_idle(void)
{
/* Variable to tell what needs to be saved and restored
@@ -628,6 +640,7 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ disable_otg_autoidle();
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
@@ -1417,6 +1430,7 @@ static int __init omap3_pm_early_init(void)
OMAP3_PRM_POLCTRL_OFFSET);
configure_vc();
+ disable_otg_autoidle();
return 0;
}
--
1.5.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC_CAP_SDIO_IRQ for omap 3430
It is still a work in progress because I have hacked the sdio_irq thread to poll all the time. I won't get a chance to do a proper fix for a couple of days at least. The main part of the fix was just turning on the cptl in the same place you turn on the cirq bit. Send me a reminder If you get no offers of testing help from anyone else and I'll try to use my beagle board and wifi card with a modern kernel. John On Mon, Oct 19, 2009 at 10:47 PM, Dirk Behme dirk.be...@googlemail.com wrote: John Rigby wrote: All, Sorry for the delay, I have been without internet access until just now. I added the cptl bit and I don't get continuous cirqs anymore. Right now I have a hacked driver that still does timed polling in sdio_irq.c and also wakes up on cirq. With this config the libertas works well. A flood ping of 1000 packets loses 2. Previously it was dropping about 30% of the packets from a flood ping. Great!! :) Without the polling in sdio_irq.c I get timeouts in libertas driver so I suspect that we may need to add checks of the DAT1 line in other places like the davinci driver does. As I said before, my kernel is a few months old so my issues may not be the same as current head of tree. Do you like to send your changes anyway? Just for reference... Thanks to all who helped on this. Now, the job will be to do this with recent kernel, make it stable and in the mid term get it applied. Anybody likes to help with this? Many thanks and best regards Dirk On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu -- *From:* John Rigby [mailto:jcri...@gmail.com] *Sent:* Sunday, October 18, 2009 7:24 PM *To:* Woodruff, Richard *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC_CAP_SDIO_IRQ for omap 3430
On Tue, Oct 20, 2009 at 11:45 AM, John Rigby jcri...@gmail.com wrote: It is still a work in progress because I have hacked the sdio_irq thread to poll all the time. I won't get a chance to do a proper fix for a couple of days at least. The main part of the fix was just turning on the cptl in the same place you turn on the cirq bit. Send me a reminder If you get no offers of testing help from anyone else and I'll try to use my beagle board and wifi card with a modern kernel. I'm happy to test on Overo. Steve John On Mon, Oct 19, 2009 at 10:47 PM, Dirk Behme dirk.be...@googlemail.com wrote: John Rigby wrote: All, Sorry for the delay, I have been without internet access until just now. I added the cptl bit and I don't get continuous cirqs anymore. Right now I have a hacked driver that still does timed polling in sdio_irq.c and also wakes up on cirq. With this config the libertas works well. A flood ping of 1000 packets loses 2. Previously it was dropping about 30% of the packets from a flood ping. Great!! :) Without the polling in sdio_irq.c I get timeouts in libertas driver so I suspect that we may need to add checks of the DAT1 line in other places like the davinci driver does. As I said before, my kernel is a few months old so my issues may not be the same as current head of tree. Do you like to send your changes anyway? Just for reference... Thanks to all who helped on this. Now, the job will be to do this with recent kernel, make it stable and in the mid term get it applied. Anybody likes to help with this? Many thanks and best regards Dirk On Mon, Oct 19, 2009 at 11:24 AM, Madhusudhan madhu...@ti.com wrote: Hi John, So does the SDIO card interrupt mode work fine now? Regards, Madhu -- *From:* John Rigby [mailto:jcri...@gmail.com] *Sent:* Sunday, October 18, 2009 7:24 PM *To:* Woodruff, Richard *Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman *Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 24xx/n8x0 booting again, linux-omap updated to -rc5
* green greenfreedo...@gmail.com [091020 09:31]: Tony Lindgren wrote at 2009-10-15 20:27 -0500: Thanks to Paul's OMAP2xxx clock: set up clockdomain pointer in struct clk patch, we got 24xx booting again both in mainline and in linux-omap. That's excellent news! That is commit f856f168bcbc5f49253dd12a4d8452857a785f1c ? Yeah, that's it. But I must be missing something somewhere... I have not yet been able to get the N810 to boot. I see only the Nokia splash. Note that I just want to see the framebuffer console at this point: I expect a panic due to no root fs. Attached is the config I'm using, which is based on n8x0_defconfig. Looks like your config ends up waiting for root on the mmc. But we're missing what was board-n800-mmc.c, so that needs to be updated for mainline. You can find the old code in the omap-2.6.30 branch under arch/arm/mach-omap2 if you have the cycles to update it. Also, the drivers/cbus needs to be updated to get the GPIO pins from board-*.c files, otherwise the retu watchdog will power down the system in 30 seconds. I am using the arm-linux-gnueabi cross-compiler from emdebian, v4.2. What version is recommended, preferably available from emdebian (4.1, 4.2, 4.3, 4.4)? Those should be just fine. The following patch is also needed to change the n8x0 serial console CMDLINE from ttyS0 to ttyS2 as the port numbering now matches the physical ports. The patch is already in linux-omap, but not yet in mainline. If that is only for the serial console, I should need no console= option, right? I've tried it both ways... Yeah, that's needed only for the serial console. 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 2/4] OMAP: Platform support for twl4030_codec MFD
* Peter Ujfalusi peter.ujfal...@nokia.com [091019 05:42]:
Add needed platform data for the twl4030_codec MFD on boards,
where the audio part of the twl4030 codec is used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
This looks safe to merge with the twl/audio patches to keep
them together. So not adding to my queue.
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c |9 +
arch/arm/mach-omap2/board-omap3beagle.c |9 +
arch/arm/mach-omap2/board-omap3evm.c |9 +
arch/arm/mach-omap2/board-omap3pandora.c |9 +
arch/arm/mach-omap2/board-overo.c|9 +
arch/arm/mach-omap2/board-zoom2.c|9 +
6 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index efaf053..4f91f7a 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -410,6 +410,14 @@ static struct regulator_init_data sdp3430_vpll2 = {
.consumer_supplies = sdp3430_vdvi_supply,
};
+static struct twl4030_codec_audio_data sdp3430_audio = {
+ .audio_mclk = 2600,
+};
+
+static struct twl4030_codec_data sdp3430_codec = {
+ .audio = sdp3430_audio,
+};
+
static struct twl4030_platform_data sdp3430_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -420,6 +428,7 @@ static struct twl4030_platform_data sdp3430_twldata = {
.madc = sdp3430_madc_data,
.keypad = sdp3430_kp_data,
.usb= sdp3430_usb_data,
+ .codec = sdp3430_codec,
.vaux1 = sdp3430_vaux1,
.vaux2 = sdp3430_vaux2,
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 70df6b4..2161d85 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -254,6 +254,14 @@ static struct twl4030_usb_data beagle_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
+static struct twl4030_codec_audio_data beagle_audio_data = {
+ .audio_mclk = 2600,
+};
+
+static struct twl4030_codec_data beagle_codec_data = {
+ .audio = beagle_audio_data,
+};
+
static struct twl4030_platform_data beagle_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -261,6 +269,7 @@ static struct twl4030_platform_data beagle_twldata = {
/* platform_data for children goes here */
.usb= beagle_usb_data,
.gpio = beagle_gpio_data,
+ .codec = beagle_codec_data,
.vmmc1 = beagle_vmmc1,
.vsim = beagle_vsim,
.vdac = beagle_vdac,
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index e4ec0c5..d9a6103 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -194,6 +194,14 @@ static struct twl4030_madc_platform_data
omap3evm_madc_data = {
.irq_line = 1,
};
+static struct twl4030_codec_audio_data omap3evm_audio_data = {
+ .audio_mclk = 2600,
+};
+
+static struct twl4030_codec_data omap3evm_codec_data = {
+ .audio = omap3evm_audio_data,
+};
+
static struct twl4030_platform_data omap3evm_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
@@ -203,6 +211,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
.madc = omap3evm_madc_data,
.usb= omap3evm_usb_data,
.gpio = omap3evm_gpio_data,
+ .codec = omap3evm_codec_data,
};
static struct i2c_board_info __initdata omap3evm_i2c_boardinfo[] = {
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 7f6bf87..5036b56 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -281,11 +281,20 @@ static struct twl4030_usb_data omap3pandora_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
+static struct twl4030_codec_audio_data omap3pandora_audio_data = {
+ .audio_mclk = 2600,
+};
+
+static struct twl4030_codec_data omap3pandora_codec_data = {
+ .audio = omap3pandora_audio_data,
+};
+
static struct twl4030_platform_data omap3pandora_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
.gpio = omap3pandora_gpio_data,
.usb= omap3pandora_usb_data,
+ .codec = omap3pandora_codec_data,
.vmmc1 = pandora_vmmc1,
.vmmc2 = pandora_vmmc2,
.keypad = pandora_kp_data,
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 9917d2f..dc55008
Re: [PATCH 06/17] OMAP3: PM: Added next state check for IVA2, USB and PER into idle loop
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
This is needed to prevent core from entering off mode if one of the IVA2,
USB or PER powerdomains are going to stay at least in retention state.
If this is not done, a powerdomain waking from RET may access core
domain which has just been reset.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
The problem I have with this one is simalar to patches 2 and 3.
It think all this state changing should be part of the CPUidle bus
master checking. If any of the conditions are met, then a different
C-state should be picked. With the current approach, the manual
prevention of CORE-off of will never be accounted for in CPUidle
stats.
Also, intead of all the manual checking of IDLEST bits, this should be
pushed into the powerdomain layer. Maybe we need a function like
pwrdm_is_idle() which can check the per-pwrdm IDLEST bits.
Then the BM check could simply call pwrdm_is_idle() on each of DSS,
IVA2, USB and PER for the C-states where CORE is going OFF. If any are
not idle, then a C-state with CORE=RET will be picked and the CPUidle
accounting will properly reflect the choice.
Kevin
---
arch/arm/mach-omap2/pm34xx.c | 36 +++-
1 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 588ab79..3e5ae14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -85,6 +85,13 @@ u32 voltage_off_while_idle;
OMAP3430_ST_DES1_MASK)
#define CORE_IDLEST3_ALL (\
OMAP3430ES2_ST_USBTLL_MASK|OMAP3430ES2_ST_CPEFUSE_MASK)
+#define PER_IDLEST_ALL (\
+ OMAP3430_ST_WDT3_MASK|OMAP3430_ST_MCBSP4_MASK|\
+ OMAP3430_ST_MCBSP3_MASK|OMAP3430_ST_MCBSP2_MASK|\
+ OMAP3430_ST_GPT9_MASK|OMAP3430_ST_GPT8_MASK|\
+ OMAP3430_ST_GPT7_MASK|OMAP3430_ST_GPT6_MASK|\
+ OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
+ OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
struct power_state {
struct powerdomain *pwrdm;
@@ -103,7 +110,7 @@ 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, *iva2_pwrdm, *dss_pwrdm;
+static struct powerdomain *cam_pwrdm, *iva2_pwrdm, *dss_pwrdm, *usb_pwrdm;
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -428,6 +435,8 @@ void omap_sram_idle(void)
int per_next_state = PWRDM_POWER_ON;
int core_next_state = PWRDM_POWER_ON;
int dss_state = PWRDM_POWER_ON;
+ int iva2_state = PWRDM_POWER_ON;
+ int usb_state = PWRDM_POWER_ON;
int core_prev_state, per_prev_state;
u32 sdrc_pwr = 0;
int per_state_modified = 0;
@@ -463,14 +472,28 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ /* Get powerdomain state data */
+ core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
+ dss_state = pwrdm_read_pwrst(dss_pwrdm);
+ iva2_state = pwrdm_read_pwrst(iva2_pwrdm);
+ usb_state = pwrdm_read_pwrst(usb_pwrdm);
+ per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
+
+ /* Check if PER domain can enter OFF or not */
+ if (per_next_state == PWRDM_POWER_OFF) {
+ if ((cm_read_mod_reg(OMAP3430_PER_MOD, CM_IDLEST)
+ PER_IDLEST_ALL) != PER_IDLEST_ALL) {
+ per_next_state = PWRDM_POWER_RET;
+ pwrdm_set_next_pwrst(per_pwrdm, per_next_state);
+ per_state_modified = 1;
+ }
+ }
/*
* Check whether core will enter idle or not. This is needed
* because I/O pad wakeup will fail if core stays on and PER
* enters off. This will also prevent unnecessary core context
* save / restore.
*/
- core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
- dss_state = pwrdm_read_pwrst(dss_pwrdm);
if (core_next_state PWRDM_POWER_ON) {
core_saved_state = core_next_state;
if ((cm_read_mod_reg(CORE_MOD, CM_IDLEST1) CORE_IDLEST1_ALL)
@@ -482,14 +505,16 @@ void omap_sram_idle(void)
core_next_state = PWRDM_POWER_ON;
pwrdm_set_next_pwrst(core_pwrdm, PWRDM_POWER_ON);
} else if (core_next_state == PWRDM_POWER_OFF
- dss_state == PWRDM_POWER_ON) {
+ (dss_state == PWRDM_POWER_ON ||
+ iva2_state = PWRDM_POWER_RET ||
+ usb_state = PWRDM_POWER_RET ||
+ per_next_state = PWRDM_POWER_RET)) {
core_next_state =
[APPLIED] [PATCH 1/1] omap iommu: fix wrong condition check for SUPERSECTION
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: omap-fixes Initial commit ID (Likely to change): 49086e551006a9fe84667edbc867cdf80095787e PatchWorks http://patchwork.kernel.org/patch/53067/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=49086e551006a9fe84667edbc867cdf80095787e -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHV2] OMAP3: PM: Removing redundant and potentially dangerous PRCM configration
Sripathy, Vishwanath vishwanath...@ti.com writes:
As part of Core domain context restoration while coming out of off mode
there are some registers being restored which are not required to be restored.
ROM code should have restored them already.
Saying should have restored is not very convincing. :)
I'm hoping that you mean ROM code *has* restored them already. In
which case, the changelog should read something like
...not required to be restored because ROM code will have already
restored them.
Overwriting some of them can have potential side effect. Eg:
CM_CLKEN_PLL register should not be written while dpll is locked.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
While updating the changelog, can you report how OFF-mode was tested
(suspend, off-while-idle, etc.) and on which platforms.
Otherwise, patch looks fine.
Thanks,
Kevin
---
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index fb864cc..88182a8 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,7 +43,6 @@ struct omap3_prcm_regs {
u32 iva2_cm_clksel2;
u32 cm_sysconfig;
u32 sgx_cm_clksel;
- u32 wkup_cm_clksel;
u32 dss_cm_clksel;
u32 cam_cm_clksel;
u32 per_cm_clksel;
@@ -52,7 +51,6 @@ struct omap3_prcm_regs {
u32 pll_cm_autoidle2;
u32 pll_cm_clksel4;
u32 pll_cm_clksel5;
- u32 pll_cm_clken;
u32 pll_cm_clken2;
u32 cm_polctrl;
u32 iva2_cm_fclken;
@@ -76,7 +74,6 @@ struct omap3_prcm_regs {
u32 usbhost_cm_iclken;
u32 iva2_cm_autiidle2;
u32 mpu_cm_autoidle2;
- u32 pll_cm_autoidle;
u32 iva2_cm_clkstctrl;
u32 mpu_cm_clkstctrl;
u32 core_cm_clkstctrl;
@@ -279,7 +276,6 @@ void omap3_prcm_save_context(void)
prcm_context.cm_sysconfig = __raw_readl(OMAP3430_CM_SYSCONFIG);
prcm_context.sgx_cm_clksel =
cm_read_mod_reg(OMAP3430ES2_SGX_MOD, CM_CLKSEL);
- prcm_context.wkup_cm_clksel = cm_read_mod_reg(WKUP_MOD, CM_CLKSEL);
prcm_context.dss_cm_clksel =
cm_read_mod_reg(OMAP3430_DSS_MOD, CM_CLKSEL);
prcm_context.cam_cm_clksel =
@@ -296,8 +292,6 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL4);
prcm_context.pll_cm_clksel5 =
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKSEL5);
- prcm_context.pll_cm_clken =
- cm_read_mod_reg(PLL_MOD, CM_CLKEN);
prcm_context.pll_cm_clken2 =
cm_read_mod_reg(PLL_MOD, OMAP3430ES2_CM_CLKEN2);
prcm_context.cm_polctrl = __raw_readl(OMAP3430_CM_POLCTRL);
@@ -343,8 +337,6 @@ void omap3_prcm_save_context(void)
cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_AUTOIDLE2);
prcm_context.mpu_cm_autoidle2 =
cm_read_mod_reg(MPU_MOD, CM_AUTOIDLE2);
- prcm_context.pll_cm_autoidle =
- cm_read_mod_reg(PLL_MOD, CM_AUTOIDLE);
prcm_context.iva2_cm_clkstctrl =
cm_read_mod_reg(OMAP3430_IVA2_MOD, CM_CLKSTCTRL);
prcm_context.mpu_cm_clkstctrl =
@@ -436,7 +428,6 @@ void omap3_prcm_restore_context(void)
__raw_writel(prcm_context.cm_sysconfig, OMAP3430_CM_SYSCONFIG);
cm_write_mod_reg(prcm_context.sgx_cm_clksel, OMAP3430ES2_SGX_MOD,
CM_CLKSEL);
- cm_write_mod_reg(prcm_context.wkup_cm_clksel, WKUP_MOD, CM_CLKSEL);
cm_write_mod_reg(prcm_context.dss_cm_clksel, OMAP3430_DSS_MOD,
CM_CLKSEL);
cm_write_mod_reg(prcm_context.cam_cm_clksel, OMAP3430_CAM_MOD,
@@ -453,7 +444,6 @@ void omap3_prcm_restore_context(void)
OMAP3430ES2_CM_CLKSEL4);
cm_write_mod_reg(prcm_context.pll_cm_clksel5, PLL_MOD,
OMAP3430ES2_CM_CLKSEL5);
- cm_write_mod_reg(prcm_context.pll_cm_clken, PLL_MOD, CM_CLKEN);
cm_write_mod_reg(prcm_context.pll_cm_clken2, PLL_MOD,
OMAP3430ES2_CM_CLKEN2);
__raw_writel(prcm_context.cm_polctrl, OMAP3430_CM_POLCTRL);
@@ -492,7 +482,6 @@ void omap3_prcm_restore_context(void)
cm_write_mod_reg(prcm_context.iva2_cm_autiidle2, OMAP3430_IVA2_MOD,
CM_AUTOIDLE2);
cm_write_mod_reg(prcm_context.mpu_cm_autoidle2, MPU_MOD, CM_AUTOIDLE2);
- cm_write_mod_reg(prcm_context.pll_cm_autoidle, PLL_MOD, CM_AUTOIDLE);
cm_write_mod_reg(prcm_context.iva2_cm_clkstctrl, OMAP3430_IVA2_MOD,
CM_CLKSTCTRL);
cm_write_mod_reg(prcm_context.mpu_cm_clkstctrl, MPU_MOD, CM_CLKSTCTRL);
--
To unsubscribe from this list: send the line unsubscribe 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 v2] OMAP3:clk - introduce DPLL4 jtype support
From: Richard Woodruff r-woodru...@ti.com
**---
V2 - patch with comments from Sergio cleanups in general
+ static used instead of a global function
V1 - original patch
**---
DPLL4 for 3630 introduces a changed block requiring
special divisor bits and additional reg fields
To allow for silicons to use this, this is introduced
as a omap3_has_jtype_dpll4() and is enabled for 3630
silicon
Tested with SDP3430, SDP3630
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Sonasath, Moiz Sonasath m-sonas...@ti.com
Cc: Sergio Alberto Aguirre Rodriguez saagui...@ti.com
Signed-off-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/clock34xx.c | 46 ++-
arch/arm/mach-omap2/cm-regbits-34xx.h |6 +++-
arch/arm/mach-omap2/id.c|3 ++
arch/arm/plat-omap/include/plat/clock.h |3 ++
arch/arm/plat-omap/include/plat/cpu.h |2 +
5 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index c258f87..2ebddb7 100644
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -675,6 +675,41 @@ static void omap3_noncore_dpll_disable(struct clk *clk)
_omap3_noncore_dpll_stop(clk);
}
+/**
+ * lookup_dco_sddiv - Set j-type DPLL4 compensation variables
+ * @clk: pointer to a DPLL struct clk
+ * @dco: digital control oscillator selector
+ * @sd_div: target sigma-delta divider
+ * @m: DPLL multiplier to set
+ * @n: DPLL divider to set
+ */
+static void lookup_dco_sddiv(struct clk *clk, u8 *dco, u8 *sd_div, u16 m, u8 n)
+{
+ unsigned long fint, clkinp, sd; /* watch out for overflow */
+ int mod1, mod2;
+
+ n++; /* always n+1 below */
+ clkinp = clk-parent-rate;
+ fint = (clkinp / n) * m;
+
+ if (fint 10)
+ *dco = 2;
+ else
+ *dco = 4;
+ /*
+* target sigma-delta to near 250MHz
+* sd = ceil[(m/(n+1)) * (clkinp_MHz / 250)]
+*/
+ clkinp /= 10; /* shift from MHz to 10*Hz for 38.4 and 19.2*/
+ mod1 = (clkinp * m) % (250 * n);
+ sd = (clkinp * m) / (250 * n);
+ mod2 = sd % 10;
+ sd /= 10;
+
+ if (mod1 + mod2)
+ sd++;
+ *sd_div = sd;
+}
/* Non-CORE DPLL rate set code */
@@ -707,6 +742,13 @@ static int omap3_noncore_dpll_program(struct clk *clk, u16
m, u8 n, u16 freqsel)
v = ~(dd-mult_mask | dd-div1_mask);
v |= m __ffs(dd-mult_mask);
v |= (n - 1) __ffs(dd-div1_mask);
+ if (dd-jtype) {
+ u8 dco, sd_div;
+ lookup_dco_sddiv(clk, dco, sd_div, m, n);
+ v = ~(dd-dco_sel_mask | dd-sd_div_mask);
+ v |= dco __ffs(dd-dco_sel_mask);
+ v |= sd_div __ffs(dd-sd_div_mask);
+ }
__raw_writel(v, dd-mult_div1_reg);
/* We let the clock framework set the other output dividers later */
@@ -1022,7 +1064,7 @@ static unsigned long omap3_clkoutx2_recalc(struct clk
*clk)
v = __raw_readl(dd-control_reg) dd-enable_mask;
v = __ffs(dd-enable_mask);
- if (v != OMAP3XXX_EN_DPLL_LOCKED)
+ if (v != OMAP3XXX_EN_DPLL_LOCKED (!dd-jtype))
rate = clk-parent-rate;
else
rate = clk-parent-rate * 2;
@@ -1135,6 +1177,8 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (omap3_has_jtype_dpll4())
+ dpll4_ck.dpll_data-jtype = 1;
}
clk_init(omap2_clk_functions);
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index 6923deb..6f2802b 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -516,9 +516,13 @@
/* CM_CLKSEL2_PLL */
#define OMAP3430_PERIPH_DPLL_MULT_SHIFT8
-#define OMAP3430_PERIPH_DPLL_MULT_MASK (0x7ff 8)
+#define OMAP3430_PERIPH_DPLL_MULT_MASK (0xfff 8)
#define OMAP3430_PERIPH_DPLL_DIV_SHIFT 0
#define OMAP3430_PERIPH_DPLL_DIV_MASK (0x7f 0)
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_SHIFT 21
+#define OMAP3630_PERIPH_DPLL_DCO_SEL_MASK (0x7 21)
+#define OMAP3630_PERIPH_DPLL_SD_DIV_SHIFT 24
+#define OMAP3630_PERIPH_DPLL_SD_DIV_MASK (0xff 24)
/* CM_CLKSEL3_PLL */
#define OMAP3430_DIV_96M_SHIFT 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 702d3b4..9cc 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -176,6 +176,8 @@ void __init omap3_check_features(void)
OMAP3_CHECK_FEATURE(status, NEON);
OMAP3_CHECK_FEATURE(status, ISP);
+ if (cpu_is_omap3630())
+ omap3_features |=
Re: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
On Fri, Oct 09, 2009 at 06:46:23PM -0400, Tony Lindgren wrote:
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap2-upstream
Initial commit ID (Likely to change): 439d2c69335a28ffdb5a9795ff384b6755ca0f7f
PatchWorks
http://patchwork.kernel.org/patch/52477/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=439d2c69335a28ffdb5a9795ff384b6755ca0f7f
This patch broke all OMAP1 boards. NULL terminator entry for omap1
serial_platform_data cannot be removed just because serial driver uses
is as last entry marker. Without it we end this way:
Unable to handle kernel NULL pointer dereference at virtual address 0028
pgd = c0004000
[0028] *pgd=
Internal error: Oops: 8005 [#1]
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12)
PC is at 0x28
LR is at serial8250_config_port+0x184/0xc34
(...etc...)
Please consider following fix (and while there fix OMAP2 too as patch broke
it as well (untested))
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 9c59332..0392ff5 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -86,7 +86,9 @@ static struct plat_serial8250_port serial_platform_data[] = {
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk= OMAP16XX_BASE_BAUD * 16,
- },
+ }, {
+ }
+
};
static struct platform_device serial_device = {
@@ -119,7 +121,7 @@ void __init omap_serial_init(void)
serial_platform_data[2].uartclk = OMAP1510_BASE_BAUD * 16;
}
- for (i = 0; i ARRAY_SIZE(serial_platform_data); i++) {
+ for (i = 0; i ARRAY_SIZE(serial_platform_data) - 1; i++) {
unsigned char reg;
/* Static mapping, never released */
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index dabc089..ca69ffa 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -585,7 +585,7 @@ void __init omap_serial_early_init(void)
* if not needed.
*/
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -637,7 +637,7 @@ void __init omap_serial_init(void)
{
int i;
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mmap /dev/mem in python
I'm trying to mmap /dev/mem in python to access various registers on a gumstix overo (with an omap 3530 processor). Here is the code I'm using (as a minimal example): import os, mmap MAP_MASK = mmap.PAGESIZE - 1 addr = (see below) f = os.open(/dev/mem, os.O_RDWR | os.O_SYNC) m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE | mmap.PROT_READ, offset=addr ~MAP_MASK) m.seek(addr MAP_MASK) c = m.read_byte() print c m.close() os.close(f) If I use: addr = 0x48002178 everything works swimmingly. However, if I use: addr = 0x48088024 (or all the addresses I've tried 0x48044000) I get the following error Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024 Bus error and python crashes. I'm basing the mmap flags and options off of devmem2.c. If I remove the O_SYNC flag from the os.open command, I can read and write to registers fine, but randomly I will get the Unhandled fault error and things will not work correctly. Am I using the right command to write to the omap registers? should I be using the O_SYNC flag? Any ideas where these errors are coming from? Thanks in advance for your help. -- To unsubscribe from this list: send the line unsubscribe 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: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
* ladislav.mi...@seznam.cz ladislav.mi...@seznam.cz [091020 14:53]:
On Fri, Oct 09, 2009 at 06:46:23PM -0400, Tony Lindgren wrote:
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap2-upstream
Initial commit ID (Likely to change):
439d2c69335a28ffdb5a9795ff384b6755ca0f7f
PatchWorks
http://patchwork.kernel.org/patch/52477/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=439d2c69335a28ffdb5a9795ff384b6755ca0f7f
This patch broke all OMAP1 boards. NULL terminator entry for omap1
serial_platform_data cannot be removed just because serial driver uses
is as last entry marker. Without it we end this way:
Unable to handle kernel NULL pointer dereference at virtual address 0028
pgd = c0004000
[0028] *pgd=
Internal error: Oops: 8005 [#1]
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12)
PC is at 0x28
LR is at serial8250_config_port+0x184/0xc34
(...etc...)
Please consider following fix (and while there fix OMAP2 too as patch broke
it as well (untested))
Thanks, I already refreshed the original patch with the same fix few
days ago :) It should be there in for-next branch and master branch.
Tony
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 9c59332..0392ff5 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -86,7 +86,9 @@ static struct plat_serial8250_port serial_platform_data[] =
{
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk= OMAP16XX_BASE_BAUD * 16,
- },
+ }, {
+ }
+
};
static struct platform_device serial_device = {
@@ -119,7 +121,7 @@ void __init omap_serial_init(void)
serial_platform_data[2].uartclk = OMAP1510_BASE_BAUD * 16;
}
- for (i = 0; i ARRAY_SIZE(serial_platform_data); i++) {
+ for (i = 0; i ARRAY_SIZE(serial_platform_data) - 1; i++) {
unsigned char reg;
/* Static mapping, never released */
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index dabc089..ca69ffa 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -585,7 +585,7 @@ void __init omap_serial_early_init(void)
* if not needed.
*/
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -637,7 +637,7 @@ void __init omap_serial_init(void)
{
int i;
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
--
To unsubscribe from this list: send the line unsubscribe 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: mmap /dev/mem in python
* Brett Graham gra...@rowland.harvard.edu [091020 15:06]: I'm trying to mmap /dev/mem in python to access various registers on a gumstix overo (with an omap 3530 processor). Here is the code I'm using (as a minimal example): import os, mmap MAP_MASK = mmap.PAGESIZE - 1 addr = (see below) f = os.open(/dev/mem, os.O_RDWR | os.O_SYNC) m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE | mmap.PROT_READ, offset=addr ~MAP_MASK) m.seek(addr MAP_MASK) c = m.read_byte() print c m.close() os.close(f) If I use: addr = 0x48002178 everything works swimmingly. However, if I use: addr = 0x48088024 (or all the addresses I've tried 0x48044000) I get the following error Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024 Bus error and python crashes. I'm basing the mmap flags and options off of devmem2.c. If I remove the O_SYNC flag from the os.open command, I can read and write to registers fine, but randomly I will get the Unhandled fault error and things will not work correctly. Am I using the right command to write to the omap registers? should I be using the O_SYNC flag? Any ideas where these errors are coming from? Sounds like you need to enable ick and fck for the device you're trying to read. 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
[ANNOUNCE] updated dspbridge on linux-omap
Hi All, I would like to announce that l-o dspbridge branch was mirrored by Tony from DSP Bridge repository at dev.omapzoom.org, this branch was rebased on top of 2.6.32-rc4. As of now, it is missing some of the latest patches sent to the mailing list but I'm hoping to include them soon. Also, DVFS Bridge feature won't compile if rebasing onto PM branch because it is missing clk notifier functions. As usual, thanks to all who keep contributing. omar --- Ameya Palande (16): DSPBRIDGE: Logical code cleanup in bridge_open() DSPBRIDGE: Fix module build warnings DSPBRIDGE: Removal of unreachable code DSPBRIDGE: Use GT_trace for CLk_Disable message DSPBRIDGE: Compiler wanrning fix for unlocked_ioctl DSPBRIDGE: Buffer size warning fixes DSPBRIDGE: avoid to dump unnecessary registers without debug DSPBRIDGE: Prevent memory access during hibernation DSPBRIDGE: fix incorrect mask of DPLL in CHNLSM_InterruptDSP2() DSPBRIDGE: Cleanup SleepDSP DSPBRIDGE: Set VDD1 OPP1 while MPU initiated OFF mode DSPBRIDGE: Pass filp-private to all the ioctl wrappers DSPBRIDGE: Define pr_ctxt as a parameter in low level functions DSPBRIDGE: Remove old resource cleanup implementation DSPBRIDGE: Set VDD1 OPP1 unconditionally while moving to off mode DSPBRIDGE: Maintain VDD1 at OPP3 while DSP is active Armando Uribe de Leon (1): BRIDGE: Number of supported OPPs increased to 5 Axel Haslam (1): BRIDGE: tiomap unmap fix Doyu Hiroshi (Nokia-D/Helsinki (1): DSPBRIDGE: convert ioctl to unlocked_ioctl Doyu Hiroshi (Nokia-D/Helsinki) (1): DSPBRIDGE: fix macros that break when inside an if/else Ernesto Ramos Falcon (2): DSPBRIDGE: Delete list implementation for resource cleanup DSPBRIDGE: Memory leak in Node Register Notify Felipe Contreras (18): tidspbridge: remove revision history tidspbridge: trivial cleanup tidspbridge: remove unused stuff tidspbridge: remove IO_CALLDPC tidspbridge: whitespace cleanups tidspbridge: trivial cleanups tidspbridge: hDevContext == pDevContext tidspbridge: remove UTIL_Wait wrapper tidspbridge: cleanup and remove HW_MBOX_IsFull tidspbridge: remove udelay and use time_after instead tidspbridge: Remove IO_InterruptDSP tidspbridge: remove IO_InterruptDSP2 tidspbridge: remove CHNLSM_InterruptDSP tidspbridge: remove wIntrVal2Dsp tidspbridge: print an error when timing out tidspbridge: don't flood the mailbox on MemUnMap tidspbridge: cleanup and remove HW_MMU_TLBFlushAll tidspbridge: decreate timeout to a saner value Fernando Guzman Lugo (20): BRIDGE: Remove sparse warnings from wcd BRIDGE: Module ISR removed BRIDGE: PRCS wrappers removal BRIDGE: Chnl module cleanup BRIDGE: Sparse warnings cleanup DSPBRIDGE: Free resources when user fails to do so DSPBRIDGE Fix for DCD stack overflow DSPBRIDGE: Removed CSL wrapper functions DSPBRIDGE: Fixed race condition with DBLL target list BRIDGE: Change GFP_ATOMIC to GFP_KERNEL DSPBRIDGE: base image reload suppor after DSP error DSPBRIDGE: slab corruption in resource cleanup fix DSPBRIDGE: Allow separate load/run addresses for Dynamic Loader DSPBRIDGE: Reset MMU and DSP on board stop DSPBRIDGE: Implemented Trampoline support for dynamic loader DSPBRIDGE: Enable/Disable MCBSP_CLOCKS for MCBSP2 DSPBRIDGE: Remove process context list DSPBRIDGE: Fix BUG scheduling while atomic DSPBRIDGE: support loading 4 dependent DLL DSPBRIDGE: check pointer before calling Proc_Detach Guzman Lugo Fernando (4): DSPBRIDGE: Remove SEEK_* redefinitions DSPBRIDGE: Removes wrappers funtions of readl and writel DSPBRIDGE: Change address resources to void __iomem * DSPBRIDGE: Remove variables not used in cfgdefs.h Hari Kanigeri (15): DSPBRIDGE: Replacing custom mapping implementation BRIDGE Add preemption support to unprotected functions BRIDGE Resource cleanup node delete fix BRIDGE Memory leak fix BRIDGE Handle Node messaging when DSP crashed DSPBRIDGE: Mapping sidetone registers DSPBRIDGE DSP getProcessor fixed DSPBRIDGE Memory flush function fix DSPBRIDGE: Add DSP_MMU_DEBUG DSPBRIDGE: Handle Node operations when DSP is in error state DSPBRIDGE: Memory lock for DMM DSPBRIDGE: Remove run_IdleBoot support DSPBRIDGE: Handle properly user space pointers DSPBRIDGE: Keep DMM resources for other nodes on PROC_Detach DSPBRIDGE: Increased DMM size to 256MB Hiroshi DOYU (30): BRIDGE: Header files BRIDGE: Doff image dynamic loader BRIDGE: Generic Utilities BRIDGE: Hardware Interfaces BRIDGE: Platform Manager BRIDGE: Resource Manager BRIDGE: Services BRIDGE: Mini driver BRIDGE: README BRIDGE: Fix header path BRIDGE: Sync omapzoom bridge patches BRIDGE: set 0 for phys_mempool_* as default BRIDGE: Rename header file location BRIDGE: Fix header path name to arch/arm/plat-omap/include/dspbridge BRIDGE: Add 'dspbridge' dirname in header file inclusion BRIDGE: Fix incorrect pathname BRIDGE: Remove paths in header
[PATCH v2 2/2] omap: 3630: update is_chip variable
3630 is getting treated like next rev of 3430
omap_chip.oc variable has to be updated for 3630 version
Provide space for 3430 future ES rev (bit7 to bit9)
Otherwise the Core power domain is not getting registered.
This gets used in the registration of power domains in:
arch/arm/mach-omap2/powerdomains34xx.h
core_34xx_es3_1_pwrdm
OMAP_CHIP_INIT(CHIP_GE_OMAP3430ES3_1)
Core power doman will get registered for 3630 only when .oc is pouplated
correctly.
Tested on Zoom3(3630) board
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Menon, Nishanth n...@ti.com
---
arch/arm/mach-omap2/id.c |2 ++
arch/arm/plat-omap/include/plat/cpu.h |8 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 1c15112..189cf7a 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -359,6 +359,8 @@ void __init omap2_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
else if (omap_rev() == OMAP3430_REV_ES3_1)
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ else if (omap_rev() == OMAP3630_REV_ES1_0)
+ omap_chip.oc |= CHIP_IS_OMAP3630ES1;
} else {
pr_err(Uninitialized omap_chip, please fix!\n);
}
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 922bf1c..5c95e4b 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -454,6 +454,8 @@ IS_OMAP_TYPE(3430, 0x3430)
#define CHIP_IS_OMAP3430ES2(1 4)
#define CHIP_IS_OMAP3430ES3_0 (1 5)
#define CHIP_IS_OMAP3430ES3_1 (1 6)
+/* Space for future revisions of 3430: bit7 to bit9 */
+#define CHIP_IS_OMAP3630ES1(1 10)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
@@ -465,8 +467,10 @@ IS_OMAP_TYPE(3430, 0x3430)
*/
#define CHIP_GE_OMAP3430ES2(CHIP_IS_OMAP3430ES2 | \
CHIP_IS_OMAP3430ES3_0 | \
-CHIP_IS_OMAP3430ES3_1)
-#define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1)
+CHIP_IS_OMAP3430ES3_1 | \
+CHIP_IS_OMAP3630ES1)
+#define CHIP_GE_OMAP3430ES3_1 (CHIP_IS_OMAP3430ES3_1 | \
+CHIP_IS_OMAP3630ES1)
int omap_chip_is(struct omap_chip_id oci);
--
1.6.5.rc1.19.g8426
--
To unsubscribe from this list: send the line unsubscribe 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: MMC_CAP_SDIO_IRQ for omap 3430
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MMC_CAP_SDIO_IRQ for omap 3430
In enable_sdio_irq if enable set ctpl else clear ctpl Again my version is halt baked. I was just happy that enabling ctpl prevents the infinitie cirq issue. On Tue, Oct 20, 2009 at 4:47 PM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Monday, October 19, 2009 1:17 PM To: linux-omap@vger.kernel.org Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux- m...@vger.kernel.org; 'Steve Sakoman' Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Madhusudhan wrote: Hi John, So does the SDIO card interrupt mode work fine now? (wrong attachment in previous mail :( sorry) If somebody likes to test, my updated patch v2 in attachment. Compile tested only, testing and comments are welcome. Can you inline the v2 patch please? It helps review. I wonder in the version that John tested was the CTPL bit set in set_ios or enable_sdio_irq? Regards, Madhu Cheers Dirk _ From: John Rigby [mailto:jcri...@gmail.com] Sent: Sunday, October 18, 2009 7:24 PM To: Woodruff, Richard Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Steve Sakoman Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430 Ok I was going to ask where you found that but I just rechecked the TRM and there it is in plain site: When this bit is set to 1, the host controller automatically disables all the input buffers except the buffer of mmci_dat[1] outside of a transaction in order to detect asynchronous card interrupt on mmci_dat[1] line and minimize the leakage current of the buffers. In my defence, I did search the TRM for every occurance of dat1 but not dat[1]. Oh well live and learn and forget and repeat. John On Sun, Oct 18, 2009 at 6:17 PM, John Rigby jcri...@gmail.com wrote: Richard, MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt Sounds exactly like what we need. Thanks John On Sun, Oct 18, 2009 at 5:12 PM, Woodruff, Richard r-woodru...@ti.com wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Dirk Behme Sent: Sunday, October 18, 2009 11:45 AM It would be funny if the TRM was wrong and the CIRQ bit is really cleared by writing 1 to it. I'll try that. A while back I hunted down a few of the bits for this. Maybe this will help some. SYSCONFIG.ENAWAKEUP = 1 allow ocp wrapper to generate an interrupt to prcm MMCHS_HCTL.IWE = 1 route wake up to module ocp wrapper MMCHS_CON.CPTL = 1 Don't disable input buffer on DAT1 after completion to allow seeing SDIO interrupt MMCHS_HCTL.IWE MMCHS_ISE.CIRQ_ENABLE bit to write to enable interrupt at pin MMCHS_STATbit to write for clear of SDIO interrupt R - IRQ_ENABLE (think host stack will do this) Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
* Tony Lindgren t...@atomide.com [091020 15:15]:
* ladislav.mi...@seznam.cz ladislav.mi...@seznam.cz [091020 14:53]:
On Fri, Oct 09, 2009 at 06:46:23PM -0400, Tony Lindgren wrote:
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap2-upstream
Initial commit ID (Likely to change):
439d2c69335a28ffdb5a9795ff384b6755ca0f7f
PatchWorks
http://patchwork.kernel.org/patch/52477/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=439d2c69335a28ffdb5a9795ff384b6755ca0f7f
This patch broke all OMAP1 boards. NULL terminator entry for omap1
serial_platform_data cannot be removed just because serial driver uses
is as last entry marker. Without it we end this way:
Unable to handle kernel NULL pointer dereference at virtual address 0028
pgd = c0004000
[0028] *pgd=
Internal error: Oops: 8005 [#1]
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12)
PC is at 0x28
LR is at serial8250_config_port+0x184/0xc34
(...etc...)
Please consider following fix (and while there fix OMAP2 too as patch broke
it as well (untested))
Thanks, I already refreshed the original patch with the same fix few
days ago :) It should be there in for-next branch and master branch.
Correction, sorry looks like I did not really read your patch. It seems
to be the right solution for mach-omap1, but not needed for mach-omap2
because the array is not plat_serial8250_port on mach-omap2.
Tony
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 9c59332..0392ff5 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -86,7 +86,9 @@ static struct plat_serial8250_port serial_platform_data[]
= {
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk= OMAP16XX_BASE_BAUD * 16,
- },
+ }, {
+ }
+
};
static struct platform_device serial_device = {
@@ -119,7 +121,7 @@ void __init omap_serial_init(void)
serial_platform_data[2].uartclk = OMAP1510_BASE_BAUD * 16;
}
- for (i = 0; i ARRAY_SIZE(serial_platform_data); i++) {
+ for (i = 0; i ARRAY_SIZE(serial_platform_data) - 1; i++) {
unsigned char reg;
/* Static mapping, never released */
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index dabc089..ca69ffa 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -585,7 +585,7 @@ void __init omap_serial_early_init(void)
* if not needed.
*/
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -637,7 +637,7 @@ void __init omap_serial_init(void)
{
int i;
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
--
To unsubscribe from this list: send the line unsubscribe 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
Fwd: mmap /dev/mem in python
If I run the following commads: devmem2 0x48004a40 w 0x038a # select 32kHz clock devmem2 0x48004a10 w 0x03007052 # enable iclk for gpt11 devmem2 0x48004a00 w 0x03007000 # enable fclk for gpt11 which all run sensibly and alter the registers, then I try to previous minimum example on address 0x48088024 (TCLK for gpt11) I get the following error: Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024 Bus error What puzzles me is that when I use devmem2 to read or write to the same register, everything works fine. On Tue, Oct 20, 2009 at 6:17 PM, Tony Lindgren t...@atomide.com wrote: * Brett Graham gra...@rowland.harvard.edu [091020 15:06]: I'm trying to mmap /dev/mem in python to access various registers on a gumstix overo (with an omap 3530 processor). Here is the code I'm using (as a minimal example): import os, mmap MAP_MASK = mmap.PAGESIZE - 1 addr = (see below) f = os.open(/dev/mem, os.O_RDWR | os.O_SYNC) m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE | mmap.PROT_READ, offset=addr ~MAP_MASK) m.seek(addr MAP_MASK) c = m.read_byte() print c m.close() os.close(f) If I use: addr = 0x48002178 everything works swimmingly. However, if I use: addr = 0x48088024 (or all the addresses I've tried 0x48044000) I get the following error Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024 Bus error and python crashes. I'm basing the mmap flags and options off of devmem2.c. If I remove the O_SYNC flag from the os.open command, I can read and write to registers fine, but randomly I will get the Unhandled fault error and things will not work correctly. Am I using the right command to write to the omap registers? should I be using the O_SYNC flag? Any ideas where these errors are coming from? Sounds like you need to enable ick and fck for the device you're trying to read. 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 -- To unsubscribe from this list: send the line unsubscribe 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: mmap /dev/mem in python
On Tue, 20 Oct 2009, Brett Graham wrote: If I use: addr = 0x48002178 everything works swimmingly. However, if I use: addr = 0x48088024 (or all the addresses I've tried 0x48044000) I get the following error Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024 Bus error 0x40020024 != 0x48088024 ? That's probably not the kernel's fault. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: mmap /dev/mem in python
It's good to at least know that this doesn't seem to be a kernel
issue, and thanks for the strace advice (I am new to this level of
linux development). Here is the truncated output for devmem and the
minimal example:
--- devmem ---
open(/dev/mem, O_RDWR|O_SYNC) = 3
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x4001f000
write(1, /dev/mem opened.\n, 17) = 17
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) = 0x4002
write(1, Memory mapped at address 0x40020..., 37) = 37
write(1, Value at address 0x48088024 (0x4..., 46) = 46
munmap(0x4002, 4096)= 0
close(3)= 0
io_submit(0, 0, 0xfbad2088 unfinished ... exit status 0
Process 1635 detached
--minimal python example--
open(/dev/mem, O_RDWR|O_SYNC|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
dup(3) = 4
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) = 0x4002
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++
Process 1633 detached
It looks like python decided to add a O_LARGEFILE and duplicate the
file descriptor. I'm still not sure what's going on here that's
causing the problem as both mmap2 calls are identical.
I don't mean to bombard this list with a problem that isn't related to
the kernel, so I'll post this to a python list somewhere. Thanks a
million for your help so far, this is driving me nutty! Also if any
more info would help just let me know.
On Tue, Oct 20, 2009 at 7:26 PM, Paul Walmsley p...@pwsan.com wrote:
On Tue, 20 Oct 2009, Brett Graham wrote:
If I run the following commads:
devmem2 0x48004a40 w 0x038a # select 32kHz clock
devmem2 0x48004a10 w 0x03007052 # enable iclk for gpt11
devmem2 0x48004a00 w 0x03007000 # enable fclk for gpt11
which all run sensibly and alter the registers, then I try to previous
minimum example on address 0x48088024 (TCLK for gpt11) I get the
following error:
Unhandled fault: external abort on non-linefetch (0x1018) at 0x40020024
Bus error
What puzzles me is that when I use devmem2 to read or write to the
same register, everything works fine.
Consider running strace on devmem2 and comparing it to the strace of your
Python code? That should show you any differences. If devmem2 works,
it's unlikely to be a kernel problem.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: mmap /dev/mem in python
On Tue, 20 Oct 2009, Brett Graham wrote:
--minimal python example--
open(/dev/mem, O_RDWR|O_SYNC|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFCHR|0640, st_rdev=makedev(1, 1), ...}) = 0
dup(3) = 4
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0x48088) = 0x4002
--- SIGBUS (Bus error) @ 0 (0) ---
+++ killed by SIGBUS +++
Process 1633 detached
Your script:
m = mmap.mmap(f, mmap.PAGESIZE, mmap.MAP_SHARED, mmap.PROT_WRITE |
mmap.PROT_READ, offset=addr ~MAP_MASK)
m.seek(addr MAP_MASK)
So the mmap() is working fine, based on the output above...
c = m.read_byte()
... but the above line is going to fail. GPTIMER registers need 16-
or 32-bit accesses[1].
- Paul
1. OMAP34xx TRM 16.3.2:
CAUTION
The GP timer registers are limited to 32-bit and 16-bit data accesses;
8-bit access is not allowed and can corrupt the register content.
--
To unsubscribe from this list: send the line unsubscribe 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: [APPLIED] [PATCH] [RFC] OMAP: eliminate OMAP_MAX_NR_PORTS
* Tony Lindgren t...@atomide.com [091020 16:01]:
* Tony Lindgren t...@atomide.com [091020 15:15]:
* ladislav.mi...@seznam.cz ladislav.mi...@seznam.cz [091020 14:53]:
On Fri, Oct 09, 2009 at 06:46:23PM -0400, Tony Lindgren wrote:
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap2-upstream
Initial commit ID (Likely to change):
439d2c69335a28ffdb5a9795ff384b6755ca0f7f
PatchWorks
http://patchwork.kernel.org/patch/52477/
Git (Likely to change, and takes a while to get mirrored)
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=439d2c69335a28ffdb5a9795ff384b6755ca0f7f
This patch broke all OMAP1 boards. NULL terminator entry for omap1
serial_platform_data cannot be removed just because serial driver uses
is as last entry marker. Without it we end this way:
Unable to handle kernel NULL pointer dereference at virtual address
0028
pgd = c0004000
[0028] *pgd=
Internal error: Oops: 8005 [#1]
last sysfs file:
Modules linked in:
CPU: 0Not tainted (2.6.32-rc5-06314-g4155da6-dirty #12)
PC is at 0x28
LR is at serial8250_config_port+0x184/0xc34
(...etc...)
Please consider following fix (and while there fix OMAP2 too as patch
broke
it as well (untested))
Thanks, I already refreshed the original patch with the same fix few
days ago :) It should be there in for-next branch and master branch.
Correction, sorry looks like I did not really read your patch. It seems
to be the right solution for mach-omap1, but not needed for mach-omap2
because the array is not plat_serial8250_port on mach-omap2.
I've refreshed the original serial.c patch in for-next branch by leaving
out the mach-omap2 changes. Also updated in the master branch, can you
please check?
Thanks,
Tony
Tony
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/arch/arm/mach-omap1/serial.c b/arch/arm/mach-omap1/serial.c
index 9c59332..0392ff5 100644
--- a/arch/arm/mach-omap1/serial.c
+++ b/arch/arm/mach-omap1/serial.c
@@ -86,7 +86,9 @@ static struct plat_serial8250_port
serial_platform_data[] = {
.iotype = UPIO_MEM,
.regshift = 2,
.uartclk= OMAP16XX_BASE_BAUD * 16,
- },
+ }, {
+ }
+
};
static struct platform_device serial_device = {
@@ -119,7 +121,7 @@ void __init omap_serial_init(void)
serial_platform_data[2].uartclk = OMAP1510_BASE_BAUD * 16;
}
- for (i = 0; i ARRAY_SIZE(serial_platform_data); i++) {
+ for (i = 0; i ARRAY_SIZE(serial_platform_data) - 1; i++) {
unsigned char reg;
/* Static mapping, never released */
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index dabc089..ca69ffa 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -585,7 +585,7 @@ void __init omap_serial_early_init(void)
* if not needed.
*/
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
@@ -637,7 +637,7 @@ void __init omap_serial_init(void)
{
int i;
- for (i = 0; i ARRAY_SIZE(omap_uart); i++) {
+ for (i = 0; i ARRAY_SIZE(omap_uart) - 1; i++) {
struct omap_uart_state *uart = omap_uart[i];
struct platform_device *pdev = uart-pdev;
struct device *dev = pdev-dev;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix broken NAND on Amstrad Delta
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091020 17:42]:
Hi,
I found that with commit 15ac408ee5a509053a765b816e9179515329369f, OMAP:
UART: drop OMAP_TAG_UART, enable all UARTs, auto-disabled on idle, NAND got
not accessible on Amstrad Delta (E3). That seems to be caused by unnecessary
omap_cfg_reg() calls for UART ports 2 and 3, that were never used on that
machine before and now are initilalized and supposed to be auto-disabled.
I can suspect that similiar problems may exist for other OMAP1510 based
boards. Furthermore, since mux code is going to be reorganized, the right
solution would probably be to remove those cpu_is_omap1510() specific bits
completely from arch/arm/mach-omap1/serial.c and push them into board specific
files where applicable. However, not being familiar with any OMAP hardware
other that my amsdelta, I provide a patch that solves the problem for that
machine only. I have locked out the bits for UART1 as well as those look not
really required, as far as I can understand
http://focus.ti.com/lit/ds/symlink/omap5910.pdf.
Oops. That happened as a nasty side effect when we removed the OMAP_TAG_UART
in commit 15ac408ee5a509053a765b816e9179515329369f.
Let's just remove the omap_cfg_reg() calls from mach-omap1/serial.c, and
add them to the board-*.c files like you suggest above. We should be able
to find which ports to mux by looking at the enabled_uarts mask in the
commit mentioned above.
Regards,
Tony
Created and tested against linux-2.6.32-r5.
Thanks,
Janusz
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
--- linux-2.6.32-rc5/arch/arm/mach-omap1/serial.c.orig2009-10-20
22:38:38.0 +0200
+++ linux-2.6.32-rc5/arch/arm/mach-omap1/serial.c 2009-10-21
01:26:51.0 +0200
@@ -143,7 +143,7 @@ void __init omap_serial_init(void)
if (cpu_is_omap15xx())
clk_set_rate(uart1_ck, 1200);
}
- if (cpu_is_omap15xx()) {
+ if (cpu_is_omap15xx() !(machine_is_ams_delta())) {
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
if (machine_is_omap_innovator()) {
@@ -165,7 +165,7 @@ void __init omap_serial_init(void)
else
clk_set_rate(uart2_ck, 4800);
}
- if (cpu_is_omap15xx()) {
+ if (cpu_is_omap15xx() !(machine_is_ams_delta())) {
omap_cfg_reg(UART2_TX);
omap_cfg_reg(UART2_RTS);
if (machine_is_omap_innovator()) {
@@ -185,7 +185,7 @@ void __init omap_serial_init(void)
if (cpu_is_omap15xx())
clk_set_rate(uart3_ck, 1200);
}
- if (cpu_is_omap15xx()) {
+ if (cpu_is_omap15xx() !(machine_is_ams_delta())) {
omap_cfg_reg(UART3_TX);
omap_cfg_reg(UART3_RX);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] omap: add bits for future 3430/3630 ES revisions
Paul Walmsley had written, on 10/20/2009 06:14 PM, the following:
Hi Vikram, Nishanth, Richard,
a few comments on this:
On Tue, 20 Oct 2009, Vikram Pandita wrote:
Add bits for future expansion of omap_chip_id type field.
This is needed to accomodate 3630ES1 chip id which is bit10
...
diff --git a/arch/arm/plat-omap/include/plat/cpu.h
b/arch/arm/plat-omap/include/plat/cpu.h
index 7cb0556..922bf1c 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -45,7 +45,7 @@ int omap_type(void);
struct omap_chip_id {
u8 oc;
- u8 type;
+ u32 type;
};
Just wanted to understand the motivation for using the u32.
Earlier in the life of these patches, two comments were mentioned: the
desire to 'futureproof' and the desire to reserve space for other
34xx-family parts.
Regarding 'futureproofing:' that's part of the reason that a separate
struct was defined for this: to prevent code that uses it from depending
on the size of the type. (Originally it was a typedef, but Linus hates
typedefs...) So it shouldn't matter how big or small the type is here, as
long as it can handle all of the bits allocated for it.
Also mentioned was the idea of reserving space for other 34xx-family
chips. I'd suggest simply renumbering the bits when and if those versions
appear. Code that uses the omap_chip_id system should always use the
macros (e.g. CHIP_IS_OMAP3430) and not encode separate bit shift values,
so renumbering should be completely safe and transparent for core code.
Module code shouldn't be using the omap_chip code, it's for core usage
only.
So, since only one bit is being added, why not continue the use of the u8?
Then when the next bits need to be added, the type can be expanded at that
point, and the bits renumbered if necessary. This should be a completely
transparent operation for code that uses it. Vikram's original patch:
http://patchwork.kernel.org/patch/54847/
should be fine.
Assumptions:
a) omap_chip_id is supposedly constant for all devices within the same
family. 3630, 3430 rev x will belong to the same family.
b) we prefer bitops to using cpu_is_blahblah() for reasons of
performance (if it could be argued so)..
Issues with the strategy of restricting to the current 8 bits:
a) Why extrabits now:
we have 8 bits now and we would have used all 8 bits with 3630 with the
mentioned patch. What do we do with the next revision of 3430? Do we
want to increase the size once it comes along? OR Do we want to do it
right now? Why wait till we get additional silicons to go figure how to
add those bits as Richard pointed out, when there could be one more in
the pipeline?
b) How much extra bits should we add?
It does not matter when you pull in extra bits - u'd have to go u16 for
next rev of 3430, it is gonna be a single entry, what if we end up (god
forbid) further revisions of 3630 or even a new gen of omap3 family -
call it 3XYZ devices?
Further how expensive is it to add the u16 Vs u32 size from a memory
usage perspective?
Either way, we could choose:
a) We can choose to stick with u8 and take the next rev of 3430 ES
revision when the time is right
b) we can choose to stick with u16 for the known future (+allowing for 5
more revisions of silicons) of OMAP3.
c) We can choose to say - no one really knows how many ES/variants of a
silicon family could happen for OMAP3/OMAP4/5/6/7 etc.. and choose u32
giving us a limit beyond which we might choose to rearchitect things.
The choice is upto this community to make.. options are very easy to
implement ;).
--
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] Fix broken NAND on Amstrad Delta
Hi,
I found that with commit 15ac408ee5a509053a765b816e9179515329369f, OMAP:
UART: drop OMAP_TAG_UART, enable all UARTs, auto-disabled on idle, NAND got
not accessible on Amstrad Delta (E3). That seems to be caused by unnecessary
omap_cfg_reg() calls for UART ports 2 and 3, that were never used on that
machine before and now are initilalized and supposed to be auto-disabled.
I can suspect that similiar problems may exist for other OMAP1510 based
boards. Furthermore, since mux code is going to be reorganized, the right
solution would probably be to remove those cpu_is_omap1510() specific bits
completely from arch/arm/mach-omap1/serial.c and push them into board specific
files where applicable. However, not being familiar with any OMAP hardware
other that my amsdelta, I provide a patch that solves the problem for that
machine only. I have locked out the bits for UART1 as well as those look not
really required, as far as I can understand
http://focus.ti.com/lit/ds/symlink/omap5910.pdf.
Created and tested against linux-2.6.32-r5.
Thanks,
Janusz
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
--- linux-2.6.32-rc5/arch/arm/mach-omap1/serial.c.orig 2009-10-20
22:38:38.0 +0200
+++ linux-2.6.32-rc5/arch/arm/mach-omap1/serial.c 2009-10-21
01:26:51.0 +0200
@@ -143,7 +143,7 @@ void __init omap_serial_init(void)
if (cpu_is_omap15xx())
clk_set_rate(uart1_ck, 1200);
}
- if (cpu_is_omap15xx()) {
+ if (cpu_is_omap15xx() !(machine_is_ams_delta())) {
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
if (machine_is_omap_innovator()) {
@@ -165,7 +165,7 @@ void __init omap_serial_init(void)
else
clk_set_rate(uart2_ck, 4800);
}
- if (cpu_is_omap15xx()) {
+ if (cpu_is_omap15xx() !(machine_is_ams_delta())) {
omap_cfg_reg(UART2_TX);
omap_cfg_reg(UART2_RTS);
if (machine_is_omap_innovator()) {
@@ -185,7 +185,7 @@ void __init omap_serial_init(void)
if (cpu_is_omap15xx())
clk_set_rate(uart3_ck, 1200);
}
- if (cpu_is_omap15xx()) {
+ if (cpu_is_omap15xx() !(machine_is_ams_delta())) {
omap_cfg_reg(UART3_TX);
omap_cfg_reg(UART3_RX);
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Calling omap_pcm_prepare() results in BUG() on OMAP1
Hi, After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, omap_pcm_prepare() unconditionally calls: omap_set_dma_src_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd-dma_ch, OMAP_DMA_DATA_BURST_16); AFAICS, current implementation of those two functions found in arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 at all, so they both end with BUG() on that machine. That seems to result in ASoC being completely unusable, at least on my OMAP5910 based Amstrad Delta. Is calling BUG() for OMAP1 from those functions intentional? If not intentional, can those be corrected by simply putting break; before defalut:? If intentional, can those function calls be conditionally omited, at least for OMAP1510, in sound/soc/omap/omap-pcm.c? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP3: DVFS: No sdrc AC timing changes during core dvfs
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Paul Walmsley Sent: Tuesday, October 20, 2009 8:21 PM This patch removes the SDRC AC timings changes done during core dvfs. Updating AC timing CTRL values for SDRC during DVFS is seen to be a risk, while the RFR CTRL value is safe to be updated. Signed-off-by: Rajendra Nayak rna...@ti.com just wanted to let you know, I haven't forgotten about this one. Am trying to get an answer from others as to whether AC timing register changes are completely unsafe, in which case your patch is probably the best way to move forward; or whether we can make the changes when no initiators are touching SDRAM. It is not guaranteed safe to write actim registers on the fly to an active part. It is safe to do RFR as it is buffered and sent out at a safe time. A few years back before omap3 as part of omap2 lessons learned this issue was highlighted but design was not able to change. Recently implementation review at rtl provided the above points. I'm not aware of anyone seeing a crash but recommendation for safety is to not. Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FW: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on OMAP3430
Any comments would be taken in.
Thanks
Regards
Shweta
-Original Message-
From: Gulati, Shweta
Sent: Tuesday, October 13, 2009 3:56 PM
To: linux-omap@vger.kernel.org
Cc: Gulati, Shweta; Gopinath, Thara
Subject: [PATCH V2] OMAP3:PM:Fix for Silicon bug on Context restore on OMAP3430
From: Shweta Gulati shweta.gul...@ti.com
(Resending the patch with the subject line and some minor fixes)
According to Silicon Bug on context restore it is found that the pad
configuration register for GPIO_28/GPIO_29(ETKD14/15) is corrupted after
returning from Core OFF mode. This happens if the MPU reads the
PADCONF_SAVEDONE bit very close to the end of context save sequence
for the pad conf registers, resulting in last context not being saved to the
scratchpad memory. This is a h/w bug. The workaround is to delay the
MPU access of SAVEDONE bit until the last context has been saved.
This patch adds a configuration option to allow 300 us delay in
save path as recommended by TI. The other option is to let the
bug occur but store the value of pad configuration register explicitly
and write it back in resume path. But this option should be chosen
only if the ETKD14/15 pads are not in use as this workaround can
lead to glitch in the pin.
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Signed-off-by: Thara Gopinathth...@ti.com
---
arch/arm/mach-omap2/pm34xx.c | 25 +
arch/arm/plat-omap/Kconfig | 17 +
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index cea3bca..4f9671a 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -26,6 +26,7 @@
#include linux/err.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/delay.h
#include mach/sram.h
#include mach/prcm.h
@@ -54,10 +55,19 @@
static int regset_save_on_suspend;
+/* A extra variable to store value of pad_config register if
+ * delay is not to be inserted and value is explicitly restored
+ * in resume path.
+ */
+#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
+static u32 store_pad_config;
+#endif
+
/* Scratchpad offsets */
#define OMAP343X_TABLE_ADDRESS_OFFSET 0x31
#define OMAP343X_TABLE_VALUE_OFFSET 0x30
#define OMAP343X_CONTROL_REG_VALUE_OFFSET 0x32
+#define CONTROL_PADCONF_ETK_D140x480025F8
u32 enable_off_mode;
u32 sleep_while_idle;
@@ -202,6 +212,17 @@ static void omap3_core_save_context(void)
omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_OFF);
control_padconf_off |= START_PADCONF_SAVE;
omap_ctrl_writel(control_padconf_off, OMAP343X_CONTROL_PADCONF_OFF);
+#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
+ store_pad_config = omap_readl(CONTROL_PADCONF_ETK_D14);
+#else
+ /* Due to Silicon Bug on context restore it is found
+* that the CONTROL_PAD_CONF_ETK14 register is not saved into
+* scratch pad memory sometimes. To rectify it delay acess by Mpu
+* for 300us for scm to finish saving task
+*/
+ udelay(300);
+#endif
+
/* wait for the save to complete */
while (!omap_ctrl_readl(OMAP343X_CONTROL_GENERAL_PURPOSE_STATUS)
PADCONF_SAVE_DONE)
@@ -217,6 +238,10 @@ static void omap3_core_save_context(void)
static void omap3_core_restore_context(void)
{
+ /* Restore the last padconf value if needed */
+#ifndef CONFIG_DELAY_IN_PADCONF_SAVE
+ omap_writel(store_pad_config, CONTROL_PADCONF_ETK_D14);
+#endif
/* Restore the control module context, padconf restored by h/w */
omap3_control_restore_context();
/* Restore the GPMC context */
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 2143db5..737d0aa 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -242,6 +242,23 @@ config OMAP_PM_SRF
endchoice
+config DELAY_IN_PADCONF_SAVE
+ bool Insert 300 us delay after the start of padconf saving
+ depends on ARCH_OMAP3 PM
+ help
+If this option is selected a 300 us delay is inserted in the
+suspend path after writing into START_PADCONF_SAVE bit to ensure
+that pad configuration register is stored properly.If mpu tries to
+access SAVE_DOME bit before the entire save is over, there is a
+possibility that the last padconf register is not saved properly.
+The delay ensures that mpu does not acess SAVE_DONE bit before the
+save is complete.
+
+If this option is not selected the bug is let
+to happen and last pad configuration register
+is explicitly saved in SDRAM and written back
+in resume path.
+
endmenu
endif
--
1.5.4.7
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
