- 05 Dec, 2009 1 commit
-
-
Yinghai Lu authored
This allows us to use the BIOS SR-IOV allocations rather than assigning our own later on. Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org>
-
- 04 Dec, 2009 16 commits
-
-
Kenji Kaneshige authored
Remove unnecessary definitions from portdrv.h and use generic definitions instead. Signed-off-by:
Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by:
-
Kenji Kaneshige authored
Remove 'port_type' field in struct pcie_port_data(), because we can get port type information from struct pci_dev. With this change, this patch also does followings: - Remove struct pcie_port_data because it no longer has any field. - Remove portdrv private definitions about port type (PCIE_RC_PORT, PCIE_SW_UPSTREAM_PORT and PCIE_SW_DOWNSTREAM_PORT), and use generic definitions instead. Signed-off-by:
-
Kenji Kaneshige authored
Minor cleanups for pcie_port_device_register(). Signed-off-by:
-
Kenji Kaneshige authored
Add missing service irqs cleanup in the error code path of pcie_port_device_register(). Signed-off-by:
-
Kenji Kaneshige authored
Call pci_enable_device() before initializing service irqs, because legacy interrupt is initialized in pci_enable_device() on some architectures. Signed-off-by:
-
Kenji Kaneshige authored
This patch cleans up the service irqs initialization as follows: - Remove 'irq_mode' field in pcie_port_data and related definitions, which is not needed because we can get the same information from 'is_msix', 'is_msi' and 'pin' fields in struct pci_dev. - Change the name of 'vectors' argument of assign_interrupt_mode() to 'irqs' because it holds irq numbers actually. People might confuse it with CPU vector or MSI/MSI-X vector. - Change function name assign_interrupt_mode() to init_service_irqs() becasuse we no longer have 'irq_mode' data structure, and new name is more straightforward (IMO). Signed-off-by:
-
Kenji Kaneshige authored
Move capability check capability to the beginning of pcie_port_device_register() prevents redundant execution path. Signed-off-by:
-
Kenji Kaneshige authored
No reason to check PME capability outside get_port_device_capability(). Do it in get_port_device_capability(). Signed-off-by:
-
Kenji Kaneshige authored
PCIe port type is already stored in 'pcie_type' field of struct pci_dev. So we don't need to get it from pci configuration space. Signed-off-by:
-
Kenji Kaneshige authored
In the current port bus driver implementation, pcie_device allocation, initialization and registration are done in separated functions. Doing those in one function make the code simple and easier to read. Signed-off-by:
-
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:
-
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 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 23 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:
-
