From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: bjorn@helgaas.com
Cc: linux-pci@vger.kernel.org,
Mika Westerberg <mika.westerberg@linux.intel.com>,
AceLan Kao <acelan@gmail.com>,
Kai-Heng Feng <kai.heng.feng@canonical.com>
Subject: Re: Fwd: [Bug 203485] New: PCI can't map correct memory resource if the BAR is 64-bit and then leads to system hang during booting up
Date: Thu, 16 May 2019 11:45:07 +0300 [thread overview]
Message-ID: <20190516084507.GW9224@smile.fi.intel.com> (raw)
In-Reply-To: <CABhMZUWcS0x+E42T3dqzio72wea32pr2GuULXc=+62T+rLAgmQ@mail.gmail.com>
On Wed, May 15, 2019 at 02:26:13PM -0500, Bjorn Helgaas wrote:
> I should have forwarded this to the list earlier. Maybe somebody
> wants to work on this?
>
> I *think* the problem is:
>
> - BIOS sets MTRR for 0x40_00000000-0x5f_ffffffff to be write-combining (WC)
> - That covers part of this PCI aperture: root bus resource [mem
> 0x40_00000000-0x7f_ffffffff window]
> - That aperture includes a frame buffer: pci 0000:00:02.0: reg 0x18:
> [mem 0x40_00000000-0x40_0fffffff 64bit pref]
> - Linux assigned an LPSS BAR to the WC area: pci 0000:00:15.0: BAR
> 0: assigned [mem 0x40_10000000-0x40_10000fff 64bit]
> - The LPSS device doesn't work if MMIO accesses to it are combined via WC
>
> I'm not an x86/MTRR/PAT expert, but I think we should be able to make
> this work correctly by changing that MTRR from WC to UC (I don't know
> if there are BIOS/OS interface implications with this), or maybe using
> PAT to override the MTRR WC setting to be UC for part or all of that
> aperture. The frame buffer driver should be smart enough to request
> WC if it wants it.
The window for the PCI resources, provided by PCI Root Bridge, may be split to
many parts as described by _CRS in ACPI, and BIOS should be consistent in
providing both.
I believe there is no issue with Linux in current state. Be "smart" here might
give a downside(s) like reducing coverage to test exactly something as above
BIOS issue.
My 2 cents.
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2019-05-16 8:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-203485-193951@https.bugzilla.kernel.org/>
2019-05-15 19:26 ` Fwd: [Bug 203485] New: PCI can't map correct memory resource if the BAR is 64-bit and then leads to system hang during booting up Bjorn Helgaas
2019-05-16 8:45 ` Andy Shevchenko [this message]
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=20190516084507.GW9224@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=acelan@gmail.com \
--cc=bjorn@helgaas.com \
--cc=kai.heng.feng@canonical.com \
--cc=linux-pci@vger.kernel.org \
--cc=mika.westerberg@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox