linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/3] drm/tegra: Fix 2d and 3d clients detaching from IOMMU domain
Date: Thu, 24 Oct 2019 16:28:41 +0300	[thread overview]
Message-ID: <45926d95-3e7a-c56b-402a-2b2c6475c5db@gmail.com> (raw)
In-Reply-To: <20191024115804.GB2924027@ulmo>

24.10.2019 14:58, Thierry Reding пишет:
> On Sun, Jun 23, 2019 at 08:37:42PM +0300, Dmitry Osipenko wrote:
>> This should should fire up on the DRM's driver module re-loader because
>> there won't be enough available domains on older Tegra SoCs.
>>
>> Cc: stable <stable@vger.kernel.org>
>> Fixes: 0c407de5ed1a ("drm/tegra: Refactor IOMMU attach/detach")
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>>  drivers/gpu/drm/tegra/dc.c   | 4 ++--
>>  drivers/gpu/drm/tegra/drm.c  | 9 ++++++---
>>  drivers/gpu/drm/tegra/drm.h  | 3 ++-
>>  drivers/gpu/drm/tegra/gr2d.c | 4 ++--
>>  drivers/gpu/drm/tegra/gr3d.c | 4 ++--
>>  5 files changed, 14 insertions(+), 10 deletions(-)
> 
> I think I understand what this is trying to do, but the commit message
> does not help at all. So what's really going on here is that we need to
> detach the device from the group regardless of whether we're sharing the
> group or not, just like we attach groups to the shared domain whether
> they share the same group or not.

Yes, the commit's message could be improved.

> But in that case, I wonder if it's even worth splitting groups the way
> we are right now. Wouldn't it be better to just put all the devices into
> the same group and be done with it?
> 
> The current code gives me headaches every time I read it, so if we can
> just make it so that all the devices under the DRM device share the same
> group, this would become a lot easier to deal with. I'm not really
> convinced that it makes much sense to keep them on separate domains,
> especially given the constraints on the number of domains available on
> earlier Tegra devices.
> 
> Note that sharing a group will also make it much easier for these to use
> the DMA API if it is backed by an IOMMU.

Probably I'm blanking on everything about IOMMU now.. could you please
remind me what "IOMMU group" is?

Isn't it that each IOMMU group relates to the HW ID (SWGROUP)? But then
each display controller has its own SWGROUP.. and thus that sharing just
doesn't make any sense, hm.

> Let me see if I can throw something together to that effect.


  reply	other threads:[~2019-10-24 13:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-23 17:37 [PATCH v1 1/3] gpu: host1x: Remove implicit IOMMU backing on client's registration Dmitry Osipenko
2019-06-23 17:37 ` [PATCH v1 2/3] drm/tegra: Fix 2d and 3d clients detaching from IOMMU domain Dmitry Osipenko
2019-10-24 11:58   ` Thierry Reding
2019-10-24 13:28     ` Dmitry Osipenko [this message]
2019-10-24 13:50       ` Thierry Reding
2019-10-24 15:47         ` Dmitry Osipenko
2019-10-24 15:56           ` Thierry Reding
2019-10-24 15:57             ` Dmitry Osipenko
2019-10-24 16:09               ` Dmitry Osipenko
2019-10-24 16:21                 ` Dmitry Osipenko
2019-10-24 16:31                   ` Dmitry Osipenko
2019-10-24 17:28                     ` Thierry Reding
2019-10-24 18:46                       ` Dmitry Osipenko
2019-10-25 11:48                         ` Thierry Reding
2019-10-25 12:35                           ` Dmitry Osipenko
2019-06-23 17:37 ` [PATCH v1 3/3] drm/tegra: vic: Use common helpers to attach/detach " Dmitry Osipenko
2019-06-24  7:04 ` [PATCH v1 1/3] gpu: host1x: Remove implicit IOMMU backing on client's registration Christoph Hellwig
2019-06-24 12:55   ` Dmitry Osipenko
2019-10-24 11:50 ` Thierry Reding
2019-10-24 13:35   ` Dmitry Osipenko
2019-10-24 13:47     ` Thierry Reding
2019-10-24 17:15       ` Dmitry Osipenko
2019-10-24 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=45926d95-3e7a-c56b-402a-2b2c6475c5db@gmail.com \
    --to=digetx@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.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).