* [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips @ 2020-05-19 20:33 Jim Quinlan via iommu 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-19 20:33 UTC (permalink / raw) To: james.quinlan, Nicolas Saenz Julienne Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Ulf Hansson, Heikki Krogerus, Saravana Kannan, Rob Herring, Greg Kroah-Hartman, Rafael J. Wysocki, Suzuki K Poulose, Julien Grall, open list, open list:LIBATA SUBSYSTEM Serial and Parallel ATA drivers, open list:DMA MAPPING HELPERS, Stefano Stabellini, open list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE, moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE, open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, Dan Williams, Robin Murphy, moderated list:ARM PORT This patchset expands the usefulness of the Broadcom Settop Box PCIe controller by building upon the PCIe driver used currently by the Raspbery Pi. Other forms of this patchset were submitted by me years ago and not accepted; the major sticking point was the code required for the DMA remapping needed for the PCIe driver to work [1]. There have been many changes to the DMA and OF subsystems since that time, making a cleaner and less intrusive patchset possible. This patchset implements a generalization of "dev->dma_pfn_offset", except that instead of a single scalar offset it provides for multiple offsets via a function which depends upon the "dma-ranges" property of the PCIe host controller. This is required for proper functionality of the BrcmSTB PCIe controller and possibly some other devices. [1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/ Jim Quinlan (15): PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB ahci_brcm: fix use of BCM7216 reset controller dt-bindings: PCI: Add bindings for more Brcmstb chips PCI: brcmstb: Add compatibily of other chips PCI: brcmstb: Add suspend and resume pm_ops PCI: brcmstb: Asserting PERST is different for 7278 PCI: brcmstb: Add control of rescal reset of: Include a dev param in of_dma_get_range() device core: Add ability to handle multiple dma offsets dma-direct: Invoke dma offset func if needed arm: dma-mapping: Invoke dma offset func if needed PCI: brcmstb: Set internal memory viewport sizes PCI: brcmstb: Accommodate MSI for older chips PCI: brcmstb: Set bus max burst side by chip type PCI: brcmstb: add compatilbe chips to match list .../bindings/pci/brcm,stb-pcie.yaml | 40 +- arch/arm/include/asm/dma-mapping.h | 17 +- drivers/ata/ahci_brcm.c | 14 +- drivers/of/address.c | 54 ++- drivers/of/device.c | 2 +- drivers/of/of_private.h | 8 +- drivers/pci/controller/Kconfig | 4 +- drivers/pci/controller/pcie-brcmstb.c | 403 +++++++++++++++--- include/linux/device.h | 9 +- include/linux/dma-direct.h | 16 + include/linux/dma-mapping.h | 44 ++ kernel/dma/Kconfig | 12 + 12 files changed, 542 insertions(+), 81 deletions(-) -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-19 20:33 [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan via iommu @ 2020-05-19 20:34 ` Jim Quinlan via iommu 2020-05-20 5:43 ` Greg Kroah-Hartman ` (2 more replies) 2020-05-19 20:34 ` [PATCH 10/15] dma-direct: Invoke dma offset func if needed Jim Quinlan via iommu 2020-05-20 16:15 ` [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Bjorn Helgaas 2 siblings, 3 replies; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-19 20:34 UTC (permalink / raw) To: james.quinlan, Nicolas Saenz Julienne Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Frank Rowand, Suzuki K Poulose, Greg Kroah-Hartman, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig The device variable 'dma_pfn_offset' is used to do a single linear map between cpu addrs and dma addrs. The variable 'dma_map' is added to struct device to point to an array of multiple offsets which is required for some devices. Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> --- drivers/of/address.c | 50 ++++++++++++++++++++++++++++++++++--- include/linux/device.h | 9 ++++++- include/linux/dma-mapping.h | 44 ++++++++++++++++++++++++++++++++ kernel/dma/Kconfig | 12 +++++++++ 4 files changed, 111 insertions(+), 4 deletions(-) diff --git a/drivers/of/address.c b/drivers/of/address.c index 96d8cfb14a60..7dfff618af6a 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -947,6 +947,8 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr, struct of_range_parser parser; struct of_range range; u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0; + bool dma_multi_pfn_offset = false; + int num_ranges = 0; while (node) { ranges = of_get_property(node, "dma-ranges", &len); @@ -977,10 +979,18 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr, pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n", range.bus_addr, range.cpu_addr, range.size); + num_ranges++; if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset) { - pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node); - /* Don't error out as we'd break some existing DTs */ - continue; + dma_multi_pfn_offset = true; + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) { + pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node); + /* + * Don't error out as we'd break some + * existing DTs that are using configs + * w/o CONFIG_DMA_PFN_OFFSET_MAP set. + */ + continue; + } } dma_offset = range.cpu_addr - range.bus_addr; @@ -991,6 +1001,40 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr, dma_end = range.bus_addr + range.size; } +#ifdef CONFIG_DMA_PFN_OFFSET_MAP + if (dma_multi_pfn_offset) { + size_t r_size = (num_ranges + 1) + * sizeof(struct dma_pfn_offset_region); + struct dma_pfn_offset_region *r; + + if (!dev) + return -EINVAL; + + dma_offset = 0; + r = devm_kcalloc(dev, 1, r_size, GFP_KERNEL); + if (!r) + return -ENOMEM; + dev->dma_offset_map = (const void *) r; + of_dma_range_parser_init(&parser, node); + + /* + * Record all info for DMA ranges array. We could + * just use the of_range struct, but if we did that it + * would require more calculations for phys_to_dma and + * dma_to_phys conversions. + */ + for_each_of_range(&parser, &range) { + r->cpu_beg = range.cpu_addr; + r->cpu_end = r->cpu_beg + range.size; + r->dma_beg = range.bus_addr; + r->dma_end = r->dma_beg + range.size; + r->pfn_offset = PFN_DOWN(range.cpu_addr) + - PFN_DOWN(range.bus_addr); + r++; + } + } +#endif + if (dma_start >= dma_end) { ret = -EINVAL; pr_debug("Invalid DMA ranges configuration on node(%pOF)\n", diff --git a/include/linux/device.h b/include/linux/device.h index ac8e37cd716a..6cd916860b5f 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -493,6 +493,8 @@ struct dev_links_info { * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller * DMA limit than the device itself supports. * @dma_pfn_offset: offset of DMA memory range relatively of RAM + * @dma_map: Like dma_pfn_offset but used when there are multiple + * pfn offsets for multiple dma-ranges. * @dma_parms: A low level driver may set these to teach IOMMU code about * segment limitations. * @dma_pools: Dma pools (if dma'ble device). @@ -578,7 +580,12 @@ struct device { allocations such descriptors. */ u64 bus_dma_limit; /* upstream dma constraint */ unsigned long dma_pfn_offset; - +#ifdef CONFIG_DMA_PFN_OFFSET_MAP + const void *dma_offset_map; /* Like dma_pfn_offset, but for + * the unlikely case of multiple + * offsets. If non-null, dma_pfn_offset + * will be 0. */ +#endif struct device_dma_parameters *dma_parms; struct list_head dma_pools; /* dma pools (if dma'ble) */ diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 330ad58fbf4d..288d8089faf7 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -256,6 +256,38 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev, size_t dma_direct_max_mapping_size(struct device *dev); #ifdef CONFIG_HAS_DMA +#ifdef CONFIG_DMA_PFN_OFFSET_MAP +struct dma_pfn_offset_region { + phys_addr_t cpu_beg; + phys_addr_t cpu_end; + dma_addr_t dma_beg; + dma_addr_t dma_end; + unsigned long pfn_offset; +}; + +static inline unsigned long dma_pfn_offset_frm_dma_addr(const void *arr, + dma_addr_t dma_addr) +{ + const struct dma_pfn_offset_region *m; + + for (m = arr; m->cpu_end; m++) + if (dma_addr >= m->dma_beg && dma_addr < m->dma_end) + return m->pfn_offset; + return 0; +} + +static inline unsigned long dma_pfn_offset_frm_phys_addr(const void *arr, + phys_addr_t paddr) +{ + const struct dma_pfn_offset_region *m; + + for (m = arr; m->cpu_end; m++) + if (paddr >= m->cpu_beg && paddr < m->cpu_end) + return m->pfn_offset; + return 0; +} +#endif /* CONFIG_DMA_PFN_OFFSET_MAP */ + #include <asm/dma-mapping.h> static inline const struct dma_map_ops *get_dma_ops(struct device *dev) @@ -575,6 +607,18 @@ static inline unsigned long dma_get_merge_boundary(struct device *dev) { return 0; } +#ifdef CONFIG_DMA_PFN_OFFSET_MAP +static inline unsigned long dma_pfn_offset_frm_dma_addr(const void *arr, + dma_addr_t dma_addr) +{ + return 0; +} +static inline unsigned long dma_pfn_offset_frm_phys_addr(const void *arr, + phys_addr_t paddr) +{ + return 0; +} +#endif /* CONFIG_DMA_PFN_OFFSET_MAP */ #endif /* CONFIG_HAS_DMA */ static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr, diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index 4c103a24e380..b4c3de521bf9 100644 --- a/kernel/dma/Kconfig +++ b/kernel/dma/Kconfig @@ -195,3 +195,15 @@ config DMA_API_DEBUG_SG is technically out-of-spec. If unsure, say N. + +config DMA_PFN_OFFSET_MAP + bool "Uses a DMA range map to calculate PFN offset" + default n + help + Some devices have a dma-range that gets converted to + a dev->dma_pfn_offset value. This option is for the + atypical case of there being multiple dma-ranges requiring + multiple pfn offsets, which are selected from when + converting to phys to dma and vice versa. + + If unsure, say N. -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu @ 2020-05-20 5:43 ` Greg Kroah-Hartman 2020-05-20 13:50 ` Jim Quinlan via iommu 2020-05-20 11:28 ` Nicolas Saenz Julienne 2020-05-20 17:42 ` Christoph Hellwig 2 siblings, 1 reply; 14+ messages in thread From: Greg Kroah-Hartman @ 2020-05-20 5:43 UTC (permalink / raw) To: Jim Quinlan Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig, Nicolas Saenz Julienne On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote: > diff --git a/include/linux/device.h b/include/linux/device.h > index ac8e37cd716a..6cd916860b5f 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -493,6 +493,8 @@ struct dev_links_info { > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller > * DMA limit than the device itself supports. > * @dma_pfn_offset: offset of DMA memory range relatively of RAM > + * @dma_map: Like dma_pfn_offset but used when there are multiple > + * pfn offsets for multiple dma-ranges. > * @dma_parms: A low level driver may set these to teach IOMMU code about > * segment limitations. > * @dma_pools: Dma pools (if dma'ble device). > @@ -578,7 +580,12 @@ struct device { > allocations such descriptors. */ > u64 bus_dma_limit; /* upstream dma constraint */ > unsigned long dma_pfn_offset; > - > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP > + const void *dma_offset_map; /* Like dma_pfn_offset, but for > + * the unlikely case of multiple > + * offsets. If non-null, dma_pfn_offset > + * will be 0. */ > +#endif > struct device_dma_parameters *dma_parms; > > struct list_head dma_pools; /* dma pools (if dma'ble) */ I'll defer to Christoph here, but I thought we were trying to get rid of stuff like this from struct device, not add new things to it for dma apis. And why is it a void *? thanks, greg k-h _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 5:43 ` Greg Kroah-Hartman @ 2020-05-20 13:50 ` Jim Quinlan via iommu 2020-05-20 14:03 ` Greg Kroah-Hartman 0 siblings, 1 reply; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-20 13:50 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig, Nicolas Saenz Julienne On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote: > > diff --git a/include/linux/device.h b/include/linux/device.h > > index ac8e37cd716a..6cd916860b5f 100644 > > --- a/include/linux/device.h > > +++ b/include/linux/device.h > > @@ -493,6 +493,8 @@ struct dev_links_info { > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller > > * DMA limit than the device itself supports. > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM > > + * @dma_map: Like dma_pfn_offset but used when there are multiple > > + * pfn offsets for multiple dma-ranges. > > * @dma_parms: A low level driver may set these to teach IOMMU code about > > * segment limitations. > > * @dma_pools: Dma pools (if dma'ble device). > > @@ -578,7 +580,12 @@ struct device { > > allocations such descriptors. */ > > u64 bus_dma_limit; /* upstream dma constraint */ > > unsigned long dma_pfn_offset; > > - > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP > > + const void *dma_offset_map; /* Like dma_pfn_offset, but for > > + * the unlikely case of multiple > > + * offsets. If non-null, dma_pfn_offset > > + * will be 0. */ > > +#endif > > struct device_dma_parameters *dma_parms; > > > > struct list_head dma_pools; /* dma pools (if dma'ble) */ > > I'll defer to Christoph here, but I thought we were trying to get rid of > stuff like this from struct device, not add new things to it for dma Hi Greg, I wasn't aware of this policy. I put it in 'struct device' because just like the existing dma_pfn_offset; it seemed to be the only way to pull this off. I'll certainly follow any ideas on alternative strategies from Christoph et al. > apis. And why is it a void *? Just wanted to minimize the number of lines I've added to device.h, no other reason. Thanks, Jim > > thanks, > > greg k-h _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 13:50 ` Jim Quinlan via iommu @ 2020-05-20 14:03 ` Greg Kroah-Hartman 2020-05-20 14:08 ` Jim Quinlan via iommu 0 siblings, 1 reply; 14+ messages in thread From: Greg Kroah-Hartman @ 2020-05-20 14:03 UTC (permalink / raw) To: Jim Quinlan Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig, Nicolas Saenz Julienne On Wed, May 20, 2020 at 09:50:36AM -0400, Jim Quinlan wrote: > On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > > > On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote: > > > diff --git a/include/linux/device.h b/include/linux/device.h > > > index ac8e37cd716a..6cd916860b5f 100644 > > > --- a/include/linux/device.h > > > +++ b/include/linux/device.h > > > @@ -493,6 +493,8 @@ struct dev_links_info { > > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller > > > * DMA limit than the device itself supports. > > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM > > > + * @dma_map: Like dma_pfn_offset but used when there are multiple > > > + * pfn offsets for multiple dma-ranges. > > > * @dma_parms: A low level driver may set these to teach IOMMU code about > > > * segment limitations. > > > * @dma_pools: Dma pools (if dma'ble device). > > > @@ -578,7 +580,12 @@ struct device { > > > allocations such descriptors. */ > > > u64 bus_dma_limit; /* upstream dma constraint */ > > > unsigned long dma_pfn_offset; > > > - > > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP > > > + const void *dma_offset_map; /* Like dma_pfn_offset, but for > > > + * the unlikely case of multiple > > > + * offsets. If non-null, dma_pfn_offset > > > + * will be 0. */ > > > +#endif > > > struct device_dma_parameters *dma_parms; > > > > > > struct list_head dma_pools; /* dma pools (if dma'ble) */ > > > > I'll defer to Christoph here, but I thought we were trying to get rid of > > stuff like this from struct device, not add new things to it for dma > Hi Greg, > > I wasn't aware of this policy. I put it in 'struct device' because > just like the existing dma_pfn_offset; it seemed to be the only way to > pull this off. I'll certainly follow any ideas on alternative > strategies from Christoph et al. > > > apis. And why is it a void *? > Just wanted to minimize the number of lines I've added to device.h, no > other reason. How would using a real type make this more lines? Never use a void * unless you have to, we want the compiler to check our errors for us :) thanks, greg k-h _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 14:03 ` Greg Kroah-Hartman @ 2020-05-20 14:08 ` Jim Quinlan via iommu 0 siblings, 0 replies; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-20 14:08 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig, Nicolas Saenz Julienne [-- Attachment #1.1: Type: text/plain, Size: 2748 bytes --] On Wed, May 20, 2020 at 10:03 AM Greg Kroah-Hartman < gregkh@linuxfoundation.org> wrote: > On Wed, May 20, 2020 at 09:50:36AM -0400, Jim Quinlan wrote: > > On Wed, May 20, 2020 at 1:43 AM Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > > > > > > On Tue, May 19, 2020 at 04:34:07PM -0400, Jim Quinlan wrote: > > > > diff --git a/include/linux/device.h b/include/linux/device.h > > > > index ac8e37cd716a..6cd916860b5f 100644 > > > > --- a/include/linux/device.h > > > > +++ b/include/linux/device.h > > > > @@ -493,6 +493,8 @@ struct dev_links_info { > > > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes > a smaller > > > > * DMA limit than the device itself supports. > > > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM > > > > + * @dma_map: Like dma_pfn_offset but used when there are multiple > > > > + * pfn offsets for multiple dma-ranges. > > > > * @dma_parms: A low level driver may set these to teach > IOMMU code about > > > > * segment limitations. > > > > * @dma_pools: Dma pools (if dma'ble device). > > > > @@ -578,7 +580,12 @@ struct device { > > > > allocations such > descriptors. */ > > > > u64 bus_dma_limit; /* upstream dma constraint */ > > > > unsigned long dma_pfn_offset; > > > > - > > > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP > > > > + const void *dma_offset_map; /* Like dma_pfn_offset, but for > > > > + * the unlikely case of > multiple > > > > + * offsets. If non-null, > dma_pfn_offset > > > > + * will be 0. */ > > > > +#endif > > > > struct device_dma_parameters *dma_parms; > > > > > > > > struct list_head dma_pools; /* dma pools (if > dma'ble) */ > > > > > > I'll defer to Christoph here, but I thought we were trying to get rid > of > > > stuff like this from struct device, not add new things to it for dma > > Hi Greg, > > > > I wasn't aware of this policy. I put it in 'struct device' because > > just like the existing dma_pfn_offset; it seemed to be the only way to > > pull this off. I'll certainly follow any ideas on alternative > > strategies from Christoph et al. > > > > > apis. And why is it a void *? > > Just wanted to minimize the number of lines I've added to device.h, no > > other reason. > > How would using a real type make this more lines? Never use a void * > unless you have to, we want the compiler to check our errors for us :) > Got it; I did not need to define the struct in device.h. Will fix if this code makes it past v1 :-) Jim > thanks, > > greg k-h > [-- Attachment #1.2: Type: text/html, Size: 3989 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu 2020-05-20 5:43 ` Greg Kroah-Hartman @ 2020-05-20 11:28 ` Nicolas Saenz Julienne 2020-05-22 14:31 ` Jim Quinlan via iommu 2020-05-20 17:42 ` Christoph Hellwig 2 siblings, 1 reply; 14+ messages in thread From: Nicolas Saenz Julienne @ 2020-05-20 11:28 UTC (permalink / raw) To: Jim Quinlan Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Frank Rowand, Suzuki K Poulose, Greg Kroah-Hartman, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig [-- Attachment #1.1: Type: text/plain, Size: 2480 bytes --] Hi Jim, thanks for having a go at this! My two cents. On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote: > The device variable 'dma_pfn_offset' is used to do a single > linear map between cpu addrs and dma addrs. The variable > 'dma_map' is added to struct device to point to an array > of multiple offsets which is required for some devices. > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> > --- [...] > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -493,6 +493,8 @@ struct dev_links_info { > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller > * DMA limit than the device itself supports. > * @dma_pfn_offset: offset of DMA memory range relatively of RAM > + * @dma_map: Like dma_pfn_offset but used when there are multiple > + * pfn offsets for multiple dma-ranges. > * @dma_parms: A low level driver may set these to teach IOMMU code > about > * segment limitations. > * @dma_pools: Dma pools (if dma'ble device). > @@ -578,7 +580,12 @@ struct device { > allocations such descriptors. */ > u64 bus_dma_limit; /* upstream dma constraint */ > unsigned long dma_pfn_offset; > - > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP > + const void *dma_offset_map; /* Like dma_pfn_offset, but for > + * the unlikely case of multiple > + * offsets. If non-null, dma_pfn_offset > + * will be 0. */ I get a bad feeling about separating the DMA offset handling into two distinct variables. Albeit generally frowned upon, there is a fair amount of trickery around dev->dma_pfn_offset all over the kernel. usb_alloc_dev() comes to mind for example. And this obviously doesn't play well with it. I feel a potential solution to multiple DMA ranges should completely integrate with the current device DMA handling code, without special cases, on top of that, be transparent to the user. In more concrete terms, I'd repackage dev->bus_dma_limit and dev->dma_pfn_offset into a list/array of DMA range structures and adapt/create the relevant getter/setter functions so as for DMA users not to have to worry about the specifics of a device's DMA constraints. For example, instead of editing dev->dma_pfn_offset, you'd be passing a DMA range structure to the device core, and let it take the relevant decisions on how to handle it internally (overwrite, add a new entry, merge them, etc...). Easier said than done. :) Regards, Nicolas [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 156 bytes --] _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 11:28 ` Nicolas Saenz Julienne @ 2020-05-22 14:31 ` Jim Quinlan via iommu 0 siblings, 0 replies; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-22 14:31 UTC (permalink / raw) To: Nicolas Saenz Julienne Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Frank Rowand, Suzuki K Poulose, Greg Kroah-Hartman, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Dan Williams, Robin Murphy, Christoph Hellwig Hi Nicolas, On Wed, May 20, 2020 at 7:28 AM Nicolas Saenz Julienne <nsaenzjulienne@suse.de> wrote: > > Hi Jim, > thanks for having a go at this! My two cents. > > On Tue, 2020-05-19 at 16:34 -0400, Jim Quinlan wrote: > > The device variable 'dma_pfn_offset' is used to do a single > > linear map between cpu addrs and dma addrs. The variable > > 'dma_map' is added to struct device to point to an array > > of multiple offsets which is required for some devices. > > > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> > > --- > > [...] > > > --- a/include/linux/device.h > > +++ b/include/linux/device.h > > @@ -493,6 +493,8 @@ struct dev_links_info { > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller > > * DMA limit than the device itself supports. > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM > > + * @dma_map: Like dma_pfn_offset but used when there are multiple > > + * pfn offsets for multiple dma-ranges. > > * @dma_parms: A low level driver may set these to teach IOMMU code > > about > > * segment limitations. > > * @dma_pools: Dma pools (if dma'ble device). > > @@ -578,7 +580,12 @@ struct device { > > allocations such descriptors. */ > > u64 bus_dma_limit; /* upstream dma constraint */ > > unsigned long dma_pfn_offset; > > - > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP > > + const void *dma_offset_map; /* Like dma_pfn_offset, but for > > + * the unlikely case of multiple > > + * offsets. If non-null, dma_pfn_offset > > + * will be 0. */ > > I get a bad feeling about separating the DMA offset handling into two distinct > variables. Albeit generally frowned upon, there is a fair amount of trickery > around dev->dma_pfn_offset all over the kernel. usb_alloc_dev() comes to mind > for example. And this obviously doesn't play well with it. The trickery should only be present when CONFIG_DMA_PFN_OFFSET_MAP=y**. Otherwise it does no harm. Also, I feel that if dev-dma_pfn_offset is valid then so is dev->dma_pfn_offset_map -- they both use the same mechanism in the same places. I am merely extending something that has been in Linux for a long time.. Further, I could have had dma_pfn_offset_map subsume dma_pfn_offset but I wanted to leave it alone since folks would complain that it would go from an addition to an if-clause and an inline function. But if I did go that way there would only be one mechanism that would cover both cases. > I feel a potential > solution to multiple DMA ranges should completely integrate with the current > device DMA handling code, without special cases, on top of that, be transparent > to the user. Having dma_pfn_offset_map subsume dma_pfn_offset would integrate the current code too. And I am not sure what you mean by being "transparent to the user" -- the writer of the PCIe endpoint driver is going to do some DMA calls and they have no idea if this mechanism is in play or not. > > In more concrete terms, I'd repackage dev->bus_dma_limit and > dev->dma_pfn_offset into a list/array of DMA range structures This is sort of what I am doing except I defined my own structure. Using the of_range structure would require one to do the same extra calculations over and over for a DMA call; this is why I defined my structure that has all of the needed precomputed variables. > and adapt/create > the relevant getter/setter functions so as for DMA users not to have to worry > about the specifics of a device's DMA constraints. I'm not sure I understand where these getter/setter functions would exist or what they would do. > editing dev->dma_pfn_offset, you'd be passing a DMA range structure to the > device core, and let it take the relevant decisions on how to handle it How and where would the device core operate for these getter/setters? In how many places in the code? The way I see it, any solution has to adjust the value when doing dma2phys and phys2dma conversions, and the most efficient place to do that is in the two DMA header files (the second one is for ARM). > internally (overwrite, add a new entry, merge them, etc...). I'm concerned that this would be overkill; I am just trying to get a driver upstream for some baroque PCIe RC HW I'm not sure if we should set up something elaborate when the demand is not there. I'll be posting a v2. ChrisophH has sent me some personal feedback which I am incorporating; so feel free to discuss your ideas with him as well because I really want consensus on any large changes in direction. Thanks, Jim ** CONFIG_DMA_OF_PFN_OFFSET_MAP=y only occurs when building for ARCH_BRCMSTB. However, ARCH_BRCMSTB is set by the ARM64 defconfig and the ARM multi_v7_defconfig, so it would be activated for those defconfigs. This may(a) get us kicked out of those defconfigs or (b) we may have to keep DMA_OF_PFN_OFFSET_MAP off in those defconfigs and only turn it on solely for Broadcom STB Linux. > > Easier said than done. :) > > Regards, > Nicolas > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu 2020-05-20 5:43 ` Greg Kroah-Hartman 2020-05-20 11:28 ` Nicolas Saenz Julienne @ 2020-05-20 17:42 ` Christoph Hellwig 2020-05-20 18:26 ` Jim Quinlan via iommu 2 siblings, 1 reply; 14+ messages in thread From: Christoph Hellwig @ 2020-05-20 17:42 UTC (permalink / raw) To: Jim Quinlan Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Greg Kroah-Hartman, Dan Williams, Robin Murphy, Christoph Hellwig, Nicolas Saenz Julienne If you don't Cc me on the whole series I have absolutely no way to review it. Don't ever do these stupid partial Ccs as they cause nothing but pain. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 17:42 ` Christoph Hellwig @ 2020-05-20 18:26 ` Jim Quinlan via iommu 2020-05-20 22:36 ` Dan Williams 0 siblings, 1 reply; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-20 18:26 UTC (permalink / raw) To: Christoph Hellwig Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Greg Kroah-Hartman, Dan Williams, Robin Murphy, Nicolas Saenz Julienne Sorry, I meant to put you on the to-list for all patches. The last time I sent out this many patches using a collective cc-list for all patches I was told to reduce my cc-list. Jim On Wed, May 20, 2020 at 1:42 PM Christoph Hellwig <hch@lst.de> wrote: > > If you don't Cc me on the whole series I have absolutely no way to > review it. Don't ever do these stupid partial Ccs as they cause nothing > but pain. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 18:26 ` Jim Quinlan via iommu @ 2020-05-20 22:36 ` Dan Williams 2020-05-21 8:19 ` Christoph Hellwig 0 siblings, 1 reply; 14+ messages in thread From: Dan Williams @ 2020-05-20 22:36 UTC (permalink / raw) To: Jim Quinlan Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Frank Rowand, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Greg Kroah-Hartman, Robin Murphy, Christoph Hellwig, Nicolas Saenz Julienne On Wed, May 20, 2020 at 11:27 AM Jim Quinlan <james.quinlan@broadcom.com> wrote: > > Sorry, I meant to put you on the to-list for all patches. The last > time I sent out this many patches using a collective cc-list for all > patches I was told to reduce my cc-list. You'd be forgiven. There are some developers that are ok to go read the thread on something like lore if they are cc'd only a subset and some that require the whole thread copied to them. Perhaps we need an entry in MAINTAINERS that makes this preference discoverable? To date I have been manually keeping track of those who want full threads and those that would prefer to just be cc'd on the cover letter and the one patch that directly affects their maintenance area. Certainly blindly cc'ing everyone recommended by scripts/get_maintainers.pl is overkill, but finding that subset is a bit of an art. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets 2020-05-20 22:36 ` Dan Williams @ 2020-05-21 8:19 ` Christoph Hellwig 0 siblings, 0 replies; 14+ messages in thread From: Christoph Hellwig @ 2020-05-21 8:19 UTC (permalink / raw) To: Dan Williams Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Heikki Krogerus, Saravana Kannan, Suzuki K Poulose, Robin Murphy, Rafael J. Wysocki, open list, open list:DMA MAPPING HELPERS, Rob Herring, Jim Quinlan, Greg Kroah-Hartman, Frank Rowand, Christoph Hellwig, Nicolas Saenz Julienne On Wed, May 20, 2020 at 03:36:16PM -0700, Dan Williams wrote: > Certainly blindly cc'ing everyone recommended by > scripts/get_maintainers.pl is overkill, but finding that subset is a > bit of an art. Yes. But I'd rather be not Cced and just find the complete thread on a list. But all the lists I'm on and have managed to read through yesterday didn't have the full series either. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 10/15] dma-direct: Invoke dma offset func if needed 2020-05-19 20:33 [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan via iommu 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu @ 2020-05-19 20:34 ` Jim Quinlan via iommu 2020-05-20 16:15 ` [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Bjorn Helgaas 2 siblings, 0 replies; 14+ messages in thread From: Jim Quinlan via iommu @ 2020-05-19 20:34 UTC (permalink / raw) To: james.quinlan, Nicolas Saenz Julienne Cc: open list, open list:DMA MAPPING HELPERS, Robin Murphy, Christoph Hellwig Just like dma_pfn_offset, another offset is added to the dma/phys translation if there happen to be multiple regions that have different mapping offsets. Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> --- include/linux/dma-direct.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index 24b8684aa21d..825a773dbbc3 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -15,6 +15,14 @@ static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr) { dma_addr_t dev_addr = (dma_addr_t)paddr; +#ifdef CONFIG_DMA_PFN_OFFSET_MAP + if (unlikely(dev->dma_offset_map)) { + unsigned long dma_pfn_offset = dma_pfn_offset_frm_phys_addr( + dev->dma_offset_map, paddr); + + return dev_addr - ((dma_addr_t)dma_pfn_offset << PAGE_SHIFT); + } +#endif return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT); } @@ -22,6 +30,14 @@ static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr) { phys_addr_t paddr = (phys_addr_t)dev_addr; +#ifdef CONFIG_DMA_PFN_OFFSET_MAP + if (unlikely(dev->dma_offset_map)) { + unsigned long dma_pfn_offset = dma_pfn_offset_frm_dma_addr( + dev->dma_offset_map, dev_addr); + + return paddr + ((phys_addr_t)dma_pfn_offset << PAGE_SHIFT); + } +#endif return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT); } #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */ -- 2.17.1 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips 2020-05-19 20:33 [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan via iommu 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu 2020-05-19 20:34 ` [PATCH 10/15] dma-direct: Invoke dma offset func if needed Jim Quinlan via iommu @ 2020-05-20 16:15 ` Bjorn Helgaas 2 siblings, 0 replies; 14+ messages in thread From: Bjorn Helgaas @ 2020-05-20 16:15 UTC (permalink / raw) To: Jim Quinlan Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, Ulf Hansson, Heikki Krogerus, Saravana Kannan, Rob Herring, Greg Kroah-Hartman, Rafael J. Wysocki, Suzuki K Poulose, Julien Grall, open list, open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers), open list:DMA MAPPING HELPERS, Stefano Stabellini, open list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE, moderated list:ARM PORT, open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS, Dan Williams, Robin Murphy, Nicolas Saenz Julienne, moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE On Tue, May 19, 2020 at 04:33:58PM -0400, Jim Quinlan wrote: > This patchset expands the usefulness of the Broadcom Settop Box PCIe > controller by building upon the PCIe driver used currently by the > Raspbery Pi. Other forms of this patchset were submitted by me years > ago and not accepted; the major sticking point was the code required > for the DMA remapping needed for the PCIe driver to work [1]. > > There have been many changes to the DMA and OF subsystems since that > time, making a cleaner and less intrusive patchset possible. This > patchset implements a generalization of "dev->dma_pfn_offset", except > that instead of a single scalar offset it provides for multiple > offsets via a function which depends upon the "dma-ranges" property of > the PCIe host controller. This is required for proper functionality > of the BrcmSTB PCIe controller and possibly some other devices. > > [1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/ > > Jim Quinlan (15): > PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB > ahci_brcm: fix use of BCM7216 reset controller > dt-bindings: PCI: Add bindings for more Brcmstb chips > PCI: brcmstb: Add compatibily of other chips > PCI: brcmstb: Add suspend and resume pm_ops > PCI: brcmstb: Asserting PERST is different for 7278 > PCI: brcmstb: Add control of rescal reset > of: Include a dev param in of_dma_get_range() > device core: Add ability to handle multiple dma offsets > dma-direct: Invoke dma offset func if needed > arm: dma-mapping: Invoke dma offset func if needed > PCI: brcmstb: Set internal memory viewport sizes > PCI: brcmstb: Accommodate MSI for older chips > PCI: brcmstb: Set bus max burst side by chip type > PCI: brcmstb: add compatilbe chips to match list If you have occasion to post a v2 for other reasons, s/PCIE_BRCMSTB depends on ARCH_BRCMSTB/Allow PCIE_BRCMSTB on ARCH_BRCMSTB also/ s/ahci_brcm: fix use of BCM7216 reset controller/ata: ahci_brcm: Fix .../ s/Add compatibily of other chips/Add bcm7278 register info/ s/Asserting PERST is different for 7278/Add bcm7278 PERST support/ s/Set bus max burst side/Set bus max burst size/ s/add compatilbe chips.*/Add bcm7211, bcm7216, bcm7445, bcm7278 to match list/ Rewrap commit logs to use full 75 character lines (to allow for the 4 spaces added by git log). In commit logs, s/This commit// (use imperative mood instead). In "Accommodate MSI for older chips" commit log, s/commont/common/. > .../bindings/pci/brcm,stb-pcie.yaml | 40 +- > arch/arm/include/asm/dma-mapping.h | 17 +- > drivers/ata/ahci_brcm.c | 14 +- > drivers/of/address.c | 54 ++- > drivers/of/device.c | 2 +- > drivers/of/of_private.h | 8 +- > drivers/pci/controller/Kconfig | 4 +- > drivers/pci/controller/pcie-brcmstb.c | 403 +++++++++++++++--- > include/linux/device.h | 9 +- > include/linux/dma-direct.h | 16 + > include/linux/dma-mapping.h | 44 ++ > kernel/dma/Kconfig | 12 + > 12 files changed, 542 insertions(+), 81 deletions(-) > > -- > 2.17.1 > _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-05-22 14:36 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-19 20:33 [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan via iommu 2020-05-19 20:34 ` [PATCH 09/15] device core: Add ability to handle multiple dma offsets Jim Quinlan via iommu 2020-05-20 5:43 ` Greg Kroah-Hartman 2020-05-20 13:50 ` Jim Quinlan via iommu 2020-05-20 14:03 ` Greg Kroah-Hartman 2020-05-20 14:08 ` Jim Quinlan via iommu 2020-05-20 11:28 ` Nicolas Saenz Julienne 2020-05-22 14:31 ` Jim Quinlan via iommu 2020-05-20 17:42 ` Christoph Hellwig 2020-05-20 18:26 ` Jim Quinlan via iommu 2020-05-20 22:36 ` Dan Williams 2020-05-21 8:19 ` Christoph Hellwig 2020-05-19 20:34 ` [PATCH 10/15] dma-direct: Invoke dma offset func if needed Jim Quinlan via iommu 2020-05-20 16:15 ` [PATCH 00/15] PCI: brcmstb: enable PCIe for STB chips Bjorn Helgaas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).