From: Robin Murphy <robin.murphy@arm.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: joro <joro@8bytes.org>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
linux-kernel <linux-kernel@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
iommu@lists.linux-foundation.org,
Simon Horman <horms+renesas@verge.net.au>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v7 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access
Date: Thu, 9 Mar 2017 11:40:24 +0000 [thread overview]
Message-ID: <60a12f1e-968d-be3c-babb-5fcf4e18f232@arm.com> (raw)
In-Reply-To: <CANqRtoSE3nE5d9tGWwbowDkFAbXSQRBzjtBoACmR0BwQB5SK-Q@mail.gmail.com>
On 09/03/17 03:44, Magnus Damm wrote:
> Hi Robin,
>
> On Wed, Mar 8, 2017 at 9:48 PM, Robin Murphy <robin.murphy@arm.com> wrote:
>> On 07/03/17 03:17, Magnus Damm wrote:
>>> From: Magnus Damm <damm+renesas@opensource.se>
>>>
>>> Not all architectures have an iommu member in their archdata, so
>>> use #ifdefs support build with COMPILE_TEST on any architecture.
>>
>> I have a feeling I might be repeating myself, but ipmmu_vmsa_archdata
>> looks to be trivially convertible to iommu_fwspec, which I strongly
>> encourage, not least because it would obviate bodges like this.
>
> Yeah, I think it should be possible to use iommu_fwspec for this
> purpose. The question is when to do it. =)
I'd actually be inclined to do it *before* any other major changes, as
it would be pretty minimal given the current structure of the driver.
But then I'm free to wilfully ignore the burden of maintaining patch
stacks between both mainline and older trees ;)
> I actually looked into it recently, but then realised that for this to
> work then due to code sharing I need to make use of iommu_fwspec on
> both 32-bit and 64-bit ARM. So it requires rework of the existing
> IPMMU for 32-bit ARM (including hairy legacy CONFIG_IOMMU_DMA=n code).
> I was actually thinking of doing some rework of 32-bit ARM IPMMU code
> anyway (I suspect iommu_device_* conversion caused breakage) and it
> probably has to happen on top of current -next. I would also like to
> start reducing burden of forward porting all these patches, and
> stirring up the ground does not really help much there...
Note that iommu_fwspec can be used pretty much orthogonally to any of
the core DMA ops support, so it shouldn't be as invasive as you might
think. See 84672f192671 ("iommu/mediatek: Convert M4Uv1 to
iommu_fwspec") as an example of an archdata-to-fwspec conversion of a
driver which only supports 32-bit ARM, and notably borrows its master
handling directly from the the IPMMU driver.
Robin.
>
> Cheers,
>
> / magnus
>
next prev parent reply other threads:[~2017-03-09 11:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-07 3:16 [PATCH v7 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V7 Magnus Damm
2017-03-07 3:16 ` [PATCH v7 01/07] iommu/ipmmu-vmsa: Remove platform data handling Magnus Damm
2017-03-08 9:49 ` Geert Uytterhoeven
2017-03-07 3:17 ` [PATCH v7 02/07] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context Magnus Damm
2017-03-07 3:17 ` [PATCH v7 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code Magnus Damm
2017-03-07 3:17 ` [PATCH v7 04/07] iommu/ipmmu-vmsa: Break out domain allocation code Magnus Damm
2017-03-08 9:51 ` Geert Uytterhoeven
2017-03-07 3:17 ` [PATCH v7 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops Magnus Damm
2017-03-08 13:38 ` Robin Murphy
2017-03-22 14:25 ` Joerg Roedel
2017-03-07 3:17 ` [PATCH v7 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access Magnus Damm
2017-03-08 9:55 ` Geert Uytterhoeven
2017-03-08 12:48 ` Robin Murphy
2017-03-09 3:44 ` Magnus Damm
2017-03-09 11:40 ` Robin Murphy [this message]
2017-03-07 3:17 ` [PATCH v7 07/07] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency Magnus Damm
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=60a12f1e-968d-be3c-babb-5fcf4e18f232@arm.com \
--to=robin.murphy@arm.com \
--cc=geert+renesas@glider.be \
--cc=horms+renesas@verge.net.au \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=magnus.damm@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