- 04 Dec, 2009 6 commits
-
-
Kenji Kaneshige authored
We don't need pcie_port_device_probe() because we can get pci device/port type using pci_is_pcie() and 'pcie_type' fields in struct pci_dev. Remove pcie_port_device_probe(). Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
Alex Williamson authored
Prior to 1f82de10 we always initialized the upper 32bits of the prefetchable memory window, regardless of the address range used. Now we only touch it for a >32bit address, which means the upper32 registers remain whatever the BIOS initialized them too. It's valid for the BIOS to set the upper32 base/limit to 0xffffffff/0x00000000, which makes us program prefetchable ranges like 0xffffffffabc00000 - 0x00000000abc00000 Revert the chunk of 1f82de10 that made this conditional so we always write the upper32 registers and remove now unused pref_mem64 variable. Signed-off-by:
Alex Williamson <alex.williamson@hp.com> Signed-off-by:
-
Shmulik Ravid authored
The pcie_flr routine writes the device control register with the FLR bit set clearing all other fields for the FLR duration. Among other fields, the Max_Payload_Size is also cleared which can cause errors if there are transactions lurking in the HW pipeline. The patch replaces the blank write with read-modify-write of the control register keeping the other fields intact. Signed-off-by:
Shmulik Ravid <shmulikr@broadcom.com> Signed-off-by:
-
Yinghai Lu authored
So we can catch if the driver sets an incorrect dma_mask. Reviewed-by:
Grant Grundler <grundler@google.com> Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
Yinghai Lu authored
This allows us to find out what DMA mask is used for each PCI device at boot time; useful for debugging. After the patch: ehci_hcd 0000:00:02.1: using 31bit consistent DMA mask e1000 0000:0b:01.0: using 64bit DMA mask e1000 0000:0b:01.0: using 64bit consistent DMA mask e1000e 0000:04:00.0: using 64bit DMA mask e1000e 0000:04:00.0: using 64bit consistent DMA mask ixgb 0000:0c:01.0: using 64bit DMA mask ixgb 0000:0c:01.0: using 64bit consistent DMA mask aacraid 0000:86:00.0: using 32bit DMA mask aacraid 0000:86:00.0: using 32bit consistent DMA mask aacraid 0000:86:00.0: using 64bit DMA mask aacraid 0000:86:00.0: using 64bit consistent DMA mask qla2xxx 0000:0c:02.0: using 64bit consistent DMA mask qla2xxx 0000:0c:02.1: using 64bit consistent DMA mask lpfc 0000:06:00.0: using 64bit DMA mask lpfc 0000:06:00.1: using 64bit DMA mask pata_amd 0000:00:06.0: using 32bit DMA mask pata_amd 0000:00:06.0: using 32bit consistent DMA mask mptsas 0000:0c:04.0: using 64bit DMA mask mptsas 0000:0c:04.0: using 64bit consistent DMA mask forcedeth 0000:00:08.0: using 39bit DMA mask forcedeth 0000:00:08.0: using 39bit consistent DMA mask niu 0000:02:00.0: using 44bit DMA mask niu 0000:02:00.0: using 44bit consistent DMA mask sata_nv 0000:00:05.0: using 32bit DMA mask sata_nv 0000:00:05.0: using 32bit consistent DMA mask ib_mthca 0000:03:00.0: using 64bit DMA mask ib_mthca 0000:03:00.0: using 64bit consistent DMA mask Reviewed-by:
-
Jesse Barnes authored
If we stop the kthread, we may end up up'ing the sem twice, which seems unintended. Reported-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
- 24 Nov, 2009 34 commits
-
-
Bjorn Helgaas authored
This patch factors out the search for an MMCONFIG region, which was previously implemented in both mmconfig_32 and mmconfig_64. No functional change. Reviewed-by:
Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by:
-
Bjorn Helgaas authored
No functional change; just tidy up printks and make them more consistent with the rest of PCI. Reviewed-by:
-
Bjorn Helgaas authored
This is only used internally now, but eventually will be used in the hot-remove path to remove the MMCONFIG region associated with a host bridge. Reviewed-by:
-
Bjorn Helgaas authored
This changes pci_mmcfg_region from a table to a list, to make it easier to add and remove MMCONFIG regions for PCI host bridge hotplug. Reviewed-by:
-
Bjorn Helgaas authored
This replaces "typeof(pci_mmcfg_config[0])" with the actual type because I plan to convert pci_mmcfg_config to a list, and then "pci_mmcfg_config[0]" won't mean anything. Reviewed-by:
-
Bjorn Helgaas authored
The virtual address is only used for x86_64, but it's so much simpler to manage it as part of the pci_mmcfg_region that I think it's worth wasting a pointer per MMCONFIG region on x86_32. Reviewed-by:
-
Bjorn Helgaas authored
Since pci_mmcfg_region contains the struct resource, no need to pass the pci_mmcfg_region *and* the resource start/size. Reviewed-by:
-
Bjorn Helgaas authored
This patch adds a resource and corresponding name to the MMCONFIG structure. This makes allocation simpler (we can allocate the resource and name at the same time we allocate the pci_mmcfg_region), and gives us a way to hang onto the resource after inserting it. This will be needed so we can release and free it when hot-removing a host bridge. Reviewed-by:
-
Bjorn Helgaas authored
No functional change, but simplifies a future patch to convert the table to a list. Reviewed-by:
-
Bjorn Helgaas authored
This only renames the struct pci_mmcfg_region members; no functional change. Reviewed-by:
-
Bjorn Helgaas authored
This adds a struct pci_mmcfg_region with a little more information than the struct acpi_mcfg_allocation used previously. The acpi_mcfg structure is defined by the spec, so we can't change it. To begin with, struct pci_mmcfg_region is basically the same as the ACPI MCFG version, but future patches will add more information. Reviewed-by:
-
Bjorn Helgaas authored
This factors out the common "bus << 20" expression used when computing the MMCONFIG address. Reviewed-by:
-
Bjorn Helgaas authored
Since all MMCONFIG regions go through pci_mmconfig_add(), we can test the address once there. If the caller supplies an address of zero, we never insert it in the pci_mmcfg_config[] table, so no need to test it elsewhere. Reviewed-by:
-
Bjorn Helgaas authored
We never set pci_mmcfg_config unless we increment pci_mmcfg_config_num, so there's no need to test both pci_mmcfg_config_num and pci_mmcfg_config. Reviewed-by:
-
Bjorn Helgaas authored
This patch encapsulate pci_mmcfg_config[] updates. All alloc/free is now done in pci_mmconfig_add() and free_all_mcfg(), so all updates to pci_mmcfg_config[] and pci_mmcfg_config_num are in those two functions. This replaces the previous sequence of extend_mmcfg(), fill_one_mmcfg() with the single pci_mmconfig_add() interface. This interface is currently static but will eventually be used in the host bridge hot-add path. Reviewed-by:
-
Bjorn Helgaas authored
Step through the ACPI MCFG table, not pci_mmcfg_config[]. No functional change, but simplifies future patches that encapsulate pci_mmcfg_config[]. Reviewed-by:
-
Bjorn Helgaas authored
Use a local variable, not pci_mmcfg_config_num, to count MCFG entries. No functional change, but simplifies future changes. Reviewed-by:
-
Bjorn Helgaas authored
Reviewed-by:
-
Yinghai Lu authored
Those functions are used by intel_bus.c so seperate them to another file. and make amd_bus a bit smaller. Signed-off-by:
-
Jiri Kosina authored
Signed-off-by:
André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Alex Chiang authored
commit db635adc turned -DDEBUG for x86/pci on when CONFIG_PCI_DEBUG is set. In general, I agree with that change. However, it exposes a bunch of very low level PCI debugging in the early x86 path, such as: 0 reading 2 from a: ffff 1 reading 2 from a: ffff 2 reading 2 from a: ffff 3 reading 2 from a: 300 3 reading 2 from 0: 1002 3 reading 2 from 2: 515e These statements add a lot of noise to the boot and aren't likely to be necessary even when handling random upstream bug reports. [In contrast, statements such as these: pci 0000:02:04.0: found [14e4:164a] class 000200 header type 00 pci 0000:02:04.0: reg 10: [mem 0xf8000000-0xf9ffffff 64bit] pci 0000:02:04.0: reg 30: [mem 0x00000000-0x0001ffff pref] are indeed useful when remote debugging users' machines] Remove the noisy printks and save electrons everywhere. Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Andi Kleen <andi@firstfloor.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
-
Kenji Kaneshige authored
Enabling power fault detected event notification in current pciehp might cause power fault interrupt storm on some machines. On those machines. On those machines, power fault detected bit in the slot status register was set again immediately when it is cleared in the interrupt service routine, and next power fault detected interrupt was notified again. Therefore, disable power fault detected event notification for now. This patch also removes unnecessary handling for power fault cleared event because this event is not supported by PCIe spec. Tested-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Kenji Kaneshige authored
Change for PCI hotplug to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Changes for PCIe AER driver to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Change for PCIe ASPM driver to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Change for PCI core to use pci_is_pcie() instead of checking pci_dev->is_pcie. Signed-off-by:
-
Kenji Kaneshige authored
Introduce pci_is_pcie() which returns true if the specified PCI device is PCI Express capable, false otherwise. The purpose of pci_is_pcie() is removing 'is_pcie' flag in the struct pci_dev, which is not needed because we can check it using 'pcie_cap' field. To remove 'is_pcie', we need to update user of 'is_pcie' to use pci_is_pcie() instead first. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in pciehp driver. This avoids unnecessary search in PCI configuration space. This patch also removes 'cap_base' field in struct controller, that was used to hold PCIe capability offset by pciehp itself. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI hotplug core. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCIe ASPM driver. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pci_pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI Express Port Bus driver. This avoids unnecessary serarch in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCIe AER driver. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Use pcie_cap() instead of pci_find_capability() to get PCIe capability offset in PCI core code. This avoids unnecessary search in PCI configuration space. Signed-off-by:
-
Kenji Kaneshige authored
Introduce pci_pcie_cap() API that returns saved PCIe capability offset (currently it is saved in 'pcie_cap' field in the struct PCI dev). Using pci_pcie_cap() instead of pci_find_capability() avoids unnecessary search in PCI configuration space. Signed-off-by:
-
