On Thu, Mar 21, 2013 at 04:06:27PM +0100, Lars-Peter Clausen wrote: > Hm, I only saw this series today would have been good to be on Cc. I've been > working on something very similar. My series goes a bit further though, it > implements an (almost generic) dmaengine based PCM driver using the of > bindings. So you need almost no platform code. The only things that are > platform specific at the moment is the pcm_hardware struct, but I'd like to > replace that in the future with something that queries the pcm hardware > parameter like max_period from the DMA engine driver. And another bit that is > still driver specific is a callback that fills the dma_slave_config struct. FWIW it might be worth looking at the one rmk wrote but has never wanted to submit for whatever reason. > In my series the channels are requested at probe time, so it is possible to > handle -EPROBE_DEFER properly and also we can allocate the audio buffers with > the dma device instead of the sound device, so stupid hacks like > card->dev->dma_mask = &dma_mask; > card->dev->coherent_dma_mask = DMA_BIT_MASK(32); > anymore. I'll try to post the series tomorrow. This is the main thing his code has got that the library hasn't, it's certainly the only issue he keeps mentioning.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
