Am Freitag, den 13.10.2017, 15:39 +0100 schrieb Mark Brown: > 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. AFAIR the caps for the supported slave bus width were introduced later than other caps and not all drivers did implement them properly, so validation at the core level at this time would probably have broken a lot of existing users. That said the dmaengine core warns since kernel 4.0 if a driver doesn't set those caps, so it's probably fine if we cook up a patch to do the validation now. Regards, Lucas -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
