Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752939AbdHQOax (ORCPT ); Thu, 17 Aug 2017 10:30:53 -0400 Received: from metis.ext.4.pengutronix.de ([92.198.50.35]:33515 "EHLO metis.ext.4.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752821AbdHQOav (ORCPT ); Thu, 17 Aug 2017 10:30:51 -0400 Message-ID: <1502980248.19806.29.camel@pengutronix.de> Subject: Re: [PATCH 06/13] drm/etnaviv: Use sychronized interface of the IOMMU-API From: Lucas Stach To: Joerg Roedel Cc: Joerg Roedel , iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Suravee Suthikulpanit , Russell King , Christian Gmeiner , David Airlie , etnaviv@lists.freedesktop.org, dri-devel@lists.freedesktop.org Date: Thu, 17 Aug 2017 16:30:48 +0200 In-Reply-To: <20170817141858.GG16908@8bytes.org> References: <1502974596-23835-1-git-send-email-joro@8bytes.org> <1502974596-23835-7-git-send-email-joro@8bytes.org> <1502976758.19806.25.camel@pengutronix.de> <20170817134539.GJ2853@suse.de> <1502978634.19806.27.camel@pengutronix.de> <20170817141858.GG16908@8bytes.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:fa0f:41ff:fe58:4010 X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 974 Lines: 22 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