Skip to content
  1. Oct 02, 2023
  2. Sep 29, 2023
  3. Sep 27, 2023
    • Vijendar Mukunda's avatar
      ASoC: SOF: amd: fix for firmware reload failure after playback · 7e1fe5d9
      Vijendar Mukunda authored
      Setting ACP ACLK as clock source when ACP enters D0 state causing
      firmware load failure as mentioned in below scenario.
      
      - Load snd_sof_amd_rembrandt
      - Play or Record audio
      - Stop audio
      - Unload snd_sof_amd_rembrandt
      - Reload snd_sof_amd_rembrandt
      
      If acp_clkmux_sel register field is set, then clock source will be
      set to ACP ACLK when ACP enters D0 state.
      
      During stream stop, if there is no active stream is running then
      acp firmware will set the ACP ACLK value to zero.
      
      When driver is reloaded and clock source is selected as ACP ACLK,
      as ACP ACLK is programmed to zero, firmware loading will fail.
      
      For RMB platform, remove the clock mux selection field so that
      ACP will use internal clock source when ACP enters D0 state.
      
      Fixes: 41cb85bc
      
       ("ASoC: SOF: amd: Add support for Rembrandt plaform.")
      Reported-by: default avatarcoolstar <coolstarorganization@gmail.com>
      Closes: https://github.com/thesofproject/sof/issues/8137
      Signed-off-by: default avatarVijendar Mukunda <Vijendar.Mukunda@amd.com>
      Link: https://lore.kernel.org/r/20230927071412.2416250-1-Vijendar.Mukunda@amd.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      7e1fe5d9
  4. Sep 26, 2023
    • Shengjiu Wang's avatar
      ASoC: fsl-asoc-card: use integer type for fll_id and pll_id · 2b21207a
      Shengjiu Wang authored
      As the pll_id and pll_id can be zero (WM8960_SYSCLK_AUTO)
      with the commit 2bbc2df4
      
       ("ASoC: wm8960: Make automatic the
      default clocking mode")
      
      Then the machine driver will skip to call set_sysclk() and set_pll()
      for codec, when the sysclk rate is different with what wm8960 read
      at probe, the output sound frequency is wrong.
      
      So change the fll_id and pll_id initial value, still keep machine
      driver's behavior same as before.
      
      Signed-off-by: default avatarShengjiu Wang <shengjiu.wang@nxp.com>
      Link: https://lore.kernel.org/r/1695202992-24864-1-git-send-email-shengjiu.wang@nxp.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      2b21207a
  5. Sep 25, 2023
  6. Sep 23, 2023
  7. Sep 20, 2023
  8. Sep 19, 2023
  9. Sep 16, 2023
  10. Sep 15, 2023
  11. Sep 14, 2023
  12. Sep 13, 2023
    • Richard Fitzgerald's avatar
      ASoC: cs42l42: Avoid stale SoundWire ATTACH after hard reset · 2d066c6a
      Richard Fitzgerald authored
      
      
      In SoundWire mode leave hard RESET asserted when exiting probe,
      and wait for an UNATTACHED notification before deasserting RESET.
      
      If the boot state of the reset GPIO was deasserted it is possible
      that the SoundWire core had already enumerated the CS42L42 before
      cs42l42_sdw_probe() is called. When cs42l42_common_probe() hard
      resets the CS42L42 it triggers a race condition:
      
      1) After cs42l42_sdw_probe() returns the thread that called it
         will call cs42l42_sdw_update_status() to report the last
         status recorded by the SoundWire core.
      
      2) The SoundWire bus master will see a PING with the CS42L42
         now reporting as unenumerated and will trigger the core
         SoundWire code to start enumerating CS42L42.
      
      These two threads are racing against each other. If (1)
      happens before (2) a stale ATTACHED notification will be
      reported to the cs42l42 driver when in fact the status of
      cs42l42 is now unattached.
      
      To avoid this race condition:
      
      - Leave RESET asserted on exit from cs42l42_sdw_probe().
        This ensures that an UNATTACHED notification must be
        sent to the cs42l42 driver. If cs42l42 was already
        enumerated it will be seen to drop off the bus, causing
        an UNATTACH notification. If it was never enumerated the
        status is already UNATTACHED and this will be reported
        by thread (1).
      
      - When the UNATTACH notification is received, release RESET.
        This will cause CS42L42 to be enumerated and eventually
        report an ATTACHED notification.
      
      - The ATTACHED notification is now valid.
      
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Signed-off-by: default avatarStefan Binding <sbinding@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20230913150012.604775-4-sbinding@opensource.cirrus.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      2d066c6a
    • Richard Fitzgerald's avatar
      ASoC: cs42l42: Don't rely on GPIOD_OUT_LOW to set RESET initially low · a479b44a
      Richard Fitzgerald authored
      
      
      The ACPI setting for a GPIO default state has higher priority than the
      flag passed to devm_gpiod_get_optional() so ACPI can override the
      GPIOD_OUT_LOW. Explicitly set the GPIO low when hard resetting.
      
      Although GPIOD_OUT_LOW can't be relied on this doesn't seem like a
      reason to stop passing it to devm_gpiod_get_optional(). So we still pass
      it to state our intent, but can deal with it having no effect.
      
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Signed-off-by: default avatarStefan Binding <sbinding@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20230913150012.604775-3-sbinding@opensource.cirrus.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      a479b44a
    • Richard Fitzgerald's avatar
      ASoC: cs42l42: Ensure a reset pulse meets minimum pulse width. · 41dac81b
      Richard Fitzgerald authored
      
      
      The CS42L42 can accept very short reset pulses of a few microseconds
      but there's no reason to force a very short pulse.
      Allow a wide range for the usleep_range() so it can be relaxed about
      the choice of timing source.
      
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Signed-off-by: default avatarStefan Binding <sbinding@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20230913150012.604775-2-sbinding@opensource.cirrus.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      41dac81b
    • Dan Carpenter's avatar
      ASoC: codecs: aw88395: Fix some error codes · cf0ba445
      Dan Carpenter authored
      These error paths should return -EINVAL instead of success.
      
      Fixes: 7f4ec778
      
       ("ASoC: codecs: Add code for bin parsing compatible with aw88261")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
      Link: https://lore.kernel.org/r/81476e78-05c2-4656-b754-f314c7ccdb81@moroto.mountain
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      cf0ba445
    • Mark Brown's avatar
      ASoC: rt5640: Fix various IRQ handling issues · ec83a0b3
      Mark Brown authored
      Merge series from Hans de Goede <hdegoede@redhat.com>:
      
      The recent(ish) rt5640 changes to add HDA header jack-detect support
      and the related suspend/resume handling fixes have introduced several
      issues with IRQ handling on boards not using the HDA header jack-detect
      support.
      
      This series fixes these issues, see the individual commit messages
      for details.
      ec83a0b3
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Disable low-power hibernation mode · 18789be8
      Richard Fitzgerald authored
      
      
      Do not allow the CS35L56 to be put into its lowest power
      "hibernation" mode. This only affects I2C because "hibernation"
      is already disabled on SPI and SoundWire.
      
      Recent firmwares need a different wake-up sequence. Until
      that sequence has been specified, the chip "hibernation" mode
      must be disabled otherwise it can intermittently fail to wake.
      
      THIS WILL NOT APPLY CLEANLY TO 6.5 AND EARLIER:
      We will send a separate backport patch to stable.
      
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20230912133841.3480466-1-rf@opensource.cirrus.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      18789be8
  13. Sep 12, 2023
    • Hans de Goede's avatar
      ASoC: rt5640: Only cancel jack-detect work on suspend if active · 8fc7cc50
      Hans de Goede authored
      
      
      If jack-detection is not used; or has already been disabled then
      there is no need to call rt5640_cancel_work().
      
      Move the rt5640_cancel_work() inside the "if (rt5640->jack) {}" block,
      grouping it together with the disabling of the IRQ which queues the work
      in the first place.
      
      This also makes suspend() symetrical with resume() which re-queues the work
      in an "if (rt5640->jack) {}" block.
      
      Cc: Oder Chiou <oder_chiou@realtek.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20230912113245.320159-7-hdegoede@redhat.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      8fc7cc50
    • Hans de Goede's avatar
      ASoC: rt5640: Fix IRQ not being free-ed for HDA jack detect mode · 8c8bf3df
      Hans de Goede authored
      Set "rt5640->irq_requested = true" after a successful request_irq()
      in rt5640_enable_hda_jack_detect(), so that rt5640_disable_jack_detect()
      properly frees the IRQ.
      
      This fixes the IRQ not being freed on rmmod / driver unbind.
      
      Fixes: 2b9c8d2b
      
       ("ASoC: rt5640: Add the HDA header support")
      Cc: Oder Chiou <oder_chiou@realtek.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20230912113245.320159-6-hdegoede@redhat.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      8c8bf3df
    • Hans de Goede's avatar
      ASoC: rt5640: Enable the IRQ on resume after configuring jack-detect · b5e85e53
      Hans de Goede authored
      The jack-detect IRQ should be enabled *after* the jack-detect related
      configuration registers have been programmed.
      
      Move the enable_irq() call for this to after the register setup.
      
      Fixes: 5fabcc90
      
       ("ASoC: rt5640: Fix Jack work after system suspend")
      Cc: Oder Chiou <oder_chiou@realtek.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20230912113245.320159-5-hdegoede@redhat.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      b5e85e53
    • Hans de Goede's avatar
      ASoC: rt5640: Do not disable/enable IRQ twice on suspend/resume · 786120eb
      Hans de Goede authored
      When jack-detect was originally added disabling the IRQ during suspend
      was done by the sound/soc/intel/boards/bytcr_rt5640.c driver
      calling snd_soc_component_set_jack(NULL) on suspend, which calls
      rt5640_disable_jack_detect(), which calls free_irq() which also
      disables it.
      
      Commit 5fabcc90 ("ASoC: rt5640: Fix Jack work after system suspend")
      added disable_irq() / enable_irq() calls on suspend/resume for machine
      drivers which do not call snd_soc_component_set_jack(NULL) on suspend.
      
      The new disable_irq() / enable_irq() are made conditional by
      "if (rt5640->irq)" statements, but this is true for the machine drivers
      which do call snd_soc_component_set_jack(NULL) on suspend too, causing
      a disable_irq() call there on the already free-ed IRQ.
      
      Change the "if (rt5640->irq)" condition to "if (rt5640->jack)" to fix this,
      rt5640->jack is only set if the jack-detect IRQ handler is still active
      when rt5640_suspend() runs.
      
      And adjust rt5640_enable_hda_jack_detect()'s request_irq() error handling
      to set rt5640->jack to NULL to match (note that the old setting of irq to
      -ENOXIO still resulted in disable_irq(-ENOXIO) calls on suspend).
      
      Fixes: 5fabcc90
      
       ("ASoC: rt5640: Fix Jack work after system suspend")
      Cc: Oder Chiou <oder_chiou@realtek.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20230912113245.320159-4-hdegoede@redhat.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      786120eb
    • Hans de Goede's avatar
      ASoC: rt5640: Fix sleep in atomic context · df7d595f
      Hans de Goede authored
      Following prints are observed while testing audio on Jetson AGX Orin which
      has onboard RT5640 audio codec:
      
        BUG: sleeping function called from invalid context at kernel/workqueue.c:3027
        in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0
        preempt_count: 10001, expected: 0
        RCU nest depth: 0, expected: 0
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x1e0/0x270
        ---[ end trace ad1c64905aac14a6 ]-
      
      The IRQ handler rt5640_irq() runs in interrupt context and can sleep
      during cancel_delayed_work_sync().
      
      The only thing which rt5640_irq() does is cancel + (re-)queue
      the jack_work delayed_work. This can be done in a single non sleeping
      call by replacing queue_delayed_work() with mod_delayed_work(),
      avoiding the sleep in atomic context.
      
      Fixes: 051dade3
      
       ("ASoC: rt5640: Fix the wrong state of JD1 and JD2")
      Reported-by: default avatarSameer Pujar <spujar@nvidia.com>
      Closes: https://lore.kernel.org/r/1688015537-31682-4-git-send-email-spujar@nvidia.com
      Cc: Oder Chiou <oder_chiou@realtek.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20230912113245.320159-3-hdegoede@redhat.com
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      df7d595f