All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"jason@lakedaemon.net" <jason@lakedaemon.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x)
Date: Wed, 01 Oct 2014 11:38:45 +0200	[thread overview]
Message-ID: <3256560.C0cZnIlnAv@wuerfel> (raw)
In-Reply-To: <20141001084626.GZ841@e106497-lin.cambridge.arm.com>

On Wednesday 01 October 2014 09:46:26 Liviu Dudau wrote:
> On Tue, Sep 30, 2014 at 09:01:14PM +0100, Arnd Bergmann wrote:
> > On Tuesday 30 September 2014 20:54:41 Arnd Bergmann wrote:
> > > On Tuesday 30 September 2014 18:48:21 Liviu Dudau wrote:
> > > > > > > > These are the functions I found that refer to pci_sys_data on arm32:
> > > > > > > > 
> > > > > > > > pcibios_add_bus
> > > > > > > > pcibios_remove_bus
> > > > 
> > > > These are only needed if you want to do per HB processing of the bus
> > > > 
> > > > > > > > pcibios_align_resource
> > > > 
> > > > mvebu is the only user of this function.
> > > > 
> > > > > > > > pci_mmap_page_range
> > > > 
> > > > This is only needed when mapping a PCI resource to userspace. Is that your case here?
> > > > 
> > > > > > > > pci_domain_nr
> > > > > > > > pci_proc_domain
> > > > 
> > > > We have equivalent functionality in the generic patches for those.
> > > > 
> > > 
> > > We clearly don't need those functions for the new drivers, but that's not
> > > the point. The problem is that when you build a kernel that has both
> > > a traditional host bridge driver and a new one in it, you always get those
> > > functions and they get called from the PCI core, with incorrect arguments.
> > 
> > FWIW, the last time we discussed this, I think I had suggested that the
> > functions that are currently architecture specific and have a generic
> > __weak fallback could become function pointers in a per-host structure
> > passed to pci_scan_root_bus, either a new structure or an extended
> > struct pci_ops. Something along these lines:
> 
> Agree to the general idea. But have a look why host drivers need the add_bus ops:
> to add MSI information into the bus!! If we take care of the MSI in the generic
> code there is less of a need for this function at all.


Right, if we can eliminate the need for some or all of the functions above,
we don't have to abstract them any more.

pcibios_remove_bus can just go away entirely, we don't have a single driver
on ARM that implements it. pcibios_add_bus as you say is just used for MSI
at the moment, and we could get rid of it by just moving the msi_chip
reference from pci_bus into pci_host_bridge. 

The arm32 implementations of pci_domain_nr/pci_proc_domain can probably be
removed if we change the arm32 pcibios_init_hw function to call the new
interfaces that set the domain number.

pci_mmap_page_range could either get generalized some more in an attempt
to have a __weak default implementation that works on ARM, or it could
be changed to lose the dependency on pci_sys_data instead. In either
case, the change would involve using the generic pci_host_bridge_window
list.

pcibios_align_resource should probably be per host, and we could move
that into a pointer in pci_host_bridge, something like this:

diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index b7c3a5ea1fca..d9cb6c916d54 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -200,11 +200,15 @@ static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
 static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 		int resno, resource_size_t size, resource_size_t align)
 {
+	struct pci_host_bridge *host = find_pci_host_bridge(bus);
+	resource_size_t (*alignf)(void *, const struct resource *,
+				  resource_size_t, resource_size_t),
 	struct resource *res = dev->resource + resno;
 	resource_size_t min;
 	int ret;
 
 	min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+	alignf = host->align_resource ?: pcibios_align_resource;
 
 	/*
 	 * First, try exact prefetching match.  Even if a 64-bit
@@ -215,7 +219,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 	 */
 	ret = pci_bus_alloc_resource(bus, res, size, align, min,
 				     IORESOURCE_PREFETCH | IORESOURCE_MEM_64,
-				     pcibios_align_resource, dev);
+				     alignf, dev);
 	if (ret == 0)
 		return 0;
 
@@ -227,7 +231,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 	     (IORESOURCE_PREFETCH | IORESOURCE_MEM_64)) {
 		ret = pci_bus_alloc_resource(bus, res, size, align, min,
 					     IORESOURCE_PREFETCH,
-					     pcibios_align_resource, dev);
+					     alignf, dev);
 		if (ret == 0)
 			return 0;
 	}
@@ -240,7 +244,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 	 */
 	if (res->flags & (IORESOURCE_PREFETCH | IORESOURCE_MEM_64))
 		ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
-					     pcibios_align_resource, dev);
+					     alignf, dev);
 
 	return ret;
 }


If we decide constantly calling find_pci_host_bridge() is too expensive, we can
be more clever about it.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x)
Date: Wed, 01 Oct 2014 11:38:45 +0200	[thread overview]
Message-ID: <3256560.C0cZnIlnAv@wuerfel> (raw)
In-Reply-To: <20141001084626.GZ841@e106497-lin.cambridge.arm.com>

On Wednesday 01 October 2014 09:46:26 Liviu Dudau wrote:
> On Tue, Sep 30, 2014 at 09:01:14PM +0100, Arnd Bergmann wrote:
> > On Tuesday 30 September 2014 20:54:41 Arnd Bergmann wrote:
> > > On Tuesday 30 September 2014 18:48:21 Liviu Dudau wrote:
> > > > > > > > These are the functions I found that refer to pci_sys_data on arm32:
> > > > > > > > 
> > > > > > > > pcibios_add_bus
> > > > > > > > pcibios_remove_bus
> > > > 
> > > > These are only needed if you want to do per HB processing of the bus
> > > > 
> > > > > > > > pcibios_align_resource
> > > > 
> > > > mvebu is the only user of this function.
> > > > 
> > > > > > > > pci_mmap_page_range
> > > > 
> > > > This is only needed when mapping a PCI resource to userspace. Is that your case here?
> > > > 
> > > > > > > > pci_domain_nr
> > > > > > > > pci_proc_domain
> > > > 
> > > > We have equivalent functionality in the generic patches for those.
> > > > 
> > > 
> > > We clearly don't need those functions for the new drivers, but that's not
> > > the point. The problem is that when you build a kernel that has both
> > > a traditional host bridge driver and a new one in it, you always get those
> > > functions and they get called from the PCI core, with incorrect arguments.
> > 
> > FWIW, the last time we discussed this, I think I had suggested that the
> > functions that are currently architecture specific and have a generic
> > __weak fallback could become function pointers in a per-host structure
> > passed to pci_scan_root_bus, either a new structure or an extended
> > struct pci_ops. Something along these lines:
> 
> Agree to the general idea. But have a look why host drivers need the add_bus ops:
> to add MSI information into the bus!! If we take care of the MSI in the generic
> code there is less of a need for this function at all.


Right, if we can eliminate the need for some or all of the functions above,
we don't have to abstract them any more.

pcibios_remove_bus can just go away entirely, we don't have a single driver
on ARM that implements it. pcibios_add_bus as you say is just used for MSI
at the moment, and we could get rid of it by just moving the msi_chip
reference from pci_bus into pci_host_bridge. 

The arm32 implementations of pci_domain_nr/pci_proc_domain can probably be
removed if we change the arm32 pcibios_init_hw function to call the new
interfaces that set the domain number.

pci_mmap_page_range could either get generalized some more in an attempt
to have a __weak default implementation that works on ARM, or it could
be changed to lose the dependency on pci_sys_data instead. In either
case, the change would involve using the generic pci_host_bridge_window
list.

pcibios_align_resource should probably be per host, and we could move
that into a pointer in pci_host_bridge, something like this:

diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index b7c3a5ea1fca..d9cb6c916d54 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -200,11 +200,15 @@ static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
 static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 		int resno, resource_size_t size, resource_size_t align)
 {
+	struct pci_host_bridge *host = find_pci_host_bridge(bus);
+	resource_size_t (*alignf)(void *, const struct resource *,
+				  resource_size_t, resource_size_t),
 	struct resource *res = dev->resource + resno;
 	resource_size_t min;
 	int ret;
 
 	min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+	alignf = host->align_resource ?: pcibios_align_resource;
 
 	/*
 	 * First, try exact prefetching match.  Even if a 64-bit
@@ -215,7 +219,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 	 */
 	ret = pci_bus_alloc_resource(bus, res, size, align, min,
 				     IORESOURCE_PREFETCH | IORESOURCE_MEM_64,
-				     pcibios_align_resource, dev);
+				     alignf, dev);
 	if (ret == 0)
 		return 0;
 
@@ -227,7 +231,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 	     (IORESOURCE_PREFETCH | IORESOURCE_MEM_64)) {
 		ret = pci_bus_alloc_resource(bus, res, size, align, min,
 					     IORESOURCE_PREFETCH,
-					     pcibios_align_resource, dev);
+					     alignf, dev);
 		if (ret == 0)
 			return 0;
 	}
@@ -240,7 +244,7 @@ static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
 	 */
 	if (res->flags & (IORESOURCE_PREFETCH | IORESOURCE_MEM_64))
 		ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
-					     pcibios_align_resource, dev);
+					     alignf, dev);
 
 	return ret;
 }


If we decide constantly calling find_pci_host_bridge() is too expensive, we can
be more clever about it.

	Arnd

  reply	other threads:[~2014-10-01  9:39 UTC|newest]

Thread overview: 122+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-28 20:53 [RFC 0/4] Add PCI/MSI(x) support for AMD Seattle Platform suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit at amd.com
2014-09-28 20:53 ` [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform suravee.suthikulpanit
2014-09-28 20:53   ` suravee.suthikulpanit-5C7GfCeVMHo
2014-09-28 20:53   ` suravee.suthikulpanit at amd.com
2014-10-10 13:45   ` Mark Rutland
2014-10-10 13:45     ` Mark Rutland
2014-10-24 12:08     ` Suravee Suthikulpanit
2014-10-24 12:08       ` Suravee Suthikulpanit
2014-09-28 20:53 ` [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x) suravee.suthikulpanit
2014-09-28 20:53   ` suravee.suthikulpanit
2014-09-28 20:53   ` suravee.suthikulpanit at amd.com
2014-09-29 14:36   ` Arnd Bergmann
2014-09-29 14:36     ` Arnd Bergmann
2014-09-30 12:03     ` Lorenzo Pieralisi
2014-09-30 12:03       ` Lorenzo Pieralisi
2014-09-30 12:31       ` Arnd Bergmann
2014-09-30 12:31         ` Arnd Bergmann
2014-09-30 16:12         ` Lorenzo Pieralisi
2014-09-30 16:12           ` Lorenzo Pieralisi
2014-09-30 16:42           ` Liviu Dudau
2014-09-30 16:42             ` Liviu Dudau
2014-09-30 17:35             ` Lorenzo Pieralisi
2014-09-30 17:35               ` Lorenzo Pieralisi
2014-09-30 17:48               ` Liviu Dudau
2014-09-30 17:48                 ` Liviu Dudau
2014-09-30 18:54                 ` Arnd Bergmann
2014-09-30 18:54                   ` Arnd Bergmann
2014-09-30 20:01                   ` Arnd Bergmann
2014-09-30 20:01                     ` Arnd Bergmann
2014-10-01  8:46                     ` Liviu Dudau
2014-10-01  8:46                       ` Liviu Dudau
2014-10-01  9:38                       ` Arnd Bergmann [this message]
2014-10-01  9:38                         ` Arnd Bergmann
2014-10-07 12:06                         ` Lorenzo Pieralisi
2014-10-07 12:06                           ` Lorenzo Pieralisi
2014-10-07 13:52                           ` Arnd Bergmann
2014-10-07 13:52                             ` Arnd Bergmann
2014-10-07 14:47                             ` Lorenzo Pieralisi
2014-10-07 14:47                               ` Lorenzo Pieralisi
2014-10-07 21:39                               ` Arnd Bergmann
2014-10-07 21:39                                 ` Arnd Bergmann
2014-10-08 10:19                                 ` Lorenzo Pieralisi
2014-10-08 10:19                                   ` Lorenzo Pieralisi
2014-10-08 14:47                                   ` Arnd Bergmann
2014-10-08 14:47                                     ` Arnd Bergmann
2014-10-09  9:04                                     ` Lorenzo Pieralisi
2014-10-09  9:04                                       ` Lorenzo Pieralisi
2014-10-09 10:51                                       ` Arnd Bergmann
2014-10-09 10:51                                         ` Arnd Bergmann
2014-10-10 13:58                                         ` Lorenzo Pieralisi
2014-10-10 13:58                                           ` Lorenzo Pieralisi
2014-10-10 18:31                                           ` Arnd Bergmann
2014-10-10 18:31                                             ` Arnd Bergmann
2014-10-13  9:36                                             ` Lorenzo Pieralisi
2014-10-13  9:36                                               ` Lorenzo Pieralisi
2014-10-22 15:59                         ` Lorenzo Pieralisi
2014-10-22 15:59                           ` Lorenzo Pieralisi
2014-10-22 16:49                           ` Bjorn Helgaas
2014-10-22 16:49                             ` Bjorn Helgaas
2014-10-22 20:52                           ` Arnd Bergmann
2014-10-22 20:52                             ` Arnd Bergmann
2014-10-23  9:13                             ` Liviu Dudau
2014-10-23  9:13                               ` Liviu Dudau
2014-10-23 11:27                               ` Lorenzo Pieralisi
2014-10-23 11:27                                 ` Lorenzo Pieralisi
2014-10-23 16:52                                 ` Jason Gunthorpe
2014-10-23 16:52                                   ` Jason Gunthorpe
2014-10-27 16:10                                   ` Lorenzo Pieralisi
2014-10-27 16:10                                     ` Lorenzo Pieralisi
2014-10-23 13:33                               ` Arnd Bergmann
2014-10-23 13:33                                 ` Arnd Bergmann
2014-10-24 10:04                                 ` Liviu Dudau
2014-10-24 10:04                                   ` Liviu Dudau
2014-11-05 23:40                                 ` Bjorn Helgaas
2014-11-05 23:40                                   ` Bjorn Helgaas
2014-11-06  0:06                                   ` Arnd Bergmann
2014-11-06  0:06                                     ` Arnd Bergmann
2014-11-06  0:06                                     ` Arnd Bergmann
2014-12-29 19:32                                 ` Suravee Suthikulpanit
2014-12-29 19:32                                   ` Suravee Suthikulpanit
2015-01-02 11:55                                   ` Lorenzo Pieralisi
2015-01-02 11:55                                     ` Lorenzo Pieralisi
2015-01-02 11:55                                     ` Lorenzo Pieralisi
2015-01-02 18:18                                     ` Suravee Suthikulanit
2015-01-02 18:18                                       ` Suravee Suthikulanit
2015-01-02 21:09                                       ` Arnd Bergmann
2015-01-02 21:09                                         ` Arnd Bergmann
2015-01-05 14:48                                         ` Lorenzo Pieralisi
2015-01-05 14:48                                           ` Lorenzo Pieralisi
2014-11-05 23:39                             ` Bjorn Helgaas
2014-11-05 23:39                               ` Bjorn Helgaas
2014-11-06  0:05                               ` Arnd Bergmann
2014-11-06  0:05                                 ` Arnd Bergmann
2014-11-06  9:52                                 ` Lorenzo Pieralisi
2014-11-06  9:52                                   ` Lorenzo Pieralisi
2014-09-29 19:19   ` Sunil Kovvuri
2014-09-29 19:19     ` Sunil Kovvuri
2014-09-28 20:53 ` [RFC 3/4] arm64: Do not call enable PCI resources when specify PCI_PROBE_ONLY suravee.suthikulpanit
2014-09-28 20:53   ` suravee.suthikulpanit
2014-09-28 20:53   ` suravee.suthikulpanit at amd.com
2014-09-29 14:38   ` Arnd Bergmann
2014-09-29 14:38     ` Arnd Bergmann
2014-09-29 18:17   ` Bjorn Helgaas
2014-09-29 18:17     ` Bjorn Helgaas
2015-06-23 22:34     ` Benjamin Herrenschmidt
2015-06-23 22:34       ` Benjamin Herrenschmidt
2015-06-23 23:05       ` Russell King - ARM Linux
2015-06-23 23:05         ` Russell King - ARM Linux
2015-06-23 22:32   ` Benjamin Herrenschmidt
2015-06-23 22:32     ` Benjamin Herrenschmidt
2014-09-28 20:53 ` [RFC 4/4] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X) suravee.suthikulpanit
2014-09-28 20:53   ` suravee.suthikulpanit-5C7GfCeVMHo
2014-09-28 20:53   ` suravee.suthikulpanit at amd.com
2014-09-28 21:35   ` Suravee Suthikulpanit
2014-09-28 21:35     ` Suravee Suthikulpanit
2014-09-28 21:35     ` Suravee Suthikulpanit
2014-09-29 14:23     ` Thomas Gleixner
2014-09-29 14:23       ` Thomas Gleixner
2014-09-29 14:42   ` Arnd Bergmann
2014-09-29 14:42     ` Arnd Bergmann

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=3256560.C0cZnIlnAv@wuerfel \
    --to=arnd@arndb.de \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    /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.