* DaVinci ASoC DMA stalls
@ 2008-09-04 13:39 Mark Lokowich
[not found] ` <48BFE50E.3000802-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Mark Lokowich @ 2008-09-04 13:39 UTC (permalink / raw)
To: ALSA-devel, davinci-linux-open-source
I've been using the DaVinci ASoC for a few months and have recently
upgraded to the 2.6.26 based DaVinci git kernel. Now my audio DMA
stalls more readily after stopping an active stream. I can manually
trigger the event by poking the ESR to reactivate the stalled stream,
suggesting the problem is in the ASP-to-DMA XEVT interface. This
problem is less prevalent in the 2.6.25 based kernel. Any help?
Regards,
Mark Lokowich
Advanced Communication Design
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <48BFE50E.3000802-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org>]
* Re: DaVinci ASoC DMA stalls [not found] ` <48BFE50E.3000802-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org> @ 2008-09-04 17:06 ` Caglar Akyuz 2008-09-04 22:23 ` Mark Lokowich 0 siblings, 1 reply; 5+ messages in thread From: Caglar Akyuz @ 2008-09-04 17:06 UTC (permalink / raw) To: Mark Lokowich; +Cc: ALSA-devel, davinci-linux-open-source Mark Lokowich wrote: > I've been using the DaVinci ASoC for a few months and have recently > upgraded to the 2.6.26 based DaVinci git kernel. Now my audio DMA > stalls more readily after stopping an active stream. I can manually > trigger the event by poking the ESR to reactivate the stalled stream, > suggesting the problem is in the ASP-to-DMA XEVT interface. This > problem is less prevalent in the 2.6.25 based kernel. Any help? > I don't know if this helps but, I am using ASoC code on my DaVinci board with latest git kernel(2.6.27) and I have no visible issues with the ASoC code. However, there may be some code-coverage issue with my usage so if you have any test method to verify that I really don't have your problem I'll be happy to perform some tests. My real concern is that this code has never been built without any problems here. First there was a separate asoc branch in davinci tree which failed to built. I tried with 2.6.25 and there was again build issues. Finally I wasn't able to build ASoC code with 2.6.27 so I tried to patch it. I think some part of it relies on some dma code which is not present in davinci tree.[1] I don't know if everybody else is patching kernel source to build asoc support, maybe I'm doing something wrong. I'm not sure, just FYI. Regards, Caglar [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2008-March/005920.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DaVinci ASoC DMA stalls 2008-09-04 17:06 ` Caglar Akyuz @ 2008-09-04 22:23 ` Mark Lokowich [not found] ` <48C05FFD.4030009-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Mark Lokowich @ 2008-09-04 22:23 UTC (permalink / raw) To: Caglar Akyuz; +Cc: ALSA-devel, davinci-linux-open-source I did have to add a getposition accessor to the DaVinci DMA module, which is used by the pcm_pointer function. Other than that, I believe the ASoC should build. My test is simply to run aplay or speaker-test, then quit and run it again. The first run is audible, the second and subsequent runs are not audible until I provide a manual DMA event trigger. Mark Caglar Akyuz wrote: > Mark Lokowich wrote: > > >> I've been using the DaVinci ASoC for a few months and have recently >> upgraded to the 2.6.26 based DaVinci git kernel. Now my audio DMA >> stalls more readily after stopping an active stream. I can manually >> trigger the event by poking the ESR to reactivate the stalled stream, >> suggesting the problem is in the ASP-to-DMA XEVT interface. This >> problem is less prevalent in the 2.6.25 based kernel. Any help? >> >> > > > I don't know if this helps but, I am using ASoC code on my DaVinci board > with latest git kernel(2.6.27) and I have no visible issues with the ASoC > code. However, there may be some code-coverage issue with my usage so if you > have any test method to verify that I really don't have your problem I'll > be happy to perform some tests. > > My real concern is that this code has never been built without any problems here. > First there was a separate asoc branch in davinci tree which failed to built. > I tried with 2.6.25 and there was again build issues. Finally I wasn't able to > build ASoC code with 2.6.27 so I tried to patch it. I think some part of it > relies on some dma code which is not present in davinci tree.[1] I don't know > if everybody else is patching kernel source to build asoc support, maybe I'm > doing something wrong. I'm not sure, just FYI. > > Regards, > Caglar > > [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2008-March/005920.html > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <48C05FFD.4030009-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org>]
* RE: DaVinci ASoC DMA stalls [not found] ` <48C05FFD.4030009-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org> @ 2008-09-09 11:52 ` Griffis, Brad 2008-09-19 22:06 ` Mark Lokowich 0 siblings, 1 reply; 5+ messages in thread From: Griffis, Brad @ 2008-09-09 11:52 UTC (permalink / raw) To: Mark Lokowich; +Cc: ALSA-devel, davinci-linux-open-source > My test is simply to run aplay or speaker-test, > then quit and run it again. The first run is audible, the second and > subsequent runs are not audible until I provide a manual DMA event trigger. When the ASP transmitter is taken out of reset it sends XEVT to the EDMA where it is "captured" in event register (ER). If that event gets cleared out before turning on the EDMA you'll end up with a scenario like you described, i.e. once you kick off a transfer manually it will then run. I haven't looked at the code you're using, but it sounds to me like the (re-)initialization sequence isn't correct. The best way for the code to work would be for the EDMA to be configured BEFORE the McBSP. That way, even if the EDMA initialization procedure clears the ER bits it won't matter because when the McBSP is subsequently released from reset it will send a new XEVT to the EDMA. Brad ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DaVinci ASoC DMA stalls 2008-09-09 11:52 ` Griffis, Brad @ 2008-09-19 22:06 ` Mark Lokowich 0 siblings, 0 replies; 5+ messages in thread From: Mark Lokowich @ 2008-09-19 22:06 UTC (permalink / raw) To: Griffis, Brad; +Cc: ALSA-devel, davinci-linux-open-source Griffis, Brad wrote: >> My test is simply to run aplay or speaker-test, >> then quit and run it again. The first run is audible, the second and >> subsequent runs are not audible until I provide a manual DMA event trigger. >> > > When the ASP transmitter is taken out of reset it sends XEVT to the EDMA where it is "captured" in event register (ER). If that event gets cleared out before turning on the EDMA you'll end up with a scenario like you described, i.e. once you kick off a transfer manually it will then run. I haven't looked at the code you're using, but it sounds to me like the (re-)initialization sequence isn't correct. > > The best way for the code to work would be for the EDMA to be configured BEFORE the McBSP. That way, even if the EDMA initialization procedure clears the ER bits it won't matter because when the McBSP is subsequently released from reset it will send a new XEVT to the EDMA. > > Brad > > Excellent tip, but the ASoC software is doing just what you suggested, starting the DMA prior to starting the ASP. I also found that the latest DMA software also causes buffer underruns when playing Ogg Vorbis files, while the 2.6.25 version doesn't have these issues. I'll keep looking. Thanks, Mark > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-09-19 22:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-04 13:39 DaVinci ASoC DMA stalls Mark Lokowich
[not found] ` <48BFE50E.3000802-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org>
2008-09-04 17:06 ` Caglar Akyuz
2008-09-04 22:23 ` Mark Lokowich
[not found] ` <48C05FFD.4030009-3mWahjwryh5BDgjK7y7TUQ@public.gmane.org>
2008-09-09 11:52 ` Griffis, Brad
2008-09-19 22:06 ` Mark Lokowich
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.