All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alistair Popple <alistair@popple.id.au>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 7/7] powerpc: Added PCI MSI support using the HSTA module
Date: Sat, 22 Feb 2014 07:41:26 +1100	[thread overview]
Message-ID: <1393015286.6771.110.camel@pasglop> (raw)
In-Reply-To: <1574137.lzDhNaVqIe@wuerfel>

On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:

> > @@ -242,8 +264,10 @@
> >  			ranges = <0x02000000 0x00000000 0x80000000 0x00000110 0x80000000 0x0 0x80000000
> >  			          0x01000000 0x0        0x0        0x00000140 0x0        0x0 0x00010000>;
> >  
> > -			/* Inbound starting at 0 to memsize filled in by zImage */
> > -			dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x0>;
> > +			/* Inbound starting at 0x0 to 0x40000000000. In order to use MSI
> > +			 * PCI devices must be able to write to the HSTA module.
> > +			 */
> > +			dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x400 0x0>;

Should we (provided it's possible in HW) create two ranges instead ? One
covering RAM and one covering MSIs ? To avoid stray DMAs whacking random
HW registers in the chip ...

> >  			/* This drives busses 0 to 0xf */
> >  			bus-range = <0x0 0xf>;
> 
> Ah, I first only saw the line you are removing and was about
> to suggest what you do anyway. Great!
> 
> > diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
> > index 54ec1d5..7cc3acc 100644
> > --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> > +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> > @@ -176,8 +176,12 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
> >  		return -ENXIO;
> >  	}
> >  
> > -	/* Check that we are fully contained within 32 bits space */
> > -	if (res->end > 0xffffffff) {
> > +	/* Check that we are fully contained within 32 bits space if we are not
> > +	 * running on a 460sx or 476fpe which have 64 bit bus addresses.
> > +	 */
> > +	if (res->end > 0xffffffff &&
> > +	    !(of_device_is_compatible(hose->dn, "ibm,plb-pciex-460sx")
> > +	      || of_device_is_compatible(hose->dn, "ibm,plb-pciex-476fpe"))) {
> >  		printk(KERN_ERR "%s: dma-ranges outside of 32 bits space\n",
> >  		       hose->dn->full_name);
> >  		return -ENXIO;
> 
> A more general question for BenH: Apparently this PCI implementation is
> getting reused on arm64 for APM X-Gene. Do you see any value in trying to
> share host controller drivers like this one across powerpc and arm64?

I would start duplicating, and see how much common code remains... Then
eventually merge.

> It's possible we are going to see the same situation with fsl_pci in the
> future, if arm and powerpc qoriq chips use the same peripherals. My
> plan for arm64 right now is to make PCI work without any code in arch/,
> just using new helper functions in drivers/pci and sticking the host
> drivers into drivers/pci/host as we started doing for arm32, but it
> can require significant work to make those drivers compatible with
> the powerpc pci-common.c.

powerpc pci-common.c is shrinking :-) At least the address remapping is
all in the core now, we could move more over I suppose...

Cheers,
Ben.

> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alistair Popple <alistair@popple.id.au>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH 7/7] powerpc: Added PCI MSI support using the HSTA module
Date: Sat, 22 Feb 2014 07:41:26 +1100	[thread overview]
Message-ID: <1393015286.6771.110.camel@pasglop> (raw)
In-Reply-To: <1574137.lzDhNaVqIe@wuerfel>

On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:

> > @@ -242,8 +264,10 @@
> >  			ranges = <0x02000000 0x00000000 0x80000000 0x00000110 0x80000000 0x0 0x80000000
> >  			          0x01000000 0x0        0x0        0x00000140 0x0        0x0 0x00010000>;
> >  
> > -			/* Inbound starting at 0 to memsize filled in by zImage */
> > -			dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x0>;
> > +			/* Inbound starting at 0x0 to 0x40000000000. In order to use MSI
> > +			 * PCI devices must be able to write to the HSTA module.
> > +			 */
> > +			dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x400 0x0>;

Should we (provided it's possible in HW) create two ranges instead ? One
covering RAM and one covering MSIs ? To avoid stray DMAs whacking random
HW registers in the chip ...

> >  			/* This drives busses 0 to 0xf */
> >  			bus-range = <0x0 0xf>;
> 
> Ah, I first only saw the line you are removing and was about
> to suggest what you do anyway. Great!
> 
> > diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
> > index 54ec1d5..7cc3acc 100644
> > --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> > +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> > @@ -176,8 +176,12 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
> >  		return -ENXIO;
> >  	}
> >  
> > -	/* Check that we are fully contained within 32 bits space */
> > -	if (res->end > 0xffffffff) {
> > +	/* Check that we are fully contained within 32 bits space if we are not
> > +	 * running on a 460sx or 476fpe which have 64 bit bus addresses.
> > +	 */
> > +	if (res->end > 0xffffffff &&
> > +	    !(of_device_is_compatible(hose->dn, "ibm,plb-pciex-460sx")
> > +	      || of_device_is_compatible(hose->dn, "ibm,plb-pciex-476fpe"))) {
> >  		printk(KERN_ERR "%s: dma-ranges outside of 32 bits space\n",
> >  		       hose->dn->full_name);
> >  		return -ENXIO;
> 
> A more general question for BenH: Apparently this PCI implementation is
> getting reused on arm64 for APM X-Gene. Do you see any value in trying to
> share host controller drivers like this one across powerpc and arm64?

I would start duplicating, and see how much common code remains... Then
eventually merge.

> It's possible we are going to see the same situation with fsl_pci in the
> future, if arm and powerpc qoriq chips use the same peripherals. My
> plan for arm64 right now is to make PCI work without any code in arch/,
> just using new helper functions in drivers/pci and sticking the host
> drivers into drivers/pci/host as we started doing for arm32, but it
> can require significant work to make those drivers compatible with
> the powerpc pci-common.c.

powerpc pci-common.c is shrinking :-) At least the address remapping is
all in the core now, we could move more over I suppose...

Cheers,
Ben.

> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alistair Popple <alistair@popple.id.au>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 7/7] powerpc: Added PCI MSI support using the HSTA module
Date: Sat, 22 Feb 2014 07:41:26 +1100	[thread overview]
Message-ID: <1393015286.6771.110.camel@pasglop> (raw)
In-Reply-To: <1574137.lzDhNaVqIe@wuerfel>

On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:

> > @@ -242,8 +264,10 @@
> >  			ranges = <0x02000000 0x00000000 0x80000000 0x00000110 0x80000000 0x0 0x80000000
> >  			          0x01000000 0x0        0x0        0x00000140 0x0        0x0 0x00010000>;
> >  
> > -			/* Inbound starting at 0 to memsize filled in by zImage */
> > -			dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x0 0x0>;
> > +			/* Inbound starting at 0x0 to 0x40000000000. In order to use MSI
> > +			 * PCI devices must be able to write to the HSTA module.
> > +			 */
> > +			dma-ranges = <0x42000000 0x0 0x0 0x0 0x0 0x400 0x0>;

Should we (provided it's possible in HW) create two ranges instead ? One
covering RAM and one covering MSIs ? To avoid stray DMAs whacking random
HW registers in the chip ...

> >  			/* This drives busses 0 to 0xf */
> >  			bus-range = <0x0 0xf>;
> 
> Ah, I first only saw the line you are removing and was about
> to suggest what you do anyway. Great!
> 
> > diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
> > index 54ec1d5..7cc3acc 100644
> > --- a/arch/powerpc/sysdev/ppc4xx_pci.c
> > +++ b/arch/powerpc/sysdev/ppc4xx_pci.c
> > @@ -176,8 +176,12 @@ static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
> >  		return -ENXIO;
> >  	}
> >  
> > -	/* Check that we are fully contained within 32 bits space */
> > -	if (res->end > 0xffffffff) {
> > +	/* Check that we are fully contained within 32 bits space if we are not
> > +	 * running on a 460sx or 476fpe which have 64 bit bus addresses.
> > +	 */
> > +	if (res->end > 0xffffffff &&
> > +	    !(of_device_is_compatible(hose->dn, "ibm,plb-pciex-460sx")
> > +	      || of_device_is_compatible(hose->dn, "ibm,plb-pciex-476fpe"))) {
> >  		printk(KERN_ERR "%s: dma-ranges outside of 32 bits space\n",
> >  		       hose->dn->full_name);
> >  		return -ENXIO;
> 
> A more general question for BenH: Apparently this PCI implementation is
> getting reused on arm64 for APM X-Gene. Do you see any value in trying to
> share host controller drivers like this one across powerpc and arm64?

I would start duplicating, and see how much common code remains... Then
eventually merge.

> It's possible we are going to see the same situation with fsl_pci in the
> future, if arm and powerpc qoriq chips use the same peripherals. My
> plan for arm64 right now is to make PCI work without any code in arch/,
> just using new helper functions in drivers/pci and sticking the host
> drivers into drivers/pci/host as we started doing for arm32, but it
> can require significant work to make those drivers compatible with
> the powerpc pci-common.c.

powerpc pci-common.c is shrinking :-) At least the address remapping is
all in the core now, we could move more over I suppose...

Cheers,
Ben.

> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



  reply	other threads:[~2014-02-21 20:41 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21  6:31 [PATCH 0/7] IBM Akebono/PPC476GTR Support Alistair Popple
2014-02-21  6:31 ` Alistair Popple
2014-02-21  6:31 ` Alistair Popple
2014-02-21  6:31 ` [PATCH 1/7] IBM Akebono: Add a SDHCI platform driver Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31   ` Alistair Popple
     [not found]   ` <1392964293-13687-2-git-send-email-alistair-Y4h6yKqj69EXC2x5gXVKYQ@public.gmane.org>
2014-02-21 14:14     ` Arnd Bergmann
2014-02-21 14:14       ` Arnd Bergmann
2014-02-21 14:14       ` Arnd Bergmann
2014-02-24  0:38       ` Alistair Popple
2014-02-24  0:38         ` Alistair Popple
2014-02-21  6:31 ` [PATCH 2/7] IBM Akebono: Add support for a new PHY interface to the IBM emac driver Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21 11:18   ` Mark Rutland
2014-02-21 11:18     ` Mark Rutland
2014-02-21 11:18     ` Mark Rutland
2014-02-24  2:09     ` Alistair Popple
2014-02-24  2:09       ` Alistair Popple
2014-02-24  2:09       ` Alistair Popple
2014-02-21  6:31 ` [PATCH 3/7] IBM Akebono: Add support to the OHCI platform driver for PPC476GTR Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21 14:16   ` Arnd Bergmann
2014-02-21 14:16     ` Arnd Bergmann
2014-02-21 14:16     ` Arnd Bergmann
2014-02-24  0:20     ` Alistair Popple
2014-02-24  0:20       ` Alistair Popple
2014-02-24  0:20       ` Alistair Popple
2014-02-21 15:34   ` Alan Stern
2014-02-21 15:34     ` Alan Stern
2014-02-21 15:34     ` Alan Stern
2014-02-21  6:31 ` [PATCH 4/7] ECHI Platform: Merge ppc-of EHCI driver into the ehci-platform driver Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21 11:48   ` Mark Rutland
2014-02-21 11:48     ` Mark Rutland
2014-02-21 11:48     ` Mark Rutland
2014-02-21 14:21     ` Arnd Bergmann
2014-02-21 14:21       ` Arnd Bergmann
2014-02-21 14:21       ` Arnd Bergmann
2014-02-22  2:32     ` Tony Prisk
2014-02-22  2:32       ` Tony Prisk
2014-02-22  2:32       ` Tony Prisk
2014-02-21 15:41   ` Alan Stern
2014-02-21 15:41     ` Alan Stern
2014-02-21 15:41     ` Alan Stern
2014-02-24  0:28     ` Alistair Popple
2014-02-24  0:28       ` Alistair Popple
2014-02-21  6:31 ` [PATCH 5/7] IBM Currituck: Clean up board specific code before adding Akebono code Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31 ` [PATCH 6/7] IBM Akebono: Add the Akebono platform Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31 ` [PATCH 7/7] powerpc: Added PCI MSI support using the HSTA module Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21  6:31   ` Alistair Popple
2014-02-21 14:33   ` Arnd Bergmann
2014-02-21 14:33     ` Arnd Bergmann
2014-02-21 14:33     ` Arnd Bergmann
2014-02-21 20:41     ` Benjamin Herrenschmidt [this message]
2014-02-21 20:41       ` Benjamin Herrenschmidt
2014-02-21 20:41       ` Benjamin Herrenschmidt
2014-02-21 21:53       ` Arnd Bergmann
2014-02-21 21:53         ` Arnd Bergmann
2014-02-21 21:53         ` Arnd Bergmann
2014-02-25  5:54       ` Alistair Popple
2014-02-25  5:54         ` Alistair Popple
2014-02-25  5:54         ` Alistair Popple

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=1393015286.6771.110.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=alistair@popple.id.au \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.