On Fri, Mar 20, 2020 at 12:19:52PM +0000, Mark Brown wrote:
On Fri, Mar 20, 2020 at 12:52:03PM +0100, Guennadi Liakhovetski wrote:
On Fri, Mar 13, 2020 at 02:39:56PM +0000, Mark Brown wrote:
On Thu, Mar 12, 2020 at 03:44:21PM +0100, Guennadi Liakhovetski wrote:
#endif
- atomic_set(&sdev->reset_count, 0); dev_set_drvdata(dev, sdev);
Do we really need to use atomics for this? They are hard to use correctly.
This variable is accessed from 2 contexts: it's incremented by the SOF driver, when the firmware has booted and it's read by the SOF VirtIO backend vhost-be.c when receiving a resume request from the guest. Timewise the variable will only be incremented during the DSP resume / power up, while the VirtIO back end is waiting for the resume to complete in pm_runtime_get_sync(). And only after that it reads the variable. But that can happen on different CPUs. Whereas I think that runtime PM will sync caches somewhere during the process, I think it is better to access the variable in an SMP-safe way, e.g. using atomic operations.
That doesn't address my concern - to repeat, my concern is that atomics are hard to use correctly. Is there no other concurrency primitive (for example this sounds like a completion) which can be used?
No, this isn't a completion - it's a counter. I've used atomic variables before, I cannot remember seeing any difficulties with their correct use described. Do you have a pointer?
Thinking about it, one problem I see is wrapping, it isn't currently handled, but that would happen after quite a few PM suspend / resume cycles... Still it can and should be fixed. But this isn't the concern, that you have?
Thanks Guennadi