From patchwork Tue Jul 8 16:22:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Suman Anna X-Patchwork-Id: 4506571 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 4CC85BEEAA for ; Tue, 8 Jul 2014 16:23:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6ABC3202F8 for ; Tue, 8 Jul 2014 16:23:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8199B201F5 for ; Tue, 8 Jul 2014 16:23:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298AbaGHQW4 (ORCPT ); Tue, 8 Jul 2014 12:22:56 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:36203 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755050AbaGHQWy (ORCPT ); Tue, 8 Jul 2014 12:22:54 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id s68GMTPM007048; Tue, 8 Jul 2014 11:22:29 -0500 Received: from DLEE71.ent.ti.com (dlee71.ent.ti.com [157.170.170.114]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id s68GMTLe028470; Tue, 8 Jul 2014 11:22:29 -0500 Received: from dlep32.itg.ti.com (157.170.170.100) by DLEE71.ent.ti.com (157.170.170.114) with Microsoft SMTP Server id 14.3.174.1; Tue, 8 Jul 2014 11:22:29 -0500 Received: from legion.dal.design.ti.com (legion.dal.design.ti.com [128.247.22.53]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id s68GMTAa025714; Tue, 8 Jul 2014 11:22:29 -0500 Received: from localhost (irmo.am.dhcp.ti.com [128.247.71.175]) by legion.dal.design.ti.com (8.11.7p1+Sun/8.11.7) with ESMTP id s68GMTt03859; Tue, 8 Jul 2014 11:22:29 -0500 (CDT) From: Suman Anna To: Ohad Ben-Cohen CC: Dave Gerlach , =?UTF-8?q?Sjur=20Br=C3=A6ndeland?= , , , , Suman Anna , Robert Tivy Subject: [PATCH 1/2] remoteproc: use a flag to detect the presence of IOMMU Date: Tue, 8 Jul 2014 11:22:00 -0500 Message-ID: <1404836521-59637-2-git-send-email-s-anna@ti.com> X-Mailer: git-send-email 2.0.0 In-Reply-To: <1404836521-59637-1-git-send-email-s-anna@ti.com> References: <1404836521-59637-1-git-send-email-s-anna@ti.com> MIME-Version: 1.0 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The remoteproc driver core currently relies on iommu_present() on the bus the device is on, to perform MMU management. However, this logic doesn't scale for multi-arch, especially for processors that do not have an IOMMU. Replace this logic instead by using a h/w capability flag for the presence of IOMMU in the rproc structure. The individual platform implementations are required to set this flag appropriately. The default setting is to not have an MMU. The OMAP remoteproc driver is updated while at this, to maintain the functionality with the IOMMU detection logic change in this patch. Cc: Sjur Brændeland Cc: Robert Tivy Signed-off-by: Suman Anna --- drivers/remoteproc/omap_remoteproc.c | 6 ++++++ drivers/remoteproc/remoteproc_core.c | 15 ++------------- include/linux/remoteproc.h | 2 ++ 3 files changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c index 5168972..858abf0 100644 --- a/drivers/remoteproc/omap_remoteproc.c +++ b/drivers/remoteproc/omap_remoteproc.c @@ -199,6 +199,12 @@ static int omap_rproc_probe(struct platform_device *pdev) oproc = rproc->priv; oproc->rproc = rproc; + /* + * All existing OMAP IPU and DSP processors do have an MMU, and + * are expected to use MMU, so this statement suffices. + * XXX: Replace this logic if and when a need arises. + */ + rproc->has_iommu = true; platform_set_drvdata(pdev, rproc); diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index 3cd85a6..11cdb11 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -94,19 +94,8 @@ static int rproc_enable_iommu(struct rproc *rproc) struct device *dev = rproc->dev.parent; int ret; - /* - * We currently use iommu_present() to decide if an IOMMU - * setup is needed. - * - * This works for simple cases, but will easily fail with - * platforms that do have an IOMMU, but not for this specific - * rproc. - * - * This will be easily solved by introducing hw capabilities - * that will be set by the remoteproc driver. - */ - if (!iommu_present(dev->bus)) { - dev_dbg(dev, "iommu not found\n"); + if (!rproc->has_iommu) { + dev_dbg(dev, "iommu not present\n"); return 0; } diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h index 9e7e745..78b8a9b 100644 --- a/include/linux/remoteproc.h +++ b/include/linux/remoteproc.h @@ -404,6 +404,7 @@ enum rproc_crash_type { * @table_ptr: pointer to the resource table in effect * @cached_table: copy of the resource table * @table_csum: checksum of the resource table + * @has_iommu: flag to indicate if remote processor is behind an MMU */ struct rproc { struct klist_node node; @@ -435,6 +436,7 @@ struct rproc { struct resource_table *table_ptr; struct resource_table *cached_table; u32 table_csum; + bool has_iommu; }; /* we currently support only two vrings per rvdev */