From: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
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:52:03 +0100 [thread overview]
Message-ID: <20200320115203.GA2130@ubuntu> (raw)
In-Reply-To: <20200313143956.GJ5528@sirena.org.uk>
Hi Mark,
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.
> > #include "ops.h"
> > @@ -617,6 +618,9 @@ int snd_sof_run_firmware(struct snd_sof_dev *sdev)
> > /* fw boot is complete. Update the active cores mask */
> > sdev->enabled_cores_mask = init_core_mask;
> >
> > + /* increment reset count */
> > + atomic_add(1, &sdev->reset_count);
> > +
>
> We at no point seem to read from this reset counter? I can't figure out
> from this commit what it's doing.
It's used in vhost-be.c (patch 10/14).
Thanks
Guennadi
next prev parent reply other threads:[~2020-03-20 11:53 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 [this message]
2020-03-20 12:19 ` Mark Brown
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=20200320115203.GA2130@ubuntu \
--to=guennadi.liakhovetski@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--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.