linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Alistair Popple <alistair@popple.id.au>
To: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org,
	mpe@ellerman.id.au, aik@ozlabs.ru
Subject: Re: [PATCH v9 12/26] powerpc/powernv/ioda1: M64 support on P7IOC
Date: Thu, 05 May 2016 09:53:51 +1000	[thread overview]
Message-ID: <2553049.lQAGOjRB9a@new-mexico> (raw)
In-Reply-To: <20160504064853.GA18778@gwshan>

On Wed, 4 May 2016 16:48:53 Gavin Shan wrote:
> On Wed, May 04, 2016 at 03:17:51PM +1000, Alistair Popple wrote:
> >On Tue, 3 May 2016 15:41:31 Gavin Shan wrote:
> >> This enables M64 window on P7IOC, which has been enabled on PHB3.
> >
> >Have we tested that this works with an adaptor? This looks to be enabling 
> >support for something that didn't previously work (64-bit BARs on P7IOC)?
> >
> 
> The M64 isn't supported on P7IOC before, meaning the PCI device's M64
> BAR is covered by PHB's M32 window. With the patch applied, the PCI
> device's M64 BAR is covered by PHB's M64 window as below log I got
> from vpl4. The kernel including the series of patches boots successfully
> on vpl4 and all looks normal.

So you're changing the way 64-bit BARs work on P7IOC to use a different bit of
the hardware/firmware? This means it could break older systems if there is
an issue with the M64 support. Other than the comments below the code looks
reasonable. However I am assuming you've tested that cards with 64-bit BARs
still function on P7 after this change as I'm not familiar enough to comment on
the specific hardware details, although your comments make sense and match the
code.

> [    0.246110] pci 0000:60:00.0: BAR 2: assigned [mem 0x3da810000000-0x3da810ffffff 64bit pref]
> [    0.246218] pci 0000:60:00.0: BAR 0: assigned [mem 0x3da081000000-0x3da08103ffff 64bit]
> [    0.246306] pci 0000:60:00.0: BAR 6: assigned [mem 0x3da081040000-0x3da08105ffff pref]
> [    0.246392] pci 0000:60     : [PE# 001] Secondary bus 96 associated with PE#1
> [    0.246484] pci 0000:60     : [PE# 001] DMA weight 15 (64), assigned (0) 1 DMA32 segments
> [    0.246552] pci 0000:60     : [PE# 001]  Setting up 32-bit TCE table at 00000000..0fffffff
> 
> Thanks,
> Gavin
> 
> >Regards,
> >
> >Alistair
> >
> >> 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 each
> >> of them are divided to 8 segments. So every P7IOC PHB supports
> >> 128 M64 segments in total. P7IOC has M64DT, which helps mapping
> >> one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
> >> M64DT, indicating that one M64 segment can only be pinned to the
> >> fixed PE#.
> >> 
> >> In order to unified M64 support M64 on P7IOC and PHB3, we just
> >> provide 128 M64 segments on every P7IOC PHB and each of them is
> >> pinned to the fixed PE# by bypassing the function of M64DT. In
> >> turn, we just need different phb->init_m64() for P7IOC and PHB3
> >> and maps M64 segment in pnv_ioda_reserve_m64_pe() for P7IOC, most
> >> of the code are shared by them.
> >> 
> >> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> >> ---
> >>  arch/powerpc/platforms/powernv/pci-ioda.c | 89 
> >+++++++++++++++++++++++++++++--
> >>  1 file changed, 86 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> >b/arch/powerpc/platforms/powernv/pci-ioda.c
> >> index 37f22b0..a1b74ec 100644
> >> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >> @@ -48,6 +48,9 @@
> >>  #include "powernv.h"
> >>  #include "pci.h"
> >>  
> >> +#define PNV_IODA1_M64_NUM	16	/* Number of M64 BARs	*/
> >> +#define PNV_IODA1_M64_SEGS	8	/* Segments per M64 BAR	*/
> >> +
> >>  /* 256M DMA window, 4K TCE pages, 8 bytes TCE */
> >>  #define TCE32_TABLE_SIZE	((0x10000000 / 0x1000) * 8)
> >>  
> >> @@ -246,6 +249,64 @@ static void pnv_ioda_reserve_dev_m64_pe(struct pci_dev 
> >*pdev,
> >>  	}
> >>  }
> >>  
> >> +static int pnv_ioda1_init_m64(struct pnv_phb *phb)
> >> +{
> >> +	struct resource *r;
> >> +	int index;
> >> +
> >> +	/*
> >> +	 * There are 16 M64 BARs, each of which has 8 segments. So
> >> +	 * there are as many M64 segments as the maximum number of
> >> +	 * PEs, which is 128.
> >> +	 */
> >> +	for (index = 0; index < PNV_IODA1_M64_NUM; index++) {
> >> +		unsigned long base, segsz = phb->ioda.m64_segsize;
> >> +		int64_t rc;
> >> +
> >> +		base = phb->ioda.m64_base +
> >> +		       index * PNV_IODA1_M64_SEGS * segsz;
> >> +		rc = opal_pci_set_phb_mem_window(phb->opal_id,
> >> +				OPAL_M64_WINDOW_TYPE, index, base, 0,
> >> +				PNV_IODA1_M64_SEGS * segsz);

Has firmware always supported OPAL_M64_WINDOW_TYPE for P7IOC? If older versions
don't support it what happens? Do we gracefully fall back to the old mode of
allocating all BARs from the M32 window or does it break?

> >> +		if (rc != OPAL_SUCCESS) {
> >> +			pr_warn("  Error %lld setting M64 PHB#%d-BAR#%d\n",
> >> +				rc, phb->hose->global_number, index);
> >> +			goto fail;
> >> +		}
> >> +
> >> +		rc = opal_pci_phb_mmio_enable(phb->opal_id,
> >> +				OPAL_M64_WINDOW_TYPE, index,
> >> +				OPAL_ENABLE_M64_SPLIT);
> >> +		if (rc != OPAL_SUCCESS) {
> >> +			pr_warn("  Error %lld enabling M64 PHB#%d-BAR#%d\n",
> >> +				rc, phb->hose->global_number, index);
> >> +			goto fail;
> >> +		}
> >> +	}
> >> +
> >> +	/*
> >> +	 * Exclude the segment used by the reserved PE, which
> >> +	 * is expected to be 0 or last supported PE#.
> >> +	 */
> >> +	r = &phb->hose->mem_resources[1];
> >> +	if (phb->ioda.reserved_pe_idx == 0)
> >> +		r->start += phb->ioda.m64_segsize;
> >> +	else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
> >> +		r->end -= phb->ioda.m64_segsize;
> >> +	else
> >> +		pr_warn("  Cannot cut M64 segment for reserved PE#%d\n",
> >> +			phb->ioda.reserved_pe_idx);

Should this be a WARN_ON()? If this condition can only exist because a future
programmer changes the reserved_pe_idx then I think it should be a WARN_ON()
as the above message would be too easy to miss.

> >> +
> >> +	return 0;
> >> +
> >> +fail:
> >> +	for ( ; index >= 0; index--)
> >> +		opal_pci_phb_mmio_enable(phb->opal_id,
> >> +			OPAL_M64_WINDOW_TYPE, index, OPAL_DISABLE_M64);
> >> +
> >> +	return -EIO;
> >> +}
> >> +
> >>  static void pnv_ioda_reserve_m64_pe(struct pci_bus *bus,
> >>  				    unsigned long *pe_bitmap,
> >>  				    bool all)
> >> @@ -315,6 +376,26 @@ static unsigned int pnv_ioda_pick_m64_pe(struct pci_bus 
> >*bus, bool all)
> >>  			pe->master = master_pe;
> >>  			list_add_tail(&pe->list, &master_pe->slaves);
> >>  		}
> >> +
> >> +		/*
> >> +		 * P7IOC supports M64DT, which helps mapping M64 segment
> >> +		 * to one particular PE#. However, PHB3 has fixed mapping
> >> +		 * between M64 segment and PE#. In order to have same logic
> >> +		 * for P7IOC and PHB3, we enforce fixed mapping between M64
> >> +		 * segment and PE# on P7IOC.
> >> +		 */
> >> +		if (phb->type == PNV_PHB_IODA1) {
> >> +			int64_t rc;
> >> +
> >> +			rc = opal_pci_map_pe_mmio_window(phb->opal_id,
> >> +					pe->pe_number, OPAL_M64_WINDOW_TYPE,
> >> +					pe->pe_number / PNV_IODA1_M64_SEGS,
> >> +					pe->pe_number % PNV_IODA1_M64_SEGS);
> >> +			if (rc != OPAL_SUCCESS)
> >> +				pr_warn("%s: Error %lld mapping M64 for 
> >PHB#%d-PE#%d\n",
> >> +					__func__, rc, phb->hose-
> >>global_number,
> >> +					pe->pe_number);
> >> +		}
> >>  	}
> >>  
> >>  	kfree(pe_alloc);
> >> @@ -329,8 +410,7 @@ static void __init pnv_ioda_parse_m64_window(struct 
> >pnv_phb *phb)
> >>  	const u32 *r;
> >>  	u64 pci_addr;
> >>  
> >> -	/* FIXME: Support M64 for P7IOC */
> >> -	if (phb->type != PNV_PHB_IODA2) {
> >> +	if (phb->type != PNV_PHB_IODA1 && phb->type != PNV_PHB_IODA2) {
> >>  		pr_info("  Not support M64 window\n");
> >>  		return;
> >>  	}
> >> @@ -364,7 +444,10 @@ static void __init pnv_ioda_parse_m64_window(struct 
> >pnv_phb *phb)
> >>  
> >>  	/* Use last M64 BAR to cover M64 window */
> >>  	phb->ioda.m64_bar_idx = 15;
> >> -	phb->init_m64 = pnv_ioda2_init_m64;
> >> +	if (phb->type == PNV_PHB_IODA1)
> >> +		phb->init_m64 = pnv_ioda1_init_m64;
> >> +	else
> >> +		phb->init_m64 = pnv_ioda2_init_m64;
> >>  	phb->reserve_m64_pe = pnv_ioda_reserve_m64_pe;
> >>  	phb->pick_m64_pe = pnv_ioda_pick_m64_pe;
> >>  }
> >> 
> >
> 

  reply	other threads:[~2016-05-04 23:54 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-03  5:41 [PATCH v9 00/26] powerpc/powernv: PCI hotplug preparation Gavin Shan
2016-05-03  5:41 ` [PATCH v9 01/26] powerpc/pci: Cleanup on struct pci_controller_ops Gavin Shan
2016-05-10 21:48   ` [v9,01/26] " Michael Ellerman
2016-05-03  5:41 ` [PATCH v9 02/26] powerpc/powernv: Cleanup on pci_controller_ops instances Gavin Shan
2016-05-05  4:07   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 03/26] powerpc/powernv: Drop phb->bdfn_to_pe() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 04/26] powerpc/powernv: Reorder fields in struct pnv_phb Gavin Shan
2016-05-03  5:41 ` [PATCH v9 05/26] powerpc/powernv: Rename PE# " Gavin Shan
2016-05-03  5:41 ` [PATCH v9 06/26] powerpc/powernv: Data type unsigned int for PE number Gavin Shan
2016-05-04  3:31   ` Alistair Popple
2016-05-04  8:39   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 07/26] powerpc/powernv: Fix initial IO and M32 segmap Gavin Shan
2016-05-04  3:31   ` Alistair Popple
2016-05-04  4:38     ` Gavin Shan
2016-05-05  2:06   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 08/26] powerpc/powernv: Simplify pnv_ioda_setup_pe_seg() Gavin Shan
2016-05-04  3:45   ` Alistair Popple
2016-05-05  2:11   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 09/26] powerpc/powernv: IO and M32 mapping based on PCI device resources Gavin Shan
2016-05-05  2:57   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 10/26] powerpc/powernv: Track M64 segment consumption Gavin Shan
2016-05-03  5:41 ` [PATCH v9 11/26] powerpc/powernv: Rename M64 related functions Gavin Shan
2016-05-03  5:41 ` [PATCH v9 12/26] powerpc/powernv/ioda1: M64 support on P7IOC Gavin Shan
2016-05-04  5:17   ` Alistair Popple
2016-05-04  6:48     ` Gavin Shan
2016-05-04 23:53       ` Alistair Popple [this message]
2016-05-05  0:40         ` Gavin Shan
2016-05-05  1:03           ` Alistair Popple
2016-05-05  2:28             ` Gavin Shan
2016-05-05  2:02   ` [PATCH v10 " Gavin Shan
2016-05-05  2:41     ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 13/26] powerpc/powernv/ioda1: Rename pnv_pci_ioda_setup_dma_pe() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 14/26] powerpc/powernv/ioda1: Introduce PNV_IODA1_DMA32_SEGSIZE Gavin Shan
2016-05-04  4:02   ` Alistair Popple
2016-05-05  2:48   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 15/26] powerpc/powernv: Remove DMA32 PE list Gavin Shan
2016-05-03  5:41 ` [PATCH v9 16/26] powerpc/powernv/ioda1: Improve DMA32 segment track Gavin Shan
2016-05-04 13:20   ` Gavin Shan
2016-05-05  1:55     ` Gavin Shan
2016-05-05  2:04   ` [PATCH v10 " Gavin Shan
2016-05-05  4:03     ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 17/26] powerpc/powernv: Use PE instead of number during setup and release Gavin Shan
2016-05-03  5:41 ` [PATCH v9 18/26] powerpc/pci: Rename pcibios_{add, remove}_pci_devices() Gavin Shan
2016-05-04  4:10   ` Alistair Popple
2016-05-04  4:53     ` [PATCH v9 18/26] powerpc/pci: Rename pcibios_{add,remove}_pci_devices() Gavin Shan
2016-05-04  4:43   ` [PATCH v9 18/26] powerpc/pci: Rename pcibios_{add, remove}_pci_devices() Andrew Donnellan
2016-05-05  3:06   ` [PATCH v9 18/26] powerpc/pci: Rename pcibios_{add,remove}_pci_devices() Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 19/26] powerpc/pci: Rename pcibios_find_pci_bus() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 20/26] powerpc/pci: Move pci_find_bus_by_node() around Gavin Shan
2016-05-04  4:46   ` Andrew Donnellan
2016-05-05  3:07   ` Alexey Kardashevskiy
2016-05-03  5:41 ` [PATCH v9 21/26] powerpc/pci: Export pci_add_device_node_info() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 22/26] powerpc/pci: Introduce pci_remove_device_node_info() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 23/26] powerpc/pci: Export pci_traverse_device_nodes() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 24/26] powerpc/pci: Don't scan empty slot Gavin Shan
2016-05-03  5:41 ` [PATCH v9 25/26] powerpc/powernv: Simplify pnv_eeh_reset() Gavin Shan
2016-05-03  5:41 ` [PATCH v9 26/26] powerpc/powernv: Exclude root bus in pnv_pci_reset_secondary_bus() Gavin Shan
2016-05-12  3:48   ` Gavin Shan
2016-05-12 11:35     ` Michael Ellerman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2553049.lQAGOjRB9a@new-mexico \
    --to=alistair@popple.id.au \
    --cc=aik@ozlabs.ru \
    --cc=benh@kernel.crashing.org \
    --cc=gwshan@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).