[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190121163539.GA18070@infradead.org>
Date: Mon, 21 Jan 2019 08:35:39 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
amd-gfx@...ts.freedesktop.org,
Christian Koenig <christian.koenig@....com>,
Alex Deucher <alexander.deucher@....com>,
David Zhou <David1.Zhou@....com>,
Huang Rui <ray.huang@....com>,
Junwei Zhang <Jerry.Zhang@....com>,
Michel Daenzer <michel.daenzer@....com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <maxime.ripard@...tlin.com>,
Sean Paul <sean@...rly.run>,
Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Will Deacon <will.deacon@....com>
Subject: Re: [RFC PATCH] drm: disable WC optimization for cache coherent
devices on non-x86
On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote:
> > Until that happens we should just change the driver ifdefs to default
> > the hacks to off and only enable them on setups where we 100%
> > positively know that they actually work. And document that fact
> > in big fat comments.
>
> Well, as I mentioned in my commit log as well, if we default to off
> unless CONFIG_X86, we may break working setups on MIPS and Power where
> the device is in fact non-cache coherent, and relies on this
> 'optimization' to get things working. The same could be true for
> non-coherent ARM systems, hence my approach to disable this hack for
> cache coherent devices on non-X86 only.
Do we break existing setups or just reduce performance due to the lack
of WC mappings? I thought it was the latter. The point is that
even your check won't do what you actually said. At lot of non-loongson
mips platforms are not cache coherent. As are a lot of arm setups
and all sparc64 ones for example. And chances that someone will
hacks this file out in a random subsystem when adding news ports also
is rather slim, so we'll remaing broken by default.
That is why I want at very least: a whitelist instead of a blacklist
and some very big comments explaining what is going on here. And in
the mid to long term even drm really needs to learn to use the
proper APIs :(
Powered by blists - more mailing lists