linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Koenig, Christian" <Christian.Koenig@amd.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "Carsten.Haitzler@arm.com" <Carsten.Haitzler@arm.com>,
	David Airlie <airlied@linux.ie>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Huang, Ray" <Ray.Huang@amd.com>,
	"Zhang, Jerry" <Jerry.Zhang@amd.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Bernhard.Rosenkranzer@linaro.org"
	<Bernhard.Rosenkranzer@linaro.org>
Subject: Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
Date: Thu, 10 Jan 2019 08:36:52 +0000	[thread overview]
Message-ID: <1ef4c460-9f11-3894-712f-b19b67287c4b@amd.com> (raw)
In-Reply-To: <20190110072841.3283-1-ard.biesheuvel@linaro.org>

Hi Ard,

thanks a lot for this! At least somebody who can explain why this 
doesn't work as expected.

The problem is that the hardware actually needs a few pages as uncached 
in a couple of cases to work correctly. So we could still run into 
issues with that solution.

For now we have blocked userspace/kernel from extensively using write 
combine mappings by adjusting drm_arch_can_wc_memory(), but that is 
probably degrading performance quite a bit.

What can be done to improve the solution? At least on X86 we solve this 
by marking the write combined pages in the linear mapping as uncached as 
well. Would this be doable on ARM as well?

Thanks,
Christian.

Am 10.01.19 um 08:28 schrieb Ard Biesheuvel:
> ARM systems do not permit the use of anything other than cached
> mappings for system memory, since that memory may be mapped in the
> linear region as well, and the architecture does not permit aliases
> with mismatched attributes.
>
> So short-circuit the evaluation in ttm_io_prot() if the flags include
> TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
> attributes immediately.
>
> This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
> Without this change, amdgpu does not start at all, and radeon only
> produces corrupt display output.
>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: Huang Rui <ray.huang@amd.com>
> Cc: Junwei Zhang <Jerry.Zhang@amd.com>
> Cc: David Airlie <airlied@linux.ie>
> Reported-by: Carsten Haitzler <Carsten.Haitzler@arm.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>   drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 046a6dda690a..0c1eef5f7ae3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp)
>   	if (caching_flags & TTM_PL_FLAG_CACHED)
>   		return tmp;
>   
> +#if defined(__arm__) || defined(__aarch64__)
> +	/* ARM only permits cached mappings of system memory */
> +	if (caching_flags & TTM_PL_SYSTEM)
> +		return tmp;
> +#endif
>   #if defined(__i386__) || defined(__x86_64__)
>   	if (caching_flags & TTM_PL_FLAG_WC)
>   		tmp = pgprot_writecombine(tmp);

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-01-10  8:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  7:28 [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM Ard Biesheuvel
2019-01-10  8:36 ` Zhang, Jerry(Junwei)
2019-01-10  8:36 ` Koenig, Christian [this message]
2019-01-10  9:34 ` Michel Dänzer
2019-01-14 10:53   ` Ard Biesheuvel
2019-01-14 11:38     ` Koenig, Christian
2019-01-14 17:32       ` Ard Biesheuvel
     [not found]         ` <9f956898-7973-98ee-6bf1-e1d445e9d365@amd.com>
2019-01-14 19:13           ` Will Deacon
2019-01-14 19:21             ` Koenig, Christian
2019-01-14 19:35               ` Will Deacon
2019-01-15 11:31                 ` Michael Ellerman
2019-01-16  0:33                   ` Benjamin Herrenschmidt
2019-01-16  7:35                     ` Koenig, Christian
2019-01-16  7:47                       ` Ard Biesheuvel
2019-01-17  6:07                         ` Benjamin Herrenschmidt
2019-01-17  8:02                           ` Ard Biesheuvel
2019-01-17  5:59                       ` Benjamin Herrenschmidt

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=1ef4c460-9f11-3894-712f-b19b67287c4b@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Bernhard.Rosenkranzer@linaro.org \
    --cc=Carsten.Haitzler@arm.com \
    --cc=Jerry.Zhang@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=airlied@linux.ie \
    --cc=ard.biesheuvel@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /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 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).