From: Karl Beldan <karl.beldan@gmail.com>
To: Mark Brown <broonie@sirena.org.uk>
Cc: Russell King <linux@arm.linux.org.uk>,
alsa-devel@alsa-project.org, Eric Miao <eric.miao@marvell.com>,
linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
Matthieu Dumont <matthieu.dumont@mobile-devices.fr>
Subject: Re: [PATCH 2/4] pxa2xx-i2s: Handle SACR1_DRPL and SACR1_DREC separately
Date: Tue, 12 May 2009 19:43:04 +0200 [thread overview]
Message-ID: <4A09B528.9050109@gmail.com> (raw)
In-Reply-To: <20090512160229.GK29889@sirena.org.uk>
Mark Brown wrote:
> On Fri, May 08, 2009 at 01:53:47AM +0200, Karl Beldan wrote:
>
>> - hw_params enables both RPL and REC functions each time,
>> enable the appropriate function in pxa2xx_i2s_trigger.
>> - pxa2xx_i2s_shutdown disables i2s anytime one of RPL or REC
>> function is off, turn it off only when both functions are off.
>> - do not put the clk_i2s for no reason in pxa2xx_i2s_shutdown.
>
>> Signed-off-by: Karl Beldan <karl.beldan@mobile-devices.fr>
>
> I'm still seeing the behaviour I was before now I've applied patch 1.
> To reproduce I'm looking at the clocks with a scope. After startup I'm
> starting a playback (aplay and mplayer have the same effect). Once the
> playback is finished (either normally or by killing the application) the
> clocks are still present. Restarting playback causes the clock to stop
> immediately and the generation of a DMA error. Subsequent iterations
> repeat the same behaviour, as does recording.
>
>> case SNDRV_PCM_TRIGGER_RESUME:
>> @@ -252,13 +254,11 @@ static void pxa2xx_i2s_shutdown(struct snd_pcm_substream *substream,
>> SAIMR &= ~SAIMR_RFS;
>> }
>>
>> - if (SACR1 & (SACR1_DREC | SACR1_DRPL)) {
>> + if ((SACR1 & (SACR1_DREC | SACR1_DRPL)) == (SACR1_DREC | SACR1_DRPL)) {
>> SACR0 &= ~SACR0_ENB;
>> pxa_i2s_wait();
>> clk_disable(clk_i2s);
>> }
>
> The problem happens because this code no longer triggers - since the
> port is still being reset on startup if the DAI is inactive the first
> patch will have no effect on DREC and DRPL, they'll be reset to their
> power on default of enabled when startup() is first called. Applying
> your third patch which removes the port reset avoids that issue.
>
Indeed, I should have put the port reset in 2/4 or in 1/4 rather than in
3/4 !
> Unfortunately there's still the outstanding issue with the third patch
> removing the FIFO flushes - looking at the datasheet I think we do need
> to clear the FIFOs, especially in the case where the PXA is running as
> slave and might've had clocks removed. Section 14.4.7.2 explicitly says
> there are situations where the FIFO might not be drained and I'd really
> not be surprised if there were others.
>
> I'm out of time to look at this today - I expect that the fix is
> probably to move some version of the port reset change into this patch.
I'd go for moving port reset into 2/4 (or 1/4 ?), 3/4 would just remove
clk_disable(clk_i2s) and leave the FIFO flushes as is, and keeping 4/4.
What do you say ?
--
Karl
next prev parent reply other threads:[~2009-05-12 17:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-07 23:53 [PATCH 2/4] pxa2xx-i2s: Handle SACR1_DRPL and SACR1_DREC separately Karl Beldan
2009-05-08 10:42 ` Mark Brown
2009-05-08 19:24 ` Karl Beldan
2009-05-11 19:05 ` Mark Brown
2009-05-11 19:43 ` Karl Beldan
2009-05-11 21:07 ` Mark Brown
2009-05-11 22:00 ` Karl Beldan
2009-05-12 8:58 ` Mark Brown
2009-05-12 9:59 ` Karl Beldan
2009-05-12 10:32 ` Mark Brown
2009-05-12 12:38 ` Karl Beldan
2009-05-12 14:34 ` Mark Brown
2009-05-12 16:02 ` Mark Brown
2009-05-12 17:43 ` Karl Beldan [this message]
2009-05-12 21:50 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2009-05-13 20:04 Karl Beldan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A09B528.9050109@gmail.com \
--to=karl.beldan@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@sirena.org.uk \
--cc=eric.miao@marvell.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux@arm.linux.org.uk \
--cc=matthieu.dumont@mobile-devices.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.