Current -mm's mmconfig has some problems of remapped range.
a) In the case of broken MCFG tables on Asus etc., we need to remap
256M range, but currently only remap 1M.
b) The base address always corresponds to bus number 0, but currently
we are assuming it corresponds to start bus number.
This patch fixes the above problems.
Signed-off-by: OGAWA Hirofumi <[email protected]>
---
arch/x86_64/pci/mmconfig.c | 48 ++++++++++++++++++++++++++++++++-------------
1 file changed, 35 insertions(+), 13 deletions(-)
diff -puN arch/x86_64/pci/mmconfig.c~pci-mmconfig-ioremap-range-fix arch/x86_64/pci/mmconfig.c
--- linux-2.6/arch/x86_64/pci/mmconfig.c~pci-mmconfig-ioremap-range-fix 2006-12-23 08:52:15.000000000 +0900
+++ linux-2.6-hirofumi/arch/x86_64/pci/mmconfig.c 2006-12-23 09:35:37.000000000 +0900
@@ -24,6 +24,39 @@ struct mmcfg_virt {
};
static struct mmcfg_virt *pci_mmcfg_virt;
+static inline int mcfg_broken(void)
+{
+ struct acpi_table_mcfg_config *cfg = &pci_mmcfg_config[0];
+
+ /* Handle more broken MCFG tables on Asus etc.
+ They only contain a single entry for bus 0-0. Assume
+ this applies to all busses. */
+ if (pci_mmcfg_config_num == 1 &&
+ cfg->pci_segment_group_number == 0 &&
+ (cfg->start_bus_number | cfg->end_bus_number) == 0)
+ return 1;
+ return 0;
+}
+
+static void __iomem *mcfg_ioremap(struct acpi_table_mcfg_config *cfg)
+{
+ void __iomem *addr;
+ u32 size;
+
+ if (mcfg_broken())
+ size = 256 << 20;
+ else
+ size = (cfg->end_bus_number + 1) << 20;
+
+ addr = ioremap_nocache(cfg->base_address, size);
+ if (addr) {
+ printk(KERN_INFO "PCI: Using MMCONFIG at %x - %x\n",
+ cfg->base_address,
+ cfg->base_address + size - 1);
+ }
+ return addr;
+}
+
static char __iomem *get_virt(unsigned int seg, unsigned bus)
{
int cfg_num = -1;
@@ -41,13 +74,7 @@ static char __iomem *get_virt(unsigned i
return pci_mmcfg_virt[cfg_num].virt;
}
- /* Handle more broken MCFG tables on Asus etc.
- They only contain a single entry for bus 0-0. Assume
- this applies to all busses. */
- cfg = &pci_mmcfg_config[0];
- if (pci_mmcfg_config_num == 1 &&
- cfg->pci_segment_group_number == 0 &&
- (cfg->start_bus_number | cfg->end_bus_number) == 0)
+ if (mcfg_broken())
return pci_mmcfg_virt[0].virt;
/* Fall back to type 0 */
@@ -139,19 +166,14 @@ int __init pci_mmcfg_arch_init(void)
}
for (i = 0; i < pci_mmcfg_config_num; ++i) {
- u32 size = (pci_mmcfg_config[0].end_bus_number - pci_mmcfg_config[0].start_bus_number + 1) << 20;
pci_mmcfg_virt[i].cfg = &pci_mmcfg_config[i];
- pci_mmcfg_virt[i].virt = ioremap_nocache(pci_mmcfg_config[i].base_address,
- size);
+ pci_mmcfg_virt[i].virt = mcfg_ioremap(&pci_mmcfg_config[i]);
if (!pci_mmcfg_virt[i].virt) {
printk(KERN_ERR "PCI: Cannot map mmconfig aperture for "
"segment %d\n",
pci_mmcfg_config[i].pci_segment_group_number);
return 0;
}
- printk(KERN_INFO "PCI: Using MMCONFIG at %x-%x\n",
- pci_mmcfg_config[i].base_address,
- pci_mmcfg_config[i].base_address + size - 1);
}
raw_pci_ops = &pci_mmcfg;
_
--
OGAWA Hirofumi <[email protected]>
On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote:
> Current -mm's mmconfig has some problems of remapped range.
>
> a) In the case of broken MCFG tables on Asus etc., we need to remap
> 256M range, but currently only remap 1M.
Hi,
I respectfully disagree. If the MCFG table is broken, we should not use
it AT ALL. It's either a correct table, and we can use it, or it's so
broken that we know it never has been tested etc etc, we're just better
of to not trust it in that case.
Greetings,
Arjan van de Ven
Hi,
Arjan van de Ven <[email protected]> writes:
> On Sat, 2006-12-23 at 10:02 +0900, OGAWA Hirofumi wrote:
>> Current -mm's mmconfig has some problems of remapped range.
>>
>> a) In the case of broken MCFG tables on Asus etc., we need to remap
>> 256M range, but currently only remap 1M.
>
> I respectfully disagree. If the MCFG table is broken, we should not use
> it AT ALL. It's either a correct table, and we can use it, or it's so
> broken that we know it never has been tested etc etc, we're just better
> of to not trust it in that case.
Hm.. I see. Sounds sane to me. Well, my patch didn't add the new
workaround of broken table, it just fixes the oops of existence workaround.
Current workaround is the following (both of linus and -mm),
if (pci_mmcfg_config_num == 1 &&
cfg->pci_segment_group_number == 0 &&
(cfg->start_bus_number | cfg->end_bus_number) == 0)
/* Assume it can access 256M range */
But, if the system has bus number 0 only, it's a correct table.
We may need to detect the broken system. blacklist?
--
OGAWA Hirofumi <[email protected]>
> Current workaround is the following (both of linus and -mm),
>
> if (pci_mmcfg_config_num == 1 &&
> cfg->pci_segment_group_number == 0 &&
> (cfg->start_bus_number | cfg->end_bus_number) == 0)
> /* Assume it can access 256M range */
>
> But, if the system has bus number 0 only, it's a correct table.
> We may need to detect the broken system. blacklist?
or just... not assume 256Mb but assume broken?
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Sorry I missed the original email, but what is the chipset (name, pci
ID) of the board(s) with the problematic bios?
OG.
Olivier Galibert <[email protected]> writes:
> Sorry I missed the original email, but what is the chipset (name, pci
> ID) of the board(s) with the problematic bios?
I don't know, here is a comment of current code.
/* Handle more broken MCFG tables on Asus etc.
They only contain a single entry for bus 0-0. Assume
this applies to all busses. */
--
OGAWA Hirofumi <[email protected]>
Arjan van de Ven <[email protected]> writes:
>> Current workaround is the following (both of linus and -mm),
>>
>> if (pci_mmcfg_config_num == 1 &&
>> cfg->pci_segment_group_number == 0 &&
>> (cfg->start_bus_number | cfg->end_bus_number) == 0)
>> /* Assume it can access 256M range */
>>
>> But, if the system has bus number 0 only, it's a correct table.
>> We may need to detect the broken system. blacklist?
>
> or just... not assume 256Mb but assume broken?
I see. And instead, add force enable option?
--
OGAWA Hirofumi <[email protected]>