On 12/29/2015 12:37 PM, Rob Herring wrote:
On Tue, Dec 22, 2015 at 03:43:52PM -0800, David Daney wrote:
From: David Daney <david.da...@cavium.com>
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge. Add a driver to provide these config
On 12/22/2015 02:03 AM, Will Deacon wrote:
On Mon, Dec 21, 2015 at 05:53:42PM -0800, David Daney wrote:
From: David Daney <david.da...@cavium.com>
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge. Add a driver to provide these config
On 12/22/2015 02:07 AM, Will Deacon wrote:
On Mon, Dec 21, 2015 at 05:53:41PM -0800, David Daney wrote:
From: David Daney <david.da...@cavium.com>
No change in functionality.
Move structure definitions into a separate header file. Split probe
function in to two parts:
- a small
From: David Daney <david.da...@cavium.com>
No change in functionality.
Move structure definitions into a separate header file. Move common
code to new file with Kconfig machinery to build it. Split probe
function in to two parts:
- a small driver specific probe function (gen_pci
From: David Daney <david.da...@cavium.com>
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge. Add a driver to provide these config
space accessor functions. The pci-host-common code is used to
configure the PCI machinery.
Signed-off-by:
On 12/22/2015 11:18 AM, David Daney wrote:
On 12/22/2015 02:03 AM, Will Deacon wrote:
On Mon, Dec 21, 2015 at 05:53:42PM -0800, David Daney wrote:
From: David Daney <david.da...@cavium.com>
[...]
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba9..16ed9c3
From: David Daney <david.da...@cavium.com>
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge.
There are two patches:
1) Refactor code in pci-host-generic so that it can more easily be
used by other drivers. This splits the driver f
From: David Daney <david.da...@cavium.com>
No change in functionality.
Move structure definitions into a separate header file. Split probe
function in to two parts:
- a small driver specific probe function (gen_pci_probe)
- a common probe that can be used by other d
From: David Daney <david.da...@cavium.com>
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge.
There are two patches:
1) Refactor code in pci-host-generic so that it can more easily be
used by other drivers.
2) Add the ThunderX PCIe
From: David Daney <david.da...@cavium.com>
Some Cavium ThunderX processors require quirky access methods for the
config space of the PCIe bridge. Add a driver to provide these config
space accessor functions. The pci-host-generic driver code is used to
configure the PCI machinery.
Sign
On 12/07/2015 02:43 PM, Bjorn Helgaas wrote:
Hi David,
On Tue, Sep 22, 2015 at 05:16:55PM -0700, David Daney wrote:
From: David Daney <david.da...@cavium.com>
The config space for external PCIe root complexes on some Cavium
ThunderX SoCs is very similar to CAM and ECAM, but d
devices. Device parameters are configured from device tree data.
eMMC, MMC and SD devices are supported.
Tested-by: Aaro Koskinen <aaro.koski...@iki.fi>
Signed-off-by: Chandrakala Chavva <ccha...@caviumnetworks.com>
Signed-off-by: David Daney <david.da...@cavium.com>
Signed-off-b
On 10/09/2015 06:20 AM, Rob Herring wrote:
On Thu, Oct 8, 2015 at 5:10 PM, David Daney <ddaney.c...@gmail.com> wrote:
From: Mark Rutland <mark.rutl...@arm.com>
Currently msi-parent is used by a few bindings to describe the
relationship between a PCI root complex and a single MS
On 10/08/2015 08:28 AM, Bjorn Helgaas wrote:
On Fri, Oct 02, 2015 at 11:43:58AM -0700, David Daney wrote:
From: David Daney <david.da...@cavium.com>
[...]
David Daney (5):
PCI: Add pci_bus_fixup_irqs().
PCI: generic: Only fixup irqs for bus we are creating.
I'm hoping we won'
driver is currently broken for non-zero starting bus numbers.
David Daney
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Daney <david.da...@cavium.com>
The first patch from Mark Rutland adds the OF device tree binding
description, which explains what we are attempting to do here. For
MSI messages on GICv3 systems there is some side-band data that
accompanies the message, this data is spe
From: David Daney <david.da...@cavium.com>
Replace open coded generation PCI/MSI requester id with call to the
new function pci_msi_domain_get_msi_rid() which applies the "msi-map"
to the id value.
Reviewed-by: Marc Zyngier <marc.zyng...@arm.com>
Signed-off-by:
Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: David Daney <david.da...@cavium.com>
---
Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
1 file changed, 220 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
diff --git a/
From: David Daney <david.da...@cavium.com>
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers. Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.
R
From: David Daney <david.da...@cavium.com>
Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
Initially supports mapping the RID via OF devic
From: David Daney <david.da...@cavium.com>
Make the offset from the beginning of the "reg" property be from the
starting bus number, rather than zero. Hoist the invariant size
calculation out of the mapping for loop.
Update host-generic-pci.txt to clarify the semantics of th
On 10/07/2015 12:44 PM, Bjorn Helgaas wrote:
Hi David,
On Fri, Oct 02, 2015 at 11:43:59AM -0700, David Daney wrote:
From: David Daney <david.da...@cavium.com>
pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
the fixups for devices on the specified bus.
Follow-on
From: David Daney <david.da...@cavium.com>
While using the pci-host-generic driver to add PCI support for the
Cavium ThunderX processors, several bugs were discovered. This patch
set fixes the bugs, a follow-on set will add the ThunderX support.
Changes from v3:
- Drop "PCI: gen
From: David Daney <david.da...@cavium.com>
If we create multiple buses with pci-host-generic, or there are buses
created by other drivers, we don't want to call pci_fixup_irqs() which
operates on all devices, not just the devices on the bus being added.
The consequence is that either the
From: David Daney <david.da...@cavium.com>
If the bus is being configured with a bus-range that does not start at
zero, pass that starting bus number to pci_scan_root_bus(). Passing
the incorrect value of zero causes attempted config accesses outside
of the supported range, which ca
From: David Daney <david.da...@cavium.com>
There are two problems with the bus_max calculation:
1) The u8 data type can overflow for large config space windows.
2) The calculation is incorrect for a bus range that doesn't start at
zero.
Since the configuration space is relative to bu
From: David Daney <david.da...@cavium.com>
pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
the fixups for devices on the specified bus.
Follow-on patch will use the new function.
Signed-off-by: David Daney <david.da...@cavium.com>
---
No change from v2.
drive
From: David Daney <david.da...@cavium.com>
The pci-host-generic driver keeps a global struct pci_ops which it
then patches with the .map_bus method appropriate for the bus device.
A problem arises when the driver is used for two different types of
bus devices, the .map_bus method for th
On 10/01/2015 02:24 AM, Marc Zyngier wrote:
Hi David,
On 30/09/15 23:47, David Daney wrote:
From: David Daney <david.da...@cavium.com>
Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to d
From: David Daney <david.da...@cavium.com>
Replace open coded generation PCI/MSI requester id with call to the
new function pci_msi_domain_get_msi_rid() which applies the "msi-map"
to the id value.
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/irqchip/ir
From: David Daney <david.da...@cavium.com>
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers. Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.
R
Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: David Daney <david.da...@cavium.com>
---
Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
1 file changed, 220 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
diff --git a/
From: David Daney <david.da...@cavium.com>
The first patch from Mark Rutland adds the OF device tree binding
description, which explains what we are attempting to do here. For
MSI messages on GICv3 systems there is some side-band data that
accompanies the message, this data is spe
From: David Daney <david.da...@cavium.com>
Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
Initially supports mapping the RID via OF devic
From: David Daney <david.da...@cavium.com>
Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
Initially supports mapping the RID via OF devic
From: David Daney <david.da...@cavium.com>
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers. Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.
R
From: David Daney <david.da...@cavium.com>
Replace open coded generation PCI/MSI requester id with call to the
new function pci_msi_domain_get_msi_rid() which applies the "msi-map"
to the id value.
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/irqchip/ir
From: David Daney <david.da...@cavium.com>
The first patch from Mark Rutland adds the OF device tree binding
description, which explains what we are attempting to do here. For
MSI messages on GICv3 systems there is some side-band data that
accompanies the message, this data is spe
Mark Rutland <mark.rutl...@arm.com>
Signed-off-by: David Daney <david.da...@cavium.com>
---
Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
1 file changed, 220 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
diff --git a/
On 09/24/2015 02:52 PM, David Miller wrote:
From: David Daney <ddaney.c...@gmail.com>
Date: Tue, 22 Sep 2015 17:41:36 -0700
From: David Daney <david.da...@cavium.com>
When the Cavium mdio-octeon devices appear in the Thunder family of
arm64 based SoCs, they show up as PCI devic
On 09/24/2015 03:04 PM, David Daney wrote:
On 09/24/2015 02:52 PM, David Miller wrote:
From: David Daney <ddaney.c...@gmail.com>
Date: Tue, 22 Sep 2015 17:41:36 -0700
From: David Daney <david.da...@cavium.com>
When the Cavium mdio-octeon devices appear in the Thunder family of
On 09/24/2015 03:14 PM, David Miller wrote:
From: David Daney <dda...@caviumnetworks.com>
Date: Thu, 24 Sep 2015 15:04:23 -0700
On 09/24/2015 02:52 PM, David Miller wrote:
From: David Daney <ddaney.c...@gmail.com>
Date: Tue, 22 Sep 2015 17:41:36 -0700
From: David Dan
On 09/24/2015 03:50 PM, David Miller wrote:
From: David Daney <dda...@caviumnetworks.com>
Date: Thu, 24 Sep 2015 15:45:41 -0700
2) The OF device tree nodes for PCI devices do not result in the
creation of a platform device.
But they are created for the children right? And that's the o
On 09/23/2015 01:21 AM, Arnd Bergmann wrote:
On Tuesday 22 September 2015 16:49:14 David Daney wrote:
From: David Daney <david.da...@cavium.com>
The pci-host-generic driver keeps a global struct pci_ops which it
then patches with the .map_bus method appropriate for the bus device.
A p
On 09/23/2015 10:07 AM, Rob Herring wrote:
On Tue, Sep 22, 2015 at 7:00 PM, David Daney <ddaney.c...@gmail.com> wrote:
From: David Daney <david.da...@cavium.com>
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controller
On 09/23/2015 09:52 AM, Marc Zyngier wrote:
On Tue, 22 Sep 2015 17:00:05 -0700
David Daney <ddaney.c...@gmail.com> wrote:
From: David Daney <david.da...@cavium.com>
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI c
On 09/23/2015 10:01 AM, Marc Zyngier wrote:
On Tue, 22 Sep 2015 17:00:06 -0700
David Daney <ddaney.c...@gmail.com> wrote:
From: David Daney <david.da...@cavium.com>
Call of_msi_map_rid() to handle mapping of the requester id.
Signed-off-by: David Daney <david.da...@cavium.com
On 09/23/2015 01:01 AM, Arnd Bergmann wrote:
On Tuesday 22 September 2015 16:49:15 David Daney wrote:
From: David Daney <david.da...@cavium.com>
There are two problems with the bus_max calculation:
1) The u8 data type can overflow for large config space windows.
2) The calcu
On 09/22/2015 06:19 AM, Bjorn Helgaas wrote:
Hi David,
On Fri, Sep 18, 2015 at 06:00:28PM -0700, David Daney wrote:
On 09/18/2015 12:45 PM, Arnd Bergmann wrote:
On Friday 18 September 2015 10:00:32 David Daney wrote:
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
On Thursday 17 September 2015
On 09/23/2015 11:01 AM, Will Deacon wrote:
On Thu, Sep 17, 2015 at 11:02:11PM +0100, David Daney wrote:
[...]
Properties of the /chosen node:
diff --git a/drivers/pci/host/pci-host-generic.c
b/drivers/pci/host/pci-host-generic.c
index 77cf4bd..0a9c453 100644
--- a/drivers/pci/host/pci
On 09/22/2015 11:52 AM, Will Deacon wrote:
On Thu, Sep 17, 2015 at 11:41:34PM +0100, David Daney wrote:
From: David Daney <david.da...@cavium.com>
The config space for external PCIe root complexes on some Cavium
ThunderX SoCs is very similar to CAM and ECAM, but differs in the
shift
On 09/22/2015 09:40 AM, Lorenzo Pieralisi wrote:
On Tue, Sep 22, 2015 at 05:13:45PM +0100, David Daney wrote:
On 09/22/2015 09:05 AM, Lorenzo Pieralisi wrote:
On Thu, Sep 17, 2015 at 11:41:34PM +0100, David Daney wrote:
[...]
Properties of the host controller node:
-- compatible
On 09/22/2015 09:05 AM, Lorenzo Pieralisi wrote:
On Thu, Sep 17, 2015 at 11:41:34PM +0100, David Daney wrote:
From: David Daney <david.da...@cavium.com>
The config space for external PCIe root complexes on some Cavium
ThunderX SoCs is very similar to CAM and ECAM, but differs in the
From: David Daney <david.da...@cavium.com>
When the Cavium mdio-octeon devices appear in the Thunder family of
arm64 based SoCs, they show up as PCI devices. Add PCI driver
wrapping so the driver is bound in the standard PCI device scan.
When in this form, a single PCI device may have mor
to MSI
controllers. This document covers msi-parent, and a new msi-map property
(specific to PCI*) which may be used to map devices (identified by their
Requester ID) to sideband data for each MSI controller that they may
target.
Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by:
From: David Daney <david.da...@cavium.com>
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers. Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.
Sign
From: David Daney <david.da...@cavium.com>
Call of_msi_map_rid() to handle mapping of the requester id.
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/irq
From: David Daney <david.da...@cavium.com>
The first patch from Mark Rutland adds the OF device tree binding
description, which explains what we are attempting to do here. For
MSI messages on GICv3 systems there is some side-band data that
accompanies the message, this data is spe
From: David Daney <david.da...@cavium.com>
If we create multiple buses with pci-host-generic, or there are buses
created by other drivers, we don't want to call pci_fixup_irqs() which
operates on all devices, not just the devices on the bus being added.
The consequence is that either the
From: David Daney <david.da...@cavium.com>
The pci-host-generic driver keeps a global struct pci_ops which it
then patches with the .map_bus method appropriate for the bus device.
A problem arises when the driver is used for two different types of
bus devices, the .map_bus method for th
From: David Daney <david.da...@cavium.com>
There are two problems with the bus_max calculation:
1) The u8 data type can overflow for large config space windows.
2) The calculation is incorrect for a bus range that doesn't start at
zero.
Since the configuration space is relative to bu
From: David Daney <david.da...@cavium.com>
pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
the fixups for devices on the specified bus.
Follow-on patch will use the new function.
Signed-off-by: David Daney <david.da...@cavium.com>
---
No change from v2.
This
From: David Daney <david.da...@cavium.com>
In the case where the PCI_PROBE_ONLY flag is set, we need to claim the
resources for all PCI devices added to the bus. Failure to claim
SRIOV BAR resources prevents SRIOV devices from being being enabled.
So, when the PCI_PROBE_ONLY flag is set,
From: David Daney <david.da...@cavium.com>
While using the pci-host-generic driver to add PCI support for the
Cavium ThunderX processors, several bugs were discovered. This patch
set fixes the bugs, a follow-on set will add the ThunderX support.
Changes from v2:
- Added " PCI: gen
From: David Daney <david.da...@cavium.com>
If the bus is being configured with a bus-range that does not start at
zero, pass that starting bus number to pci_scan_root_bus(). Passing
the incorrect value of zero causes attempted config accesses outside
of the supported range, which ca
From: David Daney <david.da...@cavium.com>
The config space for external PCIe root complexes on some Cavium
ThunderX SoCs is very similar to CAM and ECAM, but differs in the
shift values that have to be applied to the bus and devfn numbers to
compose that address window offset. Thes
On 09/21/2015 08:58 AM, Marc Zyngier wrote:
On Fri, 18 Sep 2015 10:54:02 -0700
David Daney <dda...@caviumnetworks.com> wrote:
On 09/18/2015 01:51 AM, Marc Zyngier wrote:
On Thu, 17 Sep 2015 11:00:59 -0700
David Daney <ddaney.c...@gmail.com> wrote:
Hi David,
From: David Dan
On 09/18/2015 12:45 PM, Arnd Bergmann wrote:
On Friday 18 September 2015 10:00:32 David Daney wrote:
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
On Thursday 17 September 2015 15:41:33 David Daney wrote:
From: David Daney <david.da...@cavium.com>
The on-chip devices all have fixed bar
On 09/18/2015 01:51 AM, Marc Zyngier wrote:
On Thu, 17 Sep 2015 11:00:59 -0700
David Daney <ddaney.c...@gmail.com> wrote:
Hi David,
From: David Daney <david.da...@cavium.com>
Search up the device hierarchy to find devices with a "msi-map"
property, if found apply
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
On Thursday 17 September 2015 15:41:33 David Daney wrote:
From: David Daney <david.da...@cavium.com>
The on-chip devices all have fixed bars. So, fix them up.
Signed-off-by: David Daney <david.da...@cavium.com>
You should be able
On 09/16/2015 03:32 AM, Lorenzo Pieralisi wrote:
On Tue, Sep 15, 2015 at 06:49:24PM +0100, David Daney wrote:
On 09/15/2015 10:36 AM, Will Deacon wrote:
Hi David,
On Sat, Sep 12, 2015 at 12:21:55AM +0100, David Daney wrote:
From: David Daney <david.da...@cavium.com>
Use pci_wa
to MSI
controllers. This document covers msi-parent, and a new msi-map property
(specific to PCI*) which may be used to map devices (identified by their
Requester ID) to sideband data for each MSI controller that they may
target.
Signed-off-by: Mark Rutland <mark.rutl...@arm.com>
Signed-off-by:
From: David Daney <david.da...@cavium.com>
Search up the device hierarchy to find devices with a "msi-map"
property, if found apply the mapping to the GIC device id.
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/irqchip/irq-gic
From: David Daney <david.da...@cavium.com>
The first patch from Mark Rutland adds the OF device tree binding
description, which explains what we are attempting to do here. For
MSI messages on GICv3 systems there is some side-band data that
accompanies the message, this data is spe
From: David Daney <david.da...@cavium.com>
There are two problems with the bus_max calculation:
1) The u8 data type can overflow for large config space windows.
2) The calculation is incorrect for a bus range that doesn't start at
zero.
Since the configuration space is relative to bu
From: David Daney <david.da...@cavium.com>
pci_bus_fixup_irqs() works like pci_fixup_irqs(), except it only does
the fixups for devices on the specified bus.
Follow-on patch will use the new function.
Signed-off-by: David Daney <david.da...@cavium.com>
---
This patch didn't
From: David Daney <david.da...@cavium.com>
The pci-host-generic driver keeps a global struct pci_ops which it
then patches with the .map_bus method appropriate for the bus device.
A problem arises when the driver is used for two different types of
bus devices, the .map_bus method for th
From: David Daney <david.da...@cavium.com>
If the bus is being configured with a bus-range that does not start at
zero, pass that starting bus number to pci_scan_root_bus(). Passing
the incorrect value of zero causes attempted config accesses outside
of the supported range, which ca
From: David Daney <david.da...@cavium.com>
While using the pci-host-generic driver to add PCI support for the
Cavium ThunderX processors, several bugs were discovered. This patch
set fixes the bugs, a follow-on set will add the ThunderX support.
Changes from v1:
- "PCI: generic
From: David Daney <david.da...@cavium.com>
If we create multiple buses with pci-host-generic, or there are buses
created by other drivers, we don't want to call pci_fixup_irqs() which
operates on all devices, not just the devices on the bus being added.
The consequence is that either the
From: David Daney <david.da...@cavium.com>
The config space for external PCIe root complexes on some Cavium
ThunderX SoCs is very similar to CAM and ECAM, but differs in the
shift values that have to be applied to the bus and devfn numbers to
compose that address window offset. Thes
From: David Daney <david.da...@cavium.com>
The on-chip devices all have fixed bars. So, fix them up.
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/pci/host/Kconfig | 6 +++
drivers/pci/host/Makefile | 1 +
drivers/pci/host/quirks-th
From: David Daney <david.da...@cavium.com>
Devices with fixed BARs can install BAR resources with
IORESOURCE_PCI_FIXED from the header fixup. Allow this to work with
the SRIOV BARs as well by testing if the BAR resource has already been
set before attempting to read it from the config
From: David Daney <david.da...@cavium.com>
The Cavium ThunderX arm64 based SoC needs a little bit of special
handling for both its PCIe Root Complexes as well as on-SoC devices
(which all appear as PCIe devices).
1/3 - Small change to allow SRIOV BARs to be given fixed add
r non-zero start_bus.
I anticipate sending a new version of the patch set later today (PDT).
I will add any Acked-by/Reviewed-by that I receive to the new set.
David Daney
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/11/2015 04:21 PM, David Daney wrote:
From: David Daney <david.da...@cavium.com>
While using the pci-host-generic driver to add PCI support for the
Cavium ThunderX processors, several bugs were discovered. We also
need the ability to specify a per-bus MSI controller, so s
On 09/15/2015 11:35 AM, Will Deacon wrote:
On Tue, Sep 15, 2015 at 07:02:54PM +0100, David Daney wrote:
On 09/15/2015 10:49 AM, Will Deacon wrote:
On Sat, Sep 12, 2015 at 12:21:57AM +0100, David Daney wrote:
/* Limit the bus-range to fit within reg */
- bus_max = pci
On 09/15/2015 10:49 AM, Will Deacon wrote:
On Sat, Sep 12, 2015 at 12:21:57AM +0100, David Daney wrote:
From: David Daney <david.da...@cavium.com>
There are two problems with the bus_max calculation:
1) The u8 data type can overflow for large config space windows.
2) The calcu
On 09/15/2015 10:53 AM, Will Deacon wrote:
On Sat, Sep 12, 2015 at 12:21:59AM +0100, David Daney wrote:
From: David Daney <david.da...@cavium.com>
If the device tree node for the bus has a "msi-parent" property, use
that as the default MSI controller for devices on the bus.
On 09/15/2015 10:36 AM, Will Deacon wrote:
Hi David,
On Sat, Sep 12, 2015 at 12:21:55AM +0100, David Daney wrote:
From: David Daney <david.da...@cavium.com>
Use pci_walk_bus() to restrict the fixup irq actions to only the bus
being created.
If we create multiple buses with pci-host-g
From: David Daney <david.da...@cavium.com>
If the device tree node for the bus has a "msi-parent" property, use
that as the default MSI controller for devices on the bus. Add device
tree binding documentation describing the new property.
This allows the pci-host-generic d
From: David Daney <david.da...@cavium.com>
While using the pci-host-generic driver to add PCI support for the
Cavium ThunderX processors, several bugs were discovered. We also
need the ability to specify a per-bus MSI controller, so support for
that was added.
David Daney (6):
PCI
From: David Daney <david.da...@cavium.com>
Follow-on patch will use pdev_fixup_irq(). So, make it visible and
export it.
Signed-off-by: David Daney <david.da...@cavium.com>
---
drivers/pci/setup-irq.c | 7 ---
include/linux/pci.h | 3 +++
2 files changed, 7 insertions(+),
From: David Daney <david.da...@cavium.com>
There are two problems with the bus_max calculation:
1) The u8 data type can overflow for large config space windows.
2) The calculation is incorrect for a bus range that doesn't start at
zero.
Since the configuration space is relative to bu
From: David Daney <david.da...@cavium.com>
The pci-host-generic driver keeps a global struct pci_ops which it
then patches with the .map_bus method appropriate for the bus device.
A problem arises when the driver is used for two different types of
bus devices, the .map_bus method for th
From: David Daney <david.da...@cavium.com>
The config space for external PCIe root complexes on some Cavium
ThunderX SoCs is very similar to CAM and ECAM, but differs in the
shift values that have to be applied to the bus and devfn numbers to
compose that address window offset. Thes
On 09/09/2015 10:44 AM, Frank Rowand wrote:
Second attempt at this reply. The first reply was mangled.
On 9/8/2015 11:28 AM, David Daney wrote:
From: David Daney <david.da...@cavium.com>
It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero. This h
wrote:
Hi David,
On Sat, Aug 8, 2015 at 2:11 AM, David Daney <dda...@caviumnetworks.com> wrote:
On 08/07/2015 05:05 PM, Rafael J. Wysocki wrote:
[cut]
It is actually useful to people as far as I can say.
Also, if somebody is going to use properties with ACPI, why whould
th
From: David Daney <david.da...@cavium.com>
It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.
Silence the annoying "of_irq_parse_pci() fai
From: David Daney <david.da...@cavium.com>
It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero. This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.
Silence the annoying "of_irq_parse_pci() fai
1 - 100 of 121 matches
Mail list logo
