[PATCH 2/2] DSPBRIDGE: fix build error for undefined WCD_debugMask with debug
From: Hiroshi DOYU hiroshi.d...@nokia.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
drivers/dsp/bridge/pmgr/wcd.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/dsp/bridge/pmgr/wcd.c b/drivers/dsp/bridge/pmgr/wcd.c
index 8708c78..ee15b02 100644
--- a/drivers/dsp/bridge/pmgr/wcd.c
+++ b/drivers/dsp/bridge/pmgr/wcd.c
@@ -145,6 +145,18 @@
#define MAX_STREAMS 16
#define MAX_BUFS 64
+/* Device IOCtl function pointer */
+struct WCD_Cmd {
+ u32(*fxn)(union Trapped_Args *args);
+ u32 dwIndex;
+} ;
+
+/* --- Globals */
+#if GT_TRACE
+static struct GT_Mask WCD_debugMask = { NULL, NULL }; /* Core VxD Mask */
+#endif
+static u32 WCD_cRefs;
+
static inline void __cp_fm_usr(void *to, const void __user *from,
DSP_STATUS *err, unsigned long bytes)
{
@@ -185,18 +197,6 @@ static inline void __cp_to_usr(void __user *to, const void
*from,
#define cp_to_usr(to, from, err, n)\
__cp_to_usr(to, from, (err), (n) * sizeof(*(from)))
-/* Device IOCtl function pointer */
-struct WCD_Cmd {
- u32(*fxn)(union Trapped_Args *args);
- u32 dwIndex;
-} ;
-
-/* --- Globals */
-#if GT_TRACE
-static struct GT_Mask WCD_debugMask = { NULL, NULL }; /* Core VxD Mask */
-#endif
-static u32 WCD_cRefs;
-
/*
* Function table.
* The order of these functions MUST be the same as the order of the command
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] DSPBRIDGE: fix build error for mboxsetting with debug
From: Hiroshi DOYU hiroshi.d...@nokia.com
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
drivers/dsp/bridge/hw/hw_mbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dsp/bridge/hw/hw_mbox.c b/drivers/dsp/bridge/hw/hw_mbox.c
index 5a87597..8591729 100644
--- a/drivers/dsp/bridge/hw/hw_mbox.c
+++ b/drivers/dsp/bridge/hw/hw_mbox.c
@@ -33,7 +33,7 @@
/* width in bits of MBOX Id */
#define HW_MBOX_ID_WIDTH 2
-static struct MAILBOX_CONTEXT mboxsetting = {
+struct MAILBOX_CONTEXT mboxsetting = {
.sysconfig = 2 3 | 1, /* SMART/AUTO-IDLE */
};
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap iommu: avoid remapping if it's been mapped in MPU side
From: Hiroshi DOYU hiroshi.d...@nokia.com
MPU side (v)-(p) mapping is necessary only if IOVMF_MMIO is set in
flags.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iovmm.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 6fc52fc..004fd83 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -615,7 +615,7 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct
sg_table *sgt,
u32 flags)
{
size_t bytes;
- void *va;
+ void *va = NULL;
if (!obj || !obj-dev || !sgt)
return -EINVAL;
@@ -625,9 +625,11 @@ u32 iommu_vmap(struct iommu *obj, u32 da, const struct
sg_table *sgt,
return -EINVAL;
bytes = PAGE_ALIGN(bytes);
- va = vmap_sg(sgt);
- if (IS_ERR(va))
- return PTR_ERR(va);
+ if (flags IOVMF_MMIO) {
+ va = vmap_sg(sgt);
+ if (IS_ERR(va))
+ return PTR_ERR(va);
+ }
flags = IOVMF_HW_MASK;
flags |= IOVMF_DISCONT;
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430
-Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of Woodruff, Richard Sent: Tuesday, May 19, 2009 12:53 AM To: Niilo Minkkinen; linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; t...@atomide.com Subject: RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen Sent: Monday, May 18, 2009 9:54 AM Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. Richard/Niilo, This should also be applicable to 35xx (right?) and so we got to update the fix with below patch. Regards, Ajay == patch = There is an issue with MUSB AUTOIDLE as reported by Niilo Minkkinen in below commit. 9a4b5e36ce58febdd2039dd4d129ee7edf4f5536 usb: musb: disable OTG AUTOIDLE only with omap3430 As OMAP35x is just a variant of OMAP34xx chip thus the fix is also applicable for OMAP35x so updating it for OMAP35x. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/omap2430.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 453796c..ab8336d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -233,7 +233,7 @@ int __init musb_platform_init(struct musb *musb) * MUSB AUTOIDLE don't work in 3430. * Workaround by Richard Woodruff/TI */ - if (!cpu_is_omap3430()) + if (!cpu_is_omap3430() !cpu_is_omap35xx()) l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); -- 1.6.2.4 == Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-usb 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:
Syed Rafiuddin wrote: From: Syed Rafiuddin rafiuddin.s...@ti.com This patch Adds Keypad support on OMAP4.And adds OMAP4 register addresses and configures them for OMAP4. [SNIP] Subjects are considered useful, please supply at-least semi meaningful subject next time! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Add omap34xx revision detection for ES3.1.1
ARM: OMAP: Add omap34xx revision detection for ES3.1.1
- Add omap34xx revision detection for ES3.1.1 silicon.
- Change default silicon to ES3.1.1
- Also minor bug-fix: ES2.0 rev field is 1, not 0.
- This means that ES2.0 silicon would have wrongly been
detected as unknown
Signed-off-by: Anand Gadiyar gadi...@ti.com
---
Let me know if this should be split into a bug-fix patch,
and a separate patch for adding ES 3.1.1 revision info.
I felt the change was too minor to split out, since
ES2.0 silicon is rare.
This patch is against linus' tree - so the cpu.h
change will apply with an offset
arch/arm/mach-omap2/id.c |8 ++--
arch/arm/plat-omap/include/mach/cpu.h |1 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index a98201c..414c520 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -185,7 +185,7 @@ void __init omap34xx_check_revision(void)
if (hawkeye == 0xb7ae) {
switch (rev) {
- case 0:
+ case 1:
omap_revision = OMAP3430_REV_ES2_0;
rev_name = ES2.0;
break;
@@ -201,9 +201,13 @@ void __init omap34xx_check_revision(void)
omap_revision = OMAP3430_REV_ES3_1;
rev_name = ES3.1;
break;
+ case 6:
+ omap_revision = OMAP3430_REV_ES3_1_1;
+ rev_name = ES3.1.1;
+ break;
default:
/* Use the latest known revision as default */
- omap_revision = OMAP3430_REV_ES3_1;
+ omap_revision = OMAP3430_REV_ES3_1_1;
rev_name = Unknown revision\n;
}
}
diff --git a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index 11e73d9..22cceb8 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -392,6 +392,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define OMAP3430_REV_ES2_1 0x34302034
#define OMAP3430_REV_ES3_0 0x34303034
#define OMAP3430_REV_ES3_1 0x34304034
+#define OMAP3430_REV_ES3_1_1 0x34306034
#define OMAP443X_CLASS 0x44300034
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Audio capture not working with AIC23/McBSP1 on OMAP3517
Hi, I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error Playback is working fine using the same combination. I have tried using another instance of AIC23 codec which uses McBSP2 and both playback capture works fine there. Has anyone faced this issue before? Any suggestions? Regards, Anuj Aggarwal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517
On Wed, Aug 26, 2009 at 06:30:52PM +0530, Aggarwal, Anuj wrote: I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error That suggests that DMA isn't happening - might be worth checking to see that clocks are being generated properly. Playback is working fine using the same combination. I have tried using another instance of AIC23 codec which uses McBSP2 and both playback capture works fine there. Has anyone faced this issue before? Any suggestions? Which kernel are you using? There are rather a lot of McBSP changes queued up for 2.6.32. If this ever worked in the past a git bisect might be interesting. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517
-Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Wednesday, August 26, 2009 6:34 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org Subject: Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517 On Wed, Aug 26, 2009 at 06:30:52PM +0530, Aggarwal, Anuj wrote: I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error That suggests that DMA isn't happening - might be worth checking to see that clocks are being generated properly. I am able to see the bit clock and frame sync coming properly. Playback is working fine using the same combination. I have tried using another instance of AIC23 codec which uses McBSP2 and both playback capture works fine there. Has anyone faced this issue before? Any suggestions? Which kernel are you using? There are rather a lot of McBSP changes queued up for 2.6.32. If this ever worked in the past a git bisect might be interesting. I am on 2.6.31-rc5. I have to check whether the new patches fix anything related to this. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517
Aggarwal, Anuj wrote: -Original Message- From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] Sent: Wednesday, August 26, 2009 6:34 PM To: Aggarwal, Anuj Cc: linux-omap@vger.kernel.org; alsa-de...@alsa-project.org Subject: Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517 On Wed, Aug 26, 2009 at 06:30:52PM +0530, Aggarwal, Anuj wrote: I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error That suggests that DMA isn't happening - might be worth checking to see that clocks are being generated properly. I am able to see the bit clock and frame sync coming properly. Playback is working fine using the same combination. I have tried using another instance of AIC23 codec which uses McBSP2 and both playback capture works fine there. Has anyone faced this issue before? Any suggestions? Which kernel are you using? There are rather a lot of McBSP changes queued up for 2.6.32. If this ever worked in the past a git bisect might be interesting. I am on 2.6.31-rc5. I have to check whether the new patches fix anything related to this. Not having the corect pinmux settings will also cause this issue as I found trying to get McBSP3 working. Graeme -- To unsubscribe from this list: send the line unsubscribe 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] usb: disable OTG AUTOIDLE only with omap3430
On Wed, Aug 26, 2009 at 2:47 PM, Gupta, Ajay Kumarajay.gu...@ti.com wrote: -Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of Woodruff, Richard Sent: Tuesday, May 19, 2009 12:53 AM To: Niilo Minkkinen; linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org; t...@atomide.com Subject: RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen Sent: Monday, May 18, 2009 9:54 AM Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. Richard/Niilo, This should also be applicable to 35xx (right?) and so we got to update the fix with below patch. Regards, Ajay Don't have access to spec/errata of 35xx just now ;). Could Richard confirm, if this also applies (as original comment said) . -niilo- == patch = There is an issue with MUSB AUTOIDLE as reported by Niilo Minkkinen in below commit. 9a4b5e36ce58febdd2039dd4d129ee7edf4f5536 usb: musb: disable OTG AUTOIDLE only with omap3430 As OMAP35x is just a variant of OMAP34xx chip thus the fix is also applicable for OMAP35x so updating it for OMAP35x. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/omap2430.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 453796c..ab8336d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -233,7 +233,7 @@ int __init musb_platform_init(struct musb *musb) * MUSB AUTOIDLE don't work in 3430. * Workaround by Richard Woodruff/TI */ - if (!cpu_is_omap3430()) + if (!cpu_is_omap3430() !cpu_is_omap35xx()) l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); -- 1.6.2.4 == Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-usb 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 -- - Niilo Minkkinen Kalhontie 69C 40950 MUURAME +358407324526 niilo.minkki...@iki.fi -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517
On Wed, 26 Aug 2009 14:03:56 +0100 Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Aug 26, 2009 at 06:30:52PM +0530, Aggarwal, Anuj wrote: I am trying to capture audio through LineIn on my OMAP3517 EVM, using AIC23 codec and McBSP1, and getting the following error: arecord: pcm_read:1529: read error: Input/output error That suggests that DMA isn't happening - might be worth checking to see that clocks are being generated properly. Playback is working fine using the same combination. What is exactly your configuration: Is the AIC23 master or slave, how is the McBSP1 is connected (it has additional FSR and CLKR pins compared to other ports) and is the pin muxing correct? I think I have tested the McBSP1 on Beagle but definitely only OMAP as a master since my codec was oscilloscope. Which kernel are you using? There are rather a lot of McBSP changes queued up for 2.6.32. If this ever worked in the past a git bisect might be interesting. Those recent patches should not any effect into this since they are mostly playing with the McBSP and DMA interfacing. What comes to my mind if muxing is correct and if codec is master, this might be related to those McBSP1 FSR and CLKR setup. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe 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] usb: disable OTG AUTOIDLE only with omap3430
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Niilo Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. Richard/Niilo, This should also be applicable to 35xx (right?) and so we got to update the fix with below patch. Regards, Ajay Don't have access to spec/errata of 35xx just now ;). Could Richard confirm, if this also applies (as original comment said) . There is an official errata on MUSB auto-idle not to be set: Errata 1.164 There might be NDA issues with sharing the errata document, and so cannot attach. I have not come across a public omap errata document yet. -niilo- == patch = There is an issue with MUSB AUTOIDLE as reported by Niilo Minkkinen in below commit. 9a4b5e36ce58febdd2039dd4d129ee7edf4f5536 usb: musb: disable OTG AUTOIDLE only with omap3430 As OMAP35x is just a variant of OMAP34xx chip thus the fix is also applicable for OMAP35x so updating it for OMAP35x. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/omap2430.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 453796c..ab8336d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -233,7 +233,7 @@ int __init musb_platform_init(struct musb *musb) * MUSB AUTOIDLE don't work in 3430. * Workaround by Richard Woodruff/TI */ - if (!cpu_is_omap3430()) + if (!cpu_is_omap3430() !cpu_is_omap35xx()) l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); -- 1.6.2.4 == Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-usb 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 -- - Niilo Minkkinen Kalhontie 69C 40950 MUURAME +358407324526 niilo.minkki...@iki.fi -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Audio capture not working with AIC23/McBSP1 on OMAP3517
On Wed, 26 Aug 2009 16:42:39 +0300
Jarkko Nikula jhnik...@gmail.com wrote:
Those recent patches should not any effect into this since they are
mostly playing with the McBSP and DMA interfacing. What comes to my
mind if muxing is correct and if codec is master, this might be related
to those McBSP1 FSR and CLKR setup.
Anuj: I think the issue is here that by default McBSP1 receiver is
using the CLKR and FSR pins and if those are not connected, then the
capture doesn't work. Can you try a patch below and add following lines
into your machine driver?
snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_CLKR_SRC_CLKX, 0,
SND_SOC_CLOCK_IN);
snd_soc_dai_set_sysclk(cpu_dai, OMAP_MCBSP_FSR_SRC_FSX, 0,
SND_SOC_CLOCK_IN);
Patch is compile tested only, generated against mainline 2.6.31-rc7 but should
apply to ALSA tree as well.
--
Jarkko
CUT HERE
From: Jarkko Nikula jhnik...@gmail.com
Subject: [PATCH] ASoC: OMAP: Add functionality to set CLKR and FSR sources in
McBSP DAI
The McBSP1 port in OMAP3 processors (I believe OMAP2 too but I don't have
specifications to check it) have additional CLKR and FSR pins for McBSP1
receiver. Reset default is that receiver is using bit clock and frame
sync signal from those pins but it is possible to configure to use
also CLKX and FSX pins as well. In fact, other McBSP ports are doing that
internally that transmitter and receiver share the CLKX and FSX.
Add functionaly that machine drivers can set the CLKR and FSR sources by
using the snd_soc_dai_set_sysclk.
Thanks to Aggarwal, Anuj anuj.aggar...@ti.com for reporting the issue.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
sound/soc/omap/omap-mcbsp.c | 41 +
sound/soc/omap/omap-mcbsp.h |4
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index a5d46a7..2ea2136 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -462,6 +462,40 @@ static int omap_mcbsp_dai_set_clks_src(struct
omap_mcbsp_data *mcbsp_data,
return 0;
}
+static int omap_mcbsp_dai_set_rcvr_src(struct omap_mcbsp_data *mcbsp_data,
+ int clk_id)
+{
+ int sel_bit, set = 0;
+ u16 reg = OMAP2_CONTROL_DEVCONF0;
+
+ if (cpu_class_is_omap1())
+ return -EINVAL; /* TODO: Can this be implemented for OMAP1? */
+ if (mcbsp_data-bus_id != 0)
+ return -EINVAL;
+
+ switch (clk_id) {
+ case OMAP_MCBSP_CLKR_SRC_CLKX:
+ set = 1;
+ case OMAP_MCBSP_CLKR_SRC_CLKR:
+ sel_bit = 3;
+ break;
+ case OMAP_MCBSP_FSR_SRC_FSX:
+ set = 1;
+ case OMAP_MCBSP_FSR_SRC_FSR:
+ sel_bit = 4;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (set)
+ omap_ctrl_writel(omap_ctrl_readl(reg) | (1 sel_bit), reg);
+ else
+ omap_ctrl_writel(omap_ctrl_readl(reg) ~(1 sel_bit), reg);
+
+ return 0;
+}
+
static int omap_mcbsp_dai_set_dai_sysclk(struct snd_soc_dai *cpu_dai,
int clk_id, unsigned int freq,
int dir)
@@ -484,6 +518,13 @@ static int omap_mcbsp_dai_set_dai_sysclk(struct
snd_soc_dai *cpu_dai,
case OMAP_MCBSP_SYSCLK_CLKR_EXT:
regs-pcr0 |= SCLKME;
break;
+
+ case OMAP_MCBSP_CLKR_SRC_CLKR:
+ case OMAP_MCBSP_CLKR_SRC_CLKX:
+ case OMAP_MCBSP_FSR_SRC_FSR:
+ case OMAP_MCBSP_FSR_SRC_FSX:
+ err = omap_mcbsp_dai_set_rcvr_src(mcbsp_data, clk_id);
+ break;
default:
err = -ENODEV;
}
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/omap/omap-mcbsp.h
index c8147aa..647d2f9 100644
--- a/sound/soc/omap/omap-mcbsp.h
+++ b/sound/soc/omap/omap-mcbsp.h
@@ -32,6 +32,10 @@ enum omap_mcbsp_clksrg_clk {
OMAP_MCBSP_SYSCLK_CLK, /* Internal ICLK */
OMAP_MCBSP_SYSCLK_CLKX_EXT, /* External CLKX pin */
OMAP_MCBSP_SYSCLK_CLKR_EXT, /* External CLKR pin */
+ OMAP_MCBSP_CLKR_SRC_CLKR, /* CLKR from CLKR pin */
+ OMAP_MCBSP_CLKR_SRC_CLKX, /* CLKR from CLKX pin */
+ OMAP_MCBSP_FSR_SRC_FSR, /* FSR from FSR pin */
+ OMAP_MCBSP_FSR_SRC_FSX, /* FSR from FSX pin */
};
/* McBSP dividers */
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430
Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. Richard/Niilo, This should also be applicable to 35xx (right?) and so we got to update the fix with below patch. Regards, Ajay Don't have access to spec/errata of 35xx just now ;). Could Richard confirm, if this also applies (as original comment said) . There is an official errata on MUSB auto-idle not to be set: Errata 1.164 Vikram, This Errata is also applicable on 35xx and so we need to update the AUTOIDLE fix in musb for 35xx. -Ajay There might be NDA issues with sharing the errata document, and so cannot attach. I have not come across a public omap errata document yet. -niilo- == patch = There is an issue with MUSB AUTOIDLE as reported by Niilo Minkkinen in below commit. 9a4b5e36ce58febdd2039dd4d129ee7edf4f5536 usb: musb: disable OTG AUTOIDLE only with omap3430 As OMAP35x is just a variant of OMAP34xx chip thus the fix is also applicable for OMAP35x so updating it for OMAP35x. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/omap2430.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 453796c..ab8336d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -233,7 +233,7 @@ int __init musb_platform_init(struct musb *musb) * MUSB AUTOIDLE don't work in 3430. * Workaround by Richard Woodruff/TI */ - if (!cpu_is_omap3430()) + if (!cpu_is_omap3430() !cpu_is_omap35xx()) l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); -- 1.6.2.4 == Regards, Richard W. -- To unsubscribe from this list: send the line unsubscribe linux-usb 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 -- - Niilo Minkkinen Kalhontie 69C 40950 MUURAME +358407324526 niilo.minkki...@iki.fi -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Kevin
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Saturday, August 22, 2009 2:57 AM
To: Pandita, Vikram
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk
Subject: Re: [PATCH 1/5] OMAP1/2/3/4: DEBUG_LL: cleanup
Vikram Pandita wrote:
This patch cleans up the DEBUG_LL infrastructure for omap boards.
Thanks Vikram, this is indeed in need of some cleanup. But I have some
comments about the approach taken.
This approach still doesn't solve one of the fundamental problems with
the current implementation. It prevents using a single kernel across
multiple boards. If we could drop the compile-time decision in favor of
a runtime one based on machine-type, we could use a single base
defconfig that would be able to be tested on all omap3 boards for example.
For the zImage UART output (uncompress.h) there is a global variable
__machine_arch_type which could be used to check the board type and set
variable for UART base and shift. We do this on DaVinci.
Could you give reference to this code on DaVinci?
Yes this is doable, but the question is, how do we pass these variables to the
kernel start:
arch/arm/kernel/head.S
First stage, arch/arm/boot/compressed/head.S gets the arch type -
shift/uart-addr. Fine.
This stage ends with relocated code over righting the decompressor.
Second stage, arch/arm/kernel/head.S now starts.
I am not sure how to share the data from Stage 1 in this stage?
For debug output (debug-macro.S) those macros should be changed to use
variables for UART base and shift also. While you're in changing the
board files, you could also add something like this to each:
#ifdef CONFIG_SERIAL_8250_CONSOLE
static int __init board_console_init(void)
{
return add_preferred_console(ttyS, UART#, 115200);
}
console_initcall(board_console_init);
#endif
This also allows the board to boot using a default UART even without
having the console= on the cmdline.
There is one catch to doing this at runtime instead of compile time.
The variables for the UART base and shift have to be set very early in
the boot, otherwise any errors from the early ARM asm boot (head.S) will
be missed.
For starters, they could be assingned in the board map_io hook, but we'd
still miss the debug prints if there were any errors parsing the
machine_type and processor_type early in the boot (head.S)
I'd be ok with this limitation for a first pass because it's still
better than what we currently have in l-o, but I'd like to hear if
others had some ideas for how we might do dynamic decisions on UART
based on board-type very early in the boot.
Kevin
The three stages of log printing infrastructure is using their own #defines
The patch integrates the three stages to use the same variable.
Three stages are:
Stage 1: Prints - Uncompressing Linux..
File getting used: arch/arm/plat-omap/include/mach/uncompress.h
Stage 2: Prints - 5Linux version 2.6.31
File getting used: arch/arm/plat-omap/include/mach/debug-macro.S
Stage 3: Kernel ttyS console takes over
On enabling the DEBUG_LL menuconfig item
[Kernel Hacking - Kernel low-level debugging functions]
the following entry gets auto selected
[Systerm Type - TI OMAP Implementations - Low-level Debug console UART]
This is the physical address of the UART getting used for the board.
The physical address of debug uart is provided as a menuconfig option now.
Issue with current system:
(a) Zoom2 board has a detachable debug board having the TL16CP754 Quad uart
chip.
If the debug board is not attached, _NO_ debug uart is available.
OMAP internal uarts are not used for traces on zoom2 board.
Current framework does not account for boards that may not have a debug uart
at all. The Stage 1 always accesses one of the uarts. Thats fixed now.
(b) this patch does a cleanup of
arch/arm/plat-omap/include/mach/debug-macro.S
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
---
arch/arm/plat-omap/Kconfig| 50
++---
arch/arm/plat-omap/include/mach/common.h |7 +++
arch/arm/plat-omap/include/mach/debug-macro.S | 40
arch/arm/plat-omap/include/mach/uncompress.h | 12 +
4 files changed, 54 insertions(+), 55 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ab9f9ef..2fefb64 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -162,21 +162,43 @@ config OMAP_DM_TIMER
help
Select this option if you want to use OMAP Dual-Mode timers.
-choice
-prompt Low-level debug console UART
-depends on ARCH_OMAP
-default OMAP_LL_DEBUG_UART1
-
-config OMAP_LL_DEBUG_UART1
-bool UART1
-
-config OMAP_LL_DEBUG_UART2
-bool UART2
-config OMAP_LL_DEBUG_UART3
-bool UART3
-
-endchoice
+config OMAP_DEBUG_LL_UART_PHY_ADDR
+hex Low-level debug console UART Physical Address
+depends on ARCH_OMAP DEBUG_LL
