From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by aws-us-west-2-korg-lkml-1.web.codeaurora.org (Postfix) with ESMTP id AE7C4C004E4 for ; Wed, 13 Jun 2018 11:27:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 68455204EC for ; Wed, 13 Jun 2018 11:27:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68455204EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935310AbeFML06 (ORCPT ); Wed, 13 Jun 2018 07:26:58 -0400 Received: from foss.arm.com ([217.140.101.70]:46200 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935121AbeFML04 (ORCPT ); Wed, 13 Jun 2018 07:26:56 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 451961529; Wed, 13 Jun 2018 04:26:56 -0700 (PDT) Received: from [10.1.210.28] (e107155-lin.cambridge.arm.com [10.1.210.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 621AB3F25D; Wed, 13 Jun 2018 04:26:54 -0700 (PDT) Cc: "Rafael J. Wysocki" , Viresh Kumar , Stephen Boyd , Sudeep Holla , Rajendra Nayak , devicetree@vger.kernel.org, robh@kernel.org, skannan@codeaurora.org Subject: Re: [PATCH v4 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW bindings To: Taniya Das , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org References: <1528801355-18719-1-git-send-email-tdas@codeaurora.org> <1528801355-18719-2-git-send-email-tdas@codeaurora.org> From: Sudeep Holla Organization: ARM Message-ID: <0f3f0223-3539-dc66-5300-8f30d827445d@arm.com> Date: Wed, 13 Jun 2018 12:26:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1528801355-18719-2-git-send-email-tdas@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/06/18 12:02, Taniya Das wrote: > Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's > SoCs. This is required for managing the cpu frequency transitions which are > controlled by firmware. > > Signed-off-by: Taniya Das > --- > .../bindings/cpufreq/cpufreq-qcom-fw.txt | 173 +++++++++++++++++++++ > 1 file changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > new file mode 100644 > index 0000000..e3087ec > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > @@ -0,0 +1,173 @@ > +Qualcomm Technologies, Inc. CPUFREQ Bindings > + > +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) > +SoCs to manage frequency in hardware. It is capable of controlling frequency > +for multiple clusters. > + You are bit inconsistent on the wordings. Some places you refer this as hardware engine. If so, please drop all references to firmware/FW. If it's firmware then update accordingly. > +Properties: > +- compatible > + Usage: required > + Value type: > + Definition: must be "qcom,cpufreq-fw". > + > +* Property qcom,freq-domain > +Devices supporting freq-domain must set their "qcom,freq-domain" property with > +phandle to a freq_domain_table in their DT node. > + > +* Frequency Domain Table Node > + > +This describes the frequency domain belonging to a device. > +This node can have following properties: > + > +- reg > + Usage: required > + Value type: > + Definition: Addresses and sizes for the memory of the perf > + , lut and enable bases. > + perf - indicates the base address for the desired > + performance state to be set. > + lut - indicates the look up table base address for the > + cpufreq driver to read frequencies. > + enable - indicates the enable register for firmware. You still didn't answer my earlier question. OS might touch one or 2 registers in lots of IP blocks. I am not sure why those are any different from these. Are you trying to align with any other bindings or specification. Are you trying to make this binding generic here ? I understand if it was trying to generalize the firmware interface, but you also state it's a hardware engine. So I fail to see the need for such specificity here. Why not define the whole IP block and the driver knows where to access these specific ones as they are specific to this hardware block. In that way if you decide to add more data, it's extensible easily without the need for patching DT. Eg. Suppose you need some information on power curve for EAS energy model, I really hate to update DT for that or even do a mix with DT just because f/w is no longer modifiable. -- Regards, Sudeep