lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170531191231.5qt2lfv73p572gmd@rob-hp-laptop>
Date:   Wed, 31 May 2017 14:12:31 -0500
From:   Rob Herring <robh@...nel.org>
To:     Suman Anna <s-anna@...com>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Ohad Ben-Cohen <ohad@...ery.com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-remoteproc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, "Andrew F. Davis" <afd@...com>,
        Sam Nelson <sam.nelson@...com>
Subject: Re: [PATCH 1/3] Documentation: DT: add Keystone DSP remoteproc
 binding

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@...com>
> Signed-off-by: Sam Nelson <sam.nelson@...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.

> +
> +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?

> +
> +- 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

> +			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@...00000 {
> +			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@...800000 {
> +			compatible = "shared-dma-pool";
> +			reg = <0x00000008 0x1f800000 0x00000000 0x800000>;
> +			reusable;
> +			status = "okay";
> +		};
> +	};
> +
> +	&dsp0 {
> +		memory-region = <&dsp_common_cma_pool>;
> +	};
> -- 
> 2.12.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ