Received: by 10.223.185.116 with SMTP id b49csp483695wrg; Wed, 14 Feb 2018 02:05:56 -0800 (PST) X-Google-Smtp-Source: AH8x226eF7r2RgoHGIIRzW7S3jz9DEUC72kzbjp3pSRsvGUA4gpswJBB92Sz811p2nV/y1dDDgRn X-Received: by 10.99.151.74 with SMTP id d10mr3459215pgo.258.1518602756421; Wed, 14 Feb 2018 02:05:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518602756; cv=none; d=google.com; s=arc-20160816; b=OM/vD9CfaakEwf85SxKs2+doVGIqdsy8ur2smsAPXraG/dN3ptAnys/++Q5199qS1s 7dabex6GTuymQ/olhui5+h2pds4tiz2KFEL08cUTtl0vRq336xoquvOKHSFR9ojamYyt SKyxLt01zpPbk5bzzkW/rgwjocnwFdMXTrfhv2K3ixvE+RVrnvYTIC3OMWyssZbGP4GE McGK3eF+fqa12tPaPL4XDXtS1fziL5VMrDY2V5eM/7Wkiy0w86pwMIO8U57SmFaJARLQ Hr4uGPKZ95Ti2up+gYQJJa0furB/dzcGg+7YcdVf1C8zQVaHBRrs+w4HzQKWaqK1hqHD Y0GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=5y3GwFwarB0SlKoKoBTRCUZqGL9TUXdpIk9UX072BFA=; b=KfoYdmuAgBad7Hf2/HBgbPV5aUMYGam8Zzp9Kb79jyoK02YNFRXn3xsQ8ISx2TTc+5 6B3YGmoWrMfdk/4M4JvVStx72fPN0ABD0PVvUPNP2dGXYUbGQ1lt3c4HFohF8XnIade0 Kss80xP4d65JfCr1Y4cU4+0UmSr4LGla/YJgz3ilbtzayKAXkCWO3tJ9jDkHLzZHQTKn Jyd4Ky9m8nTwE53rUkeHsspzgOTMcd7ttzTUkLnEZufiHfL+5fhoJ1HMEWlPVN+N41a5 dgRIBzS3A0zeyM4twgel6XaYR9mmE9YSknTW3OdEG6sEgVI+W5BAMTl3mpobg5saIw1e frKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=S7/5RojX; dkim=pass header.i=@codeaurora.org header.s=default header.b=bX7aC49u; 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 t128si2011135pgc.600.2018.02.14.02.05.40; Wed, 14 Feb 2018 02:05:56 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=S7/5RojX; dkim=pass header.i=@codeaurora.org header.s=default header.b=bX7aC49u; 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 S966997AbeBNKEE (ORCPT + 99 others); Wed, 14 Feb 2018 05:04:04 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:58868 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966706AbeBNKEC (ORCPT ); Wed, 14 Feb 2018 05:04:02 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 0496460F6D; Wed, 14 Feb 2018 10:04:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518602642; bh=QHIlUzct4p5E9v4Xrr+53JTOqZlk4G1HWU50gQjQgGc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=S7/5RojX8nM4qt5BVHggpa39PKBk60Dnd9pickMrqSyupZxYr/EtWhvcmZMEUG9ac 1+fZtgHFPAKNlWwXhxYrRNrQo7zoJo8ENzoIbJrBfMbEouSLXV8GsaBuKuaBOyb4XT Ur3EcPf8/IDZxIJFkWbb9mYN5/pzbgjWFSItMW2k= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.79.40.112] (blr-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.18.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: vivek.gautam@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id AA98060791; Wed, 14 Feb 2018 10:03:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518602641; bh=QHIlUzct4p5E9v4Xrr+53JTOqZlk4G1HWU50gQjQgGc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bX7aC49uiWMVVMCWWkArbgi4pZzMRL2vZhx3ic7/f6i+aYFoemDmMDs/KpUlaS3+4 Kb6RRnWVbOhSblmZdko27GK2IRaYdTbyDb8XcrFwB+EhWqi8pxduq72b37U8t2GznK r8p60lJBHrqsW6XxGMHlqo3EzP/F8LszbEY4TWRQ= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org AA98060791 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=vivek.gautam@codeaurora.org Subject: Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU To: Robin Murphy , Jeffy Chen , linux-kernel@vger.kernel.org Cc: Mark Rutland , devicetree@vger.kernel.org, Heiko Stuebner , jcliang@chromium.org, linux-rockchip@lists.infradead.org, iommu@lists.linux-foundation.org, Rob Herring , linux-arm-kernel@lists.infradead.org References: <20180124103516.2571-1-jeffy.chen@rock-chips.com> <20180124103516.2571-9-jeffy.chen@rock-chips.com> From: Vivek Gautam Message-ID: Date: Wed, 14 Feb 2018 15:33:56 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/24/2018 7:19 PM, Robin Murphy wrote: > On 24/01/18 10:35, 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 [snip] >>   +static int rk_iommu_of_get_clocks(struct rk_iommu *iommu) >> +{ >> +    struct device_node *np = iommu->dev->of_node; >> +    int ret; >> +    int i; >> + >> +    ret = of_count_phandle_with_args(np, "clocks", "#clock-cells"); >> +    if (ret == -ENOENT) >> +        return 0; >> +    else if (ret < 0) >> +        return ret; >> + >> +    iommu->num_clocks = ret; >> +    iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks, >> +                     sizeof(*iommu->clocks), GFP_KERNEL); >> +    if (!iommu->clocks) >> +        return -ENOMEM; >> + >> +    for (i = 0; i < iommu->num_clocks; ++i) { >> +        iommu->clocks[i].clk = of_clk_get(np, i); >> +        if (IS_ERR(iommu->clocks[i].clk)) { >> +            ret = PTR_ERR(iommu->clocks[i].clk); >> +            goto err_clk_put; >> +        } >> +    } > > Just to confirm my understanding from a quick scan through the code, > the reason we can't use clk_bulk_get() here is that currently, > clocks[i].id being NULL means we'd end up just getting the first clock > multiple times, right? > > I guess there could be other users who also want "just get whatever > clocks I have" functionality, so it might be worth proposing that for > the core API as a separate/follow-up patch, but it definitely doesn't > need to be part of this series. Just to understand. Is it okay to make the driver "just get whatever clocks device node gives"? Doesn't the driver need to be aware of which all clocks are supposed to be obtained and enabled  It's should good for debug to let the world know which clock we failed to get. regards Vivek > > I really don't know enough about correct clk API usage, but modulo the > binding comments it certainly looks nice and tidy now; > > Acked-by: Robin Murphy > > Thanks, > Robin. [snip] > _______________________________________________ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu