[PATCH 0/2] ARM: OMAP4: Audio regression fix for 3.8 kernel

[PATCH 0/2] ARM: OMAP4: Audio regression fix for 3.8 kernel

[Peter Ujfalusi]

Hello,

I have noticed that in 3.8-rc2 kernel OMAP4 audio is not working correctly. The
audio playback is in 'slow motion' mode.
The following two patch fixes this regression.

We need to lock the ABE DPLL for all OMAP4 revisions not only for 446x and McPDM
need to be configured to no IDLE mode during activity.

Regards,
Peter
---
Peter Ujfalusi (2):
  ARM: OMAP4: clock data: ABE DPLL need to be locked on all revisions
  ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM

 arch/arm/mach-omap2/cclock44xx_data.c      | 14 ++++++--------
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |  2 +-
 2 files changed, 7 insertions(+), 9 deletions(-)

-- 
1.8.0.2

[PATCH 1/2] ARM: OMAP4: clock data: ABE DPLL need to be locked on all revisions

[Peter Ujfalusi]

We need to lock ABE DPPL on al OMAP4 revisions, not only for OMAP446x

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/cclock44xx_data.c | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
index 5789a5e..79c32ce 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -2023,17 +2023,15 @@ int __init omap4xxx_clk_init(void)
 				     ARRAY_SIZE(enable_init_clks));
 
 	/*
-	 * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
+	 * On OMAP4 the ABE DPLL fails to turn on if in idle low-power
 	 * state when turning the ABE clock domain. Workaround this by
 	 * locking the ABE DPLL on boot.
 	 */
-	if (cpu_is_omap446x()) {
-		rc = clk_set_parent(&abe_dpll_refclk_mux_ck, &sys_32k_ck);
-		if (!rc)
-			rc = clk_set_rate(&dpll_abe_ck, OMAP4_DPLL_ABE_DEFFREQ);
-		if (rc)
-			pr_err("%s: failed to configure ABE DPLL!\n", __func__);
-	}
+	rc = clk_set_parent(&abe_dpll_refclk_mux_ck, &sys_32k_ck);
+	if (!rc)
+		rc = clk_set_rate(&dpll_abe_ck, OMAP4_DPLL_ABE_DEFFREQ);
+	if (rc)
+		pr_err("%s: failed to configure ABE DPLL!\n", __func__);
 
 	return 0;
 }
-- 
1.8.0.2

[PATCH 2/2] ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM

[Peter Ujfalusi]

McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 129d508..584acf9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2133,7 +2133,7 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
 	 * available, so it doesn't seem that we have any choice in
 	 * the kernel other than to avoid resetting it.
 	 */
-	.flags		= HWMOD_EXT_OPT_MAIN_CLK,
+	.flags		= HWMOD_EXT_OPT_MAIN_CLK | HWMOD_SWSUP_SIDLE,
 	.mpu_irqs	= omap44xx_mcpdm_irqs,
 	.sdma_reqs	= omap44xx_mcpdm_sdma_reqs,
 	.main_clk	= "mcpdm_fck",
-- 
1.8.0.2

[PATCH 0/2] ARM: OMAP4: Audio regression fix for 3.8 kernel

[Paul Walmsley]

Hi P?ter

On Thu, 3 Jan 2013, Peter Ujfalusi wrote:

> I have noticed that in 3.8-rc2 kernel OMAP4 audio is not working correctly. The
> audio playback is in 'slow motion' mode.
> The following two patch fixes this regression.
> 
> We need to lock the ABE DPLL for all OMAP4 revisions not only for 446x and McPDM
> need to be configured to no IDLE mode during activity.

Thanks, both queued for 3.8-rc fixes.

- Paul

[PATCH 1/2] ARM: OMAP4: clock data: ABE DPLL need to be locked on all revisions

[Jon Hunter]

Hi Peter,

On 01/03/2013 07:46 AM, Peter Ujfalusi wrote:
> We need to lock ABE DPPL on al OMAP4 revisions, not only for OMAP446x
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  arch/arm/mach-omap2/cclock44xx_data.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c
> index 5789a5e..79c32ce 100644
> --- a/arch/arm/mach-omap2/cclock44xx_data.c
> +++ b/arch/arm/mach-omap2/cclock44xx_data.c
> @@ -2023,17 +2023,15 @@ int __init omap4xxx_clk_init(void)
>  				     ARRAY_SIZE(enable_init_clks));
>  
>  	/*
> -	 * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
> +	 * On OMAP4 the ABE DPLL fails to turn on if in idle low-power
>  	 * state when turning the ABE clock domain. Workaround this by
>  	 * locking the ABE DPLL on boot.

I am not sure that this change to the comment is completely accurate. On
OMAP4430 I did not see any issues with the DPLL failing to turn on if
the DPLL was not locked. I only saw this particular problem on the 4460.
Therefore, it may be better to leave the comment as-is and add an
additional sentence to state that the DPLL should be locked for all
OMAP4 devices for audio to work correctly.

Cheers
Jon

[PATCH 1/2] ARM: OMAP4: clock data: ABE DPLL need to be locked on all revisions

[Paul Walmsley]

On Thu, 3 Jan 2013, Jon Hunter wrote:

> I am not sure that this change to the comment is completely accurate. On
> OMAP4430 I did not see any issues with the DPLL failing to turn on if
> the DPLL was not locked. I only saw this particular problem on the 4460.
> Therefore, it may be better to leave the comment as-is and add an
> additional sentence to state that the DPLL should be locked for all
> OMAP4 devices for audio to work correctly.

Makes sense to me; what do you think, P?ter?

- Paul

[PATCH 1/2] ARM: OMAP4: clock data: ABE DPLL need to be locked on all revisions

[Peter Ujfalusi]

On 01/04/2013 12:26 AM, Paul Walmsley wrote:
> On Thu, 3 Jan 2013, Jon Hunter wrote:
> 
>> I am not sure that this change to the comment is completely accurate. On
>> OMAP4430 I did not see any issues with the DPLL failing to turn on if
>> the DPLL was not locked. I only saw this particular problem on the 4460.
>> Therefore, it may be better to leave the comment as-is and add an
>> additional sentence to state that the DPLL should be locked for all
>> OMAP4 devices for audio to work correctly.
> 
> Makes sense to me; what do you think, P?ter?

OK, I'll resend the series with the proposed comment.

-- 
P?ter