summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/kernel/eeh_event.c
diff options
context:
space:
mode:
authorAlexey Kardashevskiy2018-02-13 06:51:35 +0100
committerMichael Ellerman2018-03-27 14:44:57 +0200
commitd41ce7b1bcc3e1d02cc9da3b83c0fe355fcb68e0 (patch)
tree3d890acabc22b746ad7a806fc89fb9fe66a0729e /arch/powerpc/kernel/eeh_event.c
parentpowerpc/mm: Fix typo in comments (diff)
downloadkernel-qcow2-linux-d41ce7b1bcc3e1d02cc9da3b83c0fe355fcb68e0.tar.gz
kernel-qcow2-linux-d41ce7b1bcc3e1d02cc9da3b83c0fe355fcb68e0.tar.xz
kernel-qcow2-linux-d41ce7b1bcc3e1d02cc9da3b83c0fe355fcb68e0.zip
powerpc/powernv/npu: Do not try invalidating 32bit table when 64bit table is enabled
GPUs and the corresponding NVLink bridges get different PEs as they have separate translation validation entries (TVEs). We put these PEs to the same IOMMU group so they cannot be passed through separately. So the iommu_table_group_ops::set_window/unset_window for GPUs do set tables to the NPU PEs as well which means that iommu_table's list of attached PEs (iommu_table_group_link) has both GPU and NPU PEs linked. This list is used for TCE cache invalidation. The problem is that NPU PE has just a single TVE and can be programmed to point to 32bit or 64bit windows while GPU PE has two (as any other PCI device). So we end up having an 32bit iommu_table struct linked to both PEs even though only the 64bit TCE table cache can be invalidated on NPU. And a relatively recent skiboot detects this and prints errors. This changes GPU's iommu_table_group_ops::set_window/unset_window to make sure that NPU PE is only linked to the table actually used by the hardware. If there are two tables used by an IOMMU group, the NPU PE will use the last programmed one which with the current use scenarios is expected to be a 64bit one. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'arch/powerpc/kernel/eeh_event.c')
0 files changed, 0 insertions, 0 deletions