linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Mikko Perttunen <cyndis@kapsi.fi>,
	Thierry Reding <thierry.reding@gmail.com>,
	Mikko Perttunen <mperttunen@nvidia.com>
Cc: linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 00/13] drm/tegra: Fix IOVA space on Tegra186 and later
Date: Fri, 25 Jan 2019 16:18:10 +0300	[thread overview]
Message-ID: <4aec3e32-e23e-4b57-4875-e273576d48fb@gmail.com> (raw)
In-Reply-To: <b62ff60c-6c71-78bb-7ecb-c69d58492e9b@kapsi.fi>

25.01.2019 11:57, Mikko Perttunen пишет:
> On 24.1.2019 23.53, Dmitry Osipenko wrote:
>> 24.01.2019 21:02, Thierry Reding пишет:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> Tegra186 and later are different from earlier generations in that they
>>> use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves
>>> slightly differently in that the geometry for IOMMU domains is set only
>>> after a device was attached to it. This is to make sure that the SMMU
>>> instance that the domain belongs to is known, because each instance can
>>> have a different input address space (i.e. geometry).
>>>
>>> Work around this by moving all IOVA allocations to a point where the
>>> geometry of the domain is properly initialized.
>>>
>>> This second version of the series addresses all review comments and adds
>>> a number of patches that will actually allow host1x to work with an SMMU
>>> enabled on Tegra186. The patches also add programming required to
>>> address the full 40 bits of address space.
>>>
>>> This supersedes the following patch:
>>>
>>>      https://patchwork.kernel.org/patch/10775579/
>>
>> Secondly, seems there are additional restrictions for the host1x jobs on T186, at least T186 TRM suggests so. In particular looks like each client is hardwired to a specific sync point and to a specific channel. Or maybe there is assumption that upstream kernel could work only in a hypervisor mode or with all protections disable. Could you please clarify?
>>
> 
> There are no such syncpoint/channel restrictions. The upstream driver indeed currently only supports the case where there is no "hypervisor" (that is, server process that allocates host1x resources) running and the kernel has access to the Host1x COMMON/"hypervisor" register aperture.
> 
> Adding support for the situation where this is not the case shouldn't be very difficult, but we currently don't have any upstream platforms where the Host1x server exists (it's only there on automotive platforms).

Thank you very much for the clarification!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2019-01-25 13:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-24 18:02 [PATCH v2 00/13] drm/tegra: Fix IOVA space on Tegra186 and later Thierry Reding
2019-01-24 18:02 ` [PATCH v2 01/13] gpu: host1x: Set up stream ID table Thierry Reding
2019-01-24 18:02 ` [PATCH v2 02/13] gpu: host1x: Program the channel stream ID Thierry Reding
2019-01-24 18:02 ` [PATCH v2 03/13] gpu: host1x: Support 40-bit addressing Thierry Reding
2019-01-25  9:13   ` Mikko Perttunen
2019-01-25  9:20     ` Thierry Reding
2019-01-25  9:32       ` Mikko Perttunen
2019-01-25  9:34         ` Mikko Perttunen
2019-01-24 18:02 ` [PATCH v2 04/13] gpu: host1x: Use direct DMA with IOMMU API usage Thierry Reding
2019-01-28 14:30   ` Dmitry Osipenko
2019-01-24 18:02 ` [PATCH v2 05/13] gpu: host1x: Restrict IOVA space to DMA mask Thierry Reding
2019-01-24 18:02 ` [PATCH v2 06/13] gpu: host1x: Support 40-bit addressing on Tegra186 Thierry Reding
2019-01-24 18:02 ` [PATCH v2 07/13] drm/tegra: Store parent pointer in Tegra DRM clients Thierry Reding
2019-01-28 14:10   ` Dmitry Osipenko
2019-01-24 18:02 ` [PATCH v2 08/13] drm/tegra: vic: Load firmware on demand Thierry Reding
2019-01-28 14:12   ` Dmitry Osipenko
2019-01-24 18:02 ` [PATCH v2 09/13] drm/tegra: Setup shared IOMMU domain after initialization Thierry Reding
2019-01-24 18:02 ` [PATCH v2 10/13] drm/tegra: Restrict IOVA space to DMA mask Thierry Reding
2019-01-24 18:02 ` [PATCH v2 11/13] drm/tegra: vic: Do not clear driver data Thierry Reding
2019-01-24 18:02 ` [PATCH v2 12/13] drm/tegra: vic: Support stream ID register programming Thierry Reding
2019-01-24 18:02 ` [PATCH v2 13/13] arm64: tegra: Enable SMMU for VIC on Tegra186 Thierry Reding
2019-01-24 21:38 ` [PATCH v2 00/13] drm/tegra: Fix IOVA space on Tegra186 and later Dmitry Osipenko
2019-01-25  9:23   ` Thierry Reding
2019-01-25 13:14     ` Dmitry Osipenko
2019-01-24 21:53 ` Dmitry Osipenko
2019-01-25  8:57   ` Mikko Perttunen
2019-01-25 13:18     ` Dmitry Osipenko [this message]

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=4aec3e32-e23e-4b57-4875-e273576d48fb@gmail.com \
    --to=digetx@gmail.com \
    --cc=cyndis@kapsi.fi \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mperttunen@nvidia.com \
    --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).