kernel/linux.git/drivers/pci, branch v4.4.171

PCI: altera: Move retrain from fixup to altera_pcie_host_init()

2019-01-16T21:16:11+00:00

commit ce4f1c7ad490aa7129bde5632d6e53943f8a866c upstream. Previously we used a PCI early fixup to initiate a link retrain on Altera devices. But Altera PCIe IP can be configured as either a Root Port or an Endpoint, and they might have same vendor ID, so the fixup would be run for both. We only want to initiate a link retrain for Altera Root Port devices, not for Endpoints, so move the link retrain functionality from the fixup to altera_pcie_host_init(). [bhelgaas: changelog] Signed-off-by: Ley Foon Tan Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: altera: Rework config accessors for use without a struct pci_bus

2019-01-16T21:16:11+00:00

commit 31fc0ad47e2e0b8417616aa0f1ddcc67edf1e109 upstream. Rework configs accessors so a future patch can use them in _probe() with struct altera_pcie instead of struct pci_bus. Signed-off-by: Ley Foon Tan Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: altera: Poll for link training status after retraining the link

2019-01-16T21:16:11+00:00

commit 411dc32d8810e0a204c799ce5c97cb56990de1cb upstream. Poll for link training status is cleared before poll for link up status. This can help to get the reliable link up status, especially when PCIe is in Gen 3 speed. Signed-off-by: Ley Foon Tan Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: altera: Poll for link up status after retraining the link

2019-01-16T21:16:11+00:00

commit 3a928e98a833e1a470a60d2fedf3c55502185fb7 upstream. Some PCIe devices take a long time to reach link up state after retrain. Poll for link up status after retraining the link. This is to make sure the link is up before we access configuration space. [bhelgaas: changelog] Signed-off-by: Ley Foon Tan Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: altera: Check link status before retrain link

2019-01-16T21:16:11+00:00

commit c622032ebc538cb3869c312ae3ad235a99da84b6 upstream. Check the link status before retraining. If the link is not up, don't bother trying to retrain it. [bhelgaas: split code move to separate patch, changelog] Signed-off-by: Ley Foon Tan Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: altera: Reorder read/write functions

2019-01-16T21:16:11+00:00

commit f8be11ae3d2c9a1338da37ff91ff4c65922d21be upstream. Move cra_writel(), cra_readl(), and altera_pcie_link_is_up() so a future patch can use them in altera_pcie_retrain(). No functional change intended. Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: altera: Fix altera_pcie_link_is_up()

2019-01-16T21:16:11+00:00

commit eff31f4002c4e25b9b8c39d0a3a551c6c64c77e8 upstream. Originally altera_pcie_link_is_up() decided the link was up if any of the low four bits of the LTSSM register were set. But the link is only up if the LTSSM state is L0, so check for that exact value. [bhelgaas: changelog] Signed-off-by: Ley Foon Tan Signed-off-by: Bjorn Helgaas Cc: Claudius Heine Signed-off-by: Greg Kroah-Hartman

PCI: Add Device IDs for Intel GPU "spurious interrupt" quirk

2018-11-21T08:27:34+00:00

commit d0c9606b31a21028fb5b753c8ad79626292accfd upstream. Add Device IDs to the Intel GPU "spurious interrupt" quirk table. For these devices, unplugging the VGA cable and plugging it in again causes spurious interrupts from the IGD. Linux eventually disables the interrupt, but of course that disables any other devices sharing the interrupt. The theory is that this is a VGA BIOS defect: it should have disabled the IGD interrupt but failed to do so. See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs") and 7c82126a94e6 ("PCI: Add new ID for Intel GPU "spurious interrupt" quirk") for some history. [bhelgaas: See link below for discussion about how to fix this more generically instead of adding device IDs for every new Intel GPU. I hope this is the last patch to add device IDs.] Link: https://lore.kernel.org/linux-pci/1537974841-29928-1-git-send-email-bmeng.cn@gmail.com Signed-off-by: Bin Meng [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v3.4+ Signed-off-by: Greg Kroah-Hartman

PCI: Reprogram bridge prefetch registers on resume

2018-10-13T07:11:32+00:00

commit 083874549fdfefa629dfa752785e20427dde1511 upstream. On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of NVIDIA GPUs and Intel SoCs. After resume, nouveau logs many errors such as: fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM] Similarly, the NVIDIA proprietary driver also fails after resume (black screen, 100% CPU usage in Xorg process). We shipped a sample to NVIDIA for diagnosis, and their response indicated that it's a problem with the parent PCI bridge (on the Intel SoC), not the GPU. Runtime suspend/resume works fine, only S3 suspend is affected. We found a workaround: on resume, rewrite the Intel PCI bridge 'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32). In the cases that I checked, this register has value 0 and we just have to rewrite that value. Linux already saves and restores PCI config space during suspend/resume, but this register was being skipped because upon resume, it already has value 0 (the correct, pre-suspend value). Intel appear to have previously acknowledged this behaviour and the requirement to rewrite this register: https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 Based on that, rewrite the prefetch register values even when that appears unnecessary. We have confirmed this solution on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN). Additionally, this solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on ASUS X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop that we had not yet patched. I suspect it will also fix the issue that was worked around in commit 7c53a722459c ("r8169: don't use MSI-X on RTL8168g"). Thomas Martitz reports that this change also solves an issue where the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3 suspend/resume. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069 Signed-off-by: Daniel Drake Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Reviewed-By: Peter Wu CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

PCI: mvebu: Fix I/O space end address calculation

2018-09-15T07:40:39+00:00

[ Upstream commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 ] pcie->realio.end should be the address of last byte of the area, therefore using resource_size() of another resource is not correct, we must substract 1 to get the address of the last byte. Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout") Signed-off-by: Thomas Petazzoni Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman