iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>,
	hch@lst.de, joro@8bytes.org, linux@armlinux.org.uk
Cc: geert+renesas@glider.be, dri-devel@lists.freedesktop.org,
	matthias.bgg@gmail.com, thierry.reding@gmail.com,
	laurent.pinchart@ideasonboard.com, will@kernel.org,
	linux-samsung-soc@vger.kernel.org, magnus.damm@gmail.com,
	kyungmin.park@samsung.com, jonathanh@nvidia.com,
	agross@kernel.org, linux-media@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, inki.dae@samsung.com,
	linux-mediatek@lists.infradead.org, linux-tegra@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, sw0312.kim@samsung.com,
	linux-kernel@vger.kernel.org, t-kristo@ti.com,
	iommu@lists.linux-foundation.org
Subject: Re: [PATCH 16/18] staging/media/tegra-vde: Clean up IOMMU workaround
Date: Thu, 27 Aug 2020 10:05:14 +0300	[thread overview]
Message-ID: <f1923a53-e799-e63c-fd22-4a6cca3b8212@gmail.com> (raw)
In-Reply-To: <affe2cfb-19e8-8e55-acd0-7170e274ab34@arm.com>

24.08.2020 17:01, Robin Murphy пишет:
...
>> Robin, thank you very much for the clarifications!
>>
>> In accordance to yours comments, this patch can't be applied until Tegra
>> SMMU will support IOMMU_DOMAIN_IDENTITY and implement def_domain_type()
>> callback that returns IOMMU_DOMAIN_IDENTITY for the VDE device.
>>
>> Otherwise you're breaking the VDE driver because
>> dma_buf_map_attachment() [1] returns the IOMMU SGT of the implicit
>> domain which is then mapped into the VDE's explicit domain [2], and this
>> is a nonsense.
> 
> It's true that iommu_dma_ops will do some work in the unattached default
> domain, but non-coherent cache maintenance will still be performed
> correctly on the underlying memory, which is really all that you care
> about for this case. As for tegra_vde_iommu_map(), that seems to do the
> right thing in only referencing the physical side of the scatterlist
> (via iommu_map_sg()) and ignoring the DMA side, so things ought to work
> out OK even if it is a little non-obvious.

I'll need to double-check this, it's indeed not clear to me right now.

I see that if Tegra DRM driver uses implicit IOMMU domain, then when VDE
driver imports DMA-buf from Terga DRM and the imported buffer will be
auto-mapped to the implicit VDE IOVA [1].

[1]
https://elixir.bootlin.com/linux/v5.9-rc2/source/drivers/gpu/drm/tegra/gem.c#L574

>> Hence, either VDE driver should bypass iommu_dma_ops from the start or
>> it needs a way to kick out the ops, like it does this using ARM's
>> arm_iommu_detach_device().
>>
>>
>> The same applies to the Tegra GPU devices, otherwise you're breaking
>> them as well because Tegra DRM is sensible to implicit vs explicit
>> domain.
> 
> Note that Tegra DRM will only be as broken as its current state on
> arm64, and I was under the impression that that was OK now - at least I
> don't recall seeing any complaints since 43c5bf11a610. Although that
> commit and the one before it are resolving the scalability issue that
> they describe, it was very much in my mind at the time that they also
> have the happy side-effect described above - the default domain isn't
> *completely* out of the way, but it's far enough that sensible cases
> should be able to work as expected.

The Tegra DRM has a very special quirk for ARM32 that was added in this
commit [2] and driver relies on checking of whether explicit or implicit
IOMMU is used in order to activate the quirk.

[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273da5a046965ccf0ec79eb63f2d5173467e20fa

Once the implicit IOMMU is used for the DRM driver, the quirk no longer
works (if I'm not missing something). This problem needs to be resolved
before implicit IOMMU could be used by the Tegra DRM on ARM32.

>> BTW, I tried to apply this series and T30 doesn't boot anymore. I don't
>> have more info for now.
> 
> Yeah, I'm still trying to get to the bottom of whether it's actually
> working as intended at all, even on my RK3288. So far my debugging
> instrumentation has been confusingly inconclusive :/

Surely it will take some time to resolve all the problems and it's great
that you're pushing this work!

I'll try to help with fixing the ARM32 Tegra side of the problems. I
added this to my "TODO" list and should be able to take a closer look
during of this/next weeks!
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-08-27  7:05 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200820150857eucas1p18f5f2ad87703a68b6ed20a090f7c1c57@eucas1p1.samsung.com>
2020-08-20 15:08 ` [PATCH 00/18] Convert arch/arm to use iommu-dma Robin Murphy
2020-08-20 15:08   ` [PATCH 01/18] ARM/dma-mapping: Drop .dma_supported for IOMMU ops Robin Murphy
2020-08-20 15:08   ` [PATCH 02/18] ARM/dma-mapping: Consolidate IOMMU ops callbacks Robin Murphy
2020-08-20 15:08   ` [PATCH 03/18] ARM/dma-mapping: Merge IOMMU ops Robin Murphy
2020-08-20 15:08   ` [PATCH 04/18] iommu/dma: Add temporary hacks for arch/arm Robin Murphy
2020-08-20 15:08   ` [PATCH 05/18] ARM/dma-mapping: Switch to iommu_dma_ops Robin Murphy
2020-09-28 11:32     ` Marek Szyprowski
2020-08-20 15:08   ` [PATCH 06/18] ARM/dma-mapping: Support IOMMU default domains Robin Murphy
2020-08-20 15:08   ` [PATCH 07/18] iommu/arm-smmu: Remove arch/arm workaround Robin Murphy
2020-08-21  8:07     ` Will Deacon
2020-08-20 15:08   ` [PATCH 08/18] iommu/renesas: " Robin Murphy
2020-08-20 15:08   ` [PATCH 09/18] iommu/mediatek-v1: Add IOMMU_DOMAIN_DMA support Robin Murphy
2020-08-29  9:54     ` Yong Wu
2020-08-20 15:08   ` [PATCH 10/18] iommu/msm: " Robin Murphy
2020-08-20 15:55     ` Rob Clark
2020-08-20 16:58       ` Robin Murphy
2020-08-20 17:05         ` Rob Clark
2020-08-20 15:08   ` [PATCH 11/18] iommu/omap: " Robin Murphy
2020-08-24 21:39     ` Suman Anna via iommu
2020-08-20 15:08   ` [PATCH 12/18] iommu/tegra-gart: " Robin Murphy
2020-08-20 20:16     ` Dmitry Osipenko
2020-08-21  0:28       ` Robin Murphy
2020-08-23 21:42         ` Dmitry Osipenko
2020-08-20 15:08   ` [PATCH 13/18] iommu/tegra: " Robin Murphy
2020-08-27 15:45     ` Thierry Reding
2020-08-27 18:18       ` Robin Murphy
2020-08-20 15:08   ` [PATCH 14/18] drm/exynos: Consolidate IOMMU mapping code Robin Murphy
2020-09-18 14:30     ` Marek Szyprowski
2020-09-21  2:09     ` Inki Dae
2020-08-20 15:08   ` [PATCH 15/18] drm/nouveau/tegra: Clean up IOMMU workaround Robin Murphy
2020-08-20 15:08   ` [PATCH 16/18] staging/media/tegra-vde: " Robin Murphy
2020-08-20 19:51     ` Dmitry Osipenko
2020-08-20 20:10       ` Dmitry Osipenko
2020-08-21  0:11       ` Robin Murphy
2020-08-23 21:34         ` Dmitry Osipenko
2020-08-24 14:01           ` Robin Murphy
2020-08-27  7:05             ` Dmitry Osipenko [this message]
2020-08-27 15:54               ` Thierry Reding
2020-08-30 19:44                 ` Dmitry Osipenko
2020-08-20 15:08   ` [PATCH 17/18] media/omap3isp: " Robin Murphy
2020-08-20 16:53     ` Sakari Ailus
2020-08-20 17:25       ` Robin Murphy
2020-08-20 19:55         ` Sakari Ailus
2020-08-20 23:01           ` Robin Murphy
2020-08-24 21:55             ` Suman Anna via iommu
2020-08-20 15:08   ` [PATCH 18/18] ARM/dma-mapping: Remove legacy dma-iommu API Robin Murphy
2020-08-24 11:40   ` [PATCH 00/18] Convert arch/arm to use iommu-dma Marek Szyprowski
2020-09-18 15:13     ` Marek Szyprowski
2020-08-27 12:31   ` Aw: " Frank Wunderlich
2020-08-27 12:54     ` Matthias Brugger

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=f1923a53-e799-e63c-fd22-4a6cca3b8212@gmail.com \
    --to=digetx@gmail.com \
    --cc=agross@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert+renesas@glider.be \
    --cc=hch@lst.de \
    --cc=inki.dae@samsung.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=matthias.bgg@gmail.com \
    --cc=robin.murphy@arm.com \
    --cc=sw0312.kim@samsung.com \
    --cc=t-kristo@ti.com \
    --cc=thierry.reding@gmail.com \
    --cc=will@kernel.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).