From: b-cousson@ti•com (Benoit Cousson)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
Date: Thu, 24 Jan 2013 13:42:51 +0100 [thread overview]
Message-ID: <51012C4B.5080300@ti.com> (raw)
In-Reply-To: <50FFC1B0.8000601@ti.com>
Hi Santosh,
On 01/23/2013 11:55 AM, Santosh Shilimkar wrote:
> Looping Marc, Benoit
>
> On Wednesday 23 January 2013 04:06 PM, 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.
>>
> This seems to be exact same topic what is getting discussed here [1]
> Technically DT is suppose to represent how the hardware is rather than
> how the bindings are done.
>
> But as Marc pointed out, the approach taken currently is to not
> duplicate the banked information. The thread [1] isn't concluded
> yet but looks like we might want to avoid duplicating the information
> considering, more of such duplication needs to follow. e.g gic i/f
>
> Am still waiting on what Benoit has to say ?
I agree with you :-)
I'm not sure the binding was properly done to reflect the HW accurately.
A local timer for my point of view should be located in the cpu node
like a L1 cache. Or at least referenced in each cpu by a phandle.
What was the rational to put it in the root?
Regards,
Benoit
next prev parent reply other threads:[~2013-01-24 12:42 UTC|newest]
Thread overview: 11+ 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 10:15 ` Mark Rutland
2013-01-22 22:05 ` Kukjin Kim
2013-01-23 10:36 ` Mark Rutland
2013-01-23 10:55 ` Santosh Shilimkar
2013-01-24 12:42 ` Benoit Cousson [this message]
2013-01-24 12:53 ` Santosh Shilimkar
2013-01-24 13:16 ` Marc Zyngier
2013-01-30 7:20 ` Santosh Shilimkar
2013-02-04 22:25 ` kgene at kernel.org
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=51012C4B.5080300@ti.com \
--to=b-cousson@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox