@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus
if (!parent || !pci_is_pcie(parent))
return 0;
+ #ifndef CONFIG_PPC_PASEMI_NEMO
+ // SB600 for the Nemo board has non-zero devices on non-root bus.
if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT)
return 1;
@@ -2231,6 +2233,7 @@ static int only_one_child(struct pci_bus
if (parent->has_secondary_link &&
!pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS))
return 1;
+ #endif
return 0;
}
----
This is my first patch on this mailing list. Sorry if it isn't in a good quality. I am still learning. I hope you can add it.
Thanks,
Christian
@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus
As this is a patch to the PCI code I can't merge it via the powerpc
tree. You would need to send it to linux-pci@vger.kernel.org.
quoted hunk
=C2=A0=C2=A0=C2=A0=C2=A0 if (!parent || !pci_is_pcie(parent)) =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return 0;+=C2=A0=C2=A0=C2=A0 #ifndef CONFIG_PPC_PASEMI_NEMO+=C2=A0=C2=A0=C2=A0 // SB600 for the Nemo board has non-zero devices on n=
on-root bus.
=C2=A0=C2=A0=C2=A0=C2=A0 if (pci_pcie_type(parent) =3D=3D PCI_EXP_TYPE_R=
But the PCI maintainer is not going to accept a patch like this, which
adds a platform specific #ifdef in core code like this.
If you look at the rest of that file I don't think you'll find a single
#ifdef other than for generic configuration symbols.
Are you sure the PCI_SCAN_ALL_PCIE_DEVS logic doesn't work for you? It
sounds like it was added for exactly this problem.
cheers
@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus
As this is a patch to the PCI code I can't merge it via the powerpc
tree. You would need to send it to linux-pci@vger.kernel.org.
quoted
if (!parent || !pci_is_pcie(parent)) return 0;+ #ifndef CONFIG_PPC_PASEMI_NEMO+ // SB600 for the Nemo board has non-zero devices on non-root bus. if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT) return 1;
@@ -2231,6 +2233,7 @@ static int only_one_child(struct pci_bus if (parent->has_secondary_link && !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS)) return 1;+ #endif
But the PCI maintainer is not going to accept a patch like this, which
adds a platform specific #ifdef in core code like this.
If you look at the rest of that file I don't think you'll find a single
#ifdef other than for generic configuration symbols.
Are you sure the PCI_SCAN_ALL_PCIE_DEVS logic doesn't work for you? It
sounds like it was added for exactly this problem.
cheers
Hi Michael,
Thanks for your reply. Sorry for my late answer. I removed the patch above from the RC1 and compiled the RC1 again. Unfortunately without the patch, the kernel doesn't recognize any drives and partitions. Do you have another idea?
Thanks,
Christian
@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus
As this is a patch to the PCI code I can't merge it via the powerpc
tree. You would need to send it to linux-pci@vger.kernel.org.
quoted
if (!parent || !pci_is_pcie(parent)) return 0;+ #ifndef CONFIG_PPC_PASEMI_NEMO+ // SB600 for the Nemo board has non-zero devices on non-root bus. if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT) return 1;
@@ -2231,6 +2233,7 @@ static int only_one_child(struct pci_bus if (parent->has_secondary_link && !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS)) return 1;+ #endif
But the PCI maintainer is not going to accept a patch like this, which
adds a platform specific #ifdef in core code like this.
If you look at the rest of that file I don't think you'll find a single
#ifdef other than for generic configuration symbols.
Are you sure the PCI_SCAN_ALL_PCIE_DEVS logic doesn't work for you? It
sounds like it was added for exactly this problem.
cheers
Hi Michael,
Thanks for your reply. Sorry for my late answer. I removed the patch above
from the RC1 and compiled the RC1 again. Unfortunately without the patch,
the kernel doesn't recognize any drives and partitions. Do you have another
idea?
What happens if you boot RC1 with "pci=pcie_scan_all"? If that works,
we do have some quirks that set that automatically, and we might be
able to add another one for the Nemo.
Can you collect the complete "lspci -vv" and dmesg output for this
system? I'm curious about why it is special.
Bjorn
@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus
As this is a patch to the PCI code I can't merge it via the powerpc
tree. You would need to send it to linux-pci@vger.kernel.org.
quoted
if (!parent || !pci_is_pcie(parent)) return 0;+ #ifndef CONFIG_PPC_PASEMI_NEMO+ // SB600 for the Nemo board has non-zero devices on non-root bus. if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT) return 1;
@@ -2231,6 +2233,7 @@ static int only_one_child(struct pci_bus if (parent->has_secondary_link && !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS)) return 1;+ #endif
But the PCI maintainer is not going to accept a patch like this, which
adds a platform specific #ifdef in core code like this.
If you look at the rest of that file I don't think you'll find a single
#ifdef other than for generic configuration symbols.
Are you sure the PCI_SCAN_ALL_PCIE_DEVS logic doesn't work for you? It
sounds like it was added for exactly this problem.
cheers
Hi Michael,
Thanks for your reply. Sorry for my late answer. I removed the patch above
from the RC1 and compiled the RC1 again. Unfortunately without the patch,
the kernel doesn't recognize any drives and partitions. Do you have another
idea?
What happens if you boot RC1 with "pci=pcie_scan_all"? If that works,
we do have some quirks that set that automatically, and we might be
able to add another one for the Nemo.
Can you collect the complete "lspci -vv" and dmesg output for this
system? I'm curious about why it is special.
Bjorn
Hi Bjorn,
Thank you for your answer. I have tried to boot the kernel 4.15 RC1 (built without the patch above) with the boot argument "pci=pcie_scan_all" but without any success.
Just for info:
The CPU is a PA Semi “PWRficient” PA6T-1682M. This device combines dual 1.8GHz PowerPC cores with a 2MB L2 cache, dual channel DDR2 memory controllers and 24 SerDes
channels. The PowerPC cores adhere to the Power ISA v2.04, and support 64-bit extensions. They feature a double precision FPU and a VMX (AltiVec) vector unit. They each have a 64kB I-cache and a 64kB D-cache.
The SerDes channels support PCI Express, XAUI and SGMII protocols. The “ENVOI” I/O subsystem which drives them includes caching, offload and DMA resources to maximise I/O
performance.
Nemo uses the AMD/ATI SB600 South Bridge to provide various integrated I/O functions including SATA/PATA ports, USB and audio. The SB600 connects to the CPU via a PCIe x4 link. This is termed an “A-link II Express” link by ATI/AMD. The design team determined early in the development of Nemo that the link’s behaviour as an endpoint does not comply fully with the PCI Express specification. Specifically, it requires the root complex to use non-zero device numbers in type 0 configuration cycles to enumerate all the devices within the SB600. This is related to the PC architecture and is used to allow SB600 devices appear on logical bus 0.
More information about the Nemo board:
https://en.wikipedia.org/wiki/AmigaOne_X1000http://www.a-eon.com/?page=x1000http://www.amigaos.net/hardware/35/amigaone-x1000
Please find attached the complete "lspci -vv" and dmesg output.
Thanks,
Christian
@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus
As this is a patch to the PCI code I can't merge it via the powerpc
tree. You would need to send it to linux-pci@vger.kernel.org.
quoted
if (!parent || !pci_is_pcie(parent)) return 0;+ #ifndef CONFIG_PPC_PASEMI_NEMO+ // SB600 for the Nemo board has non-zero devices on non-root bus. if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT) return 1;
@@ -2231,6 +2233,7 @@ static int only_one_child(struct pci_bus if (parent->has_secondary_link && !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS)) return 1;+ #endif
But the PCI maintainer is not going to accept a patch like this, which
adds a platform specific #ifdef in core code like this.
If you look at the rest of that file I don't think you'll find a single
#ifdef other than for generic configuration symbols.
Are you sure the PCI_SCAN_ALL_PCIE_DEVS logic doesn't work for you? It
sounds like it was added for exactly this problem.
cheers
Hi Michael,
Thanks for your reply. Sorry for my late answer. I removed the patch
above
from the RC1 and compiled the RC1 again. Unfortunately without the patch,
the kernel doesn't recognize any drives and partitions. Do you have
another
idea?
What happens if you boot RC1 with "pci=pcie_scan_all"? If that works,
we do have some quirks that set that automatically, and we might be
able to add another one for the Nemo.
Can you collect the complete "lspci -vv" and dmesg output for this
system? I'm curious about why it is special.
Bjorn
Hi Bjorn,
Thank you for your answer. I have tried to boot the kernel 4.15 RC1 (built
without the patch above) with the boot argument "pci=pcie_scan_all" but
without any success.
Just for info:
The CPU is a PA Semi “PWRficient” PA6T-1682M. This device combines dual
1.8GHz PowerPC cores with a 2MB L2 cache, dual channel DDR2 memory
controllers and 24 SerDes
channels. The PowerPC cores adhere to the Power ISA v2.04, and support
64-bit extensions. They feature a double precision FPU and a VMX (AltiVec)
vector unit. They each have a 64kB I-cache and a 64kB D-cache.
The SerDes channels support PCI Express, XAUI and SGMII protocols. The
“ENVOI” I/O subsystem which drives them includes caching, offload and DMA
resources to maximise I/O
performance.
Nemo uses the AMD/ATI SB600 South Bridge to provide various integrated I/O
functions including SATA/PATA ports, USB and audio. The SB600 connects to
the CPU via a PCIe x4 link. This is termed an “A-link II Express” link by
ATI/AMD. The design team determined early in the development of Nemo that
the link’s behaviour as an endpoint does not comply fully with the PCI
Express specification. Specifically, it requires the root complex to use
non-zero device numbers in type 0 configuration cycles to enumerate all the
devices within the SB600. This is related to the PC architecture and is used
to allow SB600 devices appear on logical bus 0.
More information about the Nemo board:
https://en.wikipedia.org/wiki/AmigaOne_X1000http://www.a-eon.com/?page=x1000http://www.amigaos.net/hardware/35/amigaone-x1000
Please find attached the complete "lspci -vv" and dmesg output.
Thanks. Can you collect the "lspci -vv" output as root? The one you
attached wasn't as root and doesn't include the PCI capability
information, which we need so we can tell which devices appear as
conventional PCI and which as PCIe.
It would also be helpful if you could send plain-text email because
the linux-pci list discards fancy email
(http://vger.kernel.org/majordomo-info.html#taboo).
It looks like the SB600 devices actually appear on bus 05 (not 00),
right? I see these devices (among others):
00:10.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
00:11.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
01:00.0 VGA compatible controller: [AMD/ATI] Barts XT [Radeon HD 6870]
05:12.0 SATA controller: [AMD/ATI] SB600 Non-Raid-5 SATA
05:14.4 PCI bridge: [AMD/ATI] SBx00 PCI to PCI Bridge
06:05.0 Ethernet controller: RTL-8100/8101L/8139
So 00:10.0 and 00:11.0 are bridges leading to buses 01 and 05-06.
Maybe 00:11.0 is the Downstream Port that leads to this magic "A-Link
II Express" thing?
But I don't think all those SB600 devices on bus 05 are PCIe devices.
It would certainly be unconventional to have a PCIe device (00:11.0)
at the upstream end of a link and conventional PCI devices (05:12.0,
05:13.0, 05:13.1, etc) at the downstream end, with no visible PCIe
port.
The usual thing would be that 00:11.0 would be a Root Port or a Switch
Downstream Port leading to a Link, and the other end of the Link would
terminate in either a Switch Upstream Port or an Upstream Port
embedded in an Endpoint.
We'll have to think about how to handle this. But the complete "lspci
-vv" output as root will have more useful information.
Bjorn
From: Christian Zigotzky <hidden> Date: 2017-11-29 23:39:55
On 29 November 2017 at 11:34PM, Bjorn Helgaas wrote:
On Wed, Nov 29, 2017 at 2:45 PM, Christian Zigotzky
quoted
Hi Bjorn,
Thank you for your answer. I have tried to boot the kernel 4.15 RC1 (built
without the patch above) with the boot argument "pci=pcie_scan_all" but
without any success.
Just for info:
The CPU is a PA Semi “PWRficient” PA6T-1682M. This device combines dual
1.8GHz PowerPC cores with a 2MB L2 cache, dual channel DDR2 memory
controllers and 24 SerDes
channels. The PowerPC cores adhere to the Power ISA v2.04, and support
64-bit extensions. They feature a double precision FPU and a VMX (AltiVec)
vector unit. They each have a 64kB I-cache and a 64kB D-cache.
The SerDes channels support PCI Express, XAUI and SGMII protocols. The
“ENVOI” I/O subsystem which drives them includes caching, offload and DMA
resources to maximise I/O
performance.
Nemo uses the AMD/ATI SB600 South Bridge to provide various integrated I/O
functions including SATA/PATA ports, USB and audio. The SB600 connects to
the CPU via a PCIe x4 link. This is termed an “A-link II Express” link by
ATI/AMD. The design team determined early in the development of Nemo that
the link’s behaviour as an endpoint does not comply fully with the PCI
Express specification. Specifically, it requires the root complex to use
non-zero device numbers in type 0 configuration cycles to enumerate all the
devices within the SB600. This is related to the PC architecture and is used
to allow SB600 devices appear on logical bus 0.
More information about the Nemo board:
https://en.wikipedia.org/wiki/AmigaOne_X1000http://www.a-eon.com/?page=x1000http://www.amigaos.net/hardware/35/amigaone-x1000
Please find attached the complete "lspci -vv" and dmesg output.
Thanks. Can you collect the "lspci -vv" output as root? The one you
attached wasn't as root and doesn't include the PCI capability
information, which we need so we can tell which devices appear as
conventional PCI and which as PCIe.
It would also be helpful if you could send plain-text email because
the linux-pci list discards fancy email
(http://vger.kernel.org/majordomo-info.html#taboo).
It looks like the SB600 devices actually appear on bus 05 (not 00),
right? I see these devices (among others):
00:10.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
00:11.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
01:00.0 VGA compatible controller: [AMD/ATI] Barts XT [Radeon HD 6870]
05:12.0 SATA controller: [AMD/ATI] SB600 Non-Raid-5 SATA
05:14.4 PCI bridge: [AMD/ATI] SBx00 PCI to PCI Bridge
06:05.0 Ethernet controller: RTL-8100/8101L/8139
So 00:10.0 and 00:11.0 are bridges leading to buses 01 and 05-06.
Maybe 00:11.0 is the Downstream Port that leads to this magic "A-Link
II Express" thing?
But I don't think all those SB600 devices on bus 05 are PCIe devices.
It would certainly be unconventional to have a PCIe device (00:11.0)
at the upstream end of a link and conventional PCI devices (05:12.0,
05:13.0, 05:13.1, etc) at the downstream end, with no visible PCIe
port.
The usual thing would be that 00:11.0 would be a Root Port or a Switch
Downstream Port leading to a Link, and the other end of the Link would
terminate in either a Switch Upstream Port or an Upstream Port
embedded in an Endpoint.
We'll have to think about how to handle this. But the complete "lspci
-vv" output as root will have more useful information.
Bjorn
Hi Bjorn,
Thanks for your reply. Please find attached the complete "lspci -vv" output as root.
Cheers,
Christian
On Thu, Nov 30, 2017 at 12:39:36AM +0100, Christian Zigotzky wrote:
On 29 November 2017 at 11:34PM, Bjorn Helgaas wrote:
quoted
On Wed, Nov 29, 2017 at 2:45 PM, Christian Zigotzky
quoted
Thank you for your answer. I have tried to boot the kernel 4.15
RC1 (built without the patch above) with the boot argument
"pci=pcie_scan_all" but without any success.
Just for info:
The CPU is a PA Semi “PWRficient” PA6T-1682M. This device
combines dual 1.8GHz PowerPC cores with a 2MB L2 cache, dual
channel DDR2 memory controllers and 24 SerDes channels. The
PowerPC cores adhere to the Power ISA v2.04, and support 64-bit
extensions. They feature a double precision FPU and a VMX
(AltiVec) vector unit. They each have a 64kB I-cache and a 64kB
D-cache. The SerDes channels support PCI Express, XAUI and SGMII
protocols. The “ENVOI” I/O subsystem which drives them includes
caching, offload and DMA resources to maximise I/O performance.
quoted
quoted
Nemo uses the AMD/ATI SB600 South Bridge to provide various
integrated I/O functions including SATA/PATA ports, USB and
audio. The SB600 connects to the CPU via a PCIe x4 link. This is
termed an “A-link II Express” link by ATI/AMD. The design team
determined early in the development of Nemo that the link’s
behaviour as an endpoint does not comply fully with the PCI
Express specification. Specifically, it requires the root complex
to use non-zero device numbers in type 0 configuration cycles to
enumerate all the devices within the SB600. This is related to
the PC architecture and is used to allow SB600 devices appear on
logical bus 0.
More information about the Nemo board:
https://en.wikipedia.org/wiki/AmigaOne_X1000http://www.a-eon.com/?page=x1000http://www.amigaos.net/hardware/35/amigaone-x1000
quoted
It looks like the SB600 devices actually appear on bus 05 (not 00),
right? I see these devices (among others):
00:10.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
00:11.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
01:00.0 VGA compatible controller: [AMD/ATI] Barts XT [Radeon HD 6870]
05:12.0 SATA controller: [AMD/ATI] SB600 Non-Raid-5 SATA
05:14.4 PCI bridge: [AMD/ATI] SBx00 PCI to PCI Bridge
06:05.0 Ethernet controller: RTL-8100/8101L/8139
So 00:10.0 and 00:11.0 are bridges leading to buses 01 and 05-06.
Maybe 00:11.0 is the Downstream Port that leads to this magic "A-Link
II Express" thing?
But I don't think all those SB600 devices on bus 05 are PCIe devices.
It would certainly be unconventional to have a PCIe device (00:11.0)
at the upstream end of a link and conventional PCI devices (05:12.0,
05:13.0, 05:13.1, etc) at the downstream end, with no visible PCIe
port.
The usual thing would be that 00:11.0 would be a Root Port or a Switch
Downstream Port leading to a Link, and the other end of the Link would
terminate in either a Switch Upstream Port or an Upstream Port
embedded in an Endpoint.
We'll have to think about how to handle this. But the complete "lspci
-vv" output as root will have more useful information.
Thanks for your reply. Please find attached the complete "lspci -vv"
output as root.
00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That
means there's a Link (presumably this A-Link II Express thing), and the
downstream end of the Link *should* be a PCIe Upstream Port on bus 05,
but no such device is visible. I suppose the SB600 does implement
some sort of PCIe Port there, but keeps it invisible to software, and
at the same time, contains an invisible bridge that connects the Link
to all the conventional PCI devices on bus 05.
When we scan bus 05, we do this:
pci_scan_child_bus_extend(bus=05)
for (devfn = 0; devfn < 0x100; devfn += 8)
pci_scan_slot(05, 00.0)
pci_scan_single_device
pci_scan_device(05, 00.0) # fails; no 05:00.0
pci_scan_slot(05, 01.0)
only_one_child(bus=05)
parent = 00:11.0
pci_pcie_type(00:11.0) == ROOT_PORT # returns true
Since only_one_child() sees that 00:11.0 is a Root Port, we give up
before we even get to the PCI_SCAN_ALL_PCIE_DEVS test.
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
commit 75eaf674066590e79b3e03d32488871fc881ab40
Author: Bjorn Helgaas [off-list ref]
Date: Thu Nov 30 15:22:39 2017 -0600
PCI: Make PCI_SCAN_ALL_PCIE_DEVS work for Root Ports as well as Downstream
Previously PCI_SCAN_ALL_PCIE_DEVS (set by quirks or the "pci=pcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports.
Simplify and restructure only_one_child() so PCI_SCAN_ALL_PCIE_DEVS means
we scan for all possible devices below Root Ports as well as Switch
Downstream Ports.
Signed-off-by: Bjorn Helgaas [off-list ref]
From: Christian Zigotzky <hidden> Date: 2017-12-01 22:08:57
On 30.11.2017 23:42, Bjorn Helgaas wrote:
00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That
means there's a Link (presumably this A-Link II Express thing), and the
downstream end of the Link *should* be a PCIe Upstream Port on bus 05,
but no such device is visible. I suppose the SB600 does implement
some sort of PCIe Port there, but keeps it invisible to software, and
at the same time, contains an invisible bridge that connects the Link
to all the conventional PCI devices on bus 05.
When we scan bus 05, we do this:
pci_scan_child_bus_extend(bus=05)
for (devfn = 0; devfn < 0x100; devfn += 8)
pci_scan_slot(05, 00.0)
pci_scan_single_device
pci_scan_device(05, 00.0) # fails; no 05:00.0
pci_scan_slot(05, 01.0)
only_one_child(bus=05)
parent = 00:11.0
pci_pcie_type(00:11.0) == ROOT_PORT # returns true
Since only_one_child() sees that 00:11.0 is a Root Port, we give up
before we even get to the PCI_SCAN_ALL_PCIE_DEVS test.
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Hi Bjorn,
I tested your new patch today. It boots with the boot argument "pci=pcie_scan_all". Well done! :-)
It doesn't boot without the boot argument "pci=pcie_scan_all".
Many thanks for your help.
Cheers,
Christian
On Fri, Dec 01, 2017 at 11:08:46PM +0100, Christian Zigotzky wrote:
On 30.11.2017 23:42, Bjorn Helgaas wrote:
quoted
00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That
means there's a Link (presumably this A-Link II Express thing), and the
downstream end of the Link *should* be a PCIe Upstream Port on bus 05,
but no such device is visible. I suppose the SB600 does implement
some sort of PCIe Port there, but keeps it invisible to software, and
at the same time, contains an invisible bridge that connects the Link
to all the conventional PCI devices on bus 05.
When we scan bus 05, we do this:
pci_scan_child_bus_extend(bus=05)
for (devfn = 0; devfn < 0x100; devfn += 8)
pci_scan_slot(05, 00.0)
pci_scan_single_device
pci_scan_device(05, 00.0) # fails; no 05:00.0
pci_scan_slot(05, 01.0)
only_one_child(bus=05)
parent = 00:11.0
pci_pcie_type(00:11.0) == ROOT_PORT # returns true
Since only_one_child() sees that 00:11.0 is a Root Port, we give up
before we even get to the PCI_SCAN_ALL_PCIE_DEVS test.
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Hi Bjorn,
I tested your new patch today. It boots with the boot argument
"pci=pcie_scan_all". Well done! :-)
It doesn't boot without the boot argument "pci=pcie_scan_all".
Thanks for testing that. I'll merge a similar patch for v4.16.
I don't think using "pci=pcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
Bjorn
From: Christian Zigotzky <hidden> Date: 2017-12-02 12:54:57
On 02 December 2017 at 00:27AM, Bjorn Helgaas wrote:
Thanks for testing that. I'll merge a similar patch for v4.16.
I don't think using "pci=pcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
Bjorn
Hi Bjorn,
Many thanks for your effort! I appreciate it very much. :-)
We can identify the Nemo board at the boot time. See dmesg output: [ 0.061592] NEMO SB600 IOB base e0000000
@linuxppc-dev
Any other ideas? Maybe the same as we can identify the other P.A. Semi boards (Electra, Chitra, and Athena).
@Olof
Maybe you know how we can identify the P.A. Semi Nemo board at the run-time.
@Darren
Do you have an idea?
Thanks to all for your help.
Cheers,
Christian
From: Olof Johansson <hidden> Date: 2017-12-02 23:01:17
On Sat, Dec 02, 2017 at 01:54:41PM +0100, Christian Zigotzky wrote:
On 02 December 2017 at 00:27AM, Bjorn Helgaas wrote:
quoted
Thanks for testing that. I'll merge a similar patch for v4.16.
I don't think using "pci=pcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
Bjorn
Hi Bjorn,
Many thanks for your effort! I appreciate it very much. :-)
We can identify the Nemo board at the boot time. See dmesg output: [
0.061592] NEMO SB600 IOB base e0000000
@linuxppc-dev
Any other ideas? Maybe the same as we can identify the other P.A. Semi
boards (Electra, Chitra, and Athena).
@Olof
Maybe you know how we can identify the P.A. Semi Nemo board at the run-time.
@Darren
Do you have an idea?
The below patch, together with Bjorn's, should do it. Christian, can you test
and report back?
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
From a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
Needed on Amiga X1000 with SB600.
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
From: Olof Johansson <hidden> Date: 2017-12-02 23:02:12
On Sat, Dec 2, 2017 at 3:00 PM, Olof Johansson [off-list ref] wrote:
quoted hunk
On Sat, Dec 02, 2017 at 01:54:41PM +0100, Christian Zigotzky wrote:
quoted
On 02 December 2017 at 00:27AM, Bjorn Helgaas wrote:
quoted
Thanks for testing that. I'll merge a similar patch for v4.16.
I don't think using "pci=pcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
Bjorn
Hi Bjorn,
Many thanks for your effort! I appreciate it very much. :-)
We can identify the Nemo board at the boot time. See dmesg output: [
0.061592] NEMO SB600 IOB base e0000000
@linuxppc-dev
Any other ideas? Maybe the same as we can identify the other P.A. Semi
boards (Electra, Chitra, and Athena).
@Olof
Maybe you know how we can identify the P.A. Semi Nemo board at the run-time.
@Darren
Do you have an idea?
The below patch, together with Bjorn's, should do it. Christian, can you test
and report back?
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
From a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
Needed on Amiga X1000 with SB600.
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
From: Christian Zigotzky <hidden> Date: 2017-12-03 09:43:27
On 3. Dec 2017, at 00:02, Olof Johansson [off-list ref] wrote:
=20
quoted
On Sat, Dec 2, 2017 at 3:00 PM, Olof Johansson [off-list ref] wrote:
=20
The below patch, together with Bjorn's, should do it. Christian, can you t=
est
quoted
and report back?
=20
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
=20
=20
=46rom a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
=20
Needed on Amiga X1000 with SB600.
=20
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
=20
From: Darren Stevens <hidden> Date: 2017-12-04 11:49:43
Hello Bjorn
Firstly sorry for not being=A0able to join in this discussion, I have been
moving house and only got my X1000 set up again yesterday..
On 30/11/2017, Bjorn Helgaas wrote:
I *think* something like the patch below should make this work if you
use the "pci=3Dpcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Actually the root ports on the Nemo's PA6T processor don't respond to the
SB600 unless we turn on a special 'relax pci-e' bit in one of its control
registers. We use a small out of tree init routine to do this, and there
would be the ideal place to put a call to
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
This patch fixes the last major hurdle to getting the X1000 fully supporte=
d in
the linux kernel, so thanks very much for that.
Regards
Darren
On 4. Dec 2017, at 12:40, Darren Stevens [off-list ref] wrote:
Hello Bjorn
Firstly sorry for not being able to join in this discussion, I have been
moving house and only got my X1000 set up again yesterday..
quoted
On 30/11/2017, Bjorn Helgaas wrote:
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Actually the root ports on the Nemo's PA6T processor don't respond to the
SB600 unless we turn on a special 'relax pci-e' bit in one of its control
registers. We use a small out of tree init routine to do this, and there
would be the ideal place to put a call to
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
This patch fixes the last major hurdle to getting the X1000 fully supported in
the linux kernel, so thanks very much for that.
Regards
Darren
From: Christian Zigotzky <hidden> Date: 2017-12-06 08:37:57
On 03 December 2017 10:43AM, Christian Zigotzky wrote:
On 3. Dec 2017, at 00:02, Olof Johansson [off-list ref] wrote:
quoted
quoted
On Sat, Dec 2, 2017 at 3:00 PM, Olof Johansson [off-list ref] wrote:
The below patch, together with Bjorn's, should do it. Christian, can you test
and report back?
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
From a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
Needed on Amiga X1000 with SB600.
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
Typo, should be ';', not ':'. I obviously didn't even try compiling this. :)
-Olof
Hi Olof,
Thanks a lot for your patch! I will test it on Wednesday.
Cheers,
Christian
Hi Olof,
I tested your patch today. Unfortunately the kernel 4.15-rc2 doesn't compile with your patch.
Error messages:
^~~~~~~~~
arch/powerpc/platforms/pasemi/pci.c: In function ‘pas_pci_init’:
arch/powerpc/platforms/pasemi/pci.c:298:2: error: implicit declaration of function ‘pci_set_flag’ [-Werror=implicit-function-declaration]
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS);
^~~~~~~~~~~~
cc1: some warnings being treated as errors
---
I figured out that we need 'pci_set_flags' instead of 'pci_set_flag'. I modified your patch and after that the kernel compiles. Please find attached the new patch.
Cheers,
Christian
From: Christian Zigotzky <hidden> Date: 2017-12-06 11:04:08
On 06 December 2017 at 09:37AM, Christian Zigotzky wrote:
On 03 December 2017 at 10:43AM, Christian Zigotzky wrote:
quoted
On 3. Dec 2017, at 00:02, Olof Johansson [off-list ref] wrote:
quoted
Typo, should be ';', not ':'. I obviously didn't even try compiling this. :)
-Olof
Hi Olof,
Thanks a lot for your patch! I will test it on Wednesday.
Cheers,
Christian
Hi Olof,
I tested your patch today. Unfortunately the kernel 4.15-rc2 doesn't compile with your patch.
Error messages:
^~~~~~~~~
arch/powerpc/platforms/pasemi/pci.c: In function ‘pas_pci_init’:
arch/powerpc/platforms/pasemi/pci.c:298:2: error: implicit declaration of function ‘pci_set_flag’ [-Werror=implicit-function-declaration]
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS);
^~~~~~~~~~~~
cc1: some warnings being treated as errors
---
I figured out that we need 'pci_set_flags' instead of 'pci_set_flag'. I modified your patch and after that the kernel compiles. Please find attached the new patch.
Cheers,
Christian
Hi Olof,
Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without any problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don’t need the additional boot argument 'pci=pcie_scan_all' anymore.
Is it possible to merge it via the powerpc tree?
Thanks,
Christian
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-12-06 12:44:45
Olof Johansson [off-list ref] writes:
On Sat, Dec 02, 2017 at 01:54:41PM +0100, Christian Zigotzky wrote:
quoted
On 02 December 2017 at 00:27AM, Bjorn Helgaas wrote:
quoted
=20
Thanks for testing that. I'll merge a similar patch for v4.16.
=20
I don't think using "pci=3Dpcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
=20
Bjorn
=20
Hi Bjorn,
=20
Many thanks for your effort! I appreciate it very much. :-)
=20
We can identify the Nemo board at the boot time. See dmesg output: [=C2=
=A0=C2=A0=C2=A0
quoted
0.061592] NEMO SB600 IOB base e0000000
=20
@linuxppc-dev
Any other ideas? Maybe the same as we can identify the other P.A. Semi
boards (Electra, Chitra, and Athena).
=20
@Olof
Maybe you know how we can identify the P.A. Semi Nemo board at the run-t=
ime.
quoted
=20
@Darren
Do you have an idea?
The below patch, together with Bjorn's, should do it. Christian, can you =
test
and report back?
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
My pasemi board had been powered off for a while and when I turned it
back on something popped, the power supply blew up and tripped a
breaker.
So I also can't test this, at least for now, until I get my "allowed to
use hardware" license back from my colleagues in the office.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-12-06 12:57:04
Christian Zigotzky [off-list ref] writes:
...
Hi Olof,
Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without any=
=20
problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don=E2=80=
=99t need=20
the additional boot argument 'pci=3Dpcie_scan_all' anymore.
Is it possible to merge it via the powerpc tree?
Yes.
It would be good to confirm that the change is harmless on other pasemi
boards. I'll try and get mine booted tomorrow, unless someone beats me
to it.
cheers
From: Olof Johansson <hidden> Date: 2017-12-06 15:54:03
On Wed, Dec 6, 2017 at 4:44 AM, Michael Ellerman [off-list ref] wrote:
Olof Johansson [off-list ref] writes:
quoted
On Sat, Dec 02, 2017 at 01:54:41PM +0100, Christian Zigotzky wrote:
quoted
On 02 December 2017 at 00:27AM, Bjorn Helgaas wrote:
quoted
Thanks for testing that. I'll merge a similar patch for v4.16.
I don't think using "pci=pcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
Bjorn
Hi Bjorn,
Many thanks for your effort! I appreciate it very much. :-)
We can identify the Nemo board at the boot time. See dmesg output: [
0.061592] NEMO SB600 IOB base e0000000
@linuxppc-dev
Any other ideas? Maybe the same as we can identify the other P.A. Semi
boards (Electra, Chitra, and Athena).
@Olof
Maybe you know how we can identify the P.A. Semi Nemo board at the run-time.
@Darren
Do you have an idea?
The below patch, together with Bjorn's, should do it. Christian, can you test
and report back?
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
My pasemi board had been powered off for a while and when I turned it
back on something popped, the power supply blew up and tripped a
breaker.
So I also can't test this, at least for now, until I get my "allowed to
use hardware" license back from my colleagues in the office.
Ouch. Sounds like it's the PSU not the board. Hopefully there was no
board damage, let me know if you need a replacement though and I'll
see what I can find.
-Olof
On Wed, Dec 06, 2017 at 11:57:03PM +1100, Michael Ellerman wrote:
Christian Zigotzky [off-list ref] writes:
...
quoted
Hi Olof,
Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without any
problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don’t need
the additional boot argument 'pci=pcie_scan_all' anymore.
Is it possible to merge it via the powerpc tree?
Yes.
It would be good to confirm that the change is harmless on other pasemi
boards. I'll try and get mine booted tomorrow, unless someone beats me
to it.
Theoretically, it should not do any harm since it only turns off an
enumeration optimization. Boot will be slightly slower but should
still work fine.
Darren's idea of doing it at the same time you tweak the SB600 "relax
pci-e" bit is ideal because then the two pieces are obviously
connected and it wouldn't affect any other systems at all.
Bjorn
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-12-08 11:57:42
Olof Johansson [off-list ref] writes:
On Wed, Dec 6, 2017 at 4:44 AM, Michael Ellerman [off-list ref] wrote:
quoted
Olof Johansson [off-list ref] writes:
quoted
The below patch, together with Bjorn's, should do it. Christian, can you test
and report back?
I'm guessing it won't do any harm to set this on non-X1000 platforms. My
test system is currently powered down so I can't check.
My pasemi board had been powered off for a while and when I turned it
back on something popped, the power supply blew up and tripped a
breaker.
So I also can't test this, at least for now, until I get my "allowed to
use hardware" license back from my colleagues in the office.
Ouch. Sounds like it's the PSU not the board. Hopefully there was no
board damage, let me know if you need a replacement though and I'll
see what I can find.
Thanks. Yeah the power supply is toast. One of the guys is going to see
if he can fix it.
Will try and get the board going, will let you know if it's dead too.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-12-08 11:59:41
Bjorn Helgaas [off-list ref] writes:
On Wed, Dec 06, 2017 at 11:57:03PM +1100, Michael Ellerman wrote:
quoted
Christian Zigotzky [off-list ref] writes:
...
quoted
Hi Olof,
Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without a=
ny=20
quoted
quoted
problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don=E2=
=80=99t need=20
quoted
quoted
the additional boot argument 'pci=3Dpcie_scan_all' anymore.
Is it possible to merge it via the powerpc tree?
=20
Yes.
=20
It would be good to confirm that the change is harmless on other pasemi
boards. I'll try and get mine booted tomorrow, unless someone beats me
to it.
Theoretically, it should not do any harm since it only turns off an
enumeration optimization. Boot will be slightly slower but should
still work fine.
Yep OK.
Darren's idea of doing it at the same time you tweak the SB600 "relax
pci-e" bit is ideal because then the two pieces are obviously
connected and it wouldn't affect any other systems at all.
Yes that would be ideal. That patch is currently out-of-tree I gather,
but I guess everyone who's using these machines must have that patch
anyway.
Darren what does that code look like? Can we get it upstream and close
the loop on this?
cheers
From: Christian Zigotzky <hidden> Date: 2017-12-09 18:03:51
On 08 December 2017 at 12:59PM, Michael Ellerman wrote:
quoted
Darren's idea of doing it at the same time you tweak the SB600 "relax
pci-e" bit is ideal because then the two pieces are obviously
connected and it wouldn't affect any other systems at all.
Yes that would be ideal. That patch is currently out-of-tree I gather,
but I guess everyone who's using these machines must have that patch
anyway.
Darren what does that code look like? Can we get it upstream and close
the loop on this?
cheers
Hi Michael,
Please find attached the code.
Thanks,
Christian
From: Christian Zigotzky <hidden> Date: 2017-12-15 08:06:19
On 09 December 2017 at 7:03PM, Christian Zigotzky wrote:
On 08 December 2017 at 12:59PM, Michael Ellerman wrote:
quoted
quoted
Darren's idea of doing it at the same time you tweak the SB600 "relax
pci-e" bit is ideal because then the two pieces are obviously
connected and it wouldn't affect any other systems at all.
Yes that would be ideal. That patch is currently out-of-tree I gather,
but I guess everyone who's using these machines must have that patch
anyway.
Darren what does that code look like? Can we get it upstream and close
the loop on this?
cheers
Hi Michael,
Please find attached the code.
Thanks,
Christian
Hi All,
I haven't received any response yet. Is this the correct patch you are looking for?
Thanks,
Christian
On Fri, Dec 15, 2017 at 09:04:51AM +0100, Christian Zigotzky wrote:
On 09 December 2017 at 7:03PM, Christian Zigotzky wrote:
quoted
On 08 December 2017 at 12:59PM, Michael Ellerman wrote:
quoted
quoted
Darren's idea of doing it at the same time you tweak the SB600 "relax
pci-e" bit is ideal because then the two pieces are obviously
connected and it wouldn't affect any other systems at all.
Yes that would be ideal. That patch is currently out-of-tree I gather,
but I guess everyone who's using these machines must have that patch
anyway.
Darren what does that code look like? Can we get it upstream and close
the loop on this?
cheers
Hi Michael,
Please find attached the code.
Thanks,
Christian
Hi All,
I haven't received any response yet. Is this the correct patch you
are looking for?
This is a powerpc patch that doesn't affect the PCI core, so I would
say this is Michael's bailiwick.
I guess you're only looking for a hint about whether this is the right
approach, because it's obviously fully baked yet (no changelog,
signed-off-by, etc, not a "safe for all powerpc" run-time solution,
not in Linux indentation style, etc).
It looks like the "pasemi,1682m-iob" DT property is required and
possibly sufficient to identify this system at run-time.
My advice is to finish that stuff up, post it to the powerpc
maintainers and the linuxppc-dev@lists.ozlabs.org list, and go from
there.
@@ -108,6 +109,69 @@ static int workaround_5945(struct pci_bureturn1;}+#ifdef CONFIG_PPC_PASEMI_NEMO+staticintsb600_bus=5;+staticvoid__iomem*iob_mapbase=NULL;++staticintpa_pxp_read_config(structpci_bus*bus,unsignedintdevfn,+intoffset,intlen,u32*val);++staticvoidsb600_set_flag(intbus)+{+structresourceres;+structdevice_node*dn;+structpci_bus*busp;+u32val;+interr;++if(sb600_bus==-1)+{+busp=pci_find_bus(0,0);+pa_pxp_read_config(busp,PCI_DEVFN(17,0),PCI_SECONDARY_BUS,1,&val);++sb600_bus=val;++printk(KERN_CRIT"NEMO SB600 on bus %d.\n",sb600_bus);+}++if(iob_mapbase==NULL)+{+dn=of_find_compatible_node(NULL,"isa","pasemi,1682m-iob");+if(!dn)+{+printk(KERN_CRIT"NEMO SB600 missing iob node\n");+return;+}++err=of_address_to_resource(dn,0,&res);+of_node_put(dn);++if(err)+{+printk(KERN_CRIT"NEMO SB600 missing resource\n");+return;+}++printk(KERN_CRIT"NEMO SB600 IOB base %08lx\n",res.start);++iob_mapbase=ioremap(res.start+0x100,0x94);+}++if(iob_mapbase!=NULL)+{+if(bus==sb600_bus)+{+out_le32(iob_mapbase+4,in_le32(iob_mapbase+4)|0x800);+}+else+{+out_le32(iob_mapbase+4,in_le32(iob_mapbase+4)&~0x800);+}+}+}+#endif++staticintpa_pxp_read_config(structpci_bus*bus,unsignedintdevfn,intoffset,intlen,u32*val){
@@ -126,6 +190,10 @@ static int pa_pxp_read_config(struct pciaddr=pa_pxp_cfg_addr(hose,bus->number,devfn,offset);+#ifdef CONFIG_PPC_PASEMI_NEMO+sb600_set_flag(bus->number);+#endif+/**Note:thecallerhasalreadycheckedthatoffsetis*suitablyalignedandthatlenis1,2or4.
@@ -210,6 +278,9 @@ static int __init pas_add_bridge(struct/* Interpret the "ranges" property */pci_process_bridge_OF_ranges(hose,dev,1);+/* Scan for an isa bridge. */+isa_bridge_find_early(hose);+return0;}
From: Christian Zigotzky <hidden> Date: 2017-12-16 07:19:24
On 04 December 2017 at 12:40PM, Darren Stevens wrote:
Hello Bjorn
Firstly sorry for not being able to join in this discussion, I have been
moving house and only got my X1000 set up again yesterday..
On 30/11/2017, Bjorn Helgaas wrote:
quoted
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Actually the root ports on the Nemo's PA6T processor don't respond to the
SB600 unless we turn on a special 'relax pci-e' bit in one of its control
registers. We use a small out of tree init routine to do this, and there
would be the ideal place to put a call to
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
This patch fixes the last major hurdle to getting the X1000 fully supported in
the linux kernel, so thanks very much for that.
Regards
Darren
On 15 December 2017 at 09:25PM, Bjorn Helgaas wrote:
On Fri, Dec 15, 2017 at 09:04:51AM +0100, Christian Zigotzky wrote:
quoted
On 09 December 2017 at 7:03PM, Christian Zigotzky wrote:
quoted
On 08 December 2017 at 12:59PM, Michael Ellerman wrote:
quoted
quoted
Darren's idea of doing it at the same time you tweak the SB600 "relax
pci-e" bit is ideal because then the two pieces are obviously
connected and it wouldn't affect any other systems at all.
Yes that would be ideal. That patch is currently out-of-tree I gather,
but I guess everyone who's using these machines must have that patch
anyway.
Darren what does that code look like? Can we get it upstream and close
the loop on this?
cheers
Hi Michael,
Please find attached the code.
Thanks,
Christian
Hi All,
I haven't received any response yet. Is this the correct patch you
are looking for?
This is a powerpc patch that doesn't affect the PCI core, so I would
say this is Michael's bailiwick.
I guess you're only looking for a hint about whether this is the right
approach, because it's obviously fully baked yet (no changelog,
signed-off-by, etc, not a "safe for all powerpc" run-time solution,
not in Linux indentation style, etc).
It looks like the "pasemi,1682m-iob" DT property is required and
possibly sufficient to identify this system at run-time.
My advice is to finish that stuff up, post it to the powerpc
maintainers and the linuxppc-dev@lists.ozlabs.org list, and go from
there.
Darren,
Where is this small out of tree init routine in our patch? I haven't found it yet. Please post this routine here. Please find attached our latest Nemo patch.
Thanks,
Christian
From: Christian Zigotzky <hidden> Date: 2017-12-22 09:58:30
Hi Bjorn,
Sorry I'm bothering you again. Is this small out of tree init routine in the Nemo patch? I haven't get an answer from Darren yet and I didn't found the small out of tree init routine in the Nemo patch. Please find attached the Nemo patch. Maybe you can find this small out of tree init routine.
What do you think of this following code?
if (sb600_bus == -1)
+ {
+ busp = pci_find_bus(0, 0);
+ pa_pxp_read_config(busp, PCI_DEVFN(17,0), PCI_SECONDARY_BUS, 1, &val);
+
+ sb600_bus = val;
+
+ printk(KERN_CRIT "NEMO SB600 on bus %d.\n",sb600_bus);
+ }
Thanks,
Christian
On 04 December 2017 at 12:40PM, Darren Stevens wrote:
Hello Bjorn
Firstly sorry for not being able to join in this discussion, I have been
moving house and only got my X1000 set up again yesterday..
On 30/11/2017, Bjorn Helgaas wrote:
quoted
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Actually the root ports on the Nemo's PA6T processor don't respond to the
SB600 unless we turn on a special 'relax pci-e' bit in one of its control
registers. We use a small out of tree init routine to do this, and there
would be the ideal place to put a call to
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
This patch fixes the last major hurdle to getting the X1000 fully supported in
the linux kernel, so thanks very much for that.
Regards
Darren
From: Christian Zigotzky <hidden> Date: 2017-12-22 10:22:26
I mean: I haven't gotten an answer from Darren yet. Sorry because of my English. I am still learning.
-- Christian
On 22 December 2017 at 10:57AM, Christian Zigotzky wrote:
Hi Bjorn,
Sorry I'm bothering you again. Is this small out of tree init routine in the Nemo patch? I haven't get an answer from Darren yet and I didn't found the small out of tree init routine in the Nemo patch. Please find attached the Nemo patch. Maybe you can find this small out of tree init routine.
What do you think of this following code?
if (sb600_bus == -1)
+ {
+ busp = pci_find_bus(0, 0);
+ pa_pxp_read_config(busp, PCI_DEVFN(17,0), PCI_SECONDARY_BUS, 1, &val);
+
+ sb600_bus = val;
+
+ printk(KERN_CRIT "NEMO SB600 on bus %d.\n",sb600_bus);
+ }
Thanks,
Christian
On 04 December 2017 at 12:40PM, Darren Stevens wrote:
quoted
Hello Bjorn
Firstly sorry for not being able to join in this discussion, I have been
moving house and only got my X1000 set up again yesterday..
On 30/11/2017, Bjorn Helgaas wrote:
quoted
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Actually the root ports on the Nemo's PA6T processor don't respond to the
SB600 unless we turn on a special 'relax pci-e' bit in one of its control
registers. We use a small out of tree init routine to do this, and there
would be the ideal place to put a call to
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
This patch fixes the last major hurdle to getting the X1000 fully supported in
the linux kernel, so thanks very much for that.
Regards
Darren
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-12-22 11:19:58
Christian Zigotzky [off-list ref] writes:
Hi Bjorn,
Sorry I'm bothering you again. Is this small out of tree init routine in=
=20
the Nemo patch? I haven't get an answer from Darren yet and I didn't=20
found the small out of tree init routine in the Nemo patch. Please find=20
attached the Nemo patch. Maybe you can find this small out of tree init=20
routine.
What do you think of this following code?
if (sb600_bus =3D=3D -1)
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 printk(KERN_CRIT "NEMO SB600 on bus %d.\n",sb600_bus);
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
I suspect Darren was referring to all of sb600_set_flag().
What we'd really like is to be able to do something like:
void __init pas_pci_init(void)
{
...
if (of_find_compatible_node(NULL, NULL, "nemo-something"))
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
But I don't know if there's anything in the NEMO device tree that we can
use to uniquely identify those machines? ie. the "nemo-something" string.
Can you attach the output of `lsprop /proc/device-tree` ?
cheers
From: Christian Zigotzky <hidden> Date: 2017-12-22 12:12:03
Hi Michael,
Thanks a lot for your reply! :-)
I have found two interesting lines in the device tree:
compatible "pasemi,nemo"
model "pasemi,nemo"
What do you think?
Please find attached the output of `lsprop /proc/device-tree`.
Thanks,
Christian
On 22.12.2017 12:19, Michael Ellerman wrote:
I suspect Darren was referring to all of sb600_set_flag().
What we'd really like is to be able to do something like:
void __init pas_pci_init(void)
{
...
if (of_find_compatible_node(NULL, NULL, "nemo-something"))
pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS).
But I don't know if there's anything in the NEMO device tree that we can
use to uniquely identify those machines? ie. the "nemo-something" string.
Can you attach the output of `lsprop /proc/device-tree` ?
cheers
From: Christian Zigotzky <hidden> Date: 2018-03-16 12:10:58
On 02 December 2017 at 00:27PM, Bjorn Helgaas wrote:
On Fri, Dec 01, 2017 at 11:08:46PM +0100, Christian Zigotzky wrote:
quoted
On 30.11.2017 23:42, Bjorn Helgaas wrote:
quoted
00:11.0 claims to be a PCIe Root Port leading to [bus 05-06]. That
means there's a Link (presumably this A-Link II Express thing), and the
downstream end of the Link *should* be a PCIe Upstream Port on bus 05,
but no such device is visible. I suppose the SB600 does implement
some sort of PCIe Port there, but keeps it invisible to software, and
at the same time, contains an invisible bridge that connects the Link
to all the conventional PCI devices on bus 05.
When we scan bus 05, we do this:
pci_scan_child_bus_extend(bus=05)
for (devfn = 0; devfn < 0x100; devfn += 8)
pci_scan_slot(05, 00.0)
pci_scan_single_device
pci_scan_device(05, 00.0) # fails; no 05:00.0
pci_scan_slot(05, 01.0)
only_one_child(bus=05)
parent = 00:11.0
pci_pcie_type(00:11.0) == ROOT_PORT # returns true
Since only_one_child() sees that 00:11.0 is a Root Port, we give up
before we even get to the PCI_SCAN_ALL_PCIE_DEVS test.
I *think* something like the patch below should make this work if you
use the "pci=pcie_scan_all" parameter. We have some x86 DMI quirks
that set PCI_SCAN_ALL_PCIE_DEVS automatically. I don't know how to do
something similar on powerpc, but maybe you do?
Hi Bjorn,
I tested your new patch today. It boots with the boot argument
"pci=pcie_scan_all". Well done! :-)
It doesn't boot without the boot argument "pci=pcie_scan_all".
Thanks for testing that. I'll merge a similar patch for v4.16.
I don't think using "pci=pcie_scan_all" is really an acceptable
long-term answer for you, though. Is there some way we can identify
at run-time whether we're on a Nemo system? If so, we can make this
happen automatically.
Bjorn
Hi Bjorn,
Hi All,
Olof Johansson has created a patch for us. With this patch, "pci=pcie_scan_all" executes automatically on P.A. Semi boards. We don't need to add 'pci=pcie_scan_all' to the
kernel boot arguments anymore. Could you please add Olof's patch to the official kernel source code?
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
Thanks,
Christian
From: Christian Zigotzky <hidden> Date: 2018-03-16 12:55:48
Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set by quirks or the "pci=pcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports. The problem is, that we have to add always the boot argument "pci=pcie_scan_all" for using Bjorn's improvements. Without the boot argument "pci=pcie_scan_all", the kernel doesn't boot on P.A. Semi boards with SB600 chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi’s PA6T-1682M System-on-a-Chip) because the kernel can't find any drives connected to the SB600 anymore. Olof Johansson has created a patch for executing "pci=pcie_scan_all" automatically on P.A. Semi boards. With his patch, we don't need to add 'pci=pcie_scan_all' to the kernel boot arguments anymore.
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote:
Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for
Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set by
quirks or the "pci=pcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports. The
problem is, that we have to add always the boot argument "pci=pcie_scan_all"
for using Bjorn's improvements. Without the boot argument
"pci=pcie_scan_all", the kernel doesn't boot on P.A. Semi boards with SB600
chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi’s
PA6T-1682M System-on-a-Chip) because the kernel can't find any drives
connected to the SB600 anymore. Olof Johansson has created a patch for
executing "pci=pcie_scan_all" automatically on P.A. Semi boards. With his
patch, we don't need to add 'pci=pcie_scan_all' to the kernel boot arguments
anymore.
From: Christian Zigotzky <hidden> Date: 2018-03-19 20:46:47
Hello Bjorn,
Thanks for your reply. Olof wrote this patch.
@Olof
Could you please sign off this patch?
Thanks,
Christian
On 19. Mar 2018, at 20:13, Bjorn Helgaas [off-list ref] wrote:
The patch looks fine, but I need a signed-off-by line before I can apply
it. See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/=
tree/Documentation/process/submitting-patches.rst
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pasemi/pci.c
b/arch/powerpc/platforms/pasemi/pci.c
index 5ff6108..ea54ed2 100644
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-03-19 22:32:17
Bjorn Helgaas [off-list ref] writes:
On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote:
quoted
Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for
Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set=
by
quoted
quirks or the "pci=3Dpcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports.=
The
quoted
problem is, that we have to add always the boot argument "pci=3Dpcie_sca=
n_all"
quoted
for using Bjorn's improvements. Without the boot argument
"pci=3Dpcie_scan_all", the kernel doesn't boot on P.A. Semi boards with =
SB600
quoted
chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi=E2=80=
=99s
quoted
PA6T-1682M System-on-a-Chip) because the kernel can't find any drives
connected to the SB600 anymore. Olof Johansson has created a patch for
executing "pci=3Dpcie_scan_all" automatically on P.A. Semi boards. With =
his
quoted
patch, we don't need to add 'pci=3Dpcie_scan_all' to the kernel boot arg=
it/tree/Documentation/process/submitting-patches.rst
I'm happy to take it, I've been meaning to check if Olof sent a SOB in
his original mail but haven't got to it.
...
Yes, he did, see below.
So I'll merge that, I'll add a Tested-by for you Christian.
Christian please don't remove any of the tags when submitting other
peoples' patches in future.
cheers
From a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
Needed on Amiga X1000 with SB600.
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
From: Christian Zigotzky <hidden> Date: 2018-03-21 06:44:50
Michael,
Thanks for the hint because of removing tags and thanks a lot for adding the patch to the official source code. This patch helps us a lot.
Have a nice day!
Christian
On 19 March 2018 at 11:32PM, Michael Ellerman wrote:
quoted hunk
I'm happy to take it, I've been meaning to check if Olof sent a SOB in
his original mail but haven't got to it.
...
Yes, he did, see below.
So I'll merge that, I'll add a Tested-by for you Christian.
Christian please don't remove any of the tags when submitting other
peoples' patches in future.
cheers
quoted
From a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
Needed on Amiga X1000 with SB600.
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
From: Christian Zigotzky <hidden> Date: 2018-04-16 04:30:13
Hi Michael,
Many thanks for your help. Did you merge Olof=E2=80=98s patch? I still have t=
o patch the 4.17 source code.
Thanks,
Christian
Sent from my iPhone
On 19. Mar 2018, at 23:32, Michael Ellerman [off-list ref] wrote:
=20
Bjorn Helgaas [off-list ref] writes:
=20
quoted
quoted
On Fri, Mar 16, 2018 at 01:55:36PM +0100, Christian Zigotzky wrote:
Bjorn Helgaas created a patch for making PCI_SCAN_ALL_PCIE_DEVS work for=
quoted
quoted
Root Ports as well as Downstream. Previously PCI_SCAN_ALL_PCIE_DEVS (set=
by
quoted
quoted
quirks or the "pci=3Dpcie_scan_all"
kernel parameter) only affected Switch Downstream Ports, not Root Ports.=
The
quoted
quoted
problem is, that we have to add always the boot argument "pci=3Dpcie_sca=
n_all"
quoted
quoted
for using Bjorn's improvements. Without the boot argument
"pci=3Dpcie_scan_all", the kernel doesn't boot on P.A. Semi boards with S=
B600
quoted
quoted
chipset (SB600 chipset is connected via PCIe x4 to the P.A. Semi=E2=80=99=
s
quoted
quoted
PA6T-1682M System-on-a-Chip) because the kernel can't find any drives
connected to the SB600 anymore. Olof Johansson has created a patch for
executing "pci=3Dpcie_scan_all" automatically on P.A. Semi boards. With h=
is
quoted
quoted
patch, we don't need to add 'pci=3Dpcie_scan_all' to the kernel boot arg=
=20
I'm happy to take it, I've been meaning to check if Olof sent a SOB in
his original mail but haven't got to it.
=20
...
=20
Yes, he did, see below.
=20
So I'll merge that, I'll add a Tested-by for you Christian.
=20
Christian please don't remove any of the tags when submitting other
peoples' patches in future.
=20
cheers
=20
=20
=46rom a3b390277627b0342c8ccfc16e58679e0d8abdde Mon Sep 17 00:00:00 2001
From: Olof Johansson <redacted>
Date: Sat, 2 Dec 2017 14:56:36 -0800
Subject: [PATCH] powerpc/pasemi: set PCI_SCAN_ALL_PCI_DEVS
=20
Needed on Amiga X1000 with SB600.
=20
Reported-by: Christian Zigotzky <redacted>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Olof Johansson <redacted>
---
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)
=20
From: Michael Ellerman <hidden> Date: 2018-06-04 14:10:28
On Wed, 2017-12-06 at 11:03:52 UTC, Christian Zigotzky wrote:
quoted hunk
On 06 December 2017 at 09:37AM, Christian Zigotzky wrote:
> On 03 December 2017 at 10:43AM, Christian Zigotzky wrote:
> >
> > On 3. Dec 2017, at 00:02, Olof Johansson [off-list ref] wrote:
> >>
> >> Typo, should be ';', not ':'. I obviously didn't even try
compiling this. :)
> >>
> >>
> >> -Olof
> >
> > Hi Olof,
> >
> > Thanks a lot for your patch! I will test it on Wednesday.
> >
> > Cheers,
> > Christian
>
>
> Hi Olof,
>
> I tested your patch today. Unfortunately the kernel 4.15-rc2 doesn't
compile with your patch.
>
> Error messages:
>
>���������������������������������������������� ^~~~~~~~~
> arch/powerpc/platforms/pasemi/pci.c: In function ���pas_pci_init���:
> arch/powerpc/platforms/pasemi/pci.c:298:2: error: implicit
declaration of function ���pci_set_flag���
[-Werror=implicit-function-declaration]
>���� pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS);
>���� ^~~~~~~~~~~~
> cc1: some warnings being treated as errors
>
> ---
>
> I figured out that we need 'pci_set_flags' instead of 'pci_set_flag'.
I modified your patch and after that the kernel compiles. Please find
attached the new patch.
>
> Cheers,
> Christian
Hi Olof,
Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without any
problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don���t need
the additional boot argument 'pci=pcie_scan_all' anymore.
Is it possible to merge it via the powerpc tree?
Thanks,
Christian
arch/powerpc/platforms/pasemi/pci.c | 2 ++
1 file changed, 2 insertions(+)