Re: [RFC] [PATCH] ASoC: OMAP: full duplex mode fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux