On 2015-01-26 14:36, Mark Rutland wrote: > On Thu, Jan 15, 2015 at 08:04:05AM +0000, Stefan Agner wrote: >> Add binding documentation for Miscellaneous System Control Module >> found in Freescale Vybrid SoC's. >> >> Signed-off-by: Stefan Agner <stefan@xxxxxxxx> >> --- >> .../bindings/arm/freescale/fsl,vf610-mscm.txt | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt >> >> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt >> new file mode 100644 >> index 0000000..e051b88 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt >> @@ -0,0 +1,19 @@ >> +Freescale Vybrid Miscellaneous System Control Module >> + >> +The MSCM IP contains Access Control and TrustZone Security hardware, >> +CPU Configuration registers and Interrupt Router control. >> + >> +Required properties: >> +- compatible : "fsl,vf610-mscm", "syscon" > > I'm a little concerned by this also being a syscon. What other devices > need to refer to this block as a syscon? > The block offers several functionality. I'm happy we can discuss this here a bit more in depth, since I'm really not sure if the current solution is the best solution... Due to the general rule to not split hardware modules, I hesitated to make different nodes out of it. However, this module has some quite distinct sub-modules, hence I guess it would be also feasible to do so: 0x40001000-0x4000105C - Processor information e.g. which processor ID is the accessing processor (processor identity), cache size etc... 0x40001800-0x40001820 - CPU2CPU directed interrupt generation/clear registers... 0x40001880-0x4000195E - the actual interrupt router 0x40001C00-0x40001DDC - ACTZS TrustZone registers... This driver accesses the first and the third block. The first block is necessary since the driver needs to know which CPU ID it is running on to actually program the interrupt router (Note: this is a heterogeneous multiprocessing system. This are actually treated as two independent UP systems, considering that Linux can also run on the Cortex-M4). Hence, the syscon definition which would allow to access other areas as needed, especially the processor information might be needed by any other peripheral (driver) which needs to know what CPU it is running on. What do you think? OTH, we could as well split it up in three or even four nodes. The MSCM interrupt router part just needs to access the the MSCM processor information part somehow (syscon?)... Fwiw, in our downstream kernel, the CPU2CPU interrupts are used for Freescales messaging system (MCC). I hacked a special interface in that early version of this driver, to export this functionality. But then I guess such a functionality should not affect the device tree bindings...? http://git.toradex.com/cgit/linux-toradex.git/commit/?h=toradex_vf_3.18-next&id=6f0bbad6b805cf2014eec54531dbe4ddb4867a91 For detailed information, the module is documented in the public reference manual, chapter 64. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xx&fpsp=1&tab=Documentation_Tab >> +- interrupt-controller : Identifies the node as an interrupt controller >> +- #interrupt-cells : Two cells, interrupt number and flags (IRQ type) > > What numbers and flags are valid? > The first cell is the hardware interrupt ID according to the MSCM interrupt router. The flags gets passed to the GIC interrupt controller only, hence those are the one which are supported by the GIC controller. Will add that information, thx. -- Stefan > Mark. > >> +- reg : the register range of the MSCM module >> + >> +Example: >> + mscm: mscm@40001000 { >> + compatible = "fsl,vf610-mscm", "syscon"; >> + interrupt-controller; >> + #interrupt-cells = <2>; >> + interrupt-parent = <&intc>; >> + reg = <0x40001000 0x1000>; >> + } >> -- >> 2.2.1 >> >> -- 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
