public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
	Andy Gross <andy.gross@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-remoteproc@vger.kernel.org, linux-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/4] dt-binding: remoteproc: Introduce ADSP loader binding
Date: Tue, 23 Aug 2016 13:31:21 -0500	[thread overview]
Message-ID: <20160823183121.GA13010@rob-hp-laptop> (raw)
In-Reply-To: <1471931866-3107-1-git-send-email-bjorn.andersson@linaro.org>

On Mon, Aug 22, 2016 at 10:57:43PM -0700, Bjorn Andersson wrote:
> This document defines the binding for a component that loads firmware
> and control the life cycle of the Qualcomm ADSP core.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v1:
> - Added platform names to compatibility
> 
>  .../devicetree/bindings/remoteproc/qcom,adsp.txt   | 70 ++++++++++++++++++++++
>  1 file changed, 70 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> new file mode 100644
> index 000000000000..3820151ce3e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> @@ -0,0 +1,70 @@
> +Qualcomm ADSP Peripheral Image Loader
> +
> +This document defines the binding for a component that loads and boots firmware
> +on the Qualcomm ADSP core.

ADSP is for Audio DSP? So there is another driver for the audio 
functions? Why doesn't it do the firmware loading? I'm still confused 
why this binding is separate? If you had one common interface (a rproc) 
to load and boot various other blocks like ADSP and Venus, then this 
would make sense. Or does every accel block have some separate control 
uC associated with it?

> +
> +- compatible:
> +	Usage: required
> +	Value type: <string>
> +	Definition: must be one of:
> +		    "qcom,msm8974-adsp-pil"
> +		    "qcom,msm8996-adsp-pil"
> +
> +- interrupts-extended:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: must list the watchdog, fatal IRQs ready, handover and
> +		    stop-ack IRQs
> +
> +- interrupt-names:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
> +
> +- cx-supply:
> +	Usage: required
> +	Value type: <phandle>
> +	Definition: reference to the regulator to be held on behalf of the
> +		    booting of the Hexagon core
> +
> +- memory-region:
> +	Usage: required
> +	Value type: <phandle>
> +	Definition: reference to the reserved-memory for the ADSP
> +
> +- qcom,smem-states:
> +	Usage: required
> +	Value type: <phandle>
> +	Definition: reference to the smem state for requesting the ADSP to
> +		    shut down
> +
> +- qcom,smem-state-names:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be "stop"
> +
> += EXAMPLE
> +The following example describes the resources needed to boot control the
> +ADSP, as it is found on MSM8974 boards.
> +
> +	adsp {
> +		compatible = "qcom,adsp-pil";
> +
> +		interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
> +		interrupt-names = "wdog",
> +				  "fatal",
> +				  "ready",
> +				  "handover",
> +				  "stop-ack";
> +
> +		cx-supply = <&pm8841_s2>;
> +
> +		memory-region = <&adsp_region>;
> +
> +		qcom,smem-states = <&modem_smp2p_out 0>;
> +		qcom,smem-state-names = "stop";
> +	};
> -- 
> 2.5.0
> 

  parent reply	other threads:[~2016-08-23 18:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23  5:57 [PATCH v2 1/4] dt-binding: remoteproc: Introduce ADSP loader binding Bjorn Andersson
2016-08-23  5:57 ` [PATCH v2 2/4] remoteproc: Introduce Qualcomm ADSP PIL Bjorn Andersson
2016-08-23 15:14   ` Stanimir Varbanov
2016-08-23 16:38     ` Bjorn Andersson
2016-08-23  5:57 ` [PATCH v2 3/4] ARM: dts: msm8974: Add ADSP smp2p and smd nodes Bjorn Andersson
2016-08-23  5:57 ` [PATCH v2 4/4] ARM: dts: msm8974: Add ADSP PIL node Bjorn Andersson
2016-08-23 18:31 ` Rob Herring [this message]
2016-08-23 18:57   ` [PATCH v2 1/4] dt-binding: remoteproc: Introduce ADSP loader binding Bjorn Andersson
2016-08-30 23:47     ` Bjorn Andersson

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=20160823183121.GA13010@rob-hp-laptop \
    --to=robh@kernel.org \
    --cc=andy.gross@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ohad@wizery.com \
    /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