From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
From: Kai-Heng Feng
[ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ]
7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for
Linux to enable ASPM, but for some undocumented reason, it didn't enable
ASPM on links where the downstream component is a PC
On Thu, Jun 18, 2015 at 12:55:53PM -0500, Bjorn Helgaas wrote:
> On Fri, Jun 12, 2015 at 05:35:57PM -0700, Duc Dang wrote:
> > X-Gene v1 PCIe controller has a bug in Configuration Request Retry
> > Status (CRS) logic:
> > When CPU tries to read Vendor ID and Device ID of not-existed
> > remote
On Thu, Jun 18, 2015 at 10:55 AM, Bjorn Helgaas wrote:
> On Fri, Jun 12, 2015 at 05:35:57PM -0700, Duc Dang wrote:
>> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
>> Status (CRS) logic:
>> When CPU tries to read Vendor ID and Device ID of not-existed
>> remote device, the
Hi,
On Fri, Jun 12, 2015 at 5:35 PM, Duc Dang wrote:
> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
> Status (CRS) logic:
> When CPU tries to read Vendor ID and Device ID of not-existed
> remote device, the controller returns 0x0001 instead of
> 0x; this wi
On Fri, Jun 12, 2015 at 05:35:57PM -0700, Duc Dang wrote:
> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
> Status (CRS) logic:
> When CPU tries to read Vendor ID and Device ID of not-existed
> remote device, the controller returns 0x0001 instead of
> 0x; this
X-Gene v1 PCIe controller has a bug in Configuration Request Retry
Status (CRS) logic:
When CPU tries to read Vendor ID and Device ID of not-existed
remote device, the controller returns 0x0001 instead of
0x; this will add significant delay in boot time as
pci_bus_read_dev_vendo
On Fri, Jun 12, 2015 at 5:10 PM, Duc Dang wrote:
> Hi Bjorn,
>
> On Fri, Jun 12, 2015 at 2:59 PM, Bjorn Helgaas wrote:
>> Hi Duc,
>>
>> On Thu, Jun 11, 2015 at 01:08:14PM -0700, Duc Dang wrote:
>>> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
>>> Status (CRS) logic:
>>> Wh
Hi Bjorn,
On Fri, Jun 12, 2015 at 2:59 PM, Bjorn Helgaas wrote:
> Hi Duc,
>
> On Thu, Jun 11, 2015 at 01:08:14PM -0700, Duc Dang wrote:
>> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
>> Status (CRS) logic:
>> When CPU tries to read Vendor ID and Device ID of not-existed
>
Hi Duc,
On Thu, Jun 11, 2015 at 01:08:14PM -0700, Duc Dang wrote:
> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
> Status (CRS) logic:
> When CPU tries to read Vendor ID and Device ID of not-existed
> remote device, the controller returns 0x0001 instead of
> 0xF
On Thu, 2015-06-11 at 13:08 -0700, Duc Dang wrote:
> X-Gene v1 PCIe controller has a bug in Configuration Request Retry
> Status (CRS) logic:
> When CPU tries to read Vendor ID and Device ID of not-existed
> remote device, the controller returns 0x0001 instead of
> 0x; this will a
W dniu 11.06.2015 o 22:08, Duc Dang pisze:> X-Gene v1 PCIe controller has a bug
in Configuration Request Retry
> Status (CRS) logic:
>When CPU tries to read Vendor ID and Device ID of not-existed
>remote device, the controller returns 0x0001 instead of
>0x; this will add si
X-Gene v1 PCIe controller has a bug in Configuration Request Retry
Status (CRS) logic:
When CPU tries to read Vendor ID and Device ID of not-existed
remote device, the controller returns 0x0001 instead of
0x; this will add significant delay in boot time as
pci_bus_read_dev_vendo
On Fri, Jun 5, 2015 at 2:05 PM, Bjorn Helgaas wrote:
> On Fri, May 29, 2015 at 11:24:28AM -0700, Duc Dang wrote:
>> This patch set adds MSI/MSIX termination driver support for APM X-Gene v1
>> SoC.
>> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
>> compliant
>> to GIC V
On Fri, May 29, 2015 at 11:24:28AM -0700, Duc Dang wrote:
> This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI b
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
Reviewed-by: Marc Zyngier
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 781e099..59
APM X-Gene v1 SoC supports its own implementation of MSI, which is
not compliant to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
This MSI block supports 2048 MSI termination ports coalesced into 16
physical HW IRQ lines and sh
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
This MSI block sup
On Thu, May 28, 2015 at 1:05 AM, Marc Zyngier wrote:
> On 27/05/15 19:27, Duc Dang wrote:
>> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
>> compliant to GIC V2M specification for MSI Termination.
>>
>> There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe po
On 27/05/15 19:27, Duc Dang wrote:
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
> This MSI block supports 2048 MSI termination ports c
On Mon, May 25, 2015 at 4:52 AM, Marc Zyngier wrote:
> On Fri, 22 May 2015 19:41:10 +0100
> Duc Dang wrote:
>
>> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
>> compliant
>> to GIC V2M specification for MSI Termination.
>>
>> There is single MSI block in X-Gene v1 SOC w
APM X-Gene v1 SoC supports its own implementation of MSI, which is not
compliant to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
This MSI block supports 2048 MSI termination ports coalesced into 16
physical HW IRQ lines and sh
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
Reviewed-by: Marc Zyngier
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 781e099..59a
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
On Fri, 22 May 2015 19:41:10 +0100
Duc Dang wrote:
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
> This MSI
> block supports 2048
On Wed, May 20, 2015 at 2:16 AM, Marc Zyngier wrote:
> On Mon, 18 May 2015 10:55:19 +0100
> Duc Dang wrote:
>
>> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
>> compliant
>> to GIC V2M specification for MSI Termination.
>>
>> There is single MSI block in X-Gene v1 SOC w
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block supports 2048 MSI termination ports coalesced into 16 physical HW IRQ
lines
and
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
On Mon, 18 May 2015 10:55:19 +0100
Duc Dang wrote:
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
> This MSI
> block supports 2048
On Wed, Apr 22, 2015 at 5:50 AM, Marc Zyngier wrote:
>
> On Wed, 22 Apr 2015 07:15:09 +0100
> Duc Dang wrote:
>
> > APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> > compliant
> > to GIC V2M specification for MSI Termination.
> >
> > There is single MSI block in X-Gene v
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block supports 2048 MSI termination ports coalesced into 16 physical HW IRQ
lines
and
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
On Wed, 22 Apr 2015 07:15:09 +0100
Duc Dang wrote:
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
> This MSI
> block supports 2048
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block supports 2048 MSI termination ports coalesced into 16 physical HW IRQ
lines
and
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
On 04/21/2015 12:04 AM, Duc Dang wrote:
> This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1
On 04/21/2015 12:04 AM, Duc Dang wrote:
> This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1
On 21/04/15 05:04, Duc Dang wrote:
> X-Gene v1 SoC supports total 256 MSI/MSIX vectors coalesced into
> 16 HW IRQ lines.
This commit message could be beefed up to describe what this really does.
> Signed-off-by: Duc Dang
> Signed-off-by: Tanmay Inamdar
> ---
> drivers/pci/host/Kconfig
On 20/04/15 19:51, Feng Kan wrote:
> Is it possible to use the pci_msi_create_default_irq_domain for the X-Gene MSI
> driver. Or is this going to be removed in the future. Thanks
This is not the preferred way. pci_msi_create_default_irq_domain is only
there for legacy purposes, so that we can loo
On Monday 20 April 2015 11:49:37 Feng Kan wrote:
> >
> > Obviously they appear on the PCI host bridge in order, because that
> > is a how PCI works. My question was about what happens then. On a lot
> > of SoCs, there is something like an AXI bus that uses posted
> > transactions between PCI and RA
X-Gene v1 SoC supports total 256 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pci-xgene-msi.c | 477
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
On Fri, Apr 17, 2015 at 5:45 AM, Marc Zyngier wrote:
> On 17/04/15 13:37, Duc Dang wrote:
>> On Fri, Apr 17, 2015 at 3:17 AM, Marc Zyngier wrote:
>>> On 17/04/15 11:00, Duc Dang wrote:
On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
> On Tue, 14 Apr 2015 19:20:19 +0100
> Duc Da
On Sun, Apr 19, 2015 at 12:55 PM, Arnd Bergmann wrote:
> On Sunday 19 April 2015 11:40:09 Duc Dang wrote:
>> On Fri, Apr 17, 2015 at 7:10 AM, Arnd Bergmann wrote:
>> > On Friday 17 April 2015 02:50:07 Duc Dang wrote:
>> >> +
>> >> + /*
>> >> +* MSIINTn (n is 0..F) indicates if there
On Sunday 19 April 2015 11:40:09 Duc Dang wrote:
> On Fri, Apr 17, 2015 at 7:10 AM, Arnd Bergmann wrote:
> > On Friday 17 April 2015 02:50:07 Duc Dang wrote:
> >> +
> >> + /*
> >> +* MSIINTn (n is 0..F) indicates if there is a pending MSI
> >> interrupt
> >> +* If bit x of t
On Fri, Apr 17, 2015 at 7:10 AM, Arnd Bergmann wrote:
> On Friday 17 April 2015 02:50:07 Duc Dang wrote:
>> +
>> + /*
>> +* MSIINTn (n is 0..F) indicates if there is a pending MSI interrupt
>> +* If bit x of this register is set (x is 0..7), one or more
>> interupts
>> +
On Friday 17 April 2015 02:50:07 Duc Dang wrote:
> +
> + /*
> +* MSIINTn (n is 0..F) indicates if there is a pending MSI interrupt
> +* If bit x of this register is set (x is 0..7), one or more interupts
> +* corresponding to MSInIRx is set.
> +*/
> + grp
On 17/04/15 13:37, Duc Dang wrote:
> On Fri, Apr 17, 2015 at 3:17 AM, Marc Zyngier wrote:
>> On 17/04/15 11:00, Duc Dang wrote:
>>> On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
On Tue, 14 Apr 2015 19:20:19 +0100
Duc Dang wrote:
> On Sat, Apr 11, 2015 at 5:06 AM, Marc Z
On Fri, Apr 17, 2015 at 3:17 AM, Marc Zyngier wrote:
> On 17/04/15 11:00, Duc Dang wrote:
>> On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
>>> On Tue, 14 Apr 2015 19:20:19 +0100
>>> Duc Dang wrote:
>>>
On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
wrote:
> On 2015-04-11 00:
On 17/04/15 11:00, Duc Dang wrote:
> On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
>> On Tue, 14 Apr 2015 19:20:19 +0100
>> Duc Dang wrote:
>>
>>> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
>>> wrote:
On 2015-04-11 00:42, Duc Dang wrote:
>
> On Fri, Apr 10, 2015 at 10:20 A
On Wed, Apr 15, 2015 at 1:16 AM, Marc Zyngier wrote:
> On Tue, 14 Apr 2015 19:20:19 +0100
> Duc Dang wrote:
>
>> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
>> wrote:
>> > On 2015-04-11 00:42, Duc Dang wrote:
>> >>
>> >> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
>> >> wrote:
>> >>>
>> >>
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
X-Gene v1 SoC supports total 2048 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pci-xgene-msi.c | 410 +++
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
On Tue, 14 Apr 2015 19:20:19 +0100
Duc Dang wrote:
> On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier
> wrote:
> > On 2015-04-11 00:42, Duc Dang wrote:
> >>
> >> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
> >> wrote:
> >>>
> >>> On 09/04/15 18:05, Duc Dang wrote:
>
> X-Gene v1 SoC su
On Sat, Apr 11, 2015 at 5:06 AM, Marc Zyngier wrote:
> On 2015-04-11 00:42, Duc Dang wrote:
>>
>> On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
>> wrote:
>>>
>>> On 09/04/15 18:05, Duc Dang wrote:
X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
>
On Friday 10 April 2015 17:16:32 Feng Kan wrote:
> Hi Marc:
>
> Is there any plans to support ACPI for GICv2m MSI? Both this driver and the
> GICv2m seems to support OF model of discovery for msi controller. X-Gene1
> uses this driver and X-Gene2 uses GICv2m, there needs to be a way to
> associate
Hi Feng,
On 2015-04-11 01:16, Feng Kan wrote:
Is there any plans to support ACPI for GICv2m MSI? Both this driver
and the
GICv2m seems to support OF model of discovery for msi controller.
X-Gene1
uses this driver and X-Gene2 uses GICv2m, there needs to be a way to
associate msi controller wit
On 2015-04-11 00:42, Duc Dang wrote:
On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier
wrote:
On 09/04/15 18:05, Duc Dang wrote:
X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfi
Hi Marc:
Is there any plans to support ACPI for GICv2m MSI? Both this driver and the
GICv2m seems to support OF model of discovery for msi controller. X-Gene1
uses this driver and X-Gene2 uses GICv2m, there needs to be a way to
associate msi controller with the PCIe bus. I haven't
found a standard
On Fri, Apr 10, 2015 at 11:13 AM, Paul Bolle wrote:
> Just a nit about a license mismatch.
>
> On Thu, 2015-04-09 at 10:05 -0700, Duc Dang wrote:
>> --- a/drivers/pci/host/Kconfig
>> +++ b/drivers/pci/host/Kconfig
>
>> +config PCI_XGENE_MSI
>> + bool "X-Gene v1 PCIe MSI feature"
>> + depen
On Fri, Apr 10, 2015 at 10:20 AM, Marc Zyngier wrote:
> On 09/04/15 18:05, Duc Dang wrote:
>> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
>> 16 HW IRQ lines.
>>
>> Signed-off-by: Duc Dang
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig | 6 +
>
On Thu, Apr 09, 2015 at 10:05:03AM -0700, Duc Dang wrote:
> X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
> 16 HW IRQ lines.
>
> Signed-off-by: Duc Dang
> Signed-off-by: Tanmay Inamdar
> ...
> --- /dev/null
> +++ b/drivers/pci/host/pci-xgene-msi.c
> @@ -0,0 +1,407 @@
> ...
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
X-Gene v1 SoC supports total 2688 MSI/MSIX vectors coalesced into
16 HW IRQ lines.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
drivers/pci/host/Kconfig | 6 +
drivers/pci/host/Makefile| 1 +
drivers/pci/host/pci-xgene-msi.c | 407 +++
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
On Thu, Nov 06, 2014 at 05:14:18PM -0800, Duc Dang wrote:
> X-Gene PCIE driver currently depends on Liviu Dudau's patch
> https://lkml.org/lkml/2014/9/30/166 in order to assign resource
> to root bus and endpoint devices. The patch was dropped because
> it will break x86, powerpc and probably other
X-Gene PCIE driver currently depends on Liviu Dudau's patch
https://lkml.org/lkml/2014/9/30/166 in order to assign resource
to root bus and endpoint devices. The patch was dropped because
it will break x86, powerpc and probably others. So X-Gene PCIE
host functionality is currently broken.
This pa
The ACPI _HPP method was defined before PCIe existed, so its documentation
only mentions PCI. The _HPX Type 0 setting record is essentially identical
to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied
to PCI, PCI-X, and PCIe devices, with settings being ignored if they
Hi,
i run a machine with 4 dual gigabit ethernet cards utilizing 2.6.22.7.
All cards are PCI-E, one card is PCI-X, all Gigabit Ethernet from Intel.
This is working fine and stable if only the PCI-E cards are used.
If i try to capture packets on the PCI-X card, the machine reboots after
some
gt; > card is operating. As is seen here (although a bit truncated --
> > > > separate issue, I'll try to see if I can reproduce this on one of my
> > > > HPQ rigs), the card is inserted into a PCI-X Mode-2 capable 133MHz
> > > > (bus clock) slot. Wh
gt; > > separate issue, I'll try to see if I can reproduce this on one of my
> > > HPQ rigs), the card is inserted into a PCI-X Mode-2 capable 133MHz
> > > (bus clock) slot. When operating under this mode, each data-phase
> > > between two devices is divided i
> > > I have a question: The Qlogic ISP2422 chip is said to handle PCI-X
> > > > 266MHz. So does
> > > > the HP Itanium2 server rx6600. Basically that was the reason to select
> > > > that
> > > > server. The FC-HBA is in a 266 MHz capa
I'll try to see if I can reproduce this on one of my
> > HPQ rigs), the card is inserted into a PCI-X Mode-2 capable 133MHz
> > (bus clock) slot. When operating under this mode, each data-phase
> > between two devices is divided into 2 sub-phases, effectively doubling
> > the
On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote:
> On Thu, 26 Jul 2007, Andrew Patterson wrote:
>
> > On Thu, 2007-07-26 at 15:36 +0200, Ulrich Windl wrote:
> > > Hi,
> > >
> > > I have a question: The Qlogic ISP2422 chip is said to handle PCI
On Thu, 26 Jul 2007, Andrew Patterson wrote:
> On Thu, 2007-07-26 at 15:36 +0200, Ulrich Windl wrote:
> > Hi,
> >
> > I have a question: The Qlogic ISP2422 chip is said to handle PCI-X 266MHz.
> > So does
> > the HP Itanium2 server rx6600. Basically t
On Thu, 2007-07-26 at 15:36 +0200, Ulrich Windl wrote:
> Hi,
>
> I have a question: The Qlogic ISP2422 chip is said to handle PCI-X 266MHz. So
> does
> the HP Itanium2 server rx6600. Basically that was the reason to select that
> server. The FC-HBA is in a 266 MHz capable
Hi,
I have a question: The Qlogic ISP2422 chip is said to handle PCI-X 266MHz. So
does
the HP Itanium2 server rx6600. Basically that was the reason to select that
server. The FC-HBA is in a 266 MHz capable slot. However when booting SLES10
SP1
for IA64, the logs say:
<6>QLogic Fibre C
On Tue, 15 May 2007 13:59:13 +0200 Peter Oruba wrote:
> This patch introduces an interface to read and write PCI-X / PCI-Express
> maximum read byte count values from PCI config space. There is a second
> function that returns the maximum _designed_ read byte count, which marks the
t.
>
>
>
Sorry, I missed out an essential part in the qla2xxx driver, namely the MMRBC
configuration for PCI-X. The submitted patch only did that for PCIe. This is
the corrected version
The pre-condition check is there to not blindly call the mmrbc-functions, but
to check for the bus t
Am Dienstag, 15. Mai 2007 21:37:21 schrieb Andrew Morton:
> On Tue, 15 May 2007 13:50:27 +0200
>
> "Peter Oruba" <[EMAIL PROTECTED]> wrote:
> > This patch set introduces a PCI-X / PCI-Express read byte count control
> > interface. Instead of letting every
On Tue, 15 May 2007, Andrew Morton wrote:
> On Tue, 15 May 2007 13:50:27 +0200
> "Peter Oruba" <[EMAIL PROTECTED]> wrote:
>
> > This patch set introduces a PCI-X / PCI-Express read byte count control
> > interface. Instead of letting every driver to directl
Andrew Morton wrote:
On Tue, 15 May 2007 13:50:27 +0200
"Peter Oruba" <[EMAIL PROTECTED]> wrote:
This patch set introduces a PCI-X / PCI-Express read byte count control
interface. Instead of letting every driver to directly read/write to PCI
config space for that, an inter
On 5/15/07, Peter Oruba <[EMAIL PROTECTED]> wrote:
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those valuse doesn't take
place "manually", instead wrapping functions are called to allow quirks for
some PCI
On Tue, 15 May 2007 13:50:27 +0200
"Peter Oruba" <[EMAIL PROTECTED]> wrote:
> This patch set introduces a PCI-X / PCI-Express read byte count control
> interface. Instead of letting every driver to directly read/write to PCI
> config space for that, an interface i
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those valuse doesn't take
place "manually", instead wrapping functions are called to allow quirks for
some PCI bridges.
Signed-off by: Peter Oruba <[EMAIL PROTECT
1 - 100 of 111 matches
Mail list logo
