Lines Matching +full:dma +full:- +full:window

1 /* SPDX-License-Identifier: GPL-2.0 */
35  * This is needed because of the behaviour of PCIe-to-PCI bridges. The PHB uses
37  * (and PE) that initiated a DMA. In legacy PCI individual memory read/write
38  * requests aren't tagged with the RID. To work around this the PCIe-to-PCI
41  * PCIe-to-X bridges have a similar issue even though PCI-X requests also have
42  * a RID in the transaction header. The PCIe-to-X bridge is permitted to "take
43  * ownership" of a transaction by a PCI-X device when forwarding it to the PCIe
50 /* Indicates operations are frozen for a PE: MMIO in PESTA & DMA in PESTB. */
78 	/* "Base" iommu table, ie, 4K TCEs, 32-bit DMA */
81 	/* 64-bit TCE bypass region */
86 	 * Used to track whether we've done DMA setup for this PE or not. We
88 	 * non-bridge device to the PE.
93 	 * and -1 if not supported. (It's actually identical to the
137 		/* 32-bit MMIO window */
142 		/* 64-bit MMIO window */
191 	 * allocation code sometimes decides to put a 64-bit prefetchable  in pnv_pci_is_m64()
192 	 * BAR in the 32-bit window, so we have to compare the addresses.  in pnv_pci_is_m64()
196 	return (r->start >= phb->ioda.m64_base &&  in pnv_pci_is_m64()
197 		r->start < (phb->ioda.m64_base + phb->ioda.m64_size));  in pnv_pci_is_m64()
218  * For SR-IOV we want to put each VF's MMIO resource in to a separate PE.
219  * This requires a bit of acrobatics with the MMIO -> PE configuration
229 	/* Did we map the VF BAR with single-PE IODA BARs? */
241 	 * SR-IOV BARs for this device.
246 	 * If we map the SR-IOV BARs with a segmented window then
247 	 * parts of that window will be "claimed" by other PEs.
250 	 * of the window that is used by other (non VF) PEs.
257 	return pdev->dev.archdata.iov_data;  in pnv_iov_get()
299 /* pci-ioda-tce.c */
331 	struct pci_controller *hose = bus->sysdata;  in pci_bus_to_pnvhb()
334 		return hose->private_data;  in pci_bus_to_pnvhb()