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@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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html