Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87v9ijyoek.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wo2zyoeo.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87y2nfyoes.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zh7vyoex.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rl70yse.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87365n0ysi.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kq30ysm.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zaj0ysr.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sff0yt0.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a6zv0yt5.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blkb0ytd.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87d04r0yth.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87eep70ytr.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87ft9n0ytv.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87h7u30yu1.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87imej0yu5.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87k0yz0yua.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87lfjf0yuf.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87mu3v0yuj.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/87o8ob0yun.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pn8r0yus.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1t70yuw.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sgdn0yv1.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87tuy30yv5.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Now we can use asoc_substream_to_rtd() macro,
let's use it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87v9ij0yv9.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Current soc-xxx are getting rtd from substream by

	rtd = substream->private_data;

But, getting data from "private_data" is very unclear.
This patch adds asoc_substream_to_rtd() macro which is
easy to understand that rtd from substream.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wo2z0yve.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series "ASoC: mediatek: mt8183: support machine driver for max98357b" from Tzung-Bi Shih <tzungbi@google.com>:

The series re-uses mt8183-mt6358-ts3a227-max98357.c to support machine driver
with max98357b.

The 1st patch enables left justified format from mt8183 audio platform.

The 2nd patch adds document for the new proposed compatible string for
max98357b.

The 3rd patch supports machine driver with max98357b and uses left justified
format for it.

Tzung-Bi Shih (3):
  ASoC: mediatek: mt8183: support left justified format for I2S
  ASoC: dt-bindings: mt8183: add compatible string for using max98357b
  ASoC: mediatek: mt8183: support machine driver with max98357b

 .../sound/mt8183-mt6358-ts3a227-max98357.txt  |  1 +
 sound/soc/mediatek/mt8183/mt8183-dai-i2s.c    | 59 ++++++++++++++++---
 .../mt8183/mt8183-mt6358-ts3a227-max98357.c   | 22 ++++++-
 3 files changed, 73 insertions(+), 9 deletions(-)

--
2.28.0.rc0.105.gf9edc3c819-goog

Daniel Baluta <daniel.baluta@nxp.com>:

From: Daniel Baluta <daniel.baluta@nxp.com>

This patchseries contains a couple of SOF IMX fixes
found during our first IMX SOF release.

Daniel Baluta (7):
  ASoC: SOF: define INFO_ flags in dsp_ops for imx8
  ASoC: SOF: imx: Use ARRAY_SIZE instead of hardcoded value
  ASoC: SOF: imx8: Fix ESAI DAI driver name for i.MX8/iMX8X
  ASoC: SOF: imx8m: Fix SAI DAI driver for i.MX8M
  ASoC: SOF: imx8: Add SAI dai driver for i.MX/i.MX8X
  ASoC: SOF: topology: Update SAI config bclk/fsync rate
  ASoC: SOF: pcm: Update rate/channels for SAI/ESAI DAIs

 sound/soc/sof/imx/imx8.c  | 24 +++++++++++++++++++++---
 sound/soc/sof/imx/imx8m.c |  4 ++--
 sound/soc/sof/pcm.c       |  8 ++++++++
 sound/soc/sof/topology.c  |  2 ++
 4 files changed, 33 insertions(+), 5 deletions(-)

--
2.17.1

Commit 5bd70440 ("ASoC: soc-dai: revert all changes to DAI
startup/shutdown sequence"), introduced a slight change of semantics
to DAI startup/shutdown. If startup() returns an error, shutdown()
is now called for the DAI.

This causes a deadlock in hdac_hda which issues a call to
snd_hda_codec_pcm_put() in case open fails. Upon error, soc_pcm_open()
will call shutdown(), and pcm_put() ends up getting called twice. Result
is a deadlock on pcm->open_mutex, as snd_device_free() gets called from
within snd_pcm_open(). Typical task backtrace looks like this:

[  334.244627]  snd_pcm_dev_disconnect+0x49/0x340 [snd_pcm]
[  334.244634]  __snd_device_disconnect.part.0+0x2c/0x50 [snd]
[  334.244640]  __snd_device_free+0x7f/0xc0 [snd]
[  334.244650]  snd_hda_codec_pcm_put+0x87/0x120 [snd_hda_codec]
[  334.244660]  soc_pcm_open+0x6a0/0xbe0 [snd_soc_core]
[  334.244676]  ? dpcm_add_paths.isra.0+0x491/0x590 [snd_soc_core]
[  334.244679]  ? kfree+0x9a/0x230
[  334.244686]  dpcm_be_dai_startup+0x255/0x300 [snd_soc_core]
[  334.244695]  dpcm_fe_dai_open+0x20e/0xf30 [snd_soc_core]
[  334.244701]  ? snd_pcm_hw_rule_muldivk+0x110/0x110 [snd_pcm]
[  334.244709]  ? dpcm_be_dai_startup+0x300/0x300 [snd_soc_core]
[  334.244714]  ? snd_pcm_attach_substream+0x3c4/0x540 [snd_pcm]
[  334.244719]  snd_pcm_open_substream+0x69a/0xb60 [snd_pcm]
[  334.244729]  ? snd_pcm_release_substream+0x30/0x30 [snd_pcm]
[  334.244732]  ? __mutex_lock_slowpath+0x10/0x10
[  334.244736]  snd_pcm_open+0x1b3/0x3c0 [snd_pcm]

Fixes: 5bd70440 ("ASoC: soc-dai: revert all changes to DAI startup/shutdown sequence")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@linux.intel.com>
BugLink: https://github.com/thesofproject/linux/issues/2159
Link: https://lore.kernel.org/r/20200717101950.3885187-3-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

The hdac_hda remove implementation fails to free the hda codec
resources, leading to memleaks at module unload. This gap has been there
from the start, commit 6bae5ea9 ("ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers").

Instead of duplicating the cleanup logic, use the common
snd_hda_codec_cleanup_for_unbind() to free the resources. Remove
existing code in hdac_hda to cleanup "codec.jackpoll_work" and call to
snd_hdac_regmap_exit(), as these are already done in
snd_hda_codec_cleanup_for_unbind().

The cleanup is done in ASoC component remove() callback and not in the
HDAC bus hdev_detach(). This is done to ensure the codec specific
cleanup routines are run before the parent card is freed.

Fixes: 6bae5ea9 ("ASoC: hdac_hda: add asoc extension for legacy HDA codec drivers")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
BugLink: https://github.com/thesofproject/linux/issues/2195
Link: https://lore.kernel.org/r/20200717101950.3885187-2-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add error handling for patch_ops in hdac_hda_codec_probe().
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200717101950.3885187-1-kai.vehmanen@linux.intel.comSigned-off-by: Mark Brown <broonie@kernel.org>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200719153822.59788-1-grandmaster@al2klimov.deSigned-off-by: Mark Brown <broonie@kernel.org>

Supports machine driver with max98357b
("mt8183-mt6358-ts3a227-max98357b").

The key difference from max98357a: max98357b needs to use left
justified format.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200720012559.906088-4-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

Machines with max98357b should use the compatible string
"mt8183-mt6358-ts3a227-max98357b".
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200720012559.906088-3-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

MT8183 audio platform supports EIAJ and I2S formats.  The code fixed to
use I2S format in the past.

Supports EIAJ mode via set_fmt ops and preserves to use I2S format as
the default format intentionally.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200720012559.906088-2-tzungbi@google.comSigned-off-by: Mark Brown <broonie@kernel.org>

Fixup BE DAI links rate/channels parameters to match any values
from topology.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200720072046.8152-8-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

These parameters are read from topology file and sent to DSP.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20200720072046.8152-7-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

With SOF we support 1 ESAI interface and 1 SAI interface.
This patch adds SAI1 interface support existing on i.MX8/i.MX8X
boards.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20200720072046.8152-6-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

This must match DAI name from topology. Also, sai-port
is too generic. Physical DAI port on i.MX8MP is labeled SAI3.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20200720072046.8152-5-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>

This must match DAI name from topology. Also, esai-port is too generic
as they are 2 ESAIs on i.MX8/i.MX8X boards.

SOF integration only uses ESAI0 for now.
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Link: https://lore.kernel.org/r/20200720072046.8152-4-daniel.baluta@oss.nxp.comSigned-off-by: Mark Brown <broonie@kernel.org>