All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Mario.Limonciello@dell.com
Cc: kai.heng.feng@canonical.com, mjg59@srcf.ucam.org,
	dvhart@infradead.org, andy@infradead.org, tiwai@suse.com,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
Date: Fri, 9 Mar 2018 10:46:00 +0100	[thread overview]
Message-ID: <20180309094600.m24d3zbzdsmls7aw@pali> (raw)
In-Reply-To: <014795f5a3014cd3bf55de26f76a5af8@ausx13mpc124.AMER.DELL.COM>

On Friday 09 March 2018 09:34:01 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Kai Heng Feng [mailto:kai.heng.feng@canonical.com]
> > Sent: Friday, March 9, 2018 5:30 PM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: mjg59@srcf.ucam.org; dvhart@infradead.org; andy@infradead.org;
> > Limonciello, Mario <Mario_Limonciello@Dell.com>; tiwai@suse.com; platform-
> > driver-x86@vger.kernel.org; Linux Kernel Mailing List <linux-
> > kernel@vger.kernel.org>; alsa-devel@alsa-project.org
> > Subject: Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell
> > platforms with Switchable Graphics
> > 
> > 
> > > On Mar 9, 2018, at 5:02 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Thursday 08 March 2018 17:10:23 Kai-Heng Feng wrote:
> > >> Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option
> > >> "Switchable Graphics" (SG).
> > >>
> > >> When SG is enabled, we have:
> > >> 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
> > >> 00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
> > >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> > >> [AMD/ATI] Ellesmere [Polaris10]
> > >> 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere
> > >> [Radeon RX 580]
> > >>
> > >> The Intel Audio outputs all the sound, including HDMI audio. The audio
> > >> controller comes with AMD graphics doesn't get used.
> > >>
> > >> When SG is disabled, we have:
> > >> 00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
> > >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> > >> [AMD/ATI] Ellesmere [Polaris10]
> > >> 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere
> > >> [Radeon RX 580]
> > >>
> > >> Now it's a typical discrete-only system. HDMI audio comes from AMD audio
> > >> controller, others from Intel audio controller.
> > >>
> > >> When SG is enabled, the unused AMD audio controller still exposes its
> > >> sysfs, so userspace still opens the control file and stream. If
> > >> userspace tries to output sound through the stream, it hangs when
> > >> runtime suspend kicks in:
> > >> [ 12.796265] snd_hda_intel 0000:01:00.1: Disabling via vga_switcheroo
> > >> [ 12.796367] snd_hda_intel 0000:01:00.1: Cannot lock devices!
> > >>
> > >> Since the discrete audio controller isn't useful when SG enabled, we
> > >> should just disable the device.
> > >>
> > >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > >> ---
> > >> v2: Mario suggested to squash the HDA part into the same series.
> > >>
> > >>  sound/pci/hda/hda_intel.c | 35 +++++++++++++++++++++++++++++++++++
> > >>  1 file changed, 35 insertions(+)
> > >>
> > >> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > >> index 96143df19b21..8e3e8b88624a 100644
> > >> --- a/sound/pci/hda/hda_intel.c
> > >> +++ b/sound/pci/hda/hda_intel.c
> > >> @@ -49,6 +49,7 @@
> > >>  #include <linux/clocksource.h>
> > >>  #include <linux/time.h>
> > >>  #include <linux/completion.h>
> > >> +#include <linux/dell-common.h>
> > >>
> > >>  #ifdef CONFIG_X86
> > >>  /* for snoop control */
> > >> @@ -1620,6 +1621,35 @@ static void check_msi(struct azx *chip)
> > >>  	}
> > >>  }
> > >>
> > >> +#if IS_ENABLED(CONFIG_DELL_LAPTOP)
> > >> +static bool check_dell_switchable_gfx(struct pci_dev *pdev)
> > >> +{
> > >> +	static int (*dell_switchable_gfx_enabled_func)(bool *);
> > >> +	bool enabled;
> > >> +	int err;
> > >> +
> > >> +	if (pdev->vendor != PCI_VENDOR_ID_ATI ||
> > >> +	    pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
> > >> +		return false;
> > >
> > > Are you sure that you want to do this check unconditionally on all
> > > machines which have enabled CONFIG_DELL_LAPTOP?
> > >
> > > Subvendor ID_DELL for dell specific code is not suspicious, but ID_ATI
> > > is. What would happen if ATI vendor changes to NVIDIA or other which is
> > > not related to Dell?
> > 
> > We only check it when it's both ATI and DELL, otherwise just return false?
> > 
> > The platform does have a NVIDIA variant, but the discrete NVIDIA have a
> > audio controller, hence it doesn't have the issue.
> > The issue only happens to AMD/ATI configs with "Switchable Graphics" option.
> > 
> 
> Pali is your concern that this code for matching vendor/subsystem is running
> on non-Dell too?  The only other recommendation I think that can be to restrict
> to matching Dell OEM strings in SMBIOS table, but I don't think that's any better
> than the matching for VID/SSVID.

My concern is about adding a new machine specific code into generic
driver, which check is done just by PCI vendor and subvendor.

In future there can be new models or other PCI devices which matches
above condition even they would not have any switchable graphics, nor
they would manufactured by Dell.

Also I can imagine that in future (or maybe already now?) it is possible
to find PCI device which pass above checks and connect this PCI device
into desktop /server / any non-laptop device.

If this switchable graphics solution is specific to dell laptops, then
rather checking for PCI vendor/subvevendor main check, there should be
main check via DMI strings.

Hardware is changing relatively quickly and there is absolutely no
guarantee that e.g. NVIDIA would not start providing audio controller in
similar like AMD and it would be put in those Dell machines.

> > >
> > > Interesting question would be, how handle this situation Windows?
> > 
> > I don't know how this platform handles this on Windows, I guess we need
> > Mario to shed some lights here.
> 
> Sorry I don't have this information to share.   I don't think it's too useful here
> anyway though because Windows driver architecture is much different in this
> area.
> 
> 

-- 
Pali Rohár
pali.rohar@gmail.com

WARNING: multiple messages have this Message-ID (diff)
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Mario.Limonciello@dell.com
Cc: mjg59@srcf.ucam.org, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, tiwai@suse.com,
	platform-driver-x86@vger.kernel.org, kai.heng.feng@canonical.com,
	dvhart@infradead.org, andy@infradead.org
Subject: Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
Date: Fri, 9 Mar 2018 10:46:00 +0100	[thread overview]
Message-ID: <20180309094600.m24d3zbzdsmls7aw@pali> (raw)
In-Reply-To: <014795f5a3014cd3bf55de26f76a5af8@ausx13mpc124.AMER.DELL.COM>

On Friday 09 March 2018 09:34:01 Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Kai Heng Feng [mailto:kai.heng.feng@canonical.com]
> > Sent: Friday, March 9, 2018 5:30 PM
> > To: Pali Rohár <pali.rohar@gmail.com>
> > Cc: mjg59@srcf.ucam.org; dvhart@infradead.org; andy@infradead.org;
> > Limonciello, Mario <Mario_Limonciello@Dell.com>; tiwai@suse.com; platform-
> > driver-x86@vger.kernel.org; Linux Kernel Mailing List <linux-
> > kernel@vger.kernel.org>; alsa-devel@alsa-project.org
> > Subject: Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell
> > platforms with Switchable Graphics
> > 
> > 
> > > On Mar 9, 2018, at 5:02 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Thursday 08 March 2018 17:10:23 Kai-Heng Feng wrote:
> > >> Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option
> > >> "Switchable Graphics" (SG).
> > >>
> > >> When SG is enabled, we have:
> > >> 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
> > >> 00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
> > >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> > >> [AMD/ATI] Ellesmere [Polaris10]
> > >> 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere
> > >> [Radeon RX 580]
> > >>
> > >> The Intel Audio outputs all the sound, including HDMI audio. The audio
> > >> controller comes with AMD graphics doesn't get used.
> > >>
> > >> When SG is disabled, we have:
> > >> 00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
> > >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> > >> [AMD/ATI] Ellesmere [Polaris10]
> > >> 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere
> > >> [Radeon RX 580]
> > >>
> > >> Now it's a typical discrete-only system. HDMI audio comes from AMD audio
> > >> controller, others from Intel audio controller.
> > >>
> > >> When SG is enabled, the unused AMD audio controller still exposes its
> > >> sysfs, so userspace still opens the control file and stream. If
> > >> userspace tries to output sound through the stream, it hangs when
> > >> runtime suspend kicks in:
> > >> [ 12.796265] snd_hda_intel 0000:01:00.1: Disabling via vga_switcheroo
> > >> [ 12.796367] snd_hda_intel 0000:01:00.1: Cannot lock devices!
> > >>
> > >> Since the discrete audio controller isn't useful when SG enabled, we
> > >> should just disable the device.
> > >>
> > >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > >> ---
> > >> v2: Mario suggested to squash the HDA part into the same series.
> > >>
> > >>  sound/pci/hda/hda_intel.c | 35 +++++++++++++++++++++++++++++++++++
> > >>  1 file changed, 35 insertions(+)
> > >>
> > >> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > >> index 96143df19b21..8e3e8b88624a 100644
> > >> --- a/sound/pci/hda/hda_intel.c
> > >> +++ b/sound/pci/hda/hda_intel.c
> > >> @@ -49,6 +49,7 @@
> > >>  #include <linux/clocksource.h>
> > >>  #include <linux/time.h>
> > >>  #include <linux/completion.h>
> > >> +#include <linux/dell-common.h>
> > >>
> > >>  #ifdef CONFIG_X86
> > >>  /* for snoop control */
> > >> @@ -1620,6 +1621,35 @@ static void check_msi(struct azx *chip)
> > >>  	}
> > >>  }
> > >>
> > >> +#if IS_ENABLED(CONFIG_DELL_LAPTOP)
> > >> +static bool check_dell_switchable_gfx(struct pci_dev *pdev)
> > >> +{
> > >> +	static int (*dell_switchable_gfx_enabled_func)(bool *);
> > >> +	bool enabled;
> > >> +	int err;
> > >> +
> > >> +	if (pdev->vendor != PCI_VENDOR_ID_ATI ||
> > >> +	    pdev->subsystem_vendor != PCI_VENDOR_ID_DELL)
> > >> +		return false;
> > >
> > > Are you sure that you want to do this check unconditionally on all
> > > machines which have enabled CONFIG_DELL_LAPTOP?
> > >
> > > Subvendor ID_DELL for dell specific code is not suspicious, but ID_ATI
> > > is. What would happen if ATI vendor changes to NVIDIA or other which is
> > > not related to Dell?
> > 
> > We only check it when it's both ATI and DELL, otherwise just return false?
> > 
> > The platform does have a NVIDIA variant, but the discrete NVIDIA have a
> > audio controller, hence it doesn't have the issue.
> > The issue only happens to AMD/ATI configs with "Switchable Graphics" option.
> > 
> 
> Pali is your concern that this code for matching vendor/subsystem is running
> on non-Dell too?  The only other recommendation I think that can be to restrict
> to matching Dell OEM strings in SMBIOS table, but I don't think that's any better
> than the matching for VID/SSVID.

My concern is about adding a new machine specific code into generic
driver, which check is done just by PCI vendor and subvendor.

In future there can be new models or other PCI devices which matches
above condition even they would not have any switchable graphics, nor
they would manufactured by Dell.

Also I can imagine that in future (or maybe already now?) it is possible
to find PCI device which pass above checks and connect this PCI device
into desktop /server / any non-laptop device.

If this switchable graphics solution is specific to dell laptops, then
rather checking for PCI vendor/subvevendor main check, there should be
main check via DMI strings.

Hardware is changing relatively quickly and there is absolutely no
guarantee that e.g. NVIDIA would not start providing audio controller in
similar like AMD and it would be put in those Dell machines.

> > >
> > > Interesting question would be, how handle this situation Windows?
> > 
> > I don't know how this platform handles this on Windows, I guess we need
> > Mario to shed some lights here.
> 
> Sorry I don't have this information to share.   I don't think it's too useful here
> anyway though because Windows driver architecture is much different in this
> area.
> 
> 

-- 
Pali Rohár
pali.rohar@gmail.com
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2018-03-09  9:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08  9:10 [PATCH v2 1/3] dell-led: Change dell-led.h to dell-common.h Kai-Heng Feng
2018-03-08  9:10 ` [PATCH v2 2/3] platform/x86: dell-*: Add interface for switchable graphics status query Kai-Heng Feng
2018-03-08 16:38   ` Pali Rohár
2018-03-08 16:38     ` Pali Rohár
2018-03-09  8:14     ` Kai Heng Feng
2018-03-08  9:10 ` [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics Kai-Heng Feng
2018-03-08  9:38   ` [alsa-devel] " Lukas Wunner
2018-03-08 10:38     ` Kai Heng Feng
2018-03-08 10:38       ` Kai Heng Feng
2018-03-08 11:30       ` [alsa-devel] " Lukas Wunner
2018-03-08 11:30         ` Lukas Wunner
2018-03-09  8:22         ` [alsa-devel] " Kai Heng Feng
2018-03-09  9:02   ` Pali Rohár
2018-03-09  9:02     ` Pali Rohár
2018-03-09  9:30     ` Kai Heng Feng
2018-03-09  9:34       ` Mario.Limonciello
2018-03-09  9:34         ` Mario.Limonciello
2018-03-09  9:46         ` Pali Rohár [this message]
2018-03-09  9:46           ` Pali Rohár
2018-03-09  9:59           ` Mario.Limonciello
2018-03-09  9:59             ` Mario.Limonciello
2018-03-10 10:38             ` Pali Rohár
2018-03-10 10:38               ` Pali Rohár
2018-03-11 14:03               ` Mario.Limonciello
2018-03-11 14:03                 ` Mario.Limonciello
2018-03-11 14:30                 ` Pali Rohár
2018-03-11 14:30                   ` Pali Rohár
2018-03-12  1:30                   ` Mario.Limonciello
2018-03-12  1:30                     ` Mario.Limonciello
2018-03-13  7:56                     ` Kai Heng Feng
2018-03-13  7:56                       ` Kai Heng Feng
2018-03-13  8:13                       ` Mario.Limonciello
2018-03-13  8:13                         ` Mario.Limonciello
2018-03-10  6:50       ` Lukas Wunner
2018-03-10  6:50         ` Lukas Wunner
2018-03-10 10:40         ` Pali Rohár
2018-03-10 10:40           ` Pali Rohár
2018-03-11 14:06         ` Mario.Limonciello
2018-03-11 14:06           ` Mario.Limonciello
2018-03-13  8:24         ` Kai Heng Feng
2018-04-07 16:44 ` [PATCH v2 1/3] dell-led: Change dell-led.h to dell-common.h Darren Hart
2018-04-07 16:44   ` Darren Hart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180309094600.m24d3zbzdsmls7aw@pali \
    --to=pali.rohar@gmail.com \
    --cc=Mario.Limonciello@dell.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.