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

[PATCH] [RFC] alsaloop: add feedback frequency control support for UAC2 gadgets
by Ruslan Bilovol 04 Dec '20

04 Dec '20

Add support of special "PCM Feedback Frequency Hz" UAC2 Gadget mixer control that is designed to notify host about real sampling frequency of the gadget so it can adjust number of samples that hosts sends to the gadget. This is useful if both host and gadget has its own internal freerunning clock, so host can adjust number of samples sent, preventing overrun/underrun conditions. This patch reuses logic of the "PCM Rate Shift 100000" control used in case of in-kernel ALSA loopback driver. The only difference is alsaloop reports not rate shift but frequency in Hz Signed-off-by: Ruslan Bilovol <ruslan.bilovol(a)gmail.com> --- alsaloop/alsaloop.h | 1 + alsaloop/pcmjob.c | 35 +++++++++++++++++++++++++---------- 2 files changed, 26 insertions(+), 10 deletions(-) diff --git a/alsaloop/alsaloop.h b/alsaloop/alsaloop.h index c4aa618..9a50a42 100644 --- a/alsaloop/alsaloop.h +++ b/alsaloop/alsaloop.h @@ -122,6 +122,7 @@ struct loopback_handle { unsigned int ctl_pollfd_count; snd_ctl_elem_value_t *ctl_notify; snd_ctl_elem_value_t *ctl_rate_shift; + snd_ctl_elem_value_t *ctl_fback_freq; snd_ctl_elem_value_t *ctl_active; snd_ctl_elem_value_t *ctl_format; snd_ctl_elem_value_t *ctl_rate; diff --git a/alsaloop/pcmjob.c b/alsaloop/pcmjob.c index 6a9aff4..b3802a8 100644 --- a/alsaloop/pcmjob.c +++ b/alsaloop/pcmjob.c @@ -1058,15 +1058,22 @@ static int set_notify(struct loopback_handle *lhandle, int enable) static int set_rate_shift(struct loopback_handle *lhandle, double pitch) { - int err; + int err = 0; - if (lhandle->ctl_rate_shift == NULL) - return 0; - snd_ctl_elem_value_set_integer(lhandle->ctl_rate_shift, 0, pitch * 100000); - err = snd_ctl_elem_write(lhandle->ctl, lhandle->ctl_rate_shift); - if (err < 0) { - logit(LOG_CRIT, "Cannot set PCM Rate Shift element for %s: %s\n", lhandle->id, snd_strerror(err)); - return err; + if (lhandle->ctl_rate_shift) { + snd_ctl_elem_value_set_integer(lhandle->ctl_rate_shift, 0, pitch * 100000); + err = snd_ctl_elem_write(lhandle->ctl, lhandle->ctl_rate_shift); + if (err < 0) { + logit(LOG_CRIT, "Cannot set PCM Rate Shift element for %s: %s\n", lhandle->id, snd_strerror(err)); + return err; + } + } else if (lhandle->ctl_fback_freq) { + snd_ctl_elem_value_set_integer(lhandle->ctl_fback_freq, 0, lhandle->rate * (2.0 - pitch)); + err = snd_ctl_elem_write(lhandle->ctl, lhandle->ctl_fback_freq); + if (err < 0) { + logit(LOG_CRIT, "Cannot set PCM Feedback Frequency element for %s: %s\n", lhandle->id, snd_strerror(err)); + return err; + } } return 0; } @@ -1195,6 +1202,7 @@ static int openctl(struct loopback_handle *lhandle, int device, int subdevice) int err; lhandle->ctl_rate_shift = NULL; + lhandle->ctl_fback_freq = NULL; if (lhandle->loopback->play == lhandle) { if (lhandle->loopback->controls) goto __events; @@ -1204,6 +1212,8 @@ static int openctl(struct loopback_handle *lhandle, int device, int subdevice) &lhandle->ctl_notify); openctl_elem(lhandle, device, subdevice, "PCM Rate Shift 100000", &lhandle->ctl_rate_shift); + openctl_elem(lhandle, device, subdevice, "PCM Feedback Frequency Hz", + &lhandle->ctl_fback_freq); set_rate_shift(lhandle, 1); openctl_elem(lhandle, device, subdevice, "PCM Slave Active", &lhandle->ctl_active); @@ -1289,6 +1299,9 @@ static int closeit(struct loopback_handle *lhandle) if (lhandle->ctl_rate_shift) snd_ctl_elem_value_free(lhandle->ctl_rate_shift); lhandle->ctl_rate_shift = NULL; + if (lhandle->ctl_fback_freq) + snd_ctl_elem_value_free(lhandle->ctl_fback_freq); + lhandle->ctl_fback_freq = NULL; if (lhandle->ctl) err = snd_ctl_close(lhandle->ctl); lhandle->ctl = NULL; @@ -1334,9 +1347,11 @@ int pcmjob_init(struct loopback *loop) snprintf(id, sizeof(id), "%s/%s", loop->play->id, loop->capt->id); id[sizeof(id)-1] = '\0'; loop->id = strdup(id); - if (loop->sync == SYNC_TYPE_AUTO && loop->capt->ctl_rate_shift) + if (loop->sync == SYNC_TYPE_AUTO && (loop->capt->ctl_rate_shift || + loop->capt->ctl_fback_freq)) loop->sync = SYNC_TYPE_CAPTRATESHIFT; - if (loop->sync == SYNC_TYPE_AUTO && loop->play->ctl_rate_shift) + if (loop->sync == SYNC_TYPE_AUTO && (loop->play->ctl_rate_shift || + loop->play->ctl_fback_freq)) loop->sync = SYNC_TYPE_PLAYRATESHIFT; #ifdef USE_SAMPLERATE if (loop->sync == SYNC_TYPE_AUTO && loop->src_enable) -- 1.9.1

2 2

Behringer WING usb audio - cyclic xruns dependent on periods/buffers
by Ben Bell 03 Dec '20

03 Dec '20

I've got a Behringer WING digital mixer which is equipped with a USB interface supporting 48 in, 48 out at 44.1 or 48kHz. It's plugged into a USB3 interface and for the most part it seems to work well as a class-compliant audio interface, but I'm struggling to eliminate xruns and it's starting to feel either driver or hardware quirk related issue. I've done all the usual things -- I'm running a PREEMPT_RT kernel, set up the realtime priorities of Jack and the relevant USB IRQ to no avail. I'm doing most of the debugging remotely over ssh with X shutdown and most other processes on the system stopped. There's nothing plugged into the computer beyond network, keyboard, mouse and the audio interface. I'm currently testing on kernel 5.10.0-rc5 with preempt-rt patches, but I've previously seen the same things on 5.4-rt (Debian backports) and 5.8 (self-compiled). The xruns are characterised by bursts of "retire_capture_urb" warnings in the kernel logs (and in particular the frame status for everything in those URBs is EXDEV, meaning I think that the frames haven't been consumed by the time it's retired). I've patched sound/driver/pcm.c to provide me with a bit more debugging information and it looks like usually it's almost always between 7-10 consecutive calls to retire_capture_urb that are affected. The bursts of retire_capture_urb warnings seem roughly cyclic, with a cycle time that is dependent on the combination of the frames/period setting and the number of periods per buffer, though it doesn't appear to be a strictly linear thing: 512/2 (~170s cycle); 256/2 (~94s); 128/3 (~65s); 64/13 (~270s). I can't immediately see any definitive smoking gun in the urb or interrupt counts, but there is some grouping in the timings between the xruns. Taking 64 frames, 5 periods, it's usually 50s, but sometimes 60s: 21:47:57 50s since xrun 4 21:48:47 50s since xrun 5 21:49:46 59s since xrun 6 21:50:46 60s since xrun 7 21:51:36 50s since xrun 8 21:52:36 60s since xrun 9 21:53:36 60s since xrun 10 21:54:37 61s since xrun 11 21:55:27 50s since xrun 12 21:56:27 60s since xrun 13 21:57:27 60s since xrun 14 21:58:17 50s since xrun 15 21:59:16 59s since xrun 16 22:00:06 50s since xrun 17 22:00:56 50s since xrun 18 ... If I count the URB numbers (sorry, I'm shaky on the terminology, but I'm counting each URB which is retired) I often (but not always) see the same number of URBs passing between xrun bursts. Currently at 64 frames/5 periods, it's often exactly 50042 or 49923 urbs between bursts. The delay between starting Jack and encountering the first burst is not predictable -- it's not just a whole cycle -- but stopping jack for e.g 30s then starting again delays the next burst by the same amount. So it does seem related to something in the audio streaming rather than anything else going on on the system interfering. It's as if something is slowly slipping out of sync between the Wing and the kernel until they need to resync, but I don't really know enough about USB to have any deeper insight. All the tests above happen to be at 44.1kHz with the Wing set to 48 in, 48 out, but changing to 48kHz or 2/2 IO doesn't seem to cure anything. One more data point which may not be relevant: if I switch off or unplug the Wing while Jack is running, the system gradually locks up over a period of a few seconds. I can get something out of the console briefly afterwards but within about ten seconds it's completely unresponsive. I imagine that pulling out a USB device from a realtime thread isn't a kind thing to do, but I don't recall this happening with other interfaces. Any help or insights into where I should be looking (I'm a newbie in kernel space) appreciated. If someone wants remote access to the box to investigate in realtime we could probably figure something out. bjb

2 3

[PATCH 1/2] ASoC: fsl-asoc-card: Add support for si476x codec
by Shengjiu Wang 03 Dec '20

03 Dec '20

The si476x codec is used for FM radio function on i.MX6 auto board, it only supports recording function. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/fsl-asoc-card.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c index a2dd3b6b7fec..f62f81ceab0d 100644 --- a/sound/soc/fsl/fsl-asoc-card.c +++ b/sound/soc/fsl/fsl-asoc-card.c @@ -131,6 +131,13 @@ static const struct snd_soc_dapm_route audio_map_tx[] = { {"CPU-Playback", NULL, "ASRC-Playback"}, }; +static const struct snd_soc_dapm_route audio_map_rx[] = { + /* 1st half -- Normal DAPM routes */ + {"CPU-Capture", NULL, "Capture"}, + /* 2nd half -- ASRC DAPM routes */ + {"ASRC-Capture", NULL, "CPU-Capture"}, +}; + /* Add all possible widgets into here without being redundant */ static const struct snd_soc_dapm_widget fsl_asoc_card_dapm_widgets[] = { SND_SOC_DAPM_LINE("Line Out Jack", NULL), @@ -653,6 +660,11 @@ static int fsl_asoc_card_probe(struct platform_device *pdev) priv->cpu_priv.slot_width = 32; priv->card.dapm_routes = audio_map_tx; priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_tx); + } else if (of_device_is_compatible(np, "fsl,imx-audio-si476x")) { + codec_dai_name = "si476x-codec"; + priv->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS; + priv->card.dapm_routes = audio_map_rx; + priv->card.num_dapm_routes = ARRAY_SIZE(audio_map_rx); } else { dev_err(&pdev->dev, "unknown Device Tree compatible\n"); ret = -EINVAL; @@ -869,6 +881,7 @@ static const struct of_device_id fsl_asoc_card_dt_ids[] = { { .compatible = "fsl,imx-audio-wm8960", }, { .compatible = "fsl,imx-audio-mqs", }, { .compatible = "fsl,imx-audio-wm8524", }, + { .compatible = "fsl,imx-audio-si476x", }, {} }; MODULE_DEVICE_TABLE(of, fsl_asoc_card_dt_ids); -- 2.27.0

3 3

[PATCH 1/2] ASoC: dt-bindings: imx-hdmi: Add binding doc for hdmi machine driver
by Shengjiu Wang 03 Dec '20

03 Dec '20

Imx-hdmi is a new added machine driver for supporting hdmi devices on i.MX platforms. There is HDMI IP or external HDMI modules connect with SAI or AUD2HTX interface. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- .../bindings/sound/imx-audio-hdmi.yaml | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml diff --git a/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml b/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml new file mode 100644 index 000000000000..d5474f83ac2c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audio-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX audio complex with HDMI + +maintainers: + - Shengjiu Wang <shengjiu.wang(a)nxp.com> + +properties: + compatible: + enum: + - fsl,imx-audio-hdmi + - fsl,imx-audio-sii902x + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + audio-cpu: + description: The phandle of an CPU DAI controller + + hdmi-out: + description: | + This is a boolean property. If present, the transmitting function + of HDMI will be enabled, indicating there's a physical HDMI out + connector or jack on the board or it's connecting to some other IP + block, such as an HDMI encoder or display-controller. + + hdmi-in: + description: | + This is a boolean property. If present, the receiving function of + HDMI will be enabled, indicating there is a physical HDMI in + connector/jack on the board. + +required: + - compatible + - model + - audio-cpu + +additionalProperties: false + +examples: + - | + sound-hdmi { + compatible = "fsl,imx-audio-hdmi"; + model = "audio-hdmi"; + audio-cpu = <&aud2htx>; + hdmi-out; + }; -- 2.27.0

3 3

[PATCH v2 0/5] regmap/SoundWire/ASoC: Add SoundWire SDCA support
by Bard Liao 03 Dec '20

03 Dec '20

The MIPI SoundWire Device Class standard will define audio functionality beyond the scope of the existing SoundWire 1.2 standard, which is limited to the bus and interface. The description is inspired by the USB Audio Class, with "functions", "entities", "control selectors", "audio clusters". The main difference with the USB Audio class is that the devices are typically on a motherboard and descriptors stored in platform firmware instead of being retrieved from the device. The current set of devices managed in this patchset are conformant with the SDCA 0.6 specification and require dedicated drivers since the descriptors and platform firmware specification is not complete at this time. They do however rely on the hierarchical addressing required by the SDCA standard. Future devices conformant with SDCA 1.0 should rely on a class driver. This series adds support for the hierarchical SDCA addressing and extends regmap. It then provides 3 codecs for RT711-sdca headset codec, RT1316 amplifier and RT715-scda microphone codec. Note that the release of this code before the formal adoption of the SDCA 1.0 specification was formally endorsed by the MIPI Board to make sure there is no delay for Linux-based support of this specification. v2: - rt715-sdca: Use rt715_sdca prefix to avoid compiling issue. - rt715-sdca: Merge multiple mute/volume operation into single mute/volume operation - rt711-sdca: Initial ret = 0 as it could be used uninitialized. Jack Yu (1): ASoC/SoundWire: rt715-sdca: First version of rt715 sdw sdca codec driver Pierre-Louis Bossart (2): soundwire: SDCA: add helper macro to access controls regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ Shuming Fan (2): ASoC/SoundWire: rt1316: Add RT1316 SDCA vendor-specific driver ASoC/SoundWire: rt711-sdca: Add RT711 SDCA vendor-specific driver drivers/base/regmap/Kconfig | 6 +- drivers/base/regmap/Makefile | 1 + drivers/base/regmap/regmap-sdw-mbq.c | 101 ++ include/linux/regmap.h | 35 + include/linux/soundwire/sdw_registers.h | 32 + sound/soc/codecs/Kconfig | 20 + sound/soc/codecs/Makefile | 6 + sound/soc/codecs/rt1316-sdw.c | 756 ++++++++++++ sound/soc/codecs/rt1316-sdw.h | 115 ++ sound/soc/codecs/rt711-sdca-sdw.c | 424 +++++++ sound/soc/codecs/rt711-sdca-sdw.h | 101 ++ sound/soc/codecs/rt711-sdca.c | 1482 +++++++++++++++++++++++ sound/soc/codecs/rt711-sdca.h | 246 ++++ sound/soc/codecs/rt715-sdca-sdw.c | 278 +++++ sound/soc/codecs/rt715-sdca-sdw.h | 170 +++ sound/soc/codecs/rt715-sdca.c | 947 +++++++++++++++ sound/soc/codecs/rt715-sdca.h | 124 ++ 17 files changed, 4843 insertions(+), 1 deletion(-) create mode 100644 drivers/base/regmap/regmap-sdw-mbq.c create mode 100644 sound/soc/codecs/rt1316-sdw.c create mode 100644 sound/soc/codecs/rt1316-sdw.h create mode 100644 sound/soc/codecs/rt711-sdca-sdw.c create mode 100644 sound/soc/codecs/rt711-sdca-sdw.h create mode 100644 sound/soc/codecs/rt711-sdca.c create mode 100644 sound/soc/codecs/rt711-sdca.h create mode 100644 sound/soc/codecs/rt715-sdca-sdw.c create mode 100644 sound/soc/codecs/rt715-sdca-sdw.h create mode 100644 sound/soc/codecs/rt715-sdca.c create mode 100644 sound/soc/codecs/rt715-sdca.h -- 2.17.1

5 15

How to interperet snd_pcm_htimestamp available frames?
by Eric Buddington 02 Dec '20

02 Dec '20

I am recording from multiple (cheap USB) mics, and trying to synchronize them. I am assuming that there will be a common minimum latency (reflecting an uncontested USB bus), with occasional spikes up - but not down. In my loop, I am calling snd_pcm_mmap_begin(), snd_pcm_htimestamp(), and snd__mmap_commit() in that order. My question is about the 'avail' value returned from htimestamp. It is documented as "Number of available frames when timestamp was grabbed". Does this mean frames since the last frame consumed with _mmap_commit()? Is there a possibility of there being no timestamp, or one where 'avail' refers to some older state? Thanks for any insight. -Eric

2 1

[PATCH] pcm: set the snd_pcm_ioplug_status() tstamp field
by Jonas Holmberg 02 Dec '20

02 Dec '20

Set the status tstamp field so that it can be accessed with snd_pcm_status_get_htstamp(). Signed-off-by: Jonas Holmberg <jonashg(a)axis.com> --- src/pcm/pcm_ioplug.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/pcm/pcm_ioplug.c b/src/pcm/pcm_ioplug.c index a437ca32..9b1b8ac3 100644 --- a/src/pcm/pcm_ioplug.c +++ b/src/pcm/pcm_ioplug.c @@ -115,6 +115,7 @@ static int snd_pcm_ioplug_status(snd_pcm_t *pcm, snd_pcm_status_t * status) snd_pcm_ioplug_hw_ptr_update(pcm); status->state = io->data->state; status->trigger_tstamp = io->trigger_tstamp; + gettimestamp(&status->tstamp, pcm->tstamp_type); status->avail = snd_pcm_mmap_avail(pcm); status->avail_max = io->avail_max; return 0; -- 2.26.2

2 2

[PATCH v1] ASoC: Intel: catpt: Replace open coded variant of resource_intersection()
by Andy Shevchenko 02 Dec '20

02 Dec '20

Since we have resource_intersection() helper, let's utilize it here. Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- Promised clean up for recently introduced helper. This has dependency to the patches currently in linux-pm tree. Other than that everything else is already in upstream. Hence, logically it's better to push thru Rafael's tree than wait one more cycle. sound/soc/intel/catpt/core.h | 11 ----------- sound/soc/intel/catpt/loader.c | 2 +- 2 files changed, 1 insertion(+), 12 deletions(-) diff --git a/sound/soc/intel/catpt/core.h b/sound/soc/intel/catpt/core.h index 0f53a0d43254..a64a0a77dcb7 100644 --- a/sound/soc/intel/catpt/core.h +++ b/sound/soc/intel/catpt/core.h @@ -22,17 +22,6 @@ void catpt_sram_free(struct resource *sram); struct resource * catpt_request_region(struct resource *root, resource_size_t size); -static inline bool catpt_resource_overlapping(struct resource *r1, - struct resource *r2, - struct resource *ret) -{ - if (!resource_overlaps(r1, r2)) - return false; - ret->start = max(r1->start, r2->start); - ret->end = min(r1->end, r2->end); - return true; -} - struct catpt_ipc_msg { union { u32 header; diff --git a/sound/soc/intel/catpt/loader.c b/sound/soc/intel/catpt/loader.c index 40c22e4bb263..ff7b8f0d34ac 100644 --- a/sound/soc/intel/catpt/loader.c +++ b/sound/soc/intel/catpt/loader.c @@ -267,7 +267,7 @@ static int catpt_restore_fwimage(struct catpt_dev *cdev, r2.start = off; r2.end = r2.start + info->size - 1; - if (!catpt_resource_overlapping(&r2, &r1, &common)) + if (!resource_intersection(&r2, &r1, &common)) continue; /* calculate start offset of common data area */ off = common.start - r1.start; -- 2.29.2

4 8

[PATCH 1/2] ALSA: ppc: drop if block with always false condition
by Uwe Kleine-König 02 Dec '20

02 Dec '20

The remove callback is only called for devices that were probed successfully before. As the matching probe function cannot complete without error if dev->match_id != PS3_MATCH_ID_SOUND, we don't have to check this here. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- sound/ppc/snd_ps3.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/ppc/snd_ps3.c b/sound/ppc/snd_ps3.c index 58bb49fff184..6ab796a5d936 100644 --- a/sound/ppc/snd_ps3.c +++ b/sound/ppc/snd_ps3.c @@ -1053,8 +1053,6 @@ static int snd_ps3_driver_remove(struct ps3_system_bus_device *dev) { int ret; pr_info("%s:start id=%d\n", __func__, dev->match_id); - if (dev->match_id != PS3_MATCH_ID_SOUND) - return -ENXIO; /* * ctl and preallocate buffer will be freed in -- 2.29.2

6 15

[PATCH] soundwire: master: use pm_runtime_set_active() on add
by Bard Liao 02 Dec '20

02 Dec '20

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> The 'master' device acts as a glue layer used during bus initialization only, and it needs to be 'transparent' for pm_runtime management. Its behavior should be that it becomes active when one of its children becomes active, and suspends when all of its children are suspended. In our tests on Intel platforms, we routinely see these sort of warnings on the initial boot: [ 21.447345] rt715 sdw:3:25d:715:0: runtime PM trying to activate child device sdw:3:25d:715:0 but parent (sdw-master-3) is not active This is root-caused to a missing setup to make the device 'active' on probe. Since we don't want the device to remain active forever after the probe, the autosuspend configuration is also enabled at the end of the probe - the device will actually autosuspend only in the case where there are no devices physically attached. In practice, the master device will suspend when all its children are no longer active. Fixes: bd84256e86ecf ('soundwire: master: enable pm runtime') Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> --- drivers/soundwire/master.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/soundwire/master.c b/drivers/soundwire/master.c index 3488bb824e84..9b05c9e25ebe 100644 --- a/drivers/soundwire/master.c +++ b/drivers/soundwire/master.c @@ -8,6 +8,15 @@ #include <linux/soundwire/sdw_type.h> #include "bus.h" +/* + * The 3s value for autosuspend will only be used if there are no + * devices physically attached on a bus segment. In practice enabling + * the bus operation will result in children devices become active and + * the master device will only suspend when all its children are no + * longer active. + */ +#define SDW_MASTER_SUSPEND_DELAY_MS 3000 + /* * The sysfs for properties reflects the MIPI description as given * in the MIPI DisCo spec @@ -154,7 +163,12 @@ int sdw_master_device_add(struct sdw_bus *bus, struct device *parent, bus->dev = &md->dev; bus->md = md; + pm_runtime_set_autosuspend_delay(&bus->md->dev, SDW_MASTER_SUSPEND_DELAY_MS); + pm_runtime_use_autosuspend(&bus->md->dev); + pm_runtime_mark_last_busy(&bus->md->dev); + pm_runtime_set_active(&bus->md->dev); pm_runtime_enable(&bus->md->dev); + pm_runtime_idle(&bus->md->dev); device_register_err: return ret; } -- 2.17.1

3 5