RE: [alsa-devel] [PATCH v2 2/3] ASoC: topology: Move v4 manifest header data structures to uapi

[Lin, Mengdong]

> -Original Message-
> From: alsa-devel-boun...@alsa-project.org [mailto:alsa-devel-bounces@alsa-
> project.org] On Behalf Of Guenter Roeck
> Sent: Friday, May 25, 2018 3:49 AM

> From: Guenter Roeck 
> 
> Topology manifest v4 is still part of the ABI. Move its data structures into 
> the
> uapi header file.
> 
> No functional change.

It looks good. The v4 version of topology ABI should be in uapi header file.

Previously, we hid the v4 ABI in kernel and hoped people stop using it. But the 
topology files of old ABI were already shipped out and backward compatibility 
issue has been there. Thanks for fixing this.

Thanks
Mengdong

> 
> Signed-off-by: Guenter Roeck 
> ---
> v2: Added patch to series
> 
>  include/uapi/sound/asoc.h | 57
> +++
>  sound/soc/soc-topology.c  | 56 --
>  2 files changed, 57 insertions(+), 56 deletions(-)
> 
> diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h index
> 69c37ecbff7e..a9df4900789c 100644
> --- a/include/uapi/sound/asoc.h
> +++ b/include/uapi/sound/asoc.h
> @@ -552,4 +552,61 @@ struct snd_soc_tplg_dai {
>   __le32 flags;   /* SND_SOC_TPLG_DAI_FLGBIT_* */
>   struct snd_soc_tplg_private priv;
>  } __attribute__((packed));
> +
> +/*
> + * Old version of ABI structs, supported for backward compatibility.
> + */
> +
> +/* Manifest v4 */
> +struct snd_soc_tplg_manifest_v4 {
> + __le32 size;/* in bytes of this structure */
> + __le32 control_elems;   /* number of control elements */
> + __le32 widget_elems;/* number of widget elements */
> + __le32 graph_elems; /* number of graph elements */
> + __le32 pcm_elems;   /* number of PCM elements */
> + __le32 dai_link_elems;  /* number of DAI link elements */
> + struct snd_soc_tplg_private priv;
> +} __packed;
> +
> +/* Stream Capabilities v4 */
> +struct snd_soc_tplg_stream_caps_v4 {
> + __le32 size;/* in bytes of this structure */
> + char name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> + __le64 formats; /* supported formats SNDRV_PCM_FMTBIT_* */
> + __le32 rates;   /* supported rates SNDRV_PCM_RATE_* */
> + __le32 rate_min;/* min rate */
> + __le32 rate_max;/* max rate */
> + __le32 channels_min;/* min channels */
> + __le32 channels_max;/* max channels */
> + __le32 periods_min; /* min number of periods */
> + __le32 periods_max; /* max number of periods */
> + __le32 period_size_min; /* min period size bytes */
> + __le32 period_size_max; /* max period size bytes */
> + __le32 buffer_size_min; /* min buffer size bytes */
> + __le32 buffer_size_max; /* max buffer size bytes */
> +} __packed;
> +
> +/* PCM v4 */
> +struct snd_soc_tplg_pcm_v4 {
> + __le32 size;/* in bytes of this structure */
> + char pcm_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> + char dai_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> + __le32 pcm_id;  /* unique ID - used to match with DAI link */
> + __le32 dai_id;  /* unique ID - used to match */
> + __le32 playback;/* supports playback mode */
> + __le32 capture; /* supports capture mode */
> + __le32 compress;/* 1 = compressed; 0 = PCM */
> + struct snd_soc_tplg_stream
> stream[SND_SOC_TPLG_STREAM_CONFIG_MAX]; /* for DAI link */
> + __le32 num_streams; /* number of streams */
> + struct snd_soc_tplg_stream_caps_v4 caps[2]; /* playback and capture
> +for DAI */ } __packed;
> +
> +/* Physical link config v4 */
> +struct snd_soc_tplg_link_config_v4 {
> + __le32 size;/* in bytes of this structure */
> + __le32 id;  /* unique ID - used to match */
> + struct snd_soc_tplg_stream
> stream[SND_SOC_TPLG_STREAM_CONFIG_MAX]; /* supported configs playback
> and captrure */
> + __le32 num_streams; /* number of streams */
> +} __packed;
> +
>  #endif
> diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index
> d66b2e5ccd67..40753c6a2554 100644
> --- a/sound/soc/soc-topology.c
> +++ b/sound/soc/soc-topology.c
> @@ -54,62 +54,6 @@
>  #define SOC_TPLG_PASS_START  SOC_TPLG_PASS_MANIFEST
>  #define SOC_TPLG_PASS_ENDSOC_TPLG_PASS_LINK
> 
> -/*
> - * Old version of ABI structs, supported for backward compatibility.
> - */
> -
> -/* Manifest v4 */
> -struct snd_soc_tplg_manifest_v4 {
> - __le32 size;/* in bytes of this structure */
> - __le32 control_elems;   /* number of control elements */
> - __le32 widget_elems;/* number of widget elements */
> - __le32 graph_elems; /* number of graph elements */
> - __le32 pcm_elems;   /* number of PCM elements */
> - __le32 dai_link_elems;  /* number of DAI link elements */
> - struct snd_soc_tplg_private priv;
> -} __packed;
> -
> -/* Stream Capabilities v4 */
> -struct snd_soc_tplg_stream_caps_v4 {
> - __le32 size;

RE: [alsa-devel] [PATCH v2 2/3] ASoC: topology: Move v4 manifest header data structures to uapi

[Lin, Mengdong]

> -Original Message-
> From: alsa-devel-boun...@alsa-project.org [mailto:alsa-devel-bounces@alsa-
> project.org] On Behalf Of Guenter Roeck
> Sent: Friday, May 25, 2018 3:49 AM

> From: Guenter Roeck 
> 
> Topology manifest v4 is still part of the ABI. Move its data structures into 
> the
> uapi header file.
> 
> No functional change.

It looks good. The v4 version of topology ABI should be in uapi header file.

Previously, we hid the v4 ABI in kernel and hoped people stop using it. But the 
topology files of old ABI were already shipped out and backward compatibility 
issue has been there. Thanks for fixing this.

Thanks
Mengdong

> 
> Signed-off-by: Guenter Roeck 
> ---
> v2: Added patch to series
> 
>  include/uapi/sound/asoc.h | 57
> +++
>  sound/soc/soc-topology.c  | 56 --
>  2 files changed, 57 insertions(+), 56 deletions(-)
> 
> diff --git a/include/uapi/sound/asoc.h b/include/uapi/sound/asoc.h index
> 69c37ecbff7e..a9df4900789c 100644
> --- a/include/uapi/sound/asoc.h
> +++ b/include/uapi/sound/asoc.h
> @@ -552,4 +552,61 @@ struct snd_soc_tplg_dai {
>   __le32 flags;   /* SND_SOC_TPLG_DAI_FLGBIT_* */
>   struct snd_soc_tplg_private priv;
>  } __attribute__((packed));
> +
> +/*
> + * Old version of ABI structs, supported for backward compatibility.
> + */
> +
> +/* Manifest v4 */
> +struct snd_soc_tplg_manifest_v4 {
> + __le32 size;/* in bytes of this structure */
> + __le32 control_elems;   /* number of control elements */
> + __le32 widget_elems;/* number of widget elements */
> + __le32 graph_elems; /* number of graph elements */
> + __le32 pcm_elems;   /* number of PCM elements */
> + __le32 dai_link_elems;  /* number of DAI link elements */
> + struct snd_soc_tplg_private priv;
> +} __packed;
> +
> +/* Stream Capabilities v4 */
> +struct snd_soc_tplg_stream_caps_v4 {
> + __le32 size;/* in bytes of this structure */
> + char name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> + __le64 formats; /* supported formats SNDRV_PCM_FMTBIT_* */
> + __le32 rates;   /* supported rates SNDRV_PCM_RATE_* */
> + __le32 rate_min;/* min rate */
> + __le32 rate_max;/* max rate */
> + __le32 channels_min;/* min channels */
> + __le32 channels_max;/* max channels */
> + __le32 periods_min; /* min number of periods */
> + __le32 periods_max; /* max number of periods */
> + __le32 period_size_min; /* min period size bytes */
> + __le32 period_size_max; /* max period size bytes */
> + __le32 buffer_size_min; /* min buffer size bytes */
> + __le32 buffer_size_max; /* max buffer size bytes */
> +} __packed;
> +
> +/* PCM v4 */
> +struct snd_soc_tplg_pcm_v4 {
> + __le32 size;/* in bytes of this structure */
> + char pcm_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> + char dai_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> + __le32 pcm_id;  /* unique ID - used to match with DAI link */
> + __le32 dai_id;  /* unique ID - used to match */
> + __le32 playback;/* supports playback mode */
> + __le32 capture; /* supports capture mode */
> + __le32 compress;/* 1 = compressed; 0 = PCM */
> + struct snd_soc_tplg_stream
> stream[SND_SOC_TPLG_STREAM_CONFIG_MAX]; /* for DAI link */
> + __le32 num_streams; /* number of streams */
> + struct snd_soc_tplg_stream_caps_v4 caps[2]; /* playback and capture
> +for DAI */ } __packed;
> +
> +/* Physical link config v4 */
> +struct snd_soc_tplg_link_config_v4 {
> + __le32 size;/* in bytes of this structure */
> + __le32 id;  /* unique ID - used to match */
> + struct snd_soc_tplg_stream
> stream[SND_SOC_TPLG_STREAM_CONFIG_MAX]; /* supported configs playback
> and captrure */
> + __le32 num_streams; /* number of streams */
> +} __packed;
> +
>  #endif
> diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c index
> d66b2e5ccd67..40753c6a2554 100644
> --- a/sound/soc/soc-topology.c
> +++ b/sound/soc/soc-topology.c
> @@ -54,62 +54,6 @@
>  #define SOC_TPLG_PASS_START  SOC_TPLG_PASS_MANIFEST
>  #define SOC_TPLG_PASS_ENDSOC_TPLG_PASS_LINK
> 
> -/*
> - * Old version of ABI structs, supported for backward compatibility.
> - */
> -
> -/* Manifest v4 */
> -struct snd_soc_tplg_manifest_v4 {
> - __le32 size;/* in bytes of this structure */
> - __le32 control_elems;   /* number of control elements */
> - __le32 widget_elems;/* number of widget elements */
> - __le32 graph_elems; /* number of graph elements */
> - __le32 pcm_elems;   /* number of PCM elements */
> - __le32 dai_link_elems;  /* number of DAI link elements */
> - struct snd_soc_tplg_private priv;
> -} __packed;
> -
> -/* Stream Capabilities v4 */
> -struct snd_soc_tplg_stream_caps_v4 {
> - __le32 size;

RE: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

[Lin, Mengdong]

> -Original Message-
> From: alsa-devel-boun...@alsa-project.org [mailto:alsa-devel-bounces@alsa-
> project.org] On Behalf Of Mark Brown
> Sent: Thursday, May 24, 2018 11:12 PM
 
> On Thu, May 24, 2018 at 07:55:06AM -0700, Guenter Roeck wrote:
> > On Thu, May 24, 2018 at 7:18 AM Mark Brown  wrote:
> 
> Your mail client formatting seems to be broken, the word wrapping is really
> funky (it looks like it's breaking longer than 80 column lines in the middle 
> of
> paragraphs rather than flowing paragraphs within 80 columns).
> 
> > > > I don't mind adding the structures to
> > > > sound/soc/intel/skylake/skl-tplg-interface.h,
> > > > but it seems a bit out of scope to tie this with moving the file
> > > > to include/uapi/sound.
> > > > I think that should be a separate discussion.
> 
> > > Is there some reason not to just do it while we're looking at this?
> > > I don't see why we wouldn't want to do this.
> 
> > I don't mind doing this. However, keeping the change local and in a
> > single patch would make it easier to backport, and I think that the
> > ability to backport would be essential to get more than one-person
> > test coverage. I also would have liked feedback from someone at Intel,
> > at least for the Skylake specific structures.
> 
> Oh, of course - I'm just saying we should do this, not that everything needs 
> to be
> in one patch.  Obviously the code motion would be a separate patch.
> 
> > Anyway, what file do you have in mind for the structure definitions,
> > both for the ones in soc-tolopogy.c and the ones needed in
> > skl-topology.c ? Everything into asoc.h, or something else ?
> 
> All of those that can appear in a firmware file, I don't super care where 
> they end
> up but possibly a separate header file or files to the kernel specific ones 
> as they
> might get used with Windows.

Please put the Skylake specific structures in a separate header file, not in 
asoc.h. 

The file asoc.h is for generic topology structures which are platform 
independent. The topology code in alsa-lib never parses the platform specific 
structures.

The Skylake specific structures are needed by vendor applications like Intel 
topology tool (ITT) to define topology for different platforms. The 
applications can include both asoc.h, skl-tplg-interface.h and other device 
specific headers.

Thanks
Mengdong

RE: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

[Lin, Mengdong]

> -Original Message-
> From: alsa-devel-boun...@alsa-project.org [mailto:alsa-devel-bounces@alsa-
> project.org] On Behalf Of Mark Brown
> Sent: Thursday, May 24, 2018 11:12 PM
 
> On Thu, May 24, 2018 at 07:55:06AM -0700, Guenter Roeck wrote:
> > On Thu, May 24, 2018 at 7:18 AM Mark Brown  wrote:
> 
> Your mail client formatting seems to be broken, the word wrapping is really
> funky (it looks like it's breaking longer than 80 column lines in the middle 
> of
> paragraphs rather than flowing paragraphs within 80 columns).
> 
> > > > I don't mind adding the structures to
> > > > sound/soc/intel/skylake/skl-tplg-interface.h,
> > > > but it seems a bit out of scope to tie this with moving the file
> > > > to include/uapi/sound.
> > > > I think that should be a separate discussion.
> 
> > > Is there some reason not to just do it while we're looking at this?
> > > I don't see why we wouldn't want to do this.
> 
> > I don't mind doing this. However, keeping the change local and in a
> > single patch would make it easier to backport, and I think that the
> > ability to backport would be essential to get more than one-person
> > test coverage. I also would have liked feedback from someone at Intel,
> > at least for the Skylake specific structures.
> 
> Oh, of course - I'm just saying we should do this, not that everything needs 
> to be
> in one patch.  Obviously the code motion would be a separate patch.
> 
> > Anyway, what file do you have in mind for the structure definitions,
> > both for the ones in soc-tolopogy.c and the ones needed in
> > skl-topology.c ? Everything into asoc.h, or something else ?
> 
> All of those that can appear in a firmware file, I don't super care where 
> they end
> up but possibly a separate header file or files to the kernel specific ones 
> as they
> might get used with Windows.

Please put the Skylake specific structures in a separate header file, not in 
asoc.h. 

The file asoc.h is for generic topology structures which are platform 
independent. The topology code in alsa-lib never parses the platform specific 
structures.

The Skylake specific structures are needed by vendor applications like Intel 
topology tool (ITT) to define topology for different platforms. The 
applications can include both asoc.h, skl-tplg-interface.h and other device 
specific headers.

Thanks
Mengdong

RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()

[Lin, Mengdong]

+ Jim and Jani from gfx team.

Thanks
Mengdong

> -Original Message-
> From: Lin, Mengdong
> Sent: Wednesday, March 16, 2016 12:11 AM
> To: Takashi Iwai
> Cc: Yang, Libin; kernel test robot; l...@01.org; LKML; Wu, Fengguang
> Subject: RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> 
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Tuesday, March 15, 2016 1:12 AM
> >
> > On Mon, 14 Mar 2016 16:30:22 +0100,
> > Lin, Mengdong wrote:
> > >
> > > > -Original Message-
> > > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > > Sent: Monday, March 14, 2016 9:03 PM
> > > > To: Yang, Libin
> > > > Cc: kernel test robot; l...@01.org; LKML; Wu, Fengguang; Lin,
> > > > Mengdong
> > > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > >
> > > > On Mon, 14 Mar 2016 13:02:39 +0100, Yang, Libin wrote:
> > > > >
> > > > > Hi Takashi,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > > > > Sent: Monday, March 14, 2016 3:23 PM
> > > > > > To: kernel test robot
> > > > > > Cc: l...@01.org; LKML; Wu, Fengguang; Yang, Libin; Lin,
> > > > > > Mengdong
> > > > > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151
> > > > > > at
> > > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > > >
> > > > > > On Mon, 14 Mar 2016 01:50:45 +0100, kernel test robot wrote:
> > > > > > >
> > > > > > > FYI, we noticed the below changes on
> > > > > > >
> > > > > > > https://github.com/0day-ci/linux
> > > > > > > Takashi-Iwai/ALSA-hda-Add-a-sanity-
> > > > > > check-of-pin-port-mapping-on-i915-HDMI-DP/20160310-225740
> > > > > > > commit ca53fbf3a609b6831222078af9ddbecbf76fddce ("ALSA:
> hda
> > -
> > > > > > Add a sanity check of pin / port mapping on i915 HDMI/DP")
> > > > > > >
> > > > > > >
> > > > > > > [   14.546058] snd_hda_intel :00:1b.0: bound
> :00:02.0
> > > > (ops
> > > > > > i915_audio_component_bind_ops [i915])
> > > > > > > [   14.549740] fbcon: inteldrmfb (fb0) is primary device
> > > > > > > [   14.553691] [ cut here ]
> > > > > > > [   14.553707] WARNING: CPU: 0 PID: 151 at
> > > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > > >
> > > > > > Does your tree contain the commit
> > > > > >   2f791908a70e95768596f5bb9e6de4f441d7bf13
> > > > > >   drm/i915: Fix bogus dig_port_map[] assignment for
> > pre-HSW ?
> > > > > >
> > > > > > The commit above should cover it even for HSW.
> > > > > >
> > > > > > If it's already included, then it's really a bug, and the
> > > > > > warning is exactly for catching such a bug.  The HD-audio
> > > > > > driver expects that the valid audio ports are only from port B
> > > > > > to port D while i915 driver assigns a different one.  I
> > > > > > suspect that the current assumption is too naive and broken
> > > > > > for SKL and later in this
> > regard.
> > > > > >
> > > > > > Libin, Mengdong, could you check whether the audio port
> > > > > > mapping rule is still valid?  At least, a wrong port-A mapping
> > > > > > could be reproduced even on a HSW laptop with DP-MST dock
> when
> > > > > > I boot
> > > > without
> > > > > > eDP (e.g. video=eDP-1:d option).
> > > > >
> > > > > We checked with HW before, and the mapping should be right.
> > > > > What's the problem now? I will check with our HW and gfx team.
> > > >
> > > > One problem I've heard is that port-A is reported from i915 ELD 
> > > > notifier.
> > > > This happens when you disable eDP and use DP-MST on a HSW
> machine.
> >

RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()

[Lin, Mengdong]

+ Jim and Jani from gfx team.

Thanks
Mengdong

> -Original Message-
> From: Lin, Mengdong
> Sent: Wednesday, March 16, 2016 12:11 AM
> To: Takashi Iwai
> Cc: Yang, Libin; kernel test robot; l...@01.org; LKML; Wu, Fengguang
> Subject: RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> 
> > -Original Message-
> > From: Takashi Iwai [mailto:ti...@suse.de]
> > Sent: Tuesday, March 15, 2016 1:12 AM
> >
> > On Mon, 14 Mar 2016 16:30:22 +0100,
> > Lin, Mengdong wrote:
> > >
> > > > -Original Message-
> > > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > > Sent: Monday, March 14, 2016 9:03 PM
> > > > To: Yang, Libin
> > > > Cc: kernel test robot; l...@01.org; LKML; Wu, Fengguang; Lin,
> > > > Mengdong
> > > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > >
> > > > On Mon, 14 Mar 2016 13:02:39 +0100, Yang, Libin wrote:
> > > > >
> > > > > Hi Takashi,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > > > > Sent: Monday, March 14, 2016 3:23 PM
> > > > > > To: kernel test robot
> > > > > > Cc: l...@01.org; LKML; Wu, Fengguang; Yang, Libin; Lin,
> > > > > > Mengdong
> > > > > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151
> > > > > > at
> > > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > > >
> > > > > > On Mon, 14 Mar 2016 01:50:45 +0100, kernel test robot wrote:
> > > > > > >
> > > > > > > FYI, we noticed the below changes on
> > > > > > >
> > > > > > > https://github.com/0day-ci/linux
> > > > > > > Takashi-Iwai/ALSA-hda-Add-a-sanity-
> > > > > > check-of-pin-port-mapping-on-i915-HDMI-DP/20160310-225740
> > > > > > > commit ca53fbf3a609b6831222078af9ddbecbf76fddce ("ALSA:
> hda
> > -
> > > > > > Add a sanity check of pin / port mapping on i915 HDMI/DP")
> > > > > > >
> > > > > > >
> > > > > > > [   14.546058] snd_hda_intel :00:1b.0: bound
> :00:02.0
> > > > (ops
> > > > > > i915_audio_component_bind_ops [i915])
> > > > > > > [   14.549740] fbcon: inteldrmfb (fb0) is primary device
> > > > > > > [   14.553691] [ cut here ]
> > > > > > > [   14.553707] WARNING: CPU: 0 PID: 151 at
> > > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > > >
> > > > > > Does your tree contain the commit
> > > > > >   2f791908a70e95768596f5bb9e6de4f441d7bf13
> > > > > >   drm/i915: Fix bogus dig_port_map[] assignment for
> > pre-HSW ?
> > > > > >
> > > > > > The commit above should cover it even for HSW.
> > > > > >
> > > > > > If it's already included, then it's really a bug, and the
> > > > > > warning is exactly for catching such a bug.  The HD-audio
> > > > > > driver expects that the valid audio ports are only from port B
> > > > > > to port D while i915 driver assigns a different one.  I
> > > > > > suspect that the current assumption is too naive and broken
> > > > > > for SKL and later in this
> > regard.
> > > > > >
> > > > > > Libin, Mengdong, could you check whether the audio port
> > > > > > mapping rule is still valid?  At least, a wrong port-A mapping
> > > > > > could be reproduced even on a HSW laptop with DP-MST dock
> when
> > > > > > I boot
> > > > without
> > > > > > eDP (e.g. video=eDP-1:d option).
> > > > >
> > > > > We checked with HW before, and the mapping should be right.
> > > > > What's the problem now? I will check with our HW and gfx team.
> > > >
> > > > One problem I've heard is that port-A is reported from i915 ELD 
> > > > notifier.
> > > > This happens when you disable eDP and use DP-MST on a HSW
> machine.
> >

RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()

[Lin, Mengdong]

> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Tuesday, March 15, 2016 1:12 AM
> 
> On Mon, 14 Mar 2016 16:30:22 +0100,
> Lin, Mengdong wrote:
> >
> > > -Original Message-
> > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > Sent: Monday, March 14, 2016 9:03 PM
> > > To: Yang, Libin
> > > Cc: kernel test robot; l...@01.org; LKML; Wu, Fengguang; Lin,
> > > Mengdong
> > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > >
> > > On Mon, 14 Mar 2016 13:02:39 +0100,
> > > Yang, Libin wrote:
> > > >
> > > > Hi Takashi,
> > > >
> > > > > -Original Message-
> > > > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > > > Sent: Monday, March 14, 2016 3:23 PM
> > > > > To: kernel test robot
> > > > > Cc: l...@01.org; LKML; Wu, Fengguang; Yang, Libin; Lin, Mengdong
> > > > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151
> > > > > at
> > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > >
> > > > > On Mon, 14 Mar 2016 01:50:45 +0100, kernel test robot wrote:
> > > > > >
> > > > > > FYI, we noticed the below changes on
> > > > > >
> > > > > > https://github.com/0day-ci/linux
> > > > > > Takashi-Iwai/ALSA-hda-Add-a-sanity-
> > > > > check-of-pin-port-mapping-on-i915-HDMI-DP/20160310-225740
> > > > > > commit ca53fbf3a609b6831222078af9ddbecbf76fddce ("ALSA: hda
> -
> > > > > Add a sanity check of pin / port mapping on i915 HDMI/DP")
> > > > > >
> > > > > >
> > > > > > [   14.546058] snd_hda_intel :00:1b.0: bound :00:02.0
> > > (ops
> > > > > i915_audio_component_bind_ops [i915])
> > > > > > [   14.549740] fbcon: inteldrmfb (fb0) is primary device
> > > > > > [   14.553691] [ cut here ]
> > > > > > [   14.553707] WARNING: CPU: 0 PID: 151 at
> > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > >
> > > > > Does your tree contain the commit
> > > > >   2f791908a70e95768596f5bb9e6de4f441d7bf13
> > > > >   drm/i915: Fix bogus dig_port_map[] assignment for
> pre-HSW ?
> > > > >
> > > > > The commit above should cover it even for HSW.
> > > > >
> > > > > If it's already included, then it's really a bug, and the
> > > > > warning is exactly for catching such a bug.  The HD-audio driver
> > > > > expects that the valid audio ports are only from port B to port
> > > > > D while i915 driver assigns a different one.  I suspect that the
> > > > > current assumption is too naive and broken for SKL and later in this
> regard.
> > > > >
> > > > > Libin, Mengdong, could you check whether the audio port mapping
> > > > > rule is still valid?  At least, a wrong port-A mapping could be
> > > > > reproduced even on a HSW laptop with DP-MST dock when I boot
> > > without
> > > > > eDP (e.g. video=eDP-1:d option).
> > > >
> > > > We checked with HW before, and the mapping should be right.
> > > > What's the problem now? I will check with our HW and gfx team.
> > >
> > > One problem I've heard is that port-A is reported from i915 ELD notifier.
> > > This happens when you disable eDP and use DP-MST on a HSW machine.
> > > Then port A DDI is also used for the DP-MST, and when it's plugged,
> > > it passes
> > > port=0 to the notifier.
> >
> > Hi Takashi,
> >
> > Could you or someone provide the output of intel_audio_dump when the
> error happens?
> > This can help us to check the pipe:port connections in GPU from the
> display register values.
> >
> > For Haswell and later platforms, port A (DDI A) is only used for eDP, not 
> > for
> DP or HDMI. So I feel the DP-MST dock should not bridge port A to external
> monitors and so port A should not be reported by the ELD notifier.
> > Maybe the port mapping has bug since i915 support for DP MST is still
> ongoing.
> 
> Below are four outputs with 4.5-final kernel:

Hi Takashi,

Thanks for your info!
I think the laptop built-in DP p

RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()

[Lin, Mengdong]

> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Tuesday, March 15, 2016 1:12 AM
> 
> On Mon, 14 Mar 2016 16:30:22 +0100,
> Lin, Mengdong wrote:
> >
> > > -Original Message-
> > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > Sent: Monday, March 14, 2016 9:03 PM
> > > To: Yang, Libin
> > > Cc: kernel test robot; l...@01.org; LKML; Wu, Fengguang; Lin,
> > > Mengdong
> > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > >
> > > On Mon, 14 Mar 2016 13:02:39 +0100,
> > > Yang, Libin wrote:
> > > >
> > > > Hi Takashi,
> > > >
> > > > > -Original Message-
> > > > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > > > Sent: Monday, March 14, 2016 3:23 PM
> > > > > To: kernel test robot
> > > > > Cc: l...@01.org; LKML; Wu, Fengguang; Yang, Libin; Lin, Mengdong
> > > > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151
> > > > > at
> > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > >
> > > > > On Mon, 14 Mar 2016 01:50:45 +0100, kernel test robot wrote:
> > > > > >
> > > > > > FYI, we noticed the below changes on
> > > > > >
> > > > > > https://github.com/0day-ci/linux
> > > > > > Takashi-Iwai/ALSA-hda-Add-a-sanity-
> > > > > check-of-pin-port-mapping-on-i915-HDMI-DP/20160310-225740
> > > > > > commit ca53fbf3a609b6831222078af9ddbecbf76fddce ("ALSA: hda
> -
> > > > > Add a sanity check of pin / port mapping on i915 HDMI/DP")
> > > > > >
> > > > > >
> > > > > > [   14.546058] snd_hda_intel :00:1b.0: bound :00:02.0
> > > (ops
> > > > > i915_audio_component_bind_ops [i915])
> > > > > > [   14.549740] fbcon: inteldrmfb (fb0) is primary device
> > > > > > [   14.553691] [ cut here ]
> > > > > > [   14.553707] WARNING: CPU: 0 PID: 151 at
> > > > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > > > >
> > > > > Does your tree contain the commit
> > > > >   2f791908a70e95768596f5bb9e6de4f441d7bf13
> > > > >   drm/i915: Fix bogus dig_port_map[] assignment for
> pre-HSW ?
> > > > >
> > > > > The commit above should cover it even for HSW.
> > > > >
> > > > > If it's already included, then it's really a bug, and the
> > > > > warning is exactly for catching such a bug.  The HD-audio driver
> > > > > expects that the valid audio ports are only from port B to port
> > > > > D while i915 driver assigns a different one.  I suspect that the
> > > > > current assumption is too naive and broken for SKL and later in this
> regard.
> > > > >
> > > > > Libin, Mengdong, could you check whether the audio port mapping
> > > > > rule is still valid?  At least, a wrong port-A mapping could be
> > > > > reproduced even on a HSW laptop with DP-MST dock when I boot
> > > without
> > > > > eDP (e.g. video=eDP-1:d option).
> > > >
> > > > We checked with HW before, and the mapping should be right.
> > > > What's the problem now? I will check with our HW and gfx team.
> > >
> > > One problem I've heard is that port-A is reported from i915 ELD notifier.
> > > This happens when you disable eDP and use DP-MST on a HSW machine.
> > > Then port A DDI is also used for the DP-MST, and when it's plugged,
> > > it passes
> > > port=0 to the notifier.
> >
> > Hi Takashi,
> >
> > Could you or someone provide the output of intel_audio_dump when the
> error happens?
> > This can help us to check the pipe:port connections in GPU from the
> display register values.
> >
> > For Haswell and later platforms, port A (DDI A) is only used for eDP, not 
> > for
> DP or HDMI. So I feel the DP-MST dock should not bridge port A to external
> monitors and so port A should not be reported by the ELD notifier.
> > Maybe the port mapping has bug since i915 support for DP MST is still
> ongoing.
> 
> Below are four outputs with 4.5-final kernel:

Hi Takashi,

Thanks for your info!
I think the laptop built-in DP p

RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()

[Lin, Mengdong]

> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Monday, March 14, 2016 9:03 PM
> To: Yang, Libin
> Cc: kernel test robot; l...@01.org; LKML; Wu, Fengguang; Lin, Mengdong
> Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> 
> On Mon, 14 Mar 2016 13:02:39 +0100,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -Original Message-
> > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > Sent: Monday, March 14, 2016 3:23 PM
> > > To: kernel test robot
> > > Cc: l...@01.org; LKML; Wu, Fengguang; Yang, Libin; Lin, Mengdong
> > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > >
> > > On Mon, 14 Mar 2016 01:50:45 +0100,
> > > kernel test robot wrote:
> > > >
> > > > FYI, we noticed the below changes on
> > > >
> > > > https://github.com/0day-ci/linux
> > > > Takashi-Iwai/ALSA-hda-Add-a-sanity-
> > > check-of-pin-port-mapping-on-i915-HDMI-DP/20160310-225740
> > > > commit ca53fbf3a609b6831222078af9ddbecbf76fddce ("ALSA: hda -
> > > Add a sanity check of pin / port mapping on i915 HDMI/DP")
> > > >
> > > >
> > > > [   14.546058] snd_hda_intel :00:1b.0: bound :00:02.0
> (ops
> > > i915_audio_component_bind_ops [i915])
> > > > [   14.549740] fbcon: inteldrmfb (fb0) is primary device
> > > > [   14.553691] [ cut here ]
> > > > [   14.553707] WARNING: CPU: 0 PID: 151 at
> > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > >
> > > Does your tree contain the commit
> > >   2f791908a70e95768596f5bb9e6de4f441d7bf13
> > >   drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW ?
> > >
> > > The commit above should cover it even for HSW.
> > >
> > > If it's already included, then it's really a bug, and the warning is
> > > exactly for catching such a bug.  The HD-audio driver expects that
> > > the valid audio ports are only from port B to port D while i915
> > > driver assigns a different one.  I suspect that the current
> > > assumption is too naive and broken for SKL and later in this regard.
> > >
> > > Libin, Mengdong, could you check whether the audio port mapping rule
> > > is still valid?  At least, a wrong port-A mapping could be
> > > reproduced even on a HSW laptop with DP-MST dock when I boot
> without
> > > eDP (e.g. video=eDP-1:d option).
> >
> > We checked with HW before, and the mapping should be right.
> > What's the problem now? I will check with our HW and gfx team.
> 
> One problem I've heard is that port-A is reported from i915 ELD notifier.
> This happens when you disable eDP and use DP-MST on a HSW machine.
> Then port A DDI is also used for the DP-MST, and when it's plugged, it passes
> port=0 to the notifier.

Hi Takashi,

Could you or someone provide the output of intel_audio_dump when the error 
happens?
This can help us to check the pipe:port connections in GPU from the display 
register values.

For Haswell and later platforms, port A (DDI A) is only used for eDP, not for 
DP or HDMI. So I feel the DP-MST dock should not bridge port A to external 
monitors and so port A should not be reported by the ELD notifier.
Maybe the port mapping has bug since i915 support for DP MST is still ongoing. 

Thanks
Mengdong

RE: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()

[Lin, Mengdong]

> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Monday, March 14, 2016 9:03 PM
> To: Yang, Libin
> Cc: kernel test robot; l...@01.org; LKML; Wu, Fengguang; Lin, Mengdong
> Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> 
> On Mon, 14 Mar 2016 13:02:39 +0100,
> Yang, Libin wrote:
> >
> > Hi Takashi,
> >
> > > -Original Message-
> > > From: Takashi Iwai [mailto:ti...@suse.de]
> > > Sent: Monday, March 14, 2016 3:23 PM
> > > To: kernel test robot
> > > Cc: l...@01.org; LKML; Wu, Fengguang; Yang, Libin; Lin, Mengdong
> > > Subject: Re: [lkp] [ALSA] ca53fbf3a6: WARNING: CPU: 0 PID: 151 at
> > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > >
> > > On Mon, 14 Mar 2016 01:50:45 +0100,
> > > kernel test robot wrote:
> > > >
> > > > FYI, we noticed the below changes on
> > > >
> > > > https://github.com/0day-ci/linux
> > > > Takashi-Iwai/ALSA-hda-Add-a-sanity-
> > > check-of-pin-port-mapping-on-i915-HDMI-DP/20160310-225740
> > > > commit ca53fbf3a609b6831222078af9ddbecbf76fddce ("ALSA: hda -
> > > Add a sanity check of pin / port mapping on i915 HDMI/DP")
> > > >
> > > >
> > > > [   14.546058] snd_hda_intel :00:1b.0: bound :00:02.0
> (ops
> > > i915_audio_component_bind_ops [i915])
> > > > [   14.549740] fbcon: inteldrmfb (fb0) is primary device
> > > > [   14.553691] [ cut here ]
> > > > [   14.553707] WARNING: CPU: 0 PID: 151 at
> > > sound/hda/hdac_i915.c:129 pin2port+0x2a/0x40 [snd_hda_core]()
> > >
> > > Does your tree contain the commit
> > >   2f791908a70e95768596f5bb9e6de4f441d7bf13
> > >   drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW ?
> > >
> > > The commit above should cover it even for HSW.
> > >
> > > If it's already included, then it's really a bug, and the warning is
> > > exactly for catching such a bug.  The HD-audio driver expects that
> > > the valid audio ports are only from port B to port D while i915
> > > driver assigns a different one.  I suspect that the current
> > > assumption is too naive and broken for SKL and later in this regard.
> > >
> > > Libin, Mengdong, could you check whether the audio port mapping rule
> > > is still valid?  At least, a wrong port-A mapping could be
> > > reproduced even on a HSW laptop with DP-MST dock when I boot
> without
> > > eDP (e.g. video=eDP-1:d option).
> >
> > We checked with HW before, and the mapping should be right.
> > What's the problem now? I will check with our HW and gfx team.
> 
> One problem I've heard is that port-A is reported from i915 ELD notifier.
> This happens when you disable eDP and use DP-MST on a HSW machine.
> Then port A DDI is also used for the DP-MST, and when it's plugged, it passes
> port=0 to the notifier.

Hi Takashi,

Could you or someone provide the output of intel_audio_dump when the error 
happens?
This can help us to check the pipe:port connections in GPU from the display 
register values.

For Haswell and later platforms, port A (DDI A) is only used for eDP, not for 
DP or HDMI. So I feel the DP-MST dock should not bridge port A to external 
monitors and so port A should not be reported by the ELD notifier.
Maybe the port mapping has bug since i915 support for DP MST is still ongoing. 

Thanks
Mengdong

RE: Problems loading firmware using built-in drivers with kernels that use initramfs.

[Lin, Mengdong]

> -Original Message-
> From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com]
> Sent: Wednesday, August 26, 2015 5:01 PM
> To: Jie, Yang
> Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez;
> joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg
> Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez;
> lkml; yalin wang; Lin, Mengdong
> Subject: Re: Problems loading firmware using built-in drivers with kernels 
> that
> use initramfs.
> 
> On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote:
> > > -Original Message-
> > > From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com]
> 
> > > I think the options are to either :-
> > >
> > > 1) Don not support audio DSP drivers using topology data as built-in
> drivers.
> > > Audio is not really a critical system required for booting anyway.
> > >
> > > 2) Create a default PCM for every driver that has topology data on
> > > the assumption that every sound card will at least 1 PCM. This PCM
> > > can then be re-configured when the FW is loaded.
> >
> > Yep, this case is quite similar with what Linus described.
> >
> > Is it possible that we can probe pcm device after firmware is loaded
> > for this case?
> >
> 
> The PCM devices are defined in the topology data so it is only possible to
> create the PCM device *after* the firmware is loaded in these drivers.
> 
> Liam

It seems this can prevent audio device driver in built-in mode to use topology 
drivers.

If topology is present, the vendor driver also uses request_firmware() to load 
the topology data file in the probe phase. Then ASoC core will create the sound 
card and its PCM devices. 

Shall we force the device drivers that depends on topology to be configured as 
modules?

Thanks
Mengdong 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: Problems loading firmware using built-in drivers with kernels that use initramfs.

[Lin, Mengdong]

 -Original Message-
 From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com]
 Sent: Wednesday, August 26, 2015 5:01 PM
 To: Jie, Yang
 Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez;
 joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg
 Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez;
 lkml; yalin wang; Lin, Mengdong
 Subject: Re: Problems loading firmware using built-in drivers with kernels 
 that
 use initramfs.
 
 On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote:
   -Original Message-
   From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com]
 
   I think the options are to either :-
  
   1) Don not support audio DSP drivers using topology data as built-in
 drivers.
   Audio is not really a critical system required for booting anyway.
  
   2) Create a default PCM for every driver that has topology data on
   the assumption that every sound card will at least 1 PCM. This PCM
   can then be re-configured when the FW is loaded.
 
  Yep, this case is quite similar with what Linus described.
 
  Is it possible that we can probe pcm device after firmware is loaded
  for this case?
 
 
 The PCM devices are defined in the topology data so it is only possible to
 create the PCM device *after* the firmware is loaded in these drivers.
 
 Liam

It seems this can prevent audio device driver in built-in mode to use topology 
drivers.

If topology is present, the vendor driver also uses request_firmware() to load 
the topology data file in the probe phase. Then ASoC core will create the sound 
card and its PCM devices. 

Shall we force the device drivers that depends on topology to be configured as 
modules?

Thanks
Mengdong 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

Who maintains firmware upstreaming to Linux now?

[Lin, Mengdong]

Hi,

Could someone clarify who maintains firmware upstreaming to Linux at the moment?

We need to upstream a firmware binary and its license. We've submitted the 
patch to linux-firmw...@kernel.org but got no reply for 5 weeks.
I'm not sure if Ben has been on vacation, or someone else can help to review 
and apply our firmware patch.

Thanks
Mengdong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Who maintains firmware upstreaming to Linux now?

[Lin, Mengdong]

Hi,

Could someone clarify who maintains firmware upstreaming to Linux at the moment?

We need to upstream a firmware binary and its license. We've submitted the 
patch to linux-firmw...@kernel.org but got no reply for 5 weeks.
I'm not sure if Ben has been on vacation, or someone else can help to review 
and apply our firmware patch.

Thanks
Mengdong
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

[Lin, Mengdong]

> -Original Message-
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Wednesday, December 12, 2012 6:52 PM


> > It looks like azx_runtime_suspend() is new in 3.7 and it returns
> > -EAGAIN to indicate that it actually can't be suspended (if my
> > understanding the code is correct).  However, it shouldn't do that,
> > because that causes the runtime PM core to repeat the attempts.  It
> > rather should implement a .runtime_idle() callback returning an error code
> instead.


Hi Boris and Rafael,

I remember I didn't observed repetitive attempts to suspend if the 
azx_runtime_suspend() returns -EAGAIN.

Because the HD-A driver does not implement the runtime idle callback, 
pci_pm_runtime_idle() will call pm_runtime_suspend(dev),
and then __pm_runtime_suspend(dev, 0) will be called. 
Finally the code will go to 'fail' of rpm_suspend: 
...
fail:
__update_runtime_status(dev, RPM_ACTIVE);
dev->power.deferred_resume = false;
wake_up_all(>power.wait_queue);

if (retval == -EAGAIN || retval == -EBUSY) {
dev->power.runtime_error = 0;
...
if ((rpmflags & RPM_AUTO) &&
pm_runtime_autosuspend_expiration(dev) != 0)  ... but 
since the rpmflags is 0, the code will not go to 'repeat' but to 'out'.
goto repeat;
} else {
pm_runtime_cancel_pending(dev);
}
goto out;

Please correct me if I misunderstand something.

Thanks
Mengdong

RE: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11

[Lin, Mengdong]

 -Original Message-
 From: Borislav Petkov [mailto:b...@alien8.de]
 Sent: Wednesday, December 12, 2012 6:52 PM


  It looks like azx_runtime_suspend() is new in 3.7 and it returns
  -EAGAIN to indicate that it actually can't be suspended (if my
  understanding the code is correct).  However, it shouldn't do that,
  because that causes the runtime PM core to repeat the attempts.  It
  rather should implement a .runtime_idle() callback returning an error code
 instead.


Hi Boris and Rafael,

I remember I didn't observed repetitive attempts to suspend if the 
azx_runtime_suspend() returns -EAGAIN.

Because the HD-A driver does not implement the runtime idle callback, 
pci_pm_runtime_idle() will call pm_runtime_suspend(dev),
and then __pm_runtime_suspend(dev, 0) will be called. 
Finally the code will go to 'fail' of rpm_suspend: 
...
fail:
__update_runtime_status(dev, RPM_ACTIVE);
dev-power.deferred_resume = false;
wake_up_all(dev-power.wait_queue);

if (retval == -EAGAIN || retval == -EBUSY) {
dev-power.runtime_error = 0;
...
if ((rpmflags  RPM_AUTO) 
pm_runtime_autosuspend_expiration(dev) != 0)  ... but 
since the rpmflags is 0, the code will not go to 'repeat' but to 'out'.
goto repeat;
} else {
pm_runtime_cancel_pending(dev);
}
goto out;

Please correct me if I misunderstand something.

Thanks
Mengdong