Re: [PATCH 1/3] Fixing compilation warning for 'nand/omap2.c'
On Fri, 2009-10-30 at 14:12 +0530, Vimal Singh wrote: Looping Linux-omap mailing list. From: Vimal Singh vimalsi...@ti.com Date: Fri, 30 Oct 2009 11:31:34 +0530 Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c' Fixing below warning in compilation: drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref': drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of 'omap_nand_dma_transfer' discards qualifiers from pointer target type Signed-off-by: Vimal Singh vimalsi...@ti.com --- drivers/mtd/nand/omap2.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) [dedek...@eru l2-mtd-2.6.git]$ scripts/checkpatch.pl vimal ERROR: patch seems to be corrupt (line wrapped?) #94: FILE: drivers/mtd/nand/omap2.c:500: mtd_info *mtd, u_char *buf, int len) total: 1 errors, 0 warnings, 16 lines checked vimal has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. [dedek...@eru l2-mtd-2.6.git]$ vim vimal [dedek...@eru l2-mtd-2.6.git]$ git am vimal Applying: Fixing compilation warning for 'nand/omap2.c' fatal: corrupt patch at line 10 Patch failed at 0001 Fixing compilation warning for 'nand/omap2.c' When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. [dedek...@eru l2-mtd-2.6.git]$ -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- To unsubscribe from this list: send the line unsubscribe 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/3]NAND: OMAP: Fixing omap nand driver, compiled as module
On Fri, 2009-10-30 at 14:57 +0530, Vimal Singh wrote:
Last time I forgot to 'git add' for 'arch/arm/mach-omap2/gpmc.c'... My bad.
Correct patch is below.
-vimal
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 14:54:29 +0530
Subject: [PATCH] NAND: OMAP: Fixing omap nand driver, compiled as module
Removing OMAP NAND driver, when loaded as a module, gives error and
does not get success. This fixes this and makes driver loadable and
removable run time.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c |2 ++
drivers/mtd/nand/omap2.c |5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1587682..1d10b7b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -88,6 +88,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_write_reg);
u32 gpmc_cs_read_reg(int cs, int idx)
{
@@ -96,6 +97,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_read_reg);
Why do you export these?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe 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/3]NAND: OMAP: Fixing omap nand driver, compiled as module
On Tue, Nov 3, 2009 at 1:58 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Fri, 2009-10-30 at 14:57 +0530, Vimal Singh wrote:
Last time I forgot to 'git add' for 'arch/arm/mach-omap2/gpmc.c'... My bad.
Correct patch is below.
-vimal
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 14:54:29 +0530
Subject: [PATCH] NAND: OMAP: Fixing omap nand driver, compiled as module
Removing OMAP NAND driver, when loaded as a module, gives error and
does not get success. This fixes this and makes driver loadable and
removable run time.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 2 ++
drivers/mtd/nand/omap2.c | 5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1587682..1d10b7b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -88,6 +88,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_write_reg);
u32 gpmc_cs_read_reg(int cs, int idx)
{
@@ -96,6 +97,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_read_reg);
Why do you export these?
These functions are called during prob. So, if not exported and driver
is compiled as a module compilation will break with error saying these
are not defined or not found.
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe 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/3] Fixing compilation warning for 'nand/omap2.c'
On Tue, Nov 3, 2009 at 1:48 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Fri, 2009-10-30 at 14:12 +0530, Vimal Singh wrote:
Looping Linux-omap mailing list.
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 11:31:34 +0530
Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c'
Fixing below warning in compilation:
drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref':
drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of
'omap_nand_dma_transfer' discards qualifiers from pointer target type
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c | 6 --
1 files changed, 4 insertions(+), 2 deletions(-)
[dedek...@eru l2-mtd-2.6.git]$ scripts/checkpatch.pl vimal
ERROR: patch seems to be corrupt (line wrapped?)
#94: FILE: drivers/mtd/nand/omap2.c:500:
mtd_info *mtd, u_char *buf, int len)
total: 1 errors, 0 warnings, 16 lines checked
vimal has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
[dedek...@eru l2-mtd-2.6.git]$ vim vimal
[dedek...@eru l2-mtd-2.6.git]$ git am vimal
Applying: Fixing compilation warning for 'nand/omap2.c'
fatal: corrupt patch at line 10
Patch failed at 0001 Fixing compilation warning for 'nand/omap2.c'
When you have resolved this problem run git am --resolved.
If you would prefer to skip this patch, instead run git am --skip.
To restore the original branch and stop patching run git am --abort.
[dedek...@eru l2-mtd-2.6.git]$
Grr... its again mailer's issue. Fixed this in below patch:
-vimal
From eebbd81141b196af2dc3f7a2650ce16b6b0d76ae Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 11:31:34 +0530
Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c'
Fixing below warning in compilation:
drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref':
drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of
'omap_nand_dma_transfer' discards qualifiers from pointer target type
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 090ab87..92573d5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -501,11 +501,13 @@ static void omap_read_buf_dma_pref(struct
mtd_info *mtd, u_char
static void omap_write_buf_dma_pref(struct mtd_info *mtd,
const u_char *buf, int len)
{
+ u_char *p = (u_char *)buf;
+
if (len = mtd-oobsize)
- omap_write_buf_pref(mtd, buf, len);
+ omap_write_buf_pref(mtd, p, len);
else
/* start transfer in DMA mode */
- omap_nand_dma_transfer(mtd, buf, len, 0x1);
+ omap_nand_dma_transfer(mtd, p, len, 0x1);
}
/**
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3]NAND: OMAP: Fixing omap nand driver, compiled as module
On Tue, 2009-11-03 at 14:05 +0530, Vimal Singh wrote:
On Tue, Nov 3, 2009 at 1:58 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Fri, 2009-10-30 at 14:57 +0530, Vimal Singh wrote:
Last time I forgot to 'git add' for 'arch/arm/mach-omap2/gpmc.c'... My bad.
Correct patch is below.
-vimal
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 14:54:29 +0530
Subject: [PATCH] NAND: OMAP: Fixing omap nand driver, compiled as module
Removing OMAP NAND driver, when loaded as a module, gives error and
does not get success. This fixes this and makes driver loadable and
removable run time.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c |2 ++
drivers/mtd/nand/omap2.c |5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1587682..1d10b7b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -88,6 +88,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_write_reg);
u32 gpmc_cs_read_reg(int cs, int idx)
{
@@ -96,6 +97,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_read_reg);
Why do you export these?
These functions are called during prob. So, if not exported and driver
is compiled as a module compilation will break with error saying these
are not defined or not found.
Could you show the place where they are called from please. I tried to
compile the omap NAND driver as module and it compiled fine. Probably
I'm missing something?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe 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/3] Fixing compilation warning for 'nand/omap2.c'
On Tue, 2009-11-03 at 14:08 +0530, Vimal Singh wrote:
On Tue, Nov 3, 2009 at 1:48 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Fri, 2009-10-30 at 14:12 +0530, Vimal Singh wrote:
Looping Linux-omap mailing list.
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 11:31:34 +0530
Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c'
Fixing below warning in compilation:
drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref':
drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of
'omap_nand_dma_transfer' discards qualifiers from pointer target type
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
[dedek...@eru l2-mtd-2.6.git]$ scripts/checkpatch.pl vimal
ERROR: patch seems to be corrupt (line wrapped?)
#94: FILE: drivers/mtd/nand/omap2.c:500:
mtd_info *mtd, u_char *buf, int len)
total: 1 errors, 0 warnings, 16 lines checked
vimal has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
[dedek...@eru l2-mtd-2.6.git]$ vim vimal
[dedek...@eru l2-mtd-2.6.git]$ git am vimal
Applying: Fixing compilation warning for 'nand/omap2.c'
fatal: corrupt patch at line 10
Patch failed at 0001 Fixing compilation warning for 'nand/omap2.c'
When you have resolved this problem run git am --resolved.
If you would prefer to skip this patch, instead run git am --skip.
To restore the original branch and stop patching run git am --abort.
[dedek...@eru l2-mtd-2.6.git]$
Grr... its again mailer's issue. Fixed this in below patch:
-vimal
From eebbd81141b196af2dc3f7a2650ce16b6b0d76ae Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 11:31:34 +0530
Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c'
Fixing below warning in compilation:
drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref':
drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of
'omap_nand_dma_transfer' discards qualifiers from pointer target type
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
git-send-email ...
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 090ab87..92573d5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -501,11 +501,13 @@ static void omap_read_buf_dma_pref(struct
mtd_info *mtd, u_char
:-) It is the same again.
Try to send the e-mail to yourself, then save it and apply with git-am.
If it works, send to the mailing list.
static void omap_write_buf_dma_pref(struct mtd_info *mtd,
const u_char *buf, int len)
{
+ u_char *p = (u_char *)buf;
+
if (len = mtd-oobsize)
- omap_write_buf_pref(mtd, buf, len);
+ omap_write_buf_pref(mtd, p, len);
else
/* start transfer in DMA mode */
- omap_nand_dma_transfer(mtd, buf, len, 0x1);
+ omap_nand_dma_transfer(mtd, p, len, 0x1);
}
/**
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line unsubscribe 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/3]NAND: OMAP: Fixing omap nand driver, compiled as module
On Tue, Nov 3, 2009 at 2:09 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Tue, 2009-11-03 at 14:05 +0530, Vimal Singh wrote:
On Tue, Nov 3, 2009 at 1:58 PM, Artem Bityutskiy dedeki...@gmail.com wrote:
On Fri, 2009-10-30 at 14:57 +0530, Vimal Singh wrote:
Last time I forgot to 'git add' for 'arch/arm/mach-omap2/gpmc.c'... My
bad.
Correct patch is below.
-vimal
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 14:54:29 +0530
Subject: [PATCH] NAND: OMAP: Fixing omap nand driver, compiled as module
Removing OMAP NAND driver, when loaded as a module, gives error and
does not get success. This fixes this and makes driver loadable and
removable run time.
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 2 ++
drivers/mtd/nand/omap2.c | 5 -
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1587682..1d10b7b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -88,6 +88,7 @@ void gpmc_cs_write_reg(int cs, int idx, u32 val)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_write_reg);
u32 gpmc_cs_read_reg(int cs, int idx)
{
@@ -96,6 +97,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
reg_addr = gpmc_base + GPMC_CS0 + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_read_reg);
Why do you export these?
These functions are called during prob. So, if not exported and driver
is compiled as a module compilation will break with error saying these
are not defined or not found.
Could you show the place where they are called from please. I tried to
compile the omap NAND driver as module and it compiled fine. Probably
I'm missing something?
Code snippet from omap2.c, in prob call: line 919
---
/* Enable RD PIN Monitoring Reg */
if (pdata-dev_ready) {
val = gpmc_cs_read_reg(info-gpmc_cs, GPMC_CS_CONFIG1);
val |= WR_RD_PIN_MONITORING;
gpmc_cs_write_reg(info-gpmc_cs, GPMC_CS_CONFIG1, val);
}
val = gpmc_cs_read_reg(info-gpmc_cs, GPMC_CS_CONFIG7);
val = ~(0xf 8);
val |= (0xc 0xf) 8;
gpmc_cs_write_reg(info-gpmc_cs, GPMC_CS_CONFIG7, val);
---
--
Regards,
Vimal Singh
--
To unsubscribe from this list: send the line unsubscribe 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: Update DSS2 patches for latest kernel changes
Hi, On Mon, 2009-11-02 at 16:02 +0100, ext Hiremath, Vaibhav wrote: Hi Tomi, (Tomi, Sorry for resending it again, somehow last mail did not reach to list, so sending it again by removing patches attached.) DSS2 patches needs to be updated against the latest kernel changes, especially after commit omap: headers: Move remaining headers from include/mach to include/plat Since this patch has already merged to for-next, I have done required modification to your commits (for both master and pm branch), keeping rest of the stuff as is. I could able to validate it only on OMAP3EVM (since I don't have other EVMs) with DPI/Venc interface. If you could validate rest of the interfaces then we can update the DSS2 branch with latest kernel. You can access the patches from the repository - http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap-video.git;a=shortlog;h=refs/heads/ti_display Thanks, although I have already done that =). I'm in the process of integrating new patches (mostly VRFB and DSI fixes) to the DSS patch set. When I'm done I'll post them. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Fixing compilation warning for 'nand/omap2.c'
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 090ab87..92573d5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -501,11 +501,13 @@ static void omap_read_buf_dma_pref(struct
mtd_info *mtd, u_char
:-) It is the same again.
Try to send the e-mail to yourself, then save it and apply with git-am.
If it works, send to the mailing list.
Below patch applies. Sorry for noise... :(
Thanks,
vimal
From eebbd81141b196af2dc3f7a2650ce16b6b0d76ae Mon Sep 17 00:00:00 2001
From: Vimal Singh vimalsi...@ti.com
Date: Fri, 30 Oct 2009 11:31:34 +0530
Subject: [PATCH] Fixing compilation warning for 'nand/omap2.c'
Fixing below warning in compilation:
drivers/mtd/nand/omap2.c: In function 'omap_write_buf_dma_pref':
drivers/mtd/nand/omap2.c:508: warning: passing argument 2 of
'omap_nand_dma_transfer' discards qualifiers from pointer target type
Signed-off-by: Vimal Singh vimalsi...@ti.com
---
drivers/mtd/nand/omap2.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 090ab87..92573d5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -501,11 +501,13 @@ static void omap_read_buf_dma_pref(struct
static void omap_write_buf_dma_pref(struct mtd_info *mtd,
const u_char *buf, int len)
{
+ u_char *p = (u_char *)buf;
+
if (len = mtd-oobsize)
- omap_write_buf_pref(mtd, buf, len);
+ omap_write_buf_pref(mtd, p, len);
else
/* start transfer in DMA mode */
- omap_nand_dma_transfer(mtd, buf, len, 0x1);
+ omap_nand_dma_transfer(mtd, p, len, 0x1);
}
/**
--
1.5.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Update DSS2 patches for latest kernel changes
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Tuesday, November 03, 2009 2:25 PM To: Hiremath, Vaibhav Cc: linux-omap@vger.kernel.org Subject: Re: Update DSS2 patches for latest kernel changes Hi, On Mon, 2009-11-02 at 16:02 +0100, ext Hiremath, Vaibhav wrote: Hi Tomi, (Tomi, Sorry for resending it again, somehow last mail did not reach to list, so sending it again by removing patches attached.) DSS2 patches needs to be updated against the latest kernel changes, especially after commit omap: headers: Move remaining headers from include/mach to include/plat Since this patch has already merged to for-next, I have done required modification to your commits (for both master and pm branch), keeping rest of the stuff as is. I could able to validate it only on OMAP3EVM (since I don't have other EVMs) with DPI/Venc interface. If you could validate rest of the interfaces then we can update the DSS2 branch with latest kernel. You can access the patches from the repository - http://arago-project.org/git/people/?p=vaibhav/ti-psp-omap- video.git;a=shortlog;h=refs/heads/ti_display Thanks, although I have already done that =). [Hiremath, Vaibhav] I cross-checked your repository and could not find anything there, so I started rebasing it myself. Anyway, please let me know once you are done with it. Thanks, Vaibhav I'm in the process of integrating new patches (mostly VRFB and DSI fixes) to the DSS patch set. When I'm done I'll post them. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] TWL4030: Initial support for TWL5031
Hi Samuel, On Fri, 16 Oct 2009, Koskinen Ilkka (Nokia-D/Tampere) wrote: TWL5031 introduces two new interrupts in PIH. Moreover, BCI has changed remarkably and, thus, it's disabled when TWL5031 is in use. Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com --- drivers/mfd/twl4030-core.c | 12 - drivers/mfd/twl4030-irq.c | 127 +-- include/linux/i2c/twl4030.h | 47 ++-- 3 files changed, 173 insertions(+), 13 deletions(-) Sorry to bothering you again, but I'd like to know the status of this patch. Does it need more work or could you apply it to your tree at some point? Cheers, Ilkka -- To unsubscribe from this list: send the line unsubscribe 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: Restart after 4 min of operation?
On 11/02/2009 08:35 PM, Bill Gatliff wrote: Guys: Can someone give me any ideas as to why my Beagleboard-like platform would spontaneously restart after precisely four minutes of operation? No OOPS, no nothing. This is with 2.6.32-rc5. BeagleBoard like? More details are probably required for much help. How do you power it? My BeagleBoard is powered via the OTG. I've seen it reset if I hang too much on the USB host port (exceed the meager power budget) -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Query: Regulator framework in EHCI driver
Hi Anand/Felipe, This is regarding regulator framework for 1V8 supply to EHCI PHY from twl4030 device. [EHCI port on OMAP3EVM uses SMSC USB3320 PHY and uses 1V8 supply from twl4030 chip.] I found twl4030_usb_ldo_init () function in drivers/usb/otg/twl4030-usb.c, which uses regulator framework but it can not be used by all the board which are not using twl4030 PHY. Don't you think this function need to be moved to some other common location? Currently we are not enabling 1V8 supply explicitly but still EHCI works on EVM as most of the twl4030 supplies are enabled by default. I was thinking of adding regulator framework in EHCI driver which will enable the required supplies based on one of the board_data passed (same as reset_gpio) from board files. Regards, Ajay Gupta -- To unsubscribe from this list: send the line unsubscribe 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] omap3evm: enable keypad
This patch set enables the keypad in the default configuration. It also adds it as wake-up source from suspend. It has been created and tested against latest for-next branch. Sanjeev Premi (2): omap3evm: Enable keypad in defconfig omap3evm: Add keypad as wakeup source arch/arm/configs/omap3_evm_defconfig | 12 +--- arch/arm/mach-omap2/board-omap3evm.c | 12 2 files changed, 21 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] omap3evm: Enable keypad in defconfig
Enable the TWL4030/TPS65590 keypad in the default configuration. Also updated the section with related config options in .config for easy diff. Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/configs/omap3_evm_defconfig | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm/configs/omap3_evm_defconfig b/arch/arm/configs/omap3_evm_defconfig index d5ff477..24d8b08 100644 --- a/arch/arm/configs/omap3_evm_defconfig +++ b/arch/arm/configs/omap3_evm_defconfig @@ -676,13 +676,19 @@ CONFIG_INPUT_EVDEV=y # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y +# CONFIG_KEYBOARD_ADP5588 is not set # CONFIG_KEYBOARD_ATKBD is not set -# CONFIG_KEYBOARD_SUNKBD is not set +# CONFIG_QT2160 is not set # CONFIG_KEYBOARD_LKKBD is not set -# CONFIG_KEYBOARD_XTKBD is not set +# CONFIG_KEYBOARD_GPIO is not set +# CONFIG_KEYBOARD_MATRIX is not set +# CONFIG_KEYBOARD_MAX7359 is not set # CONFIG_KEYBOARD_NEWTON is not set +# CONFIG_KEYBOARD_OPENCORES is not set # CONFIG_KEYBOARD_STOWAWAY is not set -# CONFIG_KEYBOARD_GPIO is not set +# CONFIG_KEYBOARD_SUNKBD is not set +CONFIG_KEYBOARD_TWL4030=y +# CONFIG_KEYBOARD_XTKBD is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set -- 1.6.2.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3evm: Add keypad as wakeup source
Add keypad as wakeup source from 'suspend'
state.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 660ef8c..6a1a0cd 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -343,6 +343,16 @@ static struct platform_device *omap3_evm_devices[]
__initdata = {
omap3evm_smc911x_device,
};
+/*
+ * Set wakeup sources for the board
+ */
+static void __init omap3_evm_wakeup_sources(void)
+{
+ pr_info(omap3evm: Adding wakeup sources);
+
+ omap_cfg_reg(AF26_34XX_SYS_NIRQ);
+}
+
static void __init omap3_evm_init(void)
{
omap3_evm_i2c_init();
@@ -359,6 +369,8 @@ static void __init omap3_evm_init(void)
#endif
usb_musb_init();
ads7846_dev_init();
+
+ omap3_evm_wakeup_sources();
}
static void __init omap3_evm_map_io(void)
--
1.6.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] MFD: twl4030-codec: APLL_INFREQ handling in the MFD driver
On Monday 02 November 2009 19:30:35 ext Mark Brown wrote:
On Mon, Nov 02, 2009 at 02:34:53PM +0200, Peter Ujfalusi wrote:
Move the APLL_CTL register configuration to the twl4030-codec
MFD driver.
Provide also a function for childs to query the audio_mclk
frequency.
This all looks good to me, some nitpicks below.
+unsigned int twl4030_codec_get_mclk(void)
+{
+ struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
+
+ return codec-audio_mclk;
+}
+EXPORT_SYMBOL_GPL(twl4030_codec_get_mclk);
As I said in my followup to patch 5 this feels like it should have a
parameter to specify the twl4030 though in practical systems it won't
matter.
I agree that this does not look quite nice, but as you already mentioned, it is
highly unlikely that one system would have more than one twl series of PM chip
on board. Another reason is that we have other part of the twl, which needs
resources from the codec part, but it is not loaded through the codec MFD, so
providing the needed information is kind of tricky with that setup.
+ if (!(pdata-audio_mclk == 1920 ||
+ pdata-audio_mclk == 2600 ||
+ pdata-audio_mclk == 3840)) {
+ dev_err(pdev-dev, Invalid audio_mclk\n);
+ return -EINVAL;
+ }
Might flow more naturally with a switch statement?
Yes, true. This looks weird, I'll change it.
--
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 3/5] MFD: twl4030-codec: APLL_INFREQ handling in the MFD driver
on board. Another reason is that we have other part of the twl, which needs resources from the codec part, but it is not loaded through the codec MFD, so providing the needed information is kind of tricky with that setup. I had thought that the sub-device was supposed to handle the arbitration and could be used here. But like we said, it's not going to make any difference in the grand scheme of things. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP3: move check_revision above check_features
On Tue, Oct 20, 2009 at 05:48:57AM -0500, Nishanth Menon wrote: 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 Acked-by: Mika Westerberg mika.westerb...@iki.fi Br, MW -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] MFD: twl4030-codec: APLL_INFREQ handling in the MFD driver
On Tuesday 03 November 2009 15:44:38 ext Mark Brown wrote: on board. Another reason is that we have other part of the twl, which needs resources from the codec part, but it is not loaded through the codec MFD, so providing the needed information is kind of tricky with that setup. I had thought that the sub-device was supposed to handle the arbitration and could be used here. That would have been ideal. As such the audio and the Vibra interface is the only one directly inside of the codec part of twl, but there is a need for other modules to actually control resources within the codec part in order to operate, but they are not actually sub-devices of the codec MFD. -- 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 5/5] ASoC: TWL4030: Do not modify the APLL_CTL register
On Monday 02 November 2009 19:27:20 ext Mark Brown wrote:
On Mon, Nov 02, 2009 at 02:34:55PM +0200, Peter Ujfalusi wrote:
APLL_CTL register is configured by the twl4030-codec MFD
driver.
Remove code, which makes changes in the APLL_CTL register,
and replace those with checks against the configured
audio_mclk configuration done in the MFD driver.
This all looks mostly OK. It might be nice to combine this patch with
the change to the MFD driver, simply because when the previous patch
said move but didn't remove anything from the CODEC driver it seemed a
bit surprising. The MFD part of this is queued in ASoC ATM so it
shouldn't cause cross tree issues.
I just wanted to keep patches for different subsystems separate, but I can
either merge those two, or change the commit message in patch 3, that it will
be
not misleading.
- twl4030_write(codec, TWL4030_REG_APLL_CTL, apll_ctrl);
+ if ((freq / 1000) != twl4030-sysclk) {
+ dev_err(codec-dev,
+ Mismatch in APLL infrequency %u (configred: %u)\n,
+ freq, twl4030-sysclk * 1000);
Typos in the log message here (and similarly for the other DAI).
Will fix those.
- if (infreq != TWL4030_APLL_INFREQ_26000KHZ) {
+ if (twl4030-sysclk != 26000) {
printk(KERN_ERR TWL4030 voice startup:
MCLK is not 26MHz, call set_sysclk() on init\n);
return -EINVAL;
Is that advice still appropriate if things are specified via the
codec device now?
Correct, it is not correct.
@@ -2233,6 +2215,7 @@ static int __devinit twl4030_codec_probe(struct
platform_device *pdev) twl4030_codec = codec;
/* Set the defaults, and power up the codec */
+ twl4030-sysclk = twl4030_codec_get_mclk() / 1000;
twl4030_init_chip(codec);
codec-bias_level = SND_SOC_BIAS_OFF;
twl4030_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
twl4030_codec_get_mclk() feels like it ought to take a parameter saying
which twl4030, though the chances of having multiple twl4030s in one
system are remote so it's not a real issue.
We have discussed this, but, yes the chances of having more than one twl in a
system is unlikely.
--
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] omap3: beagle: Fix USB host port power control
Any comments on this, I need this on beagleboard to make ehci work. regards, Koen Op 24 okt 2009, om 09:59 heeft Jarkko Nikula het volgende geschreven: The host port power is enabled by driving the nEN_USB_PWR low as stated in the comment. This fix is originally from Steve Sakoman st...@sakoman.com . Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Steve Sakoman st...@sakoman.com --- arch/arm/mach-omap2/board-omap3beagle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach- omap2/board-omap3beagle.c index 6cb99f6..7ad9846 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -162,7 +162,7 @@ static int beagle_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); - gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); + gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, August 27, 2009 1:55 PM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3 Hi Teerth, Reddy, Teerth tee...@ti.com writes: From : Teerth Reddy tee...@ti.com This patch changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup issue on OMAP3 SDP. Signed-off-by: Teerth Reddy tee...@ti.com Patch looks good, thanks. I'll pull this into PM branch and queue in my PM fixes queue for next merge window. I did a minor update by adding a comment in the enable_board_wakeup_source function stating that this is the interrupt pin used for T2. Kevin Teerth, Kevin, Did you test it with OFF mode enabled? When I do echo 1 /sys/power/enable_off_mode I don't see resume on the omap3evm. Schematics for the keypad are/seem to be same for EVM and SDP. Best regards, Sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap: mux: Add new style pin multiplexing data for 34xx
* Mike Rapoport mike.rapop...@gmail.com [091102 23:10]:
On Mon, Nov 2, 2009 at 9:10 PM, Tony Lindgren t...@atomide.com wrote:
* Mike Rapoport m...@compulab.co.il [091101 02:30]:
Tony Lindgren wrote:
Add new style mux data for 34xx. This should also
work with 3630 easily by adding the processor subset
and ball data.
Note that this data is __initdata, and gets optimized
out if CONFIG_OMAP_MUX is not set. Also, the debug data
gets optimized out if CONFIG_DEBUG_FS is not set.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 4
arch/arm/mach-omap2/mux.h | 2
arch/arm/mach-omap2/mux34xx.c | 1552
+
arch/arm/mach-omap2/mux34xx.h | 352 +
4 files changed, 1910 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h
[ snip ]
+
+#define OMAP3_CONTROL_PADCONF_MUX_SIZE \
+ (OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET + 0x2)
What about adding defines for each possible mode configuration, except,
perhaps,
GPIO?
Yeah it would be nice to make it easy. How about someting like:
int __init omap_mux_init_by_name(char *name, int flags);
...
omap_mux_init_by_name(i2c1_scl, OMAP_PIN_INPUT_PULLUP);
#define OMAP3_PIN_CAM_D0 OMAP3_MUX(CAM_D0, OMAP_PIN_MODE0 |
OMAP_PIN_INPUT, 0)
#define OMAP3_PIN_CAM_D0_CSI2_DX2 OMAP3_MUX(CAM_D0, OMAP_PIN_MODE2 | \
OMAP_PIN_INPUT, 0)
And, I'm for adding OMAP_MUX_GPIO_{OUT,IN,IN_PU,IN_PD}(x) as well.
And we could have also:
int __init omap_mux_init_by_gpio(int gpio, int flags);
...
omap_mux_init_by_gpio(99, OMAP_PIN_INPUT);
As the only thing we currently have for flags is the OMAP_MUX_DYNAMIC,
we could mask that too into flags and make it int instead of u16.
It seems we are thinking in really different directions :) You propose
imporved and easy to use replacements of omap_cfg_reg while I'm aming
nice tables descibing board pin configuration like, e.g,
cm_x300_mfp_cfg in arch/arm/mach-pxa/cm-x300.c. Probably it's just too
hard to me to break my PXA habbits, but I think such tables make the
board code easier to write/maintain/understand.
Besides, having both simple aliases for OMAP3_MUX(mode0, mux_value,
mux_flags) for dedicated pins does not contadict having
omap_mux_init_by_{name,gpio} helpers.
Agreed, we should make the pin muxing as easy as possible as it's
probably the biggest hurdle to anybody to start making changes to a
development board. And we should have easy to to read board specific
pin configuration tables like you're suggesting.
In the long run, we should probably start using the real signal names
as they seem to be more future proof across omaps than the register
names.
We can easily do something like this if we add char *muxname to
struct omap_board_mux (untested):
#define OMAP_MUX_SIGNAL(signal, mux_flags) \
{ \
.muxname= #signal, \
.flags = (mux_flags), \
}
#define OMAP_MUX_GPIO(gpio, mux_flags) \
{ \
.muxname= gpio_##signal,\
.flags = (mux_flags), \
}
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
OMAP_MUX_SIGNAL(i2c1_scl, OMAP_PIN_INPUT),
OMAP_MUX_GPIO(98, OMAP_PIN_INPUT_PULLUP),
OMAP_MUX_GPIO(99, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_DYNAMIC),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
Of course then we have to warn on potential duplicate signal names,
but those can be specified using the register offset + mode as
needed.
Is the above close enough to what you have in mind regarding the
board specific mux tables, or do you have still something else
in mind?
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] New mux code for 34xx
* Mike Rapoport mike.rapop...@gmail.com [091102 22:42]: On Mon, Nov 2, 2009 at 8:56 PM, Tony Lindgren t...@atomide.com wrote: * Mike Rapoport m...@compulab.co.il [091101 02:29]: Hi Tony, Tony Lindgren wrote: Hi all, Here's an initial version of the new mux code to play with. Big thanks to Paul Benoit for the 34xx mux data! I've tried your patches, they seem to work just fine on CM-T35. OK cool. To try out the new code, compile a kernel with CONFIG_OMAP_MUX and CONFIG_DEBUG_FS and these patches. The series is also availabe in the l-o git in mux branch. [ snip ] Comments welcome as always. There are some comments on patches 2 (Add new style pin multiplexing code for omap3) and 3 (Add new style pin multiplexing data for 34xx). No nitpicking for now, but checkpatch.pl is unhappy with the patchset :) OK, will run checkpatch.pl --strict on them. Thanks for the comments! While on it, can you please update board-cm-t35.c to use CUS package? OK, will do. FYI, currently working on converting the old style omap_cfg_reg() calls so we can remove the old code for 34xx. It will be probably few days before I get around posting updated patches because of some meetings over next few days. 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: Driver Merge Questions
* Chris Hudson chud...@kionix.com [091103 06:48]: Hello all, I've never submitted any software to Linux before, but I've been working on some new accelerometer drivers that should be ready for review soon (pending company approval). I've read lots of documentation on patch and driver submissions, but I still have some questions that I was hoping someone could help me find the answers to. 1- My drivers use i2c for hardware communications, miscdevice for IOCTLs, and input_dev for data and interrupt status outputs. Most of the other accelerometer drivers that I've looked at use similar designs and are located in drivers/hwmon, but I just wanted to confirm that this is the correct location currently. Sounds correct. 2- I have done all of my hardware testing with OMAP development platforms, so I thought it would be best to send my patch submissions to this list for review. The hardware monitoring tree is listed in MAINTAINERS as an orphan, but I was planning on including lm-sens...@lm-sensors.org as well. If either of these assumptions is incorrect, please let me know. Yes, please send the patches to both. Also, please run the patches through scripts/checkpatch.pl --strict, and read the files under Documentation/Submit* ;) 3- Should my patch set consist of source, header, kconfig, and makefile patches, or should I include my custom changes to mux.c, mux.h, and board-zoom2.c as well? The former are necessary for adding driver support, but the latter are specific for my hardware testing platform (which others may want to duplicate for testing purposes). I noticed that recent versions of board-zoom2.c are nice and clean, so it's probably not a good idea to wedge infrequently-used code in there with a bunch of #ifdefs. I just want to get an idea of what is generally included with a new driver. Compile should work throughout the series for each patch to keep git bisect working. To me it sounds like one patch for the driver, and then one to enable the driver in some hardware. Please not that we're reworking the mux code for omap3 to make it easier to use. So please make the mux changes yet another patch. Any help or advice would be greatly appreciated. Hope this helps! 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] OMAP3: decrease cpufreq transition latency
* Kevin Hilman khil...@deeprootsystems.com [091029 14:14]: Mike Turquette mturque...@gmail.com writes: Adjust OMAP3 frequency transition latency from 10,000,000uS to a more reasonable 300,000uS. This causes ondemand and conservative governors to sample CPU load more often resulting in more responsive behavior. Tested on Android 2.6.29; using this value and conservative governor, CORE power consumption on Zoom2 was comparable to the old and unresponsive 10,000,000uS value while UI responsiveness was greatly improved. This patch applies against Tony's omap-fixes branch. Signed-off-by: Mike Turquette mturque...@ti.com --- arch/arm/plat-omap/cpu-omap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/cpu-omap.c b/arch/arm/plat-omap/cpu-omap.c index 1868c0d..341235c 100644 --- a/arch/arm/plat-omap/cpu-omap.c +++ b/arch/arm/plat-omap/cpu-omap.c @@ -127,7 +127,7 @@ static int __init omap_cpu_init(struct cpufreq_policy *policy) } /* FIXME: what's the actual transition time? */ Can probably drop this 'FIXME' comment now. - policy-cpuinfo.transition_latency = 10 * 1000 * 1000; + policy-cpuinfo.transition_latency = 300 * 1000; otherwise, Signed-off-by: Kevin Hilman khil...@deeprootsystems.com Tony, can this still be queued for .32-rc? Sure, I'll put together one more omap-fixes series this week. 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] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091031 18:20]: Friday 30 October 2009 18:33:18 Tony Lindgren napisał(a): * Janusz Krzysztofik jkrzy...@tis.icnet.pl [091030 07:43]: Thursday 29 October 2009 23:39:44 Janusz Krzysztofik napisał(a): With CONFIG_PM=y, the omapfb/lcd device on Amstrad Delta, after initially starting correctly, breaks with the following error messages: omapfb omapfb: resetting (status 0xff96,reset count 1) ... omapfb omapfb: resetting (status 0xff96,reset count 100) omapfb omapfb: too many reset attempts, giving up. Looking closer at this I have found that it had been broken almost 2 years ago with commit 2418996e3b100114edb2ae110d5d4acb928909d2, PM fixes for OMAP1. The definite reason for broken omapfb/lcd_ams_delta in PM mode appeared to be ARM_IDLECT1:IDLIF_ARM (bit 6) put into idle. The patch below fixes it. Since PM area is quite new to me, I am not sure if there may be a better solution. AFAICS, the standard way to prevent an ARM_CLKCT1 bit being switched to idle is to enable a clock that uses it (tipb_ck, dma_ck, or tc_ck or one of its children in this case, right?). I assume there is no bug in omapfb nor lcdc, as that would be already detected. Maybe it would be better to fix drivers/video/omap/lcd_ams_delta.c (or arch/arm/mach-omap1/board-ams-delta), but I don't know what clock should I enable, if any. More looking at it, I found that might be omap_dma_running() from arch/arm/plat-omap/dma.c that needs correction. It already checks for LCD dma running for OMAP1610, but does nothing similiar for 1510. I have revisited http://focus.ti.com/lit/ug/spru674/spru674.pdf, but found no hint how to do that in a 1610 similiar way. Hmm to me it looks like the OMAP_DMA_CCR_EN should be set in one of the channels if enabled. Maybe you need add a similar check somewhere in the *_lcd_dma_* functions too in dma.c? Tony, It sounds reasonable, but the problem is that in the OMAP5910 documentation I can find no DMA_CCR equivalent in the LCD dedicated DMA channel register set, nor EN equivalent in the DMA_LCD_CTRL register. I have had a look at *_lcd_dma_*, as you suggested, and found this: /* * Set the Enable bit only if an external controller is * connected. Otherwise the OMAP internal controller will * start the transfer when it gets enabled. */ if (enable_1510_mode || !lcd_dma.ext_ctrl) return; That may suggest checking for LCD controller, not DMA channel, enable bit could give an answer if LCD DMA is likely to be running or not. So maybe adding a function to drivers/video/omap/lcdc.c that would check for OMAP_LCDC_CONTROL:OMAP_LCDC_CTRL_LCD_EN, then invoke that function from omap_dma_running() in case of omap1510 could be a proper solution. However, that would affect not only Amstrad Delta, but all 1510 based machines. Since there were no reports about broken LCD DMA on 1510, I'd rather get a confirmation from omap guys, more experienced than me, that the solution proposed is correct and should work not only for my Amstrad Delta before I get that way. That sounds like a reasonable way to fix it to me. 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: n8x0 idle power problem
* Felix Xiaozhu Lin x...@rice.edu [091023 16:41]: I am trying to compile a linux-omap kernel for n810 that can do good idle power management. However, this seems to be harder than I expected. I've done all following measurements with /sys/power/sleep_while_idle set to 1. Compiler is arm-linux-gnueabi-gcc 4.2. I use n8x0_defconfig. * Maemo kernel (2.6.21) consumes ~...@3.8v when idle. This seems to be perfect. However, it has no pm regarding serial port. Whenever serial port is enabled, idle power is ~5...@3.8v. * I've compiled 2.6.28/2.6.29 from l-o git. Serial port pm works fine. However the idle power is ~2...@3.8v. That is quite strange. * For kernel = 2.6.30 I didn't manage to boot my N810. I also dig out a thread discussing about N8x0 idle power: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11954.html where Kalle mentioned 2.6.29 idle power is OK. But I never get the same result. I'm wondering if I did something wrong in the measurement. Anybody did the same thing? You suggestion is highly appreciated. It sounds like something is blocking the deeper idle states. The way to debug is to see what clocks and domains are on before entering idle. Maybe do a register dump on a working system and compare that to the current system? 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] omap3: beagle: Fix USB host port power control
* Koen Kooi k.k...@student.utwente.nl [091103 06:11]: Any comments on this, I need this on beagleboard to make ehci work. Looks like a fix to me, will queue. Tony regards, Koen Op 24 okt 2009, om 09:59 heeft Jarkko Nikula het volgende geschreven: The host port power is enabled by driving the nEN_USB_PWR low as stated in the comment. This fix is originally from Steve Sakoman st...@sakoman.com. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Steve Sakoman st...@sakoman.com --- arch/arm/mach-omap2/board-omap3beagle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 6cb99f6..7ad9846 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -162,7 +162,7 @@ static int beagle_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); -gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); +gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; -- 1.6.3.3 -- To unsubscribe from this list: send the line unsubscribe linux- omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: Please advise on modifying defconfig for Amstrad Delta
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091024 19:41]: Hi, I'm just working on a new, updated version of ams_delta_defconfig. Starting from the current version, created over 2 years ago for 2.6.22, I turned on a few device drivers that was added recently, turned on thumb instructions support, turned on EABI, kept old ABI compatibility and NWFPE, and got a resulting kernel that is ~170kB too large to be successfully booted using tools available at http://the.earth.li/pub/e3/. Of course, I am able to trim that down, even adding a few more drivers for add-on hardware that I am using, and get a kernel that works perfectly for me, but since I have never prepared a default config, I'd like to get your advice on what I can remove and what should rather be kept untouched. Instead of pasting sixteen hundred lines here, I'd rather ask about the simplest change I can see: -# CONFIG_EMBEDDED is not set -CONFIG_KALLSYMS=y +CONFIG_EMBEDDED=y +# CONFIG_KALLSYMS is not set That would give me a kernel that is small enough, but since only a few of arm defconfigs have CONFIG_KALLSYMS not set, I am not sure if it is generally acceptable. Send that as a fix to this list with the minimal changes, we should still be able to get it in as a fix during the -rc series. If you want to update the whole defconfig, we need to wait for the merge window. Just do the diff -u, then edit the patch to leave out all the other hunks except the one above. 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: n8x0 idle power problem
By 'deeper-sleep state', you mean the full retention mode? I am sure that pm24xx.c:omap2_enter_full_retention() is called and the assembly code in sleep24xx.S is executed, by printing some debug info. Thanks. Best Regards, -- Felix On Tue, Nov 3, 2009 at 11:19 AM, Tony Lindgren t...@atomide.com wrote: * Felix Xiaozhu Lin x...@rice.edu [091023 16:41]: I am trying to compile a linux-omap kernel for n810 that can do good idle power management. However, this seems to be harder than I expected. I've done all following measurements with /sys/power/sleep_while_idle set to 1. Compiler is arm-linux-gnueabi-gcc 4.2. I use n8x0_defconfig. * Maemo kernel (2.6.21) consumes ~...@3.8v when idle. This seems to be perfect. However, it has no pm regarding serial port. Whenever serial port is enabled, idle power is ~5...@3.8v. * I've compiled 2.6.28/2.6.29 from l-o git. Serial port pm works fine. However the idle power is ~2...@3.8v. That is quite strange. * For kernel = 2.6.30 I didn't manage to boot my N810. I also dig out a thread discussing about N8x0 idle power: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg11954.html where Kalle mentioned 2.6.29 idle power is OK. But I never get the same result. I'm wondering if I did something wrong in the measurement. Anybody did the same thing? You suggestion is highly appreciated. It sounds like something is blocking the deeper idle states. The way to debug is to see what clocks and domains are on before entering idle. Maybe do a register dump on a working system and compare that to the current system? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] AM35xx: Add AM35xx specific control module registers
AM3517/05 has a few additional control module registers defined mainly to control the new IP's. This patch adds support for those new registers. Signed-off-by: Ranjith Lohithakshan ranji...@ti.com --- arch/arm/plat-omap/include/plat/control.h | 17 + 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/control.h b/arch/arm/plat-omap/include/plat/control.h index fdb6300..9ba907a 100644 --- a/arch/arm/plat-omap/include/plat/control.h +++ b/arch/arm/plat-omap/include/plat/control.h @@ -147,6 +147,15 @@ #define OMAP343X_CONTROL_PBIAS_LITE(OMAP2_CONTROL_GENERAL + 0x02b0) #define OMAP343X_CONTROL_TEMP_SENSOR (OMAP2_CONTROL_GENERAL + 0x02b4) +/* OMAP3517/AM3517 only CONTROL_GENERAL register offsets */ +#define OMAP3517_CONTROL_MSUSPENDMUX_6 (OMAP2_CONTROL_GENERAL + 0x0038) +#define OMAP3517_CONTROL_DEVCONF2 (OMAP2_CONTROL_GENERAL + 0x0310) +#define OMAP3517_CONTROL_DEVCONF3 (OMAP2_CONTROL_GENERAL + 0x0314) +#define OMAP3517_CONTROL_CBA_PRIORITY (OMAP2_CONTROL_GENERAL + 0x0320) +#define OMAP3517_CONTROL_LVL_INTR_CLEAR (OMAP2_CONTROL_GENERAL + 0x0324) +#define OMAP3517_CONTROL_IP_SW_RESET(OMAP2_CONTROL_GENERAL + 0x0328) +#define OMAP3517_CONTROL_IP_CLK_CTRL(OMAP2_CONTROL_GENERAL + 0x032C) + /* 34xx D2D idle-related pins, handled by PM core */ #define OMAP3_PADCONF_SAD2D_MSTANDBY 0x250 #define OMAP3_PADCONF_SAD2D_IDLEACK0x254 @@ -238,6 +247,14 @@ #defineFEAT_NEON 0 #defineFEAT_NEON_NONE 1 +/* OMAP3517_CONTROL_IP_CLK_CTRL bits */ +#define OMAP3517_USBOTG_VBUSP_CLK_SHIFT0 +#define OMAP3517_CPGMAC_VBUSP_CLK_SHIFT1 +#define OMAP3517_VPFE_VBUSP_CLK_SHIFT 2 +#define OMAP3517_HECC_VBUSP_CLK_SHIFT 3 +#define OMAP3517_USBOTG_FCLK_SHIFT 8 +#define OMAP3517_CPGMAC_FCLK_SHIFT 9 +#define OMAP3517_VPFE_FCLK_SHIFT 10 #ifndef __ASSEMBLY__ #if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \ -- 1.6.2.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Restart after 4 min of operation?
Gary Thomas wrote: On 11/02/2009 08:35 PM, Bill Gatliff wrote: Guys: Can someone give me any ideas as to why my Beagleboard-like platform would spontaneously restart after precisely four minutes of operation? No OOPS, no nothing. This is with 2.6.32-rc5. BeagleBoard like? More details are probably required for much help. How do you power it? My BeagleBoard is powered via the OTG. I've seen it reset if I hang too much on the USB host port (exceed the meager power budget) It's a clone of a BeagleBoard, but with more and friendlier I/O. CUS package, and they use the TPS65023RSB power supply manager. I'm not ready to bury anyone in more details yet, since it's a client's hardware and I feel like I'm imposing already... :) When I boot it to my kernel, which is based on 2.6.32-rc5, it comes up fine and then for no apparent reason after four minutes goes through a reset again. I know it's approximately the same each time, because I have uptime running in a loop so that I can conveniently see when it dies. The very same tree boots and runs properly on a true BeagleBoard rev C. What's even more wierd is that even when sitting at the u-boot prompt before launching any kernel at all, the board does the same thing--- spontaneous reset after about four minutes. The client provided me the u-boot image, and it says it's a modified one from the OMAP3EVM--- it even provides that machine id. The above behavior makes me suspect hardware, but read on before you agree. Finally, the client provided me a kernel of unknown origin (it says it's a 2.6.29-rc2) that appears to run fine no hiccup at 4 minutes. Of course, that kernel doesn't have the features they need. I'm going over it now to see if there's a magic bit somewhere that mine is missing, but I'm at a bit of a loss to explain what I'm seeing right now. Anyone have any ideas? Bizzare. (BTW, nice to hear from you again, Gary! It's been a while.) b.g. -- Bill Gatliff b...@billgatliff.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: Restart after 4 min of operation?
Gary Thomas wrote: On 11/02/2009 08:35 PM, Bill Gatliff wrote: Guys: Can someone give me any ideas as to why my Beagleboard-like platform would spontaneously restart after precisely four minutes of operation? No OOPS, no nothing. This is with 2.6.32-rc5. BeagleBoard like? More details are probably required for much help. How do you power it? My BeagleBoard is powered via the OTG. I've seen it reset if I hang too much on the USB host port (exceed the meager power budget) It's a clone of a BeagleBoard, but with more and friendlier I/O. CUS package, and they use the TPS65023RSB power supply manager. I'm not ready to bury anyone in more details yet, since it's a client's hardware and I feel like I'm imposing already... :) When I boot it to my kernel, which is based on 2.6.32-rc5, it comes up fine and then for no apparent reason after four minutes goes through a reset again. I know it's approximately the same each time, because I have uptime running in a loop so that I can conveniently see when it dies. The very same tree boots and runs properly on a true BeagleBoard rev C. What's even more wierd is that even when sitting at the u-boot prompt before launching any kernel at all, the board does the same thing--- spontaneous reset after about four minutes. The client provided me the u-boot image, and it says it's a modified one from the OMAP3EVM--- it even provides that machine id. The above behavior makes me suspect hardware, but read on before you agree. Finally, the client provided me a kernel of unknown origin (it says it's a 2.6.29-rc2) that appears to run fine no hiccup at 4 minutes. Of course, that kernel doesn't have the features they need. I'm going over it now to see if there's a magic bit somewhere that mine is missing, but I'm at a bit of a loss to explain what I'm seeing right now. Anyone have any ideas? Bizzare. I suspect a watchdog timer of some kind, but I haven't got a clue which one. There is a register - PRM_RSTST (address 0x48307258) that you could read and maybe it will tell you what was the source of the reset. - Anand (BTW, nice to hear from you again, Gary! It's been a while.) b.g. -- Bill Gatliff b...@billgatliff.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: looking for presence of PMN interrupt in OMAP3530
* Gabi Voiculescu boy3d...@yahoo.com [091027 13:24]: Hello. I am working on porting a piece of code that makes use of irq on top of the performance counters (PMN) present in the OMAP3530's Cortex A8 MPU. This code is ported from an armv6 platform (arm1176 cpu). On the original platform (pb1176) the interrupt number into the IC was known from the documentation (39). I am unable to find the interrupt number for the performance counters and can not believe the TI people left the line unconnected to the GIC when they build the OMAP3530. I have searched in the TI documentation: Interrupt table (starting on page 1074 in http://focus.ti.com/lit/ug/spruff6b/spruff6b.pdf ) for a suitable entry but did not find it. I have tried to program a counter overflow and unmask the first 4 IRQs in the MPU in the hope that one of these is the PMU irq, again without success. *** Did anybody get into this documentation problem? Did he find a fix for it? Is there a PMN interrupt in the OMAP3530 IC Interrupt table? Please take a look at arch/arm/oprofile/op_model_v7.c. Also search the mailing lists regarding the Cortex bug on the performance counter interrupt, basically the interrupt stops happening after some usage. 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: Restart after 4 min of operation?
Gadiyar, Anand wrote: I suspect a watchdog timer of some kind, but I haven't got a clue which one. Turns out I had disabled watchdog timer support in my kernel. Re-enabling it seems to have addressed the problem--- the system has run for more than 5 minutes now. :) Apparently, the default for the OMAP watchdog timer is armed at reset? Interesting. b.g. -- Bill Gatliff b...@billgatliff.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 3/8] omap: zoom2: split baord file for reuse
Pandita, Vikram had written, on 11/03/2009 03:20 PM, the following:
Please fix subject typo:
[PATCH 3/8] omap: zoom2: split baord file for reuse
board
[...]
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
new file mode 100755
index 000..c799eca
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
generic - zoom Vs LDP.. Vs Zoom2 Vs Zoom3 naming conventions.. are we
saying we dont care about LDP anymore? all zooms are zoom2 or zoom3?
[...]
+
+//static struct twl4030_gpio_platform_data zoom_gpio_data = {
+// .gpio_base = OMAP_MAX_GPIO_LINES,
+// .irq_base = TWL4030_GPIO_IRQ_BASE,
+// .irq_end= TWL4030_GPIO_IRQ_END,
+// .pulldowns = BIT(0) | BIT(1) | BIT(2) | BIT(3)
+// | BIT(4) | BIT(5)
+// | BIT(8) | BIT(9) | BIT(10) | BIT(11)
+// | BIT(12) | BIT(13) | BIT(14) | BIT(15)
+// | BIT(16) | BIT(17) ,
+// .setup = zoom_twlgpio_setup,
+//};
NAK to //
+static struct twl4030_gpio_platform_data zoom_gpio_data = {
+ .gpio_base = OMAP_MAX_GPIO_LINES,
+ .irq_base = TWL4030_GPIO_IRQ_BASE,
+ .irq_end= TWL4030_GPIO_IRQ_END,
+ .setup = zoom_twl_gpio_setup,
+};
+
+static struct twl4030_usb_data zoom_usb_data = {
+ .usb_mode = T2_USB_MODE_ULPI,
+};
+
+/* TODO: enable T2 scripts */
+#if 0
NAK to #if 0 - introduce seperately if not operational.
[...]
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
old mode 100644
new mode 100755
index 4ad9b94..abcc1ae
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -1,8 +1,6 @@
/*
* Copyright (C) 2009 Texas Instruments Inc.
- * Mikkel Christensen m...@ti.com
*
- * Modified from mach-omap2/board-ldp.c
[Should we loose the history?]
[...]
-static void __init omap_zoom2_init_irq(void)
+static void __init omap_zoom_init_irq(void)
Question on naming.. as raised above.
[...]
--
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
Hang in usb_musb_init() with 2.6.32-rc5?
Guys: I'm back! :) This time, it's because my Beagleboard-like platform hangs hard during boot if I call usb_musb_init(). There are more differences between my platform and Beagleboard in this area, namely that I'm using a different USB transceiver and I'm on hs0. But why would the platform hang hard during boot? Here are what I think are the relevant parts of my config: CONFIG_SND_USB=y # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_CAIAQ is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_MUSB_HDRC=y CONFIG_USB_MUSB_SOC=y # OMAP 343x high speed USB support CONFIG_USB_MUSB_HOST=y # CONFIG_USB_MUSB_PERIPHERAL is not set # CONFIG_USB_MUSB_OTG is not set CONFIG_USB_MUSB_HDRC_HCD=y # CONFIG_MUSB_PIO_ONLY is not set CONFIG_USB_INVENTRA_DMA=y CONFIG_USB_MUSB_DEBUG=y CONFIG_NOP_USB_XCEIV=y I also created some new mux entries that I need: omap_cfg_reg(R21_3430_USB0HS_PHY_CLK); omap_cfg_reg(R23_3430_USB0HS_PHY_STP); omap_cfg_reg(P23_3430_USB0HS_PHY_DIR); omap_cfg_reg(R22_3430_USB0HS_PHY_NXT); omap_cfg_reg(T24_3430_USB0HS_PHY_D0); omap_cfg_reg(T23_3430_USB0HS_PHY_D1); omap_cfg_reg(U24_3430_USB0HS_PHY_D2); omap_cfg_reg(U23_3430_USB0HS_PHY_D3); omap_cfg_reg(W24_3430_USB0HS_PHY_D4); omap_cfg_reg(V23_3430_USB0HS_PHY_D5); omap_cfg_reg(W23_3430_USB0HS_PHY_D6); omap_cfg_reg(T22_3430_USB0HS_PHY_D7); I'm even doing this, which I'm not sure is necessary: ick = clk_get(NULL, ick); if (ick) clk_enable(ick); ... usb_musb_init(); ... Any ideas? Thanks!! b.g. -- Bill Gatliff b...@billgatliff.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 7/8] omap: 3630sdp: introduce 3630 sdp board support
Vikram Pandita had written, on 11/03/2009 03:20 PM, the following:
Add 3630SDP board support
The board shares the same peripherals as a zoom2 main.
So reuse the peripheral file of zoom platform.
The RAM part is Hynix memory as as in zoom3.
would be great to add more details on this.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/Makefile|3 +
arch/arm/mach-omap2/board-3630sdp.c | 96 +++
3 files changed, 103 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 9824775..83551a8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -105,6 +105,10 @@ config MACH_OMAP_ZOOM3
bool OMAP3630 Zoom3 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_OMAP_3630SDP
+ bool OMAP3630 SDP board
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 712e7fc..90cf2cc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -79,6 +79,9 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
+ board-zoom-peripherals.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
mmc-twl4030.o
diff --git a/arch/arm/mach-omap2/board-3630sdp.c b/arch/arm/mach-omap2/board-3630sdp.c
new file mode 100755
index 000..450fcdd
--- /dev/null
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/gpio.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include plat/board.h
+#include plat/gpmc-smc91x.h
+#include plat/mux.h
+#include plat/usb.h
+
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
+static struct omap_smc91x_platform_data board_smc91x_data = {
+ .cs = 3,
+ .flags = GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL,
+};
+
+static void __init board_smc91x_init(void)
+{
+ board_smc91x_data.gpio_irq = 158;
+ gpmc_smc91x_init(board_smc91x_data);
+}
+#else
+static inline void board_smc91x_init(void)
+{
+}
+#endif
+
+static void enable_board_wakeup_source(void)
+{
+ omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+}
+
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = 126,
+ .reset_gpio_port[1] = 61,
+ .reset_gpio_port[2] = -EINVAL
+};
+
+static void __init omap_sdp_map_io(void)
+{
+ omap2_set_globals_343x();
+ omap2_map_common_io();
+}
+
+static struct omap_board_config_kernel sdp_config[] __initdata = {
+};
EOL?
+static void __init omap_sdp_init_irq(void)
+{
+ omap_board_config = sdp_config;
+ omap_board_config_size = ARRAY_SIZE(sdp_config);
+ omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+extern void __init zoom_peripherals_init(void);
+
+static void __init omap_sdp_init(void)
+{
+zoom_peripherals_init();
+ board_smc91x_init();
+ enable_board_wakeup_source();
+ usb_ehci_init(ehci_pdata);
+}
+
+MACHINE_START(OMAP_3630SDP, OMAP 3630SDP board)
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap_sdp_map_io,
+ .init_irq = omap_sdp_init_irq,
+ .init_machine = omap_sdp_init,
+ .timer = omap_timer,
+MACHINE_END
nice and simple :).. thanks..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hang in usb_musb_init() with 2.6.32-rc5?
Hi, On Tue, Nov 03, 2009 at 11:28:04PM +0100, ext Bill Gatliff wrote: I'm back! :) This time, it's because my Beagleboard-like platform hangs hard during boot if I call usb_musb_init(). There are more differences between my platform and Beagleboard in this area, namely that I'm using a different USB transceiver and I'm on hs0. But why would the platform hang hard during boot? Here are what I think are the relevant parts of my config: CONFIG_SND_USB=y # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_CAIAQ is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_OXU210HP_HCD is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set # CONFIG_USB_ISP1362_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_MUSB_HDRC=y CONFIG_USB_MUSB_SOC=y # OMAP 343x high speed USB support CONFIG_USB_MUSB_HOST=y # CONFIG_USB_MUSB_PERIPHERAL is not set # CONFIG_USB_MUSB_OTG is not set CONFIG_USB_MUSB_HDRC_HCD=y # CONFIG_MUSB_PIO_ONLY is not set CONFIG_USB_INVENTRA_DMA=y CONFIG_USB_MUSB_DEBUG=y CONFIG_NOP_USB_XCEIV=y I also created some new mux entries that I need: omap_cfg_reg(R21_3430_USB0HS_PHY_CLK); omap_cfg_reg(R23_3430_USB0HS_PHY_STP); omap_cfg_reg(P23_3430_USB0HS_PHY_DIR); omap_cfg_reg(R22_3430_USB0HS_PHY_NXT); omap_cfg_reg(T24_3430_USB0HS_PHY_D0); omap_cfg_reg(T23_3430_USB0HS_PHY_D1); omap_cfg_reg(U24_3430_USB0HS_PHY_D2); omap_cfg_reg(U23_3430_USB0HS_PHY_D3); omap_cfg_reg(W24_3430_USB0HS_PHY_D4); omap_cfg_reg(V23_3430_USB0HS_PHY_D5); omap_cfg_reg(W23_3430_USB0HS_PHY_D6); omap_cfg_reg(T22_3430_USB0HS_PHY_D7); I'm even doing this, which I'm not sure is necessary: ick = clk_get(NULL, ick); if (ick) clk_enable(ick); ... usb_musb_init(); ... Any ideas? Thanks!! test with omap-debug branch, enable CONFIG_LL_DEBUG and see what's going on. I'm guessing you didn't enable any transceiver driver and you're getting an oops. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] omap: zoom3: introduce zoom3 board support
Pandita, Vikram had written, on 11/03/2009 03:20 PM, the following:
Zoom3 is the next versoin of Zoom2 board.
There has been a silicon update from zoom2 to zoom3.
Zoom2 has OMAP34xx
Zoom3 has OMAP3630
Zoom3 = OMAP3630 SOM board + same zoom2 main board + same debugboard
Zoom3 has a different SDRAM part from Hynix
Zoom2 had SDRAM part from micron
would have been great to get more details on zoom3.
Reuse the zoom2 files as much for zoom3, as at board level,
there is no change at all.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |4 +
arch/arm/mach-omap2/board-zoom3.c | 59
arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 54 ++
4 files changed, 121 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/mach-omap2/board-zoom3.c
create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8685df5..9824775 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -101,6 +101,10 @@ config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_OMAP_ZOOM3
+ bool OMAP3630 Zoom3 board
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4d66b42..712e7fc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -75,6 +75,10 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2)+=
board-zoom2.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-peripherals.o \
+ mmc-twl4030.o \
+ board-zoom-debugboard.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
mmc-twl4030.o
diff --git a/arch/arm/mach-omap2/board-zoom3.c b/arch/arm/mach-omap2/board-zoom3.c
new file mode 100755
index 000..aebe7b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/gpio.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include plat/board.h
+
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+static void __init omap_zoom_map_io(void)
+{
+ omap2_set_globals_343x();
+ omap2_map_common_io();
+}
+
+static struct omap_board_config_kernel zoom_config[] __initdata = {
+};
EOL?
+static void __init omap_zoom_init_irq(void)
+{
+ omap_board_config = zoom_config;
+ omap_board_config_size = ARRAY_SIZE(zoom_config);
+ omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+extern int __init omap_zoom2_debugboard_init(void);
+extern void __init zoom_peripherals_init(void);
+
+static void __init omap_zoom_init(void)
+{
+zoom_peripherals_init();
- is that spaces here? could you checkpatch please?
+ omap_zoom2_debugboard_init();
+}
+
+MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap_zoom_map_io,
+ .init_irq = omap_zoom_init_irq,
+ .init_machine = omap_zoom_init,
+ .timer = omap_timer,
+MACHINE_END
love a small board file such as this.. thanks..
diff --git a/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
new file mode 100644
index 000..c469c48
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
@@ -0,0 +1,54 @@
+/*
+ * SDRC register values for the Hynix H8MBX00U0MER-0EM
+ *
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Nicole Chalhoub / Vincent Bour
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8MBX00U0MER0EM
Re: Restart after 4 min of operation?
On 11/03/2009 11:37 AM, Bill Gatliff wrote: Gadiyar, Anand wrote: I suspect a watchdog timer of some kind, but I haven't got a clue which one. Turns out I had disabled watchdog timer support in my kernel. Re-enabling it seems to have addressed the problem--- the system has run for more than 5 minutes now. :) Apparently, the default for the OMAP watchdog timer is armed at reset? Interesting. I'm pretty sure this is set up in U-Boot. If I were you, I'd ask the customer for the U-Boot modifications so you can check what they've done. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe 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 v2] OMAP: DMA: Fix omapfb/lcdc on Amstrad Delta broken when PM set
Tuesday 03 November 2009 20:24:38 Janusz Krzysztofik napisał(a):
If there are still no comments, especially on the bug possible impact on
other OMAP1510 boards (or even OMAP1610 with internal LCD controller), then
Tony, please apply it as is. Until it is accepted, I am stuck with new
ams_delta_defconfig.
Tony,
Sorry, I've not checked for new mail before posting this one and missed your
acceptance for my idea of fixing all omap1510, not only ams_delta. If there
are no more comments, I'll submit v3 with cpu_is_omap1510() replacing
machine_is_ams_delta().
Thanks,
Janusz
--- linux-2.6.32-rc5/arch/arm/plat-omap/dma.c.orig2009-10-16
02:41:50.0 +0200 +++
linux-2.6.32-rc5/arch/arm/plat-omap/dma.c 2009-11-03 20:15:35.0
+0100 @@ -30,6 +30,7 @@
#include linux/irq.h
#include linux/io.h
+#include asm/mach-types.h
#include asm/system.h
#include mach/hardware.h
#include mach/dma.h
@@ -1110,6 +,14 @@ int omap_dma_running(void)
{
int lch;
+ /*
+ * On Amstrad Delta, the OMAP internal LCD controller will start the
+ * transfer when it gets enabled, so assume DMA running if LCD enabled.
+ */
+ if (machine_is_ams_delta())
+ if (omap_readw(0xfffec000 + 0x00) (1 0))
+ return 1;
+
/* Check if LCD DMA is running */
if (cpu_is_omap16xx())
if (omap_readw(OMAP1610_DMA_LCD_CCR) OMAP_DMA_CCR_EN)
--
To unsubscribe from this list: send the line unsubscribe 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: Restart after 4 min of operation?
Bill Gatliff wrote: Gadiyar, Anand wrote: I suspect a watchdog timer of some kind, but I haven't got a clue which one. Turns out I had disabled watchdog timer support in my kernel. Re-enabling it seems to have addressed the problem--- the system has run for more than 5 minutes now. :) Apparently, the default for the OMAP watchdog timer is armed at reset? Interesting. Just read a little on the MPU watchdog timer. It looks like the default values would have caused a reset after ~10s. So if your board is rebooting after 4 minutes, maybe the bootloader is turning it on? I've left a board on in the bootloader for hours without seeing a reboot, so either the bootloader I was using disables the watchdog, or it's not armed at reset. - Anand-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] PM: Making bdi threads non-freezable
On Tuesday 03 November 2009, Dasgupta, Romit wrote: Subject: Re: [PATCH 1/1] PM: Making bdi threads non-freezable On Monday 02 November 2009, Dasgupta, Romit wrote: Fixes the case when bdi threads are in the refrigerator but file system sync can happen after this. This is possible in MMC when CONFIG_MMC_UNSAFE_RESUME is not set. What's going to happen if we attemt to suspend the underlying block device(s) when the bdi thread are doing their job? Is there any synchronisation mechanism for that? There is no explicit synchronization AFAICT. However, it looks like the call to 'del_gendisk' would invoke 'sync_filesystem' down the line. 'sync_filesystem' would end with synchronous writes of inodes followed by a call to '__sync_blockddev'. However, that runs concurrently with respect to the suspend thread, AFAICS, so I wonder if there's anything to make the suspend thread wait for these operations to complete. If there's nothing like that, we can't really allow the bdi threads to run in parallel with the suspend thread. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe 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: EHCI on 2.6.32-rc5-git4 + patches
On 03/11/09 01:28, Robert Nelson wrote: I tried that and various others to get other than the hub enumerated, no luck so far with kernels I have built - no lights on the hub. I am now rebuilding after following the config for the working narcissus build, EHCI looks much the same, so here's hoping. I have another 16G MMC card I am trying on after cross compiling on a Fedora 12 VirtualBox VM. Regards Sid. Hi Sid I eventually got ehci working today on my tree on launchpad. But it's not that small of a patch once i added all the mach to plat changes... However, this commit made all the difference for me, it's currently missing from tmlind's tree, the beagleboard needs it to enable power to the ehci.. http://patchwork.kernel.org/patch/55703/ Regards, Thanks, I shall give it a try. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] DSPBRIDGE: Report and print errors during OFF
From 17a071cb82e3c9d69abc7366cc50ca316cc33e6b Mon Sep 17 00:00:00 2001
From: Ernest Ramos Falcon erne...@ti.com
Date: Fri, 30 Oct 2009 17:20:36 -0600
Subject: [PATCH 3/6] DSPBRIDGE: Report and print errors during OFF transitions
Report a PWRERR event (if enabled) during self hibernation
transitions, alos print if any of the suspend or self hibernation
routines fail.
Signed-off-by: Ernest Ramos Falcon erne...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 2eb379f..da7d4f3 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -114,6 +114,9 @@ DSP_STATUS handle_hibernation_fromDSP(struct
WMD_DEV_CONTEXT *pDevContext)
#ifdef CONFIG_PM
u16 timeout = PWRSTST_TIMEOUT / 10;
enum HW_PwrState_t pwrState;
+#ifdef BRIDGE_NTFY_PWRERR
+ struct DEH_MGR *hDehMgr;
+#endif /* #ifdef BRIDGE_NTFY_PWRERR */
#ifdef CONFIG_BRIDGE_DVFS
u32 opplevel;
struct IO_MGR *hIOMgr;
@@ -133,9 +136,12 @@ DSP_STATUS handle_hibernation_fromDSP(struct
WMD_DEV_CONTEXT *pDevContext)
pwrState);
}
if (timeout == 0) {
- DBG_Trace(DBG_LEVEL7, Timed out Waiting for DSP Off mode \n);
+ pr_err(Timed out waiting for DSP self hibernation\n);
+#ifdef BRIDGE_NTFY_PWRERR
+ DEV_GetDehMgr(pDevContext-hDevObject, hDehMgr);
+ WMD_DEH_Notify(hDehMgr, DSP_PWRERROR, 0);
+#endif /* #ifdef BRIDGE_NTFY_PWRERR */
status = WMD_E_TIMEOUT;
- return status;
} else {
/* Save mailbox settings */
status = HW_MBOX_saveSettings(pDevContext-dwMailBoxBase);
@@ -258,8 +264,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
}
if (!timeout) {
- DBG_Trace(DBG_LEVEL7, SleepDSP: Timed out Waiting for DSP
- STANDBY %x \n, pwrState);
+ pr_err(Timed out waiting for DSP suspend %x\n, pwrState);
#ifdef CONFIG_BRIDGE_NTFY_PWRERR
DEV_GetDehMgr(pDevContext-hDevObject, hDehMgr);
WMD_DEH_Notify(hDehMgr, DSP_PWRERROR, 0);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] OMAP3630 PM: Correct width for CLKSEL Fields
DPLL4 M, M3, M4, M5 and M6 field width has been increased by 1 bit in 3630.
This patch has changes to accommodate this in CM dynamically based on chip
version.
These changes are dependent on previous changes sent by
Nishant/Richard under subject (OMAP3:clk - introduce DPLL4 jtype support)
Signed-off-by: Vishwanath BS vishwanath...@ti.com
---
diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
index 7844c04..f47a91a
--- a/arch/arm/mach-omap2/clock34xx.c
+++ b/arch/arm/mach-omap2/clock34xx.c
@@ -97,6 +97,7 @@ struct omap_clk {
#define CK_343X(1 0)
#define CK_3430ES1 (1 1)
#define CK_3430ES2 (1 2)
+#define CK_363X(1 3)
static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_32k_fck, omap_32k_fck, CK_343X),
@@ -134,13 +135,13 @@ static struct omap_clk omap34xx_clks[] = {
CLK(NULL, omap_12m_fck, omap_12m_fck, CK_343X),
CLK(NULL, dpll4_m2_ck, dpll4_m2_ck, CK_343X),
CLK(NULL, dpll4_m2x2_ck, dpll4_m2x2_ck, CK_343X),
- CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_343X),
+ CLK(NULL, dpll4_m3_ck, dpll4_m3_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m3x2_ck, dpll4_m3x2_ck, CK_343X),
- CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_343X),
+ CLK(NULL, dpll4_m4_ck, dpll4_m4_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m4x2_ck, dpll4_m4x2_ck, CK_343X),
- CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_343X),
+ CLK(NULL, dpll4_m5_ck, dpll4_m5_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m5x2_ck, dpll4_m5x2_ck, CK_343X),
- CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_343X),
+ CLK(NULL, dpll4_m6_ck, dpll4_m6_ck, CK_343X | CK_363X),
CLK(NULL, dpll4_m6x2_ck, dpll4_m6x2_ck, CK_343X),
CLK(NULL, emu_per_alwon_ck, emu_per_alwon_ck, CK_343X),
CLK(NULL, dpll5_ck, dpll5_ck, CK_3430ES2),
@@ -1216,6 +1217,10 @@ int __init omap2_clk_init(void)
cpu_mask |= RATE_IN_3430ES2;
cpu_clkflg |= CK_3430ES2;
}
+ if (cpu_is_omap36xx()) {
+ dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
+ cpu_mask |= RATE_IN_363X;
+ }
}
clk_init(omap2_clk_functions);
@@ -1225,6 +1230,11 @@ int __init omap2_clk_init(void)
for (c = omap34xx_clks; c omap34xx_clks + ARRAY_SIZE(omap34xx_clks);
c++)
if (c-cpu cpu_clkflg) {
+ /* for 3630, change the mask value for clocks which are
+ marked as CK_363X*/
+ if (cpu_is_omap36xx())
+ if (c-cpu CK_363X)
+ c-lk.clk-clksel_mask =
c-lk.clk-clksel_mask_3630;
clkdev_add(c-lk);
clk_register(c-lk.clk);
omap2_init_clk_clkdm(c-lk.clk);
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index a1b3de7..3e9420f
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -243,6 +243,43 @@ static const struct clksel_rate div16_dpll_rates[] = {
{ .div = 0 }
};
+static const struct clksel_rate div32_dpll_rates[] = {
+ { .div = 1, .val = 1, .flags = RATE_IN_343X | DEFAULT_RATE },
+ { .div = 2, .val = 2, .flags = RATE_IN_343X },
+ { .div = 3, .val = 3, .flags = RATE_IN_343X },
+ { .div = 4, .val = 4, .flags = RATE_IN_343X },
+ { .div = 5, .val = 5, .flags = RATE_IN_343X },
+ { .div = 6, .val = 6, .flags = RATE_IN_343X },
+ { .div = 7, .val = 7, .flags = RATE_IN_343X },
+ { .div = 8, .val = 8, .flags = RATE_IN_343X },
+ { .div = 9, .val = 9, .flags = RATE_IN_343X },
+ { .div = 10, .val = 10, .flags = RATE_IN_343X },
+ { .div = 11, .val = 11, .flags = RATE_IN_343X },
+ { .div = 12, .val = 12, .flags = RATE_IN_343X },
+ { .div = 13, .val = 13, .flags = RATE_IN_343X },
+ { .div = 14, .val = 14, .flags = RATE_IN_343X },
+ { .div = 15, .val = 15, .flags = RATE_IN_343X },
+ { .div = 16, .val = 16, .flags = RATE_IN_343X },
+ { .div = 17, .val = 17, .flags = RATE_IN_363X },
+ { .div = 18, .val = 18, .flags = RATE_IN_363X },
+ { .div = 19, .val = 19, .flags = RATE_IN_363X },
+ { .div = 20, .val = 20, .flags = RATE_IN_363X },
+ { .div = 21, .val = 21, .flags = RATE_IN_363X },
+ { .div = 22, .val = 22, .flags = RATE_IN_363X },
+ { .div = 23, .val = 23, .flags = RATE_IN_363X },
+ { .div = 24, .val = 24, .flags = RATE_IN_363X },
+ { .div = 25, .val = 25, .flags = RATE_IN_363X },
+ { .div = 26, .val = 26, .flags = RATE_IN_363X },
+ { .div = 27, .val = 27, .flags = RATE_IN_363X },
+ { .div = 28, .val = 28, .flags = RATE_IN_363X },
+ { .div = 29,
[PATCH 0/6] dspbridge varoius fixes
Here are a few patches that are intended to be included in dspbridge branch: - omar --- Ernest Ramos Falcon (1): DSPBRIDGE: Report and print errors during OFF transitions Ernesto Ramos (1): DSPBRIDGE: Fix flood of messages from DSP Fernando Guzman (1): DSPBRIDGE: Set vdd1 to OPP3 always in DSP wake up Fernando Guzman Lugo (1): DSPBRIDGE: New state for DSP transition to hibernation Omar Ramirez Luna (2): DSPBRIDGE: Lower power transtion timeout DSPBRIDGE: Remove Warning pointer from integer w/o cast drivers/dsp/bridge/wmd/_tiomap_util.h |7 +++- drivers/dsp/bridge/wmd/msg_sm.c | 11 +- drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 56 -- 3 files changed, 51 insertions(+), 23 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3
Premi, Sanjeev pr...@ti.com writes: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Thursday, August 27, 2009 1:55 PM To: Reddy, Teerth Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3 Hi Teerth, Reddy, Teerth tee...@ti.com writes: From : Teerth Reddy tee...@ti.com This patch changes for setting the padconf value for sys_nirq line which is connected to T2 INTR1. This will fix the T2 keypad wakeup issue on OMAP3 SDP. Signed-off-by: Teerth Reddy tee...@ti.com Patch looks good, thanks. I'll pull this into PM branch and queue in my PM fixes queue for next merge window. I did a minor update by adding a comment in the enable_board_wakeup_source function stating that this is the interrupt pin used for T2. Kevin Teerth, Kevin, Did you test it with OFF mode enabled? I tested on SDP, but not on omap3evm since that was the only board file touched by this patch. When I do echo 1 /sys/power/enable_off_mode I don't see resume on the omap3evm. Schematics for the keypad are/seem to be same for EVM and SDP. I'm guessing that it's because the patch from Teerth only muxes this pin for the SDP. I'm guessing that doing the same omap_cfg_reg in the OMAP3EVM board file will get this working. 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 2/8] omap: DEBUG_LL: allow no omap uart configuration
Vikram Pandita had written, on 11/03/2009 03:20 PM, the following: [...] diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h index e22f575..49b38f0 100644 --- a/arch/arm/plat-omap/include/plat/uncompress.h +++ b/arch/arm/plat-omap/include/plat/uncompress.h @@ -44,8 +44,10 @@ static void putc(int c) uart = (volatile u8 *)(OMAP_UART3_BASE); #elif defined(CONFIG_OMAP_LL_DEBUG_UART2) uart = (volatile u8 *)(OMAP_UART2_BASE); -#else +#elif defined(CONFIG_OMAP_LL_DEBUG_UART1) uart = (volatile u8 *)(OMAP_UART1_BASE); +#elif defined(CONFIG_OMAP_LL_DEBUG_NONE) + return; what is the default? an #else missing? maybe, we might want to use: #else return; also I am not clear about #ifdef CONFIG_MACH_OMAP_PALMTE return #endif Vs this - should'nt PALMTE also use this instead? unrelated.. purpose of #ifdef CONFIG_ARCH_OMAP in arch/arm/plat-omap/include/plat/uncompress.h is'nt it already OMAP? -- 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 4/6] DSPBRIDGE: New state for DSP transition to hibernation
From da109a546582dac475510a74f050120b2ccbf486 Mon Sep 17 00:00:00 2001
From: Fernando Guzman Lugo x0095...@ti.com
Date: Fri, 30 Oct 2009 18:53:39 -0600
Subject: [PATCH 4/6] DSPBRIDGE: New state for DSP transition to hibernation
This patch fixes the issue when we are waiting for DSP
to go to hibernation and in that momment we send a mailbox
interrupt to the DSP, now there is a new state to avoid
sending messange when DSP tries to go to hibernation
Signed-off-by: Fernando Guzman Lugo x0095...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index da7d4f3..e793ad3 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -114,6 +114,7 @@ DSP_STATUS handle_hibernation_fromDSP(struct
WMD_DEV_CONTEXT *pDevContext)
#ifdef CONFIG_PM
u16 timeout = PWRSTST_TIMEOUT / 10;
enum HW_PwrState_t pwrState;
+ u32 prev_state;
#ifdef BRIDGE_NTFY_PWRERR
struct DEH_MGR *hDehMgr;
#endif /* #ifdef BRIDGE_NTFY_PWRERR */
@@ -124,6 +125,9 @@ DSP_STATUS handle_hibernation_fromDSP(struct
WMD_DEV_CONTEXT *pDevContext)
omap_dspbridge_dev-dev.platform_data;
#endif
+ prev_state = pDevContext-dwBrdState;
+ pDevContext-dwBrdState = BRD_SLEEP_TRANSITION;
+
HW_PWR_IVA2StateGet(pDevContext-prmbase, HW_PWR_DOMAIN_DSP,
pwrState);
/* Wait for DSP to move into OFF state */
@@ -136,6 +140,7 @@ DSP_STATUS handle_hibernation_fromDSP(struct
WMD_DEV_CONTEXT *pDevContext)
pwrState);
}
if (timeout == 0) {
+ pDevContext-dwBrdState = prev_state;
pr_err(Timed out waiting for DSP self hibernation\n);
#ifdef BRIDGE_NTFY_PWRERR
DEV_GetDehMgr(pDevContext-hDevObject, hDehMgr);
@@ -177,6 +182,7 @@ DSP_STATUS handle_hibernation_fromDSP(struct
WMD_DEV_CONTEXT *pDevContext)
status = DSP_SOK;
#endif /* CONFIG_BRIDGE_DVFS */
} else {
+ pDevContext-dwBrdState = prev_state;
DBG_Trace(DBG_LEVEL7,
handle_hibernation_fromDSP- FAILED\n);
}
@@ -198,6 +204,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
struct DEH_MGR *hDehMgr;
#endif /* CONFIG_BRIDGE_NTFY_PWRERR */
u16 timeout = PWRSTST_TIMEOUT / 10;
+ u32 prev_state;
enum HW_PwrState_t pwrState, targetPwrState;
DBG_Trace(DBG_LEVEL7, SleepDSP- Enter function \n);
@@ -223,6 +230,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
MBX_PM_DSPRETENTION);
targetPwrState = HW_PWR_STATE_RET;
}
+ prev_state = BRD_RUNNING;
break;
case BRD_RETENTION:
status = HW_MBOX_saveSettings(pDevContext-dwMailBoxBase);
@@ -232,6 +240,8 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
targetPwrState = HW_PWR_STATE_OFF;
} else
return DSP_SOK;
+
+ prev_state = BRD_RETENTION;
break;
case BRD_HIBERNATION:
case BRD_DSP_HIBERNATION:
@@ -248,7 +258,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
SleepDSP- Bridge in Illegal state\n);
return DSP_EFAIL;
}
-
+ pDevContext-dwBrdState = BRD_SLEEP_TRANSITION;
/* Get the PRCM DSP power domain status */
HW_PWR_IVA2StateGet(pDevContext-prmbase, HW_PWR_DOMAIN_DSP,
pwrState);
@@ -264,6 +274,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
}
if (!timeout) {
+ pDevContext-dwBrdState = prev_state;
pr_err(Timed out waiting for DSP suspend %x\n, pwrState);
#ifdef CONFIG_BRIDGE_NTFY_PWRERR
DEV_GetDehMgr(pDevContext-hDevObject, hDehMgr);
@@ -506,7 +517,8 @@ DSP_STATUS PostScale_DSP(struct WMD_DEV_CONTEXT
*pDevContext, IN void *pArgs)
voltage_domain, level);
if ((pDevContext-dwBrdState == BRD_HIBERNATION) ||
(pDevContext-dwBrdState == BRD_RETENTION) ||
- (pDevContext-dwBrdState == BRD_DSP_HIBERNATION)) {
+ (pDevContext-dwBrdState == BRD_DSP_HIBERNATION) ||
+ (pDevContext-dwBrdState == BRD_SLEEP_TRANSITION)) {
/* Update the OPP value in shared memory */
IO_SHMsetting(hIOMgr, SHM_CURROPP, level);
DBG_Trace(DBG_LEVEL7,
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
[PATCH] omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions (Re: [PATCH 3/5] omap: mux: Add new style pin multiplexing data for 34xx)
* Tony Lindgren t...@atomide.com [091103 08:44]:
* Mike Rapoport mike.rapop...@gmail.com [091102 23:10]:
On Mon, Nov 2, 2009 at 9:10 PM, Tony Lindgren t...@atomide.com wrote:
* Mike Rapoport m...@compulab.co.il [091101 02:30]:
Tony Lindgren wrote:
Add new style mux data for 34xx. This should also
work with 3630 easily by adding the processor subset
and ball data.
Note that this data is __initdata, and gets optimized
out if CONFIG_OMAP_MUX is not set. Also, the debug data
gets optimized out if CONFIG_DEBUG_FS is not set.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile | 4
arch/arm/mach-omap2/mux.h | 2
arch/arm/mach-omap2/mux34xx.c | 1552
+
arch/arm/mach-omap2/mux34xx.h | 352 +
4 files changed, 1910 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h
[ snip ]
+
+#define OMAP3_CONTROL_PADCONF_MUX_SIZE \
+ (OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET + 0x2)
What about adding defines for each possible mode configuration, except,
perhaps,
GPIO?
Yeah it would be nice to make it easy. How about someting like:
int __init omap_mux_init_by_name(char *name, int flags);
...
omap_mux_init_by_name(i2c1_scl, OMAP_PIN_INPUT_PULLUP);
Here's an experimental patch to replace the omap_cfg_reg() calls
for omap3. It at least seems to make the code more readable with
the gpio numbers and signal names :)
The arch/arm/plat-omap/i2c.c muxing needs to be implemented
under mach-omap2.
The functions are only stubs right now in the mux branch in the
linux-omap tree, so that's only compile tested right now..
Will repost the whole series once things are working properly
again.
Regards,
Tony
From 763a5474f2c304e1cc8f3f8ce805c1bb84bafece Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Tue, 3 Nov 2009 14:46:00 -0800
Subject: [PATCH] omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions
Replace omap_cfg_reg() with new style signal or gpio functions
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c
index 94d850d..dc1bbc1 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -482,7 +482,7 @@ static inline void board_smc91x_init(void)
static void enable_board_wakeup_source(void)
{
- omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+ omap_mux_init_signal(sys_nirq, OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP); /* T2 interrupt line (keypad) */
}
static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c
index 1143588..7acb3a2 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -469,7 +469,7 @@ static void __init cm_t35_init(void)
usb_musb_init();
- omap_cfg_reg(AF26_34XX_SYS_NIRQ);
+ omap_mux_init_signal(sys_nirq, OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
omap3_mux_init(board_mux, OMAP_MUX_ALL_DYNAMIC | OMAP_PACKAGE_CUS);
}
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 5bb096a..fb5f33a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -141,10 +141,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
if (system_rev = 0x20 system_rev = 0x34301000) {
- omap_cfg_reg(AG9_34XX_GPIO23);
+ omap_mux_init_gpio(23, OMAP_PIN_INPUT);
mmc[0].gpio_wp = 23;
} else {
- omap_cfg_reg(AH8_34XX_GPIO29);
+ omap_mux_init_gpio(29, OMAP_PIN_INPUT);
}
/* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
@@ -426,7 +426,7 @@ static void __init omap3_beagle_init(void)
ARRAY_SIZE(omap3_beagle_devices));
omap_serial_init();
- omap_cfg_reg(J25_34XX_GPIO170);
+ omap_mux_init_gpio(170, OMAP_PIN_INPUT);
gpio_request(170, DVI_nPD);
/* REVISIT leave DVI powered down until it's needed ... */
gpio_direction_output(170, true);
@@ -436,8 +436,8 @@ static void __init omap3_beagle_init(void)
omap3beagle_flash_init();
/* Ensure SDRC pins are mux'd for self-refresh */
- omap_cfg_reg(H16_34XX_SDRC_CKE0);
- omap_cfg_reg(H17_34XX_SDRC_CKE1);
+ omap_mux_init_signal(sdrc_cke0, OMAP_PIN_OUTPUT);
+ omap_mux_init_signal(sdrc_cke1, OMAP_PIN_OUTPUT);
omap3_mux_init(board_mux, OMAP_MUX_ALL_DYNAMIC | OMAP_PACKAGE_CBB);
}
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3evm.c
index 77b1a20..7ca673a 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -171,7 +171,7 @@ static int omap3evm_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned
Re: [PATCH] omap3: beagle: Fix USB host port power control
On 03/11/09 14:11, Koen Kooi wrote: Any comments on this, I need this on beagleboard to make ehci work. regards, Koen Op 24 okt 2009, om 09:59 heeft Jarkko Nikula het volgende geschreven: The host port power is enabled by driving the nEN_USB_PWR low as stated in the comment. This fix is originally from Steve Sakoman st...@sakoman.com. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Steve Sakoman st...@sakoman.com --- arch/arm/mach-omap2/board-omap3beagle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 6cb99f6..7ad9846 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -162,7 +162,7 @@ static int beagle_twl_gpio_setup(struct device *dev, /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */ gpio_request(gpio + TWL4030_GPIO_MAX, nEN_USB_PWR); -gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1); +gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0); /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */ gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1; -- 1.6.3.3 -- Certainly works on 2.6.32-rc5, all EHCI devices are now enumerated. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] omap: zoom2: split baord file for reuse
Split zoom2 board file into:
base board file and a board-zoom-peripherals.c file
that way the same peripherals file can be reused for: zoom3 and sdp3630
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-zoom-peripherals.c | 414 ++
arch/arm/mach-omap2/board-zoom2.c| 261 +---
3 files changed, 429 insertions(+), 247 deletions(-)
create mode 100755 arch/arm/mach-omap2/board-zoom-peripherals.c
mode change 100644 = 100755 arch/arm/mach-omap2/board-zoom2.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 03cb4fc..4d66b42 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
board-rx51-peripherals.o \
mmc-twl4030.o
obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \
+ board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
new file mode 100755
index 000..c799eca
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -0,0 +1,414 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ *
+ * Modified from mach-omap2/board-ldp.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/input/matrix_keypad.h
+#include linux/gpio.h
+#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+#include asm/mach/map.h
+
+#include plat/common.h
+#include plat/usb.h
+
+#include mmc-twl4030.h
+
+/* Zoom2 has Qwerty keyboard*/
+static int board_keymap[] = {
+ KEY(0, 0, KEY_E),
+ KEY(1, 0, KEY_R),
+ KEY(2, 0, KEY_T),
+ KEY(3, 0, KEY_HOME),
+ KEY(6, 0, KEY_I),
+ KEY(7, 0, KEY_LEFTSHIFT),
+ KEY(0, 1, KEY_D),
+ KEY(1, 1, KEY_F),
+ KEY(2, 1, KEY_G),
+ KEY(3, 1, KEY_SEND),
+ KEY(6, 1, KEY_K),
+ KEY(7, 1, KEY_ENTER),
+ KEY(0, 2, KEY_X),
+ KEY(1, 2, KEY_C),
+ KEY(2, 2, KEY_V),
+ KEY(3, 2, KEY_END),
+ KEY(6, 2, KEY_DOT),
+ KEY(7, 2, KEY_CAPSLOCK),
+ KEY(0, 3, KEY_Z),
+ KEY(1, 3, KEY_KPPLUS),
+ KEY(2, 3, KEY_B),
+ KEY(3, 3, KEY_F1),
+ KEY(6, 3, KEY_O),
+ KEY(7, 3, KEY_SPACE),
+ KEY(0, 4, KEY_W),
+ KEY(1, 4, KEY_Y),
+ KEY(2, 4, KEY_U),
+ KEY(3, 4, KEY_F2),
+ KEY(4, 4, KEY_VOLUMEUP),
+ KEY(6, 4, KEY_L),
+ KEY(7, 4, KEY_LEFT),
+ KEY(0, 5, KEY_S),
+ KEY(1, 5, KEY_H),
+ KEY(2, 5, KEY_J),
+ KEY(3, 5, KEY_F3),
+ KEY(5, 5, KEY_VOLUMEDOWN),
+ KEY(6, 5, KEY_M),
+ KEY(4, 5, KEY_ENTER),
+ KEY(7, 5, KEY_RIGHT),
+ KEY(0, 6, KEY_Q),
+ KEY(1, 6, KEY_A),
+ KEY(2, 6, KEY_N),
+ KEY(3, 6, KEY_BACKSPACE),
+ KEY(6, 6, KEY_P),
+ KEY(7, 6, KEY_UP),
+ KEY(6, 7, KEY_SELECT),
+ KEY(7, 7, KEY_DOWN),
+ KEY(0, 7, KEY_PROG1), /*MACRO 1 User defined */
+ KEY(1, 7, KEY_PROG2), /*MACRO 2 User defined */
+ KEY(2, 7, KEY_PROG3), /*MACRO 3 User defined */
+ KEY(3, 7, KEY_PROG4), /*MACRO 4 User defined */
+ 0
+};
+
+static struct matrix_keymap_data board_map_data = {
+ .keymap = board_keymap,
+ .keymap_size= ARRAY_SIZE(board_keymap),
+};
+
+static struct twl4030_keypad_data zoom_kp_twl4030_data = {
+ .keymap_data= board_map_data,
+ .rows = 8,
+ .cols = 8,
+ .rep= 1,
+};
+
+static struct twl4030_madc_platform_data zoom_madc_data = {
+ .irq_line = 1,
+};
+
+static struct twl4030_hsmmc_info mmc[] = {
+ {
+ .name = external,
+ .mmc= 1,
+ .wires = 4,
+ .cover_only = true,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .power_saving = true,
+ },
+ {
+ .name = internal,
+ .mmc= 2,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .nonremovable = true,
+ .power_saving = true,
+ },
+ {} /* Terminator */
+};
+
+static struct
zd1211 firmware on OMAP5912
Hello, I'm trying to get a Belkin F5D7050 USB wireless adapter to work with the OMAP5912 starter kit. I enabled the zd1211rw driver in the kernel (2.6.32-rc2-05967-gd350540), and it appears to recognize the device when I connect it. It shows up as wlan0 when I do iwconfig. The problem I'm having is that it doesn't seem to be able to find the firmware. I downloaded the firmware files from Sourceforge and unpacked them in /lib/firmware/zd1211. But when I try to bring the interface up with ifconfig, I get the following: / # ifconfig wlan0 up usb 1-1.2: firmware: requesting zd1211/zd1211b_ub usb 1-1.2: Could not load firmware file zd1211/zd1211b_ub. Error number -2 zd1211rw 1-1.2:1.0: couldn't load firmware. Error number -2 SIOCSIFFLAGS: No such file or directory This is the output from dmesg: zd1211rw 1-1.2:1.0: zd_usb_init_hw() usb 1-1.2: request_fw_file() fw name zd1211/zd1211b_ub usb 1-1.2: firmware: requesting zd1211/zd1211b_ub usb 1-1.2: Could not load firmware file zd1211/zd1211b_ub. Error number -2 zd1211rw 1-1.2:1.0: couldn't load firmware. Error number -2 I tried copying the zd1211 firmware folder to a couple of other directories, like /etc/firmware/ and /usr/lib/hotplug/firmware/, but that didn't seem to help. I also tried loading the firmware manually, with the following commands: echo 1 /sys/class/firmware/loading cat /lib/firmware/zd1211/zd1211b_ub /sys/class/firmware/data echo 1 /sys/class/firmware/loading But after the first line, I get the following: /bin/sh: cannot create /sys/class/firmware/loading: Directory nonexistent Is there some other directory that I should be putting the firmware files in? Or have I missed some crucial step along the way? Any help would be greatly appreciated. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] omap: zoom3: introduce zoom3 board support
Zoom3 is the next versoin of Zoom2 board.
There has been a silicon update from zoom2 to zoom3.
Zoom2 has OMAP34xx
Zoom3 has OMAP3630
Zoom3 = OMAP3630 SOM board + same zoom2 main board + same debugboard
Zoom3 has a different SDRAM part from Hynix
Zoom2 had SDRAM part from micron
Reuse the zoom2 files as much for zoom3, as at board level,
there is no change at all.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/Kconfig|4 +
arch/arm/mach-omap2/Makefile |4 +
arch/arm/mach-omap2/board-zoom3.c | 59
arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 54 ++
4 files changed, 121 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/mach-omap2/board-zoom3.c
create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8685df5..9824775 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -101,6 +101,10 @@ config MACH_CM_T35
bool CompuLab CM-T35 module
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_OMAP_ZOOM3
+ bool OMAP3630 Zoom3 board
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4d66b42..712e7fc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -75,6 +75,10 @@ obj-$(CONFIG_MACH_OMAP_ZOOM2)+=
board-zoom2.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
+ board-zoom-peripherals.o \
+ mmc-twl4030.o \
+ board-zoom-debugboard.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
mmc-twl4030.o
diff --git a/arch/arm/mach-omap2/board-zoom3.c
b/arch/arm/mach-omap2/board-zoom3.c
new file mode 100755
index 000..aebe7b8
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom3.c
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/gpio.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include plat/board.h
+
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+static void __init omap_zoom_map_io(void)
+{
+ omap2_set_globals_343x();
+ omap2_map_common_io();
+}
+
+static struct omap_board_config_kernel zoom_config[] __initdata = {
+};
+static void __init omap_zoom_init_irq(void)
+{
+ omap_board_config = zoom_config;
+ omap_board_config_size = ARRAY_SIZE(zoom_config);
+ omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+extern int __init omap_zoom2_debugboard_init(void);
+extern void __init zoom_peripherals_init(void);
+
+static void __init omap_zoom_init(void)
+{
+zoom_peripherals_init();
+ omap_zoom2_debugboard_init();
+}
+
+MACHINE_START(OMAP_ZOOM3, OMAP Zoom3 board)
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap_zoom_map_io,
+ .init_irq = omap_zoom_init_irq,
+ .init_machine = omap_zoom_init,
+ .timer = omap_timer,
+MACHINE_END
diff --git a/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
new file mode 100644
index 000..c469c48
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h
@@ -0,0 +1,54 @@
+/*
+ * SDRC register values for the Hynix H8MBX00U0MER-0EM
+ *
+ * Copyright (C) 2008-2009 Texas Instruments, Inc.
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Nicole Chalhoub / Vincent Bour
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8MBX00U0MER0EM
+#define ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8MBX00U0MER0EM
+
+#include plat/sdrc.h
+
+/* Hynix H8MBX00U0MER-0EM */
+static struct omap_sdrc_params h8mbx00u0mer0em_sdrc_params[] = {
+ [0] = {
+ .rate= 2,
+
[PATCH 6/6] DSPBRIDGE: Remove Warning pointer from integer w/o cast
warning: initialization makes pointer from integer without a cast
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 34e5a74..9324f1e 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -798,7 +798,8 @@ DSP_STATUS tiomap3430_bump_dsp_opp_level(void)
{
#ifdef CONFIG_BRIDGE_DVFS
struct WMD_DEV_CONTEXT *dwContext;
- struct DEV_OBJECT *hDevObject = DRV_GetFirstDevObject();
+ struct DEV_OBJECT *hDevObject =
+ (struct DEV_OBJECT *)DRV_GetFirstDevObject();
struct dspbridge_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] DSPBRIDGE: Set vdd1 to OPP3 always in DSP wake up
From 424104463b418172a2c7c66c0b9ace83681b1fb9 Mon Sep 17 00:00:00 2001
From: Fernando Guzman x0095...@ti.com
Date: Thu, 15 Oct 2009 20:09:36 -0500
Subject: [PATCH 5/6] DSPBRIDGE: Set vdd1 to OPP3 always in DSP wake up
This patch set the vdd1 to OPP3 always in DSP wake up.
Signed-off-by: Fernando Guzman x0095...@ti.com
---
drivers/dsp/bridge/wmd/tiomap3430_pwr.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index e793ad3..34e5a74 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -797,24 +797,24 @@ void DSPClkWakeupEventCtrl(u32 ClkId, bool enable)
DSP_STATUS tiomap3430_bump_dsp_opp_level(void)
{
#ifdef CONFIG_BRIDGE_DVFS
- u32 opplevel;
-
+ struct WMD_DEV_CONTEXT *dwContext;
+ struct DEV_OBJECT *hDevObject = DRV_GetFirstDevObject();
struct dspbridge_platform_data *pdata =
omap_dspbridge_dev-dev.platform_data;
- if (pdata-dsp_get_opp pdata-dsp_set_min_opp)
- opplevel = (*pdata-dsp_get_opp)();
+ if (DSP_FAILED(DEV_GetWMDContext(hDevObject, dwContext)))
+ return DSP_EFAIL;
+ if (dwContext-dwBrdState == BRD_DSP_HIBERNATION ||
+ dwContext-dwBrdState == BRD_HIBERNATION) {
/*
-* If OPP is at minimum level, increase it before waking
-* up the DSP.
+* Increase OPP before waking up the DSP.
*/
- if (opplevel min_active_opp) {
- (*pdata-dsp_set_min_opp)(min_active_opp);
- DBG_Trace(DBG_LEVEL7, CHNLSM_InterruptDSP: Setting
- the vdd1 constraint level to %d before
- waking DSP \n, min_active_opp);
- }
+ (*pdata-dsp_set_min_opp)(min_active_opp);
+ DBG_Trace(DBG_LEVEL7, CHNLSM_InterruptDSP: Setting
+ the vdd1 constraint level to %d before
+ waking DSP \n, min_active_opp);
+ }
#endif
return DSP_SOK;
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] omap: 3630sdp: introduce 3630 sdp board support
Add 3630SDP board support
The board shares the same peripherals as a zoom2 main.
So reuse the peripheral file of zoom platform.
The RAM part is Hynix memory as as in zoom3.
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/Makefile|3 +
arch/arm/mach-omap2/board-3630sdp.c | 96 +++
3 files changed, 103 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/mach-omap2/board-3630sdp.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 9824775..83551a8 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -105,6 +105,10 @@ config MACH_OMAP_ZOOM3
bool OMAP3630 Zoom3 board
depends on ARCH_OMAP3 ARCH_OMAP34XX
+config MACH_OMAP_3630SDP
+ bool OMAP3630 SDP board
+ depends on ARCH_OMAP3 ARCH_OMAP34XX
+
config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 712e7fc..90cf2cc 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -79,6 +79,9 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \
board-zoom-peripherals.o \
mmc-twl4030.o \
board-zoom-debugboard.o
+obj-$(CONFIG_MACH_OMAP_3630SDP)+= board-3630sdp.o \
+ board-zoom-peripherals.o \
+ mmc-twl4030.o
obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
mmc-twl4030.o
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
new file mode 100755
index 000..450fcdd
--- /dev/null
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2009 Texas Instruments Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/gpio.h
+
+#include asm/mach-types.h
+#include asm/mach/arch.h
+
+#include plat/common.h
+#include plat/board.h
+#include plat/gpmc-smc91x.h
+#include plat/mux.h
+#include plat/usb.h
+
+#include sdram-hynix-h8mbx00u0mer-0em.h
+
+#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
+static struct omap_smc91x_platform_data board_smc91x_data = {
+ .cs = 3,
+ .flags = GPMC_MUX_ADD_DATA | IORESOURCE_IRQ_LOWLEVEL,
+};
+
+static void __init board_smc91x_init(void)
+{
+ board_smc91x_data.gpio_irq = 158;
+ gpmc_smc91x_init(board_smc91x_data);
+}
+#else
+static inline void board_smc91x_init(void)
+{
+}
+#endif
+
+static void enable_board_wakeup_source(void)
+{
+ omap_cfg_reg(AF26_34XX_SYS_NIRQ); /* T2 interrupt line (keypad) */
+}
+
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = 126,
+ .reset_gpio_port[1] = 61,
+ .reset_gpio_port[2] = -EINVAL
+};
+
+static void __init omap_sdp_map_io(void)
+{
+ omap2_set_globals_343x();
+ omap2_map_common_io();
+}
+
+static struct omap_board_config_kernel sdp_config[] __initdata = {
+};
+static void __init omap_sdp_init_irq(void)
+{
+ omap_board_config = sdp_config;
+ omap_board_config_size = ARRAY_SIZE(sdp_config);
+ omap2_init_common_hw(h8mbx00u0mer0em_sdrc_params,
+ h8mbx00u0mer0em_sdrc_params);
+ omap_init_irq();
+ omap_gpio_init();
+}
+
+extern void __init zoom_peripherals_init(void);
+
+static void __init omap_sdp_init(void)
+{
+zoom_peripherals_init();
+ board_smc91x_init();
+ enable_board_wakeup_source();
+ usb_ehci_init(ehci_pdata);
+}
+
+MACHINE_START(OMAP_3630SDP, OMAP 3630SDP board)
+ .phys_io= 0x4800,
+ .io_pg_offst= ((0xfa00) 18) 0xfffc,
+ .boot_params= 0x8100,
+ .map_io = omap_sdp_map_io,
+ .init_irq = omap_sdp_init_irq,
+ .init_machine = omap_sdp_init,
+ .timer = omap_timer,
+MACHINE_END
--
1.6.5.1.69.g36942
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 1/6] DSPBRIDGE: Lower power transtion timeout
Fixing subject this time.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Ramirez Luna, Omar
Sent: Tuesday, November 03, 2009 5:08 PM
To: Linux OMAP
Subject: [PATCH 1/6] DSPBRIDGE: Lower power transtion timeout
Given system latency and low timer resolutions, device
driver timeout needs to be cut to report any error, while
transitioning to OFF mode.
In the best case scenario, the transition should be immediate,
but in the worst scenario it could take up to ~400 ms,
even tough the driver defines the waiting loop to be 200 ms.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/_tiomap_util.h |7 +--
drivers/dsp/bridge/wmd/tiomap3430_pwr.c |2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/_tiomap_util.h
b/drivers/dsp/bridge/wmd/_tiomap_util.h
index 8f1e515..bd1b571 100644
--- a/drivers/dsp/bridge/wmd/_tiomap_util.h
+++ b/drivers/dsp/bridge/wmd/_tiomap_util.h
@@ -31,8 +31,11 @@
/* Time out Values in uSeconds*/
#define TIHELEN_ACKTIMEOUT 1
-/* Time out for power state transition (in msecs) */
-#define PWRSTST_TIMEOUT1500
+/*
+ * Time out for power state transition (in msecs), due to system
+ * latencies and HZ resolution this timer can vary.
+ */
+#define PWRSTST_TIMEOUT200
/* Time delay for HOM-SAM transition. */
#define WAIT_SAM 100/* in usec (1000 millisec) */
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 0c2f2fd..2eb379f 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -248,7 +248,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
pwrState);
/* Wait for DSP to move into target power state */
- while ((pwrState != targetPwrState) --timeout) {
+ while ((pwrState != targetPwrState) timeout--) {
if (msleep_interruptible(10)) {
pr_err(Waiting for DSP to Suspend interrupted\n);
return DSP_EFAIL;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH v2] OMAP: DMA: Fix omapfb/lcdc on Amstrad Delta broken when PM set
With CONFIG_PM=y, the omapfb/lcdc device on Amstrad Delta, after initially
starting correctly, breaks with the following error messages:
omapfb omapfb: resetting (status 0xff96,reset count 1)
...
omapfb omapfb: resetting (status 0xff96,reset count 100)
omapfb omapfb: too many reset attempts, giving up.
Looking closer at this I have found that it had been broken almost 2 years ago
with commit 2418996e3b100114edb2ae110d5d4acb928909d2, PM fixes for OMAP1.
The definite reason for broken omapfb/lcdc behavoiur in PM mode
appeared to be ARM_IDLECT1:IDLIF_ARM (bit 6) put into idle regardless of LCD
DMA possibly running. The bit were set based on return value of the
omap_dma_running() function that did not check for dedicated LCD DMA
channel status. The patch below fixes this.
Created and tested against linux-2.6.32-rc5
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
If there are still no comments, especially on the bug possible impact on other
OMAP1510 boards (or even OMAP1610 with internal LCD controller), then Tony,
please apply it as is. Until it is accepted, I am stuck with new
ams_delta_defconfig.
Thanks,
Janusz
--- linux-2.6.32-rc5/arch/arm/plat-omap/dma.c.orig 2009-10-16
02:41:50.0 +0200
+++ linux-2.6.32-rc5/arch/arm/plat-omap/dma.c 2009-11-03 20:15:35.0
+0100
@@ -30,6 +30,7 @@
#include linux/irq.h
#include linux/io.h
+#include asm/mach-types.h
#include asm/system.h
#include mach/hardware.h
#include mach/dma.h
@@ -1110,6 +,14 @@ int omap_dma_running(void)
{
int lch;
+ /*
+* On Amstrad Delta, the OMAP internal LCD controller will start the
+* transfer when it gets enabled, so assume DMA running if LCD enabled.
+*/
+ if (machine_is_ams_delta())
+ if (omap_readw(0xfffec000 + 0x00) (1 0))
+ return 1;
+
/* Check if LCD DMA is running */
if (cpu_is_omap16xx())
if (omap_readw(OMAP1610_DMA_LCD_CCR) OMAP_DMA_CCR_EN)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 2/6] DSPBRIDGE: Fix flood of messages from DSP
On behalf of Ernesto.
This patch fixes an issue in dspbridge when several messages are sent
in one shot but MPU was only able to process one message.
Signed-off-by: Ernesto Ramos erne...@ti.com
Signed-off by: Bhavin Shah bs...@ti.com
---
drivers/dsp/bridge/wmd/msg_sm.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 0231f65..16eab74 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -314,6 +314,11 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
(struct LST_ELEM *)pMsgFrame);
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
+ else {
+ NTFY_Notify(hMsgQueue-hNtfy,
+ DSP_NODEMESSAGEREADY);
+ SYNC_SetEvent(hMsgQueue-hSyncEvent);
+ }
fGotMsg = true;
}
@@ -361,9 +366,11 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
}
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
- if (!LST_IsEmpty(hMsgQueue-msgUsedList))
+ if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
+ NTFY_Notify(hMsgQueue-hNtfy,
+ DSP_NODEMESSAGEREADY);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
-
+ }
/* Exit critical section */
(void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] RFC: introduce 3630 boards
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Subject: [PATCH 0/8] RFC: introduce 3630 boards Introducing 3630 boards: zoom3 and sdp3630 These patches are in my git tree at: git://dev.omapzoom.org/pub/scm/integration/kernel-omap3.git zoom3 Sorry for the wrong tree. This is the right one: git://dev.omapzoom.org/pub/scm/vikram/omap3.git zoom3 this is to help ease cloning in case required. The peripherals are very similar for the two bards as per this discussion: http://marc.info/?l=linux-omapm=125676595710748w=2 So maximum reuse is done for the board files for zoom3 and sdp3630 Review comments incorporated: http://marc.info/?l=linux-omapm=125632676504364w=2 http://marc.info/?l=linux-omapm=125632720804869w=2 http://marc.info/?l=linux-omapm=125633994320138w=2 Vikram Pandita (8): omap: 3630: update is_chip variable omap: DEBUG_LL: allow no omap uart configuration omap: zoom2: split baord file for reuse omap: zoom2: update defconfig omap: zoom3: introduce zoom3 board support omap: zoom3: defconfig creation omap: 3630sdp: introduce 3630 sdp board support omap: 3630sdp: defconfig creation arch/arm/configs/omap_3630sdp_defconfig| 1606 arch/arm/configs/omap_zoom2_defconfig | 231 ++-- arch/arm/configs/omap_zoom3_defconfig | 1605 +++ arch/arm/mach-omap2/Kconfig|8 + arch/arm/mach-omap2/Makefile |8 + arch/arm/mach-omap2/board-3630sdp.c| 96 ++ arch/arm/mach-omap2/board-zoom-peripherals.c | 414 + arch/arm/mach-omap2/board-zoom2.c | 261 +--- arch/arm/mach-omap2/board-zoom3.c | 59 + arch/arm/mach-omap2/id.c |2 + arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 54 + arch/arm/plat-omap/Kconfig |3 + arch/arm/plat-omap/include/plat/cpu.h |7 +- arch/arm/plat-omap/include/plat/uncompress.h |4 +- 14 files changed, 4018 insertions(+), 340 deletions(-) create mode 100644 arch/arm/configs/omap_3630sdp_defconfig create mode 100644 arch/arm/configs/omap_zoom3_defconfig create mode 100755 arch/arm/mach-omap2/board-3630sdp.c create mode 100755 arch/arm/mach-omap2/board-zoom-peripherals.c mode change 100644 = 100755 arch/arm/mach-omap2/board-zoom2.c create mode 100755 arch/arm/mach-omap2/board-zoom3.c create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH 2/6] DSPBRIDGE: Fix flood of messages from DSP
From: Ernesto Ramos erne...@ti.com
This patch fixes an issue in dspbridge when several messages are sent
in one shot but MPU was only able to process one message.
Signed-off-by: Ernesto Ramos erne...@ti.com
Signed-off by: Bhavin Shah bs...@ti.com
---
drivers/dsp/bridge/wmd/msg_sm.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/msg_sm.c b/drivers/dsp/bridge/wmd/msg_sm.c
index 0231f65..16eab74 100644
--- a/drivers/dsp/bridge/wmd/msg_sm.c
+++ b/drivers/dsp/bridge/wmd/msg_sm.c
@@ -314,6 +314,11 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
(struct LST_ELEM *)pMsgFrame);
if (LST_IsEmpty(hMsgQueue-msgUsedList))
SYNC_ResetEvent(hMsgQueue-hSyncEvent);
+ else {
+ NTFY_Notify(hMsgQueue-hNtfy,
+ DSP_NODEMESSAGEREADY);
+ SYNC_SetEvent(hMsgQueue-hSyncEvent);
+ }
fGotMsg = true;
}
@@ -361,9 +366,11 @@ DSP_STATUS WMD_MSG_Get(struct MSG_QUEUE *hMsgQueue,
}
hMsgQueue-refCount--;
/* Reset the event if there are still queued messages */
- if (!LST_IsEmpty(hMsgQueue-msgUsedList))
+ if (!LST_IsEmpty(hMsgQueue-msgUsedList)) {
+ NTFY_Notify(hMsgQueue-hNtfy,
+ DSP_NODEMESSAGEREADY);
SYNC_SetEvent(hMsgQueue-hSyncEvent);
-
+ }
/* Exit critical section */
(void)SYNC_LeaveCS(hMsgMgr-hSyncCS);
}
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] omap: DEBUG_LL: allow no omap uart configuration
Zoom2/Zoom3 kind of boards do not use omap uarts these boards should not have DEBUG_LL writing to omap uarts Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/plat-omap/Kconfig |3 +++ arch/arm/plat-omap/include/plat/uncompress.h |4 +++- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 64b3f52..c912e0e 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -176,6 +176,9 @@ config OMAP_LL_DEBUG_UART2 config OMAP_LL_DEBUG_UART3 bool UART3 +config OMAP_LL_DEBUG_NONE + bool None + endchoice config OMAP_SERIAL_WAKE diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h index e22f575..49b38f0 100644 --- a/arch/arm/plat-omap/include/plat/uncompress.h +++ b/arch/arm/plat-omap/include/plat/uncompress.h @@ -44,8 +44,10 @@ static void putc(int c) uart = (volatile u8 *)(OMAP_UART3_BASE); #elif defined(CONFIG_OMAP_LL_DEBUG_UART2) uart = (volatile u8 *)(OMAP_UART2_BASE); -#else +#elif defined(CONFIG_OMAP_LL_DEBUG_UART1) uart = (volatile u8 *)(OMAP_UART1_BASE); +#elif defined(CONFIG_OMAP_LL_DEBUG_NONE) + return; #endif #ifdef CONFIG_ARCH_OMAP1 -- 1.6.5.1.69.g36942 -- To unsubscribe from this list: send the line unsubscribe 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: EHCI on 2.6.32-rc5-git4 + patches
On 03/11/09 01:28, Robert Nelson wrote: I tried that and various others to get other than the hub enumerated, no luck so far with kernels I have built - no lights on the hub. I am now rebuilding after following the config for the working narcissus build, EHCI looks much the same, so here's hoping. I have another 16G MMC card I am trying on after cross compiling on a Fedora 12 VirtualBox VM. Regards Sid. Hi Sid I eventually got ehci working today on my tree on launchpad. But it's not that small of a patch once i added all the mach to plat changes... However, this commit made all the difference for me, it's currently missing from tmlind's tree, the beagleboard needs it to enable power to the ehci.. http://patchwork.kernel.org/patch/55703/ Regards, Thanks, the patch worked and all the EHCI devices are enumerated. There are other issues like no output to the LCD and I don't have a FB_OMAP2 option, so trying to rebuild with FB_OMAP=y. The configuration setup seems to be very particular and easily upset by certain changes. I guess the right patches have to be installed or build failures result. Lowlevel video output switch controls (VIDEO_OUTPUT_CONTROL) [N/m/y/?] n E-Ink Broadsheet/Epson S1D13521 controller support (FB_BROADSHEET) [N/m/y/?] n OMAP frame buffer support (EXPERIMENTAL) (FB_OMAP) [Y/n/m/?] y External LCD controller support (FB_OMAP_LCDC_EXTERNAL) [N/y/?] (NEW) MIPI DBI-C/DCS compatible LCD support (FB_OMAP_LCD_MIPID) [N/y/?] (NEW) Check bootloader initialization (FB_OMAP_BOOTLOADER_INIT) [N/y/?] (NEW) Consistent DMA memory size (MB) (FB_OMAP_CONSISTENT_DMA_SIZE) [2] (NEW) # l -R 2.6.32-rc5/kernel/drivers/video/ 2.6.32-rc5/kernel/drivers/video/: total 0 drwxr-xr-x 3 root root 72 Nov 3 21:58 ./ drwxr-xr-x 16 root root 392 Nov 3 21:58 ../ drwxr-xr-x 2 root root 160 Nov 3 21:58 console/ 2.6.32-rc5/kernel/drivers/video/console: total 68 drwxr-xr-x 2 root root 160 Nov 3 21:58 ./ drwxr-xr-x 3 root root72 Nov 3 21:58 ../ -rw-r--r-- 1 root root 7647 Nov 3 21:58 bitblit.ko -rw-r--r-- 1 root root 43880 Nov 3 21:58 fbcon.ko -rw-r--r-- 1 root root 10743 Nov 3 21:58 font.ko -rw-r--r-- 1 root root 3984 Nov 3 21:58 softcursor.ko Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] DSPBRIDGE: Lower power transtion timeout
Given system latency and low timer resolutions, device
driver timeout needs to be cut to report any error, while
transitioning to OFF mode.
In the best case scenario, the transition should be immediate,
but in the worst scenario it could take up to ~400 ms,
even tough the driver defines the waiting loop to be 200 ms.
Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
drivers/dsp/bridge/wmd/_tiomap_util.h |7 +--
drivers/dsp/bridge/wmd/tiomap3430_pwr.c |2 +-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/dsp/bridge/wmd/_tiomap_util.h
b/drivers/dsp/bridge/wmd/_tiomap_util.h
index 8f1e515..bd1b571 100644
--- a/drivers/dsp/bridge/wmd/_tiomap_util.h
+++ b/drivers/dsp/bridge/wmd/_tiomap_util.h
@@ -31,8 +31,11 @@
/* Time out Values in uSeconds*/
#define TIHELEN_ACKTIMEOUT 1
-/* Time out for power state transition (in msecs) */
-#define PWRSTST_TIMEOUT1500
+/*
+ * Time out for power state transition (in msecs), due to system
+ * latencies and HZ resolution this timer can vary.
+ */
+#define PWRSTST_TIMEOUT200
/* Time delay for HOM-SAM transition. */
#define WAIT_SAM 100/* in usec (1000 millisec) */
diff --git a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
index 0c2f2fd..2eb379f 100644
--- a/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
+++ b/drivers/dsp/bridge/wmd/tiomap3430_pwr.c
@@ -248,7 +248,7 @@ DSP_STATUS SleepDSP(struct WMD_DEV_CONTEXT *pDevContext, IN
u32 dwCmd,
pwrState);
/* Wait for DSP to move into target power state */
- while ((pwrState != targetPwrState) --timeout) {
+ while ((pwrState != targetPwrState) timeout--) {
if (msleep_interruptible(10)) {
pr_err(Waiting for DSP to Suspend interrupted\n);
return DSP_EFAIL;
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] omap: zoom3: defconfig creation
Create zoom3 defconfig file Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/configs/omap_zoom3_defconfig | 1605 + 1 files changed, 1605 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/omap_zoom3_defconfig diff --git a/arch/arm/configs/omap_zoom3_defconfig b/arch/arm/configs/omap_zoom3_defconfig new file mode 100644 index 000..989cedd --- /dev/null +++ b/arch/arm/configs/omap_zoom3_defconfig @@ -0,0 +1,1605 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc5 +# Tue Nov 3 09:50:40 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=y +# CONFIG_BSD_PROCESS_ACCT_V3 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=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +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_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +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=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_FREEZER=y + +# +# 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 +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_MSM is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +#
[PATCH 8/8] omap: 3630sdp: defconfig creation
Create 3630sdp defconfig file Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/configs/omap_3630sdp_defconfig | 1606 +++ 1 files changed, 1606 insertions(+), 0 deletions(-) create mode 100644 arch/arm/configs/omap_3630sdp_defconfig diff --git a/arch/arm/configs/omap_3630sdp_defconfig b/arch/arm/configs/omap_3630sdp_defconfig new file mode 100644 index 000..eb96b1a --- /dev/null +++ b/arch/arm/configs/omap_3630sdp_defconfig @@ -0,0 +1,1606 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.32-rc5 +# Tue Nov 3 14:18:44 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=y +# CONFIG_BSD_PROCESS_ACCT_V3 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=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +# CONFIG_CGROUPS is not set +# CONFIG_SYSFS_DEPRECATED_V2 is not set +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE= +CONFIG_RD_GZIP=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +CONFIG_ANON_INODES=y +CONFIG_EMBEDDED=y +CONFIG_UID16=y +# CONFIG_SYSCTL_SYSCALL is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +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_COMPAT_BRK=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +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=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_BLOCK=y +CONFIG_LBDAF=y +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_FREEZER=y + +# +# 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 +# CONFIG_ARCH_PNX4008 is not set +# CONFIG_ARCH_PXA is not set +# CONFIG_ARCH_MSM is not set +# CONFIG_ARCH_RPC is not set +# CONFIG_ARCH_SA1100 is not set +# CONFIG_ARCH_S3C2410 is not set +#
[PATCH 4/8] omap: zoom2: update defconfig
Update DEBUG_LL for zoom2 board as CONFIG_OMAP_LL_DEBUG_NONE Sync zoom2 defconfig with menuconfig Signed-off-by: Vikram Pandita vikram.pand...@ti.com --- arch/arm/configs/omap_zoom2_defconfig | 231 - 1 files changed, 141 insertions(+), 90 deletions(-) diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index f1739fa..db4fc1c 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -1,15 +1,13 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-omap1 -# Fri Jun 12 17:25:46 2009 +# Linux kernel version: 2.6.32-rc5 +# Tue Nov 3 12:00:13 2009 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_MMU=y -# CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -18,13 +16,13 @@ CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y -# CONFIG_ARCH_HAS_ILOG2_U32 is not set -# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_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 @@ -46,11 +44,12 @@ CONFIG_BSD_PROCESS_ACCT=y # # RCU Subsystem # -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set +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_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_GROUP_SCHED=y @@ -77,7 +76,6 @@ CONFIG_UID16=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -90,18 +88,25 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y + +# +# Kernel Performance Events And Counters +# CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set -# CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set 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 @@ -114,7 +119,7 @@ CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -135,19 +140,22 @@ CONFIG_FREEZER=y # # 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_GEMINI is not set # CONFIG_ARCH_FOOTBRIDGE is not set +# CONFIG_ARCH_MXC is not set +# CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_IMX is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -156,25 +164,27 @@ CONFIG_FREEZER=y # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KIRKWOOD is not set -# CONFIG_ARCH_KS8695 is not set -# CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_LOKI is not set # CONFIG_ARCH_MV78XX0 is not set -# CONFIG_ARCH_MXC is not set # CONFIG_ARCH_ORION5X is not set +# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_KS8695 is not set +# CONFIG_ARCH_NS9XXX is not set +# CONFIG_ARCH_W90X900 is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set -# CONFIG_ARCH_MMP is not set +# CONFIG_ARCH_MSM is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5PC1XX is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set +# CONFIG_ARCH_U300 is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y -# CONFIG_ARCH_MSM is not set -# CONFIG_ARCH_W90X900 is not set +# CONFIG_ARCH_BCMRING is not set # # TI OMAP Implementations @@ -202,21 +212,26 @@ CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_LL_DEBUG_UART1 is not set # CONFIG_OMAP_LL_DEBUG_UART2 is not set -CONFIG_OMAP_LL_DEBUG_UART3=y +# CONFIG_OMAP_LL_DEBUG_UART3 is not set +CONFIG_OMAP_LL_DEBUG_NONE=y +# CONFIG_OMAP_PM_NONE is not set +CONFIG_OMAP_PM_NOOP=y
[PATCH 1/8] 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
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
Acked-by: Alexander Shishkin virtu...@slind.org
Acked-by: Ari Kauppi kau...@papupata.org
---
arch/arm/mach-omap2/id.c |2 ++
arch/arm/plat-omap/include/plat/cpu.h |7 +--
2 files changed, 7 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 7cb0556..05a0a33 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -454,6 +454,7 @@ 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)
+#define CHIP_IS_OMAP3630ES1(1 7)
#define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
@@ -465,8 +466,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.1.69.g36942
--
To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE: Kill CAMelCaSiNg
Hi All, If anyone has patches that need to be included in dspbridge branch, please send them to the list. I'm planning to give a run on the script sent by Nishant to eliminate CamelCasing from bridge starting next week. - omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH v2] OMAP: DMA: Fix omapfb/lcdc on Amstrad Delta broken when PM set
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [091103 12:05]:
Tuesday 03 November 2009 20:24:38 Janusz Krzysztofik napisał(a):
If there are still no comments, especially on the bug possible impact on
other OMAP1510 boards (or even OMAP1610 with internal LCD controller), then
Tony, please apply it as is. Until it is accepted, I am stuck with new
ams_delta_defconfig.
Tony,
Sorry, I've not checked for new mail before posting this one and missed your
acceptance for my idea of fixing all omap1510, not only ams_delta. If there
are no more comments, I'll submit v3 with cpu_is_omap1510() replacing
machine_is_ams_delta().
Sounds good to me.
Tony
Thanks,
Janusz
--- linux-2.6.32-rc5/arch/arm/plat-omap/dma.c.orig 2009-10-16
02:41:50.0 +0200 +++
linux-2.6.32-rc5/arch/arm/plat-omap/dma.c 2009-11-03 20:15:35.0
+0100 @@ -30,6 +30,7 @@
#include linux/irq.h
#include linux/io.h
+#include asm/mach-types.h
#include asm/system.h
#include mach/hardware.h
#include mach/dma.h
@@ -1110,6 +,14 @@ int omap_dma_running(void)
{
int lch;
+ /*
+* On Amstrad Delta, the OMAP internal LCD controller will start the
+* transfer when it gets enabled, so assume DMA running if LCD enabled.
+*/
+ if (machine_is_ams_delta())
+ if (omap_readw(0xfffec000 + 0x00) (1 0))
+ return 1;
+
/* Check if LCD DMA is running */
if (cpu_is_omap16xx())
if (omap_readw(OMAP1610_DMA_LCD_CCR) OMAP_DMA_CCR_EN)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] RFC: introduce 3630 boards
Introducing 3630 boards: zoom3 and sdp3630 The peripherals are very similar for the two bards as per this discussion: http://marc.info/?l=linux-omapm=125676595710748w=2 So maximum reuse is done for the board files for zoom3 and sdp3630 Review comments incorporated: http://marc.info/?l=linux-omapm=125632676504364w=2 http://marc.info/?l=linux-omapm=125632720804869w=2 http://marc.info/?l=linux-omapm=125633994320138w=2 Vikram Pandita (8): omap: 3630: update is_chip variable omap: DEBUG_LL: allow no omap uart configuration omap: zoom2: split baord file for reuse omap: zoom2: update defconfig omap: zoom3: introduce zoom3 board support omap: zoom3: defconfig creation omap: 3630sdp: introduce 3630 sdp board support omap: 3630sdp: defconfig creation arch/arm/configs/omap_3630sdp_defconfig| 1606 arch/arm/configs/omap_zoom2_defconfig | 231 ++-- arch/arm/configs/omap_zoom3_defconfig | 1605 +++ arch/arm/mach-omap2/Kconfig|8 + arch/arm/mach-omap2/Makefile |8 + arch/arm/mach-omap2/board-3630sdp.c| 96 ++ arch/arm/mach-omap2/board-zoom-peripherals.c | 414 + arch/arm/mach-omap2/board-zoom2.c | 261 +--- arch/arm/mach-omap2/board-zoom3.c | 59 + arch/arm/mach-omap2/id.c |2 + arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h | 54 + arch/arm/plat-omap/Kconfig |3 + arch/arm/plat-omap/include/plat/cpu.h |7 +- arch/arm/plat-omap/include/plat/uncompress.h |4 +- 14 files changed, 4018 insertions(+), 340 deletions(-) create mode 100644 arch/arm/configs/omap_3630sdp_defconfig create mode 100644 arch/arm/configs/omap_zoom3_defconfig create mode 100755 arch/arm/mach-omap2/board-3630sdp.c create mode 100755 arch/arm/mach-omap2/board-zoom-peripherals.c mode change 100644 = 100755 arch/arm/mach-omap2/board-zoom2.c create mode 100755 arch/arm/mach-omap2/board-zoom3.c create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8mbx00u0mer-0em.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/8] omap: zoom2: update defconfig
diff --git a/arch/arm/configs/omap_zoom2_defconfig b/arch/arm/configs/omap_zoom2_defconfig index f1739fa..db4fc1c 100644 --- a/arch/arm/configs/omap_zoom2_defconfig +++ b/arch/arm/configs/omap_zoom2_defconfig @@ -1,15 +1,13 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-omap1 -# Fri Jun 12 17:25:46 2009 +# Linux kernel version: 2.6.32-rc5 +# Tue Nov 3 12:00:13 2009 # +# CONFIG_PHONE is not set ...snip... # # Input device support Why not enable CONFIG_KEYBOARD_TWL4030? @@ -619,21 +639,22 @@ CONFIG_TOUCHSCREEN_ADS7846=y # CONFIG_TOUCHSCREEN_AD7879_I2C is not set # CONFIG_TOUCHSCREEN_AD7879_SPI is not set # CONFIG_TOUCHSCREEN_AD7879 is not set +# CONFIG_TOUCHSCREEN_EETI is not set # CONFIG_TOUCHSCREEN_FUJITSU is not set ...snip... # CONFIG_NEW_LEDS is not set +# CONFIG_ACCESSIBILITY is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y @@ -1128,6 +1173,7 @@ CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8581 is not set +# CONFIG_RTC_DRV_RX8025 is not set And here - CONFIG_RTC_DRV_TWL4030 -Manjunath-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] omap: mux: Add new style pin multiplexing data for 34xx
Tony Lindgren wrote:
* Mike Rapoport mike.rapop...@gmail.com [091102 23:10]:
On Mon, Nov 2, 2009 at 9:10 PM, Tony Lindgren t...@atomide.com wrote:
* Mike Rapoport m...@compulab.co.il [091101 02:30]:
Tony Lindgren wrote:
Add new style mux data for 34xx. This should also
work with 3630 easily by adding the processor subset
and ball data.
Note that this data is __initdata, and gets optimized
out if CONFIG_OMAP_MUX is not set. Also, the debug data
gets optimized out if CONFIG_DEBUG_FS is not set.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/Makefile |4
arch/arm/mach-omap2/mux.h |2
arch/arm/mach-omap2/mux34xx.c | 1552
+
arch/arm/mach-omap2/mux34xx.h | 352 +
4 files changed, 1910 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/mux34xx.c
create mode 100644 arch/arm/mach-omap2/mux34xx.h
[ snip ]
+
+#define OMAP3_CONTROL_PADCONF_MUX_SIZE \
+ (OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET + 0x2)
What about adding defines for each possible mode configuration, except,
perhaps,
GPIO?
Yeah it would be nice to make it easy. How about someting like:
int __init omap_mux_init_by_name(char *name, int flags);
...
omap_mux_init_by_name(i2c1_scl, OMAP_PIN_INPUT_PULLUP);
#define OMAP3_PIN_CAM_D0 OMAP3_MUX(CAM_D0, OMAP_PIN_MODE0 |
OMAP_PIN_INPUT, 0)
#define OMAP3_PIN_CAM_D0_CSI2_DX2 OMAP3_MUX(CAM_D0, OMAP_PIN_MODE2 | \
OMAP_PIN_INPUT, 0)
And, I'm for adding OMAP_MUX_GPIO_{OUT,IN,IN_PU,IN_PD}(x) as well.
And we could have also:
int __init omap_mux_init_by_gpio(int gpio, int flags);
...
omap_mux_init_by_gpio(99, OMAP_PIN_INPUT);
As the only thing we currently have for flags is the OMAP_MUX_DYNAMIC,
we could mask that too into flags and make it int instead of u16.
It seems we are thinking in really different directions :) You propose
imporved and easy to use replacements of omap_cfg_reg while I'm aming
nice tables descibing board pin configuration like, e.g,
cm_x300_mfp_cfg in arch/arm/mach-pxa/cm-x300.c. Probably it's just too
hard to me to break my PXA habbits, but I think such tables make the
board code easier to write/maintain/understand.
Besides, having both simple aliases for OMAP3_MUX(mode0, mux_value,
mux_flags) for dedicated pins does not contadict having
omap_mux_init_by_{name,gpio} helpers.
Agreed, we should make the pin muxing as easy as possible as it's
probably the biggest hurdle to anybody to start making changes to a
development board. And we should have easy to to read board specific
pin configuration tables like you're suggesting.
In the long run, we should probably start using the real signal names
as they seem to be more future proof across omaps than the register
names.
We can easily do something like this if we add char *muxname to
struct omap_board_mux (untested):
#define OMAP_MUX_SIGNAL(signal, mux_flags)\
{ \
.muxname= #signal, \
.flags = (mux_flags), \
}
#define OMAP_MUX_GPIO(gpio, mux_flags)
\
{ \
.muxname= gpio_##signal,\
.flags = (mux_flags), \
}
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
OMAP_MUX_SIGNAL(i2c1_scl, OMAP_PIN_INPUT),
OMAP_MUX_GPIO(98, OMAP_PIN_INPUT_PULLUP),
OMAP_MUX_GPIO(99, OMAP_PIN_INPUT_PULLUP | OMAP_MUX_DYNAMIC),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#endif
Of course then we have to warn on potential duplicate signal names,
but those can be specified using the register offset + mode as
needed.
Is the above close enough to what you have in mind regarding the
board specific mux tables, or do you have still something else
in mind?
It's closer :)
What I have in mind is a simple wrapper macro defining mux configuration for
straightforward cases, just like a bunch of defines in
arch/arm/mach-omap2/include/mach/mux34xx.h in my earlier patch [1].
And just use OMAP_MUX_SIGNAL, or OMAP3_MUX for more complicated cases where
flags and/or OFF mode settings are required.
For instance, for making i2c1_scl to be actually routed to its pin you would
have
static struct omap_board_mux board_mux[] __initdata = {
OMAP_MUX_I2C1_SCL,
...
}
and for dss_pclk to became hw_dbg12 you have
static struct omap_board_mux board_mux[] __initdata = {
OMAP_MUX_PCLK_HW_DBG12,
...
}
Another my point was, that each board-* file will have all the mux settings in
one consolidated place. Indeed, currently there are no many uses of
[PATCH 3/4 v2] MFD: twl4030-codec: APLL_INFREQ handling in the MFD driver
Configure the APLL_INFREQ field in the APLL_CTL register
based on the platform data.
Provide also a function for childs to query the audio_mclk
frequency.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
drivers/mfd/twl4030-codec.c | 35 +++
include/linux/mfd/twl4030-codec.h |1 +
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-codec.c b/drivers/mfd/twl4030-codec.c
index 9710307..77b9149 100644
--- a/drivers/mfd/twl4030-codec.c
+++ b/drivers/mfd/twl4030-codec.c
@@ -41,6 +41,7 @@ struct twl4030_codec_resource {
};
struct twl4030_codec {
+ unsigned int audio_mclk;
struct mutex mutex;
struct twl4030_codec_resource resource[TWL4030_CODEC_RES_MAX];
struct mfd_cell cells[TWL4030_CODEC_CELLS];
@@ -145,12 +146,45 @@ int twl4030_codec_disable_resource(unsigned id)
}
EXPORT_SYMBOL_GPL(twl4030_codec_disable_resource);
+unsigned int twl4030_codec_get_mclk(void)
+{
+ struct twl4030_codec *codec = platform_get_drvdata(twl4030_codec_dev);
+
+ return codec-audio_mclk;
+}
+EXPORT_SYMBOL_GPL(twl4030_codec_get_mclk);
+
static int __devinit twl4030_codec_probe(struct platform_device *pdev)
{
struct twl4030_codec *codec;
struct twl4030_codec_data *pdata = pdev-dev.platform_data;
struct mfd_cell *cell = NULL;
int ret, childs = 0;
+ u8 val;
+
+ if (!pdata) {
+ dev_err(pdev-dev, Platform data is missing\n);
+ return -EINVAL;
+ }
+
+ /* Configure APLL_INFREQ and disable APLL if enabled */
+ val = 0;
+ switch (pdata-audio_mclk) {
+ case 1920:
+ val |= TWL4030_APLL_INFREQ_19200KHZ;
+ break;
+ case 2600:
+ val |= TWL4030_APLL_INFREQ_26000KHZ;
+ break;
+ case 3840:
+ val |= TWL4030_APLL_INFREQ_38400KHZ;
+ break;
+ default:
+ dev_err(pdev-dev, Invalid audio_mclk\n);
+ return -EINVAL;
+ }
+ twl4030_i2c_write_u8(TWL4030_MODULE_AUDIO_VOICE,
+ val, TWL4030_REG_APLL_CTL);
codec = kzalloc(sizeof(struct twl4030_codec), GFP_KERNEL);
if (!codec)
@@ -160,6 +194,7 @@ static int __devinit twl4030_codec_probe(struct
platform_device *pdev)
twl4030_codec_dev = pdev;
mutex_init(codec-mutex);
+ codec-audio_mclk = pdata-audio_mclk;
/* Codec power */
codec-resource[TWL4030_CODEC_RES_POWER].reg = TWL4030_REG_CODEC_MODE;
diff --git a/include/linux/mfd/twl4030-codec.h
b/include/linux/mfd/twl4030-codec.h
index ef0a304..2ec317c 100644
--- a/include/linux/mfd/twl4030-codec.h
+++ b/include/linux/mfd/twl4030-codec.h
@@ -267,5 +267,6 @@ enum twl4030_codec_res {
int twl4030_codec_disable_resource(enum twl4030_codec_res id);
int twl4030_codec_enable_resource(enum twl4030_codec_res id);
+unsigned int twl4030_codec_get_mclk(void);
#endif /* End of __TWL4030_CODEC_H__ */
--
1.6.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4 v2] ASoC/MFD/OMAP: TWL4030: APLL_CTL handling change
Hello, Changes from the first series: - Typos fixed and warning/error messages for APLL frequency mismatch now consistent - twl4030-codec MFD driver audio_mclk validity check simplified - Commit message for the twl4030-codec MFD driver has been changed also - Patch: ASoC: TWL4030: Make sure, that the codec is powered on startup has been removed from the series, since it is already taken. Intro text from the first series: The following series changes the way how the APLL_CTL register is handled by the twl4030 codec related drivers. Moving the configuration of APLL_CTL register from child drivers (specifically from soc codec driver) to the twl4030-codec MFD driver. Because the audio_mclk is static, board specific and can not be changed in runtime, the codec MFD is the right place to configure it early enough, so child can use the hardware correctly. Before this patch for example the APLL_INFREQ was configured first, when the user played or recorded audio via the twl4030. The digital bypass needs correct APLL_INFREQ to be configured in order to work properly. If the digital bypass enabled before any audio activity, in some cases the bypassed audio was not correct. The series also addresses the issue, that after boot-up, neither of the loopbacks was working, because the codec was actually off. Setting the codec-bias_level to _OFF, before setting the codec bias level to STANDBY fixes this issue. This series is on top of Takashi's sound-2.6 topic/asoc branch, which has the twl403-codec MFD and related patches for 2.6.33. It would be really nice, if this series would make it also to the same branch, since this fixes some real anomalies brought in by the cleanup of the twl4030 codec related drivers. These problems were hidden before because of the inconsistent handling of bits and states in the codec driver in the past. --- Peter Ujfalusi (4): MFD: TWL4030: Add audio_mclk to the codec platform data OMAP: Configure audio_mclk for twl4030-codec MFD MFD: twl4030-codec: APLL_INFREQ handling in the MFD driver ASoC: TWL4030: Do not modify the APLL_CTL register arch/arm/mach-omap2/board-3430sdp.c |1 + arch/arm/mach-omap2/board-omap3beagle.c |1 + arch/arm/mach-omap2/board-omap3evm.c |1 + arch/arm/mach-omap2/board-omap3pandora.c |1 + arch/arm/mach-omap2/board-overo.c|1 + arch/arm/mach-omap2/board-zoom2.c|1 + drivers/mfd/twl4030-codec.c | 35 ++ include/linux/i2c/twl4030.h |1 + include/linux/mfd/twl4030-codec.h|1 + sound/soc/codecs/twl4030.c | 76 -- 10 files changed, 74 insertions(+), 45 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4 v2] ASoC: TWL4030: Do not modify the APLL_CTL register
APLL_CTL register is configured by the twl4030-codec MFD
driver.
Remove code, which makes changes in the APLL_CTL register,
and replace those with checks against the configured
audio_mclk configuration done in the MFD driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
sound/soc/codecs/twl4030.c | 76 ++--
1 files changed, 31 insertions(+), 45 deletions(-)
diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c
index c0b47df..bd8ea35 100644
--- a/sound/soc/codecs/twl4030.c
+++ b/sound/soc/codecs/twl4030.c
@@ -214,7 +214,8 @@ static void twl4030_init_chip(struct snd_soc_codec *codec)
/* set all audio section registers to reasonable defaults */
for (i = TWL4030_REG_OPTION; i = TWL4030_REG_MISC_SET_2; i++)
- twl4030_write(codec, i, cache[i]);
+ if (i != TWL4030_REG_APLL_CTL)
+ twl4030_write(codec, i, cache[i]);
}
@@ -1753,30 +1754,23 @@ static int twl4030_set_dai_sysclk(struct snd_soc_dai
*codec_dai,
{
struct snd_soc_codec *codec = codec_dai-codec;
struct twl4030_priv *twl4030 = codec-private_data;
- u8 apll_ctrl;
- apll_ctrl = twl4030_read_reg_cache(codec, TWL4030_REG_APLL_CTL);
- apll_ctrl = ~TWL4030_APLL_INFREQ;
switch (freq) {
case 1920:
- apll_ctrl |= TWL4030_APLL_INFREQ_19200KHZ;
- twl4030-sysclk = 19200;
- break;
case 2600:
- apll_ctrl |= TWL4030_APLL_INFREQ_26000KHZ;
- twl4030-sysclk = 26000;
- break;
case 3840:
- apll_ctrl |= TWL4030_APLL_INFREQ_38400KHZ;
- twl4030-sysclk = 38400;
break;
default:
- printk(KERN_ERR TWL4030 set sysclk: unknown rate %d\n,
- freq);
+ dev_err(codec-dev, Unsupported APLL mclk: %u\n, freq);
return -EINVAL;
}
- twl4030_write(codec, TWL4030_REG_APLL_CTL, apll_ctrl);
+ if ((freq / 1000) != twl4030-sysclk) {
+ dev_err(codec-dev,
+ Mismatch in APLL mclk: %u (configured: %u)\n,
+ freq, twl4030-sysclk * 1000);
+ return -EINVAL;
+ }
return 0;
}
@@ -1874,18 +1868,16 @@ static int twl4030_voice_startup(struct
snd_pcm_substream *substream,
struct snd_soc_pcm_runtime *rtd = substream-private_data;
struct snd_soc_device *socdev = rtd-socdev;
struct snd_soc_codec *codec = socdev-card-codec;
- u8 infreq;
+ struct twl4030_priv *twl4030 = codec-private_data;
u8 mode;
/* If the system master clock is not 26MHz, the voice PCM interface is
* not avilable.
*/
- infreq = twl4030_read_reg_cache(codec, TWL4030_REG_APLL_CTL)
-TWL4030_APLL_INFREQ;
-
- if (infreq != TWL4030_APLL_INFREQ_26000KHZ) {
- printk(KERN_ERR TWL4030 voice startup:
- MCLK is not 26MHz, call set_sysclk() on init\n);
+ if (twl4030-sysclk != 26000) {
+ dev_err(codec-dev, The board is configured for %u Hz, while
+ the Voice interface needs 26MHz APLL mclk\n,
+ twl4030-sysclk * 1000);
return -EINVAL;
}
@@ -1958,22 +1950,19 @@ static int twl4030_voice_set_dai_sysclk(struct
snd_soc_dai *codec_dai,
int clk_id, unsigned int freq, int dir)
{
struct snd_soc_codec *codec = codec_dai-codec;
- u8 apll_ctrl;
+ struct twl4030_priv *twl4030 = codec-private_data;
- apll_ctrl = twl4030_read_reg_cache(codec, TWL4030_REG_APLL_CTL);
- apll_ctrl = ~TWL4030_APLL_INFREQ;
- switch (freq) {
- case 2600:
- apll_ctrl |= TWL4030_APLL_INFREQ_26000KHZ;
- break;
- default:
- printk(KERN_ERR TWL4030 voice set sysclk: unknown rate %d\n,
- freq);
+ if (freq != 2600) {
+ dev_err(codec-dev, Unsupported APLL mclk: %u, the Voice
+ interface needs 26MHz APLL mclk\n, freq);
+ return -EINVAL;
+ }
+ if ((freq / 1000) != twl4030-sysclk) {
+ dev_err(codec-dev,
+ Mismatch in APLL mclk: %u (configured: %u)\n,
+ freq, twl4030-sysclk * 1000);
return -EINVAL;
}
-
- twl4030_write(codec, TWL4030_REG_APLL_CTL, apll_ctrl);
-
return 0;
}
@@ -2131,17 +2120,15 @@ static int twl4030_soc_probe(struct platform_device
*pdev)
if (setup) {
unsigned char hs_pop;
- if (setup-sysclk)
- twl4030-sysclk = setup-sysclk;
- else
- twl4030-sysclk = 26000;
+ if (setup-sysclk != twl4030-sysclk)
+ dev_warn(pdev-dev,
+
[PATCH 1/4 v2] MFD: TWL4030: Add audio_mclk to the codec platform data
Add audio_mclk to the platform data struct for the
twl4030-codec MFD driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
include/linux/i2c/twl4030.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c/twl4030.h b/include/linux/i2c/twl4030.h
index 42d6c72..c188961 100644
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -414,6 +414,7 @@ struct twl4030_codec_vibra_data {
};
struct twl4030_codec_data {
+ unsigned intaudio_mclk;
struct twl4030_codec_audio_data *audio;
struct twl4030_codec_vibra_data *vibra;
};
--
1.6.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
