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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
