From: Chen Yu <yu.c.chen@intel.com>
To: Lukas Wunner <lukas@wunner.de>, Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
Arnd Bergmann <arnd@arndb.de>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH][RFC] PCI: Workaround to enable poweroff on Mac Pro 11
Date: Tue, 31 May 2016 11:29:39 +0800 [thread overview]
Message-ID: <574D0523.3020009@intel.com> (raw)
In-Reply-To: <20160530221123.GA13535@wunner.de>
Hi Lukas,
On 2016年05月31日 06:11, Lukas Wunner wrote:
> On Mon, May 30, 2016 at 04:33:05PM -0500, Bjorn Helgaas wrote:
>> On Mon, May 30, 2016 at 06:33:24PM +0800, Chen Yu wrote:
>>> Currently there are many people reported that they can not
>>> do a poweroff nor a suspend to memory on their Mac Pro 11.
>>> After some investigations it was found that, once the PCI bridge
>>> 0000:00:1c.0 reassigns its mm windows([mem 0x7fa00000-0x7fbfffff]
>>> and [mem 0x7fc00000-0x7fdfffff 64bit pref]), the region of ACPI
>>> io resource 0x1804 becomes unaccessible immediately, where the
>>> ACPI Sleep register is located, as a result neither poweroff(S5)
>>> nor suspend to memory(S3) works.
>>>
>>> I don't know why setting the base/limit of PCI bridge mem resource
>>> would affect another io resource region, so this quirk just simply
>>> bypass the assignment of these mm resources on 0000:00:1c.0, by
>>> resetting the resource flag to 0 before updating the base/limit registers.
>>> This patch also introduces a new pci fixup phase before the actual bridge
>>> resource assignment.
>> Split the new fixup phase into a separate patch.
>>
>> I'm doubtful about this because we don't understand the root cause.
> Agreed.
>
>
>>> +}
>>> +DECLARE_PCI_FIXUP_ASSIGN(PCI_VENDOR_ID_INTEL, 0x8c10, quirk_mac_disable_mmio_bar);
>> Is this device *only* used on the Mac Pro 11? http://pci-ids.ucs.cz
>> says "8 Series/C220 Series Chipset Family PCI Express Root Port #1",
>> which sounds pretty generic.
> It's a root port of a standard Haswell chipset.
>
> This concerns the Mac*Book*Pro11 (not MacPro11), and apparently only
> the two models introduced 2015, MacBookPro11,4 and MacBookPro11,5
> (can be queried with DMI). I've never heard of issues like this on the
> 2013/2014 models (MacBookPro11,1 to 11,3).
>
> Looking at the lspci output of the MacBookPro11,4 I notice that the
> root port in question, 00:1c.0, has secondary bus 02 below it, but
> there are no devices listed on that bus:
> https://bugzilla.kernel.org/attachment.cgi?id=218181
>
> On the MacBookPro11,5, there's bus 03 below that port, but likewise
> without any devices:
> https://launchpadlibrarian.net/222477783/Lspci.txt
>
> It looks like this root port is unused, so perhaps the best option
> is to disable it as if it were an appendix. I.e., don't scan it at all,
> put it into D3 and leave it alone.
I used to bypass the probe for this pci bridge:
https://bugzilla.kernel.org/attachment.cgi?id=216661
, but it looks like although poweroff works however
the wifi and facetime are broken:
https://bugzilla.kernel.org/show_bug.cgi?id=103211#c109
Thanks,
Yu
next prev parent reply other threads:[~2016-05-31 3:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 10:33 [PATCH][RFC] PCI: Workaround to enable poweroff on Mac Pro 11 Chen Yu
2016-05-30 21:33 ` Bjorn Helgaas
2016-05-30 21:33 ` Bjorn Helgaas
2016-05-30 22:11 ` Lukas Wunner
2016-05-31 3:29 ` Chen Yu [this message]
2016-05-31 3:24 ` Chen Yu
2016-05-31 7:00 ` Yinghai Lu
2016-05-31 7:18 ` Chen Yu
2016-05-31 7:18 ` Chen Yu
2016-05-31 13:16 ` Bjorn Helgaas
2016-05-31 13:16 ` Bjorn Helgaas
2016-06-08 4:31 ` Chen Yu
2016-06-08 4:31 ` Chen Yu
2016-06-08 12:47 ` Bjorn Helgaas
2016-06-09 16:50 ` Bjorn Helgaas
2016-06-09 16:50 ` Bjorn Helgaas
2016-06-09 17:04 ` Bjorn Helgaas
2016-06-09 17:04 ` Bjorn Helgaas
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=574D0523.3020009@intel.com \
--to=yu.c.chen@intel.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael@kernel.org \
--cc=yinghai@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).