Re: [RFC PATCH 1/2] pci: don't assume pref memio are 64bit -v3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 22, 2009 at 03:37:04PM -0700, Yinghai Lu wrote:
> one system with 4g installed ( there is 1g hole)
> 
> when 4G installed.
> BIOS put ACPI etc need the hole
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009bc00 (usable)
> [    0.000000]  BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000bffa0000 (usable)
> [    0.000000]  BIOS-e820: 00000000bffa0000 - 00000000bffae000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000bffae000 - 00000000bfff0000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
> so in kernel resource will be reserved for 0xbffa0000 - 0xbfff0000 for ACPI
> 0x100000 -  0xbffa0000 for RAM...
> 
> and BIOS set
> [    0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff]
> [    0.237102] pci 0000:01:00.0: reg 10 32bit mmio: [0xc0000000-0xcfffffff]
> that is conflict with reserved res. so it can not be reserved Kernel.
> 
> then Kernel try to get range from 0x140000000 ( above the RAM, 5G and above 4g)
> and set let the bridge to use it, and ATI cards to use it.
> 
> but the problem is that ATI only support 32bit ...

Yinghai, you are trying to get a quick fix for quite a complex problem
that cannot be solved with a quick fix. Even more, there is no rush on
a quick fix because it's not a critical bug at all. 32-bit stuff ends
up above 4G *only* when there is no free space left on the 32-bit
PCI bus, and it can be considered as very effective (though rather ugly)
way of disabling the BAR that we failed to allocate.
In this particular case it was simply a side effect of the "pci_mem_start"
issue (which was indeed critical, but hopefully fixed now).


> +/* need to insert those two under iomem */
> +struct resource iomem32_resource = {
> +	.name	= "PCI mem 32bit",
> +	.start	= 0,
> +	.end	= 0xffffffff,
> +	.flags	= IORESOURCE_MEM,
> +};
> +struct resource iomem64_resource = {
> +	.name	= "PCI mem 64bit",
> +	.start	= 1ULL<<32,
> +	.end	= -1,
> +	.flags	= IORESOURCE_MEM | IORESOURCE_MEM_64,
> +};
> +

This only works on x86 and similar systems with 1:1 CPU address to bus
address mapping. There is a lot of machines with multiple 32-bit PCI
bus spaces (4G per PCI domain).

Ivan.
--
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

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux