- Alsa-devel - mailman.alsa-project.org

[PATCH] ALSA: hda: intel: Allow repeatedly probing on codec configuration errors
by Takashi Iwai 06 Oct '21

06 Oct '21

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 Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/hda_codec.h | 1 + sound/pci/hda/hda_bind.c | 20 +++++++++++--------- sound/pci/hda/hda_codec.c | 1 + sound/pci/hda/hda_controller.c | 24 ++++++++++++++++-------- sound/pci/hda/hda_controller.h | 2 +- sound/pci/hda/hda_intel.c | 29 +++++++++++++++++++++++------ sound/pci/hda/hda_intel.h | 4 +++- 7 files changed, 56 insertions(+), 25 deletions(-) diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h index 01570dbda503..0e45963bb767 100644 --- a/include/sound/hda_codec.h +++ b/include/sound/hda_codec.h @@ -224,6 +224,7 @@ struct hda_codec { #endif /* misc flags */ + unsigned int configured:1; /* codec was configured */ unsigned int in_freeing:1; /* being released */ unsigned int registered:1; /* codec was registered */ unsigned int display_power_control:1; /* needs display power */ diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c index 2523b23389e9..1c8bffc3eec6 100644 --- a/sound/pci/hda/hda_bind.c +++ b/sound/pci/hda/hda_bind.c @@ -298,29 +298,31 @@ int snd_hda_codec_configure(struct hda_codec *codec) { int err; + if (codec->configured) + return 0; + if (is_generic_config(codec)) codec->probe_id = HDA_CODEC_ID_GENERIC; else codec->probe_id = 0; - err = snd_hdac_device_register(&codec->core); - if (err < 0) - return err; + if (!device_is_registered(&codec->core.dev)) { + err = snd_hdac_device_register(&codec->core); + if (err < 0) + return err; + } if (!codec->preset) codec_bind_module(codec); if (!codec->preset) { err = codec_bind_generic(codec); if (err < 0) { - codec_err(codec, "Unable to bind the codec\n"); - goto error; + codec_dbg(codec, "Unable to bind the codec\n"); + return err; } } + codec->configured = 1; return 0; - - error: - snd_hdac_device_unregister(&codec->core); - return err; } EXPORT_SYMBOL_GPL(snd_hda_codec_configure); diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index a9ebefd60cf6..0c4a337c9fc0 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -791,6 +791,7 @@ void snd_hda_codec_cleanup_for_unbind(struct hda_codec *codec) snd_array_free(&codec->nids); remove_conn_list(codec); snd_hdac_regmap_exit(&codec->core); + codec->configured = 0; } EXPORT_SYMBOL_GPL(snd_hda_codec_cleanup_for_unbind); diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7cd452831fd3..930ae4002a81 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -25,6 +25,7 @@ #include <sound/core.h> #include <sound/initval.h> #include "hda_controller.h" +#include "hda_local.h" #define CREATE_TRACE_POINTS #include "hda_controller_trace.h" @@ -1248,17 +1249,24 @@ EXPORT_SYMBOL_GPL(azx_probe_codecs); int azx_codec_configure(struct azx *chip) { struct hda_codec *codec, *next; + int success = 0; - /* use _safe version here since snd_hda_codec_configure() deregisters - * the device upon error and deletes itself from the bus list. - */ - list_for_each_codec_safe(codec, next, &chip->bus) { - snd_hda_codec_configure(codec); + list_for_each_codec(codec, &chip->bus) { + if (!snd_hda_codec_configure(codec)) + success++; } - if (!azx_bus(chip)->num_codecs) - return -ENODEV; - return 0; + if (success) { + /* unregister failed codecs if any codec has been probed */ + list_for_each_codec_safe(codec, next, &chip->bus) { + if (!codec->configured) { + codec_err(codec, "Unable to configure, disabling\n"); + snd_hdac_device_unregister(&codec->core); + } + } + } + + return success ? 0 : -ENODEV; } EXPORT_SYMBOL_GPL(azx_codec_configure); diff --git a/sound/pci/hda/hda_controller.h b/sound/pci/hda/hda_controller.h index 3062f87380b1..f5bf295eb830 100644 --- a/sound/pci/hda/hda_controller.h +++ b/sound/pci/hda/hda_controller.h @@ -41,7 +41,7 @@ /* 24 unused */ #define AZX_DCAPS_COUNT_LPIB_DELAY (1 << 25) /* Take LPIB as delay */ #define AZX_DCAPS_PM_RUNTIME (1 << 26) /* runtime PM support */ -/* 27 unused */ +#define AZX_DCAPS_RETRY_PROBE (1 << 27) /* retry probe if no codec is configured */ #define AZX_DCAPS_CORBRP_SELF_CLEAR (1 << 28) /* CORBRP clears itself after reset */ #define AZX_DCAPS_NO_MSI64 (1 << 29) /* Stick to 32-bit MSIs */ #define AZX_DCAPS_SEPARATE_STREAM_TAG (1 << 30) /* capture and playback use separate stream tag */ diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 47777439961c..4d22e7adeee8 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -307,7 +307,8 @@ enum { /* quirks for AMD SB */ #define AZX_DCAPS_PRESET_AMD_SB \ (AZX_DCAPS_NO_TCSEL | AZX_DCAPS_AMD_WORKAROUND |\ - AZX_DCAPS_SNOOP_TYPE(ATI) | AZX_DCAPS_PM_RUNTIME) + AZX_DCAPS_SNOOP_TYPE(ATI) | AZX_DCAPS_PM_RUNTIME |\ + AZX_DCAPS_RETRY_PROBE) /* quirks for Nvidia */ #define AZX_DCAPS_PRESET_NVIDIA \ @@ -1723,7 +1724,7 @@ static void azx_check_snoop_available(struct azx *chip) static void azx_probe_work(struct work_struct *work) { - struct hda_intel *hda = container_of(work, struct hda_intel, probe_work); + struct hda_intel *hda = container_of(work, struct hda_intel, probe_work.work); azx_probe_continue(&hda->chip); } @@ -1828,7 +1829,7 @@ static int azx_create(struct snd_card *card, struct pci_dev *pci, } /* continue probing in work context as may trigger request module */ - INIT_WORK(&hda->probe_work, azx_probe_work); + INIT_DELAYED_WORK(&hda->probe_work, azx_probe_work); *rchip = chip; @@ -2142,7 +2143,7 @@ static int azx_probe(struct pci_dev *pci, #endif if (schedule_probe) - schedule_work(&hda->probe_work); + schedule_delayed_work(&hda->probe_work, 0); dev++; if (chip->disabled) @@ -2228,6 +2229,11 @@ static int azx_probe_continue(struct azx *chip) int dev = chip->dev_index; int err; + if (chip->disabled || hda->init_failed) + return -EIO; + if (hda->probe_retry) + goto probe_retry; + to_hda_bus(bus)->bus_probing = 1; hda->probe_continued = 1; @@ -2289,10 +2295,20 @@ static int azx_probe_continue(struct azx *chip) #endif } #endif + + probe_retry: if (bus->codec_mask && !(probe_only[dev] & 1)) { err = azx_codec_configure(chip); - if (err < 0) + if (err) { + if ((chip->driver_caps & AZX_DCAPS_RETRY_PROBE) && + ++hda->probe_retry < 60) { + schedule_delayed_work(&hda->probe_work, + msecs_to_jiffies(1000)); + return 0; /* keep things up */ + } + dev_err(chip->card->dev, "Cannot probe codecs, giving up\n"); goto out_free; + } } err = snd_card_register(chip->card); @@ -2322,6 +2338,7 @@ static int azx_probe_continue(struct azx *chip) display_power(chip, false); complete_all(&hda->probe_wait); to_hda_bus(bus)->bus_probing = 0; + hda->probe_retry = 0; return 0; } @@ -2347,7 +2364,7 @@ static void azx_remove(struct pci_dev *pci) * device during cancel_work_sync() call. */ device_unlock(&pci->dev); - cancel_work_sync(&hda->probe_work); + cancel_delayed_work_sync(&hda->probe_work); device_lock(&pci->dev); snd_card_free(card); diff --git a/sound/pci/hda/hda_intel.h b/sound/pci/hda/hda_intel.h index 3fb119f09040..0f39418f9328 100644 --- a/sound/pci/hda/hda_intel.h +++ b/sound/pci/hda/hda_intel.h @@ -14,7 +14,7 @@ struct hda_intel { /* sync probing */ struct completion probe_wait; - struct work_struct probe_work; + struct delayed_work probe_work; /* card list (for power_save trigger) */ struct list_head list; @@ -30,6 +30,8 @@ struct hda_intel { unsigned int freed:1; /* resources already released */ bool need_i915_power:1; /* the hda controller needs i915 power */ + + int probe_retry; /* being probe-retry */ }; #endif -- 2.31.1

1 0

[PATCH MANUALSEL 5.14 9/9] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index ed40d0f7432c..773db4bf0876 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -143,7 +143,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 4.4] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 3689f5f6be64..3766624c018f 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -144,7 +144,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 4.9] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 3689f5f6be64..3766624c018f 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -144,7 +144,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 4.14] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 8f0f05bbc081..23a15d892e50 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -145,7 +145,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 4.19 2/2] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 8f0f05bbc081..23a15d892e50 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -145,7 +145,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 5.4 4/4] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index 8f0f05bbc081..23a15d892e50 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -145,7 +145,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

[PATCH MANUALSEL 5.10 7/7] ALSA: pcsp: Make hrtimer forwarding more robust
by Sasha Levin 06 Oct '21

06 Oct '21

From: Thomas Gleixner <tglx(a)linutronix.de> [ Upstream commit f2ff7147c6834f244b8ce636b12e71a3bd044629 ] The hrtimer callback pcsp_do_timer() prepares rearming of the timer with hrtimer_forward(). hrtimer_forward() is intended to provide a mechanism to forward the expiry time of the hrtimer by a multiple of the period argument so that the expiry time greater than the time provided in the 'now' argument. pcsp_do_timer() invokes hrtimer_forward() with the current timer expiry time as 'now' argument. That's providing a periodic timer expiry, but is not really robust when the timer callback is delayed so that the resulting new expiry time is already in the past which causes the callback to be invoked immediately again. If the timer is delayed then the back to back invocation is not really making it better than skipping the missed periods. Sound is distorted in any case. Use hrtimer_forward_now() which ensures that the next expiry is in the future. This prevents hogging the CPU in the timer expiry code and allows later on to remove hrtimer_forward() from the public interfaces. Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: alsa-devel(a)alsa-project.org Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Link: https://lore.kernel.org/r/20210923153339.623208460@linutronix.de Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/drivers/pcsp/pcsp_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/drivers/pcsp/pcsp_lib.c b/sound/drivers/pcsp/pcsp_lib.c index ed40d0f7432c..773db4bf0876 100644 --- a/sound/drivers/pcsp/pcsp_lib.c +++ b/sound/drivers/pcsp/pcsp_lib.c @@ -143,7 +143,7 @@ enum hrtimer_restart pcsp_do_timer(struct hrtimer *handle) if (pointer_update) pcsp_pointer_update(chip); - hrtimer_forward(handle, hrtimer_get_expires(handle), ns_to_ktime(ns)); + hrtimer_forward_now(handle, ns_to_ktime(ns)); return HRTIMER_RESTART; } -- 2.33.0

1 0

Re: [PATCH 2/2] ASoC: rt9120: Add rt9210 audio amplifier support
by ChiYuan Huang 06 Oct '21

06 Oct '21

Hi, Mark: Mark Brown <broonie(a)kernel.org> 於 2021年10月5日週二下午8:44寫道： > > On Tue, Oct 05, 2021 at 08:36:44PM +0800, ChiYuan Huang wrote: > > Mark Brown <broonie(a)kernel.org> 於 2021年10月5日週二下午7:54寫道： > > > On Tue, Oct 05, 2021 at 09:16:55AM +0800, cy_huang wrote: > > > > > + /* Default config volume to 0dB */ > > > > + snd_soc_component_write(comp, RT9120_REG_MSVOL, 0x180); > > > > + /* Mute by default */ > > > > + snd_soc_component_update_bits(comp, RT9120_REG_VOLRAMP, > > > > + RT9120_MUTE_MASK, RT9120_MUTE_MASK); > > > > As ever you should leave the defaults at whatever the hardware defaults > > > to, the defaults for one machine may not be suitable for another so we > > > shouldn't be trying to do that in software. > > > The default volume will be kept in value 0x7ff (mute). > > I just want to follow the ASoC flow to control mute/unmute mask by AMP on/off. > > If to default set volume to 0dB and mute is improper, user have to use > > mixer control to configure the volume. > > Does mute function also need to be removed also? > > It's totally fine and indeed quite common for devices to be muted by > default - usually systems will have UCM profiles that unmute things by > the time users actually interact with them. > > Please don't take things off-list unless there is a really strong reason > to do so. Sending things to the list ensures that everyone gets a > chance to read and comment on things. After asking the HW member, there's already builtin HW volume ramp function. Mute API is still no need. There's already no pop issue without mute function. So the next change, I'll remove the default volume and mute config, and also mute API. Thx.

1 0

[RFC PATCH v1 0/1] ASoC: meson: aiu: HDMI codec control questions and issues
by Martin Blumenstingl 06 Oct '21

06 Oct '21

Hello Jerome et al., on Amlogic Meson SoCs which use the AIU audio controller we have the so-called "machine gun noise" (MGN) issue, reproducible for example in Kodi. So far nobody was able to identify the cause of this issue. My idea was to at least narrow down the issue so we can categorize it. For that I wanted to get the SPDIF output from AIU to the HDMI controller working. On Amlogic Meson GXBB/GXL/GXM SoCs a DesignWare HDMI TX controller is used. This has an SPDIF input but there's currently not driver for it. On Meson8/8b/8m2 SoCs I am working on a HDMI driver for the TransSwitch HDMI controller which - just like DesignWare HDMI TX - supports SPDIF and I2S inputs. I decided to add SPDIF support to the latter since the code from the vendor driver is much easier. It took me a while to figure out why I would not get any audio output from AIU SPDIF to the HDMI controller - or from there to the sink. The "fix" for this issue is the RFC patch which is part of this series. Any feedback would be great as I am still new to the ASoC subsystem. Another part I am still struggling with is the audio "routing" (due to lack of a better term - please correct me if this is not the right word to use for this case). I have the following description in my .dts: sound { compatible = "amlogic,gx-sound-card"; model = "M8B-ODROID-C1"; assigned-clocks = <&clkc CLKID_MPLL0>, <&clkc CLKID_MPLL1>; assigned-clock-rates = <294912000>, <270950400>; dai-link-0 { sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>; }; dai-link-1 { sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>; }; dai-link-2 { sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>; dai-format = "i2s"; mclk-fs = <256>; codec-0 { sound-dai = <&aiu AIU_HDMI CTRL_I2S>; }; }; dai-link-3 { sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>; codec-0 { sound-dai = <&aiu AIU_HDMI CTRL_PCM>; }; }; dai-link-4 { sound-dai = <&aiu AIU_HDMI CTRL_OUT>; codec-0 { sound-dai = <&hdmi_tx>; }; }; }; The driver for &hdmi_tx defines: struct hdmi_codec_pdata pdata = { .ops = &txc_48352_hdmi_codec_ops, .i2s = 1, .spdif = 1, .max_i2s_channels = 8, .data = priv, }; In hdmi_codec_ops.hw_params I always get fmt->fmt HDMI_I2S unless I remove all I2S references from the .dts snipped above (only then HDMI_SPDIF is detected). Based on the selection of the "HDMI Source" enum in aiu-codec-ctrl I was expecting the format to update as well. That unfortunately doesn't happen and I don't know how that can be achieved. Best regards, Martin Martin Blumenstingl (1): ASoC: meson: aiu: Fix HDMI codec control selection sound/soc/meson/aiu-codec-ctrl.c | 108 ++++++++++++++++++++++-------- sound/soc/meson/aiu-encoder-i2s.c | 6 -- 2 files changed, 80 insertions(+), 34 deletions(-) -- 2.33.0

5 13