public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	alsa-devel@alsa-project.org
Cc: sound-open-firmware@alsa-project.org,
	linux-kernel@vger.kernel.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>,
	Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Mark Brown <broonie@kernel.org>,
	Daniel Baluta <daniel.baluta@nxp.com>
Subject: Re: [PATCH v2 7/9] ALSA: hda/intel: Move snd_hdac_i915_init to before probe_work.
Date: Tue, 25 Jul 2023 12:13:20 +0200	[thread overview]
Message-ID: <35720f76-e8b0-578b-e326-ebfce536be04@linux.intel.com> (raw)
In-Reply-To: <a895de13-5320-953b-3d1c-34cee259d1d2@linux.intel.com>

Hey,

On 2023-07-24 12:58, Pierre-Louis Bossart wrote:
> 
> 
> On 7/19/23 18:41, Maarten Lankhorst wrote:
>> Now that we can use -EPROBE_DEFER, it's no longer required to spin off
>> the snd_hdac_i915_init into a workqueue.
>>
>> Use the -EPROBE_DEFER mechanism instead, which must be returned in the
>> probe function.
>>
>> Changes since v1:
>> - Use dev_err_probe()
>> - Don't move probed_devs bitmap unnecessarily. (tiwai)
>> - Move snd_hdac_i915_init slightly upward, to ensure
>>    it's always initialised before vga-switcheroo is called.
>>
>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
>> ---
>>   sound/pci/hda/hda_intel.c | 59 ++++++++++++++++++++-------------------
>>   1 file changed, 30 insertions(+), 29 deletions(-)
>>
>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
>> index 11cf9907f039f..e3128d7d742e7 100644
>> --- a/sound/pci/hda/hda_intel.c
>> +++ b/sound/pci/hda/hda_intel.c
>> @@ -2147,6 +2147,36 @@ static int azx_probe(struct pci_dev *pci,
>>   
>>   	pci_set_drvdata(pci, card);
>>   
>> +#ifdef CONFIG_SND_HDA_I915
>> +	/* bind with i915 if needed */
>> +	if (chip->driver_caps & AZX_DCAPS_I915_COMPONENT) {
>> +		err = snd_hdac_i915_init(azx_bus(chip), false);
>> +		if (err < 0) {
>> +			/* if the controller is bound only with HDMI/DP
>> +			 * (for HSW and BDW), we need to abort the probe;
>> +			 * for other chips, still continue probing as other
>> +			 * codecs can be on the same link.
>> +			 */
>> +			if (CONTROLLER_IN_GPU(pci)) {
>> +				dev_err_probe(card->dev, err,
>> +					     "HSW/BDW HD-audio HDMI/DP requires binding with gfx driver\n");
>> +
>> +				goto out_free;
>> +			} else {
>> +				/* don't bother any longer */
>> +				chip->driver_caps &= ~AZX_DCAPS_I915_COMPONENT;
>> +			}
>> +		}
>> +
>> +		/* HSW/BDW controllers need this power */
>> +		if (CONTROLLER_IN_GPU(pci))
>> +			hda->need_i915_power = true;
>> +	}
>> +#else
>> +	if (CONTROLLER_IN_GPU(pci))
>> +		dev_err(card->dev, "Haswell/Broadwell HDMI/DP must build in CONFIG_SND_HDA_I915\n");
>> +#endif
> 
> Is it intentional that the display_power() is left in the probe workqueue?
> 
> this piece of code follows the stuff above in the existing code?
> 
> /* Request display power well for the HDA controller or codec. For
>   * Haswell/Broadwell, both the display HDA controller and codec need
>   * this power. For other platforms, like Baytrail/Braswell, only the
>   * display codec needs the power and it can be released after probe.
>   */
> display_power(chip, true);

I think for the binding itself, there isn't any harm. We are not poking 
any hardware when binding,
only software. This appears to be true on the i915 side as well.

Cheers,
~Maarten

  reply	other threads:[~2023-07-25 10:13 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 16:41 [PATCH v2 0/9] sound: Use -EPROBE_DEFER instead of i915 module loading Maarten Lankhorst
2023-07-19 16:41 ` [PATCH v2 1/9] ALSA: hda/intel: Fix error handling in azx_probe() Maarten Lankhorst
2023-07-21 11:34   ` Péter Ujfalusi
2023-07-24 10:15     ` Pierre-Louis Bossart
2023-07-19 16:41 ` [PATCH v2 2/9] ALSA: hda/i915: Allow override of gpu binding Maarten Lankhorst
2023-07-21 12:19   ` Péter Ujfalusi
2023-07-24 10:25     ` Pierre-Louis Bossart
2023-07-25  9:54       ` Maarten Lankhorst
2023-07-25 11:52         ` Pierre-Louis Bossart
2023-07-25 12:19           ` Takashi Iwai
2023-07-19 16:41 ` [PATCH v2 3/9] ALSA: hda/i915: Add an allow_modprobe argument to snd_hdac_i915_init Maarten Lankhorst
2023-07-21 11:32   ` Péter Ujfalusi
2023-07-19 16:41 ` [PATCH v2 4/9] ALSA: hda/i915: Allow xe as match for i915_component_master_match Maarten Lankhorst
2023-07-21 12:20   ` Péter Ujfalusi
2023-07-24 10:28   ` Pierre-Louis Bossart
2023-07-25 10:04     ` Maarten Lankhorst
2023-07-19 16:41 ` [PATCH v2 5/9] ASoC: Intel: avs: Move snd_hdac_i915_init to before probe_work Maarten Lankhorst
2023-07-19 16:41 ` [PATCH v2 6/9] ASoC: Intel: Skylake: " Maarten Lankhorst
2023-07-19 16:41 ` [PATCH v2 7/9] ALSA: hda/intel: " Maarten Lankhorst
2023-07-24 10:58   ` Pierre-Louis Bossart
2023-07-25 10:13     ` Maarten Lankhorst [this message]
2023-07-19 16:41 ` [PATCH v2 8/9] ASoC: SOF: Intel: Remove deferred probe for SOF Maarten Lankhorst
2023-07-21 12:17   ` Péter Ujfalusi
2023-07-24 11:32   ` Pierre-Louis Bossart
2023-07-25 10:29     ` Maarten Lankhorst
2023-07-25 10:37       ` Takashi Iwai
2023-07-19 16:41 ` [PATCH v2 9/9] ALSA: hda/i915: Remove extra argument from snd_hdac_i915_init Maarten Lankhorst
2023-07-21 10:06 ` [PATCH v2 0/9] sound: Use -EPROBE_DEFER instead of i915 module loading Kai Vehmanen
2023-07-21 12:19 ` Péter Ujfalusi
2023-07-31 15:51 ` Takashi Iwai
2023-07-31 16:37   ` Maarten Lankhorst
2023-07-31 19:32     ` Takashi Iwai
2023-08-01  7:27       ` Maarten Lankhorst
2023-08-01 16:32     ` Pierre-Louis Bossart
2023-08-04 10:47       ` [PATCH] ASoC: SOF: Intel: Move binding to display driver outside of deferred probe Maarten Lankhorst
2023-08-04 11:59         ` Mark Brown
2023-08-04 14:31           ` Maarten Lankhorst
2023-08-04 14:34             ` 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=35720f76-e8b0-578b-e326-ebfce536be04@linux.intel.com \
    --to=maarten.lankhorst@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=perex@perex.cz \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@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