linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
Date: Wed, 30 Jan 2013 12:50:41 +0530	[thread overview]
Message-ID: <5108C9C9.4010409@ti.com> (raw)
In-Reply-To: <51013432.3080903@arm.com>

Benoit,

On Thursday 24 January 2013 06:46 PM, Marc Zyngier wrote:
> Hi Benoit,
>
> On 24/01/13 12:42, Benoit Cousson wrote:
>> 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?
>
> The rational was to follow what we already do for most (all?) banked
> resources. We already have TWD, GIC and PMU that have a root node,
> avoiding duplicated resources. I think consistency is an important thing
> to have.
>
> If we decide to move everything into CPU nodes and duplicate all the
> banked resources, fine. But that has impacts that reach far beyond the
> simple case of the timer.
>
> In particular, good luck with the GIC distributor interface, where the
> 32 first interrupts are per CPU. This would also mandate a redesign of
> the way we specify a PPI, as the CPU mask in the third field doesn't
> mean a thing anymore.
>
> If you insist on having a phandle to a timer node, fine by me.
>
Can you please comment on it so that we can conclude this thread ?
I would like to update my patches and hence the push.

Regards,
Santosh

  reply	other threads:[~2013-01-30  7:20 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
2013-01-24 12:53           ` Santosh Shilimkar
2013-01-24 13:16           ` Marc Zyngier
2013-01-30  7:20             ` Santosh Shilimkar [this message]
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=5108C9C9.4010409@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).