[PATCH v4 3/7] ARM: Exynos: add device tree support for MCT controller driver
Mark Rutland
mark.rutland at arm.com
Tue Jan 22 00:46:10 EST 2013
On Mon, Jan 21, 2013 at 10:02:18AM +0000, Thomas Abraham wrote:
> Allow the MCT controller base address and interrupts to be obtained from
> device tree and remove unused static definitions of these. The non-dt support
> for Exynos5250 is removed but retained for Exynos4210 based platforms.
>
> Cc: Changhwan Youn <chaos.youn at samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham at linaro.org>
> ---
> .../bindings/timer/samsung,exynos4210-mct.txt | 68 ++++++++++++++++++++
> arch/arm/mach-exynos/include/mach/irqs.h | 6 --
> arch/arm/mach-exynos/mct.c | 49 +++++++++++----
> 3 files changed, 105 insertions(+), 18 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> new file mode 100644
> index 0000000..cb47bfb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
> @@ -0,0 +1,68 @@
> +Samsung's Multi Core Timer (MCT)
> +
> +The Samsung's Multi Core Timer (MCT) module includes two main blocks, the
> +global timer and CPU local timers. The global timer is a 64-bit free running
> +up-counter and can generate 4 interrupts when the counter reaches one of the
> +four preset counter values. The CPU local timers are 32-bit free running
> +down-counters and generate an interrupt when the counter expires. There is
> +one CPU local timer instantiated in MCT for every CPU in the system.
> +
> +Required properties:
> +
> +- compatible: should be "samsung,exynos4210-mct".
> + (a) "samsung,exynos4210-mct", for mct compatible with Exynos4210 mct.
> + (b) "samsung,exynos4412-mct", for mct compatible with Exynos4412 mct.
> +
> +- reg: base address of the mct controller and length of the address space
> + it occupies.
> +
> +- interrupts: the list of interrupts generated by the controller. The following
> + should be the order of the interrupts specified. The local timer interrupts
> + should be specified after the four global timer interrupts have been
> + specified.
> +
> + 0: Global Timer Interrupt 0
> + 1: Global Timer Interrupt 1
> + 2: Global Timer Interrupt 2
> + 3: Global Timer Interrupt 3
> + 4: Local Timer Interrupt 0
> + 5: Local Timer Interrupt 1
> + 6: ..
> + 7: ..
> + i: Local Timer Interrupt n
> +
> +Example 1: In this example, the system uses only the first global timer
> + interrupt generated by MCT and the remaining three global timer
> + interrupts are unused. Two local timer interrupts have been
> + specified.
> +
> + mct at 10050000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x10050000 0x800>;
> + interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
> + <0 42 0>, <0 48 0>;
Rather than padding the interrupts list with nonexistent interrupts, could you
not use something like a #global-interrupts property?
That way you don't have to list fake interrupts, you know exactly how many
global interrupts to expect (so you can sanity-check the list without any
special knowledge of the interrupt controller), and it's easier to support
future revisions which could have more interrupts, in a backwards-compatible
fashion.
> + };
> +
> +Example 2: In this example, the MCT global and local timer interrupts are
> + connected to two seperate interrupt controllers. Hence, an
> + interrupt-map is created to map the interrupts to the respective
> + interrupt controllers.
> +
> + mct at 101C0000 {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x101C0000 0x800>;
> + interrupt-controller;
> + #interrups-cells = <2>;
> + interrupt-parent = <&mct_map>;
> + interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
> + <4 0>, <5 0>;
> +
> + mct_map: mct-map {
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = <0x0 0 &combiner 23 3>,
> + <0x4 0 &gic 0 120 0>,
> + <0x5 0 &gic 0 121 0>;
> + };
> + };
[...]
Thanks,
Mark.
More information about the devicetree-discuss
mailing list