On Mon, Jun 17, 2024 at 5:48 PM Krzysztof Kozlowski krzk@kernel.org wrote:
On 17/06/2024 16:04, Piotr Wojtaszczyk wrote:
It's used by snd_soc_dai_init_dma_data() in [PATCH v3 4/4] to give the dmaengine a hint which dma config to use. The LPC32xx doesn't have yet a dmamux driver like
and if I change driver platform data to foo and bar, does the DTS work? No.
They shouldn't change the same way as expected dma-names shouldn't change. Lots of drivers expect the dma-names to be "rx", "tx"
lpc18xx-dmamux.c therefore it still uses platform data entries for pl08x dma channels and 'SND_DMAENGINE_PCM_FLAG_NO_DT | SND_DMAENGINE_PCM_FLAG_COMPAT' flags in the devm_snd_dmaengine_pcm_register(). Typically instead of this platform data you would use regular 'dma' and 'dma-names' if it had proper dmamux driver like lpc18xx-dmamux.c
Exactly. Use these.
Then I need to write a lpc32xx dma mux driver, device tree binding for it and adjust the LPC32xx I2S driver for it. Is this a hard requirement to accept this patch set for the legacy LPC32xx SoC?
I do not see at all analogy with dma-names. dma-names are used ONLY by the consumer to pick up proper property "dmas" from DT. They are not passed to DMA code. They are not used to configure DMA provider at all.
You parse string from DT and pass it further as DMA filtering code. This is abuse of hardware description for programming your driver and their dependencies.
Why you cannot hard-code them?
Sorry, to be clear: NAK
That's fine, clear answers are always good. I considered to hardcode this as it was in the first version of the patch set but LPC32XX has two I2S interfaces which use different DMA signals and mux settings and I really didn't want to pick the virtual DMA channel name based on hardcoded I2S node name therefore I thought having a DT property to select proper dma channel is a better solution.