[-cc Oza, bounced] On Mon, Sep 30, 2019 at 11:46:18PM +0200, Marek Vasut wrote: > On 9/30/19 11:40 PM, Bjorn Helgaas wrote: > > This would follow the convention for subject lines: > > > > PCI: OF: Add of_pci_get_dma_ranges() for inbound DMA restrictions > > > > On Fri, Aug 09, 2019 at 07:34:48PM +0200 wrote: > >> From: Oza Pawandeep > >> > >> The patch exports interface to PCIe RC drivers so that, > >> Drivers can get their inbound memory configuration. > > > > IIUC this interface (of_pci_get_dma_ranges()) is not used directly by > > *drivers*; it is used by of_bus_pci_get_dma_ranges() in the next > > patch, and it's called by the driver core via this path: > > > > really_probe > > pci_dma_configure # pci_bus_type.dma_configure > > of_dma_configure > > of_dma_get_range > > bus->get_dma_ranges > > of_bus_pci_get_dma_ranges # of_busses[0].get_dma_ranges > > of_pci_get_dma_ranges > > > >> It provides basis for IOVA reservations for inbound memory > >> holes, if RC is not capable of addressing all the host memory, > >> Specifically when IOMMU is enabled and on ARMv8 where 64bit IOVA > >> could be allocated. > >> > >> It handles multiple inbound windows, and returns resources, > >> and is left to the caller, how it wants to use them. > > > > This should say exactly what the problem is, maybe even with a link to > > a problem report. I assume it is something like "RC <X> cannot > > address all of host memory, and if we happen to allocate a buffer > > that's not addressable, DMA to the buffer fails". It'd be nice to > > know what the failure looks like (SERR# asserted, panic, reboot, etc). > > [...] > > While it's good that someone finally looked at these patches, these were > since superseded by the following series: > https://patchwork.ozlabs.org/cover/1168166/
Good to know, thanks :)
