From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: Jarkko Nikula <jhnikula@gmail.com>,
Arun K S <arunks@mistralsolutions.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix
Date: Wed, 05 Aug 2009 15:14:42 +0200 [thread overview]
Message-ID: <4A7985C2.1040403@tis.icnet.pl> (raw)
In-Reply-To: <200908050945.22160.peter.ujfalusi@nokia.com>
Hi,
Peter Ujfalusi wrote:
> On Tuesday 04 August 2009 23:46:09 ext Janusz Krzysztofik wrote:
>
>> For both playback start while capturing and capture start while playing,
>> XSYNC_ERR/RSYNC_ERR is clear
>> and XRDY/RRDY is ready,
>
> This means that XRDY/RRDY is set (1)?
Yes, trasmit/recieve confirmed at first while(!(readw(...) & XRDY/RRDY))
attempt.
> In case of playback start while capture: What is the state of the XEMPTY bit
> (SPCR2:2)? Is it 0? It should.
Have not checked, but will do for completness.
> I think the reason is quite simple: on OMAP1 the DMA request is edge sensitive
> (compared to OMAP2 and OMAP3 where it is level based). This means:
Good recap.
> The danger with the pollwrite/pollread is:
> If the stream is not mono, than you kind of ensure a certain channel shift
> (channel switch in case of stereo stream).
Good point, I was trying break all not mono.
>> If my analysis is correct, the best solution I can see would be starting
>> McBSP transfer for one direction only, not both, so the opposite direction
>> can be started when needed. That requires deeper and wider OMAP knowledge
>> and a change in omap_mcbsp_start() API though. I am not in a position to
>> deal with this myself, I'm afraid.
>
> I agree, this would be the best solution for the problem.
I was also considering omap_mcbsp_restart(id, direction) as a more
conservative solution, but now, after Jarkko has subbmitted his patch on
omap_mcbsp_start(), it's not an option any longer, I think.
Cheers,
Janusz
next prev parent reply other threads:[~2009-08-05 13:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-03 1:32 [RFC] [PATCH] ASoC: OMAP: full duplex mode fix Janusz Krzysztofik
2009-08-03 8:29 ` Jarkko Nikula
2009-08-03 9:43 ` Mark Brown
2009-08-03 14:00 ` Janusz Krzysztofik
2009-08-03 15:14 ` Jarkko Nikula
2009-08-04 20:46 ` Janusz Krzysztofik
2009-08-05 6:45 ` Peter Ujfalusi
2009-08-05 13:14 ` Janusz Krzysztofik [this message]
2009-08-06 9:30 ` Janusz Krzysztofik
2009-08-05 7:21 ` Jarkko Nikula
2009-08-05 8:42 ` Jarkko Nikula
2009-08-05 13:26 ` Janusz Krzysztofik
2009-08-06 0:27 ` Janusz Krzysztofik
2009-08-06 9:16 ` Janusz Krzysztofik
2009-08-03 17:53 ` Arun KS
2009-08-03 17:57 ` Arun KS
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=4A7985C2.1040403@tis.icnet.pl \
--to=jkrzyszt@tis.icnet.pl \
--cc=alsa-devel@alsa-project.org \
--cc=arunks@mistralsolutions.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=jhnikula@gmail.com \
--cc=linux-omap@vger.kernel.org \
--cc=peter.ujfalusi@nokia.com \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox