[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1502980248.19806.29.camel@pengutronix.de>
Date: Thu, 17 Aug 2017 16:30:48 +0200
From: Lucas Stach <l.stach@...gutronix.de>
To: Joerg Roedel <joro@...tes.org>
Cc: Joerg Roedel <jroedel@...e.de>, iommu@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org,
Suravee Suthikulpanit <Suravee.Suthikulpanit@....com>,
Russell King <linux+etnaviv@...linux.org.uk>,
Christian Gmeiner <christian.gmeiner@...il.com>,
David Airlie <airlied@...ux.ie>, etnaviv@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 06/13] drm/etnaviv: Use sychronized interface of the
IOMMU-API
Am Donnerstag, den 17.08.2017, 16:18 +0200 schrieb Joerg Roedel:
> On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote:
> > There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API
> > to manage the GPU internal MMU, see
> > drivers/gpu/drm/etnaviv/etnaviv_iommu.c
>
> That looks like a very fragile construct, because it relies on internal
> behavior of the iommu code that can change in the future.
>
> I strongly suggest to either make etnaviv_iommu.c a real iommu driver an
> move it to drivers/iommu, or (prefered by me) just call directly into
> the map/unmap functions of this driver from the rest of the
> etnaviv_iommu.c. I don't really see a reason why the IOMMU-API needs to
> be used there as another layer of indirection.
Yeah, the IOMMU API being used internally is a historical accident, that
we didn't get around to rectify yet. It's on my things-we-need-to-do
list to prune the usage of the IOMMU API in etnaviv.
Regards,
Lucas
Powered by blists - more mailing lists