History log of /openbmc/linux/arch/powerpc/platforms/powernv/pci-ioda.c (Results 726 – 741 of 741)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# e47747f4 19-Aug-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: Fix overrunning segment tracing array

There're 2 arrays introduced to trace which PE has occupied the
corresponding resource (I/O or MMIO) segment. However, we didn't

powerpc/powernv: Fix overrunning segment tracing array

There're 2 arrays introduced to trace which PE has occupied the
corresponding resource (I/O or MMIO) segment. However, we didn't
allocate enough memory for them and that possiblly leads to PE
descriptor corruption.

The patch fixes that by allocating enough memory for those 2 arrays.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# db1266c8 19-Aug-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: Skip check on PE if necessary

While the device driver or PCI core tries to enable PCI device, the
platform dependent callback "ppc_md.pcibios_enable_device_hook" will

powerpc/powernv: Skip check on PE if necessary

While the device driver or PCI core tries to enable PCI device, the
platform dependent callback "ppc_md.pcibios_enable_device_hook" will
be called to check if there has one associated PE for the PCI device.
If we don't have the associated PE for the PCI device, it's not allowed
to enable the PCI device. Unfortunately, there might have some cases
we have to enable the PCI device (e.g. P2P bridge), but the PEs have
not been created yet.

The patch handles the unfortunate cases. Each PHB (struct pnv_phb)
has one field "initialized" to trace if the PEs have been created
and configured or not. When the PEs are not available, we won't check
the associated PE for the PCI device to be enabled.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# 13395c48 19-Aug-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: Initialize DMA for PEs

The patch introduces additional wrapper function to call the original
implementation so that the DMA can be configured for all existing PEs.

powerpc/powernv: Initialize DMA for PEs

The patch introduces additional wrapper function to call the original
implementation so that the DMA can be configured for all existing PEs.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# 11685bec 19-Aug-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: I/O and MMIO resource assignment for PEs

There're 2 types of PCI bus sensitive PEs: (A) The PE includes
single PCI bus. (B) The PE includes the PCI bus and all the subor

powerpc/powernv: I/O and MMIO resource assignment for PEs

There're 2 types of PCI bus sensitive PEs: (A) The PE includes
single PCI bus. (B) The PE includes the PCI bus and all the subordinate
PCI buses, and the patch tries to assign I/O and MMIO resources
based on created PEs. Fortunately, we figured out unified scheme
to do resource assignment for all types of PCI bus based PEs according
to Ben's idea:

- Resource assignment based on PE from top to bottom.
- The soureces, either I/O or MMIO, of the PE are figured out
from the assigned PCI bus.
- The occupied resource by parent PE could possibilly be overrided
by children PEs.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# 7ebdf956 19-Aug-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: PE list based on creation order

The resource (I/O and MMIO) will be assigned on basis of PE from
top to bottom so that we can implement the trick here: the resource

powerpc/powernv: PE list based on creation order

The resource (I/O and MMIO) will be assigned on basis of PE from
top to bottom so that we can implement the trick here: the resource
that has been assigned to parent PE could be taken by child PE if
necessary.

The current implementation already has PE list per PHB basis, but
the list doesn't meet our requirment: tracing PE based on their
cration time from top to bottom. So the patch does rename for the
DMA based PE list and introduces the list to trace the PEs sequentially
based on their creation time.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# fb446ad0 19-Aug-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: Create bus sensitive PEs

Basically, there're 2 types of PCI bus sensitive PEs: (A) The PE
includes single PCI bus. (B) The PE includes the PCI bus and all
the subord

powerpc/powernv: Create bus sensitive PEs

Basically, there're 2 types of PCI bus sensitive PEs: (A) The PE
includes single PCI bus. (B) The PE includes the PCI bus and all
the subordinate PCI buses. At present, we'd like to put PCI bus
originated by PCI-e link to form PE that contains single PCI bus,
and the PCIe-to-PCI bridge will form the 2nd type of PE. We don't
figure out to detect PLX bridge yet. Once we can detect PLX bridge
some day, we have to put PCI buses originated from the downstream
port of PLX bridge to the 2nd type of PE.

The patch changes the original implementation for a little bit
to support 2 types of PCI bus sensitive PEs described as above.
Also, the function used to retrieve the corresponding PE according
to the given PCI device has been changed based on that because each
PCI device should trace the directly associated PE.

Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Reviewed-by: Richard Yang <weiyang@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# eda485f0 17-Sep-2012 Benjamin Herrenschmidt <benh@kernel.crashing.org>

Merge remote-tracking branch 'pci/pci/gavin-window-alignment' into next

Merge Gavin patches from the PCI tree as subsequent powerpc
patches are going to depend on them

Signed-of

Merge remote-tracking branch 'pci/pci/gavin-window-alignment' into next

Merge Gavin patches from the PCI tree as subsequent powerpc
patches are going to depend on them

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# 271fd03a 11-Sep-2012 Gavin Shan <shangw@linux.vnet.ibm.com>

powerpc/powernv: I/O and memory alignment for P2P bridges

The patch implements ppc_md.pcibios_window_alignment for powernv
platform so that the resource reassignment in PCI core will be

powerpc/powernv: I/O and memory alignment for P2P bridges

The patch implements ppc_md.pcibios_window_alignment for powernv
platform so that the resource reassignment in PCI core will be
done according to the I/O and memory alignment returned from
powernv platform. The alignments returned from powernv platform
is closely depending on the scheme for PE segmenting. Besides,
the patch isn't useful for now, but the subsequent patches will
be working based on it.

[bhelgaas: use pci_pcie_type() since pci_dev.pcie_type was removed]
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

show more ...


Revision tags: v3.6-rc2, v3.6-rc1
# beacc6da 25-Jul-2012 Michael Ellerman <michael@ellerman.id.au>

powerpc: Remove all includes of <asm/abs_addr.h>

It's empty now, apart from other includes.

Fixup a few files that were getting things via this header.

Signed-off-by: Micha

powerpc: Remove all includes of <asm/abs_addr.h>

It's empty now, apart from other includes.

Fixup a few files that were getting things via this header.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


# 62f87c0e 24-Jul-2012 Yijing Wang <wangyijing@huawei.com>

PCI: Introduce pci_pcie_type(dev) to replace pci_dev->pcie_type

Introduce an inline function pci_pcie_type(dev) to extract PCIe
device type from pci_dev->pcie_flags_reg field, and prepar

PCI: Introduce pci_pcie_type(dev) to replace pci_dev->pcie_type

Introduce an inline function pci_pcie_type(dev) to extract PCIe
device type from pci_dev->pcie_flags_reg field, and prepare for
removing pci_dev->pcie_type.

Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

show more ...


Revision tags: v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4
# b918c62e 17-May-2012 Yinghai Lu <yinghai@kernel.org>

PCI: replace struct pci_bus secondary/subordinate with busn_res

Replace the struct pci_bus secondary/subordinate members with the
struct resource busn_res. Later we'll build a resource

PCI: replace struct pci_bus secondary/subordinate with busn_res

Replace the struct pci_bus secondary/subordinate members with the
struct resource busn_res. Later we'll build a resource tree of these
bus numbers.

[bhelgaas: changelog]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

show more ...


Revision tags: v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6, v3.3-rc5
# 673c9756 23-Feb-2012 Bjorn Helgaas <bhelgaas@google.com>

powerpc/PCI: replace pci_probe_only with pci_flags

We already use pci_flags, so this just sets pci_flags directly and removes
the intermediate step of figuring out pci_probe_only, then u

powerpc/PCI: replace pci_probe_only with pci_flags

We already use pci_flags, so this just sets pci_flags directly and removes
the intermediate step of figuring out pci_probe_only, then using it to set
pci_flags.

The PCI core provides a pci_flags definition (currently __weak), so drop
the powerpc definitions in favor of that.

CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

show more ...


Revision tags: v3.3-rc4, v3.3-rc3, v3.3-rc2
# f7ea82be 24-Jan-2012 Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/powernv: Fix PCI resource handling

Recent changes to the handling of PCI resources for host bridges
are breaking the PowerNV code for assigning resources on IODA.

The ro

powerpc/powernv: Fix PCI resource handling

Recent changes to the handling of PCI resources for host bridges
are breaking the PowerNV code for assigning resources on IODA.

The root of the problem is that the pci_bus attached to a host
bridge no longer has its "legacy" resource pointers populated
but only uses the newer list instead.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


Revision tags: v3.3-rc1, v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4
# cee72d5b 29-Nov-2011 Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/powernv: Display diag data on p7ioc EEH errors

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>


# f11fe552 29-Nov-2011 Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/powernv: Update OPAL interfaces

This adds some more interfaces for OPAL v2

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>


Revision tags: v3.2-rc3
# 184cd4a3 15-Nov-2011 Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/powernv: PCI support for p7IOC under OPAL v2

This adds support for p7IOC (and possibly other IODA v1 IO Hubs)
using OPAL v2 interfaces.

We completely take over resource

powerpc/powernv: PCI support for p7IOC under OPAL v2

This adds support for p7IOC (and possibly other IODA v1 IO Hubs)
using OPAL v2 interfaces.

We completely take over resource assignment and assign them using an
algorithm that hands out device BARs in a way that makes them fit in
individual segments of the M32 window of the bridge, which enables us
to assign individual PEs to devices and functions.

The current implementation gives out a PE per functions on PCIe, and a
PE for the entire bridge for PCIe to PCI-X bridges.

This can be adjusted / fine tuned later.

We also setup DMA resources (32-bit only for now) and MSIs (both 32-bit
and 64-bit MSI are supported).

The DMA allocation tries to divide the available 256M segments of the
32-bit DMA address space "fairly" among PEs. This is done using a
"weight" heuristic which assigns less value to things like OHCI USB
controllers than, for example SCSI RAID controllers. This algorithm
will probably want some fine tuning for specific devices or device
types.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

show more ...


1...<<21222324252627282930