Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp11012015imu; Thu, 6 Dec 2018 10:05:33 -0800 (PST) X-Google-Smtp-Source: AFSGD/VX0Y8S4S68rR2bYaxwzScS3X1Ce8rb3m5X0yXl0HvJsTK7wf5vFZZnldDeGB2wZStDxnGY X-Received: by 2002:a17:902:2868:: with SMTP id e95mr29224910plb.317.1544119533520; Thu, 06 Dec 2018 10:05:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544119533; cv=none; d=google.com; s=arc-20160816; b=jvvwKK13A7gb0q4tmJJ7eD20Hnz2I5ko4J+5NNA2T+inD0CiERl0C+UGs6jUBFereN 6QbY/PPbRyGb2aV8xEWxrvzyPN/s4frwmEIpVk9W9/kuw4f6l6S5l5QBDtWe5+hImdCg Ur6x9gMYpKd0/6evNz+Lv1opav+NQlLfFtAhuq/aepBYViTu8uhxBl4v8cnFCobKgRjJ Mvo5Yfd2+qzjLqmlez/zrbUE1+UK5NhHmca98VvogyYwDNR8UuGZkW6jzEnoysdG/ZPN lcbNbLPwkgFIGm0HH4hN+kCSMO1B2SUrZFGnn9kqsipBJFIVw4pAtw90s3hQ7DTghBgf qQ+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature; bh=VbqyMpy65wsMnbzE71zc5MW+SoNBLt+LnHDvNOTzt9c=; b=yKVX+8ULnGHkuNZMqVB3L1kh5XsKqxx65CVmHwCtl14P4YzmtXOitpUodKeEcUuLFp X5mwqlg7XylMwZ1W58/aCUxOBBg3Va8XU5p+rPSKI9KEqe3cHr+DiEztd2H+fJIbIxFs YOn+qXK/uwicEZSQcY8U7ymB1UFM+rLhJ5H1uFdqZPmVLaldqyrGQL6ixLerqAZKaJ4W n9vmZm2DCrERMwx55ODso1eyCAOS7P+WcIbBZGQSQsGtf/kmPXAeR5iLM7ZhxdopeK6p DTUjbhdGZIuLYLD4S2I8RzNWZzPIaDMZPVs47qwAAcWx+SkIWo56v4yHiLCJ4kp1fI9v 35dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=kuLlbkDb; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14si769304pgz.180.2018.12.06.10.05.13; Thu, 06 Dec 2018 10:05:33 -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=@kernel.org header.s=default header.b=kuLlbkDb; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726025AbeLFSCW (ORCPT + 99 others); Thu, 6 Dec 2018 13:02:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:35850 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725950AbeLFSCV (ORCPT ); Thu, 6 Dec 2018 13:02:21 -0500 Received: from localhost (unknown [104.132.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D326D20878; Thu, 6 Dec 2018 18:02:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544119340; bh=VbqyMpy65wsMnbzE71zc5MW+SoNBLt+LnHDvNOTzt9c=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=kuLlbkDbjs8KPiWwDCDuYYYvxJhVAs7CwEmOQw38DEJ94DfKhiHIvjA/vHrq2mR1e S5wfwDMiJqzW+sAfPAkepxIDkHa9eIY11xL575OGXjTNQcizzOXP+hTgMQY7ldwTFR e9cOPvwIdxb+x4m8pikX1ABhQodMUntNjWrghc4A= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Alex Elder , David Dai , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org From: Stephen Boyd In-Reply-To: <6ffdf6ca-51b5-a968-bb4e-c4d6d46f63aa@codeaurora.org> Cc: georgi.djakov@linaro.org, bjorn.andersson@linaro.org, evgreen@google.com, tdas@codeaurora.org References: <1543895413-1553-1-git-send-email-daidavid1@codeaurora.org> <1543895413-1553-2-git-send-email-daidavid1@codeaurora.org> <154395145491.88331.1174781210192403998@swboyd.mtv.corp.google.com> <8dafe631-4b16-94cd-392e-84728f2bb382@linaro.org> <154396284056.88331.12279283832884556349@swboyd.mtv.corp.google.com> <154399414865.88331.2447825064224349951@swboyd.mtv.corp.google.com> <6ffdf6ca-51b5-a968-bb4e-c4d6d46f63aa@codeaurora.org> Message-ID: <154411934006.88331.2149751521264448532@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [RFC PATCH] clk: qcom: clk-rpmh: Add IPA clock support Date: Thu, 06 Dec 2018 10:02:20 -0800 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting David Dai (2018-12-05 17:24:18) > = > = > On 12/4/2018 11:15 PM, Stephen Boyd wrote: > > Quoting David Dai (2018-12-04 17:14:10) > >> On 12/4/2018 2:34 PM, Stephen Boyd wrote: > >>> Quoting Alex Elder (2018-12-04 13:41:47) > >>>> > >>> But then we translate that clock rate into a bandwidth request to the > >>> BCM hardware? Seems really weird because it's doing the opposite of w= hat > >>> you say is abusive. What does the IPA driver plan to do with this clk? > >>> Calculate a frequency by knowing that it really boils down to some > >>> bandwidth that then gets converted back into some clock frequency? Do= we > >>> have the user somewhere that can be pointed to? > >> The clock rate is translated into a unitless threshold value sent as > >> part of the rpmh msg > >> that BCM takes to select a performance. In this case, the unit > >> conversion is based on > >> the unit value read from the aux data which is in Khz. I understand th= at > >> this wasn't > >> explicitly mentioned anywhere and I'll improve on that next patch. > > How is this different from bus bandwidth requests? In those cases the > > bandwidth is calculated in bits per second or something like that, and > > written to the hardware so it can convert that bandwidth into kHz and > > set a bus clk frequency in the clock controller? So in the IPA case > > we've skipped the bps to kHz conversion step and gone straight to the > > clk frequency setting part? Is a BCM able to aggregate units of > > bandwidth or kHz depending on how it's configured and this BCM is > > configured for kHz? > = > The data written to the hardware is just a 14bit scalar value that it = > takes to select a performance/frequency from a preset table. It's not = > really doing any sort of conversion in hardware in this case, instead = > the value is computed by software based on the aux data given. Think of = > it as a generic aggregator as opposed to being strictly bandwidth and = > the aggregator itself does not care what type of value it is(be it Khz = > or BW/s). > = Got it. Thanks!