From: Lukas Wunner <lukas@wunner.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook
Date: Sun, 9 Oct 2016 17:03:12 +0200 [thread overview]
Message-ID: <20161009150312.GA8487@wunner.de> (raw)
In-Reply-To: <1476015997.11323.347.camel@linux.intel.com>
On Sun, Oct 09, 2016 at 03:26:37PM +0300, Andy Shevchenko wrote:
> On Sat, 2016-10-08 at 15:49 +0200, Lukas Wunner wrote:
> > I'm not familiar at all with Intel MID devices, do
> > you have a way to clearly identify if a PCI device is power managed
> > by the PWRMU versus PMCSR? My guess is that at the very least,
> > intel_mid_pwr_get_lss_id() needs to be called and false needs to
> > be returned by mid_pci_power_manageable() if the return value is
> > negative.
>
> PCI bus is kinda fake on those platforms (which implement SFI) and don't
> always follow [PCI] specification. The vendor register represents so
> called Logical Subsystem ID of the device in question. Some of them are
> related to PWRMU, some to P-Unit, some just has no such register.
>
> In PWRMU/P-Unit cases PMCSR is present and writing to it is needed.
> For the rest I don't remember what is actual state, perhaps writing is
> just ignored and OS reads D0 all the time from it.
For devices with PM mechanisms not covered by the standard PCI code
(or ACPI platform code), a common pattern is to assign them a struct
dev_pm_domain using dev_pm_domain_set(). Then on suspend you'd
invoke the PCI bus suspend hook and afterwards ask the PWRMU to
power down. On resume you'd first power up using the PWRMU, then
call the PCI bus resume hook. See drivers/gpu/vga/vga_switcheroo.c:
vga_switcheroo_init_domain_pm_ops() for an example. This would have
been an alternative approach to introducing a new PCI platform for
these devices. I'm not sure which approach is more suitable, it's
just something that crossed my mind when looking at this.
Best regards,
Lukas
next prev parent reply other threads:[~2016-10-09 15:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 6:24 [PATCH 0/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops Lukas Wunner
2016-10-06 6:24 ` [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook Lukas Wunner
2016-10-07 20:55 ` Andy Shevchenko
2016-10-08 13:49 ` Lukas Wunner
2016-10-09 12:26 ` Andy Shevchenko
2016-10-09 15:03 ` Lukas Wunner [this message]
2016-10-10 10:54 ` Andy Shevchenko
2016-10-09 10:46 ` Lukas Wunner
2016-10-09 11:57 ` Andy Shevchenko
2016-10-09 12:49 ` Lukas Wunner
2016-10-07 20:55 ` [PATCH 0/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops Andy Shevchenko
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=20161009150312.GA8487@wunner.de \
--to=lukas@wunner.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).