All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
To: Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Cc: Alex Deucher
	<alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH] drm: return false in drm_arch_can_wc_memory() for ARM
Date: Fri, 21 Dec 2018 14:16:44 +0000	[thread overview]
Message-ID: <20181221141644.GB22341@e110455-lin.cambridge.arm.com> (raw)
In-Reply-To: <20181220153619.GP21184-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>

On Thu, Dec 20, 2018 at 04:36:19PM +0100, Daniel Vetter wrote:
> On Thu, Dec 20, 2018 at 09:56:57AM -0500, Alex Deucher wrote:
> > I'm not familiar enough with ARM to know if write combining
> > is actually an architectural limitation or if it's an issue
> > with the PCIe IPs used on various platforms, but so far
> > everyone that has tried to run radeon hardware on
> > ARM has had to disable it.  So let's just make it official.
> 
> wc on arm is Really Complicated (tm) afaiui. There's issues with aliasing
> mappings and stuff, so you need to allocate your wc memory from special
> pools. So probably best to just disable it until we figure this out.

I believe both of you are conflating different issues under the wrong
name. Write combining happens all the time with Arm, the ARMv8
architecture is a weakly-ordered model of memory so hardware is allowed
to re-order or combine memory access as they seem fit.

A while ago I did run an AMD GPU card on my Juno dev board and it worked
(for a very limited definition of worked, I've only validated the fact
that I could get an fbcon and could run un-accelerated X11). So I would
be interested if Alex could share some of the scenarios where people are
seeing failures.

As for aliasing, yeah, having multiple aliases to the same piece of
memory is a bad thing. The problem arises when devices on the PCI bus
have memory allocated as device memory (which on Arm is non-cacheable
and non-reorderable), but the PCI bus effectively acts as a write-combiner
which changes the order of transactions. Therefore, for devices that
have local memory associated with them (i.e. more than just register
accesses) one should allocate memory in the first place that is
Device-GRE (gathering, reordering and early-access). Otherwise, problems
will surface that are not visible on x86 as that is a strongly ordered
architecture.

>  
> > Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Given that this API is only used by AMD I'm OK for now with the change,
but I think in general it is misleading and we should work towards
fixing radeon and amd drivers.

Best regards,
Liviu

> 
> > ---
> >  include/drm/drm_cache.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
> > index bfe1639df02d..691b4c4b0587 100644
> > --- a/include/drm/drm_cache.h
> > +++ b/include/drm/drm_cache.h
> > @@ -47,6 +47,8 @@ static inline bool drm_arch_can_wc_memory(void)
> >  	return false;
> >  #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
> >  	return false;
> > +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> > +	return false;
> >  #else
> >  	return true;
> >  #endif
> > -- 
> > 2.13.6
> > 
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2018-12-21 14:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-20 14:56 [PATCH] drm: return false in drm_arch_can_wc_memory() for ARM Alex Deucher
     [not found] ` <20181220145657.304-1-alexander.deucher-5C7GfCeVMHo@public.gmane.org>
2018-12-20 15:36   ` Daniel Vetter
     [not found]     ` <20181220153619.GP21184-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-12-21 14:16       ` Liviu Dudau [this message]
     [not found]         ` <20181221141644.GB22341-A/Nd4k6kWRHZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2018-12-21 14:48           ` Alex Deucher
     [not found]             ` <CADnq5_P9VZMhC_4j3F4hqHdD6Ey0=totPuNhF3hYBzkbgHsPpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-12-21 16:39               ` Eric Anholt

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=20181221141644.GB22341@e110455-lin.cambridge.arm.com \
    --to=liviu.dudau-5wv7dgnigg8@public.gmane.org \
    --cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
    --cc=alexdeucher-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=daniel-/w4YWyX8dFk@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.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.