alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>,
	"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>
Cc: alsa-devel@alsa-project.org, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	linux-kernel@vger.kernel.org,
	sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v4 01/11] ASoC: SOF: core: add 'no_wq' probe and remove callbacks
Date: Tue, 12 Sep 2023 10:02:04 -0400	[thread overview]
Message-ID: <defa5f61-c4f2-aeb6-da23-a39539ec64fc@linux.intel.com> (raw)
In-Reply-To: <b878b564-8c18-4103-88d6-4f7b5fe01dba@linux.intel.com>



On 9/12/23 02:10, Péter Ujfalusi wrote:
> 
> 
> On 12/09/2023 03:25, Pierre-Louis Bossart wrote:
>>
>>
>>> What we have atm:
>>> snd_sof_probe - might be called from wq
>>> snd_sof_remove - might be called from wq (cleans up the snd_sof_probe
>>> 		 step)
>>
>> I don't think it's correct, snd_sof_remove cannot be called from a wq.
>> The device core knows nothing about workqueues.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sof/core.c#n328
> 
> it is called on the error path of sof_probe_continue(), which can be run
> in a workque.
> 
>>> We want a callbacks for hardware/device probing, right, split the
>>> snd_sof_probe (and remove) to be able to support a sane level of
>>> deferred probing support.
>>>
>>> With that in mind:
>>> snd_sof_device_probe - Not called from wq (to handle deferred probing)
>>> snd_sof_probe - might be called from wq
>>>
>>> snd_sof_remove - might be called from wq (cleans up the snd_sof_probe
>>> 		 step)
>>> snd_sof_device_remove - Not called from wq (to up the
>>> 			snd_sof_device_probe step)
>>>
>>> Naming option: s/device/hardware
>>
>> I like the 'device' hint since it's directly related to the device (or
>> subsystem) callbacks.
>>
>>> However, I think the snd_sof_device_remove itself is redundant and we
>>> might not need it at all as in case we have wq and there is a failure in
>>> there we do want to release resources as much as possible. The module
>>> will be kept loaded (no deferred handling in wq) and that might block
>>> PM, other devices to behave correctly. Iow, if the wq has failure we
>>> should do a cleanup to the best effort to reach a level like the driver
>>> is not even loaded.
>>
>> If we have a failure in a workqueue used for probe, then we have to
>> clean-up everything since nothing in the device core will do so for us.
> 
> Yes, this makes the snd_sof_device_remove() redundant or at least the
> definition of it is no longer a mirror of snd_sof_device_probe():
> 
> snd_sof_device_remove - might be called from wq (cleans up the
> 			snd_sof_device_probe step)
> 
> Any failure in sof_probe_continue() should execute the
> snd_sof_device_remove(), snd_sof_remove() is only involved after the
> snd_sof_probe() have returned with success.
> 
> I think this makes actually makes sense and it is well defined.
> On module remove we need to take into account the case when we have
> failed in wq similarly as we do currently (the resources have been freed
> up already).

Agree, I stand corrected, thanks Peter.


  reply	other threads:[~2023-09-12 14:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 15:36 [PATCH v4 00/11] sound: Use -EPROBE_DEFER instead of i915 module loading Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 01/11] ASoC: SOF: core: add 'no_wq' probe and remove callbacks Maarten Lankhorst
2023-08-30 17:13   ` Pierre-Louis Bossart
2023-08-31 10:44     ` Maarten Lankhorst
2023-09-01 12:22     ` Kai Vehmanen
2023-09-01 12:15   ` Kai Vehmanen
2023-09-01 12:44     ` Péter Ujfalusi
2023-09-05 12:37       ` Pierre-Louis Bossart
2023-09-07 17:29         ` Pierre-Louis Bossart
2023-09-11  6:51           ` Péter Ujfalusi
2023-09-12  0:25             ` Pierre-Louis Bossart
2023-09-12  6:10               ` Péter Ujfalusi
2023-09-12 14:02                 ` Pierre-Louis Bossart [this message]
2023-08-30 15:36 ` [PATCH v4 02/11] ASoC: SOF: Intel: hda: start splitting the probe Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 03/11] ALSA: hda/intel: Fix error handling in azx_probe() Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 04/11] ALSA: hda/i915: Allow override of gpu binding Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 05/11] ALSA: hda/i915: Add an allow_modprobe argument to snd_hdac_i915_init Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 06/11] ALSA: hda/i915: Allow xe as match for i915_component_master_match Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 07/11] ASoC: Intel: avs: Move snd_hdac_i915_init to before probe_work Maarten Lankhorst
2023-08-31 10:14   ` Amadeusz Sławiński
2023-08-30 15:36 ` [PATCH v4 08/11] ASoC: Intel: Skylake: " Maarten Lankhorst
2023-08-31 10:15   ` Amadeusz Sławiński
2023-08-30 15:36 ` [PATCH v4 09/11] ALSA: hda/intel: " Maarten Lankhorst
2023-08-30 15:36 ` [PATCH v4 10/11] ASoC: SOF: Intel: Move binding to display driver outside of deferred probe Maarten Lankhorst
2023-08-30 23:06   ` kernel test robot
2023-08-30 23:59   ` kernel test robot
2023-09-01 12:33   ` Kai Vehmanen
2023-08-30 15:36 ` [PATCH v4 11/11] ALSA: hda/i915: Remove extra argument from snd_hdac_i915_init Maarten Lankhorst

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=defa5f61-c4f2-aeb6-da23-a39539ec64fc@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=daniel.baluta@nxp.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=perex@perex.cz \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=tiwai@suse.com \
    --cc=yung-chuan.liao@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).