All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Kedar A Dongre <kedar.a.dongre@intel.com>,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH] PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports
Date: Wed, 19 Dec 2018 18:09:15 +0100	[thread overview]
Message-ID: <20181219170915.3bojdcf7h7kiesyu@wunner.de> (raw)
In-Reply-To: <20181219151558.GU2469@lahna.fi.intel.com>

On Wed, Dec 19, 2018 at 05:15:58PM +0200, Mika Westerberg wrote:
> On Wed, Dec 19, 2018 at 08:45:19AM -0600, Bjorn Helgaas wrote:
> > On Wed, Dec 19, 2018 at 03:23:24PM +0200, Mika Westerberg wrote:
> > > On Tue, Dec 18, 2018 at 02:58:50PM -0600, Bjorn Helgaas wrote:
> > > > > > For example, it looks like PCI_EXP_FLAGS_SLOT is set, but Linux
> > > > > > basically ignores it.  Maybe if PCI_EXP_FLAGS_SLOT is set but we
> > > > > > aren't using pciehp, we should assume any hotplug would be handled via
> > > > > > acpiphp?  And in that case, we should avoid doing anything that would
> > > > > > prevent platform firmware from enumerating things below the bridge?
> > > 
> > > Actually it looks like it would break power management of other
> > > components such as xHCI and Thunderbolt controller which are connected
> > > to a downstream port that has "Slot implemented" set as well.
> > 
> > To be precise, I think you mean that if we avoided power management on
> > ports with "Slot Implemented", ports leading to xHCI and Thunderbolt
> > would consume more power but would work correctly, right?  And the
> > theory is that those ports work even if the OS puts them into D3
> > because the firmware is smart enough to wake them up before poking
> > things below them?  Doesn't that make the port's power state out of
> > sync with what the OS thinks it is?
> 
> I think better example where this fails is normal Thunderbolt device
> (not host) which includes PCIe switch and there is an PCIe endpoint, say
> network interface connected to one of the downstream ports. That
> downstream port has "Slot implemented" set but is not hotplug capable.
> 
> So the device would work correctly but if you take the recent "Runtime
> D3, RTD3" system such as Lenovo Carbon X1 6th gen it keeps the whole
> PCIe hierarchy from entering D3cold. I would rather not to break that ;-)

Yeah but as you say, those are Downstream Ports.  What if you constrain
it to Root Ports?

Thanks,

Lukas

  reply	other threads:[~2018-12-19 17:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 11:20 [PATCH] PCI: Blacklist power management of Gigabyte X299 DESIGNARE EX PCIe ports Mika Westerberg
2018-12-04 17:55 ` Rafael J. Wysocki
2018-12-04 18:34   ` Mika Westerberg
2018-12-04 20:40 ` Lukas Wunner
2018-12-05  9:20   ` Mika Westerberg
2018-12-05  9:48     ` Lukas Wunner
2018-12-05 10:40       ` Mika Westerberg
2018-12-05 13:22         ` Lukas Wunner
2018-12-05 13:46           ` Mika Westerberg
2018-12-14  9:24 ` Mika Westerberg
2018-12-17 20:28 ` Bjorn Helgaas
2018-12-18  8:55   ` Mika Westerberg
2018-12-18 20:58     ` Bjorn Helgaas
2018-12-19 13:23       ` Mika Westerberg
2018-12-19 14:45         ` Bjorn Helgaas
2018-12-19 15:15           ` Mika Westerberg
2018-12-19 17:09             ` Lukas Wunner [this message]
2018-12-20 10:06               ` Mika Westerberg
2018-12-20 10:23                 ` Rafael J. Wysocki

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=20181219170915.3bojdcf7h7kiesyu@wunner.de \
    --to=lukas@wunner.de \
    --cc=helgaas@kernel.org \
    --cc=kedar.a.dongre@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rjw@rjwysocki.net \
    /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.