From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Rafael J. Wysocki"
<rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
dri-devel
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU
Date: Fri, 27 Jul 2018 23:02:01 +0300 [thread overview]
Message-ID: <4850389.K9ByBxYttl@dimapc> (raw)
In-Reply-To: <20180727183134.GD6738-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On Friday, 27 July 2018 21:31:34 MSK Joerg Roedel wrote:
> On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> > I don't follow why we need a property rather than being implied by the
> > device's (the GPU) compatible string.
>
> There might be devices where either setup works, with or without IOMMU
> translation, and the firmware can set the property depending on whether
> the user wants more performance or more security.
>
> If we have a whitelist in the kernel this gets more complicated, we
> probably need additional kernel-parameters to overwrite those whitelist
> entries. Having a property in the device-tree seems to be a better way
> here, imho.
IIUC, device-tree should be considered to be "written in stone" for a consumer
device and hence firmware property isn't something that could be easily
changed. The kernel-parameter will be much more universal. Anyway the global
whitelisting should be a different topic for discussion, right now we need a
kind of private whitelisting that is internal to kernel.
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2018-07-27 20:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-26 23:16 [RFC PATCH v1 0/6] Resolve unwanted DMA backing with IOMMU Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 1/6] driver core: Add option for disabling of backing devices DMA " Dmitry Osipenko
[not found] ` <20180726231624.21084-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-07-26 23:16 ` [RFC PATCH v1 2/6] of/device: Don't back devices DMA with IOMMU if that's undesired by driver Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 3/6] drm/tegra: Avoid implicit DMA backing with IOMMU Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 4/6] gpu: host1x: " Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 6/6] Revert "drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping" Dmitry Osipenko
2018-07-26 23:16 ` [RFC PATCH v1 5/6] drm/nouveau: tegra: Universally avoid implicit DMA backing with IOMMU Dmitry Osipenko
2018-07-27 8:25 ` [RFC PATCH v1 0/6] Resolve unwanted " Joerg Roedel
2018-07-27 9:03 ` Will Deacon
[not found] ` <20180727090328.GH28088-5wv7dgnIgG8@public.gmane.org>
2018-07-27 14:10 ` Dmitry Osipenko
2018-07-27 14:20 ` Joerg Roedel
2018-07-27 17:13 ` Rob Herring
2018-07-27 18:31 ` Joerg Roedel
[not found] ` <20180727183134.GD6738-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2018-07-27 20:02 ` Dmitry Osipenko [this message]
2018-07-27 16:02 ` Robin Murphy
[not found] ` <daadd395-dcb7-9505-f171-0fcc28570301-5wv7dgnIgG8@public.gmane.org>
2018-07-27 17:03 ` Jordan Crouse
[not found] ` <20180727170326.GA21283-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>
2018-07-27 17:16 ` Dmitry Osipenko
2018-07-28 11:40 ` Dmitry Osipenko
2018-08-02 18:24 ` Dmitry Osipenko
2018-08-03 15:43 ` Robin Murphy
2018-08-03 17:00 ` Jordan Crouse
2018-08-15 19:56 ` Dmitry Osipenko
2018-08-16 17:23 ` Robin Murphy
[not found] ` <afecce46-96d2-9688-30b4-0a3f17a651d3-5wv7dgnIgG8@public.gmane.org>
2018-09-20 17:09 ` Dmitry Osipenko
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=4850389.K9ByBxYttl@dimapc \
--to=digetx-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@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 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).