mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Suman Anna <s-anna@ti.com>
To: Rob Herring <robh@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Santosh Shilimkar <ssantosh@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	<linux-remoteproc@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	"Andrew F. Davis" <afd@ti.com>, Sam Nelson <sam.nelson@ti.com>
Subject: Re: [PATCH 1/3] Documentation: DT: add Keystone DSP remoteproc binding
Date: Wed, 31 May 2017 15:05:59 -0500	[thread overview]
Message-ID: <884f5585-eac2-57b2-a2be-879bf23f2e00@ti.com> (raw)
In-Reply-To: <20170531191231.5qt2lfv73p572gmd@rob-hp-laptop>

Hi Rob,

On 05/31/2017 02:12 PM, Rob Herring wrote:
> On Fri, May 26, 2017 at 11:53:15AM -0500, Suman Anna wrote:
>> Add the device tree bindings document for the Texas Instrument's
>> Keystone 2 DSP remoteproc devices.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Sam Nelson <sam.nelson@ti.com>
>> ---
>>  .../bindings/remoteproc/ti,keystone-rproc.txt      | 132 +++++++++++++++++++++
>>  1 file changed, 132 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt
>> new file mode 100644
>> index 000000000000..f1ba88edd00d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt
>> @@ -0,0 +1,132 @@
>> +TI Keystone DSP devices
>> +=======================
>> +
>> +Binding status: Unstable - Subject to changes for using multiple memory regions
> 
> I don't really see what would be unstable here. memory-region is easily 
> extended to multiple entries.

OK will drop this line.

> 
>> +
>> +The TI Keystone 2 family of SoCs usually have one or more (upto 8) TI DSP Core
>> +sub-systems that are used to offload some of the processor-intensive tasks or
>> +algorithms, for achieving various system level goals.
>> +
>> +These processor sub-systems usually contain additional sub-modules like L1
>> +and/or L2 caches/SRAMs, an Interrupt Controller, an external memory controller,
>> +a dedicated local power/sleep controller etc. The DSP processor core in
>> +Keystone 2 SoCs is usually a TMS320C66x CorePac processor.
>> +
>> +DSP Device Node:
>> +================
>> +Each DSP Core sub-system is represented as a single DT node. Each node has a
>> +number of required or optional properties that enable the OS running on the
>> +host processor (ARM CorePac) to perform the device management of the remote
>> +processor and to communicate with the remote processor.
>> +
>> +Required properties:
>> +--------------------
>> +The following are the mandatory properties:
>> +
>> +- compatible:		Should be one of the following,
>> +			    "ti,k2hk-dsp" for DSPs on Keystone 2 66AK2H/K SoCs
>> +			    "ti,k2l-dsp" for DSPs on Keystone 2 66AK2L SoCs
>> +			    "ti,k2e-dsp" for DSPs on Keystone 2 66AK2E SoCs
>> +
>> +- reg:			Should contain an entry for each value in 'reg-names'.
>> +			Each entry should have the memory region's start address
>> +			and the size of the region, the representation matching
>> +			the parent node's '#address-cells' and '#size-cells' values.
>> +
>> +- reg-names:		Should contain strings with the following names, each
>> +			representing a specific internal memory region, and
>> +			should be defined in this order,
>> +			     "l2sram", "l1pram", "l1dram"
>> +
>> +- label:		Should contain a string identifying the DSP instance
>> +			within the SoC. Should be the string "dsp" followed by
>> +			the instance number. Eg: "dsp0", "dsp1",..."dsp7" etc
> 
> Why does a user need to know or care?

This is used to distinguish the exact DSP instance from others since the
DT node name is a generic "dsp". One of the uses is to be able to
construct a firmware name within the driver using this label.

> 
>> +
>> +- clocks: 		Should contain the device's input clock, and should be
>> +			defined as per the bindings in,
>> +			Documentation/devicetree/bindings/clock/keystone-gate.txt
>> +
>> +- ti,syscon-dev:	Should be a pair of the phandle to the Keystone Device
>> +			State Control node, and the register offset of the DSP
>> +			boot address register within that node's address space.
>> +
>> +- resets:		Should contain the phandle to the reset controller node
>> +			managing the resets for this device, and a reset
>> +			specifier. Please refer to the following reset bindings
>> +			for the reset argument specifier as per SoC,
>> +			Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
>> +			    for 66AK2HK/66AK2L/66AK2E SoCs
>> +
>> +- interrupt-parent:	Should contain a phandle to the Keystone 2 IRQ controller
>> +			IP node that is used by the ARM CorePac processor to
>> +			receive interrupts from the DSP remote processors. See
>> +			Documentation/devicetree/bindings/interrupt-controller/ti,keystone-irq.txt
>> +			for details.
>> +
>> +- interrupts: 		Should contain an entry for each value in 'interrupt-names'.
>> +			Each entry should have the interrupt source number used by
>> +			the remote processor to the host processor. The values should
>> +			follow the interrupt-specifier format as dictated by the
>> +			'interrupt-parent' node. The purpose of each is as per the
>> +			description in the 'interrupt-names' property.
>> +
>> +- interrupt-names:	Should contain strings with the following names, each
>> +			representing a specific interrupt,
>> +			    "vring" - interrupt for virtio based IPC
>> +			    "exception" - interrupt for exception notification
>> +
>> +- kick-gpio: 		Should specify the gpio device needed for the virtio IPC
> 
> -gpios

Will fix.

> 
>> +			stack. This will be used to interrupt the remote processor.
>> +			The gpio device to be used is as per the bindings in,
>> +			Documentation/devicetree/bindings/gpio/gpio-dsp-keystone.txt
>> +
>> +Optional properties:
>> +--------------------
>> +
>> +- memory-region:	phandle to the reserved memory node to be associated
>> +			with the remoteproc device. The reserved memory node
>> +			can be a CMA memory node, and should be defined as
>> +			per the bindings in
>> +			Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>> +
>> +
>> +Example:
>> +--------
>> +
>> +	/* 66AK2H/K DSP node in SoC DTS file */
>> +	soc {
>> +		dsp0: dsp@10800000 {
>> +			compatible = "ti,k2hk-dsp";
>> +			reg = <0x10800000 0x00100000>,
>> +			      <0x10e00000 0x00008000>,
>> +			      <0x10f00000 0x00008000>;
>> +			reg-names = "l2sram", "l1pram", "l1dram";
>> +			label = "dsp0";
>> +			clocks = <&clkgem0>;
>> +			ti,syscon-dev = <&devctrl 0x40>;
>> +			resets = <&pscrst 0>;
>> +			interrupt-parent = <&kirq0>;
>> +			interrupts = <0 8>;
>> +			interrupt-names = "vring", "exception";
>> +			kick-gpio = <&dspgpio0 27 0>;
>> +		};
>> +
>> +	};
>> +
>> +	/* K2HK EVM Board file */
>> +	reserved-memory {
>> +		#address-cells = <2>;
>> +		#size-cells = <2>;
>> +		ranges;
>> +
>> +		dsp_common_cma_pool: dsp_common_cma_pool@81f800000 {
>> +			compatible = "shared-dma-pool";
>> +			reg = <0x00000008 0x1f800000 0x00000000 0x800000>;
>> +			reusable;
>> +			status = "okay";
>> +		};
>> +	};
>> +
>> +	&dsp0 {
>> +		memory-region = <&dsp_common_cma_pool>;
>> +	};

Will also fix this up based on your comments on the Davinci remoteproc
driver binding.

regards
Suman

  reply	other threads:[~2017-05-31 20:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 16:53 [PATCH 0/3] Add Keystone2 Remoteproc driver Suman Anna
2017-05-26 16:53 ` [PATCH 1/3] Documentation: DT: add Keystone DSP remoteproc binding Suman Anna
2017-05-31 19:12   ` Rob Herring
2017-05-31 20:05     ` Suman Anna [this message]
2017-06-05 17:26       ` Rob Herring
2017-06-05 18:21         ` Suman Anna
2017-06-05 19:10           ` Rob Herring
2017-06-05 20:05             ` Suman Anna
2017-05-26 16:53 ` [PATCH 2/3] remoteproc/keystone: add a remoteproc driver for Keystone 2 DSPs Suman Anna
2017-05-26 16:53 ` [PATCH 3/3] remoteproc/keystone: ensure the DSPs are in reset in probe Suman Anna

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=884f5585-eac2-57b2-a2be-879bf23f2e00@ti.com \
    --to=s-anna@ti.com \
    --cc=afd@ti.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ohad@wizery.com \
    --cc=robh@kernel.org \
    --cc=sam.nelson@ti.com \
    --cc=ssantosh@kernel.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

Powered by JetHome