2019-05-26 23:55:05 -07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2013-05-30 07:07:10 -07:00
|
|
|
/*
|
|
|
|
*/
|
2015-01-08 08:54:15 -07:00
|
|
|
#ifndef __SOUND_HDA_INTEL_H
|
|
|
|
#define __SOUND_HDA_INTEL_H
|
|
|
|
|
2015-02-19 10:04:17 -07:00
|
|
|
#include "hda_controller.h"
|
2015-01-08 08:54:15 -07:00
|
|
|
|
|
|
|
struct hda_intel {
|
|
|
|
struct azx chip;
|
|
|
|
|
|
|
|
/* for pending irqs */
|
|
|
|
struct work_struct irq_pending_work;
|
|
|
|
|
|
|
|
/* sync probing */
|
|
|
|
struct completion probe_wait;
|
ALSA: hda: intel: Allow repeatedly probing on codec configuration errors
It seems that a few recent AMD systems show the codec configuration
errors at the early boot, while loading the driver at a later stage
works magically. Although the root cause of the error isn't clear,
it's certainly not bad to allow retrying the codec probe in such a
case if that helps.
This patch adds the capability for retrying the probe upon codec probe
errors on the certain AMD platforms. The probe_work is changed to a
delayed work, and at the secondary call, it'll jump to the codec
probing.
Note that, not only adding the re-probing, this includes the behavior
changes in the codec configuration function. Namely,
snd_hda_codec_configure() won't unregister the codec at errors any
longer. Instead, its caller, azx_codec_configure() unregisters the
codecs with the probe failures *if* any codec has been successfully
configured. If all codec probe failed, it doesn't unregister but let
it re-probed -- which is the most case we're seeing and this patch
tries to improve.
Even if the driver doesn't re-probe or give up, it will go to the
"free-all" error path, hence the leftover codecs shall be disabled /
deleted in anyway.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801
Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-06 07:19:40 -07:00
|
|
|
struct delayed_work probe_work;
|
2015-01-08 08:54:15 -07:00
|
|
|
|
|
|
|
/* card list (for power_save trigger) */
|
|
|
|
struct list_head list;
|
|
|
|
|
|
|
|
/* extra flags */
|
|
|
|
unsigned int irq_pending_warned:1;
|
2015-04-14 13:13:18 -07:00
|
|
|
unsigned int probe_continued:1;
|
2024-07-29 07:15:16 -07:00
|
|
|
unsigned int runtime_pm_disabled:1;
|
2015-01-08 08:54:15 -07:00
|
|
|
|
2015-09-04 11:49:36 -07:00
|
|
|
/* vga_switcheroo setup */
|
2015-01-08 08:54:15 -07:00
|
|
|
unsigned int use_vga_switcheroo:1;
|
|
|
|
unsigned int vga_switcheroo_registered:1;
|
|
|
|
unsigned int init_failed:1; /* delayed init failed */
|
ALSA: hda: Release resources at error in delayed probe
snd-hda-intel driver handles the most of its probe task in the delayed
work (either via workqueue or via firmware loader). When an error
happens in the later delayed probe, we can't deregister the device
itself because the probe callback already returned success and the
device was bound. So, for now, we set hda->init_failed flag and make
the rest untouched until the device gets really unbound.
However, this leaves the device up running, keeping the resources
without any use that prevents other operations.
In this patch, we release the resources at first when a probe error
happens in the delayed probe stage, but keeps the top-level object, so
that the PM and other ops can still refer to the object itself.
Also for simplicity, snd_hda_intel object is allocated via devm, so
that we can get rid of the explicit kfree calls.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043
Link: https://lore.kernel.org/r/20200413082034.25166-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-04-13 01:20:31 -07:00
|
|
|
unsigned int freed:1; /* resources already released */
|
2015-01-08 08:54:15 -07:00
|
|
|
|
2015-04-29 02:43:36 -07:00
|
|
|
bool need_i915_power:1; /* the hda controller needs i915 power */
|
ALSA: hda: intel: Allow repeatedly probing on codec configuration errors
It seems that a few recent AMD systems show the codec configuration
errors at the early boot, while loading the driver at a later stage
works magically. Although the root cause of the error isn't clear,
it's certainly not bad to allow retrying the codec probe in such a
case if that helps.
This patch adds the capability for retrying the probe upon codec probe
errors on the certain AMD platforms. The probe_work is changed to a
delayed work, and at the secondary call, it'll jump to the codec
probing.
Note that, not only adding the re-probing, this includes the behavior
changes in the codec configuration function. Namely,
snd_hda_codec_configure() won't unregister the codec at errors any
longer. Instead, its caller, azx_codec_configure() unregisters the
codecs with the probe failures *if* any codec has been successfully
configured. If all codec probe failed, it doesn't unregister but let
it re-probed -- which is the most case we're seeing and this patch
tries to improve.
Even if the driver doesn't re-probe or give up, it will go to the
"free-all" error path, hence the leftover codecs shall be disabled /
deleted in anyway.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190801
Link: https://lore.kernel.org/r/20211006141940.2897-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2021-10-06 07:19:40 -07:00
|
|
|
|
|
|
|
int probe_retry; /* being probe-retry */
|
2015-01-08 08:54:15 -07:00
|
|
|
};
|
2013-05-30 07:07:10 -07:00
|
|
|
|
|
|
|
#endif
|