devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Lina Iyer <ilina@codeaurora.org>
Cc: andy.gross@linaro.org, david.brown@linaro.org,
	sboyd@codeaurora.org, rnayak@codeaurora.org,
	linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 2/4] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs
Date: Sat, 3 Feb 2018 11:11:03 -0800	[thread overview]
Message-ID: <20180203191103.GB9465@builder> (raw)
In-Reply-To: <20180119000157.7380-3-ilina@codeaurora.org>

On Thu 18 Jan 16:01 PST 2018, Lina Iyer wrote:

> +- reg:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: the first element specifies the base address of the DRV,
> +	            the second element specifies the size of the region.

This doesn't capture the fact that there are two memory regions that
needs to be described.

[..]
> +- qcom, tcs-config:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: the tuple definining the configuration of TCS.
> +	            Must have 2 cells which describe each TCS type.
> +	            <type number_of_tcs>

I think this definition should capture that it's a list of tuples and
they are describing the functional allocation of the available TCSs.

> +	- Cell #1 (TCS Type): TCS types can be specified -
> +		SLEEP_TCS
> +		WAKE_TCS
> +		ACTIVE_TCS
> +		CONTROL_TCS
> +	- Cell #2 (Number of TCS): <u32>
> +
[..]
> +EXAMPLE 1:
> +
> +For a TCS whose RSC base address is is 0x179C0000 and is at a DRV of 2, the
> +register offsets for DRV2 start at 0D00, the register calculations are like
> +this -
> +First tuple: 0x179C0000 + 0x10000 * 2 = 0x179E0000
> +Second tuple: 0x179E0000 + 0xD00  = 0x179E0D00

So the first region is the DRV base and the second describe the TCSs? I
think that the purpose of the two regions should be clarified.

If this is the case then I would suggest also adding a

	reg-names = "drv", "tcs";

in order to make the dts self-explaining.

> +
> +	apps_rsc: rsc@179e000 {
> +		compatible = "qcom,rpmh-rsc";
> +		label = "apps_rsc";
> +		reg = <0x179e0000 0x10000>, <0x179e0d00 0x3000>;
> +		interrupts = <0 5 0>;

<GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;

> +		qcom,drv-id = <2>;
> +		qcom,tcs-config = <SLEEP_TCS   3>,
> +				  <WAKE_TCS    3>,
> +				  <ACTIVE_TCS  2>,
> +				  <CONTROL_TCS 1>;
> +
> +		foo-clk {
> +			compatible = "foo-clk";
> +		};
> +	};
> +

Regards,
Bjorn

  parent reply	other threads:[~2018-02-03 19:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19  0:01 [PATCH 0/4] drivers/qcom: add RPMH communication support Lina Iyer
2018-01-19  0:01 ` [PATCH 1/4] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Lina Iyer
     [not found]   ` <20180119000157.7380-2-ilina-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-05 19:18     ` Bjorn Andersson
2018-02-08 22:00       ` Lina Iyer
2018-01-19  0:01 ` [PATCH 2/4] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs Lina Iyer
2018-01-29 19:33   ` Rob Herring
2018-01-30 16:24     ` Lina Iyer
2018-02-03 19:11   ` Bjorn Andersson [this message]
2018-01-19  0:01 ` [PATCH 3/4] drivers: qcom: rpmh-rsc: log RPMH requests in FTRACE Lina Iyer
     [not found]   ` <20180119000157.7380-4-ilina-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-19  1:26     ` Steven Rostedt
2018-01-19  7:35       ` Lina Iyer
     [not found]         ` <20180119073501.GA26362-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-19 14:44           ` Steven Rostedt
     [not found]             ` <20180119094443.39e5f020-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
2018-01-19 16:17               ` Lina Iyer
2018-01-19  0:01 ` [PATCH 4/4] drivers: qcom: rpmh: add RPMH helper functions Lina Iyer
2018-02-05 19:50   ` Bjorn Andersson
2018-02-08 23:15     ` Lina Iyer
     [not found]   ` <20180119000157.7380-5-ilina-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-15  8:49     ` Rajendra Nayak
2018-02-15 15:52       ` Lina Iyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180203191103.GB9465@builder \
    --to=bjorn.andersson@linaro.org \
    --cc=andy.gross@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ilina@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=rnayak@codeaurora.org \
    --cc=sboyd@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).