On Mon, 19 Aug 2019 18:39:37 +0200, Paul Pawlowski wrote:
Hello, I have implemented that today, and it seems that it takes 30ms to memcpy() the data from the buffer to the host memory. Other than this is works well. Source available at: https://github.com/MCMrARM/mbp2018-bridge-drv/blob/65a09949c2d7343a073d92e4d...
Do you think this is acceptable? Is there a better way to handle this?
Yes, that sounds like the only way...
One way would be to avoid the buffering in the driver completely. This also includes to disable the mmap buffer access, of course.
In this alternative way, you'd need to implement copy, copy_kernel and silence ops, for the copy operation, so the whole buffering is done in the driver side as you like. But if the chip clears the DMA buffer, then you'd need to anyway do some workaround by copying & restoring the data, so I don't think the alternative way would be worth for consideration :)
Takashi
Thank you, Paul Pawlowski
On Tue, Aug 6, 2019 at 12:57 PM Takashi Iwai tiwai@suse.de wrote:
On Wed, 31 Jul 2019 19:48:13 +0200, Paul Pawlowski wrote:
Hello, I have a device which clears the DMA buffer when I command it to start the playback. How can this be workarounded?
So it clears the DMA buffer at start, then you need to put the data on the DMA buffer again on the running stream? What a weird chip.
I found the SNDRV_PCM_INFO_DOUBLE flag, but it doesn't seem that it changes alsa/alsa-lib behaviour. I wasn't able to find any drivers which shared this quirk. I'd like to avoid double buffering if possible, as once the stream is actually started it's not required.
The PCM_INFO_DOUBLE flag has no effect for anything like that. It's merely a information bit exposed to the user-space as a hint.
In such a case, you need to implement some ugly workaround in the driver side. Since the double-buffer is needed only at start, you can save the whole content (up to appl_ptr) and write back after starting the stream.
Takashi