Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs)

[Yinghai Lu]

On 01/27/2010 01:02 PM, Jesse Barnes wrote:
> On Wed, 27 Jan 2010 12:59:05 -0800
> Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote:
> 
>> On Wed, 27 Jan 2010 12:50:12 -0800 (PST)
>> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>>
>>>
>>> On Wed, 27 Jan 2010, Bjorn Helgaas wrote:
>>>>
>>>> Without intel_bus.c, we essentially assume config 1 all the time.
>>>> If we keep intel_bus.c and this patch for .33, things should work
>>>> for configs 1 and 4.  Adding support for config 4 is good.
>>>
>>> Quite frankly, is there any major downside to just disabling/removing 
>>> intel_bus.c for 2.6.33? If we're not planning on having it in the long run 
>>> anyway - or even if we are, but we can't be really happy about the state 
>>> of it as it would be in 2.6.33, not using it at all seems to be the 
>>> smaller headache.
>>>
>>> The machines that it helps are also the machines where you can fix things 
>>> up with 'use_csr', no? And they are pretty rare, and they didn't use to 
>>> work without that use_csr in 2.6.32 either, so it's not even a regression.
>>>
>>> Am I missing something?
>>
>> No that's the plan.  intel_bus.c was a good effort, but it's just too
>> different from what Windows does, and it'll always be behind.  We'll
>> disable it for 2.6.33 and try again to move to _CRS in 2.6.34 (but
>> fixing the problem with large numbers of _CRS resources this time).
> 
> Should say "disable it for 2.6.33 for all but multi-IOH configs", which
> seem to be fairly rare anyway, and were what intel_bus.c was designed
> to accommodate.  On the one machine that motivated it, use_crs was
> broken (though it likely isn't now), so it seems the safest route.

will try to produce one patch to handle subtract decoding for legacy IOH aka the one with ESI.

the structure could be something like amd_bus.c, need to do it early, but it need after pci_arch_init to get mmconf.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/