Linux Samsung SOC development
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: iommu@lists.linux.dev, linux-samsung-soc@vger.kernel.org,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	lim Akhtar <alim.akhtar@samsung.com>,
	Lu Baolu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH] iommu/exynos: add missing set_platform_dma_ops callback
Date: Mon, 20 Feb 2023 13:58:40 +0000	[thread overview]
Message-ID: <9a12fcac-c347-5d81-acef-1124c50d0c37@arm.com> (raw)
In-Reply-To: <Y+90rkPHe/+eSLs6@ziepe.ca>

On 2023-02-17 12:35, Jason Gunthorpe wrote:
> On Fri, Feb 17, 2023 at 12:08:42PM +0100, Marek Szyprowski wrote:
>> Hi,
>>
>> I'm sorry for a delay in replying, but I was busy with other stuff.
>>
>> On 23.01.2023 22:00, Jason Gunthorpe wrote:
>>> On Mon, Jan 23, 2023 at 10:31:01AM +0100, Marek Szyprowski wrote:
>>>> Add set_platform_dma_ops() required for proper driver operation on ARM
>>>> 32bit arch after recent changes in the IOMMU framework (detach ops
>>>> removal).
>>> Thanks for looking into this!
>>>
>>> Can you explain more about how this actually solves the problem in the
>>> commit message? I don't get it.
>>
>> Exynos DRM driver calls arm_iommu_detach_device(), then
>> arm_iommu_attach_device() with a difrent 'mapping', see
>> drivers/gpu/drm/exynos/exynos_drm_dma.c Lack of set_platform_dma_ops
>> leads to a warning in iommu_group_do_set_platform_dma(). The other case
>> of calling arm_iommu_detach_device() is after unsuccessful probe of the
>> platform device.
> 
> Why can't this just use the normal iommu path in all cases?
> 
> It looks like it is trying to copy the DMA API domain from a parent
> device to a sub device.
> 
> Even when using arm_iommu an iommu_domain is still present, so the
> copy code should work?

The ARM DMA domain is a regular unmanaged domain owned by the ARM DMA 
code - in order to use any *other* domain, a user has to detach from 
that first (wrapped up in arm_iommu_detach_device() which also swizzles 
the DMA ops at the same time). Without set_platform_dma, that detach is 
now impossible (because no IOMMU API default domain exists either).

> Though I'm still not really sure how this arm_iommu stuff works..
> 
> eg if a driver does iommu_device_claim_dma_owner() how does the
> iommu_domain get set back to the arm_iommu's mapping's iommu_domain?

It doesn't. Fact is that VFIO has only ever worked on Arm with arm-smmu 
and its old deprecated DT bindings which don't interact with any of the 
DMA ops stuff. And ownership has always been inherently enforced here 
since the DMA ops are just another external user from the IOMMU API's PoV.

> According to the API that is what set_platform is supposed to do (eg
> it is what s390 does), but I don't see any code like that in any of
> the ARM32 drivers..

As above, it's in the relevant users, not the drivers. For what you're 
thinking of, the "platform" state is only ever transient.

(for the purposes of this discussion, ignore the MTK and Renesas drivers 
bodging around to implement pseudo-default-domain support on *top* of 
the user-centric arm_iommu_* APIs; that's a whole other mess to unravel)

Thanks,
Robin.

  reply	other threads:[~2023-02-20 13:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230123093116eucas1p19b8fe8afc4b631debbdc5321c53009e9@eucas1p1.samsung.com>
2023-01-23  9:31 ` [PATCH] iommu/exynos: add missing set_platform_dma_ops callback Marek Szyprowski
2023-01-23 21:00   ` Jason Gunthorpe
2023-02-17 11:08     ` Marek Szyprowski
2023-02-17 11:18       ` Baolu Lu
2023-02-17 12:35       ` Jason Gunthorpe
2023-02-20 13:58         ` Robin Murphy [this message]
2023-04-06 23:37           ` Jason Gunthorpe
2023-04-12 22:03             ` Marek Szyprowski
2023-04-12 22:40               ` Jason Gunthorpe
2023-02-03  9:41   ` Joerg Roedel

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=9a12fcac-c347-5d81-acef-1124c50d0c37@arm.com \
    --to=robin.murphy@arm.com \
    --cc=alim.akhtar@samsung.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.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