On Wed, Dec 03, 2014 at 06:01:33PM -0800, Yinghai Lu wrote:
> On Wed, Dec 3, 2014 at 2:15 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
> > In v3.16 (which does contain 5b28541552ef), when pbus_size_mem() sizes
> > the 64-bit prefetchable window, it only looks for downstream 64-bit
> > resources. Since the radeon at 01:00.0 has none, we size the window
> > to 0 + 0x200000 (the 0x200000 part is pci_hotplug_mem_size, to
> > accommodate future hot-added devices).
> >
> > But that's not big enough to hold the radeon BAR 0 [mem
> > 0xc0000000-0xcfffffff pref], so BAR 0 remains unassigned, so
> > pci_enable_device() should fail, and radeon doesn't work.
> >
> > I don't know what the best fix is, but I think it's probably too
> > aggressive to *never* use a 64-bit prefetchable window for downstream
> > 32-bit prefetchable resources. This configuration from BIOS should
> > just work without us changing anything (although we probably should
> > trim the window to start at 0xc0000000, which would still work).
>
> pci=realloc should workaround the problem, as it would take control of
> the bridge mmio BAR, and allocate more range for mmio pref under it.
I don't think pci=realloc is the answer because
1) It's a poor user experience. We should be able to handle this
automatically, without asking the user to do anything.
2) It puts the radeon framebuffer in the non-prefetchable window, and we
should be able to keep it in the prefetchable window.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
