All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
To: Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Rafael J. Wysocki"
	<rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Takashi Iwai <tiwai-IBi9RG/b67k@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Jaroslav Kysela <perex-/Fr2/VpizcU@public.gmane.org>,
	Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Bastien Nocera <hadess-0MeiytkfxGOsTnJN9+BGXg@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
	Dave Airlie <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH 5/7] vga_switcheroo: Use device link for HDA controller
Date: Fri, 23 Feb 2018 10:51:47 +0100	[thread overview]
Message-ID: <20180223095147.GB17092@wunner.de> (raw)
In-Reply-To: <20180220222059.GD32228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>

On Tue, Feb 20, 2018 at 04:20:59PM -0600, Bjorn Helgaas wrote:
> On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> > The device link is added in a PCI quirk rather than in hda_intel.c.
> > It is therefore legal for the GPU to runtime suspend to D3cold even if
> > the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
> > is not enabled, for accesses to the HDA controller will cause the GPU to
> > wake up regardless if they're occurring outside of hda_intel.c (think
> > config space readout via sysfs).
> 
> I guess this GPU wakeup happens *if* the path accessing the HDA
> controller calls pm_runtime_get_sync() or similar, right?

Right.

> We do have
> that in the sysfs config accessors via pci_config_pm_runtime_get(),
> but not in the sysfs mmap paths.  I think that's a latent PCI core
> defect independent of this series.

Yes, there may be a few places where the parent of the device is
erroneously not runtime resumed when sysfs files are accessed.
I've never used the sysfs mmap feature, so never witnessed issues
with it.

> We also don't have that in PCI core config accessors.  That maybe
> doesn't matter because the core probably shouldn't be touching devices
> after enumeration (although there might be holes there for things like
> ASPM where a sysfs file can cause reconfiguration of several devices).

I assume with PCI core config accessors you're referring to
pci_read_config_word() and friends?  Those are arguably hotpaths
where we wouldn't want the overhead to check runtime PM status
everytime.  They might also be called from atomic context, I'm
not sure, and the runtime PM callbacks may sleep by default
(unless pm_runtime_irq_safe() was called).

> > +static void quirk_gpu_hda(struct pci_dev *hda)
> > +{
> > +	struct pci_dev *gpu = NULL;
> > +
> > +	if (PCI_FUNC(hda->devfn) != 1)
> > +		return;
> > +
> > +	gpu = pci_get_domain_bus_and_slot(pci_domain_nr(hda->bus),
> 
> Unnecessary initialization.

Thanks for spotting this, it's a remnant of an earlier version of the
patch which called pci_dev_put(gpu) in the (PCI_FUNC(hda->devfn) != 1)
case.

Best regards,

Lukas
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: dri-devel@lists.freedesktop.org, Peter Wu <peter@lekensteyn.nl>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>,
	nouveau@lists.freedesktop.org, Ben Skeggs <bskeggs@redhat.com>,
	Lyude Paul <lyude@redhat.com>,
	Hans de Goede <hdegoede@redhat.com>,
	alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.com>,
	Jaroslav Kysela <perex@perex.cz>,
	linux-pm@vger.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Pierre Moreau <pierre.morrow@free.fr>,
	Bastien Nocera <hadess@hadess.net>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 5/7] vga_switcheroo: Use device link for HDA controller
Date: Fri, 23 Feb 2018 10:51:47 +0100	[thread overview]
Message-ID: <20180223095147.GB17092@wunner.de> (raw)
In-Reply-To: <20180220222059.GD32228@bhelgaas-glaptop.roam.corp.google.com>

On Tue, Feb 20, 2018 at 04:20:59PM -0600, Bjorn Helgaas wrote:
> On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> > The device link is added in a PCI quirk rather than in hda_intel.c.
> > It is therefore legal for the GPU to runtime suspend to D3cold even if
> > the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
> > is not enabled, for accesses to the HDA controller will cause the GPU to
> > wake up regardless if they're occurring outside of hda_intel.c (think
> > config space readout via sysfs).
> 
> I guess this GPU wakeup happens *if* the path accessing the HDA
> controller calls pm_runtime_get_sync() or similar, right?

Right.

> We do have
> that in the sysfs config accessors via pci_config_pm_runtime_get(),
> but not in the sysfs mmap paths.  I think that's a latent PCI core
> defect independent of this series.

Yes, there may be a few places where the parent of the device is
erroneously not runtime resumed when sysfs files are accessed.
I've never used the sysfs mmap feature, so never witnessed issues
with it.

> We also don't have that in PCI core config accessors.  That maybe
> doesn't matter because the core probably shouldn't be touching devices
> after enumeration (although there might be holes there for things like
> ASPM where a sysfs file can cause reconfiguration of several devices).

I assume with PCI core config accessors you're referring to
pci_read_config_word() and friends?  Those are arguably hotpaths
where we wouldn't want the overhead to check runtime PM status
everytime.  They might also be called from atomic context, I'm
not sure, and the runtime PM callbacks may sleep by default
(unless pm_runtime_irq_safe() was called).

> > +static void quirk_gpu_hda(struct pci_dev *hda)
> > +{
> > +	struct pci_dev *gpu = NULL;
> > +
> > +	if (PCI_FUNC(hda->devfn) != 1)
> > +		return;
> > +
> > +	gpu = pci_get_domain_bus_and_slot(pci_domain_nr(hda->bus),
> 
> Unnecessary initialization.

Thanks for spotting this, it's a remnant of an earlier version of the
patch which called pci_dev_put(gpu) in the (PCI_FUNC(hda->devfn) != 1)
case.

Best regards,

Lukas

  parent reply	other threads:[~2018-02-23  9:51 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-18  8:38 [PATCH 0/7] Modernize vga_switcheroo by using device link for HDA Lukas Wunner
2018-02-18  8:38 ` Lukas Wunner
2018-02-18  8:38 ` [PATCH 4/7] vga_switcheroo: Deduplicate power state tracking Lukas Wunner
2018-02-18  8:38 ` [PATCH 2/7] PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public Lukas Wunner
     [not found]   ` <9d36522bc3d7e0ed1c1d5f653514d9fb0d34c0a8.1518941073.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-22 17:45     ` Bjorn Helgaas
2018-02-22 17:45       ` Bjorn Helgaas
2018-02-18  8:38 ` [PATCH 7/7] drm/nouveau: Runtime suspend despite HDA being unbound Lukas Wunner
2018-02-18  8:38 ` [PATCH 5/7] vga_switcheroo: Use device link for HDA controller Lukas Wunner
     [not found]   ` <99358da18f1c61b226678c7c70240e4407ac575b.1518941073.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-20 22:20     ` Bjorn Helgaas
2018-02-20 22:20       ` Bjorn Helgaas
     [not found]       ` <20180220222059.GD32228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2018-02-23  9:51         ` Lukas Wunner [this message]
2018-02-23  9:51           ` Lukas Wunner
     [not found]           ` <20180223095147.GB17092-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-23 14:23             ` Bjorn Helgaas
2018-02-23 14:23               ` Bjorn Helgaas
2018-02-18  8:38 ` [PATCH 3/7] vga_switcheroo: Update PCI current_state on power change Lukas Wunner
2018-02-18  8:38 ` [PATCH 6/7] vga_switcheroo: Let HDA autosuspend on mux change Lukas Wunner
     [not found] ` <cover.1518941072.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-18  8:38   ` [PATCH 1/7] PCI: Restore BARs on runtime resume despite being unbound Lukas Wunner
2018-02-18  8:38     ` Lukas Wunner
     [not found]     ` <f7593132608eb9a83d7268cc5b3ef12b3dd9c52d.1518941073.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2018-02-19  9:49       ` Rafael J. Wysocki
2018-02-19  9:49         ` Rafael J. Wysocki
2018-02-20 21:29     ` Bjorn Helgaas
2018-02-20 21:29       ` Bjorn Helgaas
     [not found]       ` <20180220212922.GC32228-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
2018-02-21  9:57         ` Rafael J. Wysocki
2018-02-21  9:57           ` Rafael J. Wysocki
2018-02-21 12:39           ` Rafael J. Wysocki
2018-02-21 12:39             ` Rafael J. Wysocki
2018-02-25  8:59             ` Lukas Wunner
2018-02-25  8:59               ` Lukas Wunner
2018-02-25  9:31               ` Takashi Iwai
2018-02-25  9:31                 ` Takashi Iwai
2018-02-24 16:26           ` Lukas Wunner
2018-02-25 23:24 ` [PATCH 0/7] Modernize vga_switcheroo by using device link for HDA Mike Lothian
2018-02-25 23:24   ` Mike Lothian

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=20180223095147.GB17092@wunner.de \
    --to=lukas-jfq808j9c/izqb+pc5nmwq@public.gmane.org \
    --cc=airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=hadess-0MeiytkfxGOsTnJN9+BGXg@public.gmane.org \
    --cc=hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=perex-/Fr2/VpizcU@public.gmane.org \
    --cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=tiwai-IBi9RG/b67k@public.gmane.org \
    /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.