Skip to content
GitLab
  1. Feb 23, 2022
  3. Feb 17, 2022
  5. Feb 11, 2022
  7. Feb 10, 2022
    • Stephen Boyd's avatar
      ASoC: qcom: Actually clear DMA interrupt register for HDMI · c8d251f5
      Stephen Boyd authored 
      In commit da0363f7 ("ASoC: qcom: Fix for DMA interrupt clear reg
overwriting") we changed regmap_write() to regmap_update_bits() so that
we can avoid overwriting bits that we didn't intend to modify.
Unfortunately this change breaks the case where a register is writable
but not readable, which is exactly how the HDMI irq clear register is
designed (grep around LPASS_HDMITX_APP_IRQCLEAR_REG to see how it's
write only). That's because regmap_update_bits() tries to read the
register from the hardware and if it isn't readable it looks in the
regmap cache to see what was written there last time to compare against
what we want to write there. Eventually, we're unable to modify this
register at all because the bits that we're trying to set are already
set in the cache.

This is doubly bad for the irq clear register because you have to write
the bit to clear an interrupt. Given the irq is level triggered, we see
an interrupt storm upon plugging in an HDMI cable and starting audio
playback. The irq storm is so great that performance degrades
significantly, leading to CPU soft lockups.

Fix it by using regmap_write_bits() so that we really do write the bits
in the clear register that we want to. This brings the number of irqs
handled by lpass_dma_interrupt_handler() down from ~150k/sec to ~10/sec.

Fixes: da0363f7

 ("ASoC: qcom: Fix for DMA interrupt clear reg overwriting")
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20220209232520.4017634-1-swboyd@chromium.org


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c8d251f5
  9. Feb 09, 2022
  11. Feb 08, 2022
  13. Feb 03, 2022
  15. Jan 31, 2022
  17. Jan 29, 2022
  19. Jan 28, 2022
  21. Jan 26, 2022
  23. Jan 25, 2022
  25. Jan 22, 2022
  27. Jan 20, 2022
  29. Jan 12, 2022
  31. Jan 11, 2022
  33. Jan 10, 2022
    • Robert Hancock's avatar
      ASoC: xilinx: xlnx_formatter_pcm: Make buffer bytes multiple of period bytes · e958b588
      Robert Hancock authored 
      This patch is based on one in the Xilinx kernel tree, "ASoc: xlnx: Make
buffer bytes multiple of period bytes" by Devarsh Thakkar. The same
issue exists in the mainline version of the driver. The original
patch description is as follows:

"The Xilinx Audio Formatter IP has a constraint on period
bytes to be multiple of 64. This leads to driver changing
the period size to suitable frames such that period bytes
are multiple of 64.

Now since period bytes and period size are updated but not
the buffer bytes, this may make the buffer bytes unaligned
and not multiple of period bytes.

When this happens we hear popping noise as while DMA is being
done the buffer bytes are not enough to complete DMA access
for last period of frame within the application buffer boundary.

To avoid this, align buffer bytes too as multiple of 64, and
set another constraint to always enforce number of periods as
integer. Now since, there is already a rule in alsa core
to enforce Buffer size = Number of Periods * Period Size
this automatically aligns buffer bytes as multiple of period
bytes."

Fixes: 6f6c3c36

 ("ASoC: xlnx: add pcm formatter platform driver")
Cc: Devarsh Thakkar <devarsh.thakkar@xilinx.com>
Signed-off-by: default avatarRobert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20220107214711.1100162-2-robert.hancock@calian.com


Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      e958b588
  35. Jan 08, 2022