Received: by 10.223.176.5 with SMTP id f5csp2581750wra; Thu, 1 Feb 2018 02:45:16 -0800 (PST) X-Google-Smtp-Source: AH8x227/nS68ggLTCSEGUx5mf4ztAzfCj5wQ00GwdI74eHdrjOwnNwJAAD2cmdbPASiwZm2FeRO+ X-Received: by 2002:a17:902:b608:: with SMTP id b8-v6mr11606934pls.404.1517481915991; Thu, 01 Feb 2018 02:45:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517481915; cv=none; d=google.com; s=arc-20160816; b=zlp3yWgl/quKMcmy8kSeLTvEa4EJrMfdfKepuCE48SAS5NPyAvjxeb5CVukirHeGFG YLQ6rppuip4HZuzLUtDeV1bBUP8Ak1TiFAI9kD8tjnOVd5fiwi5nzYL4I296D2vXnl79 57s2N02l6+o06WCbzuI22WAGU4p8xY76hChG5MEx9nSu7ViOcKcFTYlAHxq+tjS2Xk9d AOtVY97zDqwEYa0CukQjERfoydFm3KMAe0X6K/dR+S/wmGTdB1GUWMgCZ6aOFZjSIhSe jLLb2SlTOybvvLxnv741Gbz8BLpPhEXsPJbDlodEZVf5e/OkCMsQt53uOZOHl0iBm/SN qITQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=JVMnhpDko/NkqNyE5ce4QMeF2aasNfcg+mRLJ2vvQqc=; b=olCX1E3jdLIsKJdUtNXTXEoZmQKChGOHWDn1DY9nRge3tWafGrtjHoDNrVuxWxjdZ5 dspEqifUVl894RDgrZ+r367I+bThrKjK6GexR50wbKujXUrfUPmT8zciNI6KmfEjQztt YQlRGZLKWyvbkfOC+r/m7k5GMuYoJWMq32ZxaB50G4wptxQradArZx/ugW4okEUl8Seb S0/4XbEMUIQRfrOO56traB2njhKzKj2OIpbrbhjaDl0TiaMFUNkWRh7dZGOCjvyGcDYG KPTfu0eFSRLo3WDZ0SoZYiFD1xn0/QMALR+gDGRZHtdqaUe4xQxGcsvh4DuMQM04XSSG kBqg== 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 bf9-v6si6114863plb.741.2018.02.01.02.45.01; Thu, 01 Feb 2018 02:45:15 -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 S1752079AbeBAKol (ORCPT + 99 others); Thu, 1 Feb 2018 05:44:41 -0500 Received: from foss.arm.com ([217.140.101.70]:47510 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751520AbeBAKoj (ORCPT ); Thu, 1 Feb 2018 05:44:39 -0500 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 AD6DD80D; Thu, 1 Feb 2018 02:44:38 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 23C8D3F25C; Thu, 1 Feb 2018 02:44:36 -0800 (PST) Date: Thu, 1 Feb 2018 10:44:34 +0000 From: Mark Rutland To: Channagoud Kadabi Cc: linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-arm@lists.infradead.org, linux-kernel@vger.kernel.org, tsoni@codeaurora.org, sboyd@codeaurora.org, kyan@codeaurora.org Subject: Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc Message-ID: <20180201104434.7j27fl2hb4glqd3v@lakrids.cambridge.arm.com> References: <1516924513-20183-1-git-send-email-ckadabi@codeaurora.org> <1516924513-20183-2-git-send-email-ckadabi@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516924513-20183-2-git-send-email-ckadabi@codeaurora.org> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 25, 2018 at 03:55:12PM -0800, Channagoud Kadabi wrote: > Documentation for last level cache controller device tree bindings, > client bindings usage examples. > > Signed-off-by: Channagoud Kadabi > --- > .../devicetree/bindings/arm/msm/qcom,llcc.txt | 93 ++++++++++++++++++++++ > 1 file changed, 93 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt > > diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt > new file mode 100644 > index 0000000..d433b0c > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt > @@ -0,0 +1,93 @@ > +* LLCC (Last Level Cache Controller) > + > +Properties: > +- compatible: > + Usage: required > + Value type: > + Definition: must be "qcom,llcc-core" > + > +- reg: > + Usage: required > + Value Type: > + Definition: must be addresses and sizes of the LLCC registers > + > +- llcc-bank-off: > + Usage: required > + Value Type: > + Definition: Offsets of llcc banks from llcc base address starting from > + LLCC bank0. > + > +- llcc-broadcast-off: > + Usage: required > + Value Type: > + Definition: Offset of broadcast register from LLCC bank0 address. Please could we use "offset" rather than "off" for both of these? That way it's obvious these aren't properties for disabling some feature. How variable are these offsets in practice? Is the memory map not fixed? > + > +- #cache-cells: > + Usage: required > + Value Type: > + Definition: Number of cache cells, must be 1 What's this for, and how is it used? > + > +- max-slices: > + usage: required > + Value Type: > + Definition: Number of cache slices supported by hardware > + > +- status: > + Usage: optional > + Value type: > + Definition: Property to enable or disable the driver This is a standard property, so I don't think it needs to be described here. > + > +== llcc amon device == > + > +Properties: > +-qcom,fg-cnt : The value of fine grained counter of activity monitor > + block. Could you elaborate on this? > + > +compatible devices: > + qcom,sdm845-llcc Huh? The "qcom,sdm845-llcc" bindings wasn't described above, and it's not clear what this means. > + > +Example: > + > + qcom,system-cache@1300000 { > + compatible = "qcom,llcc-core", "syscon", "simple-mfd"; This looks very wrong. Why do you need syscon and simple-mfd? > + reg = <0x1300000 0x50000>; > + reg-names = "llcc_base"; > + > + llcc: qcom,sdm845-llcc { > + compatible = "qcom,sdm845-llcc"; Why is this a sub-node? Why isn't the top-level node just "qcom,sdm845-llcc" ? > + #cache-cells = <1>; > + max-slices = <32>; > + }; > + > + qcom,llcc-ecc { > + compatible = "qcom,llcc-ecc"; > + }; > + > + qcom,llcc-amon { > + compatible = "qcom,llcc-amon"; > + qcom,fg-cnt = <0x7>; > + }; > + > + }; > + > +== Client == > + > +Properties: > +- cache-slice-names: > + Usage: required > + Value type: > + Definition: A set of names that identify the usecase names of a client that uses > + cache slice. These strings are used to look up the cache slice > + entries by name. > + > +- cache-slices: > + Usage: required > + Value type: > + Definition: The tuple has phandle to llcc device as the first argument and the > + second argument is the usecase id of the client. What is a "usecase id" ? Is this meant to align with #cache-cells? It would be best to keep a common prefix (i.e. call that #cache-slice-cells). Thanks, Mark.