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
WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <bhelgaas@google.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Airlie <airlied@linux.ie>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Matthew Garrett <mjg59@coreos.com>,
Daniel Vetter <daniel.vetter@intel.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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-04-23 21:30 UTC|newest]
Thread overview: 28+ 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-20 3:32 ` Dave Airlie
2015-04-21 16:07 ` Linus Torvalds
2015-04-21 16:07 ` Linus Torvalds
2015-04-21 21:12 ` Bjorn Helgaas
2015-04-21 21:12 ` Bjorn Helgaas
2015-04-23 21:30 ` Bjorn Helgaas [this message]
2015-04-23 21:30 ` Bjorn Helgaas
2015-04-23 21:56 ` Matthew Garrett
2015-04-23 22:47 ` Linus Torvalds
2015-04-23 22:47 ` Linus Torvalds
2015-04-23 22:59 ` Matthew Garrett
2015-04-24 0:55 ` Alex Deucher
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-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:06 ` Ander Conselvan De Oliveira
2015-06-08 8:29 ` 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:36 ` Ander Conselvan De Oliveira
2015-06-08 10:50 ` [PATCH] drm/i915: Properly initialize SDVO analog connectors Jani Nikula
2015-06-08 10:50 ` 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 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.