| Message ID | 20201116061905.32431-1-michael.wei.hong.sit@intel.com |
|---|---|
| Headers | show |
| Series | This patch series enables DMA mode on Intel Keem Bay platform | expand |
On Mon, Nov 16, 2020 at 02:19:03PM +0800, Michael Sit Wei Hong wrote: > In the Intel KeemBay solution, the DW AXI-based DMA has a limitation on > the number of DMA blocks per transfer. In the case of 16 bit audio ASoC > would allocate blocks exceeding the DMA block limitation. > The ASoC layers are not aware of such DMA limitation, and the DMA engine > does not provide an API to set the maximum number of blocks per linked link. Can we not extend the dmaengine API so that the ASoC layer (and any other users) can become aware of this limitation and handle it appropriately rather than jumping straight to some client driver specific handling?
On 11/16/20 1:58 PM, Mark Brown wrote: > On Mon, Nov 16, 2020 at 02:19:03PM +0800, Michael Sit Wei Hong wrote: > >> In the Intel KeemBay solution, the DW AXI-based DMA has a limitation on >> the number of DMA blocks per transfer. In the case of 16 bit audio ASoC >> would allocate blocks exceeding the DMA block limitation. > >> The ASoC layers are not aware of such DMA limitation, and the DMA engine >> does not provide an API to set the maximum number of blocks per linked link. > > Can we not extend the dmaengine API so that the ASoC layer (and any > other users) can become aware of this limitation and handle it > appropriately rather than jumping straight to some client driver > specific handling? This was supposed to be an RFC, I asked Vinod/Lars to be copied for feedback. Unfortunately the RFC tag is missing and Vinod's email wasn't the right one... (fixed now). This patchset suggests an ALSA-only quirk, having other more generic means to deal with this limitation would be fine - we just wanted to have a discussion on preferred directions. The IPs used are not Intel-specific so sooner or later someone else will have similar limitations to work-around.
On Mon, Nov 16, 2020 at 02:10:16PM -0600, Pierre-Louis Bossart wrote: > On 11/16/20 1:58 PM, Mark Brown wrote: > > On Mon, Nov 16, 2020 at 02:19:03PM +0800, Michael Sit Wei Hong wrote: > > Can we not extend the dmaengine API so that the ASoC layer (and any > > other users) can become aware of this limitation and handle it > > appropriately rather than jumping straight to some client driver > > specific handling? > This was supposed to be an RFC, I asked Vinod/Lars to be copied for > feedback. Unfortunately the RFC tag is missing and Vinod's email wasn't the > right one... (fixed now). > This patchset suggests an ALSA-only quirk, having other more generic means > to deal with this limitation would be fine - we just wanted to have a > discussion on preferred directions. The IPs used are not Intel-specific so > sooner or later someone else will have similar limitations to work-around. Generally with the dmaengine stuff we've added new query APIs to dmaengine and then used those in the ALSA/ASoC code to enumerate things, this certainly sounds like something that another device might have so it seems worth following that approach.
On Mon, 16 Nov 2020 14:19:00 +0800, Michael Sit Wei Hong wrote: > v1: Initial patch version, which contains fix for S24_LE format and also enable > DMA mode on Intel Keembay platform > > Michael Sit Wei Hong (5): > ASoC: Intel: KMB: Fix S24_LE configuration > dt-bindings: sound: intel, keembay-i2s: Add info for device to use DMA > ASoC: soc-generic-dmaengine-pcm: Add custom prepare and submit > function > ASoC: dmaengine_pcm: expose functions to header file for custom > functions > ASoC: Intel: KMB: Enable DMA transfer mode > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: Intel: KMB: Fix S24_LE configuration commit: 1bd7b0fc0165694897b7d2fb39751a07b98f6bf1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
v1: Initial patch version, which contains fix for S24_LE format and also enable DMA mode on Intel Keembay platform Michael Sit Wei Hong (5): ASoC: Intel: KMB: Fix S24_LE configuration dt-bindings: sound: intel, keembay-i2s: Add info for device to use DMA ASoC: soc-generic-dmaengine-pcm: Add custom prepare and submit function ASoC: dmaengine_pcm: expose functions to header file for custom functions ASoC: Intel: KMB: Enable DMA transfer mode .../bindings/sound/intel,keembay-i2s.yaml | 14 ++ include/sound/dmaengine_pcm.h | 21 ++ sound/core/pcm_dmaengine.c | 46 ++-- sound/soc/intel/Kconfig | 2 + sound/soc/intel/keembay/kmb_platform.c | 208 ++++++++++++++++-- sound/soc/intel/keembay/kmb_platform.h | 9 + sound/soc/soc-generic-dmaengine-pcm.c | 8 +- 7 files changed, 270 insertions(+), 38 deletions(-)