On 11/24/2015 10:06 AM, Gavin Shan wrote:
On Wed, Nov 18, 2015 at 01:23:05PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This adds a reference count of PE, representing the number of PCI
devices associated with the PE. The reference count is increased
or
On 11/17/2015 08:06 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 05:04:42PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
We're going to reserve/assign PEs when pcibios_setup_bridge() is
called. The function won't be called for root bus as it doesn
On 11/17/2015 12:37 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:01:46PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can
On 11/17/2015 12:04 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:01:59PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
As we track M32 segment consumption, this introduces an array to
the PHB to track the mapping between M64 segment and PE number.
The
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This adds standalone driver to support PCI hotplug for PowerPC PowerNV
platform that runs on top of skiboot firmware. The firmware identifies
hotpluggable slots and marked their device tree node with proper
"ibm,slot-pluggable" and "ibm,reset-by-firmware"
On 11/05/2015 12:12 AM, Gavin Shan wrote:
The pdn (struct pci_dn) instances are allocated from memblock or
bootmem when creating PCI controller (hoses) in setup_arch(). PCI
hotplug, which will be supported by proceeding patches, release
PCI device nodes and their corresponding pdn on unplugging e
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This renames pcibios_find_pci_bus() to pci_find_bus_by_node() to
avoid conflicts with those PCI subsystem weak function names, which
have prefix "pcibios". No logical changes introduced.
Could be merged into [PATCH v7 28/50] powerpc/pci: Rename
pcibios
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This renames traverse_pci_devices() to pci_traverse_device_nodes().
Why? pci_traverse_device_nodes() is not moved to some more generic header
where is would be required to have a standard prefix. And the ppc-pci.h
header does not use any standard pref
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This renames pcibios_{add,remove}_pci_devices() to avoid conflicts
with names of the weak functions in PCI subsystem, which have the
prefix "pcibios". No logical changes introduced.
As you mentioned before, the patchset is organized as "code refactorin
reset_secondary_bus,
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index ef5271a..3bb10de 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -30,6 +30,7 @@ struct pnv_phb;
struct pnv_ioda_pe {
unsigned lon
On 11/17/2015 08:03 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 04:08:30PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In current implementation, the PEs that are allocated or picked
>from the reserved list are identified by PE number. The PE instance
On 11/17/2015 07:48 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 12:07:17PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In pnv_ioda_setup_dma(), it's unnecessary to calculate the DMA32
segments for PEs on PHB3 as the whole available DMA32 space can
be ass
On 11/05/2015 12:12 AM, Gavin Shan wrote:
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup() except those used by SRIOV VFs. The
function is called for once after PCI probing and resources
assignment is completed. So it isn't hotplug friendly.
This creates P
On 11/05/2015 12:12 AM, Gavin Shan wrote:
We're going to reserve/assign PEs when pcibios_setup_bridge() is
called. The function won't be called for root bus as it doesn't
have parent bridge. However, the root bus still needs a PE to be
covered.
This reserves PE numbers that are adjacent to the r
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In current implementation, the PEs that are allocated or picked
from the reserved list are identified by PE number. The PE instance
has to be picked according to the PE number eventually. We have
same issue when PE is released.
For pnv_ioda_pick_m64_pe()
On 11/17/2015 02:04 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 01:37:22PM +1100, Alexey Kardashevskiy wrote:
On 11/17/2015 12:42 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on
On 11/17/2015 12:58 PM, Gavin Shan wrote:
On Tue, Nov 17, 2015 at 11:30:49AM +1100, Daniel Axtens wrote:
Gavin Shan writes:
This introduces pnv_ioda_init_pe() to initialize the specified PE
instance (phb->ioda.pe_array[x]). It's used by pnv_ioda_alloc_pe()
and pnv_ioda_reserve_pe(). No logica
On 11/17/2015 12:42 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:18PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can
On 11/17/2015 12:38 PM, Gavin Shan wrote:
On Mon, Nov 16, 2015 at 07:02:03PM +1100, Alexey Kardashevskiy wrote:
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can
On 11/05/2015 12:12 AM, Gavin Shan wrote:
PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according
to their DMA32 weight. The PEs on the list are iterated to setup
their TCE32 tables at system booting time. The list is used for
once and there is no good reason for it to survive.
From t
On 11/05/2015 12:12 AM, Gavin Shan wrote:
In pnv_ioda_setup_dma(), it's unnecessary to calculate the DMA32
segments for PEs on PHB3 as the whole available DMA32 space can
be assigned to one specific PE on PHB3.
This splits pnv_ioda_setup_dma() to pnv_pci_ioda1_setup_dma() and
pnv_pci_ioda2_setup
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and ea
On 11/06/2015 10:52 AM, Gavin Shan wrote:
On Fri, Nov 06, 2015 at 09:56:06AM +1100, Daniel Axtens wrote:
Gavin Shan writes:
The original implementation of pnv_ioda_setup_pe_seg() configures
IO and M32 segments by separate logics, which can be merged by
by caching @segmap, @seg_size, @win in a
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and ea
On 11/05/2015 12:12 AM, Gavin Shan wrote:
As we track M32 segment consumption, this introduces an array to
the PHB to track the mapping between M64 segment and PE number.
The information is going to be used to find M64 segment from the
PE number during PCI unplugging time in subsequent patches.
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and ea
On 11/12/2015 03:55 PM, Gavin Shan wrote:
On Thu, Nov 12, 2015 at 02:30:27PM +1100, Daniel Axtens wrote:
Hi Gavin,
Sorry to have taken so long to resume these reviews!
Thanks for your review, Daniel!
Currently, the IO and M32 segments are mapped to the corresponding
PE based on the windows
On 11/05/2015 12:12 AM, Gavin Shan wrote:
This renames the fields related to PE number in "struct pnv_phb"
for better reflecting of their usages as Alexey suggested. No
logical changes introduced.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
arch/powerp
On 08/15/2015 02:59 PM, Gavin Shan wrote:
On Fri, Aug 14, 2015 at 11:52:44PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup() except those consumed by SRIOV VFs.
The function is
On 08/15/2015 02:47 PM, Gavin Shan wrote:
On Sat, Aug 15, 2015 at 01:13:21PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch intends to add standalone driver to support PCI hotplug
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
The
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch intends to add standalone driver to support PCI hotplug
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
The firmware identified hotpluggable slots and marked their device
tree node with proper "ibm,slot-pluggable" and "ibm,r
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Currently, the PEs and their associated resources are assigned
in ppc_md.pcibios_fixup() except those consumed by SRIOV VFs.
The function is called for once after PCI probing and resources
assignment is finished which isn't hotplug friendly.
The patch cr
On 08/12/2015 09:20 PM, Gavin Shan wrote:
On Wed, Aug 12, 2015 at 09:05:09PM +1000, Alexey Kardashevskiy wrote:
On 08/12/2015 08:45 PM, Gavin Shan wrote:
On Tue, Aug 11, 2015 at 12:23:42PM +1000, Alexey Kardashevskiy wrote:
On 08/11/2015 10:03 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05
On 08/12/2015 08:45 PM, Gavin Shan wrote:
On Tue, Aug 11, 2015 at 12:23:42PM +1000, Alexey Kardashevskiy wrote:
On 08/11/2015 10:03 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:16:40PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6
On 08/06/2015 02:11 PM, Gavin Shan wrote:
This adds the refcount to PE, which represents number of PCI
devices contained in the PE. When last device leaves from the
PE, the PE together with its consumed resources (IO, DMA, PELTM,
PELTV) are released, to support PCI hotplug.
Signed-off-by: Gavin
On 08/11/2015 10:43 AM, Gavin Shan wrote:
On Tue, Aug 11, 2015 at 12:39:02AM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is
On 08/11/2015 10:38 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 07:53:02PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can&#
On 08/11/2015 10:29 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 07:31:11PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The
On 08/11/2015 10:12 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:40:08PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable wi
On 08/11/2015 10:03 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 05:16:40PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what
On 08/11/2015 09:45 AM, Gavin Shan wrote:
On Mon, Aug 10, 2015 at 04:30:09PM +1000, Alexey Kardashevskiy wrote:
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Different from PHB3 where 16 M64 BARs are supported and each
of them
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The available PE#, represented by a bitmap in the PHB, is allocated
in ascending order.
Available PE# is available exactly because it is not allocated ;)
It conflicts with the fact that M64 segments are
assigned in same order. In order to avoid the co
On 08/06/2015 02:11 PM, Gavin Shan wrote:
This renames the fields related to PE# in "struct pnv_phb" for
better reflecting of their usages as Alexey suggested. It doesn't
introduce behavioural changes.
Signed-off-by: Gavin Shan
Makes sense to move this to the beginning of the patchset as pat
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Several functions used to configure PE take pe_number to indentify
PE instance. As the pe_number is included in PE instance after it
is reserved or allocated. It's convienent for those functions to
return PE instance which includes the required pe_number.
On 08/06/2015 02:11 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't have more than 256 PEs. However, pci_dn->pe_number
already had 4-bytes for the PE#.
The patch extends the PE# cap
On 08/06/2015 02:11 PM, Gavin Shan wrote:
On P7IOC, the whole DMA32 space is divided evenly to 256MB segments.
Each PE can consume one or multiple DMA32 segments. Current code
doesn't trace the available DMA32 segments and those consumed by
one particular PE. It's conflicting with PCI hotplug.
T
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The original implementation of pnv_ioda_setup_dma() iterates the
list of PEs and configures the DMA32 space for them one by one.
The function was designed to be called during PHB fixup time.
When configuring PE's DMA32 space in pcibios_setup_bridge(), in
On 08/06/2015 02:11 PM, Gavin Shan wrote:
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is divided evenly into 256MB segments. The number
of continuous segments assigned to one particular PE depends on
the PE's DMA weight that is calculated based on the type of each
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
behavioural changes:
* Rename various fields in "struct pnv_phb" and "struct pnv_ioda_pe"
as 32-bits DMA should be related to "DMA", not "TCE".
s/dma_weight/dma32_weight/ is ok (
On 08/06/2015 02:11 PM, Gavin Shan wrote:
For P7IOC, the whole available DMA32 space, which is below the
MEM32 space, is divided evenly into 256MB segments. The number
of continuous segments assigned to one particular PE depends on
the PE's DMA weight that is calculated based on the type of each
On 08/06/2015 02:11 PM, Gavin Shan wrote:
There're 3 windows (IO, M32 and M64) for PHB, root port and upstream
These are actually IO, non-prefetchable and prefetchable windows which
happen to be IO, 32bit and 64bit windows but this has nothing to do with
the M32/M64 BAR registers in P7IOC/PHB
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch is adding 6 bitmaps, three to PE and three to PHB, to track
The patch is also removing 2 arrays (io_segmap and m32_segmap), what is
that all about? Also, there was no m64_segmap, now there is, needs an
explanation may be.
the consumed by
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The patch enables M64 window on P7IOC, which has been enabled on
PHB3. Different from PHB3 where 16 M64 BARs are supported and each
of them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, each P7IOC PHB has 16 M64 BARs an
On 08/06/2015 02:11 PM, Gavin Shan wrote:
The series of patches intend to support PCI slot for PowerPC PowerNV platform,
which is running on top of skiboot firmware. The patchset requires corresponding
changes from skiboot firmware, which is sent to skib...@lists.ozlabs.org
for review. The PCI sl
On 06/04/2015 04:41 PM, Gavin Shan wrote:
Each PHB maintains one instance of "struct pci_controller_ops",
which includes various callbacks called by PCI subsystem. In the
definition of this struct, some callbacks have explicit names for
its arguments, but the left don't have.
The patch removes a
On 06/04/2015 04:41 PM, Gavin Shan wrote:
Each PHB maintains an array helping to translate RID (Request
ID) to PE# with the assumption that PE# takes 8 bits, indicating
that we can't have more than 256 PEs. However, pci_dn->pe_number
already had 4-bytes for the PE#.
The patch extends the PE# cap
On 06/04/2015 04:41 PM, Gavin Shan wrote:
The patch cleans up DMA32 in pci-ioda.c. It shouldn't introduce
behavioural changes:
* Rename various fields in "struct pnv_phb" and "struct pnv_ioda_pe"
as 32-bits DMA should be related to "DMA", not "TCE", and move
them around to reflec
.
Cc: sta...@vger.kernel.org # v3.13
Cc: Benjamin Herrenschmidt
Reviewed-by: Anton Blanchard
[aik: folded Anton's patch with of_property_read_u32_array]
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* of_property_read_u32_array() is used for ddw_avail[]
v2:
* updated commit log
* fixe
58 matches
Mail list logo
