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.com/ Point taken, and yes, this should be handled conditionally only for the drivers that do support such a mode. Takashi
