All of lore.kernel.org
 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 1/3] gpu: host1x: Remove implicit IOMMU backing on client's registration
Date: Thu, 24 Oct 2019 20:09:23 +0300	[thread overview]
Message-ID: <b8a9fc65-3d2f-8461-e0de-83cbb45fea49@gmail.com> (raw)
In-Reply-To: <55ab29ad-da9b-c178-4480-dc6edb09b3e4@gmail.com>

24.10.2019 16:35, Dmitry Osipenko пишет:
> 24.10.2019 14:50, Thierry Reding пишет:
>> On Sun, Jun 23, 2019 at 08:37:41PM +0300, Dmitry Osipenko wrote:
>>> On ARM32 we don't want any of the clients device to be backed by the
>>> implicit domain, simply because we can't afford such a waste on older
>>> Tegra SoCs that have very few domains available in total. The recent IOMMU
>>> support addition for the Video Decoder hardware uncovered the problem
>>> that an unfortunate drivers probe order results in the DRM driver probe
>>> failure if CONFIG_ARM_DMA_USE_IOMMU=y due to a shortage of IOMMU domains
>>> caused by the implicit backing. The host1x_client_register() is a common
>>> function that is invoked by all of the relevant DRM drivers during theirs
>>> probe and hence it is convenient to remove the implicit backing there,
>>> resolving the problem.
>>>
>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>> ---
>>>  drivers/gpu/host1x/bus.c | 19 +++++++++++++++++++
>>>  1 file changed, 19 insertions(+)
>>
>> I don't really want to do this in a central place like this. If we
>> really do need this, why can't we do it in the individual drivers?
> 
> Why do you want to duplicate the same action for each driver instead of
> doing it in a single common place?
> 
>> we already call host1x_client_iommu_attach() from all the drivers and
>> that detaches from the IOMMU as well. So I'm not sure I understand why
>> this is needed.
> 
> Wish you could ask that couple months ago. I'll try to refresh the details.
> 

In kernel's boot order:

1) Host1x is attached to exclusive implicit domain
2) Host1x is detached from the implicit domain and attached to explicit
3) Both DC's fail to attach to implicit domain because DMA-mapping code
doesn't take into account multiple devices in the same group.
4) GR2D is attached to exclusive implicit domain
5) GR3D is attached to exclusive implicit domain
6) VDE is attached to exclusive implicit domain
7) VDE is detached from the implicit domain and attached to explicit
8) DC client is trying to attach to DRM domain in
host1x_client_iommu_attach() and that fails because tegra-smmu code
allocates ASID in tegra_smmu_attach_dev()->tegra_smmu_as_prepare() (i.e.
on IOMMU group's attaching) and all ASIDs are already busy.

Hence if DRM sub-device drivers are detaching from the implicit domain
on probe, then the problem is getting worked around because there are
available ASIDs at the time of host1x clients initialization.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1 1/3] gpu: host1x: Remove implicit IOMMU backing on client's registration
Date: Thu, 24 Oct 2019 20:09:23 +0300	[thread overview]
Message-ID: <b8a9fc65-3d2f-8461-e0de-83cbb45fea49@gmail.com> (raw)
Message-ID: <20191024170923.5tFmO32xJ_PvvKpzRBVrq2WJhd8W5be0X6FnF4U-iQ4@z> (raw)
In-Reply-To: <55ab29ad-da9b-c178-4480-dc6edb09b3e4@gmail.com>

24.10.2019 16:35, Dmitry Osipenko пишет:
> 24.10.2019 14:50, Thierry Reding пишет:
>> On Sun, Jun 23, 2019 at 08:37:41PM +0300, Dmitry Osipenko wrote:
>>> On ARM32 we don't want any of the clients device to be backed by the
>>> implicit domain, simply because we can't afford such a waste on older
>>> Tegra SoCs that have very few domains available in total. The recent IOMMU
>>> support addition for the Video Decoder hardware uncovered the problem
>>> that an unfortunate drivers probe order results in the DRM driver probe
>>> failure if CONFIG_ARM_DMA_USE_IOMMU=y due to a shortage of IOMMU domains
>>> caused by the implicit backing. The host1x_client_register() is a common
>>> function that is invoked by all of the relevant DRM drivers during theirs
>>> probe and hence it is convenient to remove the implicit backing there,
>>> resolving the problem.
>>>
>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>> ---
>>>  drivers/gpu/host1x/bus.c | 19 +++++++++++++++++++
>>>  1 file changed, 19 insertions(+)
>>
>> I don't really want to do this in a central place like this. If we
>> really do need this, why can't we do it in the individual drivers?
> 
> Why do you want to duplicate the same action for each driver instead of
> doing it in a single common place?
> 
>> we already call host1x_client_iommu_attach() from all the drivers and
>> that detaches from the IOMMU as well. So I'm not sure I understand why
>> this is needed.
> 
> Wish you could ask that couple months ago. I'll try to refresh the details.
> 

In kernel's boot order:

1) Host1x is attached to exclusive implicit domain
2) Host1x is detached from the implicit domain and attached to explicit
3) Both DC's fail to attach to implicit domain because DMA-mapping code
doesn't take into account multiple devices in the same group.
4) GR2D is attached to exclusive implicit domain
5) GR3D is attached to exclusive implicit domain
6) VDE is attached to exclusive implicit domain
7) VDE is detached from the implicit domain and attached to explicit
8) DC client is trying to attach to DRM domain in
host1x_client_iommu_attach() and that fails because tegra-smmu code
allocates ASID in tegra_smmu_attach_dev()->tegra_smmu_as_prepare() (i.e.
on IOMMU group's attaching) and all ASIDs are already busy.

Hence if DRM sub-device drivers are detaching from the implicit domain
on probe, then the problem is getting worked around because there are
available ASIDs at the time of host1x clients initialization.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-10-24 17:09 UTC|newest]

Thread overview: 41+ 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 11:58     ` Thierry Reding
2019-10-24 13:28     ` Dmitry Osipenko
2019-10-24 13:28       ` Dmitry Osipenko
2019-10-24 13:50       ` Thierry Reding
2019-10-24 13:50         ` Thierry Reding
2019-10-24 15:47         ` Dmitry Osipenko
2019-10-24 15:47           ` Dmitry Osipenko
2019-10-24 15:56           ` Thierry Reding
2019-10-24 15:56             ` Thierry Reding
2019-10-24 15:57             ` Dmitry Osipenko
2019-10-24 15:57               ` Dmitry Osipenko
2019-10-24 16:09               ` Dmitry Osipenko
2019-10-24 16:09                 ` Dmitry Osipenko
2019-10-24 16:21                 ` Dmitry Osipenko
2019-10-24 16:21                   ` Dmitry Osipenko
2019-10-24 16:31                   ` Dmitry Osipenko
2019-10-24 16:31                     ` Dmitry Osipenko
2019-10-24 17:28                     ` Thierry Reding
2019-10-24 17:28                       ` Thierry Reding
2019-10-24 18:46                       ` Dmitry Osipenko
2019-10-24 18:46                         ` Dmitry Osipenko
2019-10-25 11:48                         ` Thierry Reding
2019-10-25 11:48                           ` Thierry Reding
2019-10-25 12:35                           ` Dmitry Osipenko
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 11:50   ` Thierry Reding
2019-10-24 13:35   ` Dmitry Osipenko
2019-10-24 13:35     ` Dmitry Osipenko
2019-10-24 13:47     ` Thierry Reding
2019-10-24 13:47       ` Thierry Reding
2019-10-24 17:15       ` Dmitry Osipenko
2019-10-24 17:15         ` Dmitry Osipenko
2019-10-24 17:09     ` Dmitry Osipenko [this message]
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=b8a9fc65-3d2f-8461-e0de-83cbb45fea49@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 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.