All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jordan Crouse <jcrouse@codeaurora.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Clark <robdclark@gmail.com>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>,
	David Airlie <airlied@linux.ie>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Sushmita Susheelendra <ssusheel@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations
Date: Wed, 26 Jul 2017 10:35:05 -0600	[thread overview]
Message-ID: <20170726163505.GA8482@jcrouse-lnx.qualcomm.com> (raw)
In-Reply-To: <20170726155329.581707-2-arnd@arndb.de>

On Wed, Jul 26, 2017 at 05:52:45PM +0200, 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@linaro.org>
> Fixes: 7c65817e6d38 ("drm/msm: gpu: Enable zap shader for A5XX")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> I think we want this to be applied for 4.13, as the upstream
> code that was added in the merge window is seriously broken without it
> ---
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 71 ++++++++++++-----------------------
>  drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  2 -
>  2 files changed, 23 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 1d54c76a7778..ce545b3a9d17 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -15,7 +15,7 @@
>  #include <linux/cpumask.h>
>  #include <linux/qcom_scm.h>
>  #include <linux/dma-mapping.h>
> -#include <linux/of_reserved_mem.h>
> +#include <linux/of_address.h>
>  #include <linux/soc/qcom/mdt_loader.h>
>  #include "msm_gem.h"
>  #include "msm_mmu.h"
> @@ -29,6 +29,8 @@ static void a5xx_dump(struct msm_gpu *gpu);
>  static int zap_shader_load_mdt(struct device *dev, const char *fwname)
>  {
>  	const struct firmware *fw;
> +	struct device_node *np;
> +	struct resource r;
>  	phys_addr_t mem_phys;
>  	ssize_t mem_size;
>  	void *mem_region = NULL;
> @@ -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(dev->of_node, "memory-region", 0);

I think this should be np = of_parse_phandle(np, "memory-region", 0);

With that change this patch works great.

> @@ -373,44 +393,6 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
>  }
>  
>  /* Set up a child device to "own" the zap shader */

This now incorrect comment can be zapped (pun intended).

> -static int a5xx_zap_shader_dev_init(struct device *parent, struct device *dev)
> -{
> -	struct device_node *node;
> -	int ret;
> -
> -	if (dev->parent)
> -		return 0;
> -

With above changes,
Acked-and-Tested-By: Jordan Crouse <jcrouse@codeaurora.org>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2017-07-26 16:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-26 15:52 [PATCH 1/2] drm/msm: gpu: call qcom_mdt interfaces only for ARCH_QCOM Arnd Bergmann
2017-07-26 15:52 ` Arnd Bergmann
2017-07-26 15:52 ` [PATCH 2/2] drm/msm: gpu: don't abuse dma_alloc for non-DMA allocations Arnd Bergmann
2017-07-26 15:52   ` Arnd Bergmann
2017-07-26 16:35   ` Jordan Crouse [this message]
2017-07-26 20:01     ` Arnd Bergmann
2017-07-26 20:01       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170726163505.GA8482@jcrouse-lnx.qualcomm.com \
    --to=jcrouse@codeaurora.org \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=bjorn.andersson@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=ssusheel@codeaurora.org \
    --cc=stanimir.varbanov@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.