All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	'Thomas Abraham' <thomas.ab@samsung.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	'Tony Lindgren' <tony@atomide.com>
Subject: Re: [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
Date: Wed, 23 Jan 2013 07:55:26 -0600	[thread overview]
Message-ID: <50FFEBCE.3080502@gmail.com> (raw)
In-Reply-To: <20130123103614.GD32237@e106331-lin.cambridge.arm.com>

On 01/23/2013 04:36 AM, Mark Rutland wrote:
> On Tue, Jan 22, 2013 at 10:05:18PM +0000, Kukjin Kim wrote:
>> Mark Rutland wrote:
>>>
>> + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren
>>  
>>> On Tue, Jan 22, 2013 at 01:41:27AM +0000, Kukjin Kim wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Need to be changed requirements in the 'cpus' node for exynos5440
>>>> to specify all the per-cpu interrupts of arch timer.
>>>
>>> The node(s) for the arch timer should not be in the cpus/cpu@N nodes.
>>> Instead, there should be one node (in the root of the tree).
>>>
>> Well, I don't think so. As per my understanding, the local timers are
>> attached to every ARM cores (cpus) and it generates certain interrupt to the
>> GIC. So the correct representation for this in device tree is to include the
>> interrupts in the cpu nodes in dts file. Your comments  refer to a
>> limitation in the Linux kernel implementation of the arch_timer and it
>> should not result in representing the hardware details incorrectly in the
>> dts file.
> 
> I disagree. The "correct representation" is whatever the devicetree binding
> documentation describes. It does not describe placing timer nodes in the cpu
> nodes.

I don't think we should add other nodes to /cpus besides cpu nodes.

The presence of architected timers is defined by the cpu being a
Cortex-A15. So you don't really need a timer node at all. All that is
really needed is the interrupt. You could add interrupts property
directly to each cpu node. The location of PMU nodes has come up
recently as well, and the PMU interrupt could be added as well.

Whether we should change the binding at this point is questionable.
Normally, we wouldn't want to do that, but as this is all pretty new it
may be okay to make an exception here. However, I don't see anything
that is fundamentally broken with the current binding. Multi-cluster
could introduce some issues.

>>
>>> If this works currently it's only because the driver picks up one of the
>> nodes,
>>> and luckily it's the same as the others. This is not guaranteed to work in
>>> future, and will likely break.
>>>
>> It is up to the Linux kernel implementation of arch_timer to handle the
>> hardware details in dts file accordingly.
> 
> The binding specification does not specify that there should be multiple timer
> nodes, nor does it specify that they should be under cpu nodes. The timers,
> being a banked resource, can be described with one node.
> 
> It is not up to the Linux kernel to handle undocumented variations of bindings.

Except things done before documentation was enforced.

Rob

WARNING: multiple messages have this Message-ID
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
Date: Wed, 23 Jan 2013 07:55:26 -0600	[thread overview]
Message-ID: <50FFEBCE.3080502@gmail.com> (raw)
In-Reply-To: <20130123103614.GD32237@e106331-lin.cambridge.arm.com>

On 01/23/2013 04:36 AM, Mark Rutland wrote:
> On Tue, Jan 22, 2013 at 10:05:18PM +0000, Kukjin Kim wrote:
>> Mark Rutland wrote:
>>>
>> + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren
>>  
>>> On Tue, Jan 22, 2013 at 01:41:27AM +0000, Kukjin Kim wrote:
>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>
>>>> Need to be changed requirements in the 'cpus' node for exynos5440
>>>> to specify all the per-cpu interrupts of arch timer.
>>>
>>> The node(s) for the arch timer should not be in the cpus/cpu at N nodes.
>>> Instead, there should be one node (in the root of the tree).
>>>
>> Well, I don't think so. As per my understanding, the local timers are
>> attached to every ARM cores (cpus) and it generates certain interrupt to the
>> GIC. So the correct representation for this in device tree is to include the
>> interrupts in the cpu nodes in dts file. Your comments  refer to a
>> limitation in the Linux kernel implementation of the arch_timer and it
>> should not result in representing the hardware details incorrectly in the
>> dts file.
> 
> I disagree. The "correct representation" is whatever the devicetree binding
> documentation describes. It does not describe placing timer nodes in the cpu
> nodes.

I don't think we should add other nodes to /cpus besides cpu nodes.

The presence of architected timers is defined by the cpu being a
Cortex-A15. So you don't really need a timer node at all. All that is
really needed is the interrupt. You could add interrupts property
directly to each cpu node. The location of PMU nodes has come up
recently as well, and the PMU interrupt could be added as well.

Whether we should change the binding at this point is questionable.
Normally, we wouldn't want to do that, but as this is all pretty new it
may be okay to make an exception here. However, I don't see anything
that is fundamentally broken with the current binding. Multi-cluster
could introduce some issues.

>>
>>> If this works currently it's only because the driver picks up one of the
>> nodes,
>>> and luckily it's the same as the others. This is not guaranteed to work in
>>> future, and will likely break.
>>>
>> It is up to the Linux kernel implementation of arch_timer to handle the
>> hardware details in dts file accordingly.
> 
> The binding specification does not specify that there should be multiple timer
> nodes, nor does it specify that they should be under cpu nodes. The timers,
> being a banked resource, can be described with one node.
> 
> It is not up to the Linux kernel to handle undocumented variations of bindings.

Except things done before documentation was enforced.

Rob

  parent reply	other threads:[~2013-01-23 13:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  1:41 [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440 Kukjin Kim
2013-01-22  1:41 ` Kukjin Kim
2013-01-22 10:15 ` Mark Rutland
2013-01-22 10:15   ` Mark Rutland
2013-01-22 22:05   ` Kukjin Kim
2013-01-22 22:05     ` Kukjin Kim
2013-01-23 10:36     ` Mark Rutland
2013-01-23 10:36       ` Mark Rutland
2013-01-23 10:55       ` Santosh Shilimkar
2013-01-23 10:55         ` Santosh Shilimkar
     [not found]         ` <50FFC1B0.8000601-l0cyMroinI0@public.gmane.org>
2013-01-24 12:42           ` Benoit Cousson
2013-01-24 12:42             ` Benoit Cousson
     [not found]             ` <51012C4B.5080300-l0cyMroinI0@public.gmane.org>
2013-01-24 12:53               ` Santosh Shilimkar
2013-01-24 12:53                 ` Santosh Shilimkar
2013-01-24 13:16             ` Marc Zyngier
2013-01-24 13:16               ` Marc Zyngier
2013-01-30  7:20               ` Santosh Shilimkar
2013-01-30  7:20                 ` Santosh Shilimkar
2013-02-04 22:25                 ` kgene
2013-02-04 22:25                   ` kgene at kernel.org
2013-01-23 13:55       ` Rob Herring [this message]
2013-01-23 13:55         ` Rob Herring

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=50FFEBCE.3080502@gmail.com \
    --to=robherring2@gmail.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=thomas.ab@samsung.com \
    --cc=tony@atomide.com \
    /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.