The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Signed-off-by: Jeremy Linton jeremy.linton@arm.com --- config-arm64 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/config-arm64 b/config-arm64 index 77dde02..2db4e9a 100644 --- a/config-arm64 +++ b/config-arm64 @@ -110,6 +110,9 @@ CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
+# ARM Juno +CONFIG_PCI_HOST_GENERIC=y + # APM Xgene CONFIG_POWER_RESET_XGENE=y CONFIG_COMMON_CLK_XGENE=y
I'll move it to arm-generic so we don't dupe it between ARMv7 and aarch64 but over all ACK and thanks.
Peter
On Thu, May 12, 2016 at 5:24 PM, Jeremy Linton jeremy.linton@arm.com wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Signed-off-by: Jeremy Linton jeremy.linton@arm.com
config-arm64 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/config-arm64 b/config-arm64 index 77dde02..2db4e9a 100644 --- a/config-arm64 +++ b/config-arm64 @@ -110,6 +110,9 @@ CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
+# ARM Juno +CONFIG_PCI_HOST_GENERIC=y
# APM Xgene CONFIG_POWER_RESET_XGENE=y CONFIG_COMMON_CLK_XGENE=y -- 2.5.5 _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
On Thu, May 12, 2016 at 5:24 PM, Jeremy Linton jeremy.linton@arm.com wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide) http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Regards, Peter
Signed-off-by: Jeremy Linton jeremy.linton@arm.com
config-arm64 | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/config-arm64 b/config-arm64 index 77dde02..2db4e9a 100644 --- a/config-arm64 +++ b/config-arm64 @@ -110,6 +110,9 @@ CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=m CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
+# ARM Juno +CONFIG_PCI_HOST_GENERIC=y
# APM Xgene CONFIG_POWER_RESET_XGENE=y CONFIG_COMMON_CLK_XGENE=y -- 2.5.5 _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org
On 05/12/2016 12:10 PM, Peter Robinson wrote:
On Thu, May 12, 2016 at 5:24 PM, Jeremy Linton jeremy.linton@arm.com wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide) http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles.
FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that).
Other than that, it seems to be mostly working (given the PCIe tweak).
Its also somewhat functional in ACPI mode if you don't mind not having any PCIe...
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide)
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles.
Excellent, really glad to get confirmation it's looking reasonable.
FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that).
1) dmi_match oops we've seen for a long time, it doesn't seem to cause issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence 2) Is SMSC the standard usb attached device or something else? 3) grub issue (actually shim issue) is now fixed and a fix should be landing today or tomorrow. I'll update bugs and send to the arm list [1] once it's landed
Other than that, it seems to be mostly working (given the PCIe tweak).
Excellent news.
Its also somewhat functional in ACPI mode if you don't mind not having any PCIe...
Yes, know and following this one [2] closely, when I get a few cycles I'm going to do a test kernel with appropriate patches for those interested in testing, I'll send that to the arm list too.
Peter
[1] https://lists.fedoraproject.org/admin/lists/arm.lists.fedoraproject.org/ [2] http://www.spinics.net/lists/linux-pci/msg51058.html
On 05/12/2016 02:59 PM, Peter Robinson wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide)
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles.
Excellent, really glad to get confirmation it's looking reasonable.
FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that).
- dmi_match oops we've seen for a long time, it doesn't seem to cause
issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence
This machine has DMI tables, the problem is that the fedora specific watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to dmi_check_system before the smbios initcall has set up the tables (AFAIK).
- Is SMSC the standard usb attached device or something else?
Juno has two Ethernet controllers, a memory mapped 10/100 smc911x that is described by DT/ACPI, and a PCIe attached 1Gb marvell sky2.
Out of the box, nothing is attached to the usb/ehci controller.
On Thu, May 12, 2016 at 4:42 PM, Jeremy Linton jlinton@redhat.com wrote:
On 05/12/2016 02:59 PM, Peter Robinson wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide)
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles.
Excellent, really glad to get confirmation it's looking reasonable.
FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that).
- dmi_match oops we've seen for a long time, it doesn't seem to cause
issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence
This machine has DMI tables, the problem is that the fedora specific watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to dmi_check_system before the smbios initcall has set up the tables (AFAIK).
When is that initcall done on your platform? lockup_detector_init is called in a kthread started by the rest_init function. All of that is called after acpi_subsystem_init, sfi_init_late, efi_late_init, and efi_free_boot_services.
Also, the dmi code protects itself behind the dmi_initialized variable, so if dmi_check_system is called before dmi_scan_machine is called then nothing bad should happen. On x86, dmi_scan_machine is called from setup_arch, which is well before any of the above functions are called.
josh
On 05/13/2016 12:41 PM, Josh Boyer wrote:
On Thu, May 12, 2016 at 4:42 PM, Jeremy Linton jlinton@redhat.com wrote:
On 05/12/2016 02:59 PM, Peter Robinson wrote:
The ARM Juno development platform's PCIe is supported by the generic PCI host driver. Enable it so that PCIe attached peripherals work.
Pushed as (F-24 and rawhide)
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/commit/?h=f24&id=decd...
Let me know if there's other branches you'd like it on, also let me know if there's other improvements that can be made for Juno, we've not had anyone to test so what we have is a bit of a guess so any feedback for Juno support would be useful.
Thanks those two branches should be sufficient. I have a few other tweaks to post now that I seem to have cleared some internal hurtles.
Excellent, really glad to get confirmation it's looking reasonable.
FYI: There is a dmi_match oops on boot, and the SMSC's phy state change isn't consistently detected, resulting in unreliable link detection. Plus, there is likely a grub EFI issue (there are a couple bugs floating around about that).
- dmi_match oops we've seen for a long time, it doesn't seem to cause
issues but I think it's because most devices don't actually have dmi tables (or what ever they're called) so should likely be taught to behave on absence
This machine has DMI tables, the problem is that the fedora specific watchdog-Disable-watchdog-on-virtual-machines.patch is making calls to dmi_check_system before the smbios initcall has set up the tables (AFAIK).
When is that initcall done on your platform? lockup_detector_init is called in a kthread started by the rest_init function. All of that is called after acpi_subsystem_init, sfi_init_late, efi_late_init, and efi_free_boot_services.
Also, the dmi code protects itself behind the dmi_initialized variable, so if dmi_check_system is called before dmi_scan_machine is called then nothing bad should happen. On x86, dmi_scan_machine is called from setup_arch, which is well before any of the above functions are called.
Its the WARN(!dmi_initialized, KERN_ERR "dmi check: not initialized yet.\n"); in dmi_matches that is firing.
That is because, arm64_dmi_init is a core_initcall() and ends up being called after the watchdog/SMP setup, same on IA64 the only other platform with a dmi_scan_machine() call. A large part of this is because it should run after arm_enable_runtime_services, which is an early_initcall itself.
I moved the arm64_dmi_init() call into arm_enable_runtime_services() and removed the core_initcall(arm64_dmi_init) and that solves the problem. Of course that will likely cause a build failure on 32-bit ARM without some kind of stubbed out call.
kernel@lists.fedoraproject.org