All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Tomasz Figa <t.figa@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	Kukjin Kim <kgene.kim@samsung.com>,
	Thomas Abraham <thomas.abraham@linaro.org>,
	ian.campbell@citrix.com, pawel.moll@arm.com,
	mark.rutland@arm.com, rob.herring@calxeda.com,
	galak@codeaurora.org, Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [PATCH 1/8] Documentation: devicetree: Update Exynos MCT bindings description
Date: Tue, 20 Aug 2013 11:00:53 -0600	[thread overview]
Message-ID: <5213A0C5.9000901@wwwdotorg.org> (raw)
In-Reply-To: <1377006768-23174-2-git-send-email-t.figa@samsung.com>

On 08/20/2013 07:52 AM, Tomasz Figa wrote:
> This patch updates description of device tree bindings for Exynos MCT
> (multicore timers). Namely:
>  - added note about simplified specification of local timer interrupts,
>    when using single per-processor interrupt for all local timers,
>  - changed first example that was incorrectly suggesting that global
>    timer interrupts are optional,
>  - simplified example interrupt map,
>  - added example showing simplified local timer interrupt specification.

> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt

> -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.
> +  For MCT block that uses a per-processor interrupt for local timers, such
> +  as ones compatible with "samusng,exynos4412-mct", only one local timer

samsung is typo'd there.

> +Example 2: In this example, the timer interrupts are connected to two separate
> +	   interrupt controllers. Hence, an interrupt-map is created to map
> +	   the interrupts to the respective interrupt controllers.
>  
>  	mct@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>;
> +		interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
>  
>  		mct_map: mct-map {
> -			#interrupt-cells = <2>;
> +			#interrupt-cells = <1>;

>  			#address-cells = <0>;
>  			#size-cells = <0>;

I don't believe you need either of those two properties in a node solely
used as an interrupt map.

Also, why not put the interrupt-map property directly into the main mct
node; I don't believe there's any requirement nor advantage to it being
a separate node.

> -			interrupt-map = <0x0 0 &combiner 23 3>,
> -					<0x4 0 &gic 0 120 0>,
> -					<0x5 0 &gic 0 121 0>;
> +			interrupt-map = <0 &gic 0 57 0>,
> +					<1 &gic 0 69 0>,
> +					<2 &combiner 12 6>,
> +					<3 &combiner 12 7>,
> +					<4 &gic 0 42 0>,
> +					<5 &gic 0 48 0>;
>  		};
>  	};

> +Example 3: In this example, the IP contains four local timers, but using
> +	   a per-processor interrupt to handle them. Either all the local
> +	   timer interrupts can be specified, with the same interrupt specifier
> +	   value or just the first one.

That sounds like it should be two separate examples.

Actually, there's already a 2-timer example above using separate
interrupts, so why not make this example *just* be for the
single-interrupt case?

> +	mct@10050000 {
> +		compatible = "samsung,exynos4412-mct";
> +		reg = <0x10050000 0x800>;
> +		interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> +			     <0 42 0>/*, <0 42 0>, <0 42 0>, <0 42 0>*/;
> +	};

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/8] Documentation: devicetree: Update Exynos MCT bindings description
Date: Tue, 20 Aug 2013 11:00:53 -0600	[thread overview]
Message-ID: <5213A0C5.9000901@wwwdotorg.org> (raw)
In-Reply-To: <1377006768-23174-2-git-send-email-t.figa@samsung.com>

On 08/20/2013 07:52 AM, Tomasz Figa wrote:
> This patch updates description of device tree bindings for Exynos MCT
> (multicore timers). Namely:
>  - added note about simplified specification of local timer interrupts,
>    when using single per-processor interrupt for all local timers,
>  - changed first example that was incorrectly suggesting that global
>    timer interrupts are optional,
>  - simplified example interrupt map,
>  - added example showing simplified local timer interrupt specification.

> diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt

> -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.
> +  For MCT block that uses a per-processor interrupt for local timers, such
> +  as ones compatible with "samusng,exynos4412-mct", only one local timer

samsung is typo'd there.

> +Example 2: In this example, the timer interrupts are connected to two separate
> +	   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>;
> +		interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
>  
>  		mct_map: mct-map {
> -			#interrupt-cells = <2>;
> +			#interrupt-cells = <1>;

>  			#address-cells = <0>;
>  			#size-cells = <0>;

I don't believe you need either of those two properties in a node solely
used as an interrupt map.

Also, why not put the interrupt-map property directly into the main mct
node; I don't believe there's any requirement nor advantage to it being
a separate node.

> -			interrupt-map = <0x0 0 &combiner 23 3>,
> -					<0x4 0 &gic 0 120 0>,
> -					<0x5 0 &gic 0 121 0>;
> +			interrupt-map = <0 &gic 0 57 0>,
> +					<1 &gic 0 69 0>,
> +					<2 &combiner 12 6>,
> +					<3 &combiner 12 7>,
> +					<4 &gic 0 42 0>,
> +					<5 &gic 0 48 0>;
>  		};
>  	};

> +Example 3: In this example, the IP contains four local timers, but using
> +	   a per-processor interrupt to handle them. Either all the local
> +	   timer interrupts can be specified, with the same interrupt specifier
> +	   value or just the first one.

That sounds like it should be two separate examples.

Actually, there's already a 2-timer example above using separate
interrupts, so why not make this example *just* be for the
single-interrupt case?

> +	mct at 10050000 {
> +		compatible = "samsung,exynos4412-mct";
> +		reg = <0x10050000 0x800>;
> +		interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
> +			     <0 42 0>/*, <0 42 0>, <0 42 0>, <0 42 0>*/;
> +	};

  reply	other threads:[~2013-08-20 17:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20 13:52 [PATCH 0/8] Exynos device tree clean-up for 3.12 Tomasz Figa
2013-08-20 13:52 ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 1/8] Documentation: devicetree: Update Exynos MCT bindings description Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 17:00   ` Stephen Warren [this message]
2013-08-20 17:00     ` Stephen Warren
2013-08-20 17:12     ` Tomasz Figa
2013-08-20 17:12       ` Tomasz Figa
2013-08-20 20:41       ` Stephen Warren
2013-08-20 20:41         ` Stephen Warren
2013-08-20 22:13         ` Tomasz Figa
2013-08-20 22:13           ` Tomasz Figa
2013-08-26 17:21   ` [PATCH v2 " Tomasz Figa
2013-08-26 17:21     ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 2/8] ARM: dts: exynos4: Drop interrupt controller properties from MCT nodes Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 3/8] ARM: dts: exynos4x12: Move MCT node to exynos4x12.dtsi Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 4/8] ARM: dts: exynos4: Simplify MCT interrupt map Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 5/8] ARM: dts: exynos4x12: Move mshc node to exynos4x12.dtsi Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 6/8] ARM: dts: exynos4x12: Keep mshc node disabled by default Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 7/8] ARM: dts: exynos: Fix missing spaces after labels Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 13:52 ` [PATCH 8/8] ARM: dts: exynos4: Add missing unit-address of sysreg node Tomasz Figa
2013-08-20 13:52   ` Tomasz Figa
2013-08-20 14:20 ` [PATCH 0/8] Exynos device tree clean-up for 3.12 Sylwester Nawrocki
2013-08-20 14:20   ` Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5213A0C5.9000901@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ian.campbell@citrix.com \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=s.nawrocki@samsung.com \
    --cc=t.figa@samsung.com \
    --cc=thomas.abraham@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.