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@xxxxxx> > Signed-off-by: Sam Nelson <sam.nelson@xxxxxx> > --- > .../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@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>; > + }; > -- > 2.12.0 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html