On Wed 26 Jul 12:59 PDT 2017, Arnd Bergmann wrote:
> In zap_shader_load_mdt(), we pass a pointer to a phys_addr_t
> into dmam_alloc_coherent, which the compiler warns about:
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'zap_shader_load_mdt':
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:54:50: error: passing argument 3 of 'dmam_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
>
> The returned DMA address is later passed on to a function that
> takes a phys_addr_t, so it's clearly wrong to use the DMA
> mapping interface here: the memory may be uncached, or the
> address may be completely wrong if there is an IOMMU connected
> to the device. What the code actually wants to do is to get
> the physical address from the reserved-mem node. It goes through
> the dma-mapping interfaces for obscure reasons, and this
> apparently only works by chance, relying on specific bugs
> in the error handling of the arm64 dma-mapping implementation.
>
> The same problem existed in the "venus" media driver, which was
> now fixed by Stanimir Varbanov after long discussions.
>
> In order to make some progress here, I have now ported his
> approach over to the adreno driver. The patch is currently
> untested, and should get a good review, but it is now much
> simpler than the original, and it should be obvious what
> goes wrong if I made a mistake in the port.
>
> See also: a6e2d36bf6b7 ("media: venus: don't abuse dma_alloc for non-DMA allocations")
> Cc: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx>
> Fixes: 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX")
> Acked-and-Tested-by: Jordan Crouse <jcrouse@xxxxxxxxxxxxxx>
> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
Acked-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
However...
[..]
> @@ -37,6 +39,21 @@ static int zap_shader_load_mdt(struct device *dev, const char *fwname)
> if (!IS_ENABLED(CONFIG_ARCH_QCOM))
> return -EINVAL;
>
> + np = of_get_child_by_name(dev->of_node, "zap-shader");
> + if (!np)
> + return -ENODEV;
> +
> + np = of_parse_phandle(np, "memory-region", 0);
> + if (!np)
> + return -EINVAL;
> +
> + ret = of_address_to_resource(np, 0, &r);
> + if (ret)
> + return ret;
> +
> + mem_phys = r.start;
> + mem_size = resource_size(&r);
> +
...this means that it's now required that the reserved-memory region has
a "reg", the prior solution supported that we just specify a "size".
I have another driver where I need to figure out a mechanism of getting
hold of the dynamically allocated "base" of struct reserved_mem.
So I think it's appropriate to apply this fix now and loosen the
restrictions on placement later.
Regards,
Bjorn
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
