From: Mark Brown <broonie@kernel.org>
To: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
Takashi Iwai <tiwai@suse.de>,
alsa-devel@alsa-project.org,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH 06/14] ASoC: SOF: add a power status IPC
Date: Fri, 20 Mar 2020 12:19:52 +0000 [thread overview]
Message-ID: <20200320121952.GC3961@sirena.org.uk> (raw)
In-Reply-To: <20200320115203.GA2130@ubuntu>
[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]
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?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-03-20 12:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-12 14:44 [PATCH 00/14] ASoC: SOF DSP virtualisation Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 01/14] ASoC: add function parameters to enable forced path pruning Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 02/14] ASoC: SOF: extract firmware-related operation into a function Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 03/14] ASoC: SOF: VirtIO: make a function global Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 04/14] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 05/14] ASoC: SOF: support IPC with immediate response Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 06/14] ASoC: SOF: add a power status IPC Guennadi Liakhovetski
2020-03-13 14:39 ` Mark Brown
2020-03-20 11:52 ` Guennadi Liakhovetski
2020-03-20 12:19 ` Mark Brown [this message]
2020-03-20 13:27 ` Guennadi Liakhovetski
2020-03-20 15:07 ` Guennadi Liakhovetski
2020-03-20 16:39 ` Mark Brown
2020-03-23 9:31 ` Guennadi Liakhovetski
2020-03-23 12:37 ` Mark Brown
2020-03-12 14:44 ` [PATCH 07/14] ASoC: SOF: add two helper lookup functions Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 08/14] ASoC: SOF: fix uninitialised "work" with VirtIO Guennadi Liakhovetski
2020-03-13 14:45 ` Mark Brown
2020-03-13 15:24 ` [Sound-open-firmware] " Sridharan, Ranjani
2020-03-12 14:44 ` [PATCH 09/14] ASoC: SOF: add a VirtIO DSP driver Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 10/14] ASoC: SOF: add a vhost driver: sound part Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 11/14] vhost: add an SOF DSP driver Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 12/14] ASoC: SOF: VirtIO: check guest component IDs Guennadi Liakhovetski
2020-03-13 18:39 ` Mark Brown
2020-03-12 14:44 ` [PATCH 13/14] ASoC: SOF: VirtIO: free guest pipelines upon termination Guennadi Liakhovetski
2020-03-12 14:44 ` [PATCH 14/14] ASoC: SOF: VirtIO: enable simultaneous playback and capture Guennadi Liakhovetski
2020-03-13 14:31 ` [PATCH 00/14] ASoC: SOF DSP virtualisation Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200320121952.GC3961@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=guennadi.liakhovetski@linux.intel.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=sound-open-firmware@alsa-project.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.