Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Thu, Jun 28, 2018 at 2:22 AM, Jim Qu <Jim.Qu@amd.com> wrote:
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
>
> In currect HDA audio driver, it will set all codec as
> VGA_SWITCHEROO_DIS, so if system runtime pm is enabled,
> the audio which is binded to UMA will be suspended.
>
> In HDA driver side, it is difficult to know which GPU
> the audio has binded to. So set the bound gpu pci dev
> to vgaswitchroo, let vgaswitchroo make decision.
>
> Newer dGPUs use PCI_CLASS_DISPLAY_OTHER rather than
> PCI_CLASS_DISPLAY_VGA.  Make sure we check for both when
> checking for the dGPU in get_bound_vga()
>
> The patch also combine the HDA change to avoid break
> building.
>
> Change-Id: I9906c1bd4dd5b36108d7133bb1cf724d13f1cd6d
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Jim Qu <Jim.Qu@amd.com>
> ---
>  drivers/gpu/vga/vga_switcheroo.c | 11 +++++++++--
>  include/linux/vga_switcheroo.h   |  4 ++--
>  sound/pci/hda/hda_intel.c        | 15 +++++++++------
>  3 files changed, 20 insertions(+), 10 deletions(-)
>

Please resend and send it to dri-devel and alsa-devel@alsa-project.org
since this patch touches multiple subsystems.  I would propose we
merge this through the drm tree if possible.

Alex

> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
> index fc4adf3..7b7b0fd 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -329,7 +329,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   * vga_switcheroo_register_audio_client - register audio client
>   * @pdev: client pci device
>   * @ops: client callbacks
> - * @id: client identifier
> + * @bound_vga: client bound vga pci device
>   *
>   * Register audio client (audio device on a GPU). The client is assumed
>   * to use runtime PM. Beforehand, vga_switcheroo_client_probe_defer()
> @@ -339,8 +339,15 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   */
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>                         const struct vga_switcheroo_client_ops *ops,
> -                       enum vga_switcheroo_client_id id)
> +                       struct pci_dev *bound_vga)
>  {
> +       enum vga_switcheroo_client_id id = VGA_SWITCHEROO_DIS;
> +
> +       if (bound_vga) {
> +               if (vgasr_priv.handler->get_client_id)
> +                       id = vgasr_priv.handler->get_client_id(bound_vga);
> +       }
> +
>         return register_client(pdev, ops, id | ID_BIT_AUDIO, false, true);
>  }
>  EXPORT_SYMBOL(vga_switcheroo_register_audio_client);
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index 77f0f0a..a0c7b86 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -151,7 +151,7 @@ int vga_switcheroo_register_client(struct pci_dev *dev,
>                                    bool driver_power_control);
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>                                          const struct vga_switcheroo_client_ops *ops,
> -                                        enum vga_switcheroo_client_id id);
> +                                        struct pci_dev *bound_vga);
>
>  void vga_switcheroo_client_fb_set(struct pci_dev *dev,
>                                   struct fb_info *info);
> @@ -180,7 +180,7 @@ static inline int vga_switcheroo_register_handler(const struct vga_switcheroo_ha
>                 enum vga_switcheroo_handler_flags_t handler_flags) { return 0; }
>  static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>         const struct vga_switcheroo_client_ops *ops,
> -       enum vga_switcheroo_client_id id) { return 0; }
> +       struct pci_dev *bound_vga) { return 0; }
>  static inline void vga_switcheroo_unregister_handler(void) {}
>  static inline enum vga_switcheroo_handler_flags_t vga_switcheroo_handler_flags(void) { return 0; }
>  static inline int vga_switcheroo_lock_ddc(struct pci_dev *pdev) { return -ENODEV; }
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 1ae1850..8f992e6 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1319,15 +1319,17 @@ static const struct vga_switcheroo_client_ops azx_vs_ops = {
>  static int register_vga_switcheroo(struct azx *chip)
>  {
>         struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> +       struct pci_dev *p;
>         int err;
>
>         if (!hda->use_vga_switcheroo)
>                 return 0;
> -       /* FIXME: currently only handling DIS controller
> -        * is there any machine with two switchable HDMI audio controllers?
> -        */
> -       err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops,
> -                                                  VGA_SWITCHEROO_DIS);
> +
> +       p = get_bound_vga(chip->pci);
> +       err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, p);
> +
> +       if (p)
> +               pci_dev_put(p);
>         if (err < 0)
>                 return err;
>         hda->vga_switcheroo_registered = 1;
> @@ -1429,7 +1431,8 @@ static struct pci_dev *get_bound_vga(struct pci_dev *pci)
>                         p = pci_get_domain_bus_and_slot(pci_domain_nr(pci->bus),
>                                                         pci->bus->number, 0);
>                         if (p) {
> -                               if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA)
> +                               if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA ||
> +                               (p->class >> 8) == PCI_CLASS_DISPLAY_OTHER)
>                                         return p;
>                                 pci_dev_put(p);
>                         }
> --
> 2.7.4
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

HI,

Any comments for the patch?

Thanks
JimQu

________________________________________
发件人: Alex Deucher <alexdeucher@gmail.com>
发送时间: 2018年6月28日 20:43
收件人: Qu, Jim; alsa-devel@alsa-project.org; Maling list - DRI developers
抄送: amd-gfx list; Deucher, Alexander
主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Thu, Jun 28, 2018 at 2:22 AM, Jim Qu <Jim.Qu@amd.com> wrote:
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
>
> In currect HDA audio driver, it will set all codec as
> VGA_SWITCHEROO_DIS, so if system runtime pm is enabled,
> the audio which is binded to UMA will be suspended.
>
> In HDA driver side, it is difficult to know which GPU
> the audio has binded to. So set the bound gpu pci dev
> to vgaswitchroo, let vgaswitchroo make decision.
>
> Newer dGPUs use PCI_CLASS_DISPLAY_OTHER rather than
> PCI_CLASS_DISPLAY_VGA.  Make sure we check for both when
> checking for the dGPU in get_bound_vga()
>
> The patch also combine the HDA change to avoid break
> building.
>
> Change-Id: I9906c1bd4dd5b36108d7133bb1cf724d13f1cd6d
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Jim Qu <Jim.Qu@amd.com>
> ---
>  drivers/gpu/vga/vga_switcheroo.c | 11 +++++++++--
>  include/linux/vga_switcheroo.h   |  4 ++--
>  sound/pci/hda/hda_intel.c        | 15 +++++++++------
>  3 files changed, 20 insertions(+), 10 deletions(-)
>

Please resend and send it to dri-devel and alsa-devel@alsa-project.org
since this patch touches multiple subsystems.  I would propose we
merge this through the drm tree if possible.

Alex

> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
> index fc4adf3..7b7b0fd 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -329,7 +329,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   * vga_switcheroo_register_audio_client - register audio client
>   * @pdev: client pci device
>   * @ops: client callbacks
> - * @id: client identifier
> + * @bound_vga: client bound vga pci device
>   *
>   * Register audio client (audio device on a GPU). The client is assumed
>   * to use runtime PM. Beforehand, vga_switcheroo_client_probe_defer()
> @@ -339,8 +339,15 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
>   */
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>                         const struct vga_switcheroo_client_ops *ops,
> -                       enum vga_switcheroo_client_id id)
> +                       struct pci_dev *bound_vga)
>  {
> +       enum vga_switcheroo_client_id id = VGA_SWITCHEROO_DIS;
> +
> +       if (bound_vga) {
> +               if (vgasr_priv.handler->get_client_id)
> +                       id = vgasr_priv.handler->get_client_id(bound_vga);
> +       }
> +
>         return register_client(pdev, ops, id | ID_BIT_AUDIO, false, true);
>  }
>  EXPORT_SYMBOL(vga_switcheroo_register_audio_client);
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index 77f0f0a..a0c7b86 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -151,7 +151,7 @@ int vga_switcheroo_register_client(struct pci_dev *dev,
>                                    bool driver_power_control);
>  int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>                                          const struct vga_switcheroo_client_ops *ops,
> -                                        enum vga_switcheroo_client_id id);
> +                                        struct pci_dev *bound_vga);
>
>  void vga_switcheroo_client_fb_set(struct pci_dev *dev,
>                                   struct fb_info *info);
> @@ -180,7 +180,7 @@ static inline int vga_switcheroo_register_handler(const struct vga_switcheroo_ha
>                 enum vga_switcheroo_handler_flags_t handler_flags) { return 0; }
>  static inline int vga_switcheroo_register_audio_client(struct pci_dev *pdev,
>         const struct vga_switcheroo_client_ops *ops,
> -       enum vga_switcheroo_client_id id) { return 0; }
> +       struct pci_dev *bound_vga) { return 0; }
>  static inline void vga_switcheroo_unregister_handler(void) {}
>  static inline enum vga_switcheroo_handler_flags_t vga_switcheroo_handler_flags(void) { return 0; }
>  static inline int vga_switcheroo_lock_ddc(struct pci_dev *pdev) { return -ENODEV; }
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 1ae1850..8f992e6 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1319,15 +1319,17 @@ static const struct vga_switcheroo_client_ops azx_vs_ops = {
>  static int register_vga_switcheroo(struct azx *chip)
>  {
>         struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> +       struct pci_dev *p;
>         int err;
>
>         if (!hda->use_vga_switcheroo)
>                 return 0;
> -       /* FIXME: currently only handling DIS controller
> -        * is there any machine with two switchable HDMI audio controllers?
> -        */
> -       err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops,
> -                                                  VGA_SWITCHEROO_DIS);
> +
> +       p = get_bound_vga(chip->pci);
> +       err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, p);
> +
> +       if (p)
> +               pci_dev_put(p);
>         if (err < 0)
>                 return err;
>         hda->vga_switcheroo_registered = 1;
> @@ -1429,7 +1431,8 @@ static struct pci_dev *get_bound_vga(struct pci_dev *pci)
>                         p = pci_get_domain_bus_and_slot(pci_domain_nr(pci->bus),
>                                                         pci->bus->number, 0);
>                         if (p) {
> -                               if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA)
> +                               if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA ||
> +                               (p->class >> 8) == PCI_CLASS_DISPLAY_OTHER)
>                                         return p;
>                                 pci_dev_put(p);
>                         }
> --
> 2.7.4
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Lukas Wunner]

> On Thu, Jun 28, 2018 at 2:22 AM, Jim Qu <Jim.Qu@amd.com> wrote:
> > On modern laptop, there are more and more platforms
> > have two GPUs, and each of them maybe have audio codec
> > for HDMP/DP output. For some dGPU which is no output,
> > audio codec usually is disabled.
> >
> > In currect HDA audio driver, it will set all codec as
> > VGA_SWITCHEROO_DIS, so if system runtime pm is enabled,
> > the audio which is binded to UMA will be suspended.

Please explain what you mean by UMA here.  Are you referring to
dual GPU systems where both GPUs are by AMD?  And the integrated
GPU is incorrectly assigned VGA_SWITCHEROO_DIS?

Starting with v4.17, the only reason the audio driver registers
with vga_switcheroo is because it can be powered down if manual
power control is used.  However manual power control is not the
default, it's primary use case nowadays is MacBook Pros, and
there are no MacBook Pros with dual AMD GPUs.  So I don't
understand what real world use case you're trying to fix.
Please explain.


> > Newer dGPUs use PCI_CLASS_DISPLAY_OTHER rather than
> > PCI_CLASS_DISPLAY_VGA.  Make sure we check for both when
> > checking for the dGPU in get_bound_vga()

Unlike the other changes in your patch, this one would seem
perfectly valid to me.  However it's a separate issue, so
please put it in a separate patch.

Instead of adding a check for PCI_CLASS_DISPLAY_OTHER, I'd prefer
you replacing the existing check for PCI_CLASS_DISPLAY_VGA with a
check for PCI_BASE_CLASS_DISPLAY, like so:

-				if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA)
+				if ((p->class >> 16) == PCI_BASE_CLASS_DISPLAY)

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Hi Lukas,

Thanks to your response, please see comments in line.

Thanks
JimQu

________________________________________
发件人: Lukas Wunner <lukas@wunner.de>
发送时间: 2018年6月29日 16:06
收件人: Qu, Jim
抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

> > On Thu, Jun 28, 2018 at 2:22 AM, Jim Qu <Jim.Qu@amd.com> wrote:
> > > On modern laptop, there are more and more platforms
> > > have two GPUs, and each of them maybe have audio codec
> > > for HDMP/DP output. For some dGPU which is no output,
> > > audio codec usually is disabled.
> > >
> > > In currect HDA audio driver, it will set all codec as
> > > VGA_SWITCHEROO_DIS, so if system runtime pm is enabled,
> > > the audio which is binded to UMA will be suspended.

> Please explain what you mean by UMA here.  Are you referring to
> dual GPU systems where both GPUs are by AMD?  And the integrated
> GPU is incorrectly assigned VGA_SWITCHEROO_DIS?

> Starting with v4.17, the only reason the audio driver registers
> with vga_switcheroo is because it can be powered down if manual
> power control is used.  However manual power control is not the
> default, it's primary use case nowadays is MacBook Pros, and
> there are no MacBook Pros with dual AMD GPUs.  So I don't
> understand what real world use case you're trying to fix.
> Please explain.

Jim: Yeah, this a laptop which has two GPUs, iGPU has a HD audio for HDMI output. dGPU is headless which is only for offload render. This is a grapchis offloading solution for hybird GFX.

When our dGPU does suspend by runtime pm. amdgpu driver for dgpu will also call vgaswtichroo to power off its audio. vgaswitchroo driver will find audio codec by vgaswitchroo dgpu client id(VGA_SWITCHEROO_DIS).

Current HDA driver will register iGPU's audio client to vgaswitchroo as VGA_SWITCHEROO_DIS. so iGPU's audio has been powered off. It causes the issue that no sound on the HDMI device.

I think the issue should be observed on both Intel+AMD or AMD+AMD platform which has the same HW
configuration.

1.if dGPU has no audio codec. the issue should be always observed.
2.if both iGPU and dGPU has audio codecs, the issue should be random, it depends on the first audio found by vgaswitchroo driver is on iGPU or dGPU.

> > Newer dGPUs use PCI_CLASS_DISPLAY_OTHER rather than
> > PCI_CLASS_DISPLAY_VGA.  Make sure we check for both when
> > checking for the dGPU in get_bound_vga()

> Unlike the other changes in your patch, this one would seem
> perfectly valid to me.  However it's a separate issue, so
> please put it in a separate patch.

> Instead of adding a check for PCI_CLASS_DISPLAY_OTHER, I'd prefer
> you replacing the existing check for PCI_CLASS_DISPLAY_VGA with a
> check for PCI_BASE_CLASS_DISPLAY, like so:

> -                               if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA)
> +                               if ((p->class >> 16) == PCI_BASE_CLASS_DISPLAY)

Jim: That is fine, will update it.

Thanks,

Lukas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Lukas Wunner]

On Fri, Jun 29, 2018 at 08:55:40AM +0000, Qu, Jim wrote:
> When our dGPU does suspend by runtime pm. amdgpu driver for dgpu will
> also call vgaswtichroo to power off its audio. vgaswitchroo driver will
> find audio codec by vgaswitchroo dgpu client id(VGA_SWITCHEROO_DIS).

That is no longer the case since v4.17.  The HDA controller now runtime
suspends autonomously, see commit 07f4f97d7b4b ("vga_switcheroo: Use
device link for HDA controller").

Your patch appears to be geared towards an older kernel version.
Please retest on the laptop in question with a v4.17+ kernel.


> I think the issue should be observed on both Intel+AMD or AMD+AMD
> platform which has the same HW configuration.
> 
> 1.if dGPU has no audio codec. the issue should be always observed.
> 2.if both iGPU and dGPU has audio codecs, the issue should be random,
> it depends on the first audio found by vgaswitchroo driver is on iGPU
> or dGPU.

On discrete AMD and Nvidia GPUs, the HDA controller is function 1 and
the GPU is function 0 in the same PCI slot.

On Intel chipsets, the HDA controller and the GPU have completely
different PCI device numbers, e.g. the GPU might be 0000:00:02.0 and
the HDA controller might be 0000:00:1b.0.

get_bound_vga() checks that the HDA controller is function 1 and there's
a GPU in function 0 of the same slot.

Thus get_bound_vga() always returns NULL for an Intel HDA controller and
the controller is never registered with vga_switcheroo (which is fine).

Thanks,

Lukas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

[-- Attachment #1.1: Type: text/plain, Size: 2120 bytes --]

indeed?I used 4.13 on the platform. let me have a try with the patch you mentioned

thinks
jimqu

?? Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
Sent: Friday, June 29, 2018 5:21:38 PM
To: Qu, Jim
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org; dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; Deucher, Alexander; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Fri, Jun 29, 2018 at 08:55:40AM +0000, Qu, Jim wrote:
> When our dGPU does suspend by runtime pm. amdgpu driver for dgpu will
> also call vgaswtichroo to power off its audio. vgaswitchroo driver will
> find audio codec by vgaswitchroo dgpu client id(VGA_SWITCHEROO_DIS).

That is no longer the case since v4.17.  The HDA controller now runtime
suspends autonomously, see commit 07f4f97d7b4b ("vga_switcheroo: Use
device link for HDA controller").

Your patch appears to be geared towards an older kernel version.
Please retest on the laptop in question with a v4.17+ kernel.


> I think the issue should be observed on both Intel+AMD or AMD+AMD
> platform which has the same HW configuration.
>
> 1.if dGPU has no audio codec. the issue should be always observed.
> 2.if both iGPU and dGPU has audio codecs, the issue should be random,
> it depends on the first audio found by vgaswitchroo driver is on iGPU
> or dGPU.

On discrete AMD and Nvidia GPUs, the HDA controller is function 1 and
the GPU is function 0 in the same PCI slot.

On Intel chipsets, the HDA controller and the GPU have completely
different PCI device numbers, e.g. the GPU might be 0000:00:02.0 and
the HDA controller might be 0000:00:1b.0.

get_bound_vga() checks that the HDA controller is function 1 and there's
a GPU in function 0 of the same slot.

Thus get_bound_vga() always returns NULL for an Intel HDA controller and
the controller is never registered with vga_switcheroo (which is fine).

Thanks,

Lukas

[-- Attachment #1.2: Type: text/html, Size: 3650 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Lukas Wunner]

On Fri, Jun 29, 2018 at 10:40:50AM +0000, Qu, Jim wrote:
> > That is no longer the case since v4.17.  The HDA controller now runtime
> > suspends autonomously, see commit 07f4f97d7b4b ("vga_switcheroo: Use
> > device link for HDA controller").
> > 
> > Your patch appears to be geared towards an older kernel version.
> > Please retest on the laptop in question with a v4.17+ kernel.
> 
> indeed? I used 4.13 on the platform. let me have a try with the patch
> you mentioned

The commit can't be cherry-picked by itself onto v4.13, it was part of
a larger series.  It's best to use a stock v4.17 kernel.

Note, a fix went into Linus' tree yesterday, commit 57cb54e53bdd
("ALSA: hda - Force to link down at runtime suspend on ATI/AMD HDMI").
Not sure if it's needed on your machine.

Thanks,

Lukas

答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Hi Lukas,

Our OEM report the issue also can be observed with v4.17rc7 of test platform, and I also backported these 7 patches to v4.15, have confirmed the issue.

Now, I found the audio device will auto suspend even if the gpu is active, and if I plug in a HDMI device it also do not resume back. 

1. Did you encounter similar issue before?
2. audio will auto suspend as default at beginning of boot, is it expect behaviour?

Device links help us handle two things:

1. make the audio/gpu suspend/resume/poweroff processing in an orderly way with the DL_FLAG_STATELESS flag.
2. it can guarantee the audio can be accessed if gpu is poweroffed by setting the DL_FLAG_PM_RUNTIME flag.

So, in my opinion, audio's suspend/resume should be processed with gpu suspend/resume.

Thanks
JimQu

________________________________________
发件人: Lukas Wunner <lukas@wunner.de>
发送时间: 2018年6月29日 19:11
收件人: Qu, Jim
抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Fri, Jun 29, 2018 at 10:40:50AM +0000, Qu, Jim wrote:
> > That is no longer the case since v4.17.  The HDA controller now runtime
> > suspends autonomously, see commit 07f4f97d7b4b ("vga_switcheroo: Use
> > device link for HDA controller").
> >
> > Your patch appears to be geared towards an older kernel version.
> > Please retest on the laptop in question with a v4.17+ kernel.
>
> indeed? I used 4.13 on the platform. let me have a try with the patch
> you mentioned

The commit can't be cherry-picked by itself onto v4.13, it was part of
a larger series.  It's best to use a stock v4.17 kernel.

Note, a fix went into Linus' tree yesterday, commit 57cb54e53bdd
("ALSA: hda - Force to link down at runtime suspend on ATI/AMD HDMI").
Not sure if it's needed on your machine.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Lukas Wunner]

On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> Now, I found the audio device will auto suspend even if the gpu is active,
> and if I plug in a HDMI device it also do not resume back. 
> 
> 1. Did you encounter similar issue before?
> 2. audio will auto suspend as default at beginning of boot, is it expect
> behaviour?

Yes, that's expected.  Once you start streaming audio to attached displays,
user space opens the codec device and this causes the HDA controller to
runtime resume.  If the discrete GPU is suspended at that moment, it will
be powered on and kept powered on as long as user space is streaming audio.

Do you need to runtime resume the HDA controller even if user space isn't
streaming audio?  Why, and in which situation exactly?

You're saying above that the HDA controller isn't runtime resumed on
hotplug of a display.  Is that necessary to retrieve ELD or something?
I'm not sure if there's code in the HDA driver to acquire a runtime PM
ref on HPD, but maybe it's necessary.  Or maybe the code is there but
somehow no HPD interrupt is received by the HDA driver?

Thanks,

Lukas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Hi Lukas, 

Thanks to your explanation, and see comments in line.


Do you need to runtime resume the HDA controller even if user space isn't
streaming audio?  Why, and in which situation exactly?

Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.

You're saying above that the HDA controller isn't runtime resumed on
hotplug of a display.  Is that necessary to retrieve ELD or something?
I'm not sure if there's code in the HDA driver to acquire a runtime PM
ref on HPD, but maybe it's necessary.  Or maybe the code is there but
somehow no HPD interrupt is received by the HDA driver?

Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.

Thanks
JimQu

________________________________________
发件人: Lukas Wunner <lukas@wunner.de>
发送时间: 2018年7月9日 17:27
收件人: Qu, Jim
抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> Now, I found the audio device will auto suspend even if the gpu is active,
> and if I plug in a HDMI device it also do not resume back.
>
> 1. Did you encounter similar issue before?
> 2. audio will auto suspend as default at beginning of boot, is it expect
> behaviour?

Yes, that's expected.  Once you start streaming audio to attached displays,
user space opens the codec device and this causes the HDA controller to
runtime resume.  If the discrete GPU is suspended at that moment, it will
be powered on and kept powered on as long as user space is streaming audio.

Do you need to runtime resume the HDA controller even if user space isn't
streaming audio?  Why, and in which situation exactly?

You're saying above that the HDA controller isn't runtime resumed on
hotplug of a display.  Is that necessary to retrieve ELD or something?
I'm not sure if there's code in the HDA driver to acquire a runtime PM
ref on HPD, but maybe it's necessary.  Or maybe the code is there but
somehow no HPD interrupt is received by the HDA driver?

Thanks,

Lukas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> Hi Lukas,
>
> Thanks to your explanation, and see comments in line.
>
>
> Do you need to runtime resume the HDA controller even if user space isn't
> streaming audio?  Why, and in which situation exactly?
>
> Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
>
> You're saying above that the HDA controller isn't runtime resumed on
> hotplug of a display.  Is that necessary to retrieve ELD or something?
> I'm not sure if there's code in the HDA driver to acquire a runtime PM
> ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> somehow no HPD interrupt is received by the HDA driver?
>
> Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.

On the gfx side at least, we can get a hotplug event via ACPI
(depending on the OEM design) if displays are attached/detached while
the dGPU is powered down.  I suppose the gfx driver could call into
the audio driver during one of those events.  On the gfx side at least
we just generate the gfx hotplug event and let userspace deal with it.

Alex

>
> Thanks
> JimQu
>
> ________________________________________
> 发件人: Lukas Wunner <lukas@wunner.de>
> 发送时间: 2018年7月9日 17:27
> 收件人: Qu, Jim
> 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>
> On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
>> Now, I found the audio device will auto suspend even if the gpu is active,
>> and if I plug in a HDMI device it also do not resume back.
>>
>> 1. Did you encounter similar issue before?
>> 2. audio will auto suspend as default at beginning of boot, is it expect
>> behaviour?
>
> Yes, that's expected.  Once you start streaming audio to attached displays,
> user space opens the codec device and this causes the HDA controller to
> runtime resume.  If the discrete GPU is suspended at that moment, it will
> be powered on and kept powered on as long as user space is streaming audio.
>
> Do you need to runtime resume the HDA controller even if user space isn't
> streaming audio?  Why, and in which situation exactly?
>
> You're saying above that the HDA controller isn't runtime resumed on
> hotplug of a display.  Is that necessary to retrieve ELD or something?
> I'm not sure if there's code in the HDA driver to acquire a runtime PM
> ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> somehow no HPD interrupt is received by the HDA driver?
>
> Thanks,
>
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 15:58:51 +0200,
Alex Deucher wrote:
> 
> On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > Hi Lukas,
> >
> > Thanks to your explanation, and see comments in line.
> >
> >
> > Do you need to runtime resume the HDA controller even if user space isn't
> > streaming audio?  Why, and in which situation exactly?
> >
> > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> >
> > You're saying above that the HDA controller isn't runtime resumed on
> > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > somehow no HPD interrupt is received by the HDA driver?
> >
> > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> 
> On the gfx side at least, we can get a hotplug event via ACPI
> (depending on the OEM design) if displays are attached/detached while
> the dGPU is powered down.  I suppose the gfx driver could call into
> the audio driver during one of those events.  On the gfx side at least
> we just generate the gfx hotplug event and let userspace deal with it.

IMO, a more proper way would be to have the direct communication
between the graphics driver and the audio driver like i915 driver
does.  Then the audio driver can get plug/unplug event at more
accurate timing without races.

(Though, it will cause another mess wrt the weak module dependency,
 but it's another story :)


thanks,

Takashi


> 
> Alex
> 
> >
> > Thanks
> > JimQu
> >
> > ________________________________________
> > 发件人: Lukas Wunner <lukas@wunner.de>
> > 发送时间: 2018年7月9日 17:27
> > 收件人: Qu, Jim
> > 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> >
> > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> >> Now, I found the audio device will auto suspend even if the gpu is active,
> >> and if I plug in a HDMI device it also do not resume back.
> >>
> >> 1. Did you encounter similar issue before?
> >> 2. audio will auto suspend as default at beginning of boot, is it expect
> >> behaviour?
> >
> > Yes, that's expected.  Once you start streaming audio to attached displays,
> > user space opens the codec device and this causes the HDA controller to
> > runtime resume.  If the discrete GPU is suspended at that moment, it will
> > be powered on and kept powered on as long as user space is streaming audio.
> >
> > Do you need to runtime resume the HDA controller even if user space isn't
> > streaming audio?  Why, and in which situation exactly?
> >
> > You're saying above that the HDA controller isn't runtime resumed on
> > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > somehow no HPD interrupt is received by the HDA driver?
> >
> > Thanks,
> >
> > Lukas
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Lukas Wunner]

On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > You're saying above that the HDA controller isn't runtime resumed on
> > > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > > > somehow no HPD interrupt is received by the HDA driver?
> > >
> > > So far, I do not find any code about audio response HPD in kernel.
> > > the HPD interrupt will sent to user mode via uevent, not sure whether
> > > audio user mode driver can receive the event or not.
> > 
> > On the gfx side at least, we can get a hotplug event via ACPI
> > (depending on the OEM design) if displays are attached/detached while
> > the dGPU is powered down.  I suppose the gfx driver could call into
> > the audio driver during one of those events.  On the gfx side at least
> > we just generate the gfx hotplug event and let userspace deal with it.
> 
> IMO, a more proper way would be to have the direct communication
> between the graphics driver and the audio driver like i915 driver
> does.  Then the audio driver can get plug/unplug event at more
> accurate timing without races.

Since v4.17, every time the GPU is powered up, the HDA controller is
runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
vga_switcheroo_runtime_resume() added by dcac86b7d0.)

If the HDA controller can't detect presence of an HDMI display even
if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
driver.  Thus so far I don't see the need to call from amdgpu into the
HDA driver.

Thanks,

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 17:47:34 +0200,
Lukas Wunner wrote:
> 
> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > > You're saying above that the HDA controller isn't runtime resumed on
> > > > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > > > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > > > > somehow no HPD interrupt is received by the HDA driver?
> > > >
> > > > So far, I do not find any code about audio response HPD in kernel.
> > > > the HPD interrupt will sent to user mode via uevent, not sure whether
> > > > audio user mode driver can receive the event or not.
> > > 
> > > On the gfx side at least, we can get a hotplug event via ACPI
> > > (depending on the OEM design) if displays are attached/detached while
> > > the dGPU is powered down.  I suppose the gfx driver could call into
> > > the audio driver during one of those events.  On the gfx side at least
> > > we just generate the gfx hotplug event and let userspace deal with it.
> > 
> > IMO, a more proper way would be to have the direct communication
> > between the graphics driver and the audio driver like i915 driver
> > does.  Then the audio driver can get plug/unplug event at more
> > accurate timing without races.
> 
> Since v4.17, every time the GPU is powered up, the HDA controller is
> runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
> vga_switcheroo_runtime_resume() added by dcac86b7d0.)
> 
> If the HDA controller can't detect presence of an HDMI display even
> if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
> driver.  Thus so far I don't see the need to call from amdgpu into the
> HDA driver.

It's not about the PCI power state, but the problem is that the
detection of the HDMI and its ELD read is somewhat asynchronous.
Basically it's handled via the hardware unsolicited event emitted over
HD-audio bus, which was originally generated by GPU at dealing with
the hotplug/unplug.  So, this part is racy and not 100% reliable --
although usually it shouldn't be a big problem.

That said, it's not the exact "need" but it would make things more
reliable and accurate (even consumes less power as we don't need to
power up/down just for the HDMI detection).


Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 9, 2018 at 11:52 AM, Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 09 Jul 2018 17:47:34 +0200,
> Lukas Wunner wrote:
>>
>> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
>> > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
>> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
>> > > > > You're saying above that the HDA controller isn't runtime resumed on
>> > > > > hotplug of a display.  Is that necessary to retrieve ELD or something?
>> > > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
>> > > > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
>> > > > > somehow no HPD interrupt is received by the HDA driver?
>> > > >
>> > > > So far, I do not find any code about audio response HPD in kernel.
>> > > > the HPD interrupt will sent to user mode via uevent, not sure whether
>> > > > audio user mode driver can receive the event or not.
>> > >
>> > > On the gfx side at least, we can get a hotplug event via ACPI
>> > > (depending on the OEM design) if displays are attached/detached while
>> > > the dGPU is powered down.  I suppose the gfx driver could call into
>> > > the audio driver during one of those events.  On the gfx side at least
>> > > we just generate the gfx hotplug event and let userspace deal with it.
>> >
>> > IMO, a more proper way would be to have the direct communication
>> > between the graphics driver and the audio driver like i915 driver
>> > does.  Then the audio driver can get plug/unplug event at more
>> > accurate timing without races.
>>
>> Since v4.17, every time the GPU is powered up, the HDA controller is
>> runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
>> vga_switcheroo_runtime_resume() added by dcac86b7d0.)
>>
>> If the HDA controller can't detect presence of an HDMI display even
>> if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
>> driver.  Thus so far I don't see the need to call from amdgpu into the
>> HDA driver.
>
> It's not about the PCI power state, but the problem is that the
> detection of the HDMI and its ELD read is somewhat asynchronous.
> Basically it's handled via the hardware unsolicited event emitted over
> HD-audio bus, which was originally generated by GPU at dealing with
> the hotplug/unplug.  So, this part is racy and not 100% reliable --
> although usually it shouldn't be a big problem.
>
> That said, it's not the exact "need" but it would make things more
> reliable and accurate (even consumes less power as we don't need to
> power up/down just for the HDMI detection).

Well for display detection, we don't actually have to wake the GPU, we
get the notification from the embedded controller via ACPI if the GPU
is powered down, so in the GPU driver we just pass the event along to
userspace if the GPU is asleep.  I think if we wanted to pass the info
along to the audio driver, we'd need to wake both the GPU and the
audio to update the audio connect status.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 17:59:00 +0200,
Alex Deucher wrote:
> 
> On Mon, Jul 9, 2018 at 11:52 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Mon, 09 Jul 2018 17:47:34 +0200,
> > Lukas Wunner wrote:
> >>
> >> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> >> > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> >> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> >> > > > > You're saying above that the HDA controller isn't runtime resumed on
> >> > > > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> >> > > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> >> > > > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> >> > > > > somehow no HPD interrupt is received by the HDA driver?
> >> > > >
> >> > > > So far, I do not find any code about audio response HPD in kernel.
> >> > > > the HPD interrupt will sent to user mode via uevent, not sure whether
> >> > > > audio user mode driver can receive the event or not.
> >> > >
> >> > > On the gfx side at least, we can get a hotplug event via ACPI
> >> > > (depending on the OEM design) if displays are attached/detached while
> >> > > the dGPU is powered down.  I suppose the gfx driver could call into
> >> > > the audio driver during one of those events.  On the gfx side at least
> >> > > we just generate the gfx hotplug event and let userspace deal with it.
> >> >
> >> > IMO, a more proper way would be to have the direct communication
> >> > between the graphics driver and the audio driver like i915 driver
> >> > does.  Then the audio driver can get plug/unplug event at more
> >> > accurate timing without races.
> >>
> >> Since v4.17, every time the GPU is powered up, the HDA controller is
> >> runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
> >> vga_switcheroo_runtime_resume() added by dcac86b7d0.)
> >>
> >> If the HDA controller can't detect presence of an HDMI display even
> >> if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
> >> driver.  Thus so far I don't see the need to call from amdgpu into the
> >> HDA driver.
> >
> > It's not about the PCI power state, but the problem is that the
> > detection of the HDMI and its ELD read is somewhat asynchronous.
> > Basically it's handled via the hardware unsolicited event emitted over
> > HD-audio bus, which was originally generated by GPU at dealing with
> > the hotplug/unplug.  So, this part is racy and not 100% reliable --
> > although usually it shouldn't be a big problem.
> >
> > That said, it's not the exact "need" but it would make things more
> > reliable and accurate (even consumes less power as we don't need to
> > power up/down just for the HDMI detection).
> 
> Well for display detection, we don't actually have to wake the GPU, we
> get the notification from the embedded controller via ACPI if the GPU
> is powered down, so in the GPU driver we just pass the event along to
> userspace if the GPU is asleep.  I think if we wanted to pass the info
> along to the audio driver, we'd need to wake both the GPU and the
> audio to update the audio connect status.

I guess that It's not enough to have an ACPI event but we need to read
ELD upon hotplugging (not at unplugging, of course, though).  So a GPU
wakeup would be mandatory, if I'm not mistaken.


Takashi

Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Lukas Wunner]

On Mon, Jul 09, 2018 at 05:52:49PM +0200, Takashi Iwai wrote:
> On Mon, 09 Jul 2018 17:47:34 +0200, Lukas Wunner wrote:
> > Since v4.17, every time the GPU is powered up, the HDA controller is
> > runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
> > vga_switcheroo_runtime_resume() added by dcac86b7d0.)
> > 
> > If the HDA controller can't detect presence of an HDMI display even
> > if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
> > driver.  Thus so far I don't see the need to call from amdgpu into the
> > HDA driver.
> 
> It's not about the PCI power state, but the problem is that the
> detection of the HDMI and its ELD read is somewhat asynchronous.
> Basically it's handled via the hardware unsolicited event emitted over
> HD-audio bus, which was originally generated by GPU at dealing with
> the hotplug/unplug.  So, this part is racy and not 100% reliable --
> although usually it shouldn't be a big problem.
> 
> That said, it's not the exact "need" but it would make things more
> reliable and accurate (even consumes less power as we don't need to
> power up/down just for the HDMI detection).

Okay.  If amdgpu triggers the event on the HDA bus, it should call
pm_runtime_get_sync() on the HDA device beforehand.  Which device
needs to be resumed exactly to ensure ELD reception, the PCI one
or the codec?

Thanks,

Lukas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner <lukas@wunner.de> wrote:
> On Mon, Jul 09, 2018 at 05:52:49PM +0200, Takashi Iwai wrote:
>> On Mon, 09 Jul 2018 17:47:34 +0200, Lukas Wunner wrote:
>> > Since v4.17, every time the GPU is powered up, the HDA controller is
>> > runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
>> > vga_switcheroo_runtime_resume() added by dcac86b7d0.)
>> >
>> > If the HDA controller can't detect presence of an HDMI display even
>> > if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
>> > driver.  Thus so far I don't see the need to call from amdgpu into the
>> > HDA driver.
>>
>> It's not about the PCI power state, but the problem is that the
>> detection of the HDMI and its ELD read is somewhat asynchronous.
>> Basically it's handled via the hardware unsolicited event emitted over
>> HD-audio bus, which was originally generated by GPU at dealing with
>> the hotplug/unplug.  So, this part is racy and not 100% reliable --
>> although usually it shouldn't be a big problem.
>>
>> That said, it's not the exact "need" but it would make things more
>> reliable and accurate (even consumes less power as we don't need to
>> power up/down just for the HDMI detection).
>
> Okay.  If amdgpu triggers the event on the HDA bus, it should call
> pm_runtime_get_sync() on the HDA device beforehand.  Which device
> needs to be resumed exactly to ensure ELD reception, the PCI one
> or the codec?

I don't think it makes sense to power up anything until the user wants
to do something with the event.  On AMD hardware, the ELD is not
actually used.  The gpu passes the ELD info internally via shared
registers.  So as soon as the GPU driver parses the EDID and updates
the shared registers, the audio driver will know the state just by
reading back the shared registers.  That said, there no reason to act
on the event unless the user actually wants to do something with it.
E.g., the desktop manager sees the event and decides to call down to
the kernel to query the display topology (or not).  At which point the
hw can be powered up, etc.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 18:15:32 +0200,
Alex Deucher wrote:
> 
> On Mon, Jul 9, 2018 at 12:06 PM, Lukas Wunner <lukas@wunner.de> wrote:
> > On Mon, Jul 09, 2018 at 05:52:49PM +0200, Takashi Iwai wrote:
> >> On Mon, 09 Jul 2018 17:47:34 +0200, Lukas Wunner wrote:
> >> > Since v4.17, every time the GPU is powered up, the HDA controller is
> >> > runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
> >> > vga_switcheroo_runtime_resume() added by dcac86b7d0.)
> >> >
> >> > If the HDA controller can't detect presence of an HDMI display even
> >> > if it's in PCI_D0, then I suppose that needs to be adressed in the HDA
> >> > driver.  Thus so far I don't see the need to call from amdgpu into the
> >> > HDA driver.
> >>
> >> It's not about the PCI power state, but the problem is that the
> >> detection of the HDMI and its ELD read is somewhat asynchronous.
> >> Basically it's handled via the hardware unsolicited event emitted over
> >> HD-audio bus, which was originally generated by GPU at dealing with
> >> the hotplug/unplug.  So, this part is racy and not 100% reliable --
> >> although usually it shouldn't be a big problem.
> >>
> >> That said, it's not the exact "need" but it would make things more
> >> reliable and accurate (even consumes less power as we don't need to
> >> power up/down just for the HDMI detection).
> >
> > Okay.  If amdgpu triggers the event on the HDA bus, it should call
> > pm_runtime_get_sync() on the HDA device beforehand.  Which device
> > needs to be resumed exactly to ensure ELD reception, the PCI one
> > or the codec?
> 
> I don't think it makes sense to power up anything until the user wants
> to do something with the event.  On AMD hardware, the ELD is not
> actually used.  The gpu passes the ELD info internally via shared
> registers.  So as soon as the GPU driver parses the EDID and updates
> the shared registers, the audio driver will know the state just by
> reading back the shared registers.  That said, there no reason to act
> on the event unless the user actually wants to do something with it.
> E.g., the desktop manager sees the event and decides to call down to
> the kernel to query the display topology (or not).  At which point the
> hw can be powered up, etc.

It needs to power up to read even the shared registers; they are
accessed via HD-audio verbs, so we need the whole runtime resume of
the bus & codec just for reading ELD information that are stored by
GPU.

And, ELD info is mandatory for informing the hotplug information to
user-space, not only the connection/disconnection state.

If ELD and hoptlug info are passed directly from GPU by other means,
we can avoid the power up/down in the audio side, indeed.  That's what
Intel driver serves, after all.


Takashi
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

答复: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Hi All,

Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU. 

Thanks
JimQu 

-----邮件原件-----
发件人: Lukas Wunner <lukas@wunner.de> 
发送时间: 2018年7月9日 23:48
收件人: Takashi Iwai <tiwai@suse.de>
抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > You're saying above that the HDA controller isn't runtime 
> > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > I'm not sure if there's code in the HDA driver to acquire a 
> > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the 
> > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > >
> > > So far, I do not find any code about audio response HPD in kernel.
> > > the HPD interrupt will sent to user mode via uevent, not sure 
> > > whether audio user mode driver can receive the event or not.
> > 
> > On the gfx side at least, we can get a hotplug event via ACPI 
> > (depending on the OEM design) if displays are attached/detached 
> > while the dGPU is powered down.  I suppose the gfx driver could call 
> > into the audio driver during one of those events.  On the gfx side 
> > at least we just generate the gfx hotplug event and let userspace deal with it.
> 
> IMO, a more proper way would be to have the direct communication 
> between the graphics driver and the audio driver like i915 driver 
> does.  Then the audio driver can get plug/unplug event at more 
> accurate timing without races.

Since v4.17, every time the GPU is powered up, the HDA controller is runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
vga_switcheroo_runtime_resume() added by dcac86b7d0.)

If the HDA controller can't detect presence of an HDMI display even if it's in PCI_D0, then I suppose that needs to be adressed in the HDA driver.  Thus so far I don't see the need to call from amdgpu into the HDA driver.

Thanks,

Lukas
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 17:53:19 +0200,
Qu, Jim wrote:
> 
> Hi All,
> 
> Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU. 

I'm confused.  So you mean that the HDMI detection on Intel GPU
doesn't work with the hybrid GPUs?  And no audio codec on discrete
GPU...?  Why do we need vga_switcheroo at all, then?


Takashi


> 
> Thanks
> JimQu 
> 
> -----邮件原件-----
> 发件人: Lukas Wunner <lukas@wunner.de> 
> 发送时间: 2018年7月9日 23:48
> 收件人: Takashi Iwai <tiwai@suse.de>
> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> 
> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > > You're saying above that the HDA controller isn't runtime 
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a 
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the 
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > >
> > > > So far, I do not find any code about audio response HPD in kernel.
> > > > the HPD interrupt will sent to user mode via uevent, not sure 
> > > > whether audio user mode driver can receive the event or not.
> > > 
> > > On the gfx side at least, we can get a hotplug event via ACPI 
> > > (depending on the OEM design) if displays are attached/detached 
> > > while the dGPU is powered down.  I suppose the gfx driver could call 
> > > into the audio driver during one of those events.  On the gfx side 
> > > at least we just generate the gfx hotplug event and let userspace deal with it.
> > 
> > IMO, a more proper way would be to have the direct communication 
> > between the graphics driver and the audio driver like i915 driver 
> > does.  Then the audio driver can get plug/unplug event at more 
> > accurate timing without races.
> 
> Since v4.17, every time the GPU is powered up, the HDA controller is runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
> vga_switcheroo_runtime_resume() added by dcac86b7d0.)
> 
> If the HDA controller can't detect presence of an HDMI display even if it's in PCI_D0, then I suppose that needs to be adressed in the HDA driver.  Thus so far I don't see the need to call from amdgpu into the HDA driver.
> 
> Thanks,
> 
> Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 9, 2018 at 11:57 AM, Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 09 Jul 2018 17:53:19 +0200,
> Qu, Jim wrote:
>>
>> Hi All,
>>
>> Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU.
>
> I'm confused.  So you mean that the HDMI detection on Intel GPU
> doesn't work with the hybrid GPUs?  And no audio codec on discrete
> GPU...?  Why do we need vga_switcheroo at all, then?

The original problem is the audio codec is getting associated with
dGPU rather than the iGPU so switcheroo tries to power down the audio
codec when it powers down the dGPU.  We got a bit sidetracked in the
discussion however.

Alex

>
>
> Takashi
>
>
>>
>> Thanks
>> JimQu
>>
>> -----邮件原件-----
>> 发件人: Lukas Wunner <lukas@wunner.de>
>> 发送时间: 2018年7月9日 23:48
>> 收件人: Takashi Iwai <tiwai@suse.de>
>> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
>> 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>>
>> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
>> > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
>> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
>> > > > > You're saying above that the HDA controller isn't runtime
>> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
>> > > > > I'm not sure if there's code in the HDA driver to acquire a
>> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
>> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
>> > > >
>> > > > So far, I do not find any code about audio response HPD in kernel.
>> > > > the HPD interrupt will sent to user mode via uevent, not sure
>> > > > whether audio user mode driver can receive the event or not.
>> > >
>> > > On the gfx side at least, we can get a hotplug event via ACPI
>> > > (depending on the OEM design) if displays are attached/detached
>> > > while the dGPU is powered down.  I suppose the gfx driver could call
>> > > into the audio driver during one of those events.  On the gfx side
>> > > at least we just generate the gfx hotplug event and let userspace deal with it.
>> >
>> > IMO, a more proper way would be to have the direct communication
>> > between the graphics driver and the audio driver like i915 driver
>> > does.  Then the audio driver can get plug/unplug event at more
>> > accurate timing without races.
>>
>> Since v4.17, every time the GPU is powered up, the HDA controller is runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
>> vga_switcheroo_runtime_resume() added by dcac86b7d0.)
>>
>> If the HDA controller can't detect presence of an HDMI display even if it's in PCI_D0, then I suppose that needs to be adressed in the HDA driver.  Thus so far I don't see the need to call from amdgpu into the HDA driver.
>>
>> Thanks,
>>
>> Lukas
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 答复: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 18:03:48 +0200,
Alex Deucher wrote:
> 
> On Mon, Jul 9, 2018 at 11:57 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Mon, 09 Jul 2018 17:53:19 +0200,
> > Qu, Jim wrote:
> >>
> >> Hi All,
> >>
> >> Here, I want to clarify the audio device is bound to iGPU. There is no audio codec for dGPU.
> >
> > I'm confused.  So you mean that the HDMI detection on Intel GPU
> > doesn't work with the hybrid GPUs?  And no audio codec on discrete
> > GPU...?  Why do we need vga_switcheroo at all, then?
> 
> The original problem is the audio codec is getting associated with
> dGPU rather than the iGPU so switcheroo tries to power down the audio
> codec when it powers down the dGPU.  We got a bit sidetracked in the
> discussion however.

Ah, thanks, that clarifies better, but still I'm lost about what's
going on...

Can anyone summarize the problem and the results with the recent (>=
4.17) Linux kernel...?


thanks,

Takashi


> Alex
> 
> >
> >
> > Takashi
> >
> >
> >>
> >> Thanks
> >> JimQu
> >>
> >> -----邮件原件-----
> >> 发件人: Lukas Wunner <lukas@wunner.de>
> >> 发送时间: 2018年7月9日 23:48
> >> 收件人: Takashi Iwai <tiwai@suse.de>
> >> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> >> 主题: Re: [alsa-devel] ??????: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> >>
> >> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> >> > On Mon, 09 Jul 2018 15:58:51 +0200, Alex Deucher wrote:
> >> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> >> > > > > You're saying above that the HDA controller isn't runtime
> >> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> >> > > > > I'm not sure if there's code in the HDA driver to acquire a
> >> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> >> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> >> > > >
> >> > > > So far, I do not find any code about audio response HPD in kernel.
> >> > > > the HPD interrupt will sent to user mode via uevent, not sure
> >> > > > whether audio user mode driver can receive the event or not.
> >> > >
> >> > > On the gfx side at least, we can get a hotplug event via ACPI
> >> > > (depending on the OEM design) if displays are attached/detached
> >> > > while the dGPU is powered down.  I suppose the gfx driver could call
> >> > > into the audio driver during one of those events.  On the gfx side
> >> > > at least we just generate the gfx hotplug event and let userspace deal with it.
> >> >
> >> > IMO, a more proper way would be to have the direct communication
> >> > between the graphics driver and the audio driver like i915 driver
> >> > does.  Then the audio driver can get plug/unplug event at more
> >> > accurate timing without races.
> >>
> >> Since v4.17, every time the GPU is powered up, the HDA controller is runtime resumed to PCI_D0.  (See the call to pci_wakeup_bus() in
> >> vga_switcheroo_runtime_resume() added by dcac86b7d0.)
> >>
> >> If the HDA controller can't detect presence of an HDMI display even if it's in PCI_D0, then I suppose that needs to be adressed in the HDA driver.  Thus so far I don't see the need to call from amdgpu into the HDA driver.
> >>
> >> Thanks,
> >>
> >> Lukas
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Daniel Vetter]

On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> On Mon, 09 Jul 2018 15:58:51 +0200,
> Alex Deucher wrote:
> > 
> > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > Hi Lukas,
> > >
> > > Thanks to your explanation, and see comments in line.
> > >
> > >
> > > Do you need to runtime resume the HDA controller even if user space isn't
> > > streaming audio?  Why, and in which situation exactly?
> > >
> > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > >
> > > You're saying above that the HDA controller isn't runtime resumed on
> > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > > somehow no HPD interrupt is received by the HDA driver?
> > >
> > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > 
> > On the gfx side at least, we can get a hotplug event via ACPI
> > (depending on the OEM design) if displays are attached/detached while
> > the dGPU is powered down.  I suppose the gfx driver could call into
> > the audio driver during one of those events.  On the gfx side at least
> > we just generate the gfx hotplug event and let userspace deal with it.
> 
> IMO, a more proper way would be to have the direct communication
> between the graphics driver and the audio driver like i915 driver
> does.  Then the audio driver can get plug/unplug event at more
> accurate timing without races.
> 
> (Though, it will cause another mess wrt the weak module dependency,
>  but it's another story :)

Just don't do what snd-hda-intel did and instead implement the component
stuff properly :-)
-Daniel

> 
> 
> thanks,
> 
> Takashi
> 
> 
> > 
> > Alex
> > 
> > >
> > > Thanks
> > > JimQu
> > >
> > > ________________________________________
> > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > 发送时间: 2018年7月9日 17:27
> > > 收件人: Qu, Jim
> > > 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> > >
> > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > >> Now, I found the audio device will auto suspend even if the gpu is active,
> > >> and if I plug in a HDMI device it also do not resume back.
> > >>
> > >> 1. Did you encounter similar issue before?
> > >> 2. audio will auto suspend as default at beginning of boot, is it expect
> > >> behaviour?
> > >
> > > Yes, that's expected.  Once you start streaming audio to attached displays,
> > > user space opens the codec device and this causes the HDA controller to
> > > runtime resume.  If the discrete GPU is suspended at that moment, it will
> > > be powered on and kept powered on as long as user space is streaming audio.
> > >
> > > Do you need to runtime resume the HDA controller even if user space isn't
> > > streaming audio?  Why, and in which situation exactly?
> > >
> > > You're saying above that the HDA controller isn't runtime resumed on
> > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > > somehow no HPD interrupt is received by the HDA driver?
> > >
> > > Thanks,
> > >
> > > Lukas
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 17:56:43 +0200,
Daniel Vetter wrote:
> 
> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > On Mon, 09 Jul 2018 15:58:51 +0200,
> > Alex Deucher wrote:
> > > 
> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > Hi Lukas,
> > > >
> > > > Thanks to your explanation, and see comments in line.
> > > >
> > > >
> > > > Do you need to runtime resume the HDA controller even if user space isn't
> > > > streaming audio?  Why, and in which situation exactly?
> > > >
> > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > > >
> > > > You're saying above that the HDA controller isn't runtime resumed on
> > > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > > > somehow no HPD interrupt is received by the HDA driver?
> > > >
> > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > > 
> > > On the gfx side at least, we can get a hotplug event via ACPI
> > > (depending on the OEM design) if displays are attached/detached while
> > > the dGPU is powered down.  I suppose the gfx driver could call into
> > > the audio driver during one of those events.  On the gfx side at least
> > > we just generate the gfx hotplug event and let userspace deal with it.
> > 
> > IMO, a more proper way would be to have the direct communication
> > between the graphics driver and the audio driver like i915 driver
> > does.  Then the audio driver can get plug/unplug event at more
> > accurate timing without races.
> > 
> > (Though, it will cause another mess wrt the weak module dependency,
> >  but it's another story :)
> 
> Just don't do what snd-hda-intel did and instead implement the component
> stuff properly :-)

A patch is welcome :)


thanks,

Takashi

> -Daniel
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > 
> > > 
> > > Alex
> > > 
> > > >
> > > > Thanks
> > > > JimQu
> > > >
> > > > ________________________________________
> > > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > > 发送时间: 2018年7月9日 17:27
> > > > 收件人: Qu, Jim
> > > > 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> > > >
> > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > > >> Now, I found the audio device will auto suspend even if the gpu is active,
> > > >> and if I plug in a HDMI device it also do not resume back.
> > > >>
> > > >> 1. Did you encounter similar issue before?
> > > >> 2. audio will auto suspend as default at beginning of boot, is it expect
> > > >> behaviour?
> > > >
> > > > Yes, that's expected.  Once you start streaming audio to attached displays,
> > > > user space opens the codec device and this causes the HDA controller to
> > > > runtime resume.  If the discrete GPU is suspended at that moment, it will
> > > > be powered on and kept powered on as long as user space is streaming audio.
> > > >
> > > > Do you need to runtime resume the HDA controller even if user space isn't
> > > > streaming audio?  Why, and in which situation exactly?
> > > >
> > > > You're saying above that the HDA controller isn't runtime resumed on
> > > > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > > > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > > > somehow no HPD interrupt is received by the HDA driver?
> > > >
> > > > Thanks,
> > > >
> > > > Lukas
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Hi Takashi,

Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.

Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.

Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.

Thanks
JimQu

-----邮件原件-----
发件人: Takashi Iwai <tiwai@suse.de> 
发送时间: 2018年7月9日 23:58
收件人: Daniel Vetter <daniel@ffwll.ch>
抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Mon, 09 Jul 2018 17:56:43 +0200,
Daniel Vetter wrote:
> 
> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > On Mon, 09 Jul 2018 15:58:51 +0200,
> > Alex Deucher wrote:
> > > 
> > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > Hi Lukas,
> > > >
> > > > Thanks to your explanation, and see comments in line.
> > > >
> > > >
> > > > Do you need to runtime resume the HDA controller even if user 
> > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > >
> > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > > >
> > > > You're saying above that the HDA controller isn't runtime 
> > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > I'm not sure if there's code in the HDA driver to acquire a 
> > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the 
> > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > >
> > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > > 
> > > On the gfx side at least, we can get a hotplug event via ACPI 
> > > (depending on the OEM design) if displays are attached/detached 
> > > while the dGPU is powered down.  I suppose the gfx driver could 
> > > call into the audio driver during one of those events.  On the gfx 
> > > side at least we just generate the gfx hotplug event and let userspace deal with it.
> > 
> > IMO, a more proper way would be to have the direct communication 
> > between the graphics driver and the audio driver like i915 driver 
> > does.  Then the audio driver can get plug/unplug event at more 
> > accurate timing without races.
> > 
> > (Though, it will cause another mess wrt the weak module dependency,  
> > but it's another story :)
> 
> Just don't do what snd-hda-intel did and instead implement the 
> component stuff properly :-)

A patch is welcome :)


thanks,

Takashi

> -Daniel
> 
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > 
> > > 
> > > Alex
> > > 
> > > >
> > > > Thanks
> > > > JimQu
> > > >
> > > > ________________________________________
> > > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > > 发送时间: 2018年7月9日 17:27
> > > > 收件人: Qu, Jim
> > > > 抄送: alsa-devel@alsa-project.org; 
> > > > dri-devel@lists.freedesktop.org; Deucher, Alexander; 
> > > > amd-gfx@lists.freedesktop.org
> > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to 
> > > > bound gpu client id
> > > >
> > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > > >> Now, I found the audio device will auto suspend even if the gpu 
> > > >> is active, and if I plug in a HDMI device it also do not resume back.
> > > >>
> > > >> 1. Did you encounter similar issue before?
> > > >> 2. audio will auto suspend as default at beginning of boot, is 
> > > >> it expect behaviour?
> > > >
> > > > Yes, that's expected.  Once you start streaming audio to 
> > > > attached displays, user space opens the codec device and this 
> > > > causes the HDA controller to runtime resume.  If the discrete 
> > > > GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
> > > >
> > > > Do you need to runtime resume the HDA controller even if user 
> > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > >
> > > > You're saying above that the HDA controller isn't runtime 
> > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > I'm not sure if there's code in the HDA driver to acquire a 
> > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the 
> > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > >
> > > > Thanks,
> > > >
> > > > Lukas
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@alsa-project.org
> > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:
> 
> Hi Takashi,
> 
> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
> 
> Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
> 
> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi

> 
> Thanks
> JimQu
> 
> -----邮件原件-----
> 发件人: Takashi Iwai <tiwai@suse.de> 
> 发送时间: 2018年7月9日 23:58
> 收件人: Daniel Vetter <daniel@ffwll.ch>
> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> 
> On Mon, 09 Jul 2018 17:56:43 +0200,
> Daniel Vetter wrote:
> > 
> > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > Alex Deucher wrote:
> > > > 
> > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > > Hi Lukas,
> > > > >
> > > > > Thanks to your explanation, and see comments in line.
> > > > >
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user 
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime 
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a 
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the 
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > >
> > > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > > > 
> > > > On the gfx side at least, we can get a hotplug event via ACPI 
> > > > (depending on the OEM design) if displays are attached/detached 
> > > > while the dGPU is powered down.  I suppose the gfx driver could 
> > > > call into the audio driver during one of those events.  On the gfx 
> > > > side at least we just generate the gfx hotplug event and let userspace deal with it.
> > > 
> > > IMO, a more proper way would be to have the direct communication 
> > > between the graphics driver and the audio driver like i915 driver 
> > > does.  Then the audio driver can get plug/unplug event at more 
> > > accurate timing without races.
> > > 
> > > (Though, it will cause another mess wrt the weak module dependency,  
> > > but it's another story :)
> > 
> > Just don't do what snd-hda-intel did and instead implement the 
> > component stuff properly :-)
> 
> A patch is welcome :)
> 
> 
> thanks,
> 
> Takashi
> 
> > -Daniel
> > 
> > > 
> > > 
> > > thanks,
> > > 
> > > Takashi
> > > 
> > > 
> > > > 
> > > > Alex
> > > > 
> > > > >
> > > > > Thanks
> > > > > JimQu
> > > > >
> > > > > ________________________________________
> > > > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > > > 发送时间: 2018年7月9日 17:27
> > > > > 收件人: Qu, Jim
> > > > > 抄送: alsa-devel@alsa-project.org; 
> > > > > dri-devel@lists.freedesktop.org; Deucher, Alexander; 
> > > > > amd-gfx@lists.freedesktop.org
> > > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to 
> > > > > bound gpu client id
> > > > >
> > > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > > > >> Now, I found the audio device will auto suspend even if the gpu 
> > > > >> is active, and if I plug in a HDMI device it also do not resume back.
> > > > >>
> > > > >> 1. Did you encounter similar issue before?
> > > > >> 2. audio will auto suspend as default at beginning of boot, is 
> > > > >> it expect behaviour?
> > > > >
> > > > > Yes, that's expected.  Once you start streaming audio to 
> > > > > attached displays, user space opens the codec device and this 
> > > > > causes the HDA controller to runtime resume.  If the discrete 
> > > > > GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user 
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime 
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a 
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the 
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lukas
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > _______________________________________________
> > > > Alsa-devel mailing list
> > > > Alsa-devel@alsa-project.org
> > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

[-- Attachment #1: Type: text/plain, Size: 7720 bytes --]

Hi Takashi,

I am not expert in audio driver, so I just update some test result, please help triage the issue.

With audio runtime pm:

1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.

Without audio runtime pm:
1. pactl can get available audio output/sink
2. can get eld info from eld#0.1

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period. Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.

Thanks
JimQu

________________________________________
发件人: Takashi Iwai <tiwai@suse.de>
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
主题: Re: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:
>
> Hi Takashi,
>
> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
>
> Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
>
> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi

>
> Thanks
> JimQu
>
> -----邮件原件-----
> 发件人: Takashi Iwai <tiwai@suse.de>
> 发送时间: 2018年7月9日 23:58
> 收件人: Daniel Vetter <daniel@ffwll.ch>
> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>
> On Mon, 09 Jul 2018 17:56:43 +0200,
> Daniel Vetter wrote:
> >
> > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > Alex Deucher wrote:
> > > >
> > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > > Hi Lukas,
> > > > >
> > > > > Thanks to your explanation, and see comments in line.
> > > > >
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > >
> > > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > > >
> > > > On the gfx side at least, we can get a hotplug event via ACPI
> > > > (depending on the OEM design) if displays are attached/detached
> > > > while the dGPU is powered down.  I suppose the gfx driver could
> > > > call into the audio driver during one of those events.  On the gfx
> > > > side at least we just generate the gfx hotplug event and let userspace deal with it.
> > >
> > > IMO, a more proper way would be to have the direct communication
> > > between the graphics driver and the audio driver like i915 driver
> > > does.  Then the audio driver can get plug/unplug event at more
> > > accurate timing without races.
> > >
> > > (Though, it will cause another mess wrt the weak module dependency,
> > > but it's another story :)
> >
> > Just don't do what snd-hda-intel did and instead implement the
> > component stuff properly :-)
>
> A patch is welcome :)
>
>
> thanks,
>
> Takashi
>
> > -Daniel
> >
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> > >
> > >
> > > >
> > > > Alex
> > > >
> > > > >
> > > > > Thanks
> > > > > JimQu
> > > > >
> > > > > ________________________________________
> > > > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > > > 发送时间: 2018年7月9日 17:27
> > > > > 收件人: Qu, Jim
> > > > > 抄送: alsa-devel@alsa-project.org;
> > > > > dri-devel@lists.freedesktop.org; Deucher, Alexander;
> > > > > amd-gfx@lists.freedesktop.org
> > > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to
> > > > > bound gpu client id
> > > > >
> > > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > > > >> Now, I found the audio device will auto suspend even if the gpu
> > > > >> is active, and if I plug in a HDMI device it also do not resume back.
> > > > >>
> > > > >> 1. Did you encounter similar issue before?
> > > > >> 2. audio will auto suspend as default at beginning of boot, is
> > > > >> it expect behaviour?
> > > > >
> > > > > Yes, that's expected.  Once you start streaming audio to
> > > > > attached displays, user space opens the codec device and this
> > > > > causes the HDA controller to runtime resume.  If the discrete
> > > > > GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lukas
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > _______________________________________________
> > > > Alsa-devel mailing list
> > > > Alsa-devel@alsa-project.org
> > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >

[-- Attachment #2: pactl_with_runtimepm --]
[-- Type: application/octet-stream, Size: 4474 bytes --]

~$ pactl list cards
Card #0
	Name: alsa_card.pci-0000_06_00.1
	Driver: module-alsa-card.c
	Owner Module: 6
	Properties:
		alsa.card = "0"
		alsa.card_name = "HD-Audio Generic"
		alsa.long_card_name = "HD-Audio Generic at 0xe0b88000 irq 61"
		alsa.driver_name = "snd_hda_intel"
		device.bus_path = "pci-0000:06:00.1"
		sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:06:00.1/sound/card0"
		device.bus = "pci"
		device.vendor.id = "1002"
		device.vendor.name = "Advanced Micro Devices, Inc. [AMD/ATI]"
		device.product.id = "15de"
		device.string = "0"
		device.description = "HD-Audio Generic"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-pci"
	Profiles:
		output:hdmi-stereo: Digital Stereo (HDMI) Output (sinks: 1, sources: 0, priority: 5400, available: no)
		output:hdmi-surround: Digital Surround 5.1 (HDMI) Output (sinks: 1, sources: 0, priority: 300, available: no)
		output:hdmi-surround71: Digital Surround 7.1 (HDMI) Output (sinks: 1, sources: 0, priority: 300, available: no)
		output:hdmi-stereo-extra1: Digital Stereo (HDMI 2) Output (sinks: 1, sources: 0, priority: 5200, available: no)
		output:hdmi-surround-extra1: Digital Surround 5.1 (HDMI 2) Output (sinks: 1, sources: 0, priority: 100, available: no)
		output:hdmi-surround71-extra1: Digital Surround 7.1 (HDMI 2) Output (sinks: 1, sources: 0, priority: 100, available: no)
		output:hdmi-stereo-extra2: Digital Stereo (HDMI 3) Output (sinks: 1, sources: 0, priority: 5200, available: no)
		output:hdmi-surround-extra2: Digital Surround 5.1 (HDMI 3) Output (sinks: 1, sources: 0, priority: 100, available: no)
		output:hdmi-surround71-extra2: Digital Surround 7.1 (HDMI 3) Output (sinks: 1, sources: 0, priority: 100, available: no)
		off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
	Active Profile: output:hdmi-stereo-extra1
	Ports:
		hdmi-output-0: HDMI / DisplayPort (priority: 5900, latency offset: 0 usec, not available)
			Properties:
				device.icon_name = "video-display"
			Part of profile(s): output:hdmi-stereo, output:hdmi-surround, output:hdmi-surround71
		hdmi-output-1: HDMI / DisplayPort 2 (priority: 5800, latency offset: 0 usec, not available)
			Properties:
				device.icon_name = "video-display"
			Part of profile(s): output:hdmi-stereo-extra1, output:hdmi-surround-extra1, output:hdmi-surround71-extra1
		hdmi-output-2: HDMI / DisplayPort 3 (priority: 5700, latency offset: 0 usec, not available)
			Properties:
				device.icon_name = "video-display"
			Part of profile(s): output:hdmi-stereo-extra2, output:hdmi-surround-extra2, output:hdmi-surround71-extra2
pactl list sinks
Sink #0
	State: SUSPENDED
	Name: alsa_output.pci-0000_06_00.1.hdmi-stereo-extra1
	Description: HD-Audio Generic Digital Stereo (HDMI 2)
	Driver: module-alsa-card.c
	Sample Specification: s16le 2ch 44100Hz
	Channel Map: front-left,front-right
	Owner Module: 6
	Mute: no
	Volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
	        balance 0.00
	Base Volume: 65536 / 100% / 0.00 dB
	Monitor Source: alsa_output.pci-0000_06_00.1.hdmi-stereo-extra1.monitor
	Latency: 0 usec, configured 0 usec
	Flags: HARDWARE DECIBEL_VOLUME LATENCY SET_FORMATS 
	Properties:
		alsa.resolution_bits = "16"
		device.api = "alsa"
		device.class = "sound"
		alsa.class = "generic"
		alsa.subclass = "generic-mix"
		alsa.name = "HDMI 1"
		alsa.id = "HDMI 1"
		alsa.subdevice = "0"
		alsa.subdevice_name = "subdevice #0"
		alsa.device = "7"
		alsa.card = "0"
		alsa.card_name = "HD-Audio Generic"
		alsa.long_card_name = "HD-Audio Generic at 0xe0b88000 irq 61"
		alsa.driver_name = "snd_hda_intel"
		device.bus_path = "pci-0000:06:00.1"
		sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:06:00.1/sound/card0"
		device.bus = "pci"
		device.vendor.id = "1002"
		device.vendor.name = "Advanced Micro Devices, Inc. [AMD/ATI]"
		device.product.id = "15de"
		device.string = "hdmi:0,1"
		device.buffering.buffer_size = "65536"
		device.buffering.fragment_size = "32768"
		device.access_mode = "mmap+timer"
		device.profile.name = "hdmi-stereo-extra1"
		device.profile.description = "Digital Stereo (HDMI 2)"
		device.description = "HD-Audio Generic Digital Stereo (HDMI 2)"
		alsa.mixer_name = "ATI R6xx HDMI"
		alsa.components = "HDA:1002aa01,00aa0100,00100700"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-pci"
	Ports:
		hdmi-output-1: HDMI / DisplayPort 2 (priority: 5800, not available)
	Active Port: hdmi-output-1
	Formats:
		pcm


[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Qu, Jim]

Sorry, correct the typo.

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period. Therefore, upper software could not get HDMI ELD info, it can not select an available card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.

Thanks
JimQu

________________________________________
发件人: Qu, Jim
发送时间: 2018年7月10日 15:44:42
收件人: Takashi Iwai
抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
主题: 答复: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

Hi Takashi,

I am not expert in audio driver, so I just update some test result, please help triage the issue.

With audio runtime pm:

1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
2. cat /proc/asound/card0/eld* can get nothing.

Without audio runtime pm:
1. pactl can get available audio output/sink
2. can get eld info from eld#0.1

IMO, the issue should be:

Current operations like HDMI hotplug in/out, pactl command, they do not access audio HW, so the audio could not resume back at this period. Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.

Thanks
JimQu

________________________________________
发件人: Takashi Iwai <tiwai@suse.de>
发送时间: 2018年7月10日 1:09
收件人: Qu, Jim
抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
主题: Re: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

On Mon, 09 Jul 2018 18:05:09 +0200,
Qu, Jim wrote:
>
> Hi Takashi,
>
> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
>
> Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
>
> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.

OK, and it has all necessary patches including the one Lukas
suggested, right?

If so, figure out what you're actually seeing as "PA could not detect
HDMI audio".  For example, is it the HDMI (jack) detection (giving
false even if it's connected)?  Or is it an error at opening the given
device? Does the driver give the proper ELD bytes as well as the jack
state?


Takashi

>
> Thanks
> JimQu
>
> -----邮件原件-----
> 发件人: Takashi Iwai <tiwai@suse.de>
> 发送时间: 2018年7月9日 23:58
> 收件人: Daniel Vetter <daniel@ffwll.ch>
> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>
> On Mon, 09 Jul 2018 17:56:43 +0200,
> Daniel Vetter wrote:
> >
> > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > Alex Deucher wrote:
> > > >
> > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > > Hi Lukas,
> > > > >
> > > > > Thanks to your explanation, and see comments in line.
> > > > >
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > >
> > > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > > >
> > > > On the gfx side at least, we can get a hotplug event via ACPI
> > > > (depending on the OEM design) if displays are attached/detached
> > > > while the dGPU is powered down.  I suppose the gfx driver could
> > > > call into the audio driver during one of those events.  On the gfx
> > > > side at least we just generate the gfx hotplug event and let userspace deal with it.
> > >
> > > IMO, a more proper way would be to have the direct communication
> > > between the graphics driver and the audio driver like i915 driver
> > > does.  Then the audio driver can get plug/unplug event at more
> > > accurate timing without races.
> > >
> > > (Though, it will cause another mess wrt the weak module dependency,
> > > but it's another story :)
> >
> > Just don't do what snd-hda-intel did and instead implement the
> > component stuff properly :-)
>
> A patch is welcome :)
>
>
> thanks,
>
> Takashi
>
> > -Daniel
> >
> > >
> > >
> > > thanks,
> > >
> > > Takashi
> > >
> > >
> > > >
> > > > Alex
> > > >
> > > > >
> > > > > Thanks
> > > > > JimQu
> > > > >
> > > > > ________________________________________
> > > > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > > > 发送时间: 2018年7月9日 17:27
> > > > > 收件人: Qu, Jim
> > > > > 抄送: alsa-devel@alsa-project.org;
> > > > > dri-devel@lists.freedesktop.org; Deucher, Alexander;
> > > > > amd-gfx@lists.freedesktop.org
> > > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to
> > > > > bound gpu client id
> > > > >
> > > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > > > >> Now, I found the audio device will auto suspend even if the gpu
> > > > >> is active, and if I plug in a HDMI device it also do not resume back.
> > > > >>
> > > > >> 1. Did you encounter similar issue before?
> > > > >> 2. audio will auto suspend as default at beginning of boot, is
> > > > >> it expect behaviour?
> > > > >
> > > > > Yes, that's expected.  Once you start streaming audio to
> > > > > attached displays, user space opens the codec device and this
> > > > > causes the HDA controller to runtime resume.  If the discrete
> > > > > GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
> > > > >
> > > > > Do you need to runtime resume the HDA controller even if user
> > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > >
> > > > > You're saying above that the HDA controller isn't runtime
> > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lukas
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > dri-devel@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > _______________________________________________
> > > > Alsa-devel mailing list
> > > > Alsa-devel@alsa-project.org
> > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 09:44:42 +0200,
Qu, Jim wrote:
> 
> Hi Takashi,
> 
> I am not expert in audio driver, so I just update some test result, please help triage the issue.
> 
> With audio runtime pm:

What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
Please clarify your test environment at first: which kernel, which
hardware setup.

> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
> 2. cat /proc/asound/card0/eld* can get nothing.
> 
> Without audio runtime pm:
> 1. pactl can get available audio output/sink
> 2. can get eld info from eld#0.1
> 
> IMO, the issue should be:
> 
> Current operations like HDMI hotplug in/out, pactl command, they do
> not access audio HW, so the audio could not resume back at this
> period.

Sorry, not understood.  Why they don't access the audio hardware?

> Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
> I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.

As long as it's i915 and HD-audio, the hotplug and ELD info transfer
doesn't trigger the runtime PM since it's done via the direct
callback.  And ELD value is cached in HD-audio side.

The exception is that if the notification is done during the PM
operation.  But, the connection and ELD query is performed at the end
of codec resume, hence it'll be covered there.

So in theory, ELD information should be passed from the GPU to
HD-audio no matter whether runtime PM is enabled or not.


BTW, please stop top-posting.  It makes the thread readability awfully
worse.


thanks,

Takashi

> 
> Thanks
> JimQu
> 
> ________________________________________
> 发件人: Takashi Iwai <tiwai@suse.de>
> 发送时间: 2018年7月10日 1:09
> 收件人: Qu, Jim
> 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
> 主题: Re: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> 
> On Mon, 09 Jul 2018 18:05:09 +0200,
> Qu, Jim wrote:
> >
> > Hi Takashi,
> >
> > Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
> >
> > Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
> >
> > Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.
> 
> OK, and it has all necessary patches including the one Lukas
> suggested, right?
> 
> If so, figure out what you're actually seeing as "PA could not detect
> HDMI audio".  For example, is it the HDMI (jack) detection (giving
> false even if it's connected)?  Or is it an error at opening the given
> device? Does the driver give the proper ELD bytes as well as the jack
> state?
> 
> 
> Takashi
> 
> >
> > Thanks
> > JimQu
> >
> > -----邮件原件-----
> > 发件人: Takashi Iwai <tiwai@suse.de>
> > 发送时间: 2018年7月9日 23:58
> > 收件人: Daniel Vetter <daniel@ffwll.ch>
> > 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> > 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> >
> > On Mon, 09 Jul 2018 17:56:43 +0200,
> > Daniel Vetter wrote:
> > >
> > > On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> > > > On Mon, 09 Jul 2018 15:58:51 +0200,
> > > > Alex Deucher wrote:
> > > > >
> > > > > On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > > > > > Hi Lukas,
> > > > > >
> > > > > > Thanks to your explanation, and see comments in line.
> > > > > >
> > > > > >
> > > > > > Do you need to runtime resume the HDA controller even if user
> > > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > > >
> > > > > > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> > > > > >
> > > > > > You're saying above that the HDA controller isn't runtime
> > > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > > >
> > > > > > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> > > > >
> > > > > On the gfx side at least, we can get a hotplug event via ACPI
> > > > > (depending on the OEM design) if displays are attached/detached
> > > > > while the dGPU is powered down.  I suppose the gfx driver could
> > > > > call into the audio driver during one of those events.  On the gfx
> > > > > side at least we just generate the gfx hotplug event and let userspace deal with it.
> > > >
> > > > IMO, a more proper way would be to have the direct communication
> > > > between the graphics driver and the audio driver like i915 driver
> > > > does.  Then the audio driver can get plug/unplug event at more
> > > > accurate timing without races.
> > > >
> > > > (Though, it will cause another mess wrt the weak module dependency,
> > > > but it's another story :)
> > >
> > > Just don't do what snd-hda-intel did and instead implement the
> > > component stuff properly :-)
> >
> > A patch is welcome :)
> >
> >
> > thanks,
> >
> > Takashi
> >
> > > -Daniel
> > >
> > > >
> > > >
> > > > thanks,
> > > >
> > > > Takashi
> > > >
> > > >
> > > > >
> > > > > Alex
> > > > >
> > > > > >
> > > > > > Thanks
> > > > > > JimQu
> > > > > >
> > > > > > ________________________________________
> > > > > > 发件人: Lukas Wunner <lukas@wunner.de>
> > > > > > 发送时间: 2018年7月9日 17:27
> > > > > > 收件人: Qu, Jim
> > > > > > 抄送: alsa-devel@alsa-project.org;
> > > > > > dri-devel@lists.freedesktop.org; Deucher, Alexander;
> > > > > > amd-gfx@lists.freedesktop.org
> > > > > > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to
> > > > > > bound gpu client id
> > > > > >
> > > > > > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> > > > > >> Now, I found the audio device will auto suspend even if the gpu
> > > > > >> is active, and if I plug in a HDMI device it also do not resume back.
> > > > > >>
> > > > > >> 1. Did you encounter similar issue before?
> > > > > >> 2. audio will auto suspend as default at beginning of boot, is
> > > > > >> it expect behaviour?
> > > > > >
> > > > > > Yes, that's expected.  Once you start streaming audio to
> > > > > > attached displays, user space opens the codec device and this
> > > > > > causes the HDA controller to runtime resume.  If the discrete
> > > > > > GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
> > > > > >
> > > > > > Do you need to runtime resume the HDA controller even if user
> > > > > > space isn't streaming audio?  Why, and in which situation exactly?
> > > > > >
> > > > > > You're saying above that the HDA controller isn't runtime
> > > > > > resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> > > > > > I'm not sure if there's code in the HDA driver to acquire a
> > > > > > runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> > > > > > code is there but somehow no HPD interrupt is received by the HDA driver?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Lukas
> > > > > > _______________________________________________
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > > _______________________________________________
> > > > > Alsa-devel mailing list
> > > > > Alsa-devel@alsa-project.org
> > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > >
> [2 pactl_with_runtimepm <application/octet-stream (base64)>]
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

[-- Attachment #1.1: Type: text/plain, Size: 9758 bytes --]



On 2018年07月10日 16:01, Takashi Iwai wrote:
> On Tue, 10 Jul 2018 09:44:42 +0200,
> Qu, Jim wrote:
>> Hi Takashi,
>>
>> I am not expert in audio driver, so I just update some test result, please help triage the issue.
>>
>> With audio runtime pm:
> What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
> Please clarify your test environment at first: which kernel, which
> hardware setup.
>
This is v4.15 which backport Lukas' patches and also one bug fix 
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX 
platform. In generic, dGPU will always be suspended.
>> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
>> 2. cat /proc/asound/card0/eld* can get nothing.
>>
>> Without audio runtime pm:
>> 1. pactl can get available audio output/sink
>> 2. can get eld info from eld#0.1
>>
>> IMO, the issue should be:
>>
>> Current operations like HDMI hotplug in/out, pactl command, they do
>> not access audio HW, so the audio could not resume back at this
>> period.
> Sorry, not understood.  Why they don't access the audio hardware?
This is my guess, since I do not get azx_runtime_resume() print info 
which I added. it maybe access HW during this period, but do not trigger 
audio resume progress.
<https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume>
>> Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
>> I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
> As long as it's i915 and HD-audio, the hotplug and ELD info transfer
> doesn't trigger the runtime PM since it's done via the direct
> callback.  And ELD value is cached in HD-audio side.
Yeah, I have reviewed these code, it constructs ELD after reading EDID, 
and write them into HW buffer when set display mode.
> The exception is that if the notification is done during the PM
> operation.  But, the connection and ELD query is performed at the end
> of codec resume, hence it'll be covered there.
>
> So in theory, ELD information should be passed from the GPU to
> HD-audio no matter whether runtime PM is enabled or not.
>
>
> BTW, please stop top-posting.  It makes the thread readability awfully
> worse.
>
Sorry, I justed used outlook client.
> thanks,
>
> Takashi
>
>> Thanks
>> JimQu
>>
>> ________________________________________
>> 发件人: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
>> 发送时间: 2018年7月10日 1:09
>> 收件人: Qu, Jim
>> 抄送: Daniel Vetter; Alex Deucher; alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; Deucher, Alexander
>> 主题: Re: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>>
>> On Mon, 09 Jul 2018 18:05:09 +0200,
>> Qu, Jim wrote:
>>> Hi Takashi,
>>>
>>> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
>>>
>>> Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
>>>
>>> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.
>> OK, and it has all necessary patches including the one Lukas
>> suggested, right?
>>
>> If so, figure out what you're actually seeing as "PA could not detect
>> HDMI audio".  For example, is it the HDMI (jack) detection (giving
>> false even if it's connected)?  Or is it an error at opening the given
>> device? Does the driver give the proper ELD bytes as well as the jack
>> state?
>>
>>
>> Takashi
>>
>>> Thanks
>>> JimQu
>>>
>>> -----邮件原件-----
>>> 发件人: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
>>> 发送时间: 2018年7月9日 23:58
>>> 收件人: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
>>> 抄送: Alex Deucher <alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org; amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; Qu, Jim <Jim.Qu-5C7GfCeVMHo@public.gmane.org>; dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; Deucher, Alexander <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>
>>> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>>>
>>> On Mon, 09 Jul 2018 17:56:43 +0200,
>>> Daniel Vetter wrote:
>>>> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
>>>>> On Mon, 09 Jul 2018 15:58:51 +0200,
>>>>> Alex Deucher wrote:
>>>>>> On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu-5C7GfCeVMHo@public.gmane.org> wrote:
>>>>>>> Hi Lukas,
>>>>>>>
>>>>>>> Thanks to your explanation, and see comments in line.
>>>>>>>
>>>>>>>
>>>>>>> Do you need to runtime resume the HDA controller even if user
>>>>>>> space isn't streaming audio?  Why, and in which situation exactly?
>>>>>>>
>>>>>>> Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
>>>>>>>
>>>>>>> You're saying above that the HDA controller isn't runtime
>>>>>>> resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
>>>>>>> I'm not sure if there's code in the HDA driver to acquire a
>>>>>>> runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
>>>>>>> code is there but somehow no HPD interrupt is received by the HDA driver?
>>>>>>>
>>>>>>> Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
>>>>>> On the gfx side at least, we can get a hotplug event via ACPI
>>>>>> (depending on the OEM design) if displays are attached/detached
>>>>>> while the dGPU is powered down.  I suppose the gfx driver could
>>>>>> call into the audio driver during one of those events.  On the gfx
>>>>>> side at least we just generate the gfx hotplug event and let userspace deal with it.
>>>>> IMO, a more proper way would be to have the direct communication
>>>>> between the graphics driver and the audio driver like i915 driver
>>>>> does.  Then the audio driver can get plug/unplug event at more
>>>>> accurate timing without races.
>>>>>
>>>>> (Though, it will cause another mess wrt the weak module dependency,
>>>>> but it's another story :)
>>>> Just don't do what snd-hda-intel did and instead implement the
>>>> component stuff properly :-)
>>> A patch is welcome :)
>>>
>>>
>>> thanks,
>>>
>>> Takashi
>>>
>>>> -Daniel
>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>
>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> Thanks
>>>>>>> JimQu
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> 发件人: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
>>>>>>> 发送时间: 2018年7月9日 17:27
>>>>>>> 收件人: Qu, Jim
>>>>>>> 抄送: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org;
>>>>>>> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org; Deucher, Alexander;
>>>>>>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>>>>>> 主题: Re: [PATCH] vgaswitchroo: set audio client id according to
>>>>>>> bound gpu client id
>>>>>>>
>>>>>>> On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
>>>>>>>> Now, I found the audio device will auto suspend even if the gpu
>>>>>>>> is active, and if I plug in a HDMI device it also do not resume back.
>>>>>>>>
>>>>>>>> 1. Did you encounter similar issue before?
>>>>>>>> 2. audio will auto suspend as default at beginning of boot, is
>>>>>>>> it expect behaviour?
>>>>>>> Yes, that's expected.  Once you start streaming audio to
>>>>>>> attached displays, user space opens the codec device and this
>>>>>>> causes the HDA controller to runtime resume.  If the discrete
>>>>>>> GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
>>>>>>>
>>>>>>> Do you need to runtime resume the HDA controller even if user
>>>>>>> space isn't streaming audio?  Why, and in which situation exactly?
>>>>>>>
>>>>>>> You're saying above that the HDA controller isn't runtime
>>>>>>> resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
>>>>>>> I'm not sure if there's code in the HDA driver to acquire a
>>>>>>> runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
>>>>>>> code is there but somehow no HPD interrupt is received by the HDA driver?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Lukas
>>>>>>> _______________________________________________
>>>>>>> dri-devel mailing list
>>>>>>> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>>> _______________________________________________
>>>>>> Alsa-devel mailing list
>>>>>> Alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org
>>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>> _______________________________________________
>>>>> dri-devel mailing list
>>>>> dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>> --
>>>> Daniel Vetter
>>>> Software Engineer, Intel Corporation
>>>> http://blog.ffwll.ch
>>>>
>> [2 pactl_with_runtimepm <application/octet-stream (base64)>]
>>


[-- Attachment #1.2: Type: text/html, Size: 14230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 11:13:27 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月10日 16:01, Takashi Iwai wrote:
> > On Tue, 10 Jul 2018 09:44:42 +0200,
> > Qu, Jim wrote:
> >> Hi Takashi,
> >>
> >> I am not expert in audio driver, so I just update some test result, please help triage the issue.
> >>
> >> With audio runtime pm:
> > What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
> > Please clarify your test environment at first: which kernel, which
> > hardware setup.
> >
> This is v4.15 which backport Lukas' patches and also one bug fix
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
> The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX
> platform. In generic, dGPU will always be suspended.

Ah, so it's AMD+AMD, not Intel+AMD combo.  Now I understand the
situation better, thanks.

> >> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
> >> 2. cat /proc/asound/card0/eld* can get nothing.
> >>
> >> Without audio runtime pm:
> >> 1. pactl can get available audio output/sink
> >> 2. can get eld info from eld#0.1
> >>
> >> IMO, the issue should be:
> >>
> >> Current operations like HDMI hotplug in/out, pactl command, they do
> >> not access audio HW, so the audio could not resume back at this
> >> period.
> > Sorry, not understood.  Why they don't access the audio hardware?
> This is my guess, since I do not get azx_runtime_resume() print info
> which I added. it maybe access HW during this period, but do not
> trigger audio resume progress.
> <https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume>
> >> Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
> >> I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
> > As long as it's i915 and HD-audio, the hotplug and ELD info transfer
> > doesn't trigger the runtime PM since it's done via the direct
> > callback.  And ELD value is cached in HD-audio side.
> Yeah, I have reviewed these code, it constructs ELD after reading
> EDID, and write them into HW buffer when set display mode.

If the controller chip supports "wake-enable" feature (HD-audio WAKEEN
register), it could be woken up at unsolicited event even during the
link power down.  But, your report implies that AMD controller doesn't
do this, or something missing there.  That's the likely cause of the
missing hotplug event.

So, if my understanding is right, the situation won't be different
even if you have a single AMD GPU.  And possibly a side-effect of the
latest fix to force link-down for AMD GPU.  Need to check it...


Takashi

> > The exception is that if the notification is done during the PM
> > operation.  But, the connection and ELD query is performed at the end
> > of codec resume, hence it'll be covered there.
> >
> > So in theory, ELD information should be passed from the GPU to
> > HD-audio no matter whether runtime PM is enabled or not.
> >
> >
> > BTW, please stop top-posting.  It makes the thread readability awfully
> > worse.
> >
> Sorry, I justed used outlook client.
> > thanks,
> >
> > Takashi
> >
> >> Thanks
> >> JimQu
> >>
> >> ________________________________________
> >> 发件人: Takashi Iwai <tiwai@suse.de>
> >> 发送时间: 2018年7月10日 1:09
> >> 收件人: Qu, Jim
> >> 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
> >> 主题: Re: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> >>
> >> On Mon, 09 Jul 2018 18:05:09 +0200,
> >> Qu, Jim wrote:
> >>> Hi Takashi,
> >>>
> >>> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
> >>>
> >>> Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
> >>>
> >>> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.
> >> OK, and it has all necessary patches including the one Lukas
> >> suggested, right?
> >>
> >> If so, figure out what you're actually seeing as "PA could not detect
> >> HDMI audio".  For example, is it the HDMI (jack) detection (giving
> >> false even if it's connected)?  Or is it an error at opening the given
> >> device? Does the driver give the proper ELD bytes as well as the jack
> >> state?
> >>
> >>
> >> Takashi
> >>
> >>> Thanks
> >>> JimQu
> >>>
> >>> -----邮件原件-----
> >>> 发件人: Takashi Iwai <tiwai@suse.de>
> >>> 发送时间: 2018年7月9日 23:58
> >>> 收件人: Daniel Vetter <daniel@ffwll.ch>
> >>> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
> >>> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> >>>
> >>> On Mon, 09 Jul 2018 17:56:43 +0200,
> >>> Daniel Vetter wrote:
> >>>> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
> >>>>> On Mon, 09 Jul 2018 15:58:51 +0200,
> >>>>> Alex Deucher wrote:
> >>>>>> On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> >>>>>>> Hi Lukas,
> >>>>>>>
> >>>>>>> Thanks to your explanation, and see comments in line.
> >>>>>>>
> >>>>>>>
> >>>>>>> Do you need to runtime resume the HDA controller even if user
> >>>>>>> space isn't streaming audio?  Why, and in which situation exactly?
> >>>>>>>
> >>>>>>> Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> >>>>>>>
> >>>>>>> You're saying above that the HDA controller isn't runtime
> >>>>>>> resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> >>>>>>> I'm not sure if there's code in the HDA driver to acquire a
> >>>>>>> runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> >>>>>>> code is there but somehow no HPD interrupt is received by the HDA driver?
> >>>>>>>
> >>>>>>> Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> >>>>>> On the gfx side at least, we can get a hotplug event via ACPI
> >>>>>> (depending on the OEM design) if displays are attached/detached
> >>>>>> while the dGPU is powered down.  I suppose the gfx driver could
> >>>>>> call into the audio driver during one of those events.  On the gfx
> >>>>>> side at least we just generate the gfx hotplug event and let userspace deal with it.
> >>>>> IMO, a more proper way would be to have the direct communication
> >>>>> between the graphics driver and the audio driver like i915 driver
> >>>>> does.  Then the audio driver can get plug/unplug event at more
> >>>>> accurate timing without races.
> >>>>>
> >>>>> (Though, it will cause another mess wrt the weak module dependency,
> >>>>> but it's another story :)
> >>>> Just don't do what snd-hda-intel did and instead implement the
> >>>> component stuff properly :-)
> >>> A patch is welcome :)
> >>>
> >>>
> >>> thanks,
> >>>
> >>> Takashi
> >>>
> >>>> -Daniel
> >>>>
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> Takashi
> >>>>>
> >>>>>
> >>>>>> Alex
> >>>>>>
> >>>>>>> Thanks
> >>>>>>> JimQu
> >>>>>>>
> >>>>>>> ________________________________________
> >>>>>>> 发件人: Lukas Wunner <lukas@wunner.de>
> >>>>>>> 发送时间: 2018年7月9日 17:27
> >>>>>>> 收件人: Qu, Jim
> >>>>>>> 抄送: alsa-devel@alsa-project.org;
> >>>>>>> dri-devel@lists.freedesktop.org; Deucher, Alexander;
> >>>>>>> amd-gfx@lists.freedesktop.org
> >>>>>>> 主题: Re: [PATCH] vgaswitchroo: set audio client id according to
> >>>>>>> bound gpu client id
> >>>>>>>
> >>>>>>> On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> >>>>>>>> Now, I found the audio device will auto suspend even if the gpu
> >>>>>>>> is active, and if I plug in a HDMI device it also do not resume back.
> >>>>>>>>
> >>>>>>>> 1. Did you encounter similar issue before?
> >>>>>>>> 2. audio will auto suspend as default at beginning of boot, is
> >>>>>>>> it expect behaviour?
> >>>>>>> Yes, that's expected.  Once you start streaming audio to
> >>>>>>> attached displays, user space opens the codec device and this
> >>>>>>> causes the HDA controller to runtime resume.  If the discrete
> >>>>>>> GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
> >>>>>>>
> >>>>>>> Do you need to runtime resume the HDA controller even if user
> >>>>>>> space isn't streaming audio?  Why, and in which situation exactly?
> >>>>>>>
> >>>>>>> You're saying above that the HDA controller isn't runtime
> >>>>>>> resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
> >>>>>>> I'm not sure if there's code in the HDA driver to acquire a
> >>>>>>> runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
> >>>>>>> code is there but somehow no HPD interrupt is received by the HDA driver?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Lukas
> >>>>>>> _______________________________________________
> >>>>>>> dri-devel mailing list
> >>>>>>> dri-devel@lists.freedesktop.org
> >>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>>>>> _______________________________________________
> >>>>>> Alsa-devel mailing list
> >>>>>> Alsa-devel@alsa-project.org
> >>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >>>>> _______________________________________________
> >>>>> dri-devel mailing list
> >>>>> dri-devel@lists.freedesktop.org
> >>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >>>> --
> >>>> Daniel Vetter
> >>>> Software Engineer, Intel Corporation
> >>>> http://blog.ffwll.ch
> >>>>
> >> [2 pactl_with_runtimepm <application/octet-stream (base64)>]
> >>
> 
> [2  <text/html; utf-8 (8bit)>]
> 
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

On 2018年07月10日 17:50, Takashi Iwai wrote:
> On Tue, 10 Jul 2018 11:13:27 +0200,
> jimqu wrote:
>>
>>
>> On 2018年07月10日 16:01, Takashi Iwai wrote:
>>> On Tue, 10 Jul 2018 09:44:42 +0200,
>>> Qu, Jim wrote:
>>>> Hi Takashi,
>>>>
>>>> I am not expert in audio driver, so I just update some test result, please help triage the issue.
>>>>
>>>> With audio runtime pm:
>>> What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
>>> Please clarify your test environment at first: which kernel, which
>>> hardware setup.
>>>
>> This is v4.15 which backport Lukas' patches and also one bug fix
>> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
>> The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX
>> platform. In generic, dGPU will always be suspended.
> Ah, so it's AMD+AMD, not Intel+AMD combo.  Now I understand the
> situation better, thanks.
>
>>>> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
>>>> 2. cat /proc/asound/card0/eld* can get nothing.
>>>>
>>>> Without audio runtime pm:
>>>> 1. pactl can get available audio output/sink
>>>> 2. can get eld info from eld#0.1
>>>>
>>>> IMO, the issue should be:
>>>>
>>>> Current operations like HDMI hotplug in/out, pactl command, they do
>>>> not access audio HW, so the audio could not resume back at this
>>>> period.
>>> Sorry, not understood.  Why they don't access the audio hardware?
>> This is my guess, since I do not get azx_runtime_resume() print info
>> which I added. it maybe access HW during this period, but do not
>> trigger audio resume progress.
>> <https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume>
>>>> Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
>>>> I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
>>> As long as it's i915 and HD-audio, the hotplug and ELD info transfer
>>> doesn't trigger the runtime PM since it's done via the direct
>>> callback.  And ELD value is cached in HD-audio side.
>> Yeah, I have reviewed these code, it constructs ELD after reading
>> EDID, and write them into HW buffer when set display mode.
> If the controller chip supports "wake-enable" feature (HD-audio WAKEEN
> register), it could be woken up at unsolicited event even during the
> link power down.  But, your report implies that AMD controller doesn't
> do this, or something missing there.  That's the likely cause of the
> missing hotplug event.

Is there any method to confirm it?
> So, if my understanding is right, the situation won't be different
> even if you have a single AMD GPU.  And possibly a side-effect of the
> latest fix to force link-down for AMD GPU.  Need to check it...

Before Lukas' patches, it is relative with dGPU, because audio power is 
controlled by vgaswitchreroo and GFX driver, but now it won't.
revert the fix of amdgpu suspend issue, audio issue also can be observed.
>
> Takashi
>
>>> The exception is that if the notification is done during the PM
>>> operation.  But, the connection and ELD query is performed at the end
>>> of codec resume, hence it'll be covered there.
>>>
>>> So in theory, ELD information should be passed from the GPU to
>>> HD-audio no matter whether runtime PM is enabled or not.
>>>
>>>
>>> BTW, please stop top-posting.  It makes the thread readability awfully
>>> worse.
>>>
>> Sorry, I justed used outlook client.
>>> thanks,
>>>
>>> Takashi
>>>
>>>> Thanks
>>>> JimQu
>>>>
>>>> ________________________________________
>>>> 发件人: Takashi Iwai <tiwai@suse.de>
>>>> 发送时间: 2018年7月10日 1:09
>>>> 收件人: Qu, Jim
>>>> 抄送: Daniel Vetter; Alex Deucher; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher, Alexander
>>>> 主题: Re: 答复: [alsa-devel]        答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>>>>
>>>> On Mon, 09 Jul 2018 18:05:09 +0200,
>>>> Qu, Jim wrote:
>>>>> Hi Takashi,
>>>>>
>>>>> Not intel, but it is AMD APU+ AMD GFX, the APU has a local HDMI port for extension. And dGPU is only for offloading render via PRIME.
>>>>>
>>>>> Originally, the HDA driver before v4.17, there is a bug, that all the audio is set to CLIENT_DIS, so the when the dGPU suspend, the audio which is bound to iGPU will also be suspend.
>>>>>
>>>>> Now, after Lukas' patches. The audio will auto suspend. It make ubuntu audio setting could not detect HDMI audio, even if HDMI has light up.
>>>> OK, and it has all necessary patches including the one Lukas
>>>> suggested, right?
>>>>
>>>> If so, figure out what you're actually seeing as "PA could not detect
>>>> HDMI audio".  For example, is it the HDMI (jack) detection (giving
>>>> false even if it's connected)?  Or is it an error at opening the given
>>>> device? Does the driver give the proper ELD bytes as well as the jack
>>>> state?
>>>>
>>>>
>>>> Takashi
>>>>
>>>>> Thanks
>>>>> JimQu
>>>>>
>>>>> -----邮件原件-----
>>>>> 发件人: Takashi Iwai <tiwai@suse.de>
>>>>> 发送时间: 2018年7月9日 23:58
>>>>> 收件人: Daniel Vetter <daniel@ffwll.ch>
>>>>> 抄送: Alex Deucher <alexdeucher@gmail.com>; alsa-devel@alsa-project.org; amd-gfx@lists.freedesktop.org; Qu, Jim <Jim.Qu@amd.com>; dri-devel@lists.freedesktop.org; Deucher, Alexander <Alexander.Deucher@amd.com>
>>>>> 主题: Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>>>>>
>>>>> On Mon, 09 Jul 2018 17:56:43 +0200,
>>>>> Daniel Vetter wrote:
>>>>>> On Mon, Jul 09, 2018 at 05:04:22PM +0200, Takashi Iwai wrote:
>>>>>>> On Mon, 09 Jul 2018 15:58:51 +0200,
>>>>>>> Alex Deucher wrote:
>>>>>>>> On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
>>>>>>>>> Hi Lukas,
>>>>>>>>>
>>>>>>>>> Thanks to your explanation, and see comments in line.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do you need to runtime resume the HDA controller even if user
>>>>>>>>> space isn't streaming audio?  Why, and in which situation exactly?
>>>>>>>>>
>>>>>>>>> Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
>>>>>>>>>
>>>>>>>>> You're saying above that the HDA controller isn't runtime
>>>>>>>>> resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
>>>>>>>>> I'm not sure if there's code in the HDA driver to acquire a
>>>>>>>>> runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
>>>>>>>>> code is there but somehow no HPD interrupt is received by the HDA driver?
>>>>>>>>>
>>>>>>>>> Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
>>>>>>>> On the gfx side at least, we can get a hotplug event via ACPI
>>>>>>>> (depending on the OEM design) if displays are attached/detached
>>>>>>>> while the dGPU is powered down.  I suppose the gfx driver could
>>>>>>>> call into the audio driver during one of those events.  On the gfx
>>>>>>>> side at least we just generate the gfx hotplug event and let userspace deal with it.
>>>>>>> IMO, a more proper way would be to have the direct communication
>>>>>>> between the graphics driver and the audio driver like i915 driver
>>>>>>> does.  Then the audio driver can get plug/unplug event at more
>>>>>>> accurate timing without races.
>>>>>>>
>>>>>>> (Though, it will cause another mess wrt the weak module dependency,
>>>>>>> but it's another story :)
>>>>>> Just don't do what snd-hda-intel did and instead implement the
>>>>>> component stuff properly :-)
>>>>> A patch is welcome :)
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>
>>>>>> -Daniel
>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Takashi
>>>>>>>
>>>>>>>
>>>>>>>> Alex
>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> JimQu
>>>>>>>>>
>>>>>>>>> ________________________________________
>>>>>>>>> 发件人: Lukas Wunner <lukas@wunner.de>
>>>>>>>>> 发送时间: 2018年7月9日 17:27
>>>>>>>>> 收件人: Qu, Jim
>>>>>>>>> 抄送: alsa-devel@alsa-project.org;
>>>>>>>>> dri-devel@lists.freedesktop.org; Deucher, Alexander;
>>>>>>>>> amd-gfx@lists.freedesktop.org
>>>>>>>>> 主题: Re: [PATCH] vgaswitchroo: set audio client id according to
>>>>>>>>> bound gpu client id
>>>>>>>>>
>>>>>>>>> On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
>>>>>>>>>> Now, I found the audio device will auto suspend even if the gpu
>>>>>>>>>> is active, and if I plug in a HDMI device it also do not resume back.
>>>>>>>>>>
>>>>>>>>>> 1. Did you encounter similar issue before?
>>>>>>>>>> 2. audio will auto suspend as default at beginning of boot, is
>>>>>>>>>> it expect behaviour?
>>>>>>>>> Yes, that's expected.  Once you start streaming audio to
>>>>>>>>> attached displays, user space opens the codec device and this
>>>>>>>>> causes the HDA controller to runtime resume.  If the discrete
>>>>>>>>> GPU is suspended at that moment, it will be powered on and kept powered on as long as user space is streaming audio.
>>>>>>>>>
>>>>>>>>> Do you need to runtime resume the HDA controller even if user
>>>>>>>>> space isn't streaming audio?  Why, and in which situation exactly?
>>>>>>>>>
>>>>>>>>> You're saying above that the HDA controller isn't runtime
>>>>>>>>> resumed on hotplug of a display.  Is that necessary to retrieve ELD or something?
>>>>>>>>> I'm not sure if there's code in the HDA driver to acquire a
>>>>>>>>> runtime PM ref on HPD, but maybe it's necessary.  Or maybe the
>>>>>>>>> code is there but somehow no HPD interrupt is received by the HDA driver?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Lukas
>>>>>>>>> _______________________________________________
>>>>>>>>> dri-devel mailing list
>>>>>>>>> dri-devel@lists.freedesktop.org
>>>>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>>>>> _______________________________________________
>>>>>>>> Alsa-devel mailing list
>>>>>>>> Alsa-devel@alsa-project.org
>>>>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>>>> _______________________________________________
>>>>>>> dri-devel mailing list
>>>>>>> dri-devel@lists.freedesktop.org
>>>>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>>> --
>>>>>> Daniel Vetter
>>>>>> Software Engineer, Intel Corporation
>>>>>> http://blog.ffwll.ch
>>>>>>
>>>> [2 pactl_with_runtimepm <application/octet-stream (base64)>]
>>>>
>> [2  <text/html; utf-8 (8bit)>]
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 13:11:20 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月10日 17:50, Takashi Iwai wrote:
> > On Tue, 10 Jul 2018 11:13:27 +0200,
> > jimqu wrote:
> >>
> >>
> >> On 2018年07月10日 16:01, Takashi Iwai wrote:
> >>> On Tue, 10 Jul 2018 09:44:42 +0200,
> >>> Qu, Jim wrote:
> >>>> Hi Takashi,
> >>>>
> >>>> I am not expert in audio driver, so I just update some test result, please help triage the issue.
> >>>>
> >>>> With audio runtime pm:
> >>> What does this mean?  Is it the stock 4.17.x (or 4.18-rc)?
> >>> Please clarify your test environment at first: which kernel, which
> >>> hardware setup.
> >>>
> >> This is v4.15 which backport Lukas' patches and also one bug fix
> >> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=57cb54e53bdd.
> >> The platform is AMDAPU(with audio) + AMD dGPU , it is a hybird GFX
> >> platform. In generic, dGPU will always be suspended.
> > Ah, so it's AMD+AMD, not Intel+AMD combo.  Now I understand the
> > situation better, thanks.
> >
> >>>> 1. ubuntu audio setting use pactl to query audio card/output sink. Attachment is pactl output with audio runtime pm.
> >>>> 2. cat /proc/asound/card0/eld* can get nothing.
> >>>>
> >>>> Without audio runtime pm:
> >>>> 1. pactl can get available audio output/sink
> >>>> 2. can get eld info from eld#0.1
> >>>>
> >>>> IMO, the issue should be:
> >>>>
> >>>> Current operations like HDMI hotplug in/out, pactl command, they do
> >>>> not access audio HW, so the audio could not resume back at this
> >>>> period.
> >>> Sorry, not understood.  Why they don't access the audio hardware?
> >> This is my guess, since I do not get azx_runtime_resume() print info
> >> which I added. it maybe access HW during this period, but do not
> >> trigger audio resume progress.
> >> <https://elixir.bootlin.com/linux/v4.18-rc3/ident/azx_runtime_resume>
> >>>> Therefore, upper software could not get HDMI ELD info, can select a available card/output sink.
> >>>> I am also confuse that if there is no ELD info, how driver to steam audio device to wake up itself? It's sort of a chicken-or-egg question.
> >>> As long as it's i915 and HD-audio, the hotplug and ELD info transfer
> >>> doesn't trigger the runtime PM since it's done via the direct
> >>> callback.  And ELD value is cached in HD-audio side.
> >> Yeah, I have reviewed these code, it constructs ELD after reading
> >> EDID, and write them into HW buffer when set display mode.
> > If the controller chip supports "wake-enable" feature (HD-audio WAKEEN
> > register), it could be woken up at unsolicited event even during the
> > link power down.  But, your report implies that AMD controller doesn't
> > do this, or something missing there.  That's the likely cause of the
> > missing hotplug event.
> 
> Is there any method to confirm it?

The driver always sets WAKEEN bit, see azx_runtime_suspend() in
hda_intel.c.  If it still doesn't behave as expected, it means that
the feature isn't supported on that chip :)

> > So, if my understanding is right, the situation won't be different
> > even if you have a single AMD GPU.  And possibly a side-effect of the
> > latest fix to force link-down for AMD GPU.  Need to check it...
> 
> Before Lukas' patches, it is relative with dGPU, because audio power
> is controlled by vgaswitchreroo and GFX driver, but now it won't.

Right, and this is the correct behavior.

> revert the fix of amdgpu suspend issue, audio issue also can be observed.

Did you check the behavior with the single AMD GPU hardware?
If confirmed, we can forget about vga_switcheroo.


Takashi
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Tue, 10 Jul 2018 13:21:00 +0200,
Takashi Iwai wrote:
> 
> > revert the fix of amdgpu suspend issue, audio issue also can be observed.
> 
> Did you check the behavior with the single AMD GPU hardware?
> If confirmed, we can forget about vga_switcheroo.

... and taking a look back at the recent changes, I guess it can be
the forced runtime PM enablement, not directly with vga_switcheroo
action itself.

Jim, could you tell me which PCI devices are handled as vga_switcheroo
audio client?  The kernel should show all messages "xxx: Handle
vga_switcheroo audio client". 

At best, give the full dmesg output and the lspci -nv output.


thanks,

Takashi

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

[-- Attachment #1.1: Type: text/plain, Size: 2611 bytes --]



On 2018年07月11日 15:19, Takashi Iwai wrote:
> On Tue, 10 Jul 2018 13:21:00 +0200,
> Takashi Iwai wrote:
>>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
>> Did you check the behavior with the single AMD GPU hardware?
>> If confirmed, we can forget about vga_switcheroo.
> ... and taking a look back at the recent changes, I guess it can be
> the forced runtime PM enablement, not directly with vga_switcheroo
> action itself.

Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded, so 
there is no way GFX driver to control audio power. However, keep in 
mind, current audio is bound to iGPU, that mean the issue should be 
nothing about
vgaswtichreoo. since current audio pci bus is different from dGPU, that 
means the pci_bus_set_current_state() in 
vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in 
vga_switcheroo_runtime_resume() could not touch the audio pci power 
state from dGPU instance.

This is a feedback got from our OEM developer, it is the overview of 
audio detect process.

> First, the kernel  audio driver will be triggered to read ELD, if the
 >> ELD is valid, it will report a jack event (on or available) to sound
 >> core driver; the pulseaudio subscribe all jack events, if it is told
 >> that the hdmi jack is plugged in (on), the pulseaudio will set this
 >> port to available, then the pa-card or pa-sink has available port, it
 >> can be selected (manually, some daemons or policy in
 >> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.

If the description is correct. I think there are maybe two problems.

1. audio will auto power off after setup device link duo to usage_count=0.
2. duo to audio is power down, it could not get the HDMI jack insert event.

How do you think?

> Jim, could you tell me which PCI devices are handled as vga_switcheroo
> audio client?  The kernel should show all messages "xxx: Handle
> vga_switcheroo audio client".

[    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
[    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio 
client
[    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Device [1002:699f] (rev c3)
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Device [1002:15dd] (rev d1)
06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Device [1002:15de]

Thanks
JimQu
> At best, give the full dmesg output and the lspci -nv output.
>
>
> thanks,
>
> Takashi


[-- Attachment #1.2: Type: text/html, Size: 3982 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Wed, 11 Jul 2018 10:41:38 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月11日 15:19, Takashi Iwai wrote:
> > On Tue, 10 Jul 2018 13:21:00 +0200,
> > Takashi Iwai wrote:
> >>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
> >> Did you check the behavior with the single AMD GPU hardware?
> >> If confirmed, we can forget about vga_switcheroo.
> > ... and taking a look back at the recent changes, I guess it can be
> > the forced runtime PM enablement, not directly with vga_switcheroo
> > action itself.
> 
> Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded,
> so there is no way GFX driver to control audio power. However, keep in
> mind, current audio is bound to iGPU, that mean the issue should be
> nothing about
> vgaswtichreoo. since current audio pci bus is different from dGPU,
> that means the pci_bus_set_current_state() in
> vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in
> vga_switcheroo_runtime_resume() could not touch the audio pci power
> state from dGPU instance.
> 
> This is a feedback got from our OEM developer, it is the overview of
> audio detect process.
> 
> > First, the kernel  audio driver will be triggered to read ELD, if the
> >> ELD is valid, it will report a jack event (on or available) to sound
> >> core driver; the pulseaudio subscribe all jack events, if it is told
> >> that the hdmi jack is plugged in (on), the pulseaudio will set this
> >> port to available, then the pa-card or pa-sink has available port, it
> >> can be selected (manually, some daemons or policy in
> >> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.
> 
> If the description is correct. I think there are maybe two problems.
> 
> 1. audio will auto power off after setup device link duo to usage_count=0.
> 2. duo to audio is power down, it could not get the HDMI jack insert event.
> 
> How do you think?
> 
> > Jim, could you tell me which PCI devices are handled as vga_switcheroo
> > audio client?  The kernel should show all messages "xxx: Handle
> > vga_switcheroo audio client".
> 
> [    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
> [    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio
> client
> [    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)
> 
> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> Inc. [AMD/ATI] Device [1002:699f] (rev c3)
> 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> Inc. [AMD/ATI] Device [1002:15dd] (rev d1)
> 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> Device [1002:15de]

OK this sheds a brighter light, finally.

If my understanding is correct, the issue is a false vga_switcheroo
audio detection, after all.  This is the primary GPU and it shouldn't
be registered as a vga_switcheroo discrete GPU.

Below is a very ugly workaround for this particular case.  It assumes
that the AMD+AMD combo will never have audio outputs on both but only
for the primary, and it's possibly wrong.

Is there a handy way to identify whether the given VGA PCI entry is
a discrete GPU or not?  The amdgpu and radeon seem checking ATPX
ACPI.


Takashi

---
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device)
  */
 static struct pci_dev *get_bound_vga(struct pci_dev *pci)
 {
+	static const struct pci_device_id ids[] = {
+		{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),
+		  .class = PCI_BASE_CLASS_DISPLAY << 16,
+		  .class_mask = 0xff << 16 },
+		{}
+	};
 	struct pci_dev *p;
 
+	/* check whether Intel graphics is present as primary GPU */
+	if (!pci_dev_present(ids))
+		return NULL;
+
 	/* check only discrete GPU */
 	switch (pci->vendor) {
 	case PCI_VENDOR_ID_ATI:
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

On 2018年07月11日 17:04, Takashi Iwai wrote:
> On Wed, 11 Jul 2018 10:41:38 +0200,
> jimqu wrote:
>>
>>
>> On 2018年07月11日 15:19, Takashi Iwai wrote:
>>> On Tue, 10 Jul 2018 13:21:00 +0200,
>>> Takashi Iwai wrote:
>>>>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
>>>> Did you check the behavior with the single AMD GPU hardware?
>>>> If confirmed, we can forget about vga_switcheroo.
>>> ... and taking a look back at the recent changes, I guess it can be
>>> the forced runtime PM enablement, not directly with vga_switcheroo
>>> action itself.
>> Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded,
>> so there is no way GFX driver to control audio power. However, keep in
>> mind, current audio is bound to iGPU, that mean the issue should be
>> nothing about
>> vgaswtichreoo. since current audio pci bus is different from dGPU,
>> that means the pci_bus_set_current_state() in
>> vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in
>> vga_switcheroo_runtime_resume() could not touch the audio pci power
>> state from dGPU instance.
>>
>> This is a feedback got from our OEM developer, it is the overview of
>> audio detect process.
>>
>>> First, the kernel  audio driver will be triggered to read ELD, if the
>>>> ELD is valid, it will report a jack event (on or available) to sound
>>>> core driver; the pulseaudio subscribe all jack events, if it is told
>>>> that the hdmi jack is plugged in (on), the pulseaudio will set this
>>>> port to available, then the pa-card or pa-sink has available port, it
>>>> can be selected (manually, some daemons or policy in
>>>> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.
>> If the description is correct. I think there are maybe two problems.
>>
>> 1. audio will auto power off after setup device link duo to usage_count=0.
>> 2. duo to audio is power down, it could not get the HDMI jack insert event.
>>
>> How do you think?
>>
>>> Jim, could you tell me which PCI devices are handled as vga_switcheroo
>>> audio client?  The kernel should show all messages "xxx: Handle
>>> vga_switcheroo audio client".
>> [    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
>> [    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio
>> client
>> [    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)
>>
>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>> Inc. [AMD/ATI] Device [1002:699f] (rev c3)
>> 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>> Inc. [AMD/ATI] Device [1002:15dd] (rev d1)
>> 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>> Device [1002:15de]
> OK this sheds a brighter light, finally.
>
> If my understanding is correct, the issue is a false vga_switcheroo
> audio detection, after all.  This is the primary GPU and it shouldn't
> be registered as a vga_switcheroo discrete GPU.
>
> Below is a very ugly workaround for this particular case.  It assumes
> that the AMD+AMD combo will never have audio outputs on both but only
> for the primary, and it's possibly wrong.
>
> Is there a handy way to identify whether the given VGA PCI entry is
> a discrete GPU or not?  The amdgpu and radeon seem checking ATPX
> ACPI.

This is no issue about this topic, in amdgpu driver, both iGPU/dGPU will 
register as VGA_SWITCHEROO_UNKNOWN_ID, and the client id will be 
re-initialized in vgaswitchreoo_enable() via ATPX call. Then, iGPU will 
set as VGA_SWITCHEROO_IGD, and dGPU will set as VGA_SWITCHEROO_DIS.

I think current focus should be how to detect HDMI audio device under 
audio suspend state.

Thanks
JimQu
>
> Takashi
>
> ---
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device)
>    */
>   static struct pci_dev *get_bound_vga(struct pci_dev *pci)
>   {
> +	static const struct pci_device_id ids[] = {
> +		{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),
> +		  .class = PCI_BASE_CLASS_DISPLAY << 16,
> +		  .class_mask = 0xff << 16 },
> +		{}
> +	};
>   	struct pci_dev *p;
>   
> +	/* check whether Intel graphics is present as primary GPU */
> +	if (!pci_dev_present(ids))
> +		return NULL;
> +
>   	/* check only discrete GPU */
>   	switch (pci->vendor) {
>   	case PCI_VENDOR_ID_ATI:

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Wed, 11 Jul 2018 11:26:11 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月11日 17:04, Takashi Iwai wrote:
> > On Wed, 11 Jul 2018 10:41:38 +0200,
> > jimqu wrote:
> >>
> >>
> >> On 2018年07月11日 15:19, Takashi Iwai wrote:
> >>> On Tue, 10 Jul 2018 13:21:00 +0200,
> >>> Takashi Iwai wrote:
> >>>>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
> >>>> Did you check the behavior with the single AMD GPU hardware?
> >>>> If confirmed, we can forget about vga_switcheroo.
> >>> ... and taking a look back at the recent changes, I guess it can be
> >>> the forced runtime PM enablement, not directly with vga_switcheroo
> >>> action itself.
> >> Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded,
> >> so there is no way GFX driver to control audio power. However, keep in
> >> mind, current audio is bound to iGPU, that mean the issue should be
> >> nothing about
> >> vgaswtichreoo. since current audio pci bus is different from dGPU,
> >> that means the pci_bus_set_current_state() in
> >> vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in
> >> vga_switcheroo_runtime_resume() could not touch the audio pci power
> >> state from dGPU instance.
> >>
> >> This is a feedback got from our OEM developer, it is the overview of
> >> audio detect process.
> >>
> >>> First, the kernel  audio driver will be triggered to read ELD, if the
> >>>> ELD is valid, it will report a jack event (on or available) to sound
> >>>> core driver; the pulseaudio subscribe all jack events, if it is told
> >>>> that the hdmi jack is plugged in (on), the pulseaudio will set this
> >>>> port to available, then the pa-card or pa-sink has available port, it
> >>>> can be selected (manually, some daemons or policy in
> >>>> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.
> >> If the description is correct. I think there are maybe two problems.
> >>
> >> 1. audio will auto power off after setup device link duo to usage_count=0.
> >> 2. duo to audio is power down, it could not get the HDMI jack insert event.
> >>
> >> How do you think?
> >>
> >>> Jim, could you tell me which PCI devices are handled as vga_switcheroo
> >>> audio client?  The kernel should show all messages "xxx: Handle
> >>> vga_switcheroo audio client".
> >> [    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
> >> [    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio
> >> client
> >> [    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)
> >>
> >> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> >> Inc. [AMD/ATI] Device [1002:699f] (rev c3)
> >> 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> >> Inc. [AMD/ATI] Device [1002:15dd] (rev d1)
> >> 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> >> Device [1002:15de]
> > OK this sheds a brighter light, finally.
> >
> > If my understanding is correct, the issue is a false vga_switcheroo
> > audio detection, after all.  This is the primary GPU and it shouldn't
> > be registered as a vga_switcheroo discrete GPU.
> >
> > Below is a very ugly workaround for this particular case.  It assumes
> > that the AMD+AMD combo will never have audio outputs on both but only
> > for the primary, and it's possibly wrong.
> >
> > Is there a handy way to identify whether the given VGA PCI entry is
> > a discrete GPU or not?  The amdgpu and radeon seem checking ATPX
> > ACPI.
> 
> This is no issue about this topic, in amdgpu driver, both iGPU/dGPU
> will register as VGA_SWITCHEROO_UNKNOWN_ID, and the client id will be
> re-initialized in vgaswitchreoo_enable() via ATPX call. Then, iGPU
> will set as VGA_SWITCHEROO_IGD, and dGPU will set as
> VGA_SWITCHEROO_DIS.

Please check the patch.  It's not about AMDGPU driver but the vga
switcheroo detection in HD-audio driver.  Not the GPU side but the
audio side.

The issues are two folds:
- We register each AMD controller associated with a GPU always as a
  discrete GPU vga_switcheroo audio.
- And when it's registered as a vga_switcheroo client, we forcibly
  enable runtime PM of the controller, since discrete GPU needs the
  runtime suspend.

So a workaround in your case is just not to register as a vga
switcheroo audio client.  Then the runtime PM isn't enabled in the AMD
HDMI audio controller, and the HDMI detection remains active.


Takashi

> 
> Thanks
> JimQu
> >
> > Takashi
> >
> > ---
> > --- a/sound/pci/hda/hda_intel.c
> > +++ b/sound/pci/hda/hda_intel.c
> > @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device)
> >    */
> >   static struct pci_dev *get_bound_vga(struct pci_dev *pci)
> >   {
> > +	static const struct pci_device_id ids[] = {
> > +		{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),
> > +		  .class = PCI_BASE_CLASS_DISPLAY << 16,
> > +		  .class_mask = 0xff << 16 },
> > +		{}
> > +	};
> >   	struct pci_dev *p;
> >   +	/* check whether Intel graphics is present as primary GPU */
> > +	if (!pci_dev_present(ids))
> > +		return NULL;
> > +
> >   	/* check only discrete GPU */
> >   	switch (pci->vendor) {
> >   	case PCI_VENDOR_ID_ATI:
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

On 2018年07月11日 17:53, Takashi Iwai wrote:
> On Wed, 11 Jul 2018 11:26:11 +0200,
> jimqu wrote:
>>
>>
>> On 2018年07月11日 17:04, Takashi Iwai wrote:
>>> On Wed, 11 Jul 2018 10:41:38 +0200,
>>> jimqu wrote:
>>>>
>>>> On 2018年07月11日 15:19, Takashi Iwai wrote:
>>>>> On Tue, 10 Jul 2018 13:21:00 +0200,
>>>>> Takashi Iwai wrote:
>>>>>>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
>>>>>> Did you check the behavior with the single AMD GPU hardware?
>>>>>> If confirmed, we can forget about vga_switcheroo.
>>>>> ... and taking a look back at the recent changes, I guess it can be
>>>>> the forced runtime PM enablement, not directly with vga_switcheroo
>>>>> action itself.
>>>> Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded,
>>>> so there is no way GFX driver to control audio power. However, keep in
>>>> mind, current audio is bound to iGPU, that mean the issue should be
>>>> nothing about
>>>> vgaswtichreoo. since current audio pci bus is different from dGPU,
>>>> that means the pci_bus_set_current_state() in
>>>> vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in
>>>> vga_switcheroo_runtime_resume() could not touch the audio pci power
>>>> state from dGPU instance.
>>>>
>>>> This is a feedback got from our OEM developer, it is the overview of
>>>> audio detect process.
>>>>
>>>>> First, the kernel  audio driver will be triggered to read ELD, if the
>>>>>> ELD is valid, it will report a jack event (on or available) to sound
>>>>>> core driver; the pulseaudio subscribe all jack events, if it is told
>>>>>> that the hdmi jack is plugged in (on), the pulseaudio will set this
>>>>>> port to available, then the pa-card or pa-sink has available port, it
>>>>>> can be selected (manually, some daemons or policy in
>>>>>> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.
>>>> If the description is correct. I think there are maybe two problems.
>>>>
>>>> 1. audio will auto power off after setup device link duo to usage_count=0.
>>>> 2. duo to audio is power down, it could not get the HDMI jack insert event.
>>>>
>>>> How do you think?
>>>>
>>>>> Jim, could you tell me which PCI devices are handled as vga_switcheroo
>>>>> audio client?  The kernel should show all messages "xxx: Handle
>>>>> vga_switcheroo audio client".
>>>> [    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
>>>> [    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio
>>>> client
>>>> [    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)
>>>>
>>>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>>>> Inc. [AMD/ATI] Device [1002:699f] (rev c3)
>>>> 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
>>>> Inc. [AMD/ATI] Device [1002:15dd] (rev d1)
>>>> 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
>>>> Device [1002:15de]
>>> OK this sheds a brighter light, finally.
>>>
>>> If my understanding is correct, the issue is a false vga_switcheroo
>>> audio detection, after all.  This is the primary GPU and it shouldn't
>>> be registered as a vga_switcheroo discrete GPU.
>>>
>>> Below is a very ugly workaround for this particular case.  It assumes
>>> that the AMD+AMD combo will never have audio outputs on both but only
>>> for the primary, and it's possibly wrong.
>>>
>>> Is there a handy way to identify whether the given VGA PCI entry is
>>> a discrete GPU or not?  The amdgpu and radeon seem checking ATPX
>>> ACPI.
>> This is no issue about this topic, in amdgpu driver, both iGPU/dGPU
>> will register as VGA_SWITCHEROO_UNKNOWN_ID, and the client id will be
>> re-initialized in vgaswitchreoo_enable() via ATPX call. Then, iGPU
>> will set as VGA_SWITCHEROO_IGD, and dGPU will set as
>> VGA_SWITCHEROO_DIS.
> Please check the patch.  It's not about AMDGPU driver but the vga
> switcheroo detection in HD-audio driver.  Not the GPU side but the
> audio side.
>
> The issues are two folds:
> - We register each AMD controller associated with a GPU always as a
>    discrete GPU vga_switcheroo audio.
> - And when it's registered as a vga_switcheroo client, we forcibly
>    enable runtime PM of the controller, since discrete GPU needs the
>    runtime suspend.
>
> So a workaround in your case is just not to register as a vga
> switcheroo audio client.  Then the runtime PM isn't enabled in the AMD
> HDMI audio controller, and the HDMI detection remains active.
>
>
> Takashi

OK, I got your point. Let me have a try.

BTW, what about the patch in this thread, I think it is also need for 
current code. although audio power is not controlled by vgaswitchreoo, 
we also can encounter the issue(audio which is bound to iGPU will 
suspend with dGPU) if user debugfs to control the client power.

Thanks
JimQu
>> Thanks
>> JimQu
>>> Takashi
>>>
>>> ---
>>> --- a/sound/pci/hda/hda_intel.c
>>> +++ b/sound/pci/hda/hda_intel.c
>>> @@ -1418,8 +1418,18 @@ static int azx_dev_free(struct snd_device *device)
>>>     */
>>>    static struct pci_dev *get_bound_vga(struct pci_dev *pci)
>>>    {
>>> +	static const struct pci_device_id ids[] = {
>>> +		{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_ANY_ID),
>>> +		  .class = PCI_BASE_CLASS_DISPLAY << 16,
>>> +		  .class_mask = 0xff << 16 },
>>> +		{}
>>> +	};
>>>    	struct pci_dev *p;
>>>    +	/* check whether Intel graphics is present as primary GPU */
>>> +	if (!pci_dev_present(ids))
>>> +		return NULL;
>>> +
>>>    	/* check only discrete GPU */
>>>    	switch (pci->vendor) {
>>>    	case PCI_VENDOR_ID_ATI:

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Wed, 11 Jul 2018 12:21:03 +0200,
jimqu wrote:
> 
> 
> 
> On 2018年07月11日 17:53, Takashi Iwai wrote:
> > On Wed, 11 Jul 2018 11:26:11 +0200,
> > jimqu wrote:
> >>
> >>
> >> On 2018年07月11日 17:04, Takashi Iwai wrote:
> >>> On Wed, 11 Jul 2018 10:41:38 +0200,
> >>> jimqu wrote:
> >>>>
> >>>> On 2018年07月11日 15:19, Takashi Iwai wrote:
> >>>>> On Tue, 10 Jul 2018 13:21:00 +0200,
> >>>>> Takashi Iwai wrote:
> >>>>>>> revert the fix of amdgpu suspend issue, audio issue also can be observed.
> >>>>>> Did you check the behavior with the single AMD GPU hardware?
> >>>>>> If confirmed, we can forget about vga_switcheroo.
> >>>>> ... and taking a look back at the recent changes, I guess it can be
> >>>>> the forced runtime PM enablement, not directly with vga_switcheroo
> >>>>> action itself.
> >>>> Yeah, the function vga_switcheroo_set_dynamic_switch() has discarded,
> >>>> so there is no way GFX driver to control audio power. However, keep in
> >>>> mind, current audio is bound to iGPU, that mean the issue should be
> >>>> nothing about
> >>>> vgaswtichreoo. since current audio pci bus is different from dGPU,
> >>>> that means the pci_bus_set_current_state() in
> >>>> vga_switcheroo_runtime_suspend() and pci_wakeup_bus() in
> >>>> vga_switcheroo_runtime_resume() could not touch the audio pci power
> >>>> state from dGPU instance.
> >>>>
> >>>> This is a feedback got from our OEM developer, it is the overview of
> >>>> audio detect process.
> >>>>
> >>>>> First, the kernel  audio driver will be triggered to read ELD, if the
> >>>>>> ELD is valid, it will report a jack event (on or available) to sound
> >>>>>> core driver; the pulseaudio subscribe all jack events, if it is told
> >>>>>> that the hdmi jack is plugged in (on), the pulseaudio will set this
> >>>>>> port to available, then the pa-card or pa-sink has available port, it
> >>>>>> can be selected (manually, some daemons or policy in
> >>>>>> /usr/share/pulseaudio/alsa-mixer/) as default output card/default sink.
> >>>> If the description is correct. I think there are maybe two problems.
> >>>>
> >>>> 1. audio will auto power off after setup device link duo to usage_count=0.
> >>>> 2. duo to audio is power down, it could not get the HDMI jack insert event.
> >>>>
> >>>> How do you think?
> >>>>
> >>>>> Jim, could you tell me which PCI devices are handled as vga_switcheroo
> >>>>> audio client?  The kernel should show all messages "xxx: Handle
> >>>>> vga_switcheroo audio client".
> >>>> [    4.311095] snd_hda_intel 0000:06:00.1: enabling device (0000 -> 0002)
> >>>> [    4.314286] snd_hda_intel 0000:06:00.1: Handle vga_switcheroo audio
> >>>> client
> >>>> [    4.314822] snd_hda_intel 0000:06:00.6: enabling device (0000 -> 0002)
> >>>>
> >>>> 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> >>>> Inc. [AMD/ATI] Device [1002:699f] (rev c3)
> >>>> 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
> >>>> Inc. [AMD/ATI] Device [1002:15dd] (rev d1)
> >>>> 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI]
> >>>> Device [1002:15de]
> >>> OK this sheds a brighter light, finally.
> >>>
> >>> If my understanding is correct, the issue is a false vga_switcheroo
> >>> audio detection, after all.  This is the primary GPU and it shouldn't
> >>> be registered as a vga_switcheroo discrete GPU.
> >>>
> >>> Below is a very ugly workaround for this particular case.  It assumes
> >>> that the AMD+AMD combo will never have audio outputs on both but only
> >>> for the primary, and it's possibly wrong.
> >>>
> >>> Is there a handy way to identify whether the given VGA PCI entry is
> >>> a discrete GPU or not?  The amdgpu and radeon seem checking ATPX
> >>> ACPI.
> >> This is no issue about this topic, in amdgpu driver, both iGPU/dGPU
> >> will register as VGA_SWITCHEROO_UNKNOWN_ID, and the client id will be
> >> re-initialized in vgaswitchreoo_enable() via ATPX call. Then, iGPU
> >> will set as VGA_SWITCHEROO_IGD, and dGPU will set as
> >> VGA_SWITCHEROO_DIS.
> > Please check the patch.  It's not about AMDGPU driver but the vga
> > switcheroo detection in HD-audio driver.  Not the GPU side but the
> > audio side.
> >
> > The issues are two folds:
> > - We register each AMD controller associated with a GPU always as a
> >    discrete GPU vga_switcheroo audio.
> > - And when it's registered as a vga_switcheroo client, we forcibly
> >    enable runtime PM of the controller, since discrete GPU needs the
> >    runtime suspend.
> >
> > So a workaround in your case is just not to register as a vga
> > switcheroo audio client.  Then the runtime PM isn't enabled in the AMD
> > HDMI audio controller, and the HDMI detection remains active.
> >
> >
> > Takashi
> 
> OK, I got your point. Let me have a try.
> 
> BTW, what about the patch in this thread, I think it is also need for
> current code. although audio power is not controlled by vgaswitchreoo,
> we also can encounter the issue(audio which is bound to iGPU will
> suspend with dGPU) if user debugfs to control the client power.

That'd do a trick in most cases, too, but I guess one scenario is
overseen: when HD-audio driver is probed / registered before the
graphics driver, it may get a false client id, too.

And the forced runtime PM is still an issue, and this would need the
other notification mechanism than the HD-audio unsolicited event as
AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.


Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Wed, 11 Jul 2018 13:12:01 +0200,
Takashi Iwai wrote:
> 
> And the forced runtime PM is still an issue, and this would need the
> other notification mechanism than the HD-audio unsolicited event as
> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.

Since we had a nice "hack week" in this week at SUSE, I spent some
time to write some patches for the support of the direct hotplug
notification / ELD query between HD-audio and radeon/amdgpu.  It
re-utilizes the audio component framework for i915 but in a slightly
more flexible way.

The patches are found in topic/hda-acomp branch of my sound.git tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

The following commits are relevant:
  drm/i915: Split audio component to a generic type
  ALSA: hda/i915: Allow delayed i915 audio component binding
  ALSA: hda/i915: Associate audio component with devres
  ALSA: hda: Make audio component support more generic
  ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
  ALSA: hda/hdmi: Use single mutex unlock in error paths
  drm/radeon: Add audio component support
  drm/amdgpu: Add audio component support

The branch should be cleanly pullable onto the latest 4.18-rc.

I couldn't test amdgpu but the test with a radeon driver on an old
laptop seemed working through a very quick test.

Please give it a try.


thanks,

Takashi
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[jimqu]

在 2018/7/13 23:07, Takashi Iwai 写道:
> On Wed, 11 Jul 2018 13:12:01 +0200,
> Takashi Iwai wrote:
>> And the forced runtime PM is still an issue, and this would need the
>> other notification mechanism than the HD-audio unsolicited event as
>> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
> Since we had a nice "hack week" in this week at SUSE, I spent some
> time to write some patches for the support of the direct hotplug
> notification / ELD query between HD-audio and radeon/amdgpu.  It
> re-utilizes the audio component framework for i915 but in a slightly
> more flexible way.
>
> The patches are found in topic/hda-acomp branch of my sound.git tree:
>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>
> The following commits are relevant:
>    drm/i915: Split audio component to a generic type
>    ALSA: hda/i915: Allow delayed i915 audio component binding
>    ALSA: hda/i915: Associate audio component with devres
>    ALSA: hda: Make audio component support more generic
>    ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
>    ALSA: hda/hdmi: Use single mutex unlock in error paths
>    drm/radeon: Add audio component support
>    drm/amdgpu: Add audio component support
>
> The branch should be cleanly pullable onto the latest 4.18-rc.
>
> I couldn't test amdgpu but the test with a radeon driver on an old
> laptop seemed working through a very quick test.
>
> Please give it a try.

That is really wonderful work. I will check it on our AMD platform. BTW, 
For display, AMD has moved to use DC to support new asics. so there also 
need a patch for amdgpu in DC code.

Thanks
JimQu
>
> thanks,
>
> Takashi

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Sat, 14 Jul 2018 14:03:26 +0200,
jimqu wrote:
> 
> 
> 
> 在 2018/7/13 23:07, Takashi Iwai 写道:
> > On Wed, 11 Jul 2018 13:12:01 +0200,
> > Takashi Iwai wrote:
> >> And the forced runtime PM is still an issue, and this would need the
> >> other notification mechanism than the HD-audio unsolicited event as
> >> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
> > Since we had a nice "hack week" in this week at SUSE, I spent some
> > time to write some patches for the support of the direct hotplug
> > notification / ELD query between HD-audio and radeon/amdgpu.  It
> > re-utilizes the audio component framework for i915 but in a slightly
> > more flexible way.
> >
> > The patches are found in topic/hda-acomp branch of my sound.git tree:
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> >
> > The following commits are relevant:
> >    drm/i915: Split audio component to a generic type
> >    ALSA: hda/i915: Allow delayed i915 audio component binding
> >    ALSA: hda/i915: Associate audio component with devres
> >    ALSA: hda: Make audio component support more generic
> >    ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
> >    ALSA: hda/hdmi: Use single mutex unlock in error paths
> >    drm/radeon: Add audio component support
> >    drm/amdgpu: Add audio component support
> >
> > The branch should be cleanly pullable onto the latest 4.18-rc.
> >
> > I couldn't test amdgpu but the test with a radeon driver on an old
> > laptop seemed working through a very quick test.
> >
> > Please give it a try.
> 
> That is really wonderful work. I will check it on our AMD
> platform.

Thanks, it'll be great if you can check whether the current code works
or not.  I'd love to push the stuff for 4.19.  Hopefully I'll start
submitting the preparation patches in the next week.

Basically this also opens the door of the similar capability for
nouveau, and I guess it's also trivial enough.

> BTW, For display, AMD has moved to use DC to support new
> asics. so there also need a patch for amdgpu in DC code.

Could you give a more hint?  I'll try adapt the code if such a change
is already in upstream tree.


Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Sat, 14 Jul 2018 14:03:26 +0200,
> jimqu wrote:
>>
>>
>>
>> 在 2018/7/13 23:07, Takashi Iwai 写道:
>> > On Wed, 11 Jul 2018 13:12:01 +0200,
>> > Takashi Iwai wrote:
>> >> And the forced runtime PM is still an issue, and this would need the
>> >> other notification mechanism than the HD-audio unsolicited event as
>> >> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
>> > Since we had a nice "hack week" in this week at SUSE, I spent some
>> > time to write some patches for the support of the direct hotplug
>> > notification / ELD query between HD-audio and radeon/amdgpu.  It
>> > re-utilizes the audio component framework for i915 but in a slightly
>> > more flexible way.
>> >
>> > The patches are found in topic/hda-acomp branch of my sound.git tree:
>> >    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>> >
>> > The following commits are relevant:
>> >    drm/i915: Split audio component to a generic type
>> >    ALSA: hda/i915: Allow delayed i915 audio component binding
>> >    ALSA: hda/i915: Associate audio component with devres
>> >    ALSA: hda: Make audio component support more generic
>> >    ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
>> >    ALSA: hda/hdmi: Use single mutex unlock in error paths
>> >    drm/radeon: Add audio component support
>> >    drm/amdgpu: Add audio component support
>> >
>> > The branch should be cleanly pullable onto the latest 4.18-rc.
>> >
>> > I couldn't test amdgpu but the test with a radeon driver on an old
>> > laptop seemed working through a very quick test.
>> >
>> > Please give it a try.
>>
>> That is really wonderful work. I will check it on our AMD
>> platform.
>
> Thanks, it'll be great if you can check whether the current code works
> or not.  I'd love to push the stuff for 4.19.  Hopefully I'll start
> submitting the preparation patches in the next week.
>
> Basically this also opens the door of the similar capability for
> nouveau, and I guess it's also trivial enough.
>
>> BTW, For display, AMD has moved to use DC to support new
>> asics. so there also need a patch for amdgpu in DC code.
>
> Could you give a more hint?  I'll try adapt the code if such a change
> is already in upstream tree.

The new code is in drivers/gpu/drm/amd/display.

Alex
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Harry Wentland]

On 2018-07-15 10:36 AM, Alex Deucher wrote:
> On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> On Sat, 14 Jul 2018 14:03:26 +0200,
>> jimqu wrote:
>>>
>>>
>>>
>>> 在 2018/7/13 23:07, Takashi Iwai 写道:
>>>> On Wed, 11 Jul 2018 13:12:01 +0200,
>>>> Takashi Iwai wrote:
>>>>> And the forced runtime PM is still an issue, and this would need the
>>>>> other notification mechanism than the HD-audio unsolicited event as
>>>>> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
>>>> Since we had a nice "hack week" in this week at SUSE, I spent some
>>>> time to write some patches for the support of the direct hotplug
>>>> notification / ELD query between HD-audio and radeon/amdgpu.  It
>>>> re-utilizes the audio component framework for i915 but in a slightly
>>>> more flexible way.
>>>>
>>>> The patches are found in topic/hda-acomp branch of my sound.git tree:
>>>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>>>>
>>>> The following commits are relevant:
>>>>    drm/i915: Split audio component to a generic type
>>>>    ALSA: hda/i915: Allow delayed i915 audio component binding
>>>>    ALSA: hda/i915: Associate audio component with devres
>>>>    ALSA: hda: Make audio component support more generic
>>>>    ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
>>>>    ALSA: hda/hdmi: Use single mutex unlock in error paths
>>>>    drm/radeon: Add audio component support
>>>>    drm/amdgpu: Add audio component support
>>>>
>>>> The branch should be cleanly pullable onto the latest 4.18-rc.
>>>>
>>>> I couldn't test amdgpu but the test with a radeon driver on an old
>>>> laptop seemed working through a very quick test.
>>>>
>>>> Please give it a try.
>>>
>>> That is really wonderful work. I will check it on our AMD
>>> platform.
>>
>> Thanks, it'll be great if you can check whether the current code works
>> or not.  I'd love to push the stuff for 4.19.  Hopefully I'll start
>> submitting the preparation patches in the next week.
>>
>> Basically this also opens the door of the similar capability for
>> nouveau, and I guess it's also trivial enough.
>>
>>> BTW, For display, AMD has moved to use DC to support new
>>> asics. so there also need a patch for amdgpu in DC code.
>>
>> Could you give a more hint?  I'll try adapt the code if such a change
>> is already in upstream tree.
> 
> The new code is in drivers/gpu/drm/amd/display.
> 

In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event.

I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well.

Harry

> Alex
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 16 Jul 2018 17:10:43 +0200,
Harry Wentland wrote:
> 
> 
> 
> On 2018-07-15 10:36 AM, Alex Deucher wrote:
> > On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
> >> On Sat, 14 Jul 2018 14:03:26 +0200,
> >> jimqu wrote:
> >>>
> >>>
> >>>
> >>> 在 2018/7/13 23:07, Takashi Iwai 写道:
> >>>> On Wed, 11 Jul 2018 13:12:01 +0200,
> >>>> Takashi Iwai wrote:
> >>>>> And the forced runtime PM is still an issue, and this would need the
> >>>>> other notification mechanism than the HD-audio unsolicited event as
> >>>>> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
> >>>> Since we had a nice "hack week" in this week at SUSE, I spent some
> >>>> time to write some patches for the support of the direct hotplug
> >>>> notification / ELD query between HD-audio and radeon/amdgpu.  It
> >>>> re-utilizes the audio component framework for i915 but in a slightly
> >>>> more flexible way.
> >>>>
> >>>> The patches are found in topic/hda-acomp branch of my sound.git tree:
> >>>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> >>>>
> >>>> The following commits are relevant:
> >>>>    drm/i915: Split audio component to a generic type
> >>>>    ALSA: hda/i915: Allow delayed i915 audio component binding
> >>>>    ALSA: hda/i915: Associate audio component with devres
> >>>>    ALSA: hda: Make audio component support more generic
> >>>>    ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
> >>>>    ALSA: hda/hdmi: Use single mutex unlock in error paths
> >>>>    drm/radeon: Add audio component support
> >>>>    drm/amdgpu: Add audio component support
> >>>>
> >>>> The branch should be cleanly pullable onto the latest 4.18-rc.
> >>>>
> >>>> I couldn't test amdgpu but the test with a radeon driver on an old
> >>>> laptop seemed working through a very quick test.
> >>>>
> >>>> Please give it a try.
> >>>
> >>> That is really wonderful work. I will check it on our AMD
> >>> platform.
> >>
> >> Thanks, it'll be great if you can check whether the current code works
> >> or not.  I'd love to push the stuff for 4.19.  Hopefully I'll start
> >> submitting the preparation patches in the next week.
> >>
> >> Basically this also opens the door of the similar capability for
> >> nouveau, and I guess it's also trivial enough.
> >>
> >>> BTW, For display, AMD has moved to use DC to support new
> >>> asics. so there also need a patch for amdgpu in DC code.
> >>
> >> Could you give a more hint?  I'll try adapt the code if such a change
> >> is already in upstream tree.
> > 
> > The new code is in drivers/gpu/drm/amd/display.
> > 
> 
> In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event.

Thanks, I'm currently struggling to read down the whole complex DC
code tree, and it's a very helpful hint.

How is the audio enable/disable call associated with the pipe index?
IOW, if I add a hook to call a notifier callback to pass the pipe
index that is enabled/disabled, how can it be deduced?

Similarly, when DC driver gets the query about the ELD on the given
pipe, where can I convert it to which object?

DC is quite another beast, so I still haven't figured out the
structures yet...


> I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well.

Oh I just didn't know that amdgpu code was with MIT.  Indeed the
driver module is provided via "GPL and additional rights".

I'm fine to change the license to follow other code bits there.  What
exactly SPDX tag should be put there?


thanks,

Takashi
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 16, 2018 at 11:25 AM, Takashi Iwai <tiwai@suse.de> wrote:
> On Mon, 16 Jul 2018 17:10:43 +0200,
> Harry Wentland wrote:
>>
>>
>>
>> On 2018-07-15 10:36 AM, Alex Deucher wrote:
>> > On Sat, Jul 14, 2018 at 12:31 PM, Takashi Iwai <tiwai@suse.de> wrote:
>> >> On Sat, 14 Jul 2018 14:03:26 +0200,
>> >> jimqu wrote:
>> >>>
>> >>>
>> >>>
>> >>> 在 2018/7/13 23:07, Takashi Iwai 写道:
>> >>>> On Wed, 11 Jul 2018 13:12:01 +0200,
>> >>>> Takashi Iwai wrote:
>> >>>>> And the forced runtime PM is still an issue, and this would need the
>> >>>>> other notification mechanism than the HD-audio unsolicited event as
>> >>>>> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.
>> >>>> Since we had a nice "hack week" in this week at SUSE, I spent some
>> >>>> time to write some patches for the support of the direct hotplug
>> >>>> notification / ELD query between HD-audio and radeon/amdgpu.  It
>> >>>> re-utilizes the audio component framework for i915 but in a slightly
>> >>>> more flexible way.
>> >>>>
>> >>>> The patches are found in topic/hda-acomp branch of my sound.git tree:
>> >>>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>> >>>>
>> >>>> The following commits are relevant:
>> >>>>    drm/i915: Split audio component to a generic type
>> >>>>    ALSA: hda/i915: Allow delayed i915 audio component binding
>> >>>>    ALSA: hda/i915: Associate audio component with devres
>> >>>>    ALSA: hda: Make audio component support more generic
>> >>>>    ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
>> >>>>    ALSA: hda/hdmi: Use single mutex unlock in error paths
>> >>>>    drm/radeon: Add audio component support
>> >>>>    drm/amdgpu: Add audio component support
>> >>>>
>> >>>> The branch should be cleanly pullable onto the latest 4.18-rc.
>> >>>>
>> >>>> I couldn't test amdgpu but the test with a radeon driver on an old
>> >>>> laptop seemed working through a very quick test.
>> >>>>
>> >>>> Please give it a try.
>> >>>
>> >>> That is really wonderful work. I will check it on our AMD
>> >>> platform.
>> >>
>> >> Thanks, it'll be great if you can check whether the current code works
>> >> or not.  I'd love to push the stuff for 4.19.  Hopefully I'll start
>> >> submitting the preparation patches in the next week.
>> >>
>> >> Basically this also opens the door of the similar capability for
>> >> nouveau, and I guess it's also trivial enough.
>> >>
>> >>> BTW, For display, AMD has moved to use DC to support new
>> >>> asics. so there also need a patch for amdgpu in DC code.
>> >>
>> >> Could you give a more hint?  I'll try adapt the code if such a change
>> >> is already in upstream tree.
>> >
>> > The new code is in drivers/gpu/drm/amd/display.
>> >
>>
>> In particular, I imagine all you need should be in display/amdgpu_dm, although there's chance you might have to touch display/dc/dce/dce_audio.c if you have to do anything with the unsolicited event.
>
> Thanks, I'm currently struggling to read down the whole complex DC
> code tree, and it's a very helpful hint.
>
> How is the audio enable/disable call associated with the pipe index?
> IOW, if I add a hook to call a notifier callback to pass the pipe
> index that is enabled/disabled, how can it be deduced?
>
> Similarly, when DC driver gets the query about the ELD on the given
> pipe, where can I convert it to which object?
>
> DC is quite another beast, so I still haven't figured out the
> structures yet...
>
>
>> I see you're using the GPL license, rather than MIT in amdgpu_audio.c. Since the code in display/dc is shared with other OSes and internal test frameworks it has to be MIT. Not entirely sure about display/amdgpu_dm, but if GPL is fine in amd/amdgpu it's probably fine there as well.
>
> Oh I just didn't know that amdgpu code was with MIT.  Indeed the
> driver module is provided via "GPL and additional rights".
>
> I'm fine to change the license to follow other code bits there.  What
> exactly SPDX tag should be put there?

Preferably:
SPDX-License-Identifier: MIT
or I suppose dual licensing (MIT or GPL 2.0) is ok too.

Alex

>
>
> thanks,
>
> Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Alex Deucher]

On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> Hi Lukas,
>
> Thanks to your explanation, and see comments in line.
>
>
> Do you need to runtime resume the HDA controller even if user space isn't
> streaming audio?  Why, and in which situation exactly?
>
> Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.


Sounds like a bug in the HDA driver.  The HDA driver should cache what
it needs or power it back up when there is an ioctl/etc. that requires
something that can't be cached.

Alex

>
> You're saying above that the HDA controller isn't runtime resumed on
> hotplug of a display.  Is that necessary to retrieve ELD or something?
> I'm not sure if there's code in the HDA driver to acquire a runtime PM
> ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> somehow no HPD interrupt is received by the HDA driver?
>
> Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
>
> Thanks
> JimQu
>
> ________________________________________
> 发件人: Lukas Wunner <lukas@wunner.de>
> 发送时间: 2018年7月9日 17:27
> 收件人: Qu, Jim
> 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
>
> On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
>> Now, I found the audio device will auto suspend even if the gpu is active,
>> and if I plug in a HDMI device it also do not resume back.
>>
>> 1. Did you encounter similar issue before?
>> 2. audio will auto suspend as default at beginning of boot, is it expect
>> behaviour?
>
> Yes, that's expected.  Once you start streaming audio to attached displays,
> user space opens the codec device and this causes the HDA controller to
> runtime resume.  If the discrete GPU is suspended at that moment, it will
> be powered on and kept powered on as long as user space is streaming audio.
>
> Do you need to runtime resume the HDA controller even if user space isn't
> streaming audio?  Why, and in which situation exactly?
>
> You're saying above that the HDA controller isn't runtime resumed on
> hotplug of a display.  Is that necessary to retrieve ELD or something?
> I'm not sure if there's code in the HDA driver to acquire a runtime PM
> ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> somehow no HPD interrupt is received by the HDA driver?
>
> Thanks,
>
> Lukas
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Mon, 09 Jul 2018 16:02:48 +0200,
Alex Deucher wrote:
> 
> On Mon, Jul 9, 2018 at 6:16 AM, Qu, Jim <Jim.Qu@amd.com> wrote:
> > Hi Lukas,
> >
> > Thanks to your explanation, and see comments in line.
> >
> >
> > Do you need to runtime resume the HDA controller even if user space isn't
> > streaming audio?  Why, and in which situation exactly?
> >
> > Jim: OEM system uses pactl to queiry audio card and audio output sink, since the audio has power down by runtime pm, so the audio card and output sink are all unavailable. they could not select the available HDMI audio for audio playing.
> 
> 
> Sounds like a bug in the HDA driver.  The HDA driver should cache what
> it needs or power it back up when there is an ioctl/etc. that requires
> something that can't be cached.

Actually I'm not sure whether the analysis above is correct.  If PA
shows it's unavailable, it implies rather that the HDMI is seen as
unconnected.  PA doesn't matter about the runtime PM state.  If a
runtime PM fails, it'd result in a "failure", not "unavailable".


Takashi

> 
> Alex
> 
> >
> > You're saying above that the HDA controller isn't runtime resumed on
> > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > somehow no HPD interrupt is received by the HDA driver?
> >
> > Jim: So far, I do not find any code about audio response HPD in kernel. the HPD interrupt will sent to user mode via uevent, not sure whether audio user mode driver can receive the event or not.
> >
> > Thanks
> > JimQu
> >
> > ________________________________________
> > 发件人: Lukas Wunner <lukas@wunner.de>
> > 发送时间: 2018年7月9日 17:27
> > 收件人: Qu, Jim
> > 抄送: alsa-devel@alsa-project.org; dri-devel@lists.freedesktop.org; Deucher, Alexander; amd-gfx@lists.freedesktop.org
> > 主题: Re: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id
> >
> > On Mon, Jul 09, 2018 at 08:52:33AM +0000, Qu, Jim wrote:
> >> Now, I found the audio device will auto suspend even if the gpu is active,
> >> and if I plug in a HDMI device it also do not resume back.
> >>
> >> 1. Did you encounter similar issue before?
> >> 2. audio will auto suspend as default at beginning of boot, is it expect
> >> behaviour?
> >
> > Yes, that's expected.  Once you start streaming audio to attached displays,
> > user space opens the codec device and this causes the HDA controller to
> > runtime resume.  If the discrete GPU is suspended at that moment, it will
> > be powered on and kept powered on as long as user space is streaming audio.
> >
> > Do you need to runtime resume the HDA controller even if user space isn't
> > streaming audio?  Why, and in which situation exactly?
> >
> > You're saying above that the HDA controller isn't runtime resumed on
> > hotplug of a display.  Is that necessary to retrieve ELD or something?
> > I'm not sure if there's code in the HDA driver to acquire a runtime PM
> > ref on HPD, but maybe it's necessary.  Or maybe the code is there but
> > somehow no HPD interrupt is received by the HDA driver?
> >
> > Thanks,
> >
> > Lukas
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx