All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Covington <cov@codeaurora.org>
To: Kumar Gala <galak@codeaurora.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	David Brown <davidb@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: dts: msm8974: Move arch-timer out of soc node
Date: Mon, 17 Mar 2014 13:48:22 -0400	[thread overview]
Message-ID: <53273566.20208@codeaurora.org> (raw)
In-Reply-To: <26E59402-2F50-4E42-AAF2-AF321CB51799@codeaurora.org>

Hi Kumar,

On 03/17/2014 01:33 PM, Kumar Gala wrote:
> 
> On Mar 17, 2014, at 12:31 PM, Christopher Covington <cov@codeaurora.org> wrote:
> 
>> Hi Stephen,
>>
>> On 03/11/2014 05:24 PM, Stephen Boyd wrote:
>>> The architected timer is not a register addressable piece of
>>> hardware. Instead it's accessed through cp15 accessors. Move it
>>> to the root of the devicetree to reflect this.
>>
>> I find this confusing, perhaps due to overloading of the word "register".
>> Aren't CP15's a class of coprocessor _registers_? Could it perhaps be clearer
>> to talk about memory-mapped versus CP15-mapped timers?
>>
>> Is "soc" documented somewhere or is it just a name for a container? Assuming
>> the latter, it's not obvious to me why being a child of a system on chip node
>> would imply having memory mapped registers.
> 
> “soc” is a container, since its compatible = "simple-bus”, this implies
> memory mapped register access for nodes inside of it.

That makes sense. Thanks for explaining it.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

WARNING: multiple messages have this Message-ID (diff)
From: cov@codeaurora.org (Christopher Covington)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: msm8974: Move arch-timer out of soc node
Date: Mon, 17 Mar 2014 13:48:22 -0400	[thread overview]
Message-ID: <53273566.20208@codeaurora.org> (raw)
In-Reply-To: <26E59402-2F50-4E42-AAF2-AF321CB51799@codeaurora.org>

Hi Kumar,

On 03/17/2014 01:33 PM, Kumar Gala wrote:
> 
> On Mar 17, 2014, at 12:31 PM, Christopher Covington <cov@codeaurora.org> wrote:
> 
>> Hi Stephen,
>>
>> On 03/11/2014 05:24 PM, Stephen Boyd wrote:
>>> The architected timer is not a register addressable piece of
>>> hardware. Instead it's accessed through cp15 accessors. Move it
>>> to the root of the devicetree to reflect this.
>>
>> I find this confusing, perhaps due to overloading of the word "register".
>> Aren't CP15's a class of coprocessor _registers_? Could it perhaps be clearer
>> to talk about memory-mapped versus CP15-mapped timers?
>>
>> Is "soc" documented somewhere or is it just a name for a container? Assuming
>> the latter, it's not obvious to me why being a child of a system on chip node
>> would imply having memory mapped registers.
> 
> ?soc? is a container, since its compatible = "simple-bus?, this implies
> memory mapped register access for nodes inside of it.

That makes sense. Thanks for explaining it.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

  reply	other threads:[~2014-03-17 17:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 21:24 [PATCH] ARM: dts: msm8974: Move arch-timer out of soc node Stephen Boyd
2014-03-11 21:24 ` Stephen Boyd
2014-03-17 17:31 ` Christopher Covington
2014-03-17 17:31   ` Christopher Covington
2014-03-17 17:33   ` Kumar Gala
2014-03-17 17:33     ` Kumar Gala
2014-03-17 17:48     ` Christopher Covington [this message]
2014-03-17 17:48       ` Christopher Covington

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=53273566.20208@codeaurora.org \
    --to=cov@codeaurora.org \
    --cc=davidb@codeaurora.org \
    --cc=galak@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sboyd@codeaurora.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.