> + total_weight = pnv_pci_ioda_total_dma_weight(phb);
> + weight = pnv_pci_ioda_pe_dma_weight(pe);
> + if (!total_weight || !weight)
> + return;
> +
> + segs = (weight * phb->ioda.dma32_count) / total_weight;
> + if (!segs)
> + segs = 1;
I'm a little
Gavin Shan writes:
> Similar to the mechanism tracking consumed IO/M32/M64 segments,
> this introduces an array for each PHB to track the consumed DMA32
> segments, which are going to be released on PCI unplugging time.
> The index of the array is the DMA32 segment
Gavin Shan writes:
> Each PHB maintains an array helping to translate 2-bytes Request
> ID (RID) to PE# with the assumption that PE# takes one byte, meaning
> that we can't have more than 256 PEs. However, pci_dn->pe_number
> already had 4-bytes for the PE#.
>
> This
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 logical changes introduced.
>
> Signed-off-by: Gavin Shan
Following some discussion on IRC, it looks like there are roughly 2
machines on the planet with skiboot and p5ioc2, so I'm not worried about
that any more.
I am still vaguely concerned about a failing fundamental reset.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe
d with a bridge
device. As such, a bridge reset only is appropriate. If this breaks
anything, the caller is broken.
It might be worth including a condensed version of this in the commit
message.
Reviewed-by: Daniel Axtens <d...@axtens.net>
Regards,
Daniel Axtens
>
> Sig
Gavin Shan writes:
> void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
> {
> - pnv_eeh_bridge_reset(dev, EEH_RESET_HOT);
> + int option, freset = 0;
> +
> + if (dev->subordinate)
> + pci_walk_bus(dev->subordinate,
> +
> - rc = opal_pci_reset(phb->opal_id,
> - OPAL_RESET_PHB_ERROR,
> - OPAL_ASSERT_RESET);
> - if (rc != OPAL_SUCCESS) {
> - pr_warn("%s: Failure %lld
Hi Gavin,
Sorry to have taken so long to resume these reviews!
> Currently, the IO and M32 segments are mapped to the corresponding
> PE based on the windows of the parent bridge of PE's primary bus.
> It's not going to work when the windows of root port or upstream
> port of the PCIe switch
Looks good.
Will hold off on an official review until I can test the series.
Regards,
Daniel
Gavin Shan writes:
> 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
all look good, with one nit-pick:
> - void(*shutdown)(struct pci_controller *);
> + void(*shutdown)(struct pci_controller *hose);
I think we're trying to move from hose to phb in new code.
Once that is fixed:
Reviewed-by: Daniel Axtens <d...@axtens.net>
Regards,
Daniel
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 advance. This shouldn't
> cause any behavioural changes.
>
> Signed-off-by:
ks for cleaning it up!
Reviewed-by: Daniel Axtens <d...@axtens.net>
>
> Signed-off-by: Gavin Shan <gws...@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff -
Gavin Shan writes:
>
> +void pcibios_setup_bridge(struct pci_bus *bus, unsigned long type)
> +{
> + struct pci_controller *hose = pci_bus_to_host(bus);
Very much a nit-pick, but I thought we were trying to move towards using
phb instead of hose in new code?
14 matches
Mail list logo