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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
