On Fri, Oct 13, 2017 at 01:35:43PM +0200, Lucas Stach wrote:
Am Freitag, den 13.10.2017, 12:25 +0100 schrieb Mark Brown:
On Fri, Oct 13, 2017 at 12:43:46PM +0200, Lucas Stach wrote:
The commit [1] which changed imx-pcm-dma to derive the pcm_config from the attached dmaengine introduced a regression on the supported sample formats, as imx-sdma doesn't properly advertise all the supported slave bus widths.
How did this work previously - shouldn't we have failed to use the unadvertised bus widths? I'd expect the framework to be providing error checking for the clients here.
No, if the sound PCM implementation explicitly provides a pcm_config with the hw.formats set to 0, the core only looks at the DAI supported formats. Now that we derive the pcm_config from the dmaengine
I'm not talking about the sound side here...
hw.formats gets filled with formats supported by the dmaengine, which is then used as an additional constraint by the core.
...I'm talking about the constraints supported on the DMA side. I would not expect the DMA side to be accepting things it said it didn't support.