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

[alsa-devel] Serious bug calling ALSA lib functions from .so vs. .o file
by scott andrew franco 18 Jun '19

18 Jun '19

Hi, I am having a strange issue calling snd_pcm_* alsa-lib functions from a .so file. The example is a pretty run of the mill .wav file output example in C from the internet, which I have placed in playwav.c. I put the routine that does the pcm play, alsaplaywave(), into a routine and have a duplicate in another external file, test2.c. I named the one in playwav.c alsaplaywav1(), and the one in test2.c alsaplaywav(). The compile is done as follows: gcc -g3 -Iinclude -fPIC -c test2.c -o test2.o gcc -shared test2.o -o test2.so # # Compiling from .so causes bug, compiling from .o does not # gcc -g3 -Iinclude linux/playwav.c ./test2.so -lasound -o playwav #gcc -g3 -Iinclude linux/playwav.c ./test2.o -lasound -o playwav If the test2.so file is used, the playback has its parameters such as rate messed up, and the result is it plays as fast as possible (series of chirps). If the above line is just changed to test2.o, the playback is fine. Further, if the copy of alsaplaywav() local to the playwav.c file is executed, the playback is correct. It is only when playing from the routine in the .so file that it messes up. To find out what the key point of failure is, I put all of the preamble for the routine up until it does a snd_pcm_hw_params_set_rate_near() at the calling point (in playwav.c) and commented that out in the routine. The idea was to see exactly which alsa call being done inside the .so caused the malfunction. The rate set appears to be the key. Do that outside the .so, it works, do it inside, it does not. I note that snd_pcm_hw_params_set_rate_near() goes through a few macros in alsa-lib. I think I could debug this better if I can get alsa symbols into gdb. As in the other message, I cannot figure out where the libasound.so gets constructed in the build. I see libasound.a, but no libasound.so. Apologies for not cutting the example down further, but the failure mode is quite complex and that is difficult. Find playwav.c and test2.c attached, and the compile instructions I used above or in cplaywav. The files are fairly small. Thanks for any help. Scott Franco

3 8

[alsa-devel] [PATCH v7 0/4] Fix jack detection for Chromebook Pixel
by Fletcher Woodruff 18 Jun '19

18 Jun '19

Headphone/mic jack detection doesn't work on the Chromebook Pixel 2015. This patch changes the irq implementation to support polarity flipping and fixes the configuration code so that correct GPIO pins are read from ACPI. With this series, plugging and unplugging the headphone jack switches between headphones and speakers automatically, and headset microphones are also detected. v7: - Rebase onto for-next branch of broonie/sound.git v6: - Move refactoring into its own patch - Reorder patches so that DT property names patch is first - Clarify commit message for patch which implements irq handler - Remove unused work struct - Make IRQ function return IRQ_HANDLED only if IRQs actually fire v5: - Fix void* parameter to devm_request_threaded_irq v4: - Fix incorrect void* cast in rt5677_irq() v3: - Update commit message for patch 1/3 to clarify why we implement our own irq_chip. v2: - Split IRQ change into two patches: adding and fixing potential race - Change config reading code to try both DT and ACPI style names Ben Zhang (2): ASoC: rt5677: clear interrupts by polarity flip ASoC: rt5677: handle concurrent interrupts Fletcher Woodruff (2): ASoC: rt5677: fall back to DT prop names on error ASoC: rt5677: move jack-detect init to i2c probe sound/soc/codecs/rt5677.c | 319 ++++++++++++++++++++++++++------------ sound/soc/codecs/rt5677.h | 13 +- 2 files changed, 236 insertions(+), 96 deletions(-) -- 2.22.0.410.gd8fdbe21b5-goog

4 11

[alsa-devel] [PATCH] ASoC: Intel: sof_rt5682: use GFP_KERNEL instead of GFP_ATOMIC
by Tzung-Bi Shih 18 Jun '19

18 Jun '19

Change the memory allocation flag from GFP_ATOMIC to GFP_KERNEL because probe of platform device is unlikely a place where cannot sleep. Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- It might be a typo introduced from copied-and-pasted. sound/soc/intel/boards/sof_rt5682.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c index e2e5f97d9920..02138aa8a850 100644 --- a/sound/soc/intel/boards/sof_rt5682.c +++ b/sound/soc/intel/boards/sof_rt5682.c @@ -498,7 +498,7 @@ static int sof_audio_probe(struct platform_device *pdev) int dmic_num, hdmi_num; int ret, ssp_amp, ssp_codec; - ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_ATOMIC); + ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM; -- 2.22.0.410.gd8fdbe21b5-goog

3 2

[alsa-devel] [PATCH v2 1/1] ASoC: rsnd: fixup mod ID calculation in rsnd_ctu_probe_
by Jiada Wang 18 Jun '19

18 Jun '19

From: Nilkanth Ahirrao <anilkanth(a)jp.adit-jv.com> commit c16015f36cc1 ("ASoC: rsnd: add .get_id/.get_id_sub") introduces rsnd_ctu_id which calcualates and gives the main Device id of the CTU by dividing the id by 4. rsnd_mod_id uses this interface to get the CTU main Device id. But this commit forgets to revert the main Device id calcution previously done in rsnd_ctu_probe_ which also divides the id by 4. This path corrects the same to get the correct main Device id. The issue is observered when rsnd_ctu_probe_ is done for CTU1 Fixes: c16015f36cc1 ("ASoC: rsnd: add .get_id/.get_id_sub") Signed-off-by: Nilkanth Ahirrao <anilkanth(a)jp.adit-jv.com> Signed-off-by: Suresh Udipi <sudipi(a)jp.adit-jv.com> Signed-off-by: Jiada Wang <jiada_wang(a)mentor.com> --- v2: fixed commit id v1: initial version --- sound/soc/sh/rcar/ctu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sh/rcar/ctu.c b/sound/soc/sh/rcar/ctu.c index 8cb06dab234e..7647b3d4c0ba 100644 --- a/sound/soc/sh/rcar/ctu.c +++ b/sound/soc/sh/rcar/ctu.c @@ -108,7 +108,7 @@ static int rsnd_ctu_probe_(struct rsnd_mod *mod, struct rsnd_dai_stream *io, struct rsnd_priv *priv) { - return rsnd_cmd_attach(io, rsnd_mod_id(mod) / 4); + return rsnd_cmd_attach(io, rsnd_mod_id(mod)); } static void rsnd_ctu_value_init(struct rsnd_dai_stream *io, -- 2.19.2

3 2

[alsa-devel] Issues with tip alsa-lib (stable, 1.1.9)
by scott andrew franco 18 Jun '19

18 Jun '19

A roundup of my current issues with the alsa-lib repository: 1. No apparent .so (dynamic link) file output. The configure and make instructions were followed, and no apparent .so resulted: samiam@samiam-home-pc:~/projects/alsa/alsa-lib-1.1.9$ find . -name *.so samiam@samiam-home-pc:~/projects/alsa/alsa-lib-1.1.9$ find . -name *.a ./src/timer/.libs/libtimer.a ./src/rawmidi/.libs/librawmidi.a ./src/ucm/.libs/libucm.a ./src/topology/.libs/libtopology.a ./src/.libs/libasound.a ./src/hwdep/.libs/libhwdep.a ./src/seq/.libs/libseq.a ./src/mixer/.libs/libmixer.a ./src/control/.libs/libcontrol.a ./src/pcm/.libs/libpcm.a samiam@samiam-home-pc:~/projects/alsa/alsa-lib-1.1.9$ This has made it difficult to debug issues with the library. Using the configure flags does not seem to have an effect on this, IE: ./configure --enable-shared=yes --enable-static=no Linux distributions have libasound.so files in them, so clearly it was possible at some time in the past. 2. Build instructions are conflicting. ./configure make Does work on this version. This is the standard GNU build method, and I have seen these build instructions around the internet for building alsa. The INSTALL file recommends: ./gitcompile Which also (appears) to work, but no reason appears for why this special file is needed or what it does that is different. I can't get a .so (dynamic library from the build, so I can't check the function of the resulting build. Is there a reason the instructions from ./gitcompile cannot be merged back into the make? 3. make install brings the system down. Executing: make install Brought my ubuntu 18.04 sound system down. I had to reinstall Ubuntu to get it to work again. In summary, ALSA is not a development project anymore. It is the "official sound system of Linux" and is part of the kernel. There is a lot of activity on the ALSA list. Cannot some effort be put into professionalizing the repository? Thank you for your attention, Scott A. Franco San Jose, CA

2 1

[alsa-devel] [PATCH 1/2] ASoC: Intel: sof-rt5682: add MCLK support for BYT platform
by Bard liao 18 Jun '19

18 Jun '19

From: Xun Zhang <xun2.zhang(a)intel.com> The sof-rt5682 machine driver currently uses BCLK on BYT/Minnowboard platform. The MCLK signal is available since the Turbot revision, so enable MCLK on BYT/Minnowboard Turbot platform. Signed-off-by: Xun Zhang <xun2.zhang(a)intel.com> Signed-off-by: Bard liao <yung-chuan.liao(a)linux.intel.com> --- sound/soc/intel/boards/sof_rt5682.c | 65 ++++++++++++++++++++++++++++- 1 file changed, 64 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c index e2e5f97d9920..f3d481b75b15 100644 --- a/sound/soc/intel/boards/sof_rt5682.c +++ b/sound/soc/intel/boards/sof_rt5682.c @@ -9,6 +9,7 @@ #include <linux/input.h> #include <linux/module.h> #include <linux/platform_device.h> +#include <linux/clk.h> #include <linux/dmi.h> #include <sound/core.h> #include <sound/jack.h> @@ -32,6 +33,7 @@ #define SOF_RT5682_SSP_AMP_MASK (GENMASK(8, 6)) #define SOF_RT5682_SSP_AMP(quirk) \ (((quirk) << SOF_RT5682_SSP_AMP_SHIFT) & SOF_RT5682_SSP_AMP_MASK) +#define SOF_RT5682_MCLK_BYTCHT_EN BIT(9) /* Default: MCLK on, MCLK 19.2M, SSP0 */ static unsigned long sof_rt5682_quirk = SOF_RT5682_MCLK_EN | @@ -48,6 +50,7 @@ struct sof_hdmi_pcm { }; struct sof_card_private { + struct clk *mclk; struct snd_soc_jack sof_headset; struct list_head hdmi_pcm_list; }; @@ -59,6 +62,22 @@ static int sof_rt5682_quirk_cb(const struct dmi_system_id *id) } static const struct dmi_system_id sof_rt5682_quirk_table[] = { + { + .callback = sof_rt5682_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Circuitco"), + DMI_MATCH(DMI_PRODUCT_NAME, "Minnowboard Max"), + }, + .driver_data = (void *)(SOF_RT5682_SSP_CODEC(2)), + }, + { + .callback = sof_rt5682_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "AAEON"), + DMI_MATCH(DMI_PRODUCT_NAME, "UP-CHT01"), + }, + .driver_data = (void *)(SOF_RT5682_SSP_CODEC(2)), + }, { .callback = sof_rt5682_quirk_cb, .matches = { @@ -127,6 +146,27 @@ static int sof_rt5682_codec_init(struct snd_soc_pcm_runtime *rtd) RT5682_CLK_SEL_I2S1_ASRC); } + if (sof_rt5682_quirk & SOF_RT5682_MCLK_BYTCHT_EN) { + /* + * The firmware might enable the clock at + * boot (this information may or may not + * be reflected in the enable clock register). + * To change the rate we must disable the clock + * first to cover these cases. Due to common + * clock framework restrictions that do not allow + * to disable a clock that has not been enabled, + * we need to enable the clock first. + */ + ret = clk_prepare_enable(ctx->mclk); + if (!ret) + clk_disable_unprepare(ctx->mclk); + + ret = clk_set_rate(ctx->mclk, 19200000); + + if (ret) + dev_err(rtd->dev, "unable to set MCLK rate\n"); + } + /* * Headset buttons map to the google Reference headset. * These can be configured by userspace. @@ -161,10 +201,20 @@ static int sof_rt5682_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct sof_card_private *ctx = snd_soc_card_get_drvdata(rtd->card); struct snd_soc_dai *codec_dai = rtd->codec_dai; int clk_id, clk_freq, pll_out, ret; if (sof_rt5682_quirk & SOF_RT5682_MCLK_EN) { + if (sof_rt5682_quirk & SOF_RT5682_MCLK_BYTCHT_EN) { + ret = clk_prepare_enable(ctx->mclk); + if (ret < 0) { + dev_err(rtd->dev, + "could not configure MCLK state"); + return ret; + } + } + clk_id = RT5682_PLL1_S_MCLK; if (sof_rt5682_quirk & SOF_RT5682_MCLK_24MHZ) clk_freq = 24000000; @@ -507,7 +557,9 @@ static int sof_audio_probe(struct platform_device *pdev) dmic_num = 0; hdmi_num = 0; /* default quirk for legacy cpu */ - sof_rt5682_quirk = SOF_RT5682_SSP_CODEC(2); + sof_rt5682_quirk = SOF_RT5682_MCLK_EN | + SOF_RT5682_MCLK_BYTCHT_EN | + SOF_RT5682_SSP_CODEC(2); } else { dmic_num = 1; hdmi_num = 3; @@ -515,6 +567,17 @@ static int sof_audio_probe(struct platform_device *pdev) dmi_check_system(sof_rt5682_quirk_table); + /* need to get main clock from pmc */ + if (sof_rt5682_quirk & SOF_RT5682_MCLK_BYTCHT_EN) { + ctx->mclk = devm_clk_get(&pdev->dev, "pmc_plt_clk_3"); + ret = clk_prepare_enable(ctx->mclk); + if (ret < 0) { + dev_err(&pdev->dev, + "could not configure MCLK state"); + return ret; + } + } + dev_dbg(&pdev->dev, "sof_rt5682_quirk = %lx\n", sof_rt5682_quirk); ssp_amp = (sof_rt5682_quirk & SOF_RT5682_SSP_AMP_MASK) >> -- 2.17.1

2 2

Re: [alsa-devel] udev: Access permission of fw character device in which fw node includes unit handled by ALSA
by Takashi Sakamoto 18 Jun '19

18 Jun '19

Hi Lennart, Thanks for your reply, and notice to this legacy and minor issue ;) On Mon, Jun 17, 2019, at 22:26, Lennart Poettering wrote: > On Mo, 20.05.19 21:27, Takashi Sakamoto (o-takashi(a)sakamocchi.jp) wrote: > > > Hi all, > > > > I'm an ALSA developer, mainly committing to drivers for audio and > > music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a > > concern about access permission for fw character device. > > I am not sure I understand firewire well enough to say something too > smart. But if I understand correctly, then we (in systemd upstream) > currently only have these four firewire specific rules in our tree: > > SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video" > SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video" > SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video" > SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video" > > And all of these are handled by some firewire core driver? Although it's probable that some of them are handled by in-kernel driver (perhaps firedtv.ko), they're just for userspace applications. The in-kernel driver adds another device to system (in this case video character device) and access rules to it are apart from the one for fw character device, as long as all features are implemented in the in-kernel driver. In a case of drivers in ALSA firewire stack, we decided to implement a part of features in userspace application, due to the complexity of vendor-dependent protocols. The in-kernel drivers just implement isochronous packet streaming for PCM frames and MIDI messages, and tells userspace applications the related fw character device via ALSA hwdep interface[1]. > The devices you care about, how would the rules look like for this? Here, I'd like to explain about the relationships between instances on IEEE 1394 bus topology and fw character device, modalias on in-kernel driver. ``` IEEE 1394 bus + node A (=fw character device, /dew/fw0) + unit A1 (=modalias on in-kernel driver, fw0.0) + unit B2 (=modalias on in-kernel driver, fw0.1) + ... + node B (=fw character device, /dev/fw1) + unit B1 (=modalias on in-kernel driver, fw1.0) + unit B2 (=modalias on in-kernel driver, fw1.1) + ... + ... ``` The relationship between node/unit is similar to device/interface in USB case. One node can includes several units which represent actual functionalities, and any in-kernel driver is bound to one of the units. On the other hand, fw character device is added for each node. The node is subject of communication. When any driver in ALSA firewire stack is bound to one of units in a node, I expect udevd to change group of the corresponding fw character device to 'audio', and expect logind to assign ACL to it. + node A (fw character device with 'audio' group, +uaccess) + unit A1 (any driver in ALSA firewire stack is bound to) In current framework of udev rule, this seems to be difficult to achieve, in my opinion. Thus, if I managed to achieve it by rule framework, I would add and maintain many entries generated from my registry[2]. > In general, when it comes to auto-loading of drivers we usually expect > the kernel to add modalias metadata to .ko files. > > In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff > that is great to have but is not essential for a device to work > basically. > > Rules files should generally be kept short. i.e. if you add 3 more > rules for the devices you care about, that'd be fine — if you add 100, > then that's not so great however, and another approach should be > found. Yes. I'd like to avoid increasing maintenance cost of anybody including myself... > Anyway, given that I am not a firewire pro, I figure you have to > decide yourself what the best approach is, and then prep a PR and we > can have a look. Without looking at an (maybe just RFC) patch I am not > sure I grok enugh to properly comment on it. Okay. I'll attempt to post several RFC patches. It takes me a bit long time because this is my first attempt to commit systemd, but I'm happy if you review and comment to them. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc… [2] https://github.com/takaswie/am-config-roms Thanks Takashi Sakamoto

1 0

[alsa-devel] [PATCH] dt-bindings: Add missing newline at end of file
by Geert Uytterhoeven 18 Jun '19

18 Jun '19

"git diff" says: \ No newline at end of file after modifying the files. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt | 2 +- .../devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt | 2 +- Documentation/devicetree/bindings/regulator/pv88060.txt | 2 +- Documentation/devicetree/bindings/sound/cs42l73.txt | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt index 3538a214fff156d4..352f5e9c759bc3f5 100644 --- a/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt +++ b/Documentation/devicetree/bindings/ipmi/npcm7xx-kcs-bmc.txt @@ -36,4 +36,4 @@ Example: kcs_chan = <2>; status = "disabled"; }; - }; \ No newline at end of file + }; diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt index 83f4bbac94bb19db..a1264cc8660dcd59 100644 --- a/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,npcm7xx-pinctrl.txt @@ -213,4 +213,4 @@ pinctrl: pinctrl@f0800000 { groups = "clkreq"; function = "clkreq"; }; -}; \ No newline at end of file +}; diff --git a/Documentation/devicetree/bindings/regulator/pv88060.txt b/Documentation/devicetree/bindings/regulator/pv88060.txt index 10a6dadc008eb38d..6a7c8a92fdb0bf1c 100644 --- a/Documentation/devicetree/bindings/regulator/pv88060.txt +++ b/Documentation/devicetree/bindings/regulator/pv88060.txt @@ -121,4 +121,4 @@ Example regulator-max-microvolt = <5000000>; }; }; - }; \ No newline at end of file + }; diff --git a/Documentation/devicetree/bindings/sound/cs42l73.txt b/Documentation/devicetree/bindings/sound/cs42l73.txt index 80ae910dbf6c3880..47b868b5ab011470 100644 --- a/Documentation/devicetree/bindings/sound/cs42l73.txt +++ b/Documentation/devicetree/bindings/sound/cs42l73.txt @@ -19,4 +19,4 @@ codec: cs42l73@4a { reg = <0x4a>; reset_gpio = <&gpio 10 0>; chgfreq = <0x05>; -}; \ No newline at end of file +}; -- 2.17.1

2 1

[alsa-devel] [PATCH] ASoC: soc-core: export function to find components
by bgoswami＠codeaurora.org 18 Jun '19

18 Jun '19

From: Banajit Goswami <bgoswami(a)codeaurora.org> Drivers may need to use the ASoC core function to find out whether a particular component is already registered with ASoC core or not. Export the function so that drivers can use it outside of the file. Signed-off-by: Banajit Goswami <bgoswami(a)codeaurora.org> --- include/sound/soc.h | 2 ++ sound/soc/soc-core.c | 13 ++++++++++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 482b4ea..def975f 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1405,6 +1405,8 @@ int snd_soc_component_update_bits_async(struct snd_soc_component *component, void snd_soc_component_async_complete(struct snd_soc_component *component); int snd_soc_component_test_bits(struct snd_soc_component *component, unsigned int reg, unsigned int mask, unsigned int value); +struct snd_soc_component *soc_find_component( + const struct device_node *of_node, const char *name); /* component wide operations */ int snd_soc_component_set_sysclk(struct snd_soc_component *component, diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 41c0cfa..50a9977 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -741,7 +741,17 @@ int snd_soc_resume(struct device *dev) static const struct snd_soc_dai_ops null_dai_ops = { }; -static struct snd_soc_component *soc_find_component( +/** + * soc_find_component: find a component from component_list in ASoC core + * + * @of_node: of_node of the component to query. + * @name: name of the component to query. + * + * function to find out if a component is already registered with ASoC core. + * + * Returns component handle for success, else NULL error. + */ +struct snd_soc_component *soc_find_component( const struct device_node *of_node, const char *name) { struct snd_soc_component *component; @@ -764,6 +774,7 @@ static struct snd_soc_component *soc_find_component( return NULL; } +EXPORT_SYMBOL(soc_find_component); static int snd_soc_is_matching_component( const struct snd_soc_dai_link_component *dlc, -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 2

[alsa-devel] [PATCH v2 0/3] ASoC: SOF: fix suspend ordering with runtime idle
by Kai Vehmanen 18 Jun '19

18 Jun '19

Hi all, this series addresses issues with ordering of HDA codec and controller suspends in the runtime PM flows. The implemented logic for SOF is similar to what has been used by the Intel AZX HDA driver. To implement this, first a fix is needed to hdac_hdmic ASoC codec driver. SOF framework also needs to be extended to allow SOF devices to implement a runtime_idle callback. Third, concrete implementation is in a separate patch for APL/CNL Intel hardware, for which strict ordering of codec-controller power down sequence needs to be maintained. As this extends the SOF device interface, Pierre asked me to send to the list for wider review. This series has been prereviewd at SOF github as: https://github.com/thesofproject/linux/pull/1003 v2: - Rebased on broonie/for-next, there was a conflict with patch "ASoC: SOF: Intel: hda: release link DMA for paused streams during suspend" - Added Reviewed-by tags from v1 round Kai Vehmanen (3): ASoC: hdac_hdmi: report codec link up/down status to bus ASoC: SOF: add runtime idle callback ASoC: SOF: Intel: implement runtime idle for CNL/APL sound/soc/codecs/hdac_hdmi.c | 2 ++ sound/soc/sof/intel/apl.c | 1 + sound/soc/sof/intel/cnl.c | 1 + sound/soc/sof/intel/hda-dsp.c | 13 +++++++++++++ sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/ops.h | 8 ++++++++ sound/soc/sof/pm.c | 8 ++++++++ sound/soc/sof/sof-acpi-dev.c | 2 +- sound/soc/sof/sof-pci-dev.c | 2 +- sound/soc/sof/sof-priv.h | 2 ++ 10 files changed, 38 insertions(+), 2 deletions(-) -- 2.17.1

1 3