From: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
David Zhou <David1.Zhou-5C7GfCeVMHo@public.gmane.org>,
Maxime Ripard
<maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>,
Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
Maarten Lankhorst
<maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
Michel Daenzer <michel.daenzer-5C7GfCeVMHo@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Junwei Zhang <Jerry.Zhang-5C7GfCeVMHo@public.gmane.org>,
Huang Rui <ray.huang-5C7GfCeVMHo@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>,
Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>,
Alex Deucher <alexander.deucher-5C7GfCeVMHo@public.gmane.org>,
Sean Paul <sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org>,
Christian Koenig <christian.koenig-5C7GfCeVMHo@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
Date: Mon, 21 Jan 2019 07:59:08 -0800 [thread overview]
Message-ID: <20190121155908.GA8084@infradead.org> (raw)
In-Reply-To: <CAKv+Gu-hR=uieOeg7QheA5yfAycUoi2vjZsDUvROKVjW4eUNqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > > +#include <linux/dma-noncoherent.h>
> >
> > This header is not for usage in device drivers, but purely for
> > dma-mapping implementations!
> >
>
> Is that documented anywhere?
I'll add big fat comments. But the fact that nothing is exported
there should be a fairly big hint.
> > And even if something like this was valid to do, it would have to be
> > a core function with an arch hook, and not hidden in a random driver.
>
> Why would it not be valid to do? Is it wrong for a driver to be aware
> of whether a device is cache coherent or not?
>
> And in case it isn't, do you have an alternative suggestion on how to
> fix this mess?
For the write combine mappings we need a proper core API how instances
can advertise the support. One thing I want to do fairly soon is
error checking of the attrs argument to dma_alloc_attrs - so if you
pass in something unsupported it will give you back an error.
It seems that isn't quite enough for the drm use case, so we might
also need a way to query these features, but that really has to go
through the usual dma layer abstraction as well and not hacked together
in a driver based on an eduacted guestimate.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>,
David Zhou <David1.Zhou@amd.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
David Airlie <airlied@linux.ie>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Michel Daenzer <michel.daenzer@amd.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
amd-gfx@lists.freedesktop.org,
Christoph Hellwig <hch@infradead.org>,
Junwei Zhang <Jerry.Zhang@amd.com>, Huang Rui <ray.huang@amd.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel@ffwll.ch>,
Michael Ellerman <mpe@ellerman.id.au>,
Alex Deucher <alexander.deucher@amd.com>,
Sean Paul <sean@poorly.run>,
Christian Koenig <christian.koenig@amd.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
Date: Mon, 21 Jan 2019 07:59:08 -0800 [thread overview]
Message-ID: <20190121155908.GA8084@infradead.org> (raw)
In-Reply-To: <CAKv+Gu-hR=uieOeg7QheA5yfAycUoi2vjZsDUvROKVjW4eUNqw@mail.gmail.com>
On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > > +#include <linux/dma-noncoherent.h>
> >
> > This header is not for usage in device drivers, but purely for
> > dma-mapping implementations!
> >
>
> Is that documented anywhere?
I'll add big fat comments. But the fact that nothing is exported
there should be a fairly big hint.
> > And even if something like this was valid to do, it would have to be
> > a core function with an arch hook, and not hidden in a random driver.
>
> Why would it not be valid to do? Is it wrong for a driver to be aware
> of whether a device is cache coherent or not?
>
> And in case it isn't, do you have an alternative suggestion on how to
> fix this mess?
For the write combine mappings we need a proper core API how instances
can advertise the support. One thing I want to do fairly soon is
error checking of the attrs argument to dma_alloc_attrs - so if you
pass in something unsupported it will give you back an error.
It seems that isn't quite enough for the drm use case, so we might
also need a way to query these features, but that really has to go
through the usual dma layer abstraction as well and not hacked together
in a driver based on an eduacted guestimate.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
amd-gfx@lists.freedesktop.org,
Christian Koenig <christian.koenig@amd.com>,
Alex Deucher <alexander.deucher@amd.com>,
David Zhou <David1.Zhou@amd.com>, Huang Rui <ray.huang@amd.com>,
Junwei Zhang <Jerry.Zhang@amd.com>,
Michel Daenzer <michel.daenzer@amd.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Sean Paul <sean@poorly.run>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
Date: Mon, 21 Jan 2019 07:59:08 -0800 [thread overview]
Message-ID: <20190121155908.GA8084@infradead.org> (raw)
In-Reply-To: <CAKv+Gu-hR=uieOeg7QheA5yfAycUoi2vjZsDUvROKVjW4eUNqw@mail.gmail.com>
On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > > +#include <linux/dma-noncoherent.h>
> >
> > This header is not for usage in device drivers, but purely for
> > dma-mapping implementations!
> >
>
> Is that documented anywhere?
I'll add big fat comments. But the fact that nothing is exported
there should be a fairly big hint.
> > And even if something like this was valid to do, it would have to be
> > a core function with an arch hook, and not hidden in a random driver.
>
> Why would it not be valid to do? Is it wrong for a driver to be aware
> of whether a device is cache coherent or not?
>
> And in case it isn't, do you have an alternative suggestion on how to
> fix this mess?
For the write combine mappings we need a proper core API how instances
can advertise the support. One thing I want to do fairly soon is
error checking of the attrs argument to dma_alloc_attrs - so if you
pass in something unsupported it will give you back an error.
It seems that isn't quite enough for the drm use case, so we might
also need a way to query these features, but that really has to go
through the usual dma layer abstraction as well and not hacked together
in a driver based on an eduacted guestimate.
next prev parent reply other threads:[~2019-01-21 15:59 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 10:06 [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86 Ard Biesheuvel
2019-01-21 10:06 ` Ard Biesheuvel
2019-01-21 10:11 ` Koenig, Christian
2019-01-21 10:11 ` Koenig, Christian
2019-01-21 10:11 ` Koenig, Christian
2019-01-21 15:07 ` Christoph Hellwig
2019-01-21 15:07 ` Christoph Hellwig
2019-01-21 15:07 ` Christoph Hellwig
2019-01-21 15:33 ` Ard Biesheuvel
2019-01-21 15:33 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-hR=uieOeg7QheA5yfAycUoi2vjZsDUvROKVjW4eUNqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-21 15:59 ` Christoph Hellwig [this message]
2019-01-21 15:59 ` Christoph Hellwig
2019-01-21 15:59 ` Christoph Hellwig
2019-01-21 16:14 ` Ard Biesheuvel
2019-01-21 16:14 ` Ard Biesheuvel
2019-01-21 16:22 ` Christoph Hellwig
2019-01-21 16:22 ` Christoph Hellwig
2019-01-21 16:22 ` Christoph Hellwig
2019-01-21 16:30 ` Ard Biesheuvel
2019-01-21 16:30 ` Ard Biesheuvel
2019-01-21 16:35 ` Christoph Hellwig
2019-01-21 16:35 ` Christoph Hellwig
2019-01-21 16:35 ` Christoph Hellwig
2019-01-21 16:50 ` Ard Biesheuvel
2019-01-21 16:50 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-5V-UjP_YzZBCEsa+o_G6BRSVw2ZimYGNEfRGf-aRPNg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-21 17:55 ` Michel Dänzer
2019-01-21 17:55 ` Michel Dänzer
2019-01-21 17:55 ` Michel Dänzer
2019-01-21 17:59 ` Ard Biesheuvel
2019-01-21 17:59 ` Ard Biesheuvel
2019-01-21 17:59 ` Ard Biesheuvel
2019-01-21 18:04 ` Michel Dänzer
2019-01-21 18:04 ` Michel Dänzer
2019-01-21 18:20 ` Ard Biesheuvel
2019-01-21 18:20 ` Ard Biesheuvel
2019-01-21 18:23 ` Michel Dänzer
2019-01-21 18:23 ` Michel Dänzer
2019-01-21 18:28 ` Ard Biesheuvel
2019-01-21 18:28 ` Ard Biesheuvel
[not found] ` <CAKv+Gu99zHqcQtj6TiOXAr3Qa6WWhKem+DHVA_mAQ0-Bc0Vbqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-21 19:04 ` Michel Dänzer
2019-01-21 19:04 ` Michel Dänzer
2019-01-21 19:04 ` Michel Dänzer
2019-01-21 19:18 ` Ard Biesheuvel
2019-01-21 19:18 ` Ard Biesheuvel
2019-01-22 8:38 ` Ard Biesheuvel
2019-01-22 8:38 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_VBd8agHASc5RS0eCgyXP64Lt_i4yPuBjKwGQ+5Lpd5Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-22 20:56 ` Alex Deucher
2019-01-22 20:56 ` Alex Deucher
2019-01-22 20:56 ` Alex Deucher
2019-01-22 21:07 ` Ard Biesheuvel
2019-01-22 21:07 ` Ard Biesheuvel
2019-01-23 7:15 ` Christoph Hellwig
2019-01-23 7:15 ` Christoph Hellwig
2019-01-23 9:08 ` Ard Biesheuvel
2019-01-23 9:08 ` Ard Biesheuvel
2019-01-23 16:44 ` Christoph Hellwig
2019-01-23 16:44 ` Christoph Hellwig
2019-01-23 16:44 ` Christoph Hellwig
2019-01-23 16:52 ` Ard Biesheuvel
2019-01-23 16:52 ` Ard Biesheuvel
2019-01-23 16:52 ` Ard Biesheuvel
2019-01-24 9:13 ` Christoph Hellwig
2019-01-24 9:13 ` Christoph Hellwig
[not found] ` <20190124091316.GA22796-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2019-01-24 9:25 ` Koenig, Christian
2019-01-24 9:25 ` Koenig, Christian
2019-01-24 9:25 ` Koenig, Christian
2019-01-24 9:28 ` Ard Biesheuvel
2019-01-24 9:28 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_3LurSN-6w1WijPfpJpc+Pgu0YTnwTfMrXMF3-AKAnJA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-24 9:45 ` Koenig, Christian
2019-01-24 9:45 ` Koenig, Christian
2019-01-24 9:45 ` Koenig, Christian
2019-01-24 9:59 ` Ard Biesheuvel
2019-01-24 9:59 ` Ard Biesheuvel
2019-01-24 11:23 ` Koenig, Christian
2019-01-24 11:23 ` Koenig, Christian
2019-01-24 11:23 ` Koenig, Christian
2019-01-24 11:26 ` Ard Biesheuvel
2019-01-24 11:26 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_2f0FaJ+Th7H48u4GrPX=MM9xw0fFjdwhfRrr1nhgEkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-24 11:37 ` Koenig, Christian
2019-01-24 11:37 ` Koenig, Christian
2019-01-24 11:37 ` Koenig, Christian
2019-01-24 11:45 ` Ard Biesheuvel
2019-01-24 11:45 ` Ard Biesheuvel
2019-01-24 13:54 ` Alex Deucher
2019-01-24 13:54 ` Alex Deucher
2019-01-24 13:57 ` Ard Biesheuvel
2019-01-24 13:57 ` Ard Biesheuvel
[not found] ` <CAKv+Gu9Ch_+2wUirmPb1-dXGzWbF2XoH-b6DrtkBNEXpx5obPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-24 14:00 ` Alex Deucher
2019-01-24 14:00 ` Alex Deucher
2019-01-24 14:00 ` Alex Deucher
2019-01-24 16:04 ` Michel Dänzer
2019-01-24 16:04 ` Michel Dänzer
2019-01-24 16:04 ` Michel Dänzer
[not found] ` <CAKv+Gu-9vEKu8mG-o+-4M1ZcgZmTTJVfEdNS9R27AFX8P5sqyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-01-24 9:31 ` Michel Dänzer
2019-01-24 9:31 ` Michel Dänzer
2019-01-24 9:31 ` Michel Dänzer
2019-01-24 9:37 ` Ard Biesheuvel
2019-01-24 9:37 ` Ard Biesheuvel
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=20190121155908.GA8084@infradead.org \
--to=hch-wegcikhe2lqwvfeawa7xhq@public.gmane.org \
--cc=David1.Zhou-5C7GfCeVMHo@public.gmane.org \
--cc=Jerry.Zhang-5C7GfCeVMHo@public.gmane.org \
--cc=airlied-cv59FeDIM0c@public.gmane.org \
--cc=alexander.deucher-5C7GfCeVMHo@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
--cc=daniel-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org \
--cc=michel.daenzer-5C7GfCeVMHo@public.gmane.org \
--cc=mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org \
--cc=ray.huang-5C7GfCeVMHo@public.gmane.org \
--cc=sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@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.