On Mon, 12 Oct 2020 16:46:56 +0200, Jaroslav Kysela wrote:
Dne 12. 10. 20 v 16:21 Takashi Iwai napsal(a):
But, I doubt whether we really need to care about that; as mentioned earlier, there is little to change from the user-space side. It just pause or resume. The only difference is the resume target, and honestly speaking, there is no interest in it from user-space side. And, the rest is about the kernel internal, and this can be really done in the way of the original patch. The flow is quite simple and understandable...
The core compress code already uses the state mechanism (although internally).
Also, it's really unclear if all drivers were checked, if the pause triggers can be called from the drain state (I know it's another point, but the drivers should probably offer a flag that they support this). And why to call the pause release callback when there's no pause (drain + release ioctl instead drain + pause + release ioctl)? It's a clear midlevel code fault. This protection should be there not in the hw drivers.
I refer the original patch: https://lore.kernel.org/alsa-devel/000c01d69585$228db6b0$67a92410$@samsung.c...
Point taken, and yes, this should be handled conditionally only for the drivers that do support such a mode.
Takashi