From: Bjorn Helgaas <bhelgaas@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Matthew Garrett <mjg59@coreos.com>
Subject: Re: git pull] drm for v4.1-rc1
Date: Thu, 23 Apr 2015 16:30:15 -0500 [thread overview]
Message-ID: <20150423213015.GA7888@google.com> (raw)
In-Reply-To: <CA+55aFyVMfTBB0oz_yx8+eQOEJnzGtCsYSj9QuhEpdZ9BHdq5A@mail.gmail.com>
[+cc Matthew]
On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
> pci_bus 0000:01: Allocating resources
> pci_bus 0000:02: Allocating resources
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
> i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
>
> That resource is complete garbage. "flags 0x2" is not even a valid
> flag value. I'm *guessing* it might be IORESOURCE_ROM_SHADOW, but if
> that is valid, then it should also have have had the IORESOURCE_MEM
> bit, and it doesn't.
Your i915 does not have a ROM BAR in hardware. If the default video
device has no ROM BAR, pci_fixup_video() sets IORESOURCE_ROM_SHADOW
even though the resource flags are zero because the BAR itself doesn't
exist.
If IORESOURCE_ROM_SHADOW is set, pci_map_rom() assumes there's a
shadow ROM image at 0xC0000. Is there a shadow image even if the
device itself doesn't have a ROM BAR?
We could fabricate a resource even if the BAR doesn't exist, e.g.,
"flags = IORESOURCE_MEM | ... | IORESOURCE_ROM_SHADOW", but that
would be ugly and error-prone in other places that use the ROM.
Matthew added dev->rom for ROM images supplied by the platform
(84c1b80e3263 ("PCI: Add support for non-BAR ROMs")). A shadow
image seems like a similar thing. I think it would be cleaner to get
rid of IORESOURCE_ROM_SHADOW altogether and instead set "dev->rom =
0xC0000" if there's a shadow image, e.g.:
int pcibios_add_device(struct pci_dev *dev)
{
if (dev-is-default-vga-device) {
dev->rom = 0xC0000;
dev->romlen = 0x20000;
}
pa_data = boot_params.hdr.setup_data;
while (pa_data) {
...
if (data->type == SETUP_PCI) {
rom = (struct pci_setup_rom *)data;
if (dev-is-rom-dev) {
dev->rom = ...
dev->romlen = rom->pcilen;
}
}
}
But the rules for figuring out which image to use seem ...
complicated.
Bjorn
next prev parent reply other threads:[~2015-04-23 21:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-20 3:32 git pull] drm for v4.1-rc1 Dave Airlie
2015-04-21 16:07 ` Linus Torvalds
2015-04-21 21:12 ` Bjorn Helgaas
2015-04-23 21:30 ` Bjorn Helgaas [this message]
2015-04-23 21:56 ` Matthew Garrett
2015-04-23 22:47 ` Linus Torvalds
2015-04-23 22:59 ` Matthew Garrett
2015-04-24 0:55 ` Alex Deucher
2015-06-05 21:18 ` Stefan Lippers-Hollmann
2015-06-06 23:52 ` Ville Syrjälä
2015-06-07 2:32 ` Stefan Lippers-Hollmann
2015-06-08 8:06 ` Ander Conselvan De Oliveira
2015-06-08 8:29 ` Ander Conselvan De Oliveira
2015-06-08 10:28 ` Stefan Lippers-Hollmann
2015-06-08 8:26 ` [PATCH] drm/i915: Properly initialize SDVO analog connectors Ander Conselvan de Oliveira
2015-06-08 10:36 ` [Fwd: Re: [PATCH] drm/i915: Properly initialize SDVO analog connectors] Ander Conselvan De Oliveira
2015-06-08 10:50 ` [PATCH] drm/i915: Properly initialize SDVO analog connectors Jani Nikula
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=20150423213015.GA7888@google.com \
--to=bhelgaas@google.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mjg59@coreos.com \
--cc=torvalds@linux-foundation.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