Support Multiple Dma Windows With Different Offsets

SubjectRe: [PATCH V5 1/2] ACPI / scan: Support multiple dma windows with different offsetsFromYicong Yang <>DateTue, 18 Oct :33:44 +0800On 2022/9/11 17:06, Jianmin Lv wrote:
> In DT systems configurations, of_dma_get_range() returns struct
> bus_dma_region DMA regions; they are used to set-up devices
> DMA windows with different offset available for translation between DMA
> address and CPU address.
>
> In ACPI systems configuration, acpi_dma_get_range() does not return
> DMA regions yet and that precludes setting up the dev->dma_range_map
> pointer and therefore DMA regions with multiple offsets.
>
> Update acpi_dma_get_range() to return struct bus_dma_region
> DMA regions like of_dma_get_range() does.
>
> After updating acpi_dma_get_range(), acpi_arch_dma_setup() is changed for
> ARM64, where the original dma_addr and size are removed as these
> arguments are now redundant, and pass 0 and U64_MAX for dma_base
> and size of arch_setup_dma_ops; this is a simplification consistent
> with what other ACPI architectures also pass to iommu_setup_dma_ops().
>

Hi,

With this patch we met problem as well. The DMA coherent mask is not set correctly
for a ehci usb controller and lead to the below calltrace:

[ 16.699259] [ cut here ] [ 16.703855] WARNING: CPU: 0 PID: 853 at kernel/dma/mapping.c:499 dma_alloc_attrs+0xc0/0xf0
[ 16.712082] Modules linked in:
[ 16.715124] CPU: 0 PID: 853 Comm: kworker/0:3 Not tainted 6.1.0-rc1-pipe-deadlock+ #5
[ 16.722916] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B211.01 11/10/2021
[ 16.731745] Workqueue: events work_for_cpu_fn
[ 16.736083] pstate: (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–)
[ 16.743013] pc : dma_alloc_attrs+0xc0/0xf0
[ 16.747091] lr : dma_pool_alloc+0x11c/0x200
[ 16.751255] sp : ffff80001e46bb50
[ 16.754554] x29: ffff80001e46bb50 x28: x27: [ 16.761657] x26: ffff80000b33ce18 x25: ffff800009cc6c48 x24: [ 16.768759] x23: ffff00208c x22: x21: cc0
[ 16.775861] x20: ffff00208ae82080 x19: ffff c40d0 x18: [ 16.782964] x17: 626d756e x16: e x15: ffff00208ae82640
[ 16.790066] x14: x13: 646e756f72616b72 x12: 6f [ 16.797167] x11: 73706f6e x10: ffff205f x9 : ffff b3ac
[ 16.804269] x8 : ffff b1b00 x7 : x6 : [ 16.811371] x5 : x4 : x3 : cc0
[ 16.818472] x2 : ffff00208c x1 : x0 : [ 16.825574] Call trace:
[ 16.828009] dma_alloc_attrs+0xc0/0xf0
[ 16.831741] dma_pool_alloc+0x11c/0x200
[ 16.835559] ehci_qh_alloc+0x60/0x12c
[ 16.839207] ehci_setup+0x18c/0x40c
[ 16.842680] ehci_pci_setup+0xb8/0x680
[ 16.846412] usb_add_hcd+0x310/0x5c0
[ 16.849973] usb_hcd_pci_probe+0x254/0x36c
[ 16.854051] ehci_pci_probe+0x40/0x60
[ 16.857698] local_pci_probe+0x48/0xb4
[ 16.861431] work_for_cpu_fn+0x24/0x40
[ 16.865163] process_one_work+0x1e0/0x450
[ 16.869155] worker_thread+0x2cc/0x44c
[ 16.872886] kthread+0x114/0x120
[ 16.876099] ret_from_fork+0x10/0x20
[ 16.879657] —[ end trace ]—

After reverting this patch the problem resolved. Tested on the latest 6.1-rc1.
Some investigation below…

> Reviewed-by: Robin Murphy
> Signed-off-by: Jianmin Lv
> —
> drivers/acpi/arm64/dma.c | 28 ++++++++++++ > drivers/acpi/scan.c | 53 +++++++++++++++++ > include/acpi/acpi_bus.h | 3 +–
> include/linux/acpi.h | 7 +++—
> 4 files changed, 44 insertions(+), 47 deletions(-)
>
> diff –git a/drivers/acpi/arm64/dma.c b/drivers/acpi/arm64/dma.c
> index f16739ad3cc0..93d796531af > — a/drivers/acpi/arm64/dma.c
> +++ b/drivers/acpi/arm64/dma.c
> @@ -4,11 +4,12 @@
> #include
> #include
>
> -void acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
> +void acpi_arch_dma_setup(struct device *dev)
> {
> int ret;
> u64 end, mask;
> – u64 dmaaddr = 0, size = 0, offset = 0;
> + u64 size = 0;
> + const struct bus_dma_region *map = NULL;
>
> /*
> * If @dev is expected to be DMA-capable then the bus code that created
> @@ -26,7 +27,19 @@ void acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
> else
> size = 1ULL <<>>
> – ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
> + ret = acpi_dma_get_range(dev, &map);
> + if (!ret && map) {
> + const struct bus_dma_region *r = map;
> +
> + for (end = 0; r->size; r++) {
> + if (r->dma_start + r->size – 1 > end)
> + end = r->dma_start + r->size – 1;
> + }
> +

DSDT reports a window of [mem 0x xffffffff pref] in _DMA for the target device
but we’re not retriving it correctly here. After adding some messages, it shows we haven’t
enter this loop and make size as 1 and mask to 0 finally.

Please let me know if you need more information.

Thanks.

> + size = end + 1;
> + dev->dma_range_map = map;
> + }
> +
> if (ret == -ENODEV)
> ret = iort_dma_get_ranges(dev, &size);
> if (!ret) {
> @@ -34,17 +47,10 @@ void acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
> * Limit coherent and dma mask based on size retrieved from
> * firmware.
> */
> – end = dmaaddr + size – 1;
> + end = size – 1;
> mask = DMA_BIT_MASK(ilog2(end) + 1);
> dev->bus_dma_limit = end;
> dev->coherent_dma_mask = min(dev->coherent_dma_mask, mask);
> *dev->dma_mask = min(*dev->dma_mask, mask);
> }
> –
> – *dma_addr = dmaaddr;
> – *dma_size = size;
> –
> – ret = dma_direct_set_offset(dev, dmaaddr + offset, dmaaddr, size);
> –
> – dev_dbg(dev, “dma_offset(%#08llx)%s\n”, offset, ret ? ” failed!” : “”);
> }
> diff –git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 42cec8120f18..f96ef > — a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include “internal.h”
>
> @@ -1467,25 +1468,21 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
> * acpi_dma_get_range() – Get device DMA parameters.
> *
> * @dev: device to configure
> – * @dma_addr: pointer device DMA address result
> – * @offset: pointer to the DMA offset result
> – * @size: pointer to DMA range size result
> + * @map: pointer to DMA ranges result
> *
> – * Evaluate DMA regions and return respectively DMA region start, offset
> – * and size in dma_addr, offset and size on parsing success; it does not
> – * update the passed in values on failure.
> + * Evaluate DMA regions and return pointer to DMA regions on
> + * parsing success; it does not update the passed in values on failure.
> *
> * Return 0 on success, > */
> -int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
> u64 *size)
> +int acpi_dma_get_range(struct device *dev, const struct bus_dma_region **map)
>
> struct acpi_device *adev;
> LIST_HEAD(list);
> struct resource_entry *rentry;
> int ret;
> struct device *dma_dev = dev;
> – u64 len, dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> + struct bus_dma_region *r;
>
> /*
> * Walk the device tree chasing an ACPI companion with a _DMA
> @@ -1510,31 +1507,28 @@ int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
>
> ret = acpi_dev_get_dma_resources(adev, &list);
> if (ret > 0) Read the blog