summaryrefslogtreecommitdiff
path: root/sound/soc/sh/fsi.c
diff options
context:
space:
mode:
authorSudhakar Rajashekhara <sudhakar.raj@ti.com>2010-06-11 13:54:51 (GMT)
committerMark Brown <broonie@opensource.wolfsonmicro.com>2010-06-15 10:53:18 (GMT)
commit5b61ea499727f22ebdaaeedb9801b12ed6eb59c7 (patch)
tree051fa95b13b233e753bc5db315a6952c6c2b4465 /sound/soc/sh/fsi.c
parente854df613fe934c94a0b39eccb4104e72ccbbded (diff)
downloadlinux-5b61ea499727f22ebdaaeedb9801b12ed6eb59c7.tar.xz
ASoC: DaVinci: Fix McASP hardware FIFO configuration
On DA830/OMAP-L137 and DA850/OMAP-L138 SoCs, the McASP peripheral has FIFO support. This FIFO provides additional data buffering. It also provides tolerance to variation in host/DMA controller response times. More details of the FIFO operation can be found at http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprufm1&fileType=pdf Existing sequence of steps for audio playback/capture are: a. DMA configuration b. McASP configuration (configures and enables FIFO) c. Start DMA d. Start McASP (enables FIFO) During McASP configuration, while FIFO was being configured, FIFO was being enabled in davinci_hw_common_param() function of sound/soc/davinci/davinci-mcasp.c file. This generated a transmit DMA event, which gets serviced when DMA is started. https://patchwork.kernel.org/patch/84611/ patch clears the DMA events before starting DMA, which is the right thing to do. But this resulted in a state where DMA was waiting for an event from McASP (after step c above), but the event which was already there, has got cleared (because of step b above). The fix is not to enable the FIFO during McASP configuration as FIFO was being enabled as part of McASP start. Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Diffstat (limited to 'sound/soc/sh/fsi.c')
0 files changed, 0 insertions, 0 deletions