Searched hist:"98 e1241c" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/sound/soc/cirrus/ |
H A D | Kconfig | 98e1241c Sat Apr 28 15:51:42 CDT 2018 Alexander Sverdlin <alexander.sverdlin@gmail.com> ASoC: cirrus: i2s: IRQ-based stream watchdog
I2S controller on EP93xx seems to have undocumented HW issue. According to "EP93xx User’s Guide", controller can handle underflow and either transmit last sample or zeroes in such case until FIFO is filled again. In reality undeflow conditions seem to confuse internal state machine from time to time and the whole stream gets shifted by one byte (as captured by logic analyser on the I2S outputs). One could only hear noise instead of original stream and this continues until the FIFO is disabled and enabled again.
Work this around by watching underflow interrupt and resetting I2S TX channel + fill FIFO with zero samples until DMA catches up again. This is a nasty workaround, but it works. Hence, Kconfig option to disable it in case of problems.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> 98e1241c Sat Apr 28 15:51:42 CDT 2018 Alexander Sverdlin <alexander.sverdlin@gmail.com> ASoC: cirrus: i2s: IRQ-based stream watchdog I2S controller on EP93xx seems to have undocumented HW issue. According to "EP93xx User’s Guide", controller can handle underflow and either transmit last sample or zeroes in such case until FIFO is filled again. In reality undeflow conditions seem to confuse internal state machine from time to time and the whole stream gets shifted by one byte (as captured by logic analyser on the I2S outputs). One could only hear noise instead of original stream and this continues until the FIFO is disabled and enabled again. Work this around by watching underflow interrupt and resetting I2S TX channel + fill FIFO with zero samples until DMA catches up again. This is a nasty workaround, but it works. Hence, Kconfig option to disable it in case of problems. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
H A D | ep93xx-i2s.c | 98e1241c Sat Apr 28 15:51:42 CDT 2018 Alexander Sverdlin <alexander.sverdlin@gmail.com> ASoC: cirrus: i2s: IRQ-based stream watchdog
I2S controller on EP93xx seems to have undocumented HW issue. According to "EP93xx User’s Guide", controller can handle underflow and either transmit last sample or zeroes in such case until FIFO is filled again. In reality undeflow conditions seem to confuse internal state machine from time to time and the whole stream gets shifted by one byte (as captured by logic analyser on the I2S outputs). One could only hear noise instead of original stream and this continues until the FIFO is disabled and enabled again.
Work this around by watching underflow interrupt and resetting I2S TX channel + fill FIFO with zero samples until DMA catches up again. This is a nasty workaround, but it works. Hence, Kconfig option to disable it in case of problems.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> 98e1241c Sat Apr 28 15:51:42 CDT 2018 Alexander Sverdlin <alexander.sverdlin@gmail.com> ASoC: cirrus: i2s: IRQ-based stream watchdog I2S controller on EP93xx seems to have undocumented HW issue. According to "EP93xx User’s Guide", controller can handle underflow and either transmit last sample or zeroes in such case until FIFO is filled again. In reality undeflow conditions seem to confuse internal state machine from time to time and the whole stream gets shifted by one byte (as captured by logic analyser on the I2S outputs). One could only hear noise instead of original stream and this continues until the FIFO is disabled and enabled again. Work this around by watching underflow interrupt and resetting I2S TX channel + fill FIFO with zero samples until DMA catches up again. This is a nasty workaround, but it works. Hence, Kconfig option to disable it in case of problems. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|