Hi @Anonymous, I noticed before we have reported PCIE issue: https://bugs.96boards.org/show_bug.cgi?id=595, and I see seems you reported this issue, so are you are aware this issue?
Can you confirm if use legacy booting images PCIE can be recognized and after swtiching to UEFI/ARM-TF then PCIE cannot work anymore?
Hi Leo-yan,
Below bug is with kernel 4.9 -
https://bugs.96boards.org/show_bug.cgi?id=595
But now I am using kernel 4.4 -
Linux localhost 4.4.82-g8892910-dirty #24 SMP PREEMPT
With kernel 4.4 and legacy boot images PCIE device is working fine.
With kernel 4.4 and UEFI/ARM TF, PCIE device is not recognized.
With UEFI+ARM TF and kernel 4.9 PCIE works? If so I can try it.
Thanks
Hi Leo-yan,
I tried with kernel 4.9 and UEFI+ARM TF images also, pcie device is not recognized.
Logs :
[ 3.870742] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 3.876684] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 3.883595] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 3.890404] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
[ 3.928650] OF: PCI: host bridge /soc/pcie@f4000000 ranges:
[ 3.934310] OF: PCI: MEM 0xf6000000…0xf7ffffff → 0x00000000
[ 4.941391] Kirin-pcie f4000000.pcie: Link Fail
[ 4.946218] Kirin-pcie f4000000.pcie: PCI host bridge to bus 0000:00
[ 4.952653] pci_bus 0000:00: root bus resource [bus 00-01]
[ 4.958204] pci_bus 0000:00: root bus resource [mem 0xf6000000-0xf7ffffff] (bus address [0x00000000-0x01ffffff])
[ 4.968606] pci 0000:00:00.0: [19e5:3660] type 01 class 0x060400
[ 4.974738] pci 0000:00:00.0: reg 0x10: [mem 0xf6000000-0xf6ffffff]
[ 4.981260] pci 0000:00:00.0: supports D1 D2
[ 4.985590] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[ 4.992182] pci 0000:00:00.0: BAR 0: assigned [mem 0xf6000000-0xf6ffffff]
[ 4.999132] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 5.004688] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[ 5.011738] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
Thanks
Hi Leo-yan,
please let me know if you found fix for the above issue.
Thanks
Hi @Anonymous, I have filed the bug for PCI device issue: https://bugs.96boards.org/show_bug.cgi?id=653
This issue is likely there have some missed setting in ARM-TF/UEFI booting images, but these setting is exist in Hisilicon legacy booting images. Unfortunately, Hisilicon legacy booting images are not open source code, so need go back to check with Hisilicon for this.
You could monitor bug 653 if there have any update for this.
Flashing wrong images.
Hi,
With the latest UEFI bootloader http://builds.96boards.org/snapshots/reference-platform/components/uefi-staging/latest/ lspci is working and with some WARs mentioned, rtcwake is going to suspend and waking up after specified time (busybox rtcwake -d /dev/rtc1 -m mem -s 5)
iff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 6e3c143…ed2dbfe 100644
— a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -379,6 +379,8 @@ static int pl061_suspend(struct device *dev)
struct pl061_gpio *chip = dev_get_drvdata(dev);
int offset;
return 0;
chip->csave_regs.gpio_data = 0;
chip->csave_regs.gpio_dir = readb(chip->base + GPIODIR);
chip->csave_regs.gpio_is = readb(chip->base + GPIOIS);
@@ -400,6 +402,8 @@ static int pl061_resume(struct device *dev)
struct pl061_gpio *chip = dev_get_drvdata(dev);
int offset;
return 0;
for (offset = 0; offset < PL061_GPIO_NR; offset++) {
if (chip->csave_regs.gpio_dir & (BIT(offset)))
pl061_direction_output(&chip->gc, offset,
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index e630d4f…07e7c70 100644
— a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -270,6 +270,8 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
adap->dev.of_node = pdev->dev.of_node;
dev->pm_runtime_disabled = true;
if (dev->pm_runtime_disabled) {
pm_runtime_forbid(&pdev->dev);
} else {
We are working on PCIe drivers and we are interested in bringing the PCIe link down to L2, looks like, even though suspend/resume works, the PCIe link is not going to L2 (PCIe root complex is not going to suspend)
Please help.
Thanks,
Shankar
I have fixed the issues.
Now GPIOs can be suspended. And wakeup from RTC is working.
See topic:
[Does Hikey960 support susped-to-mem with Linux 4.9 kernel? - #7 by sreenad]
Hi Sreenad,
Is your patch committed to 4.9 kernel?
Can you please point me to your patch?
Also, are pcie devices .suspend getting called? i.e PCIe link going to L2?
Thanks,
Shankar
I could fix only GPIO18 and GPIO19 suspend-resume hang issue.
I didnt face any problem in PCIe driver.
Let me know upto which stage u could reach during suspend.
Regards,
Sreenad.
Hi Sreenad,
We will try with your patch.
But could you please confirm if Hikey960 PCIe root complex supports L2 (link state 2) or not?
Any code change needed to add RC L2 support?
We would use suspend/resume only if PCIe L2 is supported.
Thanks,
SJ
You would be able to reach upto GPIO suspend, after USB and i2c adapter suspend.
If you are facing problem in that, disable USB pm callbacks (so USB will be powered even after suspend) and for i2c, either disable runtime suspend for it. Or have a state check before going for suspend. Because in my code, runtime pm and suspend pm callbacks where same and did not had a current state check.
At some version, synopsis had fixed the issue in its i2c drivers.
If u are again facing problem in it, let me know.
Regarding PCIe, I don’t have much knowledge in that area to confirm your query.
Also, currently I don’t have 960 board with me, as I am working in different things.
Regards,
Sreenad.
