Received: by 10.223.176.5 with SMTP id f5csp1391428wra; Wed, 31 Jan 2018 05:52:04 -0800 (PST) X-Google-Smtp-Source: AH8x224Pr9xDoMEe8LBKYtuKzvFkZMnPa2vh9TWywNyLHxxjCu+sdC4BU6Pe5k7WKjDrKGL8DtZy X-Received: by 2002:a17:902:e65:: with SMTP id 92-v6mr26165087plw.148.1517406724295; Wed, 31 Jan 2018 05:52:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517406724; cv=none; d=google.com; s=arc-20160816; b=pyh+r+xGPsvS+xkW/xVPr8YQEXKl0rcB00rraLWMqsHUhoy3pskCPAeYLjUlLJ0PEL Lv3lBeInSxfaLRsrBCfAiJail1kG9/jIgRYVN34iSMLQRQ3uGQkoH9w9wTIXqOL9DZdR HjpStYJT1wzl9Iv7QpnmiF0ownMwbHx4NkXh7Q5r7Q48jt466DXahGfO9XlVhUtXWHKI 0tsRSs+tRc936FHmjSmoAOwMaEgOO30pnVCNcfP+S4f0TDRae5Xt0jAJtP4GCXKZRUsn 12EdqlnkPhQjf9hrRoF9I14yxv3bCAA6hqTXKoicTWelvb53pD2OqU2oXwagTe6CBEX3 8QpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dmarc-filter :arc-authentication-results; bh=T+R1b2sikv1mOoEdhqlavQ4ZHfpcEkV9Dz0Rhyw8n2U=; b=eWFpR+Jyz1KzNqSMT7AUxY6r92MYX8YMZz4StQmtV80AxSN0AUejtLrl05u67lzKYU KLtgULwumIJbmrhIYvYuxx+nQzKMpZqNoXFqFP1nr0GRa7MS4hg/2las3flJ+xa8bxhv azLmMQavBTyxG2g7CHCcK4pSaLEvBqocpaRaSs3XAgwQ3KT0dVFrXmy5UjkVr7XIn1Ru Kjb86fOpKYRSkiVgv4JMCzRdaIrk3Dv2q9u+2xCnVM6IgY7RCPn7yE7L82IhbTYaWS2P NUjiK56XnPltCbmNb4jT7VKS0WPNXbSNGmqRInTVFc+juacRKV16CLPwJIscWzNCkbo0 OVWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e68si4472775pfa.298.2018.01.31.05.51.50; Wed, 31 Jan 2018 05:52:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752543AbeAaNvX (ORCPT + 99 others); Wed, 31 Jan 2018 08:51:23 -0500 Received: from mail.kernel.org ([198.145.29.99]:46060 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751587AbeAaNvV (ORCPT ); Wed, 31 Jan 2018 08:51:21 -0500 Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E085721798; Wed, 31 Jan 2018 13:51:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E085721798 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh@kernel.org Received: by mail-qt0-f179.google.com with SMTP id s39so21848450qth.7; Wed, 31 Jan 2018 05:51:20 -0800 (PST) X-Gm-Message-State: AKwxytfHtOx1QOxU82NOyUsuDYdZvB9lV3SyuEj4scSSx4glkA7JiVE8 6zmnwi7e5V0g7fRHHVZ0nGjzGU8aMJ7EILkB2A== X-Received: by 10.200.26.69 with SMTP id q5mr49445272qtk.174.1517406679983; Wed, 31 Jan 2018 05:51:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.20 with HTTP; Wed, 31 Jan 2018 05:50:59 -0800 (PST) In-Reply-To: References: <20180124103516.2571-1-jeffy.chen@rock-chips.com> <20180124103516.2571-9-jeffy.chen@rock-chips.com> <20180130170515.3g6wtadqgmehxh5b@rob-hp-laptop> From: Rob Herring Date: Wed, 31 Jan 2018 07:50:59 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU To: Tomasz Figa Cc: Jeffy Chen , "linux-kernel@vger.kernel.org" , Ricky Liang , Robin Murphy , simon xue , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Heiko Stuebner , "open list:ARM/Rockchip SoC..." , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Mark Rutland , Joerg Roedel , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 31, 2018 at 1:52 AM, Tomasz Figa wrote: > Hi Rob, > > On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring wrote: >> On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote: >>> From: Tomasz Figa >>> >>> Current code relies on master driver enabling necessary clocks before >>> IOMMU is accessed, however there are cases when the IOMMU should be >>> accessed while the master is not running yet, for example allocating >>> V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA >>> mapping API and doesn't engage the master driver at all. >>> >>> This patch fixes the problem by letting clocks needed for IOMMU >>> operation to be listed in Device Tree and making the driver enable them >>> for the time of accessing the hardware. >>> >>> Signed-off-by: Jeffy Chen >>> Signed-off-by: Tomasz Figa >>> --- >>> >>> Changes in v5: >>> Use clk_bulk APIs. >>> >>> Changes in v4: None >>> Changes in v3: None >>> Changes in v2: None >>> >>> .../devicetree/bindings/iommu/rockchip,iommu.txt | 8 +++ >> >> Please split binding patches to a separate patch. >> >>> drivers/iommu/rockchip-iommu.c | 74 ++++++++++++++++++++-- >>> 2 files changed, 76 insertions(+), 6 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt >>> index 2098f7732264..33dd853359fa 100644 >>> --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt >>> +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt >>> @@ -14,6 +14,13 @@ Required properties: >>> "single-master" device, and needs no additional information >>> to associate with its master device. See: >>> Documentation/devicetree/bindings/iommu/iommu.txt >>> +Optional properties: >>> +- clocks : A list of master clocks requires for the IOMMU to be accessible >>> + by the host CPU. The number of clocks depends on the master >>> + block and might as well be zero. See [1] for generic clock >>> + bindings description. >> >> Hardware blocks don't have a variable number of clock connections. > > I think you underestimate the imagination of hardware designers. :) Learned long ago to never do that. If there are 2 ways to do something, they will find a 3rd way. > For Rockchip IOMMU, there is a set of clocks, which all need to be > enabled for IOMMU register access to succeed. The clocks are not > directly fed to the IOMMU, but they are needed for the various buses > and intermediate blocks on the way to the IOMMU to work. The binding should describe the clock connections, not what clocks a driver needs (currently). It sounds like a lack of managing bus clocks to me. In any case, the binding must be written so it can be verified. If you can have any number of clocks with any names, there's no point in documenting. Rob